Articles: Storage
 

Bookmark and Share

(2) 

Table of Contents

Pages: [ 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 ]

Testing RAID controllers is a daunting and unrewarding task. Although the process can be automated well enough, it takes a very long time. There are too many long tests producing too many numbers. But as we have already tested as many as six SAS RAID controllers of the latest generation, one from each major brand, we can’t miss the opportunity to throw them all together into a comparative review.

Right now, the market is calm. Existing controllers cope with today’s loads well enough. The PCI Express bus has ousted PCI-X while the serial interfaces SAS and SATA have replaced the parallel SCSI and PATA. The SAS 2.0 interface is going to boost bandwidth from 3 to 6Gbps but it is not anywhere near as yet, so the manufacturers have some time to catch their breath and release firmware updates to solve various bugs and optimize performance. We have to confess that we will compare the controllers with those firmware versions that were the newest at the time of our acquiring and testing them. Perhaps this is not quite correct as the controllers tested most recently have an advantage, but we don’t have an opportunity to test as many as six controllers all at the same time.

Before making any comparisons, we want to explain what results we expect. First of all, we expect stable operation and high performance, preferably predictable performance. Unfortunately, stability can hardly be checked out. While all the controllers worked flawlessly on our testbed, some users report problems related to specific combinations of controllers and hard disks. We can’t check out every combination, so you should follow the official compatibility lists or just take the risk. Today’s controllers are generally less susceptible to inexplicable glitches than their predecessors. As for the performance factor, there are some things that we try to focus on.

RAID0 is the simplest case to discuss. The controller only has to cope with load correctly, deliver a high sequential read speed and perform as many random-address operations per second as possible. Multithreaded loads and the processing of files are a special case. Practice suggests that all controllers slow down when processing multiple threads of data but the performance hit varies. It is especially hard when the requests are coming in from a rather short queue. Most controllers have surprisingly low speeds under such seemingly easy conditions. The speed delivered when processing files is usually much lower than what we can see in synthetic benchmarks. Sometimes, a controller may write one and the same file (or a set of files) faster than read it. This is partly due to the amount of cache memory which has grown up to 256 or even 512 megabytes, but our test loads are designed to be bigger than the controller’s total cache. Thus, it is the controller’s firmware algorithms that must be held responsible for such capricious performance.

Mirror-based arrays, RAID1, RAID 10 and RAID1E, are somewhat more complex for a RAID controller (you can learn more about RAID1E here if you are not yet familiar with it). Besides the above-mentioned things, there are a few characteristic factors that concern mirror-based arrays only.

First of all, it is the controller’s ability to read data from both disks in a mirror pair simultaneously. The read/write head of one disk is going to be somewhat closer to the necessary sector, so this “luckier” disk can yield the requested data somewhat faster. As a result, a controller that can make use of this technique has an advantage at random reading. Its RAID10 array does not degenerate into a RAID0 built out of half the number of disks but can compete with and even outperform a same-size RAID0.

The second characteristic feature we always pay our attention to is the ability (or the lack thereof) to parallel sequential reading to both disks of a mirror pair. If, while reading a long piece of sequentially located data, the controller does not just read symmetrically from both disks but sends each even-numbered request to one disk and each odd-numbered request to the other disk, the resulting sequential read speed can improve greatly. The value of this improvement usually depends not only on the size of the requested file but also on the size of the chunks the file is being read by. Of course, we want to see a bigger performance growth at a smaller size of the data chunk.

The third feature is the ability to parallel multithreaded load into different disks of mirror pairs. If the controller can identify this kind of load (i.e. that it is being requested to read two separate fragments of sequentially placed data), it would be perfect to send each thread of requests to one disk of a mirror pair. We guess it is clear that this technique can produce a considerable performance boost, too.

Summing it up, mirror-based arrays are not so simple to work with. The controller’s firmware has to effectively identify the type of load and apply appropriate optimizations in order to meet our requirements. And we are not too strict, actually. All such algorithms have been around for a decade, first introduced in ATA controllers with very weak (by today’s standards) processors.

And finally, there are rotating checksum arrays RAID5 and RAID6. On one hand, the latest generation of controllers find it easier to cope with such arrays as they are equipped with high-performance processors to calculate checksums (or even two checksums as in RAID6). On the other hand, any flaws in firmware are now much more apparent, having been previously concealed by the insufficiently high speed of XOR operations. These types of arrays are becoming more and more demanded because few users want to lose half the disk capacity to build a mirror-based array whereas amounts of crucial information that requires fault-tolerant storage are growing up at a tremendous rate. Why is RAID6 so popular? It’s simple. Today’s arrays grow to impressive size. Even if you don’t take newest disks, you can easily build a 30-terabyte array out of Seagate’s ST31000640SS with SAS interface. If one disk of such a huge array fails, restoring the array takes not a few hours but a few (or even many) days. For information to be secure during these few days, RAID6 is preferred to RAID5 as being capable of surviving a loss of not one but two disks simultaneously. Yes, a RAID6 suffers a terrible performance hit when two of its disks fail, but it is still usually better than a mirror-based array because the latter has only half the useful capacity, the number of disks in the array being the same.

Winding up this already too long introduction, we want to answer one popular question. Are these controllers any good at all if you can go and buy solid state drives that deliver astonishing performance? Yes, they are good despite that competition. The cost of HDD storage is as yet much lower than that of SSDs. SSDs also have lower storage capacities, so you have to take a few such drives for a serious disk subsystem, in which case it is still handier to connect them via RAID controllers. The performance factor is not so definite, either. While multi-channel (they are multi-channel indeed) SSDs are much better than any HDD-based array at reading, HDDs are not so hopeless at writing. Coupled with the fact that an SSD has a limited number of rewrite cycles, it looks like a RAID array built out of SAS drives is still the most optimal choice for a disk subsystem capable of handling a large number of write requests: it is going to be both cheaper and more reliable.

 
Pages: [ 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 ]

Discussion

Comments currently: 2
Discussion started: 11/09/09 05:37:26 PM
Latest comment: 11/10/09 01:47:23 AM

View comments

Add your Comment