snapclone or mirrorclone

[ben horan]

We have expanded our EVA8000 to a new cab so it is very busy in terms of IO not to mention that a number vdisks are being CA'd. The new expansion cab has its own disk group and so we need to move a few vdisks across to that new disk group to create space in our existing disk group.

Our options are snapclone or mirrorclone and i would like to know which one is less likely to affect performance. Only one vdisk will be done at a time, outside of normal hours. Some are up to (and over) 2GB in size but none are CA'd.

For the snapclone method we would mark vdisk as write-through, shutdown server, create snapclone to container in new group, unpresent orginal vdisk and then present snapclone to the server before restarting server. Then we can leave snapclone to complete overnight or weekend.

With a mirrorclone we have to create a mirrorclone to new disk group, wait for the mirrorclone to complete, shutdown server, detach & fracture mirrorclone, unpresent original vdisk and present mirrorclone before starting up server.

Is there a preferred method? - is either option better in terms of performance or time to complete??

[IBaltay]

Hi,
maybe the less performance demanding method is simply ungrouping the HDD from the original and grouping them into the new DG

[IBaltay]

the above suggestion is valid according to the EVA Performance best practices if both DGs are from the identical HDDs. So if there is a possibility not touching the vdisks but only resize the DG sizes it can be done without the snapclones/mirrorclones

[IBaltay]

If the above cannot be used, then only the mirrorclone is usable because it is the continuous local copy...

[ben horan]

Because our existing DG is over 70+ HDDs and the new EVA8000 expansion cabinet has over 40 HDDs we made a decision not to group these 40 disks into the existing DG as the levelling operation would be very large and encroach into the working day. Instead we are going to move individual vdisks into the new disk group to create space in the existing disk group.

[IBaltay]

I am sending you the EVA config best practices, because
a) the more spindles the more perf in the DG
b) 70 is not enough to be affraid of any perf degradation yet...

http://h71028.www7.hp.com/ERC/downloads/4AA0-2787ENW.pdf?jumpid=reg_R1002_USEN

[Steven Clementi]

"the levelling operation would be very large and encroach into the working day."

I would not worry about a leveling process decreasing the performance of the disk group by so much that it effects your users in a bad way.

Generally speaking, Leveling is a background process on the controllers that people ("users") don't even notice.

Have you had a bad experience with a leveling process before?


Steven

[ben horan]

Our EVA is fully populated with 300GB FC disks. Once DG of 95 disks and one DG of 73 disks. We have only 1TB free in each DG so they are very full. The new expansion cab has 40 disks. We feel that if we add the disks to the existing DG's levelling will take a very long time and even though it is a "background task" there may be performance degredation.

[IBaltay]

but the EVA configuration best practices does not confirm/prove your concern and you may get the performance degradation within the new DG (only 40 disks) in comparison with the first (95) or second (73) existing DGs

[Phillip Thayer]

Ben,

The EVA is designed to work best with larger disk groups that are equally divisible by 8. So, by breaking up your 168 (21 RSS's of 8 drives each) into 2 disk groups of 73 and 95 you are actually forcing your EVA to run slower. The disk group with 73 will create 8 RSS's of 8 drives and 1 RSS's of 9 disks. The disk group with 95 will create 11 RSS's of 8 drives and 1 RSs with 7 drives. These partial RSS's consisting of 7 and 9 drives will cause a performance issue.

Best thing for you to do is:

1. 33 of your new drives to the disk group with 95 disk in it.
2. remove one drive from your disk group with 73 in it and add it along with the remaining 7 new disk drives to the disk group with 128 disks in it.
3. User the Snapclone functionality to migrate VDisks to the larger disk group.
4. Remove 8 drives at a time from the smaller disk group and add them into the larger disk group in groups of 8 until you have only on disk group of 208 disk drives.

Once this is done, you are now spreading your I/O over 208 spindles instead of only 73, 95 or 40 disk drives. More spindles means more I/O throughput.

Phil