ServiceGuard migrating to a new Storage need HELP

[loy4lplay]

Hello,

I need to migrate my ServiceGuard to a new storage and I plan on mirroring the LUNs from the storage side, this is pretty much what I'm planning to do, help will be appreciated, am I missing something?

OS HP-UX 11.11

1) Bring down the ServiceGuard cluster services

cmhaltcl

edit /etc/rc.config.d/cmcluster 1 to 0

2) Backup VGs 

vgcfgbackup –f /etc/lvmconf/vg_name.conf.orig vgname

- Create mapfile of every VG to be exported and imported

vgexport –s –p –m /etc/lvmconf/vg_name.mapfile /dev/vg_name

3- Start LUN mirroring from the storage

4) Deactivate the VGs used by SG

vgchange –a n /dev/vg_names

4.- Export the VGs

vgexport /dev/vg_name

8.- Present the mirrored LUNs to the SG and run ioscan to recognize them

9.- Import the VGs using the mapfiles with the new mirrored luns 

mkdir /dev/vg_name

mknod /dev/vg_name/group c 64 0xXX0000

vgimport –v –s –m /etc/lvmconf/vg_name /dev/vg_name

 Execute strings /etc/lvmtab > lvmtab.new 

1. Activate the VGs

vgchange –a y /dev/vg_name

Start SG services 

also, when I import the VGs using the mapfiles, wouldnt that import them using the old storage disks or should i unpresent them first?

Thanks!!!

P.S. This thread has been moevd from General to HP-UX > LVM and VxVM. - Hp Forum Moderator

[Bill Hassell]

vgimport has two modes: explicit device (LUN) list on the command line and auto-import by matching the PV serial numbers. So yes, leaving the old LUNs visible will find duplicate LUNs that are not alternate paths.

So unpresent them before vgimport.
The alternative is to figure out which new LUNs belong to each VG and put all of them on the vgimport command line.

Also, the ioscan step needs insf to follow.

[loy4lplay]

Could you explain this Bill? So yes, leaving the old LUNs visible will find duplicate LUNs that are not alternate paths.

[Bill Hassell]

OK, an alternate path is a device file that points to the same exact LUN but uses a different I/O path.

Assuming your array duplication software works correctly, the new array will have exact copies of the original LUNs.

Each volume group is uniquely identified by a VGID number that is stored in the LVM records at the front of each PV (physical volume or disk LUN). There is also a unique PVID added to each disk. For the original array, you can vgexport a VG (with the -s option), then vgimport without specifying the PV device files.  vgimport (with -m option) will scan every visible disk on the system and import all the disks with the same VGID listed in the mapfile.

But you have duplicated all the LUNs and presented those new LUNs. There are now two LUNs with the same PVID and VGID, so assuming a simple 1 disk VG, you now have two identical disks for LVM to use. But the LVM record also knows how many disks belong to the VG (1 in this example), yet two of them have been found. So you'll get a mismatch error from vgimport.

If you want to keep the old disks presented, then you'll have to list the PVs from the new array for each vgimport. That may be a pain if there are many PVs in some VGs.

Recommendation: Turn off the old disk PVs and then do your vgimport. It's much simpler.