In my previous article about enabling Microsoft Azure Site Recovery (ASR), I showed you how to configure Azure and Hyper-V hosts and clusters to enable replication of running virtual machines to the cloud using ASR services. In this post, I’ll show you the step-by-step process of replicating virtual machines to Azure, including additional configuration steps that you should perform.
If you’ve kept along with my previous article, then you should have already performed the following:
The next step is to start replicating your on-premises Hyper-V virtual machines into Azure.
Unlike with pure Hyper-V Replica, you will not be enabling virtual machine replication from the source host. Instead, you’ll log into the Azure management portal and navigate to Recovery Services, where you’ll enter your ASR vault and protection group. You’ll see an option to Add Virtual Machines, where clicking this option opens the Enable Virtual Machine Protection dialog. Select one virtual machine and select the operating system type, where the latter obviously affects your billing when the virtual machine is powered up. You should also select the virtual hard disk that contains the operating system.
Within this dialog, it is important to note that you can only enable protection for one virtual machine at a time . If you have multiple virtual machines, then you’ll need to revisit the dialog or use PowerShell.
Once you click the check button to signify completion of the task, Azure will communicate with the on-premises Hyper-V host that’s running the selected virtual machine via the installed provider. Your virtual machine will show an Enabling Protection status in the Azure provider while this is occurring.
Also note that you can create more than one protection group for a Hyper-V site. This lets you have some virtual machines replicate according to one policy and others that replicate with another policy. Keep in mind that a virtual machine can only be replicated once, so it may only be enabled in one of those protection groups.
When Hyper-V Replica (HVR) is enabled, the virtual machine must be copied to the destination site. Regular asynchronous replication will continue after this initial copy. The initial copy takes some time. How long? Well that depends on a few factors:
In other words, I do not know how long a copy will take. Only you can determine the time it takes by doing some math.
Speaking of bandwidth, I cheat a bit when I do a demonstration. No one wants to sit around while 12 GB of data is replicated from my lab via a modest consumer-grade ADSL line with a 256 Kbps upload speed! So I create a number of virtual machines with blank dynamic VHDX files. Each file is 4 MB in size and an initial copy is done in seconds. I cannot fail these machines over, but they allow me to demonstrate the mechanics of enabling replication and recovery.
Unfortunately, at this time there is not an out-of-band method for conducting the initial copy. But I would not be surprised to see it added in the future, as this has been perviously done for Azure storage accounts and for seeding online backup.
You can monitor the progress of a copy. The first place to look is the Jobs view in your ASR vault. Everything that ASR does is a job. Each job has steps, and Azure tracks the progress of these steps.
The second place you can look is on the host itself in Hyper-V Manager. The status of the virtual machine will show the percentage progress of the initial copy. The Replication information tab at the bottom of Hyper-V Manager shows a quick replication summary. You can also right-click the virtual machine and select Replication > View Replication Health to see more information.
Once completed, the virtual machine will show a status of Protected in the vault’s protection group.
When your virtual machine reaches a protected status, then HVR starts to conduct asynchronous replication according to the policy assigned in your protection group’s replication policy. The virtual machine doesn’t exist in Azure yet, as it’s only consuming storage. The virtual machine will eventually exist because of a test, or a planned or unplanned failover. At this point, we’ll have an issue if we start a replica virtual machine:
You can configure these two settings by navigating into a virtual machine via the protection group in the Azure management portal. Here you can configure the specification that the replica virtual machine will have should it ever be started up via any kind of failover. Make sure that you assign enough resources for your service requirements. I would probably go with the Basic tier when possible. The only benefits that the Standard tier provides is additional specifications, that is unless you automate the installation of Standard tier features, such as load balancing or auto-scale.
You can also set your virtual machine’s network. Remember that the virtual machine will have a single virtual network connection with a dynamically assigned address for the subnet. But you can override that with a static address after the virtual machine is deployed.
Once you are finished with your first virtual machine, you can test a failover, enable replication for the rest of the virtual machines, and configure target settings.
The end goal of ASR is to create one or more one-click failover processes that can quickly start with little IT knowledge beyond being able to log into Azure. ASR offers recovery plans, a set of ordered steps for failing over virtual machines, requesting manual steps and running Azure Automation runbooks. A recovery plan can automate the failover of up to 50 virtual machines. There are two ways you can use recovery plans:
Keep your recovery plan design in mind when enabling replication of your virtual machines. For example, consider whether you want to get the essentials of each service into Azure as quickly as possible, or perhaps you want to prioritize the movement of complete services with all of their HA and scalability.