Multi RAID-GROUP in a LUN

First off I would recommend that you get the "EMC CLARiiON Best Practices for Fibre Channel Storage: CLARiiON Release xx Firmware Update". You can find this on Powerlink by searching for "EMC CLARiiON Best Practices for Fibre Channel Storage".

You can combine one LUN from each of the Raid Groups and combine all those LUNs into one metaLUN.

There are two types of metaLUNs, stripped and concatenated.

Stripped is the best choice if you need performance, in this case each LUN must be the same size. Stripped metaLUN combines the LUNs into one large metaLUN and the performance will be based on the number is total data disks (not counting the parity disks). Stripping takes a long time to finish.

Concatenated metaLUN is best if you just need extra space and are not concerned with performance - it is also available immediately.

In all cases be careful about using metaLUNs - once you create the first metaLUN, the RG's that you used become a Hyper Group - you should then in the future only use the RGs in the Hyper for metaLUNs and always use all the RG's.

regards,

glen kelley

Yes, you can combine LUNs into MetaLUNs and create a single multi-terabyte LUN.

If you will be putting a single filesystem on this LUN check first that your filesystem of choice supports making a filesystem that large. Then check its performance, including "full" fsck's. In particular ext2 and ext3 can take a very long time to check when a full fsck is required. Waiting an hour or more for a system to come up while it is running fsck on a single large filesystem can make for some irate users.

Exactly how large is this super metalun going to be ?

146GB disks: 9x146 x 6 = 54x146 = ±8TB
300GB disks: 9x300 x 6 = 54x300 = ±16TB

What is your plan ?
I would definately suggest calling EMC for help with this hge metalun, since I cannot image large sizes such as this are supported. But indeed: best pratices should be read as well.

Glen,

Can you explain further the reason for only creating metaLUNs in a Raid Group, once that RG has been used for metaLUNs. I cannot find any reference to Hyper Group in the Best Practices White Paper.

Is this a firm recommendation by EMC?

Thanks,

Dave.

No, this is not a firm recommendation - just something that we've seen when there are a VERY large number of metaLUNs (more than 50) that have the component LUNs scattered all over the Raid Groups. We've seen performance issues with one disk in a Raid Group when this condition is met - seems like the metaLUNs cross by chance in one Raid Group and this crossing seems to affect just a couple of disks or just one.

MetaLUNs are stripped differently the normal LUNs - the parity disk gets moved around. This seems to make the access to individual disks somewhat different. We looked at a number of configurations and noticed that this did not happen if you keep metaLUNs in the same RG's, use all component LUNs in the "hype group" for each metaLUN, rotate the meta head (the first LUN in the metaLUN) to different RG's, don't use component LUNs from different hyper groups, etc.

Again, this is a rare occurance but we're starting to see it more often as metaLUNs get used more.

glen

I also want to add that some of this metaLUN information may not be completely accurate - as I said, I'm not real clear on the underlying reasons for this behavior and we are working to refine this.

The important point is to be very methodical about the way you layout metaLUNs - really try to understand that the lowest common point is the disks - they have limitations based on rotation speed and head seek time - when you start to layout many LUNs across the disks, if the disks get into head thrashing, you'll see performance issues. Think about the way that the LUNs are stripped on the physical disks and what would happen if one of those LUNs belonged to a metaLUN, say at the outside of the platter and other LUNs were in the inner of the platter - you could get a situation where the heads are flying back and forth across the platter - long latency times.

glen