What’s New in Windows 8 for Hyper-V Based Cloud Computing (Part 11) - Hyper-V Disaster Recovery Scenarios
If you would like to read the other parts in this article series please go to:
This article is the final one of an 11 part series that provides a comprehensive look at the new features in Windows Server 2012 and Windows 8 client that support virtualization and cloud computing.
Hyper-V Replica Disaster Recovery Scenarios
Hyper-V Replica supports four main disaster recovery scenarios for private, hosting, and cross-premise environments. The private environment scenarios consist of setting up replicas between a main corporate office and a branch office, and also between enterprise datacenters. The hosting scenario involves configuring replicas between hosting provider datacenters that support multiple clients. Finally, the cross-premise scenario consists of setting up replicas between a corporate office and a hosting provider datacenter that supports multiple clients.
In all of these cases, Hyper-V Replica supports planned and unplanned disaster recovery solutions. Planned disaster recovery includes regular disaster recovery test and validation, support for site maintenance, and impending disasters such as in the case of an incoming hurricane. For these events, a controlled cutover of the primary virtual machines to the Replica sites can be effected without data loss. Unplanned disaster recovery occurs in the case of unpredictable events that take the primary virtual machines offline. For these events, an automated cutover to the Replica sites may be effected with some data loss and the replica virtual machines starting from the last successful replicated recovery point.
Main Corporate Office and Branch Office Scenario
Organizations with a main corporate office and multiple, geographically dispersed branch office locations tend to centralize certain critical applications at the main site. These applications are usually accessed by branch office sites through a WAN link. Critical applications can include SQL Server instances, IIS websites, System Center applications, line of business (LOB) applications, or many other core applications. Generally, applications are centralized at the main site because of budget limitations, or due to facilities and/or IT staff limitations at the branch office sites. Without a disaster recovery plan to mitigate the problem, if the main site becomes inaccessible because of a network connectivity issue, physical server failure, or physical facility failure, the branch office locations can incur a serious business impact because they can no longer access the critical applications that they need to conduct daily operations. However, by using Windows Server 2012 Hyper-V to deploy critical applications in virtual machines at the main corporate site, and by replicating the virtual machines with Hyper-V Replica to key branch office sites, an efficient and cost-effective disaster recovery plan is possible within the budgets of even small to medium size companies.
The implementation of this type of disaster recovery scenario includes the following basic steps:
- Deploy Windows Server 2012 Hyper-V at the main corporate site and branch office sites
- Virtualize critical applications at the main corporate site on Windows Server 2012 Hyper-V (possibly a failover cluster to concurrently implement high-availability)
- Define whether to use Kerberos (AD domain membership or trusts required) or certificate-based (different or no common AD domain membership support, or encrypted replication requirement) authentication between primary and replica servers
- Configure one or more Windows Server 2012 Replica Servers at selected branch office sites
- Enable replication between the primary virtual machines running at the main corporate site and the selected Replica Servers at the branch office sites
- Perform the initial replication of the primary virtual machines to the selected Replica Servers
- Perform a test failover of each primary virtual machine to validate the ability to successfully cutover to the selected branch office sites
- Configure Hyper-V Replica at the main corporate site to validate a reverse replication path for the primary virtual machines
- Perform a planned failover of each primary virtual machine to the selected Replica Servers and validate the reverse replication path for the primary virtual machines
- Perform test migrations of the primary virtual machines in failover cluster environment to validate that replication continues after either server or storage migrations (Hyper-V Replica Broker configuration required)
A test failover does not require a scheduled outage because the primary virtual machine continues to execute and replicate to the Replica virtual machine during the test event. This option is provided with Hyper-V Replica to create a new, duplicate test virtual machine for the purpose of verifying that a recovery point is able to start successfully, and that the test replica virtual machine works correctly. The new test virtual machine is created with the same name as the primary virtual machine with the addition of Test added to the end of the name. As an example, for a primary virtual machine named VM1, the new test virtual machine is named VM1-Test. Since the new test virtual machine is created on the same Hyper-V server as the primary virtual machine, the network configuration of the new test virtual machine is disconnected so that it does not interfere with the running primary virtual machine. You should connect the new test virtual machine to an isolated network in order to perform reverse replication or other verification tasks.
A planned failover requires a scheduled outage because the primary virtual machine must be shut down to ensure that there is no data loss. After the primary virtual machine is shutdown, the latest Hyper-V Replica log is sent to the Replica Server, and you perform a controlled cutover to the Replica Server. During a planned failover, reverse replication path validation takes place and the Replica virtual machine is started and remains running until you perform a planned failover back to the primary virtual machine.
Enterprise Datacenter Scenario
The enterprise datacenter scenario fits companies that tend to have multiple datacenters dispersed in key geographic locations at which they host critical applications. The enterprise datacenter is usually a secured access, temperature-controlled environment with robust network connectivity able to host a significant amount of computing resources with onsite redundancies. However, this does not negate the need for a good disaster recovery plan. Just as in the case of the main corporate site scenario, critical applications running only in a single datacenter can become a single point of failure and cause a major impact to enterprise business operations, if the datacenter goes offline.
Implementing a disaster recovery plan for the enterprise datacenter scenario follows the same basic outline as for the main corporate office / branch office site scenario, with the exception that the complexity and scale of the deployment are of much greater importance. In an enterprise datacenter scenario, there are generally a very large number of virtual machines that need to be replicated across multiple enterprise datacenters to ensure continued business operations. In addition, it is common place for large failover cluster deployments to exist in enterprise datacenters, adding complexity to the Hyper-V Replica configuration with a requirement to deploy a Hyper-V Replica Broker. Specifically, a Hyper-V Replica Broker provides two main functions. First, it provides a primary virtual machine server with a Replica Server name on the Replica cluster for initial placement. Secondly, it provides a primary virtual machine to Replica Server mapping so that replication can continue successfully in the case of virtual machine or storage migrations on the Replica side.
Hosting Provider Datacenter Scenario
A hosting provider datacenter scenario is similar to an enterprise datacenter scenario with the difference that hosting virtual machines from different tenants imposes broader isolation requirements that may not always exist in the enterprise. The implementation of a disaster recovery plan in this scenario requires stringent network and security isolation procedures, as well as a detailed plan to define the location of Replica Servers that provide the various tenants with access that meet their specific SLA agreements.
In addition to permanently hosting virtual machines for different tenants in a host datacenter, a service that hosting providers can offer is to become a disaster recovery location for corporate-based resources. In this scenario, certificate-based authentication must be used as Hyper-V Replica is leveraged across different Active Directory forests and domains (i.e., primary virtual machine in customer forest/domain and replica virtual machine in untrusted hosting provider forest/domain). With certificate-based authorization, data that is replicated between the primary site and replica site is encrypted.
On the hosting provider side, it is possible that replica virtual machines from different tenants are hosted on the same set of failover cluster nodes requiring a means to isolate them from each other for replication security and integrity. Hyper-V Replica supports isolation of virtual machine replicas through the use of a security tag. This security tag is a plain text field that functions like a VLAN tag used to isolate network traffic across a switch. In Hyper-V Replica, the security tag allows the creation of trust zones that segregate the primary and replica server sets between which replication is authorized to take place for a specific virtual machine.
In this final article of the 11 Part series, you learned about disaster recovery scenarios enabled out-of-box with the Windows Server 2012 Hyper-V Replica feature. It should now be evident that Hyper-V Replica provides support for common disaster recovery and business continuity scenarios across the spectrum of enterprises within or across cloud environments, and without the expense or integration of third-party solutions.
If you would like to read the other parts in this article series please go to: