standards for ungrouping EVA disks

[ben horan]

I have 10+ disks to ungroup in an active disk group which has over 100 disks. What is the standard for ungrouping e.g. is it safer to ungroup only 1 or 2 disks at one time or is it fine to ungroup in batches of 8??

[Vincent Fleming]

Your safest bet would be to ungroup no more than one at a time and wait for the leveling to complete before attempting the next.

Of course, it's always a best practice to backup the entire array before attempting any such activity.

Good luck,
Vince

[Rob Leadbeater]

Hi,

I could be wrong, as I'm not in front of an EVA at the moment, but I didn't think there was an option to ungroup more than one disk at a time...

Cheers,

Rob

[ben horan]

Thanks guys. What risk is there in ungrouping a disk each night and then leaving the levelling operation to complete over the weekend?
As it stands it takes over 2 days for levelling to complete on this disk group and this will mean over a couple of months to remove the 20+ disks I have to remove (we are replacing 146GBs with 300GBs).

[Uwe Zessin]

Ungrouping means additional I/O load on the disks, but do you have a choice?

You could backup all data, remove the virtual disks, the disk group, replace the disk drives, recreate everything and reload the data - but can you really afford this downtime?

[ben horan]

We don't unfotunately. We have 6 slots free on the EVA and a number of new servers with large disk space requirements in the pipeline! Hence the need to ungroup 146GB and replace with 300GB asap.

[Uwe Zessin · Accepted solution]

That's what I thought.
I think you are safe to start a new Ungroup after the previous one has finished and while the disk group is still leveling. I've seen leveling restarting from 0% after a number of events.

I agree with the previous speakers that it is not a good idea to trigger multiple ungroup operations at once. The EVA will do it one by one anyway, but I did see problems in older firmware versions. As this is a rather rare operation I wonder how well this has been tested by the engineers.

[Rob Leadbeater]

Agree... You don't have to wait for the levelling operation to complete before ungrouping another disk. I seem to remember doing this before, and the the levelling percent did go back to 0%.

Just bear in mind the amount of I/O that will be generated, and what impact that might have on the connected hosts.

Cheers,

Rob

[MWard]

If you have a second SAN you could DR replicate the vdisk's on the disk group to the other SAN, verify replication, break DR replication, delete the original disk group, pull all the drives, create a new disk group, replicate the vdisk's back to the original SAN.

Without a second SAN you will need to do it one disk at a time.

[IBaltay]

Hi,
First of all it is good to look at the RSSes.
(by default it is 8 disks). Therefore it is recommended to ungroup the the disks in the multiple of 8 to remove the whole RSS and not start a split/merge RSS operation.

Second, the ungroup is separated from the leveling operation. Ungroup is relatively quick but leveling is very time demanding because it means all the DG vdisks redistribution. So you must ungroup it one by one, wait until it is ungrouped and than you can ungroup second, third, etc. till the 8th disk. You need not wait for the leveling.
It will be done at the end of the ungroup.
Thus the ungroup can be relatively quick.

[koenigj3]

Is it best to identify eight disks that are a RSS set and remove the whole set of disks? If you move part of one and part of another, would the EVA readjust?

[IBaltay]

Hi,
from one RSS you can ungroup only 1 disk at a time and when you go beneath the 6 RSS members, which is the minimum, the RSS algorithm is doing the split/merge operation and it is completely up to it how it distributes the 5 disks from the original RSS. It can create 1 RSS with 11 members and one with 10 members, or 2 RSSs with 10 members and one with 9 members, etc... Therefore it is better to look at the disk enclosures for the current RSS disk distribution and then decide which disks will be ungrouped with the accent on the RSS vertical design and the default concept of 8 physical disks in all RSSs.

[Tom O'Toole]

In the newer versions of CV/EVA, it doesn't show you anything about the RSS membership, as far as I know. I have been playing with CV/EVA 8.0 and the info is not there (haven't used it extensively,so maybe it's there if you really dig)...

A few years ago, with an EVA that had not been put into production, my boss and I ungrouped about 20 disks at once... The io to this array, and CV/EVA access became EXTREMELY slow for two days, and kind of ground to a halt, so we just rebooted it (I think). This was with VCS3010 I believe...

I think it's OK to ungroup one disk per disk group.

[Uwe Zessin]

RSS information is still available in the "ls disk full XML" output of SSSU V8.0.0:

7
1

[Tom O'Toole]

Thanks Uwe,

That's great - I have a script that generates a graphical RSS report... We have learned not to go through contortions moving disks around to reoptimize RSS state however...

[Gilles Salvin]

Hello Ben

I've exactly the same thing to do
(replace 8 X 136Gb by 8 X 300Gb on a eva3000)

I've alreday ungroup 1 disk and the leveling
will take 48 hours !!!
Please let me know how you have proceed if already done.
have you ungrouped the 8 disks 1 by 1 without waiting the end of leveling ?

Was the EVA very slow during that ?

Thanks