These days, I try to be involved in any Containers, DevOps, Automation, etc. related discussion. Part of my role is to consult my customers around how to architect their containers platform and orchestration tools in Azure. But what happens when you have a chance to do something cool like architecting a solution which involves Mesosphere DC/OS, Azure Container Service, Azure Container Registry, Docker and VMware vSphere?! Let’s find out…
In the last part for this series, we will tie up all the loose ends after a successful ASR Unplanned Failover.
Now that we have our north Europe Classic VM replicated to west Europe storage account, it is time to hit the unplanned failover button and see what’s happening.
In this post we will configure the Classic VM replication scenario and initiate the synchronization between our sites.
In this post we will create the West Europe Resource Group, storage account and VNet which will be used as the “target” infrastructure for the replicated Classic VM.
In this post we will install the Mobility Service agent on our Classic VM and touch on the networking challenges we have with this design.
The Process Server is the most important component in a deployment like ours. It is the one responsible for handling all compute and IO intensive aspects of replication and maintaining replication policies, replication status and health reports.
About two weeks ago, Azure Site Recovery (ASR) V2 was released to preview. Using the “Unplanned Failover” we can perform ASM (Classic / V1) VM to Azure Resource Manager (ARM) VM conversion.