SAN Disk Migration and Multipathing

[John Eaton]

I am not a Linux expert by any means, but do have 15 yrs on HPUX, so I've got a good idea of what I'm doing.
We will be migrating a bunch of SUSE hosts from 1 EMC Symmetrix array to a new one using SRDF to copy the data at the disk level, and then vgexport/vgimport to make the switch to the new devices once the data copy is completed. The problem is we're not sure how MPIO will affect this plan. I've read what I can find on it, but have yet to find anything like what we are doing to reference.
Has anyone actually done something like this? Clearly any Service Guard people have done the vgexport/vgimport process, but the concern we have is that the new disks will look just like the old ones (which will be online and in use up to the last second). We need to present the new devices (read only by default) in advance so we can verify that they are visible, and to determine the new names for use in the vgimport process. They will have unique identifiers from the EMC array, but the LVM headers will be identical to the existing device they are paired with. From what I understand the MPIO system is designed to recognize the disk ID and automatically match it to the exiting devices with the new path.
Anyone got any ideas on what issues we might run into? Can we put something in multipath.conf to force it to see these as different devices?
Thanks for any assistance. John

[Ivan Ferreira]

>>> They will have unique identifiers from the EMC array, but the LVM headers will be identical to the existing device they are paired with. From what I understand the MPIO system is designed to recognize the disk ID and automatically match it to the exiting devices with the new path.

MPIO will not detect the other storage disks as another path to your current disks, but LVM will complain about duplicate IDs.

To verify your data, you should unpresent the current disks, present the other storage disks, rescan the disks, activate the volume groups and check the data.

Also, are you using multipath.conf or a multipath capable driver?

[skt_skt]

Yout requierment is as identical to a SAN migration on HP-UX system.

make the srdf group, make the target RO.
keep the group in asycn mode and
during the outage window make it ACP(adapative copy), wait till the full sync and split the group and make the target RW.

verify the target data. Make sure you are using the target LUNs and getting troubled with the OLD source LUNs.

[John Eaton]

Ivan,
Thanks for your response.
I'm not quite sure how to answer the last question. The multipath.conf file is being used, but I was under the impression that the driver and HBA also had to be capable of this as well, Qlogic QLA2340.

I know the EMC headers will be unique, and that the LVM headers will not. It looks like we will be able to get a test system tomorrow, so I'll know better how it acts. The key concern is timing. The maint windows are very small, and if we have to remove the old devices, add the new and reboot, then we won't make the desired window, plus then the rollback plan is much longer, too.
The procedure we have been using (HPUX) is: before the down window present the new devices, ioscan, insf, then use inq to 'locate' the new devices. During the down window export the VGs, sync/split the volumes, import the VGs using the new devices, and mount up the FSs. Worked very well on HPUX, but this multipath thing has us a bit shy, never having seen it before. Minimal risk is more important than timing of course.
John

[John Eaton]

Santhosh,
Thanks, but that's not the issue we have concern with. We have years of experience with EMC and SRDF. It's how SLES9 MPIO will interact with the new devices that we are unsure of.
John

[John Eaton]

It looks like we've figured out what we need to know by testing.
We can find the 'ID' that linux uses to identify the disk from the symmetrix 'wwn' id (not to be confused with the SAN WWN), and pre-build the multipath.conf entries to assign the aliases that are then used with LVM. We were able to create a new VG, export it, and import it on another system. While I did find instructions for the individual commands, there apparently is no 'how to' of this nature to be found. Lots of others looking in other forums, but no answers it seems. The trick is to use pvscan before the vgimport.
I'll post a final response once we've actually migrated a live VG.
Thanks, John