Peer Motion with ESX RDM LUNs

[BryanW]

I need to migrate an VMWare ESX 5.5 farm from an F-Class to a 7400, but there is a 5-node Windows 2008 Cluster sitting on ESX using RDM (pass-through) LUNs. Has anyone on the board done this type of migration with peer-motion?
I know online Windows cluster migration required 3.1.3, not sure about ESX RDM clusters, I would assume the same applies? I am about to set up a test environment before doing prod but don't have another system up to 3.1.3 yet. Hope to within a week or so.

[hdtvguy]

We were faced with a similar issue and looked at peer-motion, but it requires a server (can be a VM) to manager/orchestrate) the activity and then there were other limitations that basically made me give up. We set up RCIP replication between the 2 arrays and replicated the volumes then took short down times to disconnect the old RDMs and connect the new RDMs. We only had a handful of RDMs to deal with as we recently migrated away from most of our RDMS and went to VMDKs becasue of our DR with SRM.

[Richard Siemers]

What is the OS + Cluster (Windows 2008) friendly method for migrating LUNs to new storage?

Would Veritas Storage Foundations help solve this problem? I would like to see the contract Microsoft signed with Veritas in its early days that to this day still cripples Windows server's volume manager from delivering comparable value to its Unix/Linux peers.

In theory for this problem (Disclaimer, I last reviewed this when W2003 was in its prime) - you could install storage foundations on all the nodes, convert the RDMs to dynamic disks.... from the new storage, issue a new set of RDM LUNs... use storage foundations to add new luns as a mirror to old RDMs... sync up... break old LUNs out of mirror... de-configure old RDMs and remove. Last I investigated VSF, you were then committed to using it for the life of the cluster because once you go dynamic disk, there is no going back... and VSF is what unlocks cluster's ability to use dynamic disk.

[BryanW]

Since 3PAR theoretically now offers online windows cluster LUN migration via peer motion in 3.1.3 I wonder if they are using the nodes port persistence ability to "spoof" WWPNs for the cutover, similar to Hitachi/XP auto LUN.

If so I would think that would work the same for RDMs as normal Windows cluster VVs as it should be transparent to the OS(s). I guess I will know in a week or two when I can start testing .

[hdtvguy]

My concern with peer motion in general is that it spoofs WWNs. When you move a volume from one array to another the volume will have a new WWN in the new array, but spoof the old WWN to attached hosts. Seeing as my AIX guys use the WWN to derive the serial number of a volume I see the potential for issues in how we inventory our volumes. For ESXi we just did RCIP and then took a brief downtime to reconnect the RDMs, for datastores, storage migration while they were up.

[Richard Siemers]

Seeing as my AIX guys use the WWN to derive the serial number of a volume I see the potential for issues in how we inventory our volumes.

What do you mean when you say "inventory" your volumes? From a host unique ID point of view, since its the same LUN just moving to a new host, you would need/want the WWN to stay identical... or else it would break. What potential issues with inventory are you concerned with?

We're also an AIX shop, which is why I am interested, and want to make sure we're not talking about having to enable dyntrk on all your AIX hosts, so that N_PORT id changes are dynamic and do not require admins to rmdev the old path and discover/add the new one.

[hdtvguy]

Seeing as my AIX guys use the WWN to derive the serial number of a volume I see the potential for issues in how we inventory our volumes.

What do you mean when you say "inventory" your volumes? From a host unique ID point of view, since its the same LUN just moving to a new host, you would need/want the WWN to stay identical... or else it would break. What potential issues with inventory are you concerned with?

We're also an AIX shop, which is why I am interested, and want to make sure we're not talking about having to enable dyntrk on all your AIX hosts, so that N_PORT id changes are dynamic and do not require admins to rmdev the old path and discover/add the new one.

I am not sure how the showvv command will display volume WWNs since the volumes would have 2 WWNs, one for the real WWN on the new array and then the spoofed WWN. I suspect that would cause a lot of confusion as my AIX guys live and die by the WWN and my guys don't.

[Richard Siemers]

I am not certain that the WWN is actually "spoofed" at all, I believe it is copied and identical at the target system. I skimmed through a couple documents online and this is the best blurb I can find related to the topic, perhaps you have something better:

"During this whole process, including the copy step, the applications on the host have uninterrupted access to their data. This is possible thanks to the fact that the WWNs of the VLUNs on the destination array are identical to the ones on the source array. This way, the multipathing software on the host thinks it is still talking to the VLUN located on the legacy array before, during, and after the migration."


The only spoofing I know of, off the top of my head, is port persistance with NPIV.