Migration of EVA vraid using shadow

[sartur]

We have a 2 Alpha OpenVMS Cluster nodes with shared disks in a EVA8000. The EVA8000 is shared with other servers (Linux, Solaris and Windows). We want to migrate OpenVMS Cluster vraids in the EVA8000 to another EVA6400 dedicated to that environment for better performance. We will convert the current vraids in the EVA8400 to shadows's sets of single-member and then bring you the second member of the Shadow in the EVA6400. After completion of the shadow synchronization proceed to remove the member in the EVA8000.
What would be the considerations taken into account to perform this procedure?
Is this the best procedure?
There is some risk to migrate in this way?

[Oswald Knoppers_1]

You can have (at least) three members in a shadow set. So I would not reduce the shadow set to one member before adding the EVA6400 member.

Apart from that, yes this is the way to migrate to new storage without any downtime.

Oswald

[Jan van den Ende]

Sartur,

I fully agree with Oswald.
I did it myself that way several times.
Works like a charm.
During the shadow copy operation (takes HOURS!) the performance to that unit is poor, so best perform it in "quiet" hours.
And do only one unit at a time, both for performance reasons and to avoid any unnecessary bottlenecks.

Success!

Proost.

Have one on me.

jpe

[The Brit]

You didn't mention the VMS version, however, you might want to think about whether there is going to be a need to increase the size of you volumes any time soon. If the answer is yes, then make the EVA6400 units the (larger) size that you want and then add them to the shadowsets. Dissimilar Device shadowing has been available since I think 7.3-2. You might have to schedule a downtime at some time in the future if you dont have Dynamic Volume Expansion enabled on your volumes.

In any case, be sure that the EVA6400 units are equal to, or greater than the size of the 8400 units. If they are smaller, even by a single block, they will not shadow.

Dave.

[sartur]

The OpenVMS version is 8.3
A month later we would be migrating the Alphas server to Integrity with OpenVMS 8.3-1H1

[Robert Gezelter]

sartur,

I certainly agree with the comment about using Dynamic Volume Expansion and volume shadowing.

You may want to take a look at "Migrating OpenVMS Storage Environments without Interruption or Disruption" (slides at http://www.rlgsc.com/hptechnologyforum/2007/1512.html ) from the 2007 HP Enterprise Technology Symposium.

Done with the proper care, this approach allows the migration to be performed without any interruption of production operations.

- Bob Gezelter, http://www.rlgsc.com

[Jon Pinkley]

Sartur,

If I were you, I would get things working and stabalized with single member shadowsets before worrying about migrating the data from the EVA8000 to the EVA6400. That part will be relatively straight forward once all the device named have been changed from $1$DGA to DSA devices.

The system disk, quorum disk and dump device require some additional consideration/work if you will be shadowing the system disk.

Here are some of the things that you must prepare for when changing physical device names, and may not be obvious if you haven't done this before.

a. The queue manager database uses physical device names. Any entries must be requeued after the device names change.
b. Make sure there are no references to the physical device names except in the mount commands used in the system startup.

For the problem discussed in (a.) you may want to read the thread "Migrating queue entries from one device to another"

http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1149896

In addition to the physical device names changing due to conversion to DSA devices, shadowing also affects the following as well:

c. If you have a quorum disk, it can't be on a Host Based Shadowset volume (even if there is only a single member)
d. If you decide to shadow your system disk, there are other considerations, wwidmgr, dosd, etc.

Since you are planning to migrate to Integrity, now would be a good time to start planning for multiple system disks, and how you will share the cluster common files. I am assuming you will be adding the Integrity server(s) to the cluster prior to removing the Alphas, so there will be a period of time that you will have a mixed cluster.

You are going to have to dismount the disk to be able to convert them to single member shadowsets. If the current disks were not initialized with /limit when they were created, once you have the disk dismounted, mount them private and use the set volume/limit command to set them up for future expansion. This isn't quite as good as having initialized the disk with /limit (the maximum files allowed won't be changed to the 16 million ODS2/5 limit), but it will allow the volume to be expanded to 1TB (or less depending on the clustersize on the disk).

You are using shadowing as a mechanism to allow the disks to be migrated "online", not as a data protection solution. Creating single member shadowsets shouldn't significantly affect the reliablility of what you have been using. Therefore, I think adding a third member is overkill, and I wouldn't do it myself as long as something other than vraid0 is being used on the EVAs.

Since performance is evidently an issue, I would avoid using vraid5, and use vraid1 on the EVA6400, at least for devices where performance is critical. How many disk groups and disks/disk group do you have on the 6400?

Be aware that you will manually have to co-ordinate your OS system IDs so you don't duplicate them on the EVA8000 and the EVA6400. Most sites use a numbering convention that keeps the OS unit IDs different on different disk arrays.

Jon

[Jon Pinkley]

Sartur,

This note is to clarify some things that have been stated in this thread.

1. To be able to expand a volume, dynamic volume expansion must be enabled; either the disk (volume) must have been initialized with /limit[=n] or the set volume /limit[=n] command must have been used while the volume was mounted private. This "pre-allocates" a storage bitmap large enough for the specified size, so the volume can be increased in size at a later time with the $ set volume/size[=n] command.

2. With the EVA, you can expand the size of a vdisk while it is being used by VMS. So there is no need to create vdisk larger than needed to "pre-allocate" space to the vdisk. The only reason to do this is to "reserve" the space so something else on the EVA can't allocate the space you want for your vdisk. However, unless the volume has dynamic volume expansion enabled, the $ set volume/size command will not do anything. The technique that Bob references in his post dated Aug 8, 2010 00:23:22 GMT in this thread, uses HBVS to allow expanding virtual devices using fixed sized members. That technique will always work, but it is not a requirement when the controller has the capability of expanding the device.

Jon

[Verne Britton]

Others have mentioned it but not with much emphasis ... some of the possible modifications require the disk TO BE MOUNTED PRIVATELY ...

that means your keyboard/process will be the only one using it ... NO OTHER ALPHASERVER OR OTHER USER can be using the disk while you are doing things like SET VOLUME ...

Once your SET commands are finished (last time I did one it took only a minute or two), you can remount the disk with /SYSTEM or /CLUSTER and put it back into production.

FYI, took me awhile to schedule a time and make a plan to do this on my cluster to the special dedicated disk (not the system disk) holding our SYSUAF and RIGHTSLIST files :-)

Verne

[Robert Gezelter]

sartur,

With all due respect, I will note that while Jon is correct that my presentation illustrated using fixed size volumes, that particular case is only one of the many cases where this technique can be employed.

Using EVAs with extendable volumes is certainly viable. The technique can also be used when switching RAID parameters, or when switching EVAs. While it can use the features of the EVA, the approach is inherently EVA agnostic.

- Bob Gezelter, http://www.rlgsc.com