Maintaining Business Continuity of Virtualized Environments with Hyper-V Replica: scenario overview
Updated: February 29, 2012
Applies To: Windows Server 8 Beta
[This topic is pre-release documentation and is subject to change in future releases. Blank topics are included as placeholders.]
This document briefly introduces the basic concepts involved in using Hyper-V Replica as a means to maintain business continuity for deployments of virtual machines through planned downtime (such as for maintenance) or unplanned downtime (such as in an emergency). It introduces a subtopic which walks you through setting up Hyper-V Replica and demonstrating its core use in a planned failover scenario.
Did you mean…
Increasing Server, Storage, and Network Availability: scenario overview
Hosted Cloud Platform Pillar Scenario
Scenario description
This scenario involves using Hyper-V Replica to provide business continuity for virtualized environments, preventing suspension of operations due to either planned events (such as hardware maintenance) or unplanned events (such as a local disaster or hardware failure).
For more general information about this scenario, see Windows Server 8 Overview.
Key concepts
In this scenario, we define two “sites”: the “primary site,” which is the location where the virtualized environment normally operates; and the “Replica site,” which is the location of the server that will receive the replicated data. At the primary site, the primary server is the physical server that hosts one or more primary virtual machines. At the Replica site, the Replica server similarly hosts the Replica virtual machines.
Once replication is configured and enabled, an initial copy of data from the primary virtual machines must be sent to the Replica virtual machines. We call this “initial replication” and you can choose to accomplish it directly over the network or by copying the data to a physical device and transporting that to the Replica site.
When replication is underway, changes in the primary virtual machines are transmitted over the network periodically to the Replica virtual machines. The exact frequency varies depending on how long a replication cycle takes to finish (depending in turn on the network throughput, among other things), but generally replication occurs approximately every 5-15 minutes.
You can choose to move operations on any primary virtual machine to its corresponding Replica virtual machine at any time, an action we call “planned failover.” In a planned failover, any un-replicated changes are first copied over to the Replica virtual machine, so no loss of data occurs. After the planned failover, the Replica virtual machine takes over the workload; to provide similar protection for the virtual machine that is now servicing the workload, you configure “reverse replication” to send changes back to the primary virtual machine (once that comes back online).
If the primary server should fail unexpectedly, perhaps as a result of a major hardware failure or a natural disaster, you can bring up the Replica virtual machines to take over the workload—this is “unplanned failover.” In unplanned failover, there is the possibility of data loss, since there was no opportunity to copy over changes that might not have been replicated yet.
In this scenario
This scenario currently comprises using Hyper-V Replica to maintain continuous operation of virtual machines, particularly in planned downtime situations. For much more information about Hyper-V Replica, including overviews of how it works and usage in other scenarios (such as unplanned downtime and with failover clusters), see the Understand and Troubleshoot Hyper-V Replica document (https://go.microsoft.com/fwlink/p/?LinkId=237258).
Practical applications
As system administrators increasingly take advantage of the resource savings and management advantages of virtualized deployments, methods of maintaining business continuity in those environments through expected and unexpected interruptions become even more important. A variety of technologies already exist that can assist with maintaining business continuity. However, these technologies come with limitations, such as requirements for specific hardware or the need for shared storage. Some solutions are feasible only for certain server workloads.
Hyper-V Replica provides asynchronous replication of Hyper-V virtual machines between two hosting servers. It is simple to configure and does not require either shared storage or any particular storage hardware. Any server workload that can be virtualized in Hyper-V can be replicated. Replication works over any ordinary IP-based network, and the replicated data can be encrypted during transmission. Hyper-V Replica works with standalone servers, failover clusters, or a mixture of both. The servers can be physically co-located or widely separated geographically. The physical servers do not need to be in the same domain, or even joined to any domain at all.
Hardware requirements
You can set up replication of Hyper-V virtual machines as long as you have any two physical Windows Server “8” Beta servers which support the Hyper-V role. The two servers can be physically co-located or in completely separate geographical locations. The Demonstrate Hyper-V Replica topic walks through step by step how to set up replication between two standalone Hyper-V servers using Kerberos authentication and then demonstrate test failover and planned failover between them. For additional steps required to configure Replica with failover clusters or certificate-based authentication, see the Understand and Troubleshoot Hyper-V Replica document (https://go.microsoft.com/fwlink/p/?LinkId=237258).
See also
This table contains links to related resources that explore other aspects of this scenario, including blogs and forums where you can find the most up-to-date information.
Content type | References |
---|---|
Product evaluation |
Windows Server 8 Overview| Understand and Troubleshoot Hyper-V Replica |
Planning |
|
Deployment |
|
Operations |
|
Troubleshooting |
|
Security |
|
Tools and settings |
|
Community resources |
Ben Armstrong’s Virtual PC Guy's WebLog| John Howard's Hyper-V and virtualization blog| Tony Soper's blog| Martin McClean's ThePosterGuy blog| Hyper-V Portal on the TechNet Wiki |
Related technologies |