To test the ASR fail over you can create a Recovery Plan which contains multiple VMs or test the fail over for a single VM. However it is important that you create recovery plans for your production environment in order to specify how the fail over should happen. Let’s take each scenario and see how we can address them.
- Should your require to RDP after you fail-over your VM to Azure, you must enable Remote Desktop Connection in on-premise VM before you do test or actual fail over. This is a MUST. Also same should be done with SSH access for Linux VMs.
- After the test fail over you’ll use a public IP address to remote into the Azure VM. In this case make sure your firewall doesn’t restrict that address. If you have configured the network mapping then you’ll get a private IP from your on-premise network. So you still RDP into LAN. I’d use this only after I have created a production recovery plan and use same for actual fail over.
Test Fail over from on-premise to Azure
In a test fail over you simulate the actual fail over sequence before you move it into production. For that you’ll need to choose between an existing isolated VM network or you can select NONE so that your test fail over will be done in an isolated environment without a VM network attached. Note that once you complete the test, Microsoft Azure will remove all the items like the test VM that was used to simulate the test.
- Select the VM network that you want to test the ASR. This should be a separate VM network or you can select NONE.
- You’ll need to create an End Point to allow RDP to the test VM. It’s pretty much straight forward as below.
- Once RDP end point has been created you can try remote into the test VM and see everything fits.
- Remember you still need to complete the test in order to clear the test deployment as below.
- It will prompt you to comment on the test scenario. Select the check box to clean up the environment.
- Once the environment is cleaned and the test is done you can see the status of the test fail over as all complete.
For production deployment you’ll have to create a recovery plan. It will run a sequence of actions that you define to perform the fail over. You can customize the plan to include VM groups to specify start sequences, scripts to run once fail over sequence starts etc… Refer this article from TechNet for more information on customizing the recovery plan.
- Select Source and Target followed by the VMs that needs to be included in this recovery plan.
Planned fail over is always pre – planned. For an example you want fail over your corporate web site at the end of each month when you update the web site. In such situations you can leverage ASR to plan it first hand, which VMs start first, any clean up tasks that should run etc.. Additionally you can configure an orchestrator workflow to automate same if you are using system center.
Unplanned fail over is more robust. This can be leveraged in a disastrous situation. It is something that you do not expect but you can create DR recovery plan for this
Let’s see how to work with a planned fail over. Note that steps are same for both planned and unplanned.
- Select Planned Fail over from the menu. Here I have only select the VM that I need to fail over. You can select a recovery plan that include multiple VMs if you need.
- Select the fail over direction. Since this is fail over it would be from on-premise to Azure.
- Let the process continue. As this depends on the network speed and size of the VM this may take some time.
- Once the fail over is done as above you’ll have to commit the fail over. Once it is committed your VM will be up and running from the cloud.
Once you completed the fail over you’ll need to move back to on-premise VM. Let’s see how you can do that. I have done this is again for a single VM not for a recovery plan to save time.
- You may notice that the VM in on premise VMM is in a halt status once the fail over has been done.
- Select the VM from Recovery Services and select the fail over accordingly. If you did planned before select planned again. I have selected the second option to minimize the fail over time but it’s up to you whether you want to go back to pre – fail over state or not.
- You’ll notice that several actions are skipped in the fail back job as we are syncing only the data that has been changed during the fail over window.
- If you have selected Synchronize data before fail over option additionally you’ll have to select Complete Fail Over button in the job window.
- To complete the fail over click Commit Button.
We have successfully configured fail over scenario from on premise Azure. In the last post of this series lets discuss the best practices, hiccups and how to clean the ASR configuration in VMM in a demo VMM environment.