Windows Server 2012 Hyper-V Role introduces a new capability, Hyper-V Replica, as a built-in replication mechanism at a virtual machine (VM) level. Hyper-V Replica can asynchronously replicate a selected VM running at a primary site to a designated replica site across LAN/WAN. The following schematic presents this concept.
Here both a primary site and a replica site are Windows Server 2012 Hyper-V hosts where a primary site runs production or the so-called primary VMs, while a replica site is standing by with replicated VMs off and to be brought online, should the primary site experiences a planned or unplanned VM outage. Hyper-V Replica requires neither shared storage, nor a specific storage hardware. Once an initial copy is replicated to a replica site and replication is ongoing, Hyper-V Replica will replicate only the changes of a configured primary VM, i.e. the deltas, asynchronously.
Establishing Hyper-V Replica Framework
Once all the requirements are put in place, first configure a target replica server, followed by configure an intended VM at a primary site for replication. The following is a sample process to establish Hyper-V Replica:
Step 1
Identify a Windows Server 2012 Hyper-V host as the replica site and enable Hyper-V Replica in the Hyper-V settings on the host in Hyper-V Manager. The following are Hyper-V Replica sample settings of a replica site, Development.
Step 2
Using the Hyper-V Manager of a primary site, right-click an intended VM to enable Hyper-V Replica by walking through the wizard to establish a replication relationship. Below shows how to enable Hyper-V Replica of A-Selected-VM at the primary site, VDI.
Step 3
As applicable, carry out the initial replication of a target workload. If an initial copy is to be sent out over the network, this will happen in real-time or according to a schedule at the end of step 2.
Step 4
Conduct a Test Failover event from the replica site by right-clicking the replicated VM and select the option to confirm the readiness of accepting a replication request and process the traffic.
Step 5
Conduct a Planned Failover event from the primary site after shutting down an intended source VM as shown below.
The following information returns upon a successful execution a Planned Failover event of A-Selected-VM from a primate site where VDI as the source Hyper-V host to a replica site where Development as the destination host, for example.
Notice that successfully performing a Planned Failover will automatically establish a reverse replication relationship where then the before replica site (Development) becomes the current primary site and the before primary site (VDI) becomes the current replica site and start the primary VM. The Replication Health, accessible by right-clicking a VM with Hyper-V Replica enabled in Hyper-V Manager, reveals the current replication relationship. The following shows Replication Health information of the VM, VDI, before and after successfully performing a planned failover with a reverse replication relationship automatically set.
In the event that a source VM experiences an unexpected outage at a primary site, it is necessary to manually start the replicated VM at the replica site, while in this scenario a reverse replication relationship will not be automatically established due to some un-replicated changes may have lost along with the unexpected outage.
Step 6
Conduct another Planned Failover event to confirm that the reverse replication works. In the presented scenario, the planned failover will be now from Development back to VDI. And upon successful execution of the planned failover event, the resulted (i.e. reversed) replication relationship should be VDI as a primary site with Development as the replica site. Which is the same state at the beginning of step 5.
Step 7
1. Test Hyper-V Replica against VM mobility scenarios including Live Migration of Hyper-V Replica-enabled VMs and related storage among cluster nodes, SMB 3.0 shares, file servers, etc. This is where network virtualization (presented later in this book) becomes critically needed to provide transparency of network configurations at a VM level to minimize the technical complexities of relocating a VM or its associated storage.
Step 8
Incorporate Hyper-V Replica configurations and maintenance into applicable corporate IT standard operating procedures and start monitoring and maintaining the health of Hyper-V Replica resources.
Asynchronous Replication of Changes
The replication process will replicate, i.e. create an identical VM in the Hyper-V Manager of the replica server and subsequently the change tracking module of Hyper-V Replica will track and replicate the write-operations in the source VM every a few minutes after the last successful replication regardless the associated vhd files are hosted in SMB shares, Cluster Shared Volumes (CSVs), SANs, or with directly attached storage devices.
Hyper-V Replica Cluster
Importantly, if to employ a Hyper-v failover cluster as a replica site, must use Failover Cluster Manager to perform all Hyper-V Replica configurations and management. And first create a Hyper-V Replica Broker role, as demonstrated below.
A Hyper-V Replica Broker is the focal point in this case. It queries the associated cluster database to realize which node is the correct one to redirect VM specific events such as Live Migration requests in a replica cluster.
Windows Active Directory domain is not a requirement for Hyper-V Replica which can also be implemented between workgroups and untrusted domains with a certificate-based authentication. Active Directory is however a requirement if involving a Hyper-v host which is part of a failover cluster, and in such case all Hyper-V hosts of a failover cluster must be in the same Active Directory domain with security enforced at the cluster level.
Business Continuity and Disaster Recovery (BCDR)
In a BC scenario and a planned failover event of a primary VM, Hyper-V Replica will first copy any un-replicated changes to the replica VM, such that the event produces no loss of data. Once the planned failover is completed, the replica VM will then become the primary VM and carry the workload, while a reverse replication is automatically set. In a DR scenario, i.e. an unplanned outage of a primary VM, an operator will need to manually bring up the replicated VM with an expectation of some data loss, since changes of the primary VM not yet replicated to the replicated VM have now been lost along with the unplanned outage.
No comments:
Post a Comment