Simplified Azure Site Recovery for VMware vSphere
I was stunned when Microsoft announced that they would support using Azure as a cloud-based disaster recovery site for VMware vSphere. VMware has a large share of the on-premises virtualization market, and despite the growth and progress of Hyper-V, many customers are keeping that incumbent footprint.
Rather than ignoring that lucrative market or causing customers with heterogeneous on-premises virtual installations to seek multiple vendors for disaster recovery as a service (DRaaS) solutions, Microsoft has given those customers a single cloud, Azure, to which they can replicate Hyper-V, vSphere, and physical machines to for disaster recovery. Unfortunately, Azure Site Recovery (ASR) required some in-Azure complexity, but Microsoft has announced the simplification of ASR for vSphere, and this should make Microsoft’s DR site in the cloud much more attractive.
Legacy Azure Site Recovery for vSphere
The solution that Microsoft rolled out to support vSphere in 2015 was based on a product called Scout that was obtained by Microsoft through the acquisition of InMage. As has often been the way of the past, Microsoft has gone through a phased process of releasing and integrating this new product:
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.
- Release the product as quickly as possible.
- Improve the product and make it more “Microsoft” over time.
This has been the case with Scout, which provided Microsoft the means to replicate Windows and Linux machines to Azure. The architecture was quite complex when compared to ASR for Hyper-V. At least two Azure virtual machines were required to run in Azure, and another machine was required on-premises:
- Configuration Server: This is an Azure Standard A3 virtual machine running in the same subscription that is the target for replication. This machine coordinates all replication activities for VMware virtual machines and physical servers.
- Master Target Server: This is either a Windows Server 2012 R2 to replicate Windows or a CentOS 6.6 to replicate Linux Standard A3 (maximum of 8 data disks) or Standard D14 (maximum of 32 data disks) Azure virtual machine in your Azure subscription. This machine receives replicated data from the primary site and writes it to attached data disks in VHD format. These disks are the disks that will be used to failover to Azure.
- Process Server: This Windows Server 2012 R2 physical or virtual machine is deployed on premises, preferably on the same LAN as the machines it will protect. This machine will optimize replication traffic before sending it to Azure. It also provides automated discovery of VMware virtual machines.
It doesn’t take long to see that running two or more virtual machines in Azure creates a lot of cost in addition to the per-replicated machine charge for using ASR. I had a number of customers contact me about replicating from small VMware installations to Azure; I advised that it would be cheaper to convert to Hyper-V and then to replicate to Azure without needing additional machines to manage and receive replication traffic.
Enhanced Azure Site Recovery for vSphere
Microsoft announced that ASR will no longer need virtual machines to run in Azure as the Master Target Server or the Configuration Server; I assume these roles will be handled by the Azure fabric, something that was discussed at TechEd Europe 2014. You no longer need those machines and that means:
- The cost of using ASR for vSphere is reduced.
- The complexity of the solution is reduced.
Other changes made to ASR for vSphere include:
- Unified installation: Setup of on-premises components was made simpler and more scaleable.
- Secure deployment: HTTPS 443 is used to secure replication and management traffic.
- Recovery points: Windows/Linux single virtual machine and multi-virtual machine deployments are crash and application-consistent.
- Test failover: You can test failovers without impacting production systems or ongoing replication.
- Unplanned failover: An unplanned failover to Azure can be done with an option to automatically shut down virtual machines before failover.
- Failback: Only delta changes are replicated back to the on-premises site.
- vSphere 6.0: There is some support for VMware Vsphere 6.0.
Microsoft stepped ahead of VMware when they offered VMware customers a hybrid cloud DR solution. Microsoft’s rapid pace of development means that, just a few months after release, ASR support for VMware has been enhanced and extends Microsoft’s lead.