migrate from securepath to PVlinks?

[TMcB]

Hi everyone -
looking for some advice on migrating MCSG volumes.
We are currently connected to EVAs and use secuepath - all very easy / straight forward so far!

We will be moving to IBM DS4800s, and after reading up on their web site - it looks like we'll have to migrate to using PVLinks for multi pathing.

I'm really just looking for some advice, as we've never used PVLinks before - is there anything I should be aware of regarding doing this sort of migration.

I had planned something along the following lines :

1. run ioscan and insf –e - should now see disks

2. pvcreate structures on new disks
pvcreate -f /dev/rdsk/newdisk1
pvcreate -f /dev/rdsk/newdisk2
3. Add new disk to VG
vgextend /dev/vgsgm /dev/rdsk/newdisk1
vgextend /dev/vgsgm /dev/rdsk/newdisk2
4. Configure mirroring
a. remove original mirror
lvreduce –m0 /dev/vgsgm/lvusr1 /dev/dsk/oldEVAdisk1 (old disk)
b. setup new mirror
lvextend -m 1 /dev/vgsgm/lvusr1 /dev/dsk/newEVAdisk1 (new disk)
mirror sync may take some time
5. Once mirroring complete , remove other EVA disks
lvreduce -m0 /dev/vgsgm/lvusr1 /dev/dsk/oldEVAdisk2 (2nd old disk)
lvextend -m1 /dev/vgsgm/lvusr1 /dev/dsk/newEVAdisk2 (2nd new disk)
6. Remove old disks from VG
vgreduce –f /dev/vgsgm /dev/dsk/oldEVAdisk1 /dev/dsk/oldEVAdisk2
7. update lvmtab on bfssgm02
vgexport –pvs –m /etc/lvmconf/map.vgsgm /dev/vgsgm
ftp map file to bfssgm02
on 2nd node :
vgexport /dev/vgsgm
mkdir /dev/vgsgm
mknod /dev/vgsgm/group c 64 0x010000
vgimport –vs –m /etc/lvmconbf/map.vgsgm /dev/vgsgm

Repeat for each LV


Would I need to unistall securepath before using any of the disks from the DS4800?

Any advice would be greatly apprecated.

[TTr]

Take a look at the

http://www-03.ibm.com/systems/storage/disk/ds4000/pdf/interop-matrix.pdf

It is not very clear that the DS4800 is supported with SG. Note 6 says itanium servers are supported but not clear if it means with SG. Why didn't they put the checkmark in the matrix instead of adding note 6.

I am actually using RX servers with the DS4800 and SG but when I did some testing, the DS4800 changed controller ownership on some of the LUNs when those LUNs were tranferred over to the other node. We are trying to figure out if that was caused by our zoning. The result is somewhat acceptible since the DS4800 is in active/passive setup.

As for your migration approach it looks OK, I wouold suggest you run a test if you have the luxury.

> Would I need to unistall securepath before using any of the disks from the DS4800?

It depends if securepath can coexist with PVlinks. See if you can determine that from the securepath literature. Will securepath "grab" the new DS4800 LUNs once they are visible in the server. If not, then securepath probably coexists happily with PVlinks.

[Tim Nelson]

With an active/passive array I would expect secure path to cause issue as secure path is a path load balancer. PVLinks is not ( only path failover ).

This may be why IBM does not want secure path installed ?

In this day and age I am still suprised that there are active/passive arrays out there. Maybe just my lack of real knowledge but during my purchases if I see active/passive I pass on that vendors technology.

As far as PVLink configuration. Add the primary path to your VG. Then add all alternate paths to the VG. The vg will automatically mark the others as alternate. ( you can add them all at once, the first one in the list will become the primary ).

--- Physical volumes ---
PV Name /dev/dsk/c14t0d3
PV Name /dev/dsk/c12t0d3 Alternate Link
PV Status available
Total PE 25596
Free PE 0
Autoswitch On

[TMcB]

thanks everone for getting back to me.
I was off for a few days holiday so apologies for not replying.

I appreciate your comments and I guess the only thing I can do to confirm this is to test it - luckily we have a test server here.

thanks again

[TTr]

The DS4800 is known as dual active array. It is active/passive but both controllers can do I/O concurrently. You can do a decent I/O load balancing and failover, manually, by assigning about half of your LUNs to controller A and the remaining LUNs to controller B based on your I/O. Each LUN is owned by a controller and that's the prefered ownership. Then the other controller can assume ownership if there is a path failure. On the LVM side you use the prefered controller as the primary path and the other controller as the alternate.