If you would like to be notified when Nirmal Sharma releases the next part of this article series please sign up to the WindowsNetworking.com Real time article update newsletter.
The Hyper-V Replica is designed to replicate virtual machine’s changed contents to the Replica Server. In case of any planned and unplanned failovers and when you start the replica virtual machine on the Replica Server, you are provided with the backup copies to recover virtual machine and application data. There are two backup copies provided by Hyper-V Replica; “Standard Backup copy” and “Application-Consistent Backup copy”. These backup copies are sometimes referred to as “recovery points”. The “Standard Backup copy” is a ‘point-in-time’ copy of the virtual machine VHD files which is generated by the Primary Server. “Application-Consistent Backup Copy” is created by the Hyper-V VSS writer, which is basically a VSS snapshot of the volumes inside the virtual machine. These backup copies are sent to the Replica Server when replication interval expires. You apply standard backup copies to recover virtual machine’s storage and application consistent snapshot copies are used to recover application data.
Hyper-V Replica does not know what is running inside a virtual machine. For example, you could have an active directory domain controller running or you might have deployed a database application in a virtual machine. Essentially, there are two types of applications which can be hosted in a Hyper-V replica environment; applications which are aware of VSS technology and applications which are not aware of VSS technology. The VSS-aware applications provide their own VSS writer. The Application VSS writer works with the Hyper-V VSS writer to take a consistent snapshot of the volumes inside the virtual machine. This consistent copy is then sent to the Replica Server when the replication interval expires. There are some disadvantages associated when hosting the applications which are not aware of the VSS technology. Since applications do not have a VSS writer, you could see an inconsistent application snapshot being sent to the Replica Server.
You can host any application which utilizes VSS technology so application-consistent snapshots, created by the Hyper-V VSS writer, can be used to recover the application data. But it is not always necessary that your applications have to have a VSS Writer before they can work in the Hyper-V Replica environment. There are a few applications which work differently and do not really have to be VSS-aware. For example, active directory technology does not have to be VSS aware to run in the Hyper-V replica environment. Instead of explaining every application as to how they operate in the Hyper-V Replica environment, I will choose to explain how active directory virtual domain controllers operate in Hyper-V replica environment.
As part of the Active Directory disaster recovery design, we host at least one domain controller in the disaster recovery site. In case of any failures with the production site domain controllers, users can authenticate against domain controllers available in the disaster recovery site. This is the common design seen for midsized to large organization IT environments.
The first question is to ask why you would want to host a domain controller in a Hyper-V Replica environment if a domain controller is already a highly available application. In other words, a domain controller has a built-in replication engine which keeps the Active Directory database synchronized to other domain controllers running in both production and disaster recovery sites. Any domain controller, which has an updated copy of the Active directory database, can provide authentication and authorization services. So does it make sense to enable Hyper-V replica for virtual domain controllers? Actually, it makes sense in two cases:
- Since the virtual domain controller hosted in the Replica Server is always “turned off”, you can utilize system resources of Hyper-V Replica server to host other virtual machines.
- Domain controllers running Windows Server 2012 and later operating systems understand very well te Hyper-V replica technology and its Planned and Unplanned failover options.
Microsoft introduced VM-GenerationID (VMGenID) which provides a way for Hyper-V Host to communicate to the guest operating systems when significant changes have occurred. For example, Hyper-V host can communicate to a virtualized domain controller running Windows Server 2012 and later versions whenever a hypervisor operation occurs. Once the virtual domain controller receives this communication from Hyper-V host, it needs to take an action which is in favor of the active directory database.
To better illustrate the case of a domain controller participating in Hyper-V replica Planned/Unplanned failovers, let’s assume you have two domain controllers running in the same site and these two domain controllers are the direct replication partners. Domain controllers VMDC1 and VMDC2 are running on the Primary Site whereas VMDC2-Copy is a replica copy of VMDC2 which is running on the Replica Site.
This is what happens when a failover (Planned or Unplanned) takes place for a domain controller running Windows Server 2012 or later versions:
Hyper-V Replica “Planned Failover” for Windows Server 2012 or later versions:
- Virtual administrator enables replication for VMDC2 on Primary Site.
- As part of the replication, a copy of VMDC2 is created on the Replica Site.
- VMDC2 running on Primary Site is shut down and a failover is performed to the VMDC2-Copy running on the Replica Site.
- After VMDC2-Copy starts on the Replica site, it checks the value of VMGenID that it has in its database.
- VMDC2-Copy resets its InnovcationID, discards its RID Pool, and sets an initial synchronization requirement before it can resume the operation.
- VMDC2-Copy saves the new value of VMGenID in its database and commits any new updates it received from a partner domain controller or done by an administrator locally.
- Since the InnovocationID is reset, VMDC1 will respect the changes made by VMDC2-Copy and any new updates will be successfully replicated to the VMDC1 which is running on the Primary site.
Hyper-V Replica “Unplanned Failover” for Windows Server 2012 or later versions:
In case of “Unplanned Failover”, VMDC2 will not have a chance to replicate the changes it received from VMDC1. It is because the Unplanned Failover occurs when there is a disaster with Primary Site or VMDC1. In case of disaster, VMDC2-Copy will not know about the changes and as a result the changes will be lost.
The following steps help you understand when a planned or unplanned failover is initiated for Windows Server 2008 R2 or earlier versions in Hyper-V Replica environment.
Hyper-V Replica “Planned Failover” for Windows Server 2008 R2 and earlier versions:
If you’re running an earlier version of the virtual domain controller (Windows Server 2008 R2 or earlier), since the 2008 R2 or earlier versions AD replication engine does not understand VMGenID technology, it places these domain controllers at the risk of USN rollback. The following example illustrates what happens when a Planned Failover is triggered for Windows Server 2008 R2 and earlier virtual domain controllers:
- VMDC1 and VMDC2 are running Windows Server 2008 R2 or earlier versions.
- VMDC2 is shut down and a planned failover is performed on VMDC2-Copy. All data on VMDC2 is replicated to VMDC2-Copy before the shutdown is complete.
- Since VMDC2-Copy does not understand VMGenID, after VMDC2-Copy starts, it resumes replication with VMDC1 using the same invocationID as DC2.
“Unplanned Failover” for Windows Server 2008 R2 and earlier versions is not a risk if you’re running only one domain controller in a single Active Directory forest but this is not supported by the Microsoft PSS Team.
Summary
You learned how VMGenerationID technology helps you host virtual domain controllers running Windows Server 2012 and later versions without worrying about USN rollback. While you can successfully host virtual domain controllers running Windows Server 2012 and later, but there is a little risk USN rollback associated with Windows Server 2008 R2 and earlier virtual domain controllers.
In the next part of this article series, I will show you how to host active directory domain controllers in a Replica environment and how virtual domain controllers can handle the different failover actions explained in this part of the article series.
If you would like to be notified when Nirmal Sharma releases the next part of this article series please sign up to the WindowsNetworking.com Real time article update newsletter.
