• 5 min read

Azure Site Recovery Enables One-Click Orchestrated Failover of Virtual Machines to Azure

Recovery plans in Azure Site Recovery can enable a one-click recovery of virtual machines to Azure. Read on how to build and customize them for your workloads.

Azure Site Recovery, with its Disaster Recovery to Azure capabilities, can now protect your workloads and recover them in Azure as IAAS VMs. Brad Anderson announced the preview of disaster recovery to Azure on the 19th of June. Since then we have seen a massive uptake of the feature with customers protecting and recovering their virtual machines in Azure. If you haven’t already started using the service check out the Teched video and sign up for the service.

In this short blog we will look at how you can take advantage of a Azure Site Recovery feature called the Recovery Plan to make disaster recovery to Azure consistently accurate, repeatable and automated. This blog will also give you a short overview of how to build recovery plans and give guidance on some interesting pieces of activities that you need to take care when failing over your virtual machines to Azure.

Azure as a target brings about changes to the way users see the failed over virtual machines and how they interact with them. However, the Site Recovery team has worked very hard to ensure that the experience of failover to Azure remains intuitive and simple. Our goal remains the same: One-Click Disaster Recovery. Additionally, we have also ensured that the disaster recovery to Azure experience remains similar to the experience of recovering an application into another VMM site . Needless to say, a recovery plan to Azure can be used for a planned failover, unplanned failover as well as for DR drills using test failover.

A recovery plan to Azure continues to address the following needs for the user:

  1. Defining a group of virtual machines that failover together.
  2. Defining the dependencies between the virtual machines so that the application comes up accurately.
  3. Automating the recovery along with custom manual actions so that tasks other than the failover of the virtual machines can also be achieved.


Create Recovery plan

To walk you through the experience let us consider a simple three-tier virtualized application made up of ‘BackendSQL’, ‘MiddlewareApp’ and the ‘FrontendIIS’. Let us create a recovery plan so that the application can be recovered into Azure when required. Let us name it ‘FinanceAppRecovery’.

 01RP Create first page  02RP Create second page
  • Create a new Recovery plan.
  • Give the recovery plan a name.
  • Specify the source as the VMM server and target as Microsoft Azure
  • Add the virtual machines of your application into the the recovery plan


Customize Recovery plan

A simple three-tier application can be visualized as below. The frontend servers depend on the middleware and the SQL servers. The middleware server would also depend on the SQL server. To guarantee that  the application comes up correctly you need to ensure that the dependencies are modeled correctly. This will recover the virtual machines honoring the dependencies you model.

three tier

These dependencies in the application can be defined by using Groups. For our walkthrough, the user would create three groups – one for each tier of the application and move the virtual machines into the correct group. For our example, place the ‘BackendSQL’ into Group 1, ‘MiddlewareApp’ into Group 2, and the ‘FrontendIIS’ into Group 3. This will ensure that during shutdown of the application on-premises, the Group 3 will be shutdown first following which the Group 2 virtual machines will be turned off. Group 1 VMs will be turned off in the end. This will ensure that during shutdown there is no data loss.

 04 add group  05 move VM
  •  Use the ‘Group’ button on the task bar to add new groups
  •  When a group has been added select a virtual machine and ‘Move Virtual Machine’ into the required group

The boot order is also orchestrated in the order of the groups. The Group 1 virtual machines will be booted first, followed by Group 2 and finally Group 3. This is to ensure that the backend virtual machines come up before the VMs that depend on it. In our example, when the ‘FrontendIIS’ virtual machine is booted in Group 3, both the VMs that it depends upon ‘BackendSQL’ and ‘MiddlewareApp’, will also be up and running in Azure

The above image shows how a three tier application looks when a recovery plan is created for it.

Initiate failover

When you initiate a failover, the plan recovers the virtual machines in Azure as IAAS virtual machines. The plan also ensures that the dependencies are honored and the VMs are brought up in the right order. The virtual machines are attached to a virtual network based on the network mapping inputs.

 07 recoveryjob
After initiating a failover you can go to the jobs page to see the progress. The jobs page will show you granular progress and inform you if there is any error during the execution.

After failover completes you can see that a FinanceAppRecovery cloud service has been created for you. If you navigate to see the instances deployed in the application you can see that the three virtual machines have been recovered as IAAS machines and are ready to use.

 08 cloud service instace
The virtual machines are now recovered in Azure. Now you can interact with them as if they are IAAS VMs.

The recovery plan is now in a ‘Commit Waiting’ state. Ensure that you commit the plan so that failover is completed.

When you are ready, check out the Azure Site Recovery product page  and sign-up for an Azure Trial to get started. If you stumble across any issues or want to engage with other users, visit the Azure Site Recovery Forum on MSDN. We are constantly improving and enabling new feature – Get your voice heard!

Here are some quick FAQs if you get stuck or wonder why-does-it-work-that-way?

Q1. I get a warning “The name can contain only letters, numbers, and hyphens. It should start with a letter and end with a letter or a number. “, when creating a recovery plan. I never got this when I created a plan to recover into another VMM site.

name and target

Ans. When a recovery plan is failed over into Azure, a cloud service also gets created with the same name as recovery plan and the VMs that are recovered get deployed in it. It gets created in the same affinity group as the network to which the VMs in the plan belong to. Cloud service name is a global public endpoint that can be used by you to reach the virtual machines. If the recovery plan name is ‘FinanceApplication’, the cloud service will generate a subdomain financeapplication.cloudapp.net. When you failover the recovery plan back to VMM – the cloud service will get deleted.

Q2. Is there a limit to number of VMs in a single recovery plan?

Ans. A single cloud service cannot have more than 50 virtual machines. Hence there is also a limit to the number of VMs that can be added to the recovery plan and is set to 50.

Q3. There is a limit of 20 cloud services per subscription. Does this mean I cannot create more than 20 recovery plan?

Ans. Limit on the number of cloud services does not limit the number of recovery plans you can create. But you cannot failover more than 20 recovery plans. You can increase the number of cloud services by opening an incident with the help of Azure Customer Support.

Q4. I have a VM that serves webpages at port 80. However after failover into Azure I cannot connect to the VM over port 80. I also cannot RDP into it. Is there something more I should do to enable this?

Ans. A VM that is failed over to Azure cannot be accessed directly over the internet. You need to configure the endpoints to allow access. Follow this tutorial to understand how to configure the endpoints.

Q5. I configured the Remote Desktop (RDP) endpoint but still the virtual machine is not reachable. What could have gone wrong?

Ans. Did you enable the RDP port on the virtual machine before failover? If you have not configured it in the Windows settings you cannot access the VM. Make sure that you have allowed other computers to connect to your machine using remote desktop.