As with any large datacenter projects, server migrations are always a part of them. You meet with stakeholders almost daily to ensure success. Those pesky project managers asking for your pre-migration plans, migrations plans and the all important backout plans.
You are down to your final few servers and realize, that 4 of the 8 are SQL boxes that are in a cluster and you have to minimize downtime as much as possible. You get where I’m going here, “as little down time as possible”.
As I was sitting through my migrations plans, downtime came out to around 4.5 hours – due to the amount of data and a 1Gbps circuit. This scenario had shared nothing, the new datacenter was located on the other side of the building. Then, my friend Zerto came to mind, could I use this to “Move” the Primary node with RDM’s to the new datacenter? I then thought, Zerto does a great job with failovers in emergencies and I’ve used the move operation on stand-alone VM’s to migrate VM’s hundreds of miles away with less than 5 minutes of downtime. Could this work….
*Note: When Zerto completes Failovers or Moves it disconnects the CD-ROM. After successful failovers or moves, ensure you re-add the CD-ROM device.
Let’s go over the steps to make this happen.
- Create the new LUNS needed on the new storage array – ensure they are the same size as is configured on the old array.
- Add Primary Node to a VPG
- On the “Storage” tab, select each drive separately and configure to use the RDM for that drive in the new environment. (If the OS drive is currently a VMDK, keep it that way)
- Allow VM to Sync – Do not sync secondary node at this time
- Take SQL Backup
- Close connections to databases
- Once SQL Backup complete, open “Failover Cluster Manager” and stop SQL Services
- After SQL Services are stopped, stop cluster services
- At this point, I disconnected the NIC’s on the secondary node. You don’t want the primary to communicate with the secondary until it’s on the new infrastructure.
- Log into ZVM, select the primary node and move to new environment – ENSURING REVERSE Replication is NOT enabled.
- Once the VM has been been brought up on the new infrastructure, shut down the server
- Add CD-ROM back to VM
- Ensure secondary SCSI controller is set for “Physical”
- Check the RDM’s and ensure they are all set for “Physical” compatibility mode
- Power up the Primary node, log in and ensure Cluster Services are running and start SQL Services – At this point, you should be able to complete checkout and have users access their DB’s.
- Once everything on the primary checks out, power down the secondary node and remove the old RDM’s from the machine.
- Power back on (with NIC’s still disconnected)
- Create a VPG with the secondary node – ensuring only the OS drive is attached and sync.
- Once Sync’d, you can move the secondary node – it will power up on the new infrastructure with disconnected NIC’s and no RDM’s.
- Power down the secondary node
- Go into Edit settings and take note of the mapping file locations and SCSI device numbers – Close edit screen on primary without making changes
- Edit settings on secondary node, Add hard disks and point to the correct mapping file for the device, ensuring you have selected the right mapping file and SCSI device number
- After adding all RDM’s, ensure secondary SCSI controller is also set for “Physcial” under SCSI Bus Sharing.
- Power up VM and update VMware Tools (if desired)
- Re-Connect NIC’s so that nodes can communicate – Within a few minutes, you will see that node 1/2 are both online in Failover Cluster Manager.
Total downtime for the customer was around 15 minutes. Time for both VM’s to be on the new infrastructure was around an hour.