If you have not had a chance to read part 1 of this three-part series, please do so now, because part 1 explains what Azure Site Recovery (ASR) is and why you would want to use it in your environment. Part 2 in this blog series has a narrow focus on the steps to make Azure Site Recovery operational in your environment. Part 3 will cover testing failover and failback, provide a deeper understanding of what actually happens behind the scenes, offer a few recommendations for troubleshooting, and discuss some advanced topics such as using a remote site clone of a protected VM for testing.
A Few Assumptions About Readers
To get the most out of this blog post, you should already have done the following:
How to Set Up Replication Groups and Make Cloud Settings
Once you have taken the steps above, we can protect your VMs with Azure Site Recovery, with SAN replication functionality provided by the NetApp SMI-S agent and SnapMirror. The first step is to open Fabric Resources [in what application is Fabric Resources?] and then, under Storage, click on Arrays. Once your SVMs appear in the managed array list (you should see the primary site array and the secondary site array), you can right-click the primary array and choose Properties. One of the options for Properties is Replication Groups. By clicking New you will launch the Replication Group Creation Wizard. Make sure to select LUNs attached to Hyper-V hosts that will hold protected VMs’ virtual disks.
Once you create your Fabric Replication Group, you can either create or modify your cloud under the VMs section. Make sure that on the first page of the Cloud settings you select the Send Configuration Data About This Cloud to the Azure Site Recovery option.
Continue to set up the private cloud as you normally would by selecting all of the appropriate resources; however, the last step prior to the summary should be selecting Replication Groups. On this page, select the Replication Group that was created in the previous step.
A second cloud needs to exist at the DR destination site (and also have resources assigned to it).
Azure Portal Settings
Once both of these clouds exist and they are each sending configuration data to Azure Site Recovery, launch the Azure Site Portal and continue the configuration from this portal. Then continue on to Recovery Services and choose the Azure Site Recovery Vault. Then choose Protected Items.
After you select the appropriate primary cloud, it will launch the configuration steps shown below. As you select each item from the top down, different options will become visible. Make sure to choose SAN as the Replication Type; the Array tab will appear.
Once the primary cloud protection is configured and the secondary cloud is identified as, Azure will configure the secondary cloud as its pairing partner.
Then you need to configure one more setting—the Server Storage setting under the Resources option for the ASR vault. You need to select the source and target for the replication pairing shown as follows.
Choose the option to map the storage to the vault by selecting the NetApp SVM and Storage Pools, as shown in this dialog box.
Once you complete these steps, you will have a new designation for the two clouds—the primary cloud will be designated as the Protected Cloud and the secondary cloud will be designated as the Recovery Cloud. Once you set the Azure Site Recovery Cloud settings, click Protected Cloud under Protected Items and select Virtual Machines. The option will appear to add a Replication Group.
Creating and Modifying the Default Templates
Once you complete the settings above, you can create or modify the default VM template for the Replication Group. Doing so allows all new VMs inside that Replication Group to automatically inherit the protection settings.
A Few FInal Words
This is a long post, but it contains the information needed to configure Azure Site Recovery. Blog post 3 in this series will discuss how to initiate test failovers and failbacks as well as discuss some troubleshooting steps and advanced features.
It is possible that VMs might be created without using the template, so in that case the protection settings would be done individually on each VM. The choice to divert from automatic protection is still with you.
Now read part 3, which covers creating a recovery plan, failover and failback, as well as a few advanced features such as cloning on the remote site.