Many system administrators consider VM-level availability adequate for in-guest workload resiliency. If a host fails, detection mechanisms can be deployed to restart the downed VMs on another server. A normal outage window for these events could be just a matter of minutes. See the upcoming sections for more information.
However, many in-guest, application-level SLAs are more stringent than what host-level methods can provide for a VM. Many application owners will supplement VM-level availability with application-level availability features. For instance, some of the Microsoft SQL Server availability features include Always On Failover Cluster Instances (FCIs), Always On Availability Groups (AGs), and log shipping. This paper is not the place to debate which method(s) will be used in your environment; you need to determine the architecture for each deployment.
Hyper-V contains availability features designed to improve the availability of VMs. These include Quick Migration, Live Migration, Hyper-V Replica, and Hyper-V Storage Replica. The first two are more for high availability and the last two are more disaster recovery focused.
All of these options are different from what an application provides and the discussion of what to use in your organization is outside the scope of this paper. It is not an “either/or” situation – sometimes it is best to use platform-level options, other times what is available inside the VM, or you could combine them.
Features such as Live Migration require the proper number of hosts to ensure no single points of failure. This topic will be discussed in more depth in the topic “Anti-Affinity”. One of the important aspects of Live Migration is that there is no downtime to what is running in the VM. Live Migration allows administrators to proactively move a VM from one host to another in advance of a known operation, such as host-level patching. Other times, the cluster will detect a host failure and attempt to restart the VMs that were on the downed host, all of which are now offline, onto the remaining hosts in the cluster and bring them back into service. That is Quick Migration.
Live and Quick Migration can complement, but are not replacements for, a proper availability strategy for an application.
Another feature is Hyper-V Replica. It creates a standby copy of a VM as a continuously replicated stream over the network to a powered-off VM clone on a different Hyper-V host. This host can be at the same datacenter or a completely different site and host for off-site replication. Once the initial copy is replicated, the feature then continuously replicates changes in the virtual disks to keep the destination copy up to date with the source VM as shown below.
Microsoft has free training on Hyper-V Replica entitled “Implement Hyper-V Replica”.
Hyper-V Storage Replica is a software-based feature similar to Pure’s array-based replication and requires a WSFC. The replication technologies inside the FlashArray include synchronous ActiveCluster, continuously replicated ActiveDR, and ad hoc or scheduled asynchronous Protection Group snapshot replication. The simple configuration, management, and rich feature set, make these features that are built-in to the FlashArray the best choice for replicating between physical and virtual FlashArrays. Not every business use case has access to a FlashArray for a replication target, which is where a Storage Replica could be considered.
Storage Replica enables replication of storage volumes between servers for disaster recovery purposes, both in a single datacenter and across datacenters to different physical sites, as shown below Storage Replica can replicate either synchronously or asynchronously so that you can match the configuration to the RPO of a given data platform. This replication is one layer beneath the virtual machine layer and replicates all VMs for the storage volumes that take advantage of this feature.