Designing your business continuity and disaster recovery (BCDR) strategy may have become a whole lot easier, thanks to Azure Site Recovery. With cloud adoption increasing at an ever higher rate, for most businesses that means implementing a hybrid-cloud model with certain mission-critical workloads and data remaining on-premises. Fortunately, with Microsoft’s InMage acquisition, Azure Site Recovery (ASR) brings a number of different BCDR deployment scenarios to the table that now include even VMware-based infrastructure.
Protecting On-Premises VMware VMs in Azure
This scenario lets us utilize the resources of scale available in the Azure cloud to help protect on-premises services. In a new BCDR plan, we are no longer looking at building out a physical failover site, which reduces or eliminates capital expense for additional servers, storage, networking, and other infrastructure. Instead, we inventory virtual machines required for failover and budget per-instance. Viewing disaster recovery as a service, provided that prerequisites and requirements are met, should lead to relatively quick implementation as well. With proper recovery plans, we can enable simple failover and failback for replicated VMs, even for multi-tiered applications.
Replication Between On-Premises VMware Sites
Our second scenario is using ASR to replicate and orchestrate failover between on-premises VMware sites. Many organizations will already have existing disaster recovery sites, or they may need to combine multiple failover methods as part of a larger BCDR strategy. ASR can now meet these needs and allow businesses to consolidate cloud offerings in Azure.
The primary focus in this article will be on protecting on-premises VMware virtual machines in Azure.
Azure account – You will need a Microsoft Azure account. A free trial is available.
Azure storage – Must be either a standard geo-redundant storage (GRS) account or a premium storage account. It also needs to be associated with the same subscription and be in the same region as the Azure Site Recovery service.
Azure virtual network – The configuration server and master target server should be deployed in the same Azure virtual network, which must also be associated with the same subscription and be in the same region as the Azure Site Recovery vault. ExpressRoute or site-to-site VPN are optional, depending on your preferred replication transport.
Virtual machines – Protected VMs need to conform to Azure requirements.
Windows – Windows Server 2012 R2, Windows Server 2012, and Windows Server 2008 R2 with SP1 are supported.
Linux (64-bit only) – Centos 6.4, 6.5, 6.6; Oracle Enterprise Linux 6.4 or 6.5 running either Red Hat compatible kernel or UEK3; SUSE Linux Enterprise Server 11 SP3.
VMware – vCenter 5.1 or 5.5 is required, along with ESXi 5.1 or 5.5 hypervisors, all with the latest updates. VMware Tools should be installed and running on protected VMs.
Configuration server – As the central management component, this coordinates communication, replication, and recovery operations. This resides in Azure.
Master target server – This receives and stores replicated data at each site.
Process server – It caches, compresses, encrypts, and transfers data between sites. This also performs push installation of the mobility service and automatic discovery of on-premises VMware VMs.
Mobility service – This service runs on protected VMs and transfers data to the process server. It utilizes VSS for Windows application consistency.
Azure Site Recovery vault – Servers are registered in the Site Recovery vault. This orchestrates ASR processes.
Replication mechanism – The options for replication transport are public Internet over SSL/TLS (default), site-to-site VPN, or ExpressRoute; all communication is outbound-initiated from source site.
vContinuum server – This on-premises component coordinates failback plans.
Network connectivity between your on-premises site and Azure virtual network can take place over public Internet or private connections (site-to-site VPN or ExpressRoute). When using public Internet, most communication, including VM replication, takes place over SSL/TLS encrypted connections using the public endpoints on the configuration server and master target server. The choice of transport method must be made during the initial deployment and cannot be changed; however, the best choice for any given environment will be driven by the failover workload and business requirements.
You will have to take certain configuration maximums into account when planning for ASR. These include max size per disk and per VM (1 TB and 31 TB, respectively), number of VMs per master target server, and daily change rate. For individual VMs, dynamic disks are not supported and you are limited to 1 TB daily data change, or 144 GB per disk, at the top end. Microsoft recommends a limit of 10,000 IOPS at the source per master target server. Consequently, your choice of GRS or premium storage in the Azure environment will depend on your source workload.
For component server sizing, we’re mainly looking at the process servers, master target servers, and configuration server. Process servers are sized according to daily change rate, taking resources such as compute for inline compression and encryption, available disk-based cache storage, and network bandwidth into consideration. Master target server sizing relies upon total IOPS, daily change rate, and retention volume storage. Also consider the overall IOPS limit per Azure storage account when planning your master target servers. Each configuration server will handle up to 100 protected VMs, beyond which you will need additional configuration servers.
By replicating VMware virtual machines to Azure or to a secondary VMware site, Azure Site Recovery allows us to leverage the Azure platform to streamline our cloud portfolios and recovery plans. The ability to integrate other infrastructure models, such as VMM, Hyper-V, and multi-site layouts, is a great added bonus that reduces cost, complexity, and administrative effort. For many organizations with VMware infrastructure already using Azure or those looking to get started with Azure, this makes for a particularly compelling BCDR solution that can tie in with single pane of glass cloud management.
Do you want to explore options for extending your infrastructure to the cloud? Credera has extensive experience in designing, planning, and implementing cloud solutions. If you have questions about this blog post, points of view, or IT infrastructure, please leave a comment below, contact us here.