I just noticed I missed the part about the first 5 drives. I'm assuming you are referring to the first 5 drives in enclosure 0 bus 0?

If so, there is nothing preventing you from using them, but I personally wouldn't use them for anything like an Exchange database or log files. If you have to use them I would recommend something that doesn't require high performance (backup space or application files maybe). I actually block usage of this space on all my arrays except for temporary emergency use. Other than that they sit empty.

The reason behind this can be found discussed in many places on the Forums, and in several EMC whitepapers but it boils down to this. The first five drives 0_0_0 through 0_0_4 are used by the CLARiiON for a few special purposes and "busy" LUNs built on these drives can affect the performance of the internal software of the array itself. So while you can use them, you should be aware of what you are doing and why you are doing it before you make that call.

When building the Meta-Luns, I should choose Striping, correct?

For what you are doing, definitely. This will evenly distribute the IO load over all underlying drives in all the RAID groups used for the Meta element LUNs.

Thanks.

It turned out I needed only 18 luns and I didn't use the Vault disks. I used the remaining 31 and split them into 6 RAID 5 groups. I bound 9 luns to each RG and then merged them into 18 Meta-luns. Each Meta-Lun is spanning 3 Raid Groups.

No problem. And that sounds good.

Out of curiosity, did you Put the Metas together from groups of LUNs from the same raid groups or did you stagger them around?

example of type 1:
RAID Group 1 - LUN10, LUN11, LUN12
RAID Group 2 - LUN20, LUN21, LUN22
RAID Group 3 - LUN30, LUN31, LUN32
RAID Group 4 - LUN40, LUN41, LUN42

Meta1 (LUN10, LUN20, LUN30)
Meta2 (LUN11, LUN21, LUN31)

example of type 2:
Same RAID Groups

Meta1 (LUN10, LUN20, LUN30)
Meta2 (LUN21, LUN31, LUN40)
Meta3 (LUN32, LUN41, LUN11)
etc.

Just curious, as I think the second layout would better spread the performance and avoid concentrating what the gurus call the "leading edge" of the Meta Stripes. I should have mentioned this earlier *lol* but I just thought of it when you said how you layed it out in the end.

I did it like the first one. That's okay. Its easy to change it up some.

I've read about rotating the "base" LUN of a MetaLUN from the Best Practices guide (p.20) but still don't completely understand it. If it's to distribute the "hot edge", wouldn't you have to use something like the following configuration?

RAID Group 1 - LUN10, LUN11, LUN12
RAID Group 2 - LUN20, LUN21, LUN22
RAID Group 3 - LUN30, LUN31, LUN32

Meta1 (LUN10, LUN21, LUN32)
Meta2 (LUN20, LUN31, LUN12)
Meta3 (LUN30, LUN11, LUN22)

Assuming that LUNs get created from the from the outside of the disks first (is this true?), shouldn't the MetaLUNs all start with the first LUN created from each RAID group? This probably only works if everything gets carved up at the same time and LUN sizes being the same.

I think I get where you're going with rotating the base LUNs, but how about also using LUNs from all four RAID groups instead of just three?

I think my confusion is coming from my understanding of the "hot edge" (outer edge of disk) and the diagram from p21 of the Best Practices guide. Help?

-merill

Hello Merril.

I think you got the reason for rotating the base LUN but I'll just add the following; Typically some file system metadata is placed in the same logical space on that particular file systems construction. This is probably more applicable to some journalled file systems.
If you took the 1st LUN in each metaLUN from the same raid group, the result could be that metadata placed with the same logical offset from block 0 of that device would be subject to more activity.

Now, if you have several metaLUNs all with their 1st LUN from the same raid group, the same logical offset on all metaLUNs could therefore end up on the same spindle (where a disk itself actually starts i.e. inner or outer tracks doesn't really matter). With that in mind, if metadata updates were taking place across all the metaLUNs whilst in use, this could result in more spindle contention than if you offset each metaLUN start LUN by using a different raid group.

Using 4 raid groups rather than 3, no problem with that. How you actually make up the metaLUN is your decision due to the flexibilty in the implementation. Thus, if your application requires the IOPs capability of 100 drives, using 20 * 4+1 Raid 5 groups would fulfill that however you would then need to look at your application capability to drive the IO to that many drives i.e. target queue depth and concurrency. Maybe that specific example is a bit far fetched, but spreading many loads across many spindles is a good way to go if you don't have specific requirements for dedicated LUNs, but many loads with different peak time activity - an ideal way to utilise many spindles to absorb these peaks.

~Keith