Growing LUNs on a VMAX

You can form a non meta device already bound to a pool into a concatenated meta. (I think it requires 5875).  Since even concatenated metas effectively touch every disk in the thin pool, the performance difference isn't as drastic as a concatenated vs striped meta on a clariion.

Concat and Striped both can be expanded online in VMAX. I know expanding a LUN in CX is far easier than in VMAX but you can certainly do it.

You are using pools so you shouldnt have any trouble growing a windows lun.  In 5875 you can take a non-meta device and turn it into a meta volume as a way to grow it; 5874 the device had to be a meta before being bound to a pool.  With pools you should be creating concatenated meta-volumes anyway as the data is already striped across the TDAT's in the pool.

Take a look around powerlink for virtual lun migrator as well.

RobertDudley wrote:   With pools you should be creating concatenated meta-volumes anyway as the data is already striped across the TDAT's in the pool.

no necessarily, we had discussions with our TC and SPEED guys and striped is still recommended.

Can you elaborate on this?

I don't see any option in SMC to grow a device.

Assuming this needs to be done with symconfigure, can you let me know where this is covered in the documention?

wonder if you have to upgrade SMC to 7.2 to take advantage of new features in 75.

Agree with Dynamox, striped thin meta gives better performance than concat thin meta in some cases...I guess earlier the main reason for recommending concat thin meta coz there was no way to expand the striped thin meta using protect data option...?

just my thoughts...

regards,

Saurabh

75 is only supported with SMC/SE 7.2 or higher...trust me i have seen some real issues if you try to manage 75 with version below 7.2

So which is it?  Stripe metas in a thin pool which is then striping the data twice or as the EMC person put it "in some cases performance is better".  What are the cases where striping a meta in a thin pool results in better performance?  What are the dependencies?  Pool size, data type, data base type, host type etc.

I have had some conversations with incredibly talented performance people from EMC that gave the do not stripe recommendation.

A single logical Symmetrix logical volume cannot deliver the performance of a large backed thin pool.  Say you have an eight engine VMAX with 2400 drives capable of delivering 100s of thousands of backend IOPs.  We know we cannot get all those IOPs through one logical volume even if it was presented on all available FA paths.

So for a host LUN that requires very high performance, you may still need a meta volume, even with a wide striped VP backend, or a host based striped volume over many Symmetrix logical volumes.

As to expansion, you can now expand a striped thin meta on VMAX with 5875 code, but it requires a thick BCV meta that matches the configuration of the thin meta you are trying to expand.

From Best practices for fast, simple capacity allocation with emc virtual provisioning.

With Synchronous SRDF®, Enginuity allows one outstanding write per thin device per path. With concatenated metadevices, this could cause a performance problem by limiting the concurrency of writes. This limit will not affect striped metadevices in the same way because of the small size of the metavolume stripe (1 cylinder or 1920 blocks).
Enginuity allows eight read requests per path per thin device. This limits the number of read requests that can be passed through to the thin pool regardless of the number of data devices that may be in it. This can cause slower performance in environments with a high read miss rate.
Symmetrix Enginuity has a logical volume write pending limit to prevent one volume from monopolizing writeable cache. Because each meta member gets a small percentage of cache, a striped meta is likely to offer more writable cache to the meta volume.
Before configuring striped metadevices, please consult with an EMC performance specialist.

Caution: Striped thin metadevices cannot be expanded while preserving data.

Quincy should be able to add more to it...

regards,

Saurabh

How long would you expect an expansion to take to grow a 1TB 50 way striped meta by 400GB with data preservation?  Several hours, a day? Just trying to get an idea how long.

Traditionally (on DMX3/4) it would take as much time as it would take to copy 500GB of data to a RAID10 symdev and back again. I guess 2 times half an hour or so ? Maybe less, maybe more, which depends on how busy your machine is and how large the symdevs in your META are (how many physical spindle are helping to move the data back and forth).

I tested out the thin striped meta expansion after we upgraded to 5875 recently, the commit took around 4 hrs to complete for a 100gb TDEV.

Hi Woodzy.  Could you give me some high level steps to expanding a striped meta using the BCV method? I am not familiar with this process.  Was it a strictly online process where the host never lost access to the LUN.  thanks in advance