Quick Links
- Part 1: ASR Deployment Planner Tool
- Part 2: ASR VMware – Azure Environment Prep
- Part 3: ASR Deploy a Configuration Server
- Part 4: ASR Enable Replication for VMware VMs
- Part 5: ASR Invoking a DR-Drill
- Part 6: ASR Invoke Failover to Azure
- Part 7: ASR Failback to VMware
Overview
In this guide series we’ll be going through all the necessary steps to replicate a VMware environment to Azure for DR purposes. To achieve this we’ll be making use of the Azure Site Recovery service but before we get into things, let’s have a quick overview of the components of ASR and their place within the environment/solution:
NOTE: When the time comes to continue on to a full production deployment, I’d advise having a proper read through the following official documentation on this section.
ASR Architecture
…and the following table gives a little context for each piece of the pie:
| Component | Requirement | Details |
|---|---|---|
| Azure | An Azure subscription, Azure Storage account for cache, Managed Disk and Azure network. | Replicated data from on-premises VMs is stored in Azure storage. Azure VMs are created with the replicated data when you run a failover from on-premises to Azure. The Azure VMs connect to the Azure virtual network when they're created. |
| Configuration Server | A single on-premises machine. We recommend that you run it as a VMware VM that can be deployed from a downloaded OVF template. The machine runs all on-premises Site Recovery components, which include the configuration server, process server, and master target server. | Configuration server: Coordinates communications between on-premises and Azure, and manages data replication. Process server: Installed by default on the configuration server. It receives replication data; optimizes it with caching, compression, and encryption; and sends it to Azure Storage. The process server also installs Azure Site Recovery Mobility Service on VMs you want to replicate, and performs automatic discovery of on-premises machines. As your deployment grows, you can add additional, separate process servers to handle larger volumes of replication traffic. Master target server: Installed by default on the configuration server. It handles replication data during failback from Azure. For large deployments, you can add an additional, separate master target server for failback. |
| VMware Servers | VMware VMs are hosted on on-premises vSphere ESXi servers. We recommend a vCenter server to manage the hosts. | During Site Recovery deployment, you add VMware servers to the Recovery Services vault. |
| Replicated machines | Mobility Service is installed on each VMware VM that you replicate. | We recommend that you allow automatic installation from the process server. Alternatively, you can install the service manually or use an automated deployment method, such as System Center Configuration Manager. |
Replication Process
The following diagram outlines what the replication process from VMware to Azure looks like:
Replication data flow works as follows:
- VMs communicate with the on-premises configuration server on port HTTPS 443 inbound, for replication management.
- The configuration server orchestrates replication with Azure over port HTTPS 443 outbound.
- VMs send replication data to the process server (running on the configuration server machine) on port HTTPS 9443 inbound. This port can be modified.
- The process server receives replication data, optimizes and encrypts it, and sends it to Azure storage over port 443 outbound.
A few key points to be aware of are:
- RPO Thresholds – play no part in replication, but are instead meant to assist in monitoring, i.e. events are logged and raised to an admin if configured to do so.
- Recovery Point Retention – Maximum retention is 24 hours on Premium storage and 72 hours on Standard.
- App Consistent Snapshots – Configurable, can be between 1 and 12 hours. Snapshots are Standard Azure Blob Snapshots and are requested as a VSS snapshot by the mobility service running on the VM (more on this service later).
- Replication traffic to Azure storage it over public endpoints i.e. over the internet or using ExpressRoute
NOTE: Replication over a VPN gateway is not supported.
Failover and Failback Process
The following diagram outlines what a failback from an Azure replication infrastructure to On-premises looks like:
A few key points to be aware of are:
- You can create recovery plans for failover, these include the ability to:
- Model out what a failover looks like, including which VMs are included, the order they come up etc.
- Run scripts or runbooks or pause to allow manual intervention for additional tasks to be completed.
- To allow failback to on-premises after a DR invocation, a temporary process server is required to replicate changes FROM Azure.
- A VPN connection or ExpressRoute is required to failback to on-premises as connectivity is required between your Azure Virtual Network and on-premises network.
- Failback happens in the following 3 stages:
- Re-protect the Azure VMs so that they replicate from Azure back to the on-premises VMware VMs.
- Run a failover to the on-premises site.
- After workloads have failed back, you re-enable replication for the on-premises VMs.
Although that’s a very high level overview of how ASR works, there will be additional context on each piece of the puzzle as we work through the guide. With that in mind before putting any DR solution in place, you’ll want to plan it thoroughly…enter the ASR Deployment Planner Tool