Expand Lun, use unused space in same raid group?

take a look at document:

EMC. "Whitepaper: EMC CLARiiON MetaLUNs-- A Detailed review" EMC  Powerlink,
http://powerlink.emc.com/km/live1/en_US/Offering_Technical/White_Paper/H1024.1_clariion_metaluns_cncpt_wp_ldv.pdf

specifically look for section "Stacked MetaLUN"

Thanks a ton!!!

Great info.  If I read that section correctly it seems as though it is a big no for striped, and a tentative yes for concat?

Note a stacked MetaLun only has poor performance for striped component LUNs.  For stacked concatenated component, LUNs performance is not greatly affected.

Anyway, thanks for the quick response

Thanks Glen. What about striped metaLUN with components from the same raid group used for heavy random i/o ?

Not real sure about this - if you think about the stacked concept and then stripped, you would expect the performance is suffer under most conditions, but more with large, sequential IO. Maybe small, random IO would be OK, but I would still recommend not vertically stripping metaLUN components in the same raid group.

glen

If you concatenate the two LUNs in the same Raid Group, performance will be about the same as with the original LUN - no gain in performance, but no real loss either.

Best would be to create a new LUN in a different raid group that has the same number of disks and raid type, create a LUN exactly the same size and you can stripe the two together - you gain the extra space and about double the performance. This of course depends on what's going on in the second raid group - if it's heavily utilized, you could actually lower the performance due to interference from LUNs in the other raid group.

glen

Thanks, I appreciate all the help

In a small block random workload with low or very low locality, a stacked MetaLUN would not have an adverse effect on performance.  This is because the drive heads  are skewing all over the RAID group's drives anyway.  However, this type of I/O is not common.  Most random I/O has a certain degree of locality, which restricts the drive head movement to a narrower region of the drives.  A stacked MetaLUN would have more than one region, where the drives would be 'popping' back and forth betweent them.

Again, it comes back to how well you understand your I/O: sequential, mixed, random.  If its random, how much locality does it have?  While stacked MetaLUNs are not recommended, if the System Administrator understands his or her choices and is willing to accept the consequences, there is no prohibition in Navisphere or FLARE in creating them.

Thanks John. What metrics in Navi analyzer can help determine low/high locality ?

Could you not LUN migrate (assuming you have some free space) into a larger LUN?  That would take the LUN "stacking" out of the equation.  Perhaps a two-step process (migrate elsewhere, migrate back) but based on the original post it was only 146GB.

Dan

That probably would have worked as well, just migrate it to some temp space, then destroy the lun, then rebind it with the correct amount of space.  Don't think I've ever had to migrate a lun, so I'll have to test that 

In the end, after evaluating I/O type, performance, raid group, and time constraints,  we decided to concat into the same raid group, however great information in terms of provisioning in this thread, so thanks to everyone.

It would be interesting to know if navi analyzer did have metrics for locality.

Look at the Disk value Average Seek Distance (GB) - this gives a rough estimate of how far the heads are seeking in GB's. If you have a 100GB disk and the ASD is 50GB's, then you can assume that the heads are seeking 1/2 the capacity of the disk - probably very random. The closer you get to zero, the more sequential the seeks.

You can also look at Full Stripe Writes - if the writes are very sequential this number should approach Total Write IOPS.

Look at Read Cache Ratio - the closer the ratio to 1, the more sequential the Reads and the more Read Cache Hits/s you will get.

The data is there, just in different places - you need to put the different values together to make an approximation.

glen

You can use "Average Seek Distance" for the disk object. Of course, if you have multiple partitions on the RAID group or are using the disks in a pool, I wouldn't expect to see any locality at the disk level.

Thank you Glen and John ..very helpful.

jps00 wrote: You can use "Average Seek Distance" for the disk object. Of course, if you have multiple partitions on the RAID group or are using the disks in a pool, I wouldn't expect to see any locality at the disk level.

what did yo mean by multiple partitions ? Multiple LUNs ?  So if i look at disk object and i know that disk belongs to a RAID group where MetaLUNs are being utialized, what would be the most effective process to find out if particular LUN/MetaLUN has high/low locality. At that point i can't rely on disk object metrics and have to look at LUN metrics only  (Read Bandwidth with Prefetch Bandwidth, Read/Write Cache Hits ..etc)?

Thanks a lot