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

[Steven Clementi · Accepted solution]

You guys are missing the fact that Ben's main concern is that when grouping the new disks, his users might notice some performance degradation while the DG levels.

Personally, I don't think the users will see any difference in performance. Sure, there will be some difference... but I think it is negligable compared to the performance cut they might notice after you move Virtual disks to a DG with 40 disks vs. 73 or 95 disks.

Even then they would have to be a high performance user with a pretty high i/o profile on the EVA to notice any really big change.


The short story is, I think you would be fine grouping the 40 disks in with one of your other groups, or both (splitting them to give both groups space (and yes.. trying to keep with the multiple of 8 best practice)). Even if you started 6pm Friday and the leveling was well along it's way by monday morning, I think the price you'd pay is less then if you had a 3rd DG.

Facts...

Protection levels is PER Disk Group. You will lose additional raw space by creating a 3rd DG.

"partial RSS's consisting of 7 and 9 drives will cause a performance issue." - I never actually seen any performance issues when there is a RSS of less/more than 8. It simply means that redundancy is not optimal in 1 set of disks.

"Best thing for you to do is:" - might not be to combine all of your disks into 1 Disk Group. Lot's of reasoning goes into the decesion to have a single or multiple disk groups... and we do not know how your EVA came to have 2 Disk Groups.

Different applications require different i/o performance, internal politics sometimes plays a role in the decision to have one or multiple DG's, etc.

It is very easy to state the Best Practice(s).


Steven

[ben horan]

Thanks guys - especially Steven. After your comments I think we will go for integrating the expansion cabinets 40 disks into the existing disk groups. We will also aim to make the disk numbers divisible by 8 in the DGs. We need to stay with the 2 DG's as one is a very sensitive email application and mangement like it to be in its own DG.

Is there any best practise as to how many disks we can add at one time? i.e. is 32 in one go okay?

[IBaltay]

>Is there any best practise as to how many >disks we can add at one time? i.e. is 32 in >one go okay?


HDD installation

HP recommends to install (not group) a maximum of 4 HDD at one time. The procedure is the following:
1. insert not more then 4 physical disks
2. wait until the activity indicator on each inserted drive becomes solid green and remains solid for 10 seconds
3. you can proceed with 4 other disks until 32

HDD grouping to the DGs
the best is to check the original RSS layout
if you have any RSS with 6 members i would first saturate those hungry ones and then add the disks in the groups of 8 to have full vertical layout, which should be fairly easy with 18 enclosures

[Uwe Zessin]

> HP recommends to install (not group) a maximum of 4 HDD at one time.

I strongly recommend to install one disk drive at a time and wait until it has been properly recognized in Command View EVA. Yes, this takes a lot of time, but I still see EVAs with duplicate disk drive names which is caused by CV-EVA.

[ben horan]

We will add disks to the expansion cabinet one at a time to be safe.

We do actually have 2 disks with the same name in another disk group, is this okay? Is there any fix required?

[IBaltay]

Each disk has its own unique wwn so the logical name should not be a problem

[Uwe Zessin]

It is a problem, because one of the disks with a publicate name is not completely processed by CV-EVA. For example
- it is not included in the disk counts
- last time I was searching for it, the icon did not appear in the disk group hierarchy

I find it very confusing if an incorrect number of disk drives shown ;-)

[Uwe Zessin]

> Is there any fix required?

Sorry, Ben, missed the question.
In that case I simply give the visible disk a different name within CV-EVA. After a refresh / new discovery, the view should be correcct.