Enabling Hyper-V Replica

Installation Considerations

Hyper-V Replica is implemented as part of the Hyper-V Role.  The Hyper-V Role can be enabled on a standalone Hyper-V server or on servers that are members of a Failover Cluster.  Hyper-V servers can function as members of a Workgroup or as member servers in the same or different Active Directory domains.   It is not required that Primary and Replica servers be part of the same Active Directory domain.  If the Hyper-V server role is enabled on servers that are members of a Failover Cluster, those servers must be joined to the same Active Directory domain. The Hyper-V server role can be enabled using the Server Manager console or the Deployment Image and Servicing Management (DISM) command line tool.  The Hyper-V role has no dependencies on any other server roles.  Installing the Hyper-V role also installs the Hyper-V Management interface, which is part of the Remote Server Administration Tools (RSAT) feature.

Deployment Scenarios

There are four primary deployment scenarios for Hyper-V Replica:

  • Head Office and Branch Office (HO-BO)
  • Enterprise Datacenter
  • Hosting Provider Datacenter
  • Customer Office and Hosting Provider Datacenter (Cross-Premise)
Head Office and Branch Office

rep3

This scenario typically involves Mid-Market customers who have a main corporate Head Office and one or more Branch Offices located in different physical locations. This type of customer typically has a limited budget for purchasing hardware, WAN connectivity, and hiring IT Staff.   As part of a cost saving initiative, a customer may decide to implement Microsoft virtualization technologies to migrate corporate applications running on physical hardware to virtualized workloads running on Microsoft servers running the Hyper-V role.  One or more of servers are hosted in the Head Office location either as standalone servers or as part of one or more Hyper-V Failover Clusters.

Management decides to implement a Disaster Recovery (DR) plan and deploys additional servers running the Hyper-V role (Hyper-V Failover Clusters) at one or more Branch Offices to function as Replica servers.  Using Microsoft’s Hyper-V Replica functionality, the customer implements a DR solution.  Implementing this DR solution involves these basic steps:

  1. Configure a Replica Server (Replica Failover Cluster) at one or more designated Branch Offices
  2. Create the replication relationships between the virtual machines running in the Head Office and the Branch Office(s)
  3. Perform the initial replication for all virtual workloads
  4. Perform a Test Failover on each virtual machine ensuring it will start on the Branch Office server(s)
  5. Configure the server(s) in the Head Office as Replica servers as part of a reverse replication strategy for the Branch Office Replica servers
  6. Execute a Planned Failover of all virtual machines to the Branch Office(s) to ensure all virtual machines come online properly (Note:  A Planned Failover requires a Virtual Machine be shutdown first resulting in an outage if it is a production workload)
  7. Execute another Planned Failover back to the Head Office from the Branch Office(s) to verify reverse replication
  8. Monitor replication for all virtual machines and generate reports as needed
  9. Test virtual machine mobility scenarios to ensure they function properly.  These scenarios can include live migration of virtual machines between cluster nodes, or migration of virtual machine storage between File Servers
  10. Test replication using virtual machines that have been restored from backup
  11. Modify corporate maintenance (Change Management) plans to include using Hyper-V Replica functionality
Enterprise Datacenter

The Enterprise Datacenter scenario is very similar to the Head Office and Branch Office scenario in terms of the actual steps an administrator executes to implement Disaster Recovery using Hyper-V Replica.  The main difference would be scale.  Enterprise environments typically include one, or more, large, geographically dispersed datacenters supporting a greater number of virtualized workloads running on more servers.  Additionally, enterprise environments may implement Third Party or ‘homegrown’ applications that take advantage of Hyper-V Replica APIs (Application Programming Interface) in an effort to streamline internal management processes.

Hosting Provider Datacenter

The Hosting Provider Datacenter scenario is very similar to the Enterprise scenario in terms of the actual steps an administrator executes to implement Disaster Recovery using Hyper-V Replica.  Hosting companies have additional concerns in that they are dealing with multiple customers (tenants) on a shared internal infrastructure.  This requires implementing stricter isolation policies within the datacenter and a billing system that can accurately track resource usage.

Customer Office and Hosting Provider Datacenter (Cross-Premises)

rep4

The Customer Office and Hosting Provider Datacenter (Cross-Premises) scenario takes the Hosting Provider Datacenter scenario one-step further in that Disaster Recovery is provided as a service (Infrastructure as a Service (IaaS)) to customers external to the hosting company itself.  This modifies the administrative process as follows:

  1. Hosting company configures a Replica Server (Replica Failover Cluster) in the Hosting company datacenter
  2. Hosting company develops a customer portal providing access to customers for tracking their services and adding services as needed
  3. Customer subscribes to hosting company disaster recovery service
  4. Hosting company provides required server and certificate information.  Customer creates the replication relationships between the virtual machines running in the customer environment and the designated Replica server(s) in the hosting company’s datacenter (using a secure Virtual Private Network (VPN) connection)
  5. Customer performs the initial replication or all virtual workloads
  6. Customer performs a Test Failover on each virtual machine ensuring it will start on the Replica server(s)
  7. Customer configures their server(s) as part of a reverse replication strategy on their own premise server(s)
  8. Customer executes a Planned Failover of all virtual machines to the hosting company datacenter Replica server(s) to ensure all virtual machines come online properly
  9. Customer executes another Planned Failover back to their on premise server(s) to verify reverse replication
  10. Customer monitors replication for all virtual machines and generates reports as needed
  11. Customer tests virtual machine mobility scenarios provided hosting company provides those services
  12. Customer and hosting company test replication using virtual machines that have been restored from backup
  13. Customer modifies maintenance (Change Management) plans to include using Hyper-V Replica functionality

 

Technical Overview of Hyper-V Replica

Prerequisites

To take advantage of the Hyper-V Replica, which is included as part of the Hyper-V server role, the following pre-requisites must be met:

  • Hardware that supports the Hyper-V Role on Windows Server 2012
  • Sufficient storage on both the Primary and Replica servers to host the files used by virtualized workloads
  • Network connectivity between the locations hosting the Primary and Replica servers
  • Properly configured firewall rules to permit replication between the Primary and Replica sites
  • An X.509v3 certificate to support Mutual Authentication with certificates (if desired or needed)

Functional Description

Administrators can use Hyper-V Replica to provide a virtual machine  level replication solution which efficiently replicates data over a LAN/WAN to a remote (Replica) site without relying on software or hardware technologies outside of the Windows Server 2012 operating system.  At a very high level (details to follow in the Architecture section), Hyper-V Replica is summarized in the following:

rep2

•    Replication Engine:  The Replication Engine, in many respects, is the ‘heart’ of Hyper-V Replica.  It manages the replication configuration details and handles initial replication, delta replication, failover, and test-failover operations. It also tracks virtual machine and storage mobility events and takes appropriate actions as needed (i.e. it pauses replication events until migration events complete and then resumes where they left off)

•    Change Tracking:  The Change Tracking module provides a virtual machine level change tracking mechanism on the primary server by keeping track of the write-operations, which happen in the virtual machine.  This component is designed in such a way that it makes the scenario work irrespective of where the virtual machine VHD file(s) resides (VHD files can be hosted on Direct Attached Storage (DAS), a SAN LUN, an SMB share on a File Server, or a Cluster Shared Volume (CSV)

•    Network Module: The Networking Module provides a secure and efficient (data compression by default) network channel to transfer virtual machine replicas between Primary and Replica site.  Network communications are built on top of HTTP\HTTPS protocols and support integrated as well as certificate-based authentication with optional support for encryption

•    Hyper-V Replica Broker role:  The Hyper-V Replica Broker role is configured in a Windows Server 2012 Failover Cluster. This functionality supports seamless replication even in the event of a migration of a replica virtual machine from one cluster node to another.  This is achieved by interacting with the Windows Server Failover Clustering (WSFC) service and the Hyper-V network module. The Hyper-V Replica Broker redirects all virtual machine specific events to the appropriate node in the replica cluster.  The Broker queries the cluster database to determine which node should handle which events.  This ensures all events are redirected to the correct node in the cluster in the event a Quick Migration, Live Migration or Storage Migration process was executed

•    Management Experience:   This includes the following components:

  • Hyper-V Manager UI: The replication settings are available in the Hyper-V Manager and provide an end-to-end experience for replication configuration, inbox monitoring, test failover, planned failover, unplanned failover and reverse-replication experiences
  • Failover Cluster Manager UI: When Primary or Replica servers are part of a Hyper-V Failover Cluster, all management for the virtual machines and the Hyper-V Replica configurations should be done from the Failover Cluster Manager interface
  • Scripting:  Hyper-V Replica functionality is integrated within the Hyper-V PowerShell Module
  • Hyper-V Replica APIs: These are part of the Hyper-V WMI interface. This interface can also be used by Third Party management software applications
  • Remote Management:  The Hyper-V Manager UI is included as part of the Remote Server Administration Tools (RSAT) that can be installed on supported Windows 8 Consumer Preview operating systems so administrators can remotely manage virtual machine replication

Security Considerations

There is no requirement for servers running the Hyper-V role to be part of an Active Directory domain unless those servers are part of a Failover Cluster.  If the servers are part of an Active Directory domain, then that is a defined security boundary, and it is the responsibility of the Domain Administrator to configure domain-level security policies to protect the domain and to allow Hyper-V to function properly.  Hyper-V Replica can also be implemented between un-trusted domains/workgroups.

Security in Hyper-V is implemented at the following levels:

  • Hyper-V uses a new Simple Authorization model where a Hyper-V Administrators group is created locally on each server running the Hyper-V role when the role is installed. The Authorization Manager is still present, and the Hyper-V Administrators group, along with members of the local administrators group in the server, is added by default
  • Hyper-V administrators can configure Replica servers to accept incoming connections from specific servers, thus restricting access, using a Fully Qualified Domain Name (FQDN) (e.g. P1.contoso.com) or by using a wildcard attached to a domain suffix (e.g. *.contoso.com).  If the Replica server is a Failover Cluster, security is enforced at the cluster level
  •  Firewall rules must be configured to allow incoming connections on the Hyper-V Replica servers for the designated port configured by the Hyper-V Administrator (Refer to Appendix B)
  • Mutual Authentication is accomplished by using Integrated Authentication in an Active directory environment (Kerberos) between trusted domains.  Certificates can be used outside of Active Directory. This would be common in an X-premise environment where a Hosting company is providing DR services to multiple tenants.  Additional security is provided by way of a Replication Authorization Tag.  Consider a scenario where a Hosting company is providing DR services to multiple Third Party Tenants (e.g. Contoso.com, Fabrikam.com and WoodgroveBank.com).  Each of these tenants is using the same Replica Cluster at the Hosting Company’s datacenter to host Replica virtual machines.  A Replication Authorization Tag (Security Tag in the UI) is used to prevent one company from gaining access to another company’s replica machines.

 

What Is Hyper-V Replica?

Hyper-V Replica is new functionality added to the Hyper-V Role in Windows Server 2012.  Hyper-V Replica enables organizations to implement an affordable Business Continuity and Disaster Recovery (BCDR) solution for virtualized workloads. This allows virtual machines running at a primary site to be efficiently replicated to secondary location (Replica site) across a WAN link. 

rep

Purpose/Benefits

Hyper-V Replica provides a storage-agnostic and workload-agnostic solution that replicates efficiently, periodically, and asynchronously over IP-based networks, typically to a remote site. Hyper-V Replica allows a Hyper-V Administrator, in the event of a failure at a primary site (e.g. fire, natural disaster, power outage, server failure etc…), to execute a failover of production workloads to replica servers at a secondary location within minutes, thus incurring minimal downtime.  The configurations at each site do not have to be the same with respect to server or storage hardware. Hyper-V Replica provides a System Administrator the option to restore virtualized workloads to a point in time depending on the Recovery History selections for the virtual machine.  Hyper-V Replica provides the necessary management APIs that enable IT management vendors to build an enterprise class Disaster Recovery (DR) solution for their customers. Hyper-V Replica enables Infrastructure as a Service (IaaS) for hosting providers that host dedicated/virtual servers for their customers. With Hyper-V Replica, Hosters can provide solutions that offer DR as a service to their customers (specifically Small and Medium Business (SMB) customers). 

Here is a list of terms that are relevant to the Hyper-V Replica functionality:

Term

Definition

Recovery Time Objective (RTO) The Recovery Time Objective (RTO) is the duration of time within which a business process must be restored after a disaster (or disruption) in order to avoid unacceptable consequences associated with a break in business continuity.  This can also be referred to in business terms as a Service Level Agreement (SLA)
Recovery Point Objective (RPO) The Recovery Point Objective (RPO) describes the acceptable amount of data loss measured in time
Application-consistent Replica Recovery to a point-in-time that is consistent from the application’s perspective.  To accomplish this, the Volume Shadow Copy Service (VSS) is used
Standard Replica A crash consistent replica of the primary virtual machine
Primary server The Hyper-V machine (Hyper-V Failover Cluster) that hosts virtualized production workloads
Replica  server The Hyper-V machine (Hyper-V Failover Cluster) that hosts the replica virtual machines for a Primary server
Planned Failover A Planned Failover is a controlled event where an Administrator gracefully moves a virtual machine from a Primary site to a replica site
Failover A Failover is an unplanned event where the Primary site experienced a problem and replica virtual machines had to be brought online at a replica site
Test Failover A process an Administrator executes on a replica virtual machine to verify it’s functionality