Traditionally, in an on-premises environment we setup stretch clusters across regions to protect against region failure. Microsoft came up with Azure Site Recovery to give users the the capability to move their workloads into Azure during a site or workload down situation. In this article, we are going to talk about an alternate approach to protecting your workload if you have a Hyper-V Cluster. I will have a follow up article in which I will go into details regarding this approach.
With the new nested virtualization capabilities that have been added to Azure, it allows us to run Hyper-V on top of an Azure VM.
Learn more about Hyper-V nested virtualization.
The new series Dv3 and Ev3 allows us to run Hyper-V on them.
Here I have created a D4sV3 VM on which I installed Hyper-V. Also, the network on which the VM is placed is under my EXPRESSROUTE circuit. An on-premise environment consists of a two node Hyper-V Cluster managed by SCVMM 2016.
Now we can take two approaches to migrate our workloads in Azure.
- Either create a new cluster on Azure and migrate your VM from on-prem cluster to one in Azure.
- Add the Azure VM to the existing Cluster and setup a storage spaces cluster on Azure.
Approach 1:
Approach 1 is straight forward. We add the VM to the domain and then create a cluster in Azure. You can add an additional DC in Azure that can manage the DNS. Since we have Express Route connectivity between the locations, connectivity should not be a concern.
We can migrate the VM with the storage, sharing no information during the migration, on to the different cluster. We can also setup a replica broker role on both clusters and then start the Hyper-V replica for the VM On-premises. Depending on which Express Route Bandwidth you choose, replication may take some time. It took around 20 minutes for my 40 GB ubuntu VM to be replicated into Azure.
Hyper-V host on Azure shows up during VM migration.
VRHYP is the cluster on-prem and VRHYP2 is the one in Azure. This gives you the capability to have a Hyper-V as a service 
.
Ubuntu VM migrated into Azure and running seamlessly.
If required, you can always failback to the on-prem cluster.
Approach 2:
In Approach 2 we add the VM to the existing Hyper-V cluster and manage it with SCVMM. This approach will follow the standard stretched cluster without stretched VLAN, as that is not possible in Azure.
We have deployed the same logical switch across to the Hyper-V running in Azure. We can go in deeper in this scenario and create another VM and setup Hyper-V on that. Once we have the two nodes up we can add data disk to the nodes and create Storage Spaces Direct.
Learn more about S2D implementation on Azure.
Storage Spaces Direct can be set with different resiliency levels including 2x, 3x, or parity. At least 4 nodes are required to get parity, but you can go for two nodes if you are just getting started.
We must make sure that the CSV volume that we create is the same size of what we have on-prem. Now we will use the Storage Replica feature that is available with Server 2016. This way we will keep the replica copy of the CSV volume we have on-prem into Azure via ExpressRoute.
Learn more about Storage Replica Server 2016.
We performed this action so that if the on-prem cluster fails, the VM can seamlessly start on Hyper-V hosted on Azure. This way we do not have to depend on a third-party tool for storage replication.
In the end, I would suggest that this is an alternate approach to Azure Site Recovery. This approach gives you more control over the VM migration scenarios, but you are limited to Server 2016 and Hyper-V.
Vinayak Rattan
Partner Technical Consultant