Has anyone done a Hyper-V failover with Nimble?

[pbitpro96]

I am setting up my 2nd Nimble at the DR colo, where there is a Hyper-V cluster there ready to go. There is a 3-node Hyper-V cluster at HQ with 3 CSVs on the HQ Nimble.

Does anyone have a runbook or high-level feedback on the failover process?

-Shut down all Virtual Machines at HQtrs.

-On Nimble, failover all CSV volumes

-Present volumes to new cluster, add as CSV

-Import VMs into Hyper-V (one at a time?)

-Boot up VMs, set new IPs

-Move VMs to failover role

-Change DNS records to point to failover location (DR has different IPs from HQ)

Any thoughts would be appreciated. I'll be happy to share my runbook and procedures when the failover is completed!

[mfeightner34]

Hi Paul,

I'm also looking for guidance on the best way to do this.  We just had our annual DR testing using Hyper-V replication (don't have the second Nimble deployed in our DR site yet), and it was very quick and easy to do.  I'm hoping that when we move over to Nimble replication, we can find ways to make it just as quick and easy. Any input from others already doing this would be greatly appreciated.

Thanks for posting.

[pcaviness27]

Hi Paul,

I don't have hands-on with Hyper-V and DR failover, but Appendix B in the Hyper-V best practice guide offers some tips.

http://uploads.nimblestorage.com/wp-content/uploads/2015/05/22100703/bpg_nimble_storage_hyperv.pdf

Hopefully this will be helpfull - let us know how everything works out.

Thanks - Pete

[jliu79]

My setup is a little different from yours:

My main site Nimble replicates to the DR site Nimble and I have a pretty good connection between the 2 sites and they use the same IP subnets. I have a 4-node cluster: 3 at HQ, and 1 at DR.

In the event of DR:

1. Shutdown all the VMs

2. Failover Nimble volumes.

3. re-establish iSCSI connection in connection manager to the DR site array.

4. The  Hyper-V cluster should see the same CSV volumes.

5. power up VMs on the node at DR site, set up new servers and join them into the cluster.

[mfeightner34]

Hi Jason,

So just to be clear, you have a node at your DR site that is a member of your production cluster, is that correct?  Not sure that would work for us, but an interesting option.

Thanks!

[jliu79]

Yes the node at DR is part of the production cluster which will make things much easier for us. But I think the steps you listed would work for your setup.

[foodandbikes · Accepted solution]

I've spent the last 2 years planning this for a customer, doing simple tests for all methods.

Hyper-v replication is by far the easiest method, but that does not work for all VMs. It also allows for auto re-IP of VMs as well, assuming OS is supported.

If the outage is planned and you have a DR cluster waiting, then you could use the Cluster role migration wizard. This will NOT affect your production cluster.

1. Migrate roles to DR cluster using Cluster migration wizard. This creates shell objects for VMs, storage, etc.

2. Failover the Nimble volumes.

3. Present the volumes to the DR cluster, but do not configure them. You may just need to bring them online, I forget. The migration wizard will recognize the disk GUID and bring them online with the same name and config as the source side.

4. Power on your VMs in FOCM. This process then creates all the VM objects in hyper-v.

5. Re-IP all the systems as necessary.

If DR is not planned then you will need to:

-On Nimble, promote all CSV volumes

-Present volumes to new cluster, add as CSV (try to keep the same volume names to make importing easier)

-Import VMs into Hyper-V (one at a time?)

-Boot up VMs, set new IPs

-Move VMs to failover role

-Change DNS records to point to failover location (DR has different IPs from HQ)

The idea of having a cluster node at the DR site is intriguing...