The goal is simple..copy data from one set of LUNs to another. Data on source LUNs must remain online to minimize downtime.

All source data must sync to destination LUN to maintain consistency between the pairing, while source is online and available. Furthermore, the tool used must be byte for byte as opposed to block based, stripe alignment (64K or 128K) needs to stick on destination LUN. So SAN Copy is not an option

And most critical of all, the disk signatures for each clustered disk resource must be transferred from source to destination LUN.

Enter Open Migrator..a host based tool from EMC, cluster aware, that does just that. Migrates source to destination, byte for byte, allowing one to stripe align the destination LUN prior to migration. Copy occurs online while source is servicing what it services.

Two reboots, one to install OM and attach OM to each source and destination LUN, a filter level driver captures writes to the source and writes to both the source and destination. And one reboot to perform the swap once the data migration completes.

Now OM has been around for years, so its nothing new to some. But to me it is, my world has been filled with SAN Copy and EMCopy.

BTW, I hate MS clusters (my demons). They have their place I suppose, but I am hoping VMware’s Fault Tolerance eradicates their footprint from this luscious planet……Umm anyway…

Where were we, oh yes..sounds peachy huh? And honestly I was impressed after my first cluster migration, but it seems my trusting nature was a bit premature as the second cluster turned out to be a train wreck.

Here is a quick rundown of the headaches that occurred…

• LUNs were In Sync and Verified prior to the final reboot. Passive node was shutdown.
• Reboot occurred on active node. LUNs came up, destination LUNs (now source), came up mounted with the correct drive letterings and signatures
• The old LUNs come up unmounted signatures swapped. Ok cool, so what happened?
• Well the destination LUNs were in a state of RAWness, inaccessible, no filesystem present. WTH?
• Now the old signatures were tied to these new LUNs of which there was no data. So as you would guess the cluster service was fornicated.
• Ok sir, what did you do to rollback? Why rollback? I had no data, I HAD NO DATA ON THE NEW SOURCE LUNS. I felt like I had been railed in the face by a freight train, not good. So rollback was our only option.
• Now to rollback I had to  swap the signatures back to the original LUNs for the cluster service to start. Delightful, funny enough that was the only part of the migration that worked seamlessly.
• And here we go….
  • We first needed the old signatures documented and paired with the appropriate disk id. We accomplished this through searching the system event log on the active or passive node. I believe the event ID we filtered for was 1304.
  • Once determined, we used  a utility called dumpcfg from the Windows 2000 Resource Kit, to change the signatures. Here is the command…
    • dumpcfg –s <replace with signature> <replace with disk id>
  • BTW here is the path to your current siggy’s------HKLM/System/CurrentControlSet/Services/Clusdisk/Parameters/Signatures
  • Of course, prior to this we disabled the cluster disk within Device Manager/Show Hidden Devices/Non-Plug and Play Devices, and rebooted.
  • Once this command was run we rebooted and enabled the cluster disk and cluster service and rebooted one last time.
  • Once compete the cluster service started with out a hitch, passive node was brought online, failover and failback was rocking.

I will kiss and make up with Open Migrator over time, no worries, it just wont be my tool of choice for clusters…MSCS-1 Me-0.