Faced with the prospect of the extra disks needed for RAID 10 or the heavily marketed RAID 5, most users would go with the economic option and choose the latter believing they avoided themselves potential capacity problems for the future. But with 15k FC disks now seen as a norm for an OLTP (with some users even going for SSDs), the need to decide between RAID 10 or RAID 5 is something that needs to go beyond economic considerations. The benefits of Storage administration becoming easier and more accessible via GUIs and single management panes has ironically led to the downside of an emergence of poor storage practices becoming more common place. Enterprise storage systems with unbalanced loads on their BEDs and FEDs, write pending cache levels which are too high despite an abundance of cache, array groups hitting maximums while others are dormant are just some of the situations occurring and causing unnecessary strains and performance problems. Coupled with the sometimes negligent approach to equating the application demands with the relevant storage, performance degradation of expensive high end arrays often leads to hard to trace degraded replication and back up procedures.
Hence the obvious case for RAID 10 to be considered instead of RAID 5 for an OLTP or Exchange database falls in a similar category, with an onset of Storage administrators ready to shake their heads in disagreement, content with the current performance they’ve attained with RAID 5. While on the surface that may be the case, a closer inspection as to how the arrays are affected with regards to the variations in read/write combinations coming from different hosts quickly paints an alternate picture.
In the case when several hundred reads and writes bombard the system, suddenly the effects on the array become apparent. Even with the best tuned cache you will struggle in such a situation if the amount of data reaching the FEDs can't be passed on at the same rate to the BEDs. The result is a high write pending cache level which will then lead to other problems such as high I/O wait times on the host or even arrays unable to accept further writes due to a chockablock backlog. The point to remember is that just because the host believes it has completed its writes, the actual writes being committed to disk are still the responsibility of the array. Like any Christmas shopping rush, order is maintained by a steady flow of customers going through the shop doors avoiding crushes, stampedes and eventual door blocks. In the same vein, pending writes in cache need to be written to disk at a rate similar to how they come in.
With the parity-based RAID 5, applications with heavy random writes can easily cause high write-pending ratios. Thus the suitability of RAID 10 for such applications becomes evident. For sequential reads and writes RAID 5 works a treat due to the minimized head movement. Yet if you fall for the trap of placing a write-intensive workload on RAID 5 volumes instead of RAID 10, you will soon have the burden of the overhead of parity calculations which will in turn affect the performance of the processors. Therefore the erroneous conclusion that saving costs by utilizing RAID 5 and compensating the performance with more cache will only lead to a high write pending level. Hence establishing the ratio of reads and writes generated at the host level and concurrently matching the appropriate RAID type will lead to better performance as well as optimization of your storage array.
To conclude a high write-pending utilization on your cache, could be the symptom of an imbalance on either your host or storage system. If your host has volume management that has striping deployed on the volumes, chances are you're probably not spreading the stripe across all the BEDs. Furthermore the RAID type is probably not the most suitable. With migration tools / software such as Hitachi’s Tiered Storage Manager (formerly known as Cruise Control) it’s a straightforward process of migrating data from one LUN to another transparently, thus allowing you to change from a RAID 5 to a RAID 10 parity group. In such circumstances the cost of RAID 10 may be higher but the performance costs related to mismatching the RAID to the relevant applications will be more so.
