Offload Storage Mirroring Operations with Azure Site Recovery (Part 3 of 3)

What We Covered So Far and What’s Next

In part 1 of this blog series I talked about the advantages of offloading disaster recovery/business continuity–type operations to an orchestrator such as Azure Site Recovery (ASR). I also talked about how this differs from the NetApp® SnapManager® for Hyper-V® (SMHV) offering.

 

In part 2 of this series I explained how to set up ASR to protect your private cloud and included a number of screen captures to illustrate the settings and options you need to be aware of.

 

So far I have not discussed either creating a recovery plan or testing failover and failback. I will do that here, and then I will discuss how ASR and SMHV can be used together.

 

Creating a Recovery Plan

As this point you should have at least a single VM that is part of a cloud and protected using ASR, but that is all useless unless you have a plan for what to do in case of a failure. From the ASR menu you can select our protected cloud vault, choose Recovery Plan, and then choose Create Recovery Plan.

 

Creating a Recovery Plan.png

 

You then get to select where the recovery plan will operate (see the example below).

 

Specify the Recovery Plan.png

 

Once you select the SAN replication type, select the individual Replication Group that you want to be included in this recovery group. (See the sample screen below.)

 

Select Virtual Machines.png

 

Once that is done, the recovery plan is created, and you can choose some custom settings for the recovery group. For example, you can divide the pack of servers into two sets and let them start up in order. This might be valuable if you have a server, such as a domain controller, that needs to be available before other servers start or if you have a SQL back end for a series of web server front ends. Note that other customer actions can be placed in here as well, such as post-VM scripts. You’ll find more on this feature later in this blog post.

 

You will also note that the actions listed in the recovery plan assume that you are performing a planned failover and will properly shut down the VMs on the primary site before failing over. This will still occur in a situation in which a proper shutdown did not occur, but in cases in which a proper shutdown is possible, this prevents problems.

 

Failing Over a VM to a Secondary Site

To fail over a VM to a secondary site, open the Azure Site Recovery options and choose Failover for the VM you want to move (see the example below).

 

Failover.png

 

Once you choose to move your VMs from site to site, the orders stipulated in the recovery plan, in this case a set of three VMs that will be booted in a specific order, will be followed.

 

Confirm Failover.png

 

At this point, you could grab a coffee, but be fast, the process won’t take long. You can always watch the job through the Jobs button; see the following for what that will likely appear as.

 

Failover Complete.png

 

Once this process completes, the VMs should be running in your secondary cloud on your secondary site. 

 

Reversing Back to the Primary Site

Reversing the operation that just completed should be just as easy. Along the bottom bar of the same Azure screen that you used to initiate the failover there is an option to Reverse the Replication. This action returns the VMs to the primary site in the same way that they were moved to the secondary site.

 

Reversing Back to Primary Site.png

 

Creating Test Failover VMs

Now that you moved a VM back and forth, let me show you how to do a test failover without affecting the VMs on the primary site. Obviously you can’t have a test VM failover pop up on the network while the original is running, so you should choose to test the remote site using an isolated network. Following is the option to care about under the section “Confirm Test Failover.”

 

Confirm Test Failover.png

 

Integrating SMHV with ASR

Although technically there is no integration between SMHV and ASR, there is a way to use these products together because neither directly interferes with the workings of the other. The strength of SMHV is that it is tied to the VM and knows how to create a hardware-based VSS flushed NetApp Snapshot® copy. Once SMHV creates this Snapshot copy, it lives in the NetApp FlexVol® volume.

 

When ASR uses NetApp® SnapMirror® software to copy the FlexVol volume from the primary to the secondary location, the SMHV-created Snapshot copies get pulled along. This means that if you are forced to perform an unplanned failover to the remote site, you can choose to bring up the most recent (unflushed) copy of the VM, or you can choose the most recent SMHV (VSS flushed) copy of the VM. The only action you would need to take would be to revert the VM to the most recent SMHV-created Snapshot copy instead of using the most recent SnapMirror copy. This process would have to be scripted but could be automated. As soon as I write sample scripts for this I will post them on the NetApp PowerShell and SMI-S Communities sites, so keep an eye out for them there.

 

Visit our Microsoft Cloud and Virtualization Communities site for a deeper conversation regarding this new cool feature called ASR and for SMI-S help in general.