Rob Waggoner |
|
In this video, I walk through the Test Failover scenario. I will show you how to initiate a Test Failover and the results of a Test Failover scenario. Take note that a Test Failover scenario exists so you can ensure that your VM is replicating to Azure. Test Failover is not for production, but a tool to leverage to confirm your failovers are ready in the event of a disaster.
Two things that came up in this discussion:
- The RDP endpoint is not enabled by default, you must manually add the endpoint to the test VM before you can remote to it. From a security perspective, this is the way to do this. We do not expose any more capabilities than you need. As you will see in the Fail Over video, you don’t actually need to enable RDP if you have a Site-to-Site VPN in place.
- Your attached virtual hard disks (other than C:) will be offline in your test VM unless you set a policy in DiskPart. Below is a screen shot of configuring the policy. Remember, this needs to be implemented on your production VM, not the test replica VM:
The key line is DISKPART> SAN POLICY=ONLINEALL from within Diskpart. If you set this policy on the original VM (not one of the test failover replica’s) all of your attached virtual hard disks will come up by default in Azure. Otherwise you must manually bring them online in the Azure VMs.
A few other nice details about ASR
- What if my VM is using the D drive, what will happen to my D drive with ASR? ASR will map the temporary drive to a different letter so your workload will see it the original D drive.
- What about workloads that use the VHDX formatted hard disk on my local Hyper-V host? ASR can support VHDX’s on a local Hyper-V host. ASR will actually copy the VM to a VHD formatted file within Azure, and copy the contents back to your on-premises VHDX in the event of a fail over and fail back scenario.
Be sure to watch the rest of the series at http://azure.msts2.com
Until next time,
Rob