VMAX Disk Group modification

You can drain/rebalance/delete/create DATA devices for your Thin Pools via symcli/Unisphere but any change in disk group membership requires a bin change. Think of the bin as the hardware configuration database for the array: any physical changes require bin change while logical changes (with a few exceptions) can be done via symcli.

On the symm RAID applies to the volume not the disks or the Disk Group. You can have volumes of multiple RAID types on the same physical disks in the same disk group.

Is your intent to drain the DATA devices off of a specific number of disks and then move those disks to a another disk group?

If so then the drain and deletion of the DATA devices can be performed via symcli but moving the empty disks from one disk group to another requires a bin change.

There should be absolutely no difference in performance because of which disk groups the drives are in if they are not physically moving because of this configuration change.

I'm also not a fan of mixing raid types on the same spindles.

I'm also not a fan of RAID5 in the middle tier of a FAST VP configuration, as it is usually more expensive per IOP there, and with FAST VP, that tier is an IOP tier, not a capacity tier.

AFAIK, you don't need to change the disk group to create data devices with a different protection.

HOWEVER, data devices (TDATs) need to be placed carefully so every disk has the same number of TDATs on it.  This could require a little homework to get it right before issuing the symconfigure commands.

Here are some thoughts, your plan above will work (will need to use symmmigrate on step 1 to move the extents as well) but you may want to look at this from another perspective.

How many disks and what RAID type are going to be in the "other" thin pool that you will rebind the thin devices to? If that is a RAID 5 pool then why not rebuild the DATA devices on the 32 disks from the disk group that you are draining and put them in that pool?

Using the 16 disks leftover for a thin pool is a pretty small number of disks for a thin pool. Unless you have specific vendor requirements for disk isolation you may have better results with one large thin pool and a good number of disks supporting the shared workload.

AranH,

    Only couple of tdevs are bound to a thin pool, below is my plan,

1. Rebind those tdevs to other thin pool and make sure no tdevs are bound to the thin pool.

2. Drain and delete all data devices of that disk group and then move specific number (16 out of 32 disks) from that disk group to other.

3. Then re-create the data devices with existing 16 disks with a different Raid configuration i.e Raid-5 (7+1).

Any suggestions?

Thanks

Yes, however I think you could drain all the TDATs from disks in one group, create new TDATs with a new protection on those same disks and add them to the pool along with other disks in a different group.  AFAIK, there is no requirement that all disks in a given pool be in the same disk group.

Thanks AranH and rohang.

Quincy56 - The ultimate pupose is not reconfigure the Raid group, to create some free disks from trivial disk groups and add those disks to an important disk group where it needs some more space. Does it makes sense?

Agreed, if you are going to drain all the disks in the Disk Group for use in the target Thin Pool then there is no need to move the disks. If you are only draining and moving a specific number of disks from the Disk Group to move to another Disk Group then I recommend a bin change as I am not a fan of hosting DATA devices for different Thin Pools and/or RAID types on the same disks. It will work but your performance will vary...

AranH,

  Actually I am going to temporarily rebind the thin devices from FC thin pool formed from DISK GROUP B to another thin pool formed from DISK GROUP C

Currently the FC pool is configured with 2-Way Mir with 32 disks in that DISK GROUP B and once after re-config the DISK GROUP B that pool will be configured with RAID-5 (7+1) with 16 disks in that DISK GROUP B and the thin devices will be brought back to this pool.

The remaining 16 FC disks from DISK GROUP B will be used in another DISK GROUP A, which currently has 16 FC Disks and has thin pool configured with 2-Way Mir

Questions:

1. Here once I have moved all thin devices to other pool, shall I delete all the tdats use to form that FC pool from DISK GROUP B? No need for draining. Right?

2. Once TDATS are deleted, I will use bin file change to move 16 FC disks from DISK GROUP B to DISK GROUP A.

3. Currently DISK GROUP A has already 16 FC disks in it and thin pool exists with 2- WAY Mir config, so what will be the procedure to add these 16 disks? Can it be done on the fly and create TDATS from the newly added 16 disks and how to expand the existing thin pool?

Thanks

Awesome ..Thanks a lot rohang.

Here is one more question

So the Disk Group A currently with 16 disks has already TDATS of size 68708 MB each and hardly 27 MB free space. Each spindle has 8 Hypers. So now once these 16 disks are added to Disk Group A, I believe we need to create TDATS of same size, Am I right? If so how does it matter?

Thanks

That's correct.

All TDATs in the pool should be of the same size as using different size devices could result in uneven data distribution, as extents are allocated in a round-robin manner.

Also, each drive will be divided into a minimum of 8 hypers in order to maintain adequate disk queue depth.

regards.

Since you are adding the same number of disks to the disk group it is easy enough to just use the same size, RAID config, and number of DATA devices already in the disk group for your symmconfigure command.