Microsoft announced several improvements to its cloud-based disaster recovery (DR) service, Azure Site Recovery (ASR) at Ignite 2017. Most of these features aren’t publicly available yet but should be either generally available or in preview in the coming weeks and months.
ASR is a DR service that covers three scenarios for Windows and Linux machines
- On-premises to on-premises replication for vSphere and System Center and Hyper-V customers
- On-premises to Azure replication for vSphere, System Center and Hyper-V, Hyper-V, and physical server customers
- Replicating Azure virtual machines from one Azure region to another – currently in Preview
New Recovery Services Vault Dashboard
Some customers were quite vocal about how difficult it was for them to manage their ASR deployments; they needed an overall view that could quickly dive into the details, highlighting exceptions that needed to be managed.
As a result, a new dashboard for ASR is being added to the recovery services vault, the resource type in Azure that is used for managing ASR and Azure Backup. This new dashboard should provide comprehensive replication and failover monitoring.
Azure Site Recovery Deployment Planner for Hyper-V
We’ve had a version of the ASR Deployment Planner for VMware since March. VMware is a bigger market than Hyper-V, so I was OK with a planner being released for those customers first. Microsoft promised a version for Hyper-V by the end of Q2 of the calendar year 2017, but it had yet to surface by Ignite 2017 (end of Q3). I asked about this at Ignite and was told that the Hyper-V version was announced that same week. Two weeks have passed since Ignite and I’ve yet to see a download link. This might be another example of the current Microsoft “announcement”, which is more of a statement of intent instead of a release.
I like how easy it is to replicate a running Azure virtual machine from one region to another and Microsoft has just made it easier. Instead of browsing to your recovery services vault, you can edit the settings of the VM and enable replication from there, just as you can to enable Azure Backup protection.
That’s one less excuse for not knowing about inter-region fault tolerance of your Windows or Linux compute workloads.
Multi-VM Consistency Groups (Preview)
ASR treats each machine independently; each is replicated in an isolated state from the others and each can be failed over as a single instance.
Some applications require that a group of machines is failed over in a cross-machine consistent state. To date, this has not been possible with ASR. In the near future, Multi-VM Consistency Groups will allow us to simultaneously create application consistent snapshots of multiple machines. When we failover, we can select the application consistent snapshot as the recovery point for that group of machines, thus maintaining application consistency across multiple virtual machines.
OVF-Based Management Appliance for vSphere
Replication of vSphere virtual machines requires an on-premises management role, executing three critical services, to be deployed onto a Windows Server 2012 R2 (virtual) machine. The installation and configuration of that management server can be fiddly.
Microsoft is introducing a new OVF-based image for that machine that you will be able to easily import into vSphere to build the new machine. You will then connect to the service via a URL and complete a relatively simple wizard to configure the management appliance. At that time, you’ll switch over to the recovery services fault to start managing replication, orchestration, and failovers (including isolated test failovers).
Added Support for vSphere
Support for WS2016 was announced for vSphere. However, at the time of writing (mid-October), WS2016 was officially listed as not supported on vSphere.
We’ve had support for UEFI-based virtual machines on Hyper-V (Generation 2) for a long time but to date, vSphere virtual machines could only use BIOS. Microsoft is changing this by adding support for UEFI-based virtual machines on vSphere. This is still listed as unsupported.
Failback of Managed Disks
I’m a huge fan of using managed disks in Azure. They just make life so much easier when running workloads in Azure … unless you want to use Azure Site Recovery. Managed disks do not require storage accounts (none of the pain of dealing with unique names, tracking disk numbers versus the 20,000 IOPS limit of a storage account, and more), added features such as snapshots, easy VM creation from disks, higher levels of availability, and the list goes on, and on …
If you want to use ASR for disaster recovery. then managed disks is not for you. I know! You’ve seen managed disks as an option in ASR – please don’t use it without knowing what it’s for! After you have performed an initial sync of a new machine to Azure, you normally pre-configure some things like network settings, virtual machine series/size, and availability set membership. A check box appeared there a few months ago to deploy a failed over machine with managed disks. That’s great, right? Not so much, and here’s why.
- If you are planning to use ASR to migrate a virtual machine to Azure, it’s recommended that you check that box to deploy the (planned) failed over machine with managed disks.
- However, if you check that box in a DR scenario and want to fail the virtual machine back to on-premises after a disaster, you cannot check that box. Doing so will prevent a failback today.
Microsoft is working on enabling failback of machines that are failed over to Azure with managed disks. Hopefully, this will coincide with support for replication Azure virtual machines from region to another when those machines have managed disks.
You might think I’m being a bit negative with my comments on announcements versus unknown availability. This is something that’s irking me in general with Microsoft these days. However, I’m overall positive about the direction that ASR is going and they did say to watch the ASR blog over the coming months for news on these new features.