The optimum maximum size of a RAID level-5 group is dependent on the I/O and heavily influenced by the block size.

If your I/O is large block sequential, or has a large sequential  component the 4+1 or 8+1 is best.  This construct leverages the CLARiiON's attempts to perform full-stripe writes.

The optimum maximum RAID group size for random I/O is more flexible.  The number of IOPS required is the primary consideration.  A truely random small block workload can have any RAID 5 configuration that matched its throughput requirement.  For a truly random small block workload any RAID-5 configuration between and including 4+1 and 8+1 works (IOPS dependent).  For example, a 6+1.  However, if there is any sequential component (its really a mixed work load), the 4+1 is the best compromise for capacity and throughput.

Separating the component LUNs of your MetaLUN onto different buses does not provide a performance benefit.  I believe there is confusion with RAID group 'bus balancing' here.  However, separating the component LUNs this way certainly avoids any contention between the component LUNs.

EMC CLARiiON Best Practices for Performance and Availability FLARE Revision 29 contains no prohibition for using SATA drives in MetaLUNs.

Information on RAID group sizing is found in the RAID groups and I/O block size section of the EMC CLARiiON Best Practices for Performance and Availability, FLARE Rev. 29 (Best Practices).  In addition, there is a further discussion of RAID group size in the CLARiiON RAID groups section of the EMC CLARiiON Storage System Fundamentals for Performance and Availability (Fundicmentals) document.  Also of interest is the latest edition of EMC CLARiiON MetaLUNs, this contains a lot of new information on MetaLUN performance.  However, the whitepaper references both Best Practices and Fundamentals.   These documents are available on Powerlink.

Older versions of the Best Practices guide (19, 24 & 26) contained the following statement under the section CLARiiON RAID 5 stripe optimizations:

Reading your reply and noting that the statement relating to MR3 writes has been deleted from the v28 BPG, does this imply that the R5 write algorithms have been adjusted to favour 4+1 & 8+1 ?

The EMC CLARiiON Best Practices are regularly revised to bring the users the best information and the latest thought on performance and availabilty.  For general performance information always refer to the latest (currently FLARE Rev. 29) version.  For ‘speeds and feeds’ data on legacy CLARiiONs, the FLARE Rev. 26 revision should be used.

The CLARiiON’s caching algorithms are constantly being revised and improved.  However, they still work basically the same.

What is most important is to align the workload’s I/O size to the CLARiiON RAID group’s stripe size.  Most file systems, O/Ss, and DBs default to a 256KB, 512KB, or 1MB maximum I/O size.  Note this is a 'Large block I/O General Case', your workload may be different.

Ideally, every I/O going to a RAID group would be a full stripe.  However, the CLARiiON’s cache also tries to coalesce smaller I/O’s into full stripes for efficiency.  The default CLARiiON stripe element size is 64KB.  The stripe size is calculated by multiplying the number of stripe drives (less parity drive) by the stripe element size. For example, a five-disk RAID 5 (4+1) with a 64 KB stripe element size has a stripe size of 256 KB.

The 2+1, 4+1, and 8+1 RAID group configurations stripe size coincide with 256KB, 512KB, and 1MB maximum I/O sizes mentioned above.  Note coincide can means ‘fits exactly,’ or is evenly divisible by, or is an even multiple of.

Having written that, the 2+1 is an unlikely candidate for a parity RAID group. Its ratio of user drive capacity to data protection is low.  With only three spindles, its performance is also low.  Likewise, the 8+1 is not an ideal candidate.  It has a high ratio of capacity to data protection and high performance, but has availablity considerations.  For example, it can take a long time to rebuild an 8+1 in the event of a drive failure.  This leaves the 4+1 as the best candidate.  It has a good capacity to data protection ratio, good performance, and rebuilds quickly.

A detailed discussion of full stripe writes is found in the EMC CLARiiON Storage System Fundamentals white paper in the ‘Stripe Size’ section.  Likewise, a detailed discussion of RAID group to I/O size is found in the EMC CLARiiON Best Practices for Performance and Availality, FLARE Revision 29 in the ‘RAID groups and I/O block size’ section.  Both papers are available on Powerlink.

We ran some timed tests.  Here are the results:

This data is very interesting to me, as I was about to configure a new CX4 using striped Metaluns (SATA II , RAID1_0 groups of 4 or 8 drives, spread over 4 or 5 DAE's, mostly random small block I/O) . Am I understanding correctly that your performance decreased by nearly 10X using striped Metaluns? What is the significance of the Par/Seq notations - is that striped Metaluns vs concatenated (in which case I wouldn't expect to see a performance increase from striping)? Can you add anything about the type of testing you did, or the type of workload? Thanks.

"par" and "seq" stands for parallel and sequential, as in striped metaLUNs.  I made those terms up.

The guy before me created 2 x R5(6+1) RGs in the SAME DAE, and then created Striped MetaLUNs in those 2 RGs in the same DAE.  I called that "sequential" because you can't really write 2 RGs in the same DAE in parallel.  Parallel Striped MetaLUNs would have been in different RGs in different DAEs on different busses.

Yes, you read it correctly.  The "simple" SATA II MetaLUNs, read at 500+ GB/hour, and the old SATA II Striped MetaLUNs read at 57 GB/hr.  We used a sequential read program from CommVault called "diskread", because the problem first showed up as poor backup speed from the CX.  Note that sequential I/O on the CX is just as fast for SATA II R5 as it is for FC R1/0.

Speaking of LUN configuration, we were told to only configure SATA II as R5.  We put the R1/0 on FC drives.

So this was a read-only workload? It's still surprising to me, but my concern is more for the write portion of our I/O (due to historically horrendous performance on our current CX3-10, probably due to its small cache) so I haven't thought about reads much.

After reading your post, I'm thinking I'll try one set of RAID10 SATA 2 RG's over 5 DAE's for metaluns, for the few cases where we really need multi-TB LUNS, but reserve the rest for smaller dedicated LUNS . The multi-TB LUNS tend to be used for VM installations supporting several hundred 10GB OS images, so I could imagine that it might be beneficial to use the striped ML in a case like that where there's random I/O spread over a large LUN, originating from a small number of clients (the VM servers). Hopefully I'll have our new CX-4 accessible in a week or two, and I'll be able to do some testing.

Have you gotten any response from EMC about the unexpected performance loss?