- 1 Vapor IO Brings OpenDCRE to General Availability
- 2 VMware Takes the Wraps Off vRealize Automation and vRealize Business
- 3 Microsoft Previews Hyper-V Containers for Windows Server 2016
- 4 Mirantis Led FUEL Project Gets Installed Under OpenStack Big Tent
- 5 Red Hat Enterprise Linux 7.2 Adds Security, DR Features
Get Ready for RAID-6 Page 2
Checking RAID Performance
There are two parts of RAID controllers to consider to ensure they can meet the performance requirements of RAID-6 compared to RAID-5, since almost every midrange RAID vendor has designed its controller around RAID-5 performance requirements rather than RAID-6. One is the performance of the processor calculating the parity, and the second is the performance of the back-end channels.
The performance of the processor should be pretty easy to measure. Ask the vendor to take a single disk tray or at most four disk trays. Before you begin you must understand the number of back-end connections and the performance of those connections. For example, if you have four back-end 4Gb FC connections, you will need to match those four connections with four FC HBAs and a system or systems that can run those HBAs at full rate. You must ensure you match the front-side performance (performance from server to RAID) with the backside performance (performance from RAID controller to the disk trays). Create a 4+1 LUN and a 4+2 LUN and use a program that can write to the raw device with multiple threads such as xdd from www.ioperformance.com. The write to the 4+1 should be the same as the 4+2.
Now do the same for as many LUNs as you have performance to run at full rate. Assume full rate in two ways. Take the maximum performance of the disk drives in the LUN using outer cylinders and ask the vendor what the maximum performance is to the disk tray. Take the lower value of these two numbers. Repeat using 8+1 and 8+2 for as many LUNs as you have performance to run at full rate. The performance for writing where parity performance is critical should be the same. If it is not, then the parity processor is not fast enough, the performance of the back end of the RAID is not designed well, or both.
Determining if it is the processor is difficult, and in this day and age not as likely, since high performance processors are fairly cost-effective. On the other hand, designing the back end of RAID controllers is complex, so that is most often the likely culprit. Today, most RAID controllers support an FC fabric connection to each of the disk trays, and within the tray with either FC-Al, SATA or SAS connections within the disk tray. The first thing to understand is the ratio of performance from the RAID controller to the hosts compared to the performance of the RAID controller to cache. Often for midrange controllers, the ratio is between 1 to 1 and 1 to 4 and sometimes more (more bandwidth from the controller to the disk trays). Remember, for RAID-6, you are going to use more bandwidth as the second parity drive is written and, for many vendors, read.
Take the following example. Let's say you have four 4Gb FC for the front-end performance and six channels from the cache to the disk trays (1 to 1.5).
Number of LUNs
Total Bandwidth Required to RAID Controller in MB/sec
Total Bandwidth Required to Disk in MB/sec
The RAID controller described above would use the maximum bandwidth available for the four 4+2 LUNs. This is neither good nor bad, but just a fact that RAID-6 uses more bandwidth than RAID-5. Some vendors address this bandwidth issue for reads by not reading all of the parity drives, so the problem would only be on writes; other vendors do other things. Of course this is worst-case for streaming I/O, but the same concepts are true for IOPS but the issues are seek and latency for IOPS and not bandwidth.
RAID-6 will require more bandwidth than RAID-5 and could affect the performance of your RAID controller. The write example I give can be caused not only by a user writing from a host, but also if the controller requires a LUN to be reconstructed. It is important, especially for RAID-6, to understand the back-end performance of the RAID controller and relate that to the planned LUN configuration. The performance of the controller from the cache to host is always slower for midrange products than cache to disk, and for enterprise products this is now also the case.
What this all means is that before you buy any RAID controller, understand the planned configuration and how much I/O is needed by the hosts and add in the potential for a rebuild. RAID-6 configurations need to be considered, since they will require more bandwidth between the cache and disk trays and RAID-5.
This article was originally published on Enterprise Storage Forum.