Export (0) Print
Expand All

Step 1: Prepare to Deploy Hyper-V Replica

Published: May 31, 2012

Updated: May 31, 2012

Applies To: Windows Server 2012, Windows Server 2012 R2



This topic helps you make the basic decisions required so that you can get Hyper-V Replica working for your particular situation as smoothly and quickly as possible. Because Replica is so simple and flexible, you can use it in a wide variety of deployment scenarios. Deciding on a few key factors ahead of time will allow you to quickly move through the Enable Replication wizard.

For further assistance in making detailed planning decisions for your unique deployment (such as what replication frequency would be best, predicting the network load generated by replication, and more, download and use the Capacity Planner for Hyper-V Replica from http://www.microsoft.com/en-us/download/details.aspx?id=39057.

 

Task Description

1.1. Make basic planning decisions

Make basic planning decisions.

1.2. Install the Hyper-V server role

Install the Hyper-V server role, if it is not already installed.

1.3. Configure the firewall

Configure the firewall, if the replication data will be crossing it.

1.4. Configure Hyper-V Replica Broker

Configure the Hyper-V Replica Broker, if the servers are part of a failover cluster.

1.5. Provide a certificate for encrypted data

Create a certificate for Replica to use, if the replication data should be encrypted.

noteNote
This topic includes sample Windows PowerShell cmdlets that you can use to automate some of the procedures described. For more information, see Using Cmdlets.

By deciding on a few basic parameters ahead of time, you can save some time when you run the Enable Replication wizard and ensure that your replication deployment will work perfectly from the start.

  1. Will both the primary and Replica servers be behind the same firewall? Because the Replica site is likely remote from the primary site, you should configure your firewall to allow replication data through. If the primary and Replica servers will be separated by a firewall, add Step 1.3 to your to-do list.

  2. Will either the primary or Replica server be part of a failover cluster? If so, Replica needs a NetBIOS name and IP address to use as a connection point to the cluster. To enable this, install Hyper-V on each node of the cluster and configure a Hyper-V Replica Broker role for the cluster. If a failover cluster is involved in replication, add Step 1.4 to your to-do list.

  3. Does the replication data sent between the primary and Replica servers need to be encrypted? To provide encrypted replication data transfer, Replica uses certificate-based authentication, so you must have or create an appropriate security certificate. For example, in any remote office or other cross-premises scenario, the data should probably be encrypted for security. However, if both the primary and Replica servers are physically co-located and are behind the same firewall, the built-in Kerberos authentication may be adequate.

    noteNote
    Kerberos authentication is only available when the primary and Replica servers are members of the same domain or in mutually trusted domains. Other scenarios require certificate-based authentication.

    If the transmitted replication data must be encrypted, add Step 1.5 to your to-do list.

  4. Which VHDs need to be replicated? VHDs that contain data that is rapidly changing and not used by the Replica server after failover, such as page file disks, should be excluded from replication to conserve network bandwidth. Make a note of which VHDs can be excluded from replication.

  5. How many recovery points do you need? You can configure Replica to store only the latest received replication data; the data on the Replica server is updated according to the replication frequency you configure. You can also configure Replica to maintain an additional one or more recovery points, which are created once approximately every hour. Having additional recovery points also allows you to recover virtual machine operations to an earlier point in time when you perform a failover. A maximum of 15 (24 in Windows Server 2012 R2) such recovery points is possible. Make a note of the number of recovery points you need.

  6. Do you need applications to remain consistent? The standard replication configuration maintains consistency in the state of the operating system of the replicated virtual machines after a failover, but not the state of applications that may be running in the virtual machine. To preserve the state of applications, you can choose to have Replica create additional application-consistent recovery points that use VSS on a set schedule. Make a note whether you need application-consistent recovery points.

  7. Decide on the initial replication method. To start replicating data, Replica needs to transfer the current state of the virtual machines. This initial state can be transmitted directly over the existing network, either immediately or at a later time that you configure. You can also use a pre-existing restored virtual machine on the Replica server (for example, if you have restored an earlier backup of the virtual machine on the Replica server) as the initial copy. Or, you can save network bandwidth by copying the initial copy to external media and then physically delivering the media to the Replica site. Make a note of the initial replication method you plan to use.

    noteNote
    If you plan to use a pre-existing virtual machine restored from backup as the source for the initial replication, delete all previous snapshots associated with the virtual machine before you enable replication and start the initial replication.

  8. (For Windows Server 2012 R2) Will you use extended replication? In extended replication, your Replica server forwards changes that occur on the primary virtual machines to a third server (the extended Replica server). After a planned or unplanned failover from the primary server to the Replica server, the extended Replica server provides further business continuity protection. Once you have completed Steps 1 through 5 to enable, configure, and test replication between the primary and Replica servers, see Step 6 for information about configuring and working with extended replication.

Hyper-V Replica is a feature of Hyper-V, so you must enable the Hyper-V server role if you aren’t already using it. Replica also requires virtual machines, so if you haven’t already done so, you need to create one or more. To enable the Hyper-V server role and create virtual machines, see Install Hyper-V and Configure a Virtual Machine.

Hyper-V Replica already includes firewall rules that will allow the replication data to pass through, but you do have to enable the appropriate exceptions. Follow the steps below depending on whether you plan to use Kerberos or certificate-based authentication on standalone (non-clustered) servers. If your servers are part of a failover cluster, run the Windows PowerShell cmdlets that follow the procedures on any node in the cluster to enable the firewall rules on all nodes in the cluster.

noteNote
The details of this step apply only to Windows Firewall. If you are using a non-Microsoft firewall, different steps may be required.

  1. Open Windows Firewall with Advance Security and click Inbound Rules.

  2. Right-click Hyper-V Replica HTTP Listener (TCP-In) and click Enable Rule.

  1. Open Windows Firewall with Advance Security and click Inbound Rules.

  2. Right-click Hyper-V Replica HTTPS Listener (TCP-In) and click Enable Rule.

For servers that are part of a failover cluster, run this Windows PowerShell cmdlet on any node in the cluster if you will be using Kerberos authentication for Replica. The cmdlet must be run by a user with administrative privileges.

get-clusternode | ForEach-Object  {Invoke-command -computername $_.name -scriptblock {Enable-Netfirewallrule -displayname "Hyper-V Replica HTTP Listener (TCP-In)"}}

For servers that are part of a failover cluster, run this Windows PowerShell cmdlet on any node in the cluster if you will be using certificate-based authentication for Replica. The cmdlet must be run by a user with administrative privileges.

get-clusternode | ForEach-Object  {Invoke-command -computername $_.name -scriptblock {Enable-Netfirewallrule -displayname "Hyper-V Replica HTTPS Listener (TCP-In)"}}

If you plan to use a failover cluster with Hyper-V Replica and haven’t already set up the cluster, see http://go.microsoft.com/fwlink/?LinkId=253006

Each node of the failover cluster that is involved in Replica must have the Hyper-V server role installed. If you haven’t already done so, refer to Step 1.2 in this topic and install the Hyper-V role on each cluster node.

Finally, configure the Hyper-V Replica Broker for the cluster with the following steps.

  1. In Server Manager, open Failover Cluster Manager.

  2. In the left pane, connect to the cluster, and while the cluster name is highlighted, click Configure Role in the Actions pane. The High Availability wizard opens

  3. In the Select Role screen, select Hyper-V Replica Broker.

  4. Complete the wizard, providing a NetBIOS name and IP address to be used as the connection point to the cluster (called a “client access point”). The Hyper-V Replica Broker is configured, resulting in a client access point name. Make a note of the client access point name for configuring Replica later on.

  5. Verify that the Hyper-V Replica Broker role comes online successfully and can fail over between all nodes of the cluster. To do this, right-click the role, point to Move, and then click Select Node. Then, select a node, and then click OK.

PowerShell Logo Windows PowerShell equivalent commands

The following Windows PowerShell cmdlet or cmdlets perform the same function as the preceding procedure. Enter each cmdlet on a single line, even though they may appear word-wrapped across several lines here because of formatting constraints.

This example sequence of cmdlets will create a Hyper-V Replica Broker names “HVR-Broker” that uses the static IP address 192.168.1.5. All steps must be completed by a user with administrative privileges.

$BrokerName = “HVR-Broker”
Add-ClusterServerRole -Name $BrokerName –StaticAddress 192.168.1.5
Add-ClusterResource -Name “Virtual Machine Replication Broker” -Type "Virtual Machine Replication Broker" -Group $BrokerName
Add-ClusterResourceDependency “Virtual Machine Replication Broker” $BrokerName
Start-ClusterGroup $BrokerName

If you configure Replica to use Kerberos authentication, the data transmitted from the primary to the Replica server is not encrypted. For the data to be encrypted, you should use certificate-based authentication. You can either provide an existing X.509v3 certificate or create a self-signed certificate.

If you are already using a certificate server or public key infrastructure (PKI) system, you can use an existing certificate, provided that it meets the following criteria:

  • The certificate must not be expired or revoked.

  • The certificate must include both client and server authentication extensions for enhanced key usage (EKU) and an associated private key.

  • The certificate must terminate at a valid root certificate in the Trusted Root Certification Authorities store on the Replica server.

  • If the virtual machine is hosted by a standalone server, the subject common name (CN) must be equal to (or the subject alternative name—DNS name) should contain the FQDN of the host. If the virtual machine is hosted by a failover cluster, the subject common name (CN) must be equal to (or the subject alternative name—DNS name) should contain the FQDN of the Hyper-V Replica Broker.

For additional information about using certificates with Hyper-V Replica, see http://blogs.technet.com/b/virtualization/archive/2012/03/13/hyper-v-replica-certificate-requirements.aspx

You can validate any candidate certificate by running certutil –store my on both the primary and Replica servers. In both cases, the output of the command should indicate that the certificate passed the encryption test.

  1. On the primary server, copy the Makecert.exe utility locally.

  2. Create a self-signed test root authority certificate by running the following command from an elevated command prompt:

    makecert -pe -n "CN=PrimaryTestRootCA" -ss root -sr LocalMachine -sky signature -r "PrimaryTestRootCA.cer"

  3. Create a new certificate signed by the test root authority certificate by running the following command from an elevated command prompt, supplying the FQDN of the primary server:

    makecert -pe -n "CN=<FQDN>" -ss my -sr LocalMachine -sky exchange -eku 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 -in "PrimaryTestRootCA" -is root -ir LocalMachine -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 PrimaryTestCert.cer

  4. On the Replica server, copy the Makecert.exe utility locally.

  5. Create a self-signed test root authority certificate by running the following command from an elevated command prompt:

    makecert -pe -n "CN=ReplicaTestRootCA" -ss root -sr LocalMachine -sky signature -r "ReplicaTestRootCA.cer"

  6. Create a new certificate signed by the test root authority certificate by running the following command from an elevated command prompt, supplying the FQDN of the Replica server:

    makecert -pe -n "CN=<FQDN>" -ss my -sr LocalMachine -sky exchange -eku 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 -in "ReplicaTestRootCA" -is root -ir LocalMachine -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 ReplicaTest.cer

  7. Copy the file ReplicaTestRootCA.cer from the Replica server to the primary server, and then import it with the following command:

    certutil -addstore -f Root "ReplicaTestRootCA.cer"

  8. Copy the file PrimaryTestRootCA.cer from the primary server to the Replica server, and then import it with the following command:

    certutil -addstore -f Root "PrimaryTestRootCA.cer"

  9. By default, a certificate revocation check is required; however, self-signed certificates don’t support revocation checks. Disable the check by editing the registry on both the primary and Replica servers with the following command:

    reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication" /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f

noteNote
A slightly different version of this procedure that uses the Certificates snap-in to Microsoft Management Console is available at the Virtualizaition Blog.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft