Hyper-V Replica is designed to replicate a virtual machine's content from a primary server to a replica server...
running in the disaster recovery site. In case of any disaster, the virtualized workload is brought online at the replica site manually. Hyper-V Replica tracks the changes on the VM's virtual hard disk files and replicates the changed contents every five minutes in Windows Server 2012 and every 30 seconds, five minutes or 15 minutes in Windows Server 2012 R2. It doesn't provide high availability like Windows Failover Clustering, but it still makes sure to provide availability of VM data by replicating the changed contents. This article explains benefits of using Hyper-V Replica for applications and the type of applications which can be hosted in a Hyper-V replica environment.
Pros and cons of hosting applications in Hyper-V Replica
The major advantage of hosting applications in a Hyper-V Replica environment is that it provides the ability to recover your application data with application-consistent snapshot copies. However, this approach might not work for all the applications.
Hyper-V Replica can create standard backup copies of VM storage, which helps you recover other operating system (OS) components of a VM. For example, if you apply a Windows update to the primary VM and that update causes some OS components to behave abnormally, you can recover from such failures by restoring to a recovery point that Hyper-V Replica created based on VM storage.
Because the replica copy of a VM is always "turned off," you can utilize the replica server resources to run other VMs.
The major disadvantage of Hyper-V Replica is that it can only support replication of contents every five minutes in Windows Server 2012 and every 30 seconds, five minutes or 15 minutes in Windows Server 2012 R2. That means if the data is not replicated within the interval specified and if the primary VM crashes, the application will lose the data. Application-consistent snapshots can only be created once every hour and sent to the replica VM based on the schedule set above.
Can I host all applications in Hyper-V Replica?
The short answer to this question is that it depends on the characteristics of the application. Hyper-V Replica does not know what is running inside a VM. A VM could be running with a SQL instance or Exchange Server or you might have deployed an Active Directory domain controller in the VM. Deciding whether to host an application in a Hyper-V Replica environment depends on the characteristics of an application. Let's consider a few examples to determine what types of applications should be backed up by Hyper-V Replica.
Case 1: An application that provides a built-in mechanism to replicate the data and can recover from data failures automatically: If an application possesses these characteristics, then I think it is a good practice to exclude such applications from Hyper-V replication because Hyper-V Replica's main job is to provide replication services and help in recovering VM storage and application data. If an application can replicate its data by using its own mechanism and can recover from data failures automatically, then it makes no sense to use Hyper-V Replica for such applications. But consider the fact that Hyper-V Replica also provides the standard backup copies to recover from OS failures -- you might want to enable Hyper-V replication for such applications if you want additional protection from OS failures.
Case 2: An application that does not have a built-in mechanism to replicate the data and includes no mechanism to recover from data failures: In this case, it's a good opportunity to consider replication. Hyper-V Replica plays a major role for applications with these characteristics. Because Hyper-V Replica provides application-consistent snapshots for application data, you are allowed to recover application data. You could have two types of applications running in this category: VSS-aware applications and non-VSS-aware applications. If an application is VSS-aware and is hosted in a Hyper-V Replica environment, the application VSS writer and the Hyper-V VSS writer work with each other to ensure the data is not lost. On the other hand, if you run a non-VSS-aware application in a Hyper-V Replica environment that does not have its own VSS writer, it may result in data loss. If the application has data in the memory and it cannot commit the memory data to the disk, an inconsistent application snapshot will be created and sent to the replica server. Because the backup copy is not consistent, it cannot be used to recover application data.
Case 3: An application that understands planned and unplanned failovers of Hyper-V Replica: In this case, the application can be deployed safely in the Hyper-V Replica environment. For example, SQL Server is supported in Hyper-V Replica as long as you follow steps explained by Microsoft. Similarly, Active Directory domain controllers running Windows Server 2012 and later understand Hyper-V Replica technology and are supported for different Hyper-V Replica failover options.
Hyper-V Replica is unaware of what is running inside a VM and simply replicates the changed contents to the replica server. The decision for implementing an application in a Hyper-V Replica environment depends on whether an application can communicate with the Hyper-V VSS writer. Applications should also take necessary actions when application-consistent snapshot copies are created by the Hyper-V VSS writer. If an application keeps the data in the memory and does not understand VSS technology, then an inconsistent application snapshot will be sent to the replica server, which you cannot rely on to recover your application data.