Last Update: Sep 04, 2024 | Published: Mar 16, 2015
Part of the attractiveness of Microsoft Azure Site Recovery (ASR) is the ability to orchestrate failover of virtual machines. Microsoft calls this orchestration “one-click failover.” In this article, I will explain how you can create a Recovery Plan (RP) for managing the failover of Hyper-V virtual machines to Microsoft Azure.
A recovery plan (RP) is a set of ordered steps that allows you to conduct a failover in a prescribed fashion. Virtual machine startup can be ordered, thus modelling application dependencies (database first, then application, then web interface), and to conduct other operations that are either scripted or completed manually.
An RP can orchestrate the failover of up to 50 virtual machines. When you failover to Azure, the virtual machines will be a part of a single cloud service. You can have up to 20 cloud services in a subscription, so you can failover up to 20 RPs, assuming that the subscription doesn’t have any other deployed cloud services.
The original intention of an RP was to orchestrate the failover of an n-tier application. If you have three n-tier applications (each up to 50 virtual machines), then you have three RPs, one for each application. If you operate in an SME environment, however, you might have just a single RP for all virtual machines. Keep in mind that if you do this then all of the virtual machines will share a single public IP address (the cloud service) after a failover, so you will not be able to open a public port, such as TCP 80 to more than one machine.
A simple recovery plan will automatically instantiate and boot any selected virtual machines. You can create groups to order the start-up of those machines.
When you create a RP, you can select it and run a test with planned or unplanned failover, which affects all virtual machines in the plan. By default, a RP will have a single group. All virtual machines in that group will failover at the same time. To model dependencies, you can create groups. When you run a planned failover, the virtual machines in the last group are shut down in the production site first, and the virtual machines in the first group are started up first. In unplanned and test failovers, the plan simply starts with Group 1 and works in forward order.
We can also create scripted and manual groups that run before or after a virtual machine group. A scripted group will execute an automation runbook. This can be useful to create endpoints for Internet accessible services or to reserve virtual network IP addresses. A manual group allows the runbook to prompt the operator to start a documented action; the runbook will pause until an operator confirms that the action was done.
You can start engineering RPs once your virtual machines are replicated. Make sure that you have done the following:
Browse into your recovery vault and select Recovery Plans. Click Create and confirm the configuration of your new RP as shown below.
The following screen is where you select the virtual machines that will be managed by this RP. You can add virtual machines later if you want to.
Browse into a RP to edit it. A new RP will have a group called Group 1: Start. This contains all of the virtual machines that you originally added to the RP. At the bottom of the screen, you have the option to add:
If you add a group, select a virtual machine and click the Move Virtual Machine action. A mini-menu appears to let you move the virtual machine into a different group.
If you select a group, you can add:
When you are happy with your engineering, you can test it via a test failover, where your virtual machines will be brought online on a virtual network of your choice, such as the isolate test network.