Unsolved
This post is more than 5 years old
22 Posts
0
2677
Striped Meta Expansion / Clones / BCVs ?
I have to do various striped meta expansions. This works well but is a slow process, taking over 45 minutes to add 2 meta members to a 1.4 TB LUN for example, and is also somewhat restrictive, in that we can only expand by identical meta members, so for my 8-way 1.4 TB meta, with each meta member of 175 GB, I can only extend by increments of 175 GB. We have migrated onto EMC from HDS USP-V where expansions are much more flexible (even though USP-V is a much older environment than VMAX it can expand by any amount very fluidly) so the OS teams are critical of this limitation of VMAX.
I guess another option would be to clone the LUN to a larger target and then unmount the old LUN and present the copied one. However, this would require a Clone license, but we don't have that, so ... what other way is there to do this? Is it possible to create a larger LUN, then copy the data from a smaller LUN in there, and then present that LUN to the host?
Dream93
72 Posts
0
September 8th, 2014 03:00
i think auto-meta is not related to this. basically auto-meta is nothing but what the name implies - i.e. some configuration settings that symm can use to 'automatically' create metas. for ex, one can define a setting such that if user tries to create volume >500GB, symm can automatically create meta Lun (composite volume). these settings can also tell the meta configuration used by symm...
Whereas the question here, expanding a stripe meta to any size similar to concatenate meta?
Regards.
rwise1
22 Posts
0
September 8th, 2014 05:00
The maximum size for a single symdev is 240 GB. Meta's are required above that size. We can either create meta's manually (by creating the symdevs and forming a meta), or use Auto-Meta to specify a size (say 1 TB) and the VMAX will automatically create the right size of symdevs to form a 1 TB meta, so auto-metas are not related here.
What I am basiaclly interested here is in taking a striped-meta (either single symdev or meta, and either concat, or striped), and then migrating it internally on the box (ideally online, but also offline seems impossible on VMAX) to another, larger sized meta. It's been pointed out to me that HDS could do this 8 years ago (not 5 as I previously thought - and HDS does all this non-disruptively online), so it is incredible to me that VMAX can't take an arbitrarily sized LUN, and then migrate or expand it to an arbitrarily sized LUN in the same box, which seems a very reasonable and straightforward operation that we would want from an array (and particularly Virtually Provisioned arrays where it should not matter how the data is stored on the box), but so far in this thread, it seems to be that the answer is this operation is completely impossible in-box on a VMAX !