MUNICH—Rohde & Schwarz has begun shipping its R&S SpycerNode media storage system, which was launched in September at the IBC 2018 in Amsterdam.

R&S SpycerNode leverages High Performance Computing (HPS), a combination of hardware, file system and a software approach to RAID that relies on erasure coding in combination with declustering to increase performance and reduce rebuild times, the company said. The system, which can be expanded during operation, also is highly scalable.

Erasure coding means that a data block is always written including parity. Declustering, a software-based strategy, spreads the spare disk over all other disks, which decreases rebuild times and reduces the impact on performance.

The newly shipping product features Rohde & Schwarz’ device manager web application, making setup faster and integration of other Rohde & Schwarz systems easier, the company said. In addition, device manager’s intuitive web-based UI, which is operated from a single client, simplifies maintenance and service.

R&S SpycerNode comes in various 2U and 5U chassis designs available with NL-SAS HDDs (hard disk drives) and SAS SSDs (solid-state disks) with different capacities. The product has main processor units and JBOD (just a bunch of disks) units. A main unit is redundant and equipped with two appliance controllers, each of which has two 100 Gbit interfaces.

More information is available on the Rohde & Schwarz website.

Anyone with any type of high-performance storage system for a video playout server, play-to-air system or nonlinear editing solution of any scale has probably experienced this. One of their disk drives fails completely or you get that error warning of “imminent drive failure—change drive ooooX3Hd immediately!”

Some may procrastinate and risk certain impact. Others take heed and elect to change the failing drive, and still another group sits back knowing they’d planned ahead and bought an extra hot-spare and that the drive controller system will take over without human intervention.

Fig. 1: Characteristics of selected Redundant Array of Independent Disks (RAID) levelsRESILIENCY TO DATA LOSS
When a hard drive in RAID configuration fails there is a period whereby the system fault tolerance or resiliency to data loss decreases. Depending upon the RAID level employed or the protection scheme in place, the risks may range from moderate to serious.

The most significant and primary concern to the system is if another drive in the same array fails. Such a loss compromises the entire storage system and renders all the data in that LUN, array or possibly the system useless.

When the protective element in either the dedicated parity drive (as in RAID 3 or RAID 4) or the secondary protective parity set (as in dual-parity RAID 6) are no longer available, the period between then and when the array is rebuilt and back on line, at 100-percent service level, can be dicey at best.

When a failed or failing drive is detected, the administrator/maintenance technician must first replace the bad drive, which in turn triggers a process called the “RAID Rebuild.” RAID rebuilding is the data reconstruction process, which mathematically reconstructs all the data and its parity complement, so that full protection (with fault tolerance) is restored, in essence returning the system’s resiliency back to a “normal” state.

Sometimes when certain data checks or other errors are detected by the controller, the drive array may go into a reconfirmation period whereby checksums and/or parity algorithms perform a track-by-track, sector-by-sector, block-by-block analysis on each drive. Ultimately, parity or checksums are all compared and/or rewritten and the array is then requalified to a stable, active state.

STEPS TO RECOVERY
RAID fault tolerance involves a number of steps. In one example, should a disk fail, the RAID controller attempts to copy the resilient data to a spare drive while the failed one is replaced. Using parity data and RAID algorithms, which vary depending upon the RAID Level, parity data is then reassembled back to either the dedicated parity drive (as in RAID 3 or RAID 4) or is distributed across all the drives, as in RAID 5 or RAID 6 configurations. See Fig. 1 for selected RAID characteristics.

For other RAID levels, should one of the main data drives fail and no active hot-spare is available, a new HDD must then be installed. Then data from the other remaining drives is reconstructed using data extracted from a dedicated parity drive or from the parity blocks distributed across the array, back onto the new drive. Either way, the risks during the rebuild time are elevated until the new drive is brought online with all the reconstructed data and parity elements having been restored.

Large-scale drive arrays, those with hundreds of spindles (HDDs) usually have sufficient overhead, intelligence and processing bandwidth to compensate for certain fault issues. Those which employ intelligent RAID controllers can also be proactive. Should the RAID controller suspect or detect that a hard drive is about to fail, the proactive controller may begin the process of RAID rebuild to either a (hot) standby drive or signal the user to replace the failing drive, or add another drive in an available slot so that the RAID rebuild process can be kickstarted before an actual failure occurs.

FAILURES DURING THE REBUILD TIME
One of the drawbacks to RAID—when in failure mode or during a rebuild process—is that the performance of certain applications or processes may be impacted due to system latency. System throughput—otherwise known as bandwidth—may be reduced because: (a) not all the drives are functioning; and (b) the rebuild process takes away the I/O speed while it rapidly moves blocks of data sets from the remaining active drives onto the new/replacement drive.

The reduced performance can be especially noticeable when the array is relatively small, i.e., when the number of spindles (drives) is low; or when the individual HDDs are very large.

As hard disk storage capacities continue to increase, rebuild process times will take longer and longer. In some cases, for drives in excess of one to two terabytes, the rebuild process can last from several hours to several days. Of course, during this period, latency and the risk of another failure increases, resulting in performance and usability becoming further compromised. This is one reason, among others, that high-performance storage solutions tend to use smaller capacity HDDs (e.g., 300 GB to 750 GB) and may put many more drives into a single chassis or array.

These issues and considerations become part of the selection and decision process regarding how to choose a storage solution. For the more advanced video server or mediacentric products, those built for mission-critical operations, many manufacturers have already taken these conditions into account and provide sufficient fault tolerance or resiliency to “ride through” most of the more commonplace maintenance, upkeep and failure situations.

Another technology solution involves the use of flash memory or more appropriately, solid-state drives to either supplement the array (as a cache or secondary storage tier) or completely replace the hard disk drive altogether. I’ll explore that topic in greater depth at another time.

Karl Paulsen is a SMPTE Fellow and chief technology officer at Diversified. For more about this and other storage topics, read his book “Moving Media Storage Technologies.” Contact Karl atkpaulsen@diversifiedus.com.

In my April column (“Putting the IOPS Where They Count”), the generalities of Input Output Operations (per second) or IOPS were explored from the physical device that is the hard disk drive (HDD) perspective.

We learned how the combination of disk drives in arrays can support the specific workload requirements of a system. Also discussed was a seldom-addressed factor called the “RAID penalty,” the impact of selecting a given RAID-level against the overall total system IOPS.

Continuing on this theme, solid-state devices (i.e., drives or disks)—known as SSDs—have a different set of impacts on the overall normalized IOPS equation. It is a fairly well-known fact that SSDs will age based upon the number of erase cycles the device is put through over the course of its normal use. Flash memory physics, a primary component of the SSD, is a contributing factor as to how IOPS performance will change.

Specifications for read/write performance are often given for SSDs, and Flash, at the time of their initial placement into service. What is surprising is that performance can (and will) change, sometimes dramatically, once the device is placed into service. This figure is irrespective of the number of erase cycles, but certainly dependent upon the SSD time in service and the number of read/write cycles, with or without erasures.

DIFFERENTIATING IOPS

Table 1: Dramatic IOPS comparison of the same equivalent storage sizes for SSD versus HDD. (A) is for a 12-drive, 50/50 read-write workload; (B) for a 60-drive, 50/50 load; and (C) for a 60-drive 70/30 workload. Note the variations in HDD rotations speeds (15K, 10K and 7K RPM) and the impacts on IOPS for each set of spinning disk arrays.

There are amazing differences in IOPS for SSD versus conventional spinning disks. Take, for example, a spinning disk array made of 10K RPM SAS drives, each in the modest 528 GB capacity (pretend they make such a drive). Given a 50/50 workload ratio of read/write and 12 drives in the array, for a RAID 6 configuration the usable capacity would be 4.7 TB—and the I/O performance would be 429 IOPS. A RAID 5 configuration would be the same usable storage, but IOPS increases to 600 (thus the meaning of the term “RAID Penalty”).

Apply the same configuration in terms of the same number of SSD drives, the same total usable capacity and a 50/05 workload, and the IOPS climb to 34,286 for RAID 6 and 48,000 for RAID 5. That is nearly an 80x increase at RAID 5 and RAID 6 over the HDD.

For a different perspective, change the read/write ratio from 50/50 to 70-percent read and 30-percent write. For the same HDD configurations, the performance for RAID 6 now increase from 429 to 600 IOPS; and for RAID 5, the change goes from 600 to 789 IOPS. For the SSD equivalent, the RAID 6 performance goes from 34,286 to 48,000 IOPS; and for RAID 5 the change is from 48,000 IOPS to 63,156. The increase between HDD and SSD is still an 80x improvement regardless of the RAID configuration. (See Table 1 for additional comparisons.)

CHANGING THE LANDSCAPE

You can easily see why the popularity of SSD in personal laptops, tablets and smartphones (whether you realized they were installed or not) has dramatically changed the overall system performance landscape. But how are these specifications measured, and how are they marketed?

A technical tutorial provided by SNIA (Storage Networking Industry Association) at the January 2015 Storage Visions conference in Las Vegas revealed some surprising issues about how the SSD is rated—especially in its new versus “broken-in” or “steady” states.

Performance of an SSD is about how well it functions at accessing, saving or retrieving the bits. This should be understood independently from the network, the application or any other processes or operations that could influence, negatively, the net overall performance. There are specific metrics used to judge or measure performance—more on this in a bit.

Fig. 1: This graph shows the impacts on drive aging. The STEADY STATE region is the time period used for the measurement, per the suggestions in the SNIA testing document. Note the TRANSITION period between FOB (“fresh-out-of-the-box) and the STEADY STATE (preferred test range) where the IOPS performance will dramatically change.

However, it should be recognized that SSD performance changes over time. There is a period between the “fresh-out-of-the-box” (FOB) and the “steady state” period where there is a “transition” period. The normalized IOPS performance, depending upon the type of memory’s multilevel cell structure, will actually do a step-function—negatively—from a peak FOB IOPS figure to the steady state IOPS measurement. (See Fig. 1 for selected relative comparisons.)

When developing a “level of performance” metric, the measurements will depend upon the type of IO request. The influencing metrics include whether the SSD access is sequential or random in nature, and varies based upon the size of the blocks, the read/write workload (as exemplified from the previous comparison) and how the IO access blocks are physically arranged on the media itself (known as “block alignment”).

Another factor for the performance is the duration of the writes in terms of continuous activity, based upon the number of hours of 100-percent writes across a specified block size (e.g., 4KiB = 4096 kilobytes; the kibibyte [KiB] being a 1000-unit byte for quantities of digital information).

SNIA has addressed a standardized measurement model for ensuring that the same perspectives can be applied across many SSDs. This procedure is detailed in the document “Solid State Storage Performance Test Specification” (PTS), developed, published and validated by SNIA.

How the SSD is used and for what purposes has a lot to do with how well and how long the device will perform and at what performance levels. Enterprise class implementations require much higher overall performance than what is generally put into the market for generic or consumer applications. Enterprise class devices are expected to be run at full workload and under steady state conditions 24/7; so they are tested (and hopefully spec’d) in those environments.

These are the types of devices most often found in professional applications, and for SSDs can come aggregated in all forms of storage configurations (DAS, NAS, SAN) and in as RAID or Tiered storage solutions.

IOPS OR LATENCY

IOPS become important metrics in both consumer and enterprise operations. That said, the management of response times (i.e., the mitigation of latencies) becomes a most important and overriding factor for what are considered high-level IOPS devices. Enterprise class SSDs with comparable IOPS may in actual practice differ significantly in response times and latencies.

Which leads us to the application—another contributing factor that can substantially change the need for some operational statistics in the storage device and physical media type. Random instances of activities that generate high response-time “spikes” become evident and obvious as the spinning gear appears and activities wait for the settling time in memory access.

For media-centric activities, this impact is apparent in editing systems, MAMs, VOD and other activities where high volumes of metadata read/writes are present. When the file is of a contiguous large size—stored sequentially on a storage medium—the read/write performance impact can be relatively insignificant.

However, for the editorial process or for graphics rendering, there are often hundreds of smaller files that are being acted upon, and are often spread randomly across the storage device. Any latency in writing the blocks or in accessing the file chunks will dramatically change performance, making SSDs ideal for metadata and high-volume database activities and potentially unnecessary for contiguous file retrieval.

For video server devices with content caching just ahead of playout, an HDD will provide a suitable real-time performance, assuming it was selected properly and designed for those activities. SSDs can provide improvements (as in VOD systems), but the HDD is, so far, a more economical solution—at least for most long-form content.

That, in a nut shell, is an overview of the issues surrounding SSD performance and a brief introduction on why the IOPS for the HDD is significantly different for an SSD. Later, we’ll look at more recent developments in the cell-structure of NAND, Flash and other SSD devices, and how those improvements influence the performance of SSDs.

In the meantime, choose your SSD wisely and know your application before deciding to wholesale forklift your space-taking, power-consuming, maintenance-intensive disk arrays.

Karl Paulsen, CPBE and SMPTE Fellow, is the CTO at Diversified Systems. Read more about other storage topics in his book “Moving Media Storage Technologies.” Contact Karl atkpaulsen@divsystems.com.