Migrate data from VA7410 to EVA4440 with minimum downtime

[MohamedTaher]

Hi,

We have a two nodes MC Service Guard Cluster, running HP-UX 11.11, connected through two SAN switches to two VA7410

Because of performance issues, we decided to migrate the data on the VAs to two new EVA4400, but we want to do this with the minimum downtime because we are not allowed to stop the production more than 1 hour.

The most important VG, called vgproddb, containes lvols using PVG-strict allocation policy. The structure of /etc/lvmpvg is as follows:

VG vgproddb
PVG vgproddb_a
/dev/dsk/c8t1d0
/dev/dsk/c10t1d1
/dev/dsk/c8t1d2
/dev/dsk/c10t1d3
.
.
PVG vgproddb_b
/dev/dsk/c7t1d0
/dev/dsk/c11t1d1
/dev/dsk/c7t1d2
/dev/dsk/c11t1d3
.
.

PVG vgproddb_a devices are in VA7410_a and vgproddb_b ones are in VA7410_b; so that the data in VA7410_a is mirrored in VA7410_b

MAX PV in vgproddb is 64 and already 53 PVs are used. Because of MAX PV restriction, my idea to migrate the data is as followes (but i need please your help to validate it and to check if it's possible to do it without any data corruption risk, ad to check where we need a downtime):

1) Link the two new EVA's to the SAN and present to the 2 nodes the same number of vDisks as in the VA's with the same size

2)
#lvreduce -m0 /dev/vgproddb/lvol$i /dev/dsk/c7tXdY

#lvreduce -m0 /dev/vgproddb/lvol$i /dev/dsk/c11tXdY

(do we need to umount the FS here? Is there any risk?)

3)

#vgreduce vgproddb /dev/dsk/c7tXdY
#vgreduce vgproddb /dv/dsk/c11tXdY

4) Add devices with their alternate path from the second EVA (EVA_b) to vgproddb:

#vgextend vgproddb /dev/dsk/cNtXdY /dev/dsk/cMtXdY

5) In /etc/lvmpvg, modify PVG vgproddb_b by adding /dev/dsk/cNtXdY /dev/dsk/cMtXdY and removing /dev/dsk/c7tXdY and /dev/dsk/c11tXdY

(is it all that we need for mirroring or do we need to launch also lvextend -m 1?)

6) Import the new LVM structure of vgproddb in the second node cluster using vgexport -p/vgimport

7) In the cluster config file: modify the PV lock devices (use the new EVA_b ones instead of VA7410_b ones)

8) Unlink VA7410_b from the SAN

9) Monitoring period of 3 days; then goto step 2 to replace VA7410_a devices by EVA_a ones

Is this migration plan realistic. Please i need your remarks and ideas

[Ivan Krastev]

Some remarks:
2.
>do we need to umount the FS here? Is there any risk?)

You are removing mirror copy and no umount is necessary.

5. >(is it all that we need for mirroring or do we need to launch also lvextend -m 1?)

You need lvextend:
lvextend -m 1 /dev/group/logvolXX pvg_group_name

7. New disks for cluster lock - this is the only downtime for cluster.

regards,
ivan

[MohamedTaher]

Thank you Ivan for your answer, it's really good news that we need downtime only for cluster PV lock change

Do we need it also for vgimport in the second cluster node? Shoud i vgremove vgproddb in this second node before vgimport?

[Ivan Krastev · Accepted solution]

Yes, you will need vgexport/vgimport onthe second node.

Remember /dev/vg*/group settings, because this file will be removed after vgexport.
Create vg dir and group file, update /etc/lvmpvg and import new settings.

During this operations you can disable package switching on that node.

regards,
ivan

[Steven E. Protter]

Shalom,

Before you start due to the possibility of data loss, do a good, cold backup.

I would set up the disks on the EVA and present them to the system.

I would set them up as new disks.

pvcreate
lvcreate
lvextend
newfs

As needed.

Then I'd use a tool like mirror/ux to copy the data hot.

Confirm the mirror copy is working.

Then break the mirror leaving the EVA as the only functioning logical volume.

That is the now downtime way.

I'd actually prefer a downtime process that involved bringing down all systems and copying the system to the EVA from a fbackup or other backup media.

SEP

[MohamedTaher]

Thank you guys