The following took quite a bit of trial and error on my part, when EMC
setup our environment, they turned the Autometa feature on, so when a
DEV is created larger then 240gb, it automatically rounded up and
created 100gb slices and forms striped METAs. In my understanding,
striped meta volumes are not really benificial in a thin pooled
environment, that EMC best practices call for concatenated METAs (as
each concatenated slice is striped across the entire thin pool allready)
Unfortunatly
we were already stuck in this config and hundreds of our META volumes
were setup as striped. It is far easier to expand a concatenated META
(concatenated METAs also dont have hyper size restrictions) I could
find no easy document listing how to expand a striped meta that was a
TDEV and the only other blog online I found mentioned expanding a
standard Device and not a TDEV. So here you go!
UPDATE: I've since learned from EMC that the advantage
of having striped metas in a thin pool environment provides more I/O
"hooks" (as our SE put it) on the front end to the host and can increase
performance for high I/O intensive applications when compared to a
standard TDEV or a concatenated meta.
1. For
a protected (online) expansion, create a BCV+TDEV Meta the same size as
the TDEV Meta you wish to expand, with the same size hypers.
· Use
the "configure" command to create a copy of the original Meta's
configuration (Members and hyper size and bind location which you will
have to unbind from)
· symconfigure -cmd "configure 1 devices copying dev xxxx(orig meta) overriding config=BCV+TDEV;" prep
· Unbind from thin pool then bind fully allocated and with persistent flag on :::::IMPORTANT:::::
· symconfigure -cmd "unbind tdev xxxx(new BCV+TDEV meta head) from pool <thin_pool>;" prep
· symconfigure -cmd "bind tdev xxxx(new BCV+TDEV meta head) to pool <thin_pool> PREALLOCATE SIZE = ALL, allocate_type = persistent;" prep
· This will take some time (10 to 15 min depending on size) as it needs to pre-allocate all the space to the pool. Wait for pre-allocation to complete before continuing
Note:
If you manually create the TDEV meta to be used as a BCV, you can use
this to convert it: symconfigure -cmd "convert dev xxxx to BCV+TDEV;"
prep
2. Create
new Meta members for the original META, the same size as existing
members (in cylinders), with the number to achieve amount needed for
expansion (Leave them unbound)
· symconfigure -cmd "create dev count=4, size=xxxxxx,config=TDEV, emulation=fba;" commit
· Do not bind
3. Then finially run this command to expand the original META, using the BCV Meta created in step 1:
· symconfigure -cmd "add dev xxxx:xxxx to meta xxxx, protect_data=TRUE, bcv_meta_head=xxxx;" prep
It should run for quite some time, as it copies all data to the BCV,
expands the original volume, then copies/re-stripes the data back,
including on to the new Meta members. We have seen it bring our back end
director utilization to over 80% during the entire expansion, so plan
on doing it during a time of low utilization.
After the expansion completes the BCV+TDEV can be cleaned up and deleted
==========================================================================
Convert all the existing concatenated metas to striped metas.
Here are the steps to do a conversion:
1) Create a new meta of the same size and number of members of the meta to be converted: symconfigure –sid <x> -cmd “create dev count=1 size=<x> gb, emulation=FBA, config=TDEV;” commit
2) Bind the new meta to a pool: symconfigure –sid <x> -cmd “bind tdev <x> to pool <pool name>;” commit
3) Change the new meta to be a BCV: symconfigure –sid <x> -cmd “convert dev <x> to bcv+tdev;” commit
4) Preallocate the new BCV: symconfigure -sid <x> -cmd "start allocate on tdev <x>, start_cyl=0 end_cyl=last_cyl allocate_type=persistent;" commit
5) Run the conversion: symconfigure -sid <x> -cmd "convert meta <x>, config=striped, protect_data=TRUE, bcv_meta_head=<BCV device>;" commit
The last step will take some time; it took about 30 minutes to convert a 200GB two-member meta when I was testing.
