HP Matrix Operating Environment Co-Existence with Microsoft Hyper-V Replica

Transcription

1 Technical white paper HP Matrix Operating Environment Co-Existence with Microsoft Hyper-V Replica HP Insight Management 7.4 Update 1 Table of contents Hyper-V Replica high-level overview... 3 What happens during replication... 3 Types of failover operations in Hyper-V Replica... 3 Test Failover... 3 Planned Failover... 3 Unplanned Failover... 4 Steps to enable replication for a virtual machine... 4 Tested Configurations... 5 Behavior of HP Systems Insight Manager and HP Insight Control Virtual Machine Management... 5 When using one CMS... 5 When using Two CMSs... 9 Known issue when using HP Capacity Advisor Microsoft Hyper-V Replica and HP Matrix Recovery Management Co-Existence Appendix A Configure Hyper-V Replica using Hyper-V Manager when hosts are not in a cluster Steps to configure a Replica server using Hyper-V Manager Steps to Enable Replication on a virtual machine using Hyper-V Manager Steps to perform Planned Failover using Hyper-V Manager Steps to perform Unplanned Failover using Hyper-V Manager Appendix B Configure Hyper-V Replica using Failover Cluster Manager when hosts are in a cluster Steps to configure Hyper-V Replica Broker role for the cluster using Failover Cluster Manager Steps to Enable Replication on a virtual machine using Failover Cluster Manager For more information Resources, contacts, or additional links References Click here to verify the latest version of this document

2 Introduction The Matrix Operating Environment (Matrix OE) 7.4 Update1 release provides co-existence with Microsoft Hyper-V Replica, a feature of Hyper-V that replicates all changes on a virtual machine to a counterpart virtual machine hosted by a different server. Hyper-V Replica applies to Hyper-V 2012, Hyper-V 2012 R2, and later versions. This white paper documents the necessary steps to follow for the Matrix Operating Environment to co-exist with Hyper-V Replica and known requirements, limitations, and issues. This document assumes that the reader is familiar with both Matrix and Hyper-V operations. This is not a User Guide for how to configure or use either product; consult the appropriate documentation for details. Matrix related documentation is available at: An overview of Hyper-V Replica is available at: 2

3 Hyper-V Replica high-level overview Windows Server 2012 Hyper-V and Windows Server 2012 R2 Hyper-V introduce a capability, Hyper-V Replica, as a builtin replication mechanism at a virtual machine (VM) level. Hyper-V Replica can asynchronously replicate a selected VM running at a primary site to a designated Replica site. 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. Basically, the user needs to define two sites as below: Primary site The site which is the location where the virtualized environment normally operates. It consists of one or more hosts and VMs, from which services are normally delivered. Replica site The site which is the location of the server that will receive the replicated data. It consists of one or more Replica hosts and Replica VMs that receive VM state from the primary site to be able to deliver services in the event of failover. What happens during replication Once replication is configured and enabled on servers at the primary site, an initial copy of data from the primary virtual machines is sent to the Replica virtual machines. This is called initial replication and the user 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 factors), but generally, replication data is sent to the Replica server every 5 minutes in Windows Server In Windows Server 2012 R2, user can configure the replication frequency, so that the changes are sent every 30 seconds, every 5 minutes, or every 15 minutes. Types of failover operations in Hyper-V Replica At a high level, Hyper-V Replica supports three types of Failover, such as: Test Failover Planned Failover Unplanned Failover Each of these failover mechanisms are built to meet specific and different needs. In a Hyper-V Replica environment, the primary server could be a standalone server or part of a cluster and similarly Replica server could be a standalone server or part of a cluster. Independent of where the VM resides, the workflow and the set of features offered are the same and the three types of failover mechanisms will work. Test Failover Test Failover is an operation initiated on the Replica virtual machine which allows the user to test the sanity of the virtualized workload without interrupting the production workload or ongoing replication. Test Failover has an ability to non-disruptively simulate the recovery procedure in an isolated network. Test Failover is used in case the user wishes to run minimal tests to validate if the replication is on track, train personnel on planned / unplanned failure procedures and test the recovery plan that the user has built. Planned Failover The user can choose to move operations of any primary site virtual machine to its corresponding Replica site virtual machine at any time, and this action is called planned failover. Planned Failover requires the VM to be shut down to 3

4 ensure consistency. In a planned failover, any unreplicated changes are first copied over to the Replica virtual machine and the primary virtual machine will be in shut down state, so no loss of data occurs. After the planned failover, the Replica virtual machine takes over the workload and will be powered on; to provide similar protection for the virtual machine that is now servicing the workload. The user needs to configure Reverse Replication on the replicated VM (which is online) to send changes back to the primary virtual machine which is now powered off. Unplanned Failover If the primary server should fail unexpectedly, perhaps as a result of a major hardware failure or a natural disaster, the user can bring up the Replica virtual machines to take over the workload this is unplanned failover. In unplanned failover, there is a possibility of data loss, since there was no opportunity to copy over changes that may have not been replicated. Note Refer to Appendix A and Appendix B for step-by-step procedures to configure a Hyper-V Replica environment and the planned /unplanned failure process (both for non-cluster and cluster configurations). Steps to enable replication for a virtual machine The following high level steps enable replication on a VM. The Appendices of this document provide more detailed steps. All the below steps are performed using Hyper-V Manager or Failover Cluster Manager except for creating the VMs (step1) where VMs can also be provisioned using Matrix OE interface. 1. Create a VM on any local disk (if standalone hosts) or CSV (if clustered hosts) of a primary server. For VM on cluster hosts, it should be High Availability enabled. 2. From Hyper-V Manager, select the VM (in powered on or powered off state) and click Enable Replication. 3. Specify the Replica server name (Cluster name in case of clustered hosts). Select one of the below authentication type for data transfer and compress the data option. Use Kerberos authentication (HTTP) Use certificate based authentication (HTTPS) 4. Choose the virtual hard disks (VHDs) to be replicated. 5. Choose the frequency at which the details will be sent to the Replica server. The data will be sent to the Replica server based on the selected time frequency. 6. Specify the recovery points as either latest or additional hourly recovery points. This will enable the user to choose to store only the latest recovery point of the primary virtual machine on the Replica server or to add additional recovery points, allowing the user to recover to an earlier point in time. 7. Choose the initial replication method. Different methods to perform initial replication are: Using network Send initial copy over the network. Using external media Send initial copy using external media (User needs to specify the location to export initial copy). Using existing VM Use an existing VM on the Replica server as the initial copy. Specify when to start the initial replication Immediately or on specific date and time. 8. Check the summary of replication details and confirm to start the replication. 4

5 Tested Configurations Matrix Operating Environment 7.4 Update 1 has been tested with the following versions and configurations of Hyper-V hosts. All operations like enable replication for a VM, planned or unplanned failover and failback are performed using Hyper-V Manager or Failover Cluster Manager. Matrix OE does not provide interfaces to enable replication or perform failover and failback but can co-exist with environments having such features. Configuration 1: Configuration 1 Primary and Replica sites: Windows Server 2012 Hyper-V hosts without cluster Configuration 2: Primary and Replica sites: Windows Server 2012 Hyper-V hosts with cluster Configuration 3: Primary and Replica sites: Windows Server 2012 R2 Hyper-V hosts without cluster Configuration 4: Primary and Replica sites: Windows Server 2012 R2 Hyper-V hosts with cluster Note In a cluster environment where the primary site has one Failover Cluster and the Replica site has another Failover Cluster, it is necessary that the virtual machines to be replicated are configured with High Availability (HA). Also, in both the primary and Replica clusters, the Hyper-V Replica Broker role needs to be configured which acts as a gateway for the failover to happen using Failover Cluster Manager. However, - In a standalone (primary site) to cluster (Replica site) environment, the primary VM is not High Availability enabled. After replication, High Availability is enabled on the Replica VM by Failover Cluster Manager. - In a cluster (primary site) to standalone (Replica site) environment, the user needs to enable High Availability on primary VM and after replication, the Replica VM is not High Availability (HA) enabled. Behavior of HP Systems Insight Manager and HP Insight Control Virtual Machine Management HP Systems Insight Manager (HP SIM), the Matrix Operating Environment (Matrix OE) and Insight Control virtual machine management (VMM) can co-exist with environments using Hyper-V Replica. However, there are some aspects of the behavior after initial configuration and after planned or unplanned failovers (or failbacks) which should be understood. After replication is enabled for virtual machines from Hyper-V Manager, for every VM on primary site for which replication is enabled there will be a Replica VM on the Replica server with the same name and same UUID. The user will notice some differences in HP SIM behavior for replicated VMs in the Replica environment. A one Central Management Server (CMS) configuration has both the primary servers and Replica servers managed by one CMS. A two CMS (nonfederated) configuration has the primary servers managed by one CMS and the Replica servers managed by the second CMS (typically at the Replica site). When using one CMS Behavior of HP Systems Insight Manager Once the replication is enabled on VMs, in the SIM System page, the user will find VMs residing either on the primary host (for active VMs) or on the Replica host (for inactive VMs). When VM replication is enabled, the primary and Replica VM have the same UUID. As a result, HP SIM will only list one VM. The listed VM could either be the primary or the replica, depending on the order of SIM discovery. The host that the VM is associated with can be determined from the 5

6 Associations section of the SIM System page for a particular host. Virtual machine information in the Associations section of the SIM System page reflects the SIM associations and drives SIM behavior. Behavior of HP Insight Control Virtual Machine Management Replica virtual machines are treated as inactive VMs by VMM and these will not be displayed under the Virtual Machines section (VMM interface) in the SIM System page for the host. Virtual machine information in the Virtual Machine section (VMM interface) of the SIM System page reflects the Insight Control virtual machine manager associations and drives VMM behavior. The VMM interface will only show the VMs on the primary site which are associated with primary hosts and these will continue to be associated with the primary hosts until the Replica VMs are enabled with Reverse replication. After failover, when the VMs on the Replica hosts are enabled with Reverse replication, VMM will identify those VMs as the active ones, and then the host association for the VMs will change to the Replica server (and be displayed in the Virtual Machines section). Note After failover (planned or unplanned) it is necessary to enable Reverse Replication on Replica VMs (after this step these will be primary) from the Hyper-V Manager to ensure the virtual machines are associated with the correct host and also visible under the correct host in the VMM interface. Both HP SIM and VMM behavior is explained below for some of the scenarios The test environment consists of; hosts configured both at primary (win12r2112h1host) and Replica sites (siteb_r1 host). The primary server (win12r2112h1 in the environment) hosts four VMs (Replica_VM1 through Replica_VM4). Before Replication The user can see all of the VMs in the HP SIM System page for the primary host (win12r2112h1). Notice that the SIM Associations tab shows all these VMs associated with the primary host and their names will appear as win12r2112h1_replica_vm1, win12r2112h1_replicavm2, etc (See the screen shot below). Also, notice that the Virtual Machines section shows same set of VMs for the primary host (based on VMM information). If in a situation where there are no VMs under Virtual Machines section of a host it means that the host does not have any active VMs on it. At this point in time, the Replica hosts (siteb_r1 host) will not show any of these VMs under the SIM Associations section of the system page and the Virtual Machines section of the system page because replication is not yet enabled. Click on any of the Guest Names under the Associations section of the system page (perhaps win12r2112h1_replica_vm1 as shown below), and a VM page with all the details will be displayed. The Virtual Machine Configuration Details section will show the VM Host field retrieved from VMM and it indicates that it is the host which is hosting an active VM. Clicking host name under Associations section will take the user to SIM System page of host. 6

7 After Replication Once the initial replication is completed for each VM, the Replica VMs will be created by Hyper-V on the Replica server (on siteb_r1 host). Therefore, there are two instances of each VM (a primary VM and a Replica VM), which have identical names and UUIDs. The HP SIM System page will list either the primary VM or Replica VM, depending on which host was last discovered. VMM treats Replica VMs as inactive (until Reverse replication is enabled) and will filter out the Replica VMs and therefore only shows the primary VMs on the Virtual Machines section of the SIM System page of the host. After initial replication if the user triggers a host identification task on any of the Replica hosts then VMs associations with hosts will change. Refer to the screenshot below which shows the VMs being associated with a Replica server (siteb_r1 host) after host identification is triggered on the Replica servers (siteb_r1 host). At this point, the primary server will not have any VMs associated with it. There is no change in the VMM data (i.e. Replica server will not have any VMs under the Virtual Machines section of the host system page as these are still inactive VMs). Sometimes for a particular VM (such as Replica_VM1 in the screenshot below), the SIM System page could show different host names in the Associations section (see the Hosted By entry) and the Virtual Machine Configuration Details section (see the VM Host entry). As noted earlier, HP SIM will associate the VM with only one host based on 7

8 recent host discovery and the same is reflected in the Associations section of the system page whereas the VM (Replica_VM1) is actually active on the Replica host (siteb_r1 host) and Virtual Machine Configuration Details section shows the same. After planned failover is completed for all the VMs on primary hosts to Replica hosts, VMs will be up and running on a Replica server (on siteb_r1host). Now, based on HP SIM s last identification status, the Associations section of the system page will show the VMs either with primary or Replica hosts. The figure below shows all the VMs associated with Replica server (siteb_r1 host) but VMM will continue to show the VMs associated with primary hosts until Reverse Replication is enabled on Replica VMs. Once the Reverse Replication is enabled on all the Replica VMs, the Virtual Machine section of the system page will show the VMs associated/hosted with Replica host (i.e. with siteb_r1 host) as shown below. In case of unplanned failover, the VMs need to be enabled with Reverse Replication once after primary site is online or using a different site which will act as a Replica site. The Virtual Machines section of the system page will then show the accurate information of the VMs and their hosts. 8

9 When using Two CMSs In the case of Hyper-V Replica co-existing with a two non-federated CMS configuration, the primary site and Replica site are managed by two different and independent CMSs. In such an environment the user will not notice the issues which are observed with using single CMS. The two CMSs will independently manage each of the sites and the HP SIM behavior with respect to UUID is not observed as there will not be duplicate VMs in each CMS. In case the user notices that there are no details under the Virtual Machine Configuration Details section of the VM page after replication is enabled and it displays the message Host is not registered with VMM it means the VM is not an active VM but it is just a HP SIM node (as shown under Associations section) and the VM will be active on a different host on other site. Limitations with HP SIM and Matrix OE Once replication is enabled on a primary VM, primary VM and the Replica VM have the same UUID, and thus HP SIM cannot identify them as different VMs. This issue limits the HP SIM behavior and VMs could appear as migrating or changing in association from one Hyper-V host to another Hyper-V host (having Replica VMs) after the HP SIM host identification is triggered. If automatic identification of the hosts is triggered in HP SIM then the VMs will change association from the primary host to the Replica host or vice versa (due to the same UUID for primary VM and Replica VM). The VM will be shown associated with the host most recently identified. Hyper-V Replica cannot co-exist with Matrix in a federated Central Management Server (CMS) environment where one CMS has version lower than 7.4 Update1 (all CMSs must be 7.4 update1 or later). Important: Once the user plans to discontinue the use of the Hyper-V Replica feature and replication is no longer required, the user should delete the Replica VMs after removing/disabling the replication. If Hyper-V Replica is disabled but the Replica VMs are not deleted then VMM will not be able to filter out the inactive Replica VMs and it will show all the VMs (both active and inactive VMs). This will lead to VMM displaying two VMs with the same UUID. Behavior of HP Matrix Operating Environment The Matrix OE will have almost the same behaviors and constraints as those for HP SIM and Insight Control virtual machine management outlined earlier. Below are some observations, constraints, and behaviors: 9

10 After replication is enabled for a VM, the Matrix infrastructure orchestration service or logical server will be associated with the VM on the primary site. After a VM failover, the Matrix infrastructure orchestration service or logical server will be associated with the VM on replica site. For example, hvreplica2 Hyper-V host. The user must enable replication for a VM using the Microsoft Hyper-V interfaces (out-of-band to Matrix OE). The Matrix OE interfaces do not enable replication or perform failover and failback, but can co-exist in environments using such features. That is, Matrix OE can create a Hyper-V VM (as part of a Matrix infrastructure orchestration service or as a logical server), and that VM can have replication configured by Hyper-V Manager. In a cluster environment, the user will not be able to perform replication or failover without enabling High Availability for the VMs. The Matrix infrastructure orchestration designer can be used to enable HA when creating a service template. After replication is enabled in a primary VM, the following operations will not be synchronized in the Replica VM but Matrix OE will not block these operations on the primary VM (components added, edited, or removed after replication is enabled, are not replicated): o Add servers o Remove servers o Add new disk o Add disk o Edit disk o Add network o Remove network o Edit virtual servers: CPU and memory Note After replication, if a primary VM is edited (for example, CPU, Memory, add disk, add/update network) using Hyper-V Manager, the changes will not be reflected in the Replica VM. Hyper-V only provides replication of virtual hard disk (VHD). 10

11 To illustrate this behavior, below is an example when user edits a virtual server in HPIO changing the CPU. HPIO service created with one CPU and VM details in Hyper-V host: After adding one more CPU using HP infrastructure orchestration: 11

12 Primary VM will have 2 virtual processors as shown below after adding CPU using HP infrastructure orchestration: Replica VM still has the original values (only one CPU): 12

13 CLI will display the service in Replica server as well: VMs with replication enabled can be imported into Matrix OE, but Matrix has no knowledge of the replication. The VM behaviors are the same as when a service is created using Matrix OE and later replicated out-of-band to Matrix. When a failover occurs, Matrix OE can take some time to synchronize the logical server or service with the VM status. The Administrator can use the Matrix ioexec command and run sync logicalserver in order to try forcing synchronization, although delays can still occur. Disk Pass-Through raw disks attached to a VM are not allowed to be replicated by Hyper-V. Primary VMs and Replica VMs will have different static MAC addresses. Matrix OE will display the appropriate IP associated with each MAC address. After a failover occurs, the Matrix logical server or service will be associated with the Replica VM (as shown in Matrix OE visualization or the infrastructure orchestration Servers tab). 13

14 Matrix logical servers or services created with static IP addresses will have the same behavior as those created with DHCP, although synchronization may take longer after a failover occurs. Note In an environment consisting of Windows Server 2012 Hyper-V and Windows Server 2012 R2 Hyper-V hosts, replication is allowed from Windows Server 2012 Hyper-V to Windows Server 2012 R2 Hyper-V but not vice-versa. Windows Server 2012 R2 Hyper-V provides support to have extended Replica server. In extended replication, Replica server forwards information about changes that occur on the primary virtual machines to a third server (the extended Replica server). User can fail over to the extended Replica server if both the primary and Replica servers go down. This White paper do not cover the scope of having extended Replica server in the test environment. Known issue when using HP Capacity Advisor When DHCP is enabled, the replicated VM in the Replica site gets its IP address from DHCP which is different from its IP address in primary site. In such a situation, the Replica VM should be manually discovered with the new IP address (DHCP assigned) in HP SIM. After this step, the Replica VM works fine with Capacity Advisor. When DHCP is disabled and a static IP address is assigned to a VM in the primary site, the Replica VM is discovered automatically without any issue in HP SIM and works fine with Capacity Advisor. 14

15 Microsoft Hyper-V Replica and HP Matrix Recovery Management Co- Existence Hyper-V Replica and HP Matrix recovery management can co-exist in the same environment but should not be used to protect or replicate the same VMs. As an example: Hyper-V Replica can be protecting Hyper-V 2012 and Hyper-V 2012 R2 VMs. HP Matrix recovery management can be protecting physical servers, VMware VMs, and Microsoft 2008 Hyper-V VMs. Hyper-V Replica and Matrix recovery management are two independent products managing and protecting separate resources. Do not attempt to use both on the same resources (for example, the same VMs or different sets of VMs sharing a common data store, or mixed failovers). You cannot failover a VM using Hyper-V Replica at the primary site and then a failback using HP Matrix recovery management at the Replica site. A given VM is either protected by Hyper-V Replica or by Matrix recovery management (so one solution manages the VM and its replica). 15

16 Appendix A Configure Hyper-V Replica using Hyper-V Manager when hosts are not in a cluster This document does not describe the detailed steps to configure Hyper-V Replica, but covers the main steps (with screenshots). All the below steps are performed using Windows Server 2012 R2 Hyper-V Manager. Steps to configure a Replica server using Hyper-V Manager 1. In Hyper-V Manager, enable Hyper-V Replica on the Replica site server (i.e., SAVDALHV02) using Hyper-V Settings. Select Replication Configuration and select the different options as below: You will find two options for encrypting the data; Use Kerberos (HTTP) and Use certificate based Authentication (HTTPS). Select Use Kerberos (HTTP) for the Replica server. In the Authorization and storage section, specify the servers that are allowed to replicate virtual machines to the Replica server. Add the primary server FQDN name (from which replication is allowed), Storage Location where the replicated VM needs to be saved and a name for the replication Trust Group. Then click OK. 16

17 2. When using the http server, it is necessary to enable the HTTP listener. 17

18 3. Go to Windows server manager. Select Tools Windows Firewall with Advance Security. Select inbound rules and Enable Rule for the Hyper-V Replica HTTP Listener. 18

19 Steps to Enable Replication on a virtual machine using Hyper-V Manager 1. In the Hyper-V Manager, select the primary site server (i.e., SAVDALHV01 host which is the primary server in the screenshot shown below) and select the VM (e.g.savdaldc10) which needs to be replicated. Right click the VM and select Enable Replication. While using Windows Server 2012 R2, right click the VM, select Replication option and then Enable Replication. 2. Read through onscreen information and click Next to continue. In the Specify Replica server wizard, browse or select the Replica server name (i.e., SAVDALHV02 host which is the Replica server) where the VM needs to be replicated. Click Next. 19

20 3. In the Specify Connection Parameters wizard, select Use Kerberos authentication (HTTP) and check the Compress the data that is transferred over network option. Click Next. 4. Select all the VHDs (virtual hard disks) that need to be replicated. Click Next. Choose the frequency at which changes will be sent to the Replica server. Click Next. 5. In the next step the user can either select Maintain only the latest recovery point or Create additional hourly recovery points. If the user selects Create additional hourly recovery points, then the user can specify the coverage provided by additional recovery points (in hours). Then click Next. 20

21 6. In the next step, the user can select the Initial Replication Method and schedule the Initial Replication. a. Using network Send initial copy over the network. b. Using external media Send initial copy using external media (User needs to specify the location to export initial copy). c. Using existing VM Use an existing VM on the Replica server as the initial copy. Specify when to start the initial replication immediately or on specific date and time. Click Next. 21

22 7. The final step is to check the summary of replication and click Finish. 8. After clicking Finish, the user will find the replicated VM will be created on the Replica server (for example, SAVDALHV02 host) with powered off state. 22

23 9. Also, on the Replica server, the user will find the files related to the Replica VM under the storage location specified while configuring the Replica server. 10. After failover is completed, the Replica VM takes the workload, the Replica server becomes the primary server to that VM, and the original primary server becomes the Replica server if the user configures reverse replication. If the user plans to enable failover- failback, follow the steps mentioned under Steps to configure Replica server using Hyper-V Manager for the primary host to configure it as a Replica server (as shown below). 23

24 Steps to perform Planned Failover using Hyper-V Manager 1. To perform a planned failover, make sure that the primary VM is powered off. Then, right click on the primary VM and select ReplicationPlanned Failover. 2. The user can select Reverse the replication direction after failover and Start the Replica virtual machine after failover. Uncheck any of the options according to user requirements. Once the user clicks Fail Over, the Replica VM on the Replica server will be powered on and the VM present on the primary server will remain in the powered off state. 24

25 Steps to perform Unplanned Failover using Hyper-V Manager The user can also perform unplanned failover where the primary site server or primary VM goes down unexpectedly and the workload needs to be taken over by a Replica VM or in the reverse direction. Assume that the primary server or VM is powered off unexpectedly. Now, to perform an unplanned failover, the user needs to select a Replica VM (which is in a powered off state), select the Replication Failover option and in the dialog that opens, choose the recovery snapshot of the virtual machine to which to recover, and then click Failover. This action will failover to the Replica host and the Replica VM will start running. In unplanned failover there is a possibility of data loss on the Replica VM since there was no opportunity to copy over changes that might not have yet been replicated. Planned and unplanned failover can be performed in the reverse direction as well (i.e., failover from active Replica server to inactive primary server). 25

26 Appendix B Configure Hyper-V Replica using Failover Cluster Manager when hosts are in a cluster This document does not describe the detailed steps to configure Hyper-V Replica, but covers the main steps (with screenshots). All the steps and screenshots in this Appendix are from using Windows Server 2012 R2 Hyper-V. Hyper-V replication of VMs in clustered hosts can be configured between two clusters (primary site cluster and Replica site cluster). It is not allowed to be configured between two hosts residing in the same cluster. Enabling replication in the cluster environment requires VMs to be configured with High Availability. The servers which will be part of the Replica site cluster need to be configured as Replica servers (Replication configuration) using the steps mentioned under Steps to configure a Replica server using Hyper-V Manager of Appendix A. Steps to configure Hyper-V Replica Broker role for the cluster using Failover Cluster Manager 1. Hyper-V Replica Broker role enables the failover cluster to participate in virtual machine replication with Hyper-V Replica. Hyper-V Replica Broker needs to be configured on both primary and Replica site clusters but only one Hyper-V Replica Broker can be configured on each failover cluster. To start enabling the Hyper-V Replica Broker role, open Failover Cluster Manager, select the cluster (for example, primary site cluster) and select Roles Configure Role. The High Availability wizard opens. 26

27 2. Read through the onscreen information and click Next in the Availability Wizard. In the Select Role wizard select the Hyper-V Replica Broker option and click Next. 3. In the Client Access Point wizard, specify a name for the clustered role (e.g., Replica1123). Then, select the network to be used and specify the IP address that clients will use when accessing the cluster. Click Next to continue. Make a note of the client access point name for later configuration of the Replica. 27

28 4. On the Confirmation wizard, read all the parameters and click Next to continue. 5. Failover Cluster Manager will process the High availability configuration and show the Summary of Hyper-V Replica Broker. Click Finish and this will create a new entry under Roles. Follow the same steps to configure Hyper-V Replica Broker for Replica site cluster. In the example screenshot, Replica_1156 is the Hyper-V Replica Broker for Replica cluster. 28

29 Steps to Enable Replication on a virtual machine using Failover Cluster Manager 1. To enable replication, open Failover Cluster Manager and select the VM (for example, Replica as shown in the screenshot) to be replicated from one of the clusters (for example, from the primary site cluster which has the Replica_1123 Broker role). Make sure it is powered off. Select the Replication -> Enable Replication option. 2. Read through the onscreen information of the Enable Replication wizard and click Next to continue. Then, specify the Replica server name to use to replicate the virtual machine. If the Replica server is on a Failover Cluster, specify the name of Hyper-V Replica Broker which is configured on Replica server (for example, Replica site cluster Broker is Replica_1156 ). Click Next to continue. 29

30 3. In the Specify Connection Parameters wizard, select Use Kerberos authentication (HTTP) and check the Compress the data that is transferred over network option. Click Next to continue. 4. Select all the virtual hard disks (VHDs) that need to be replicated. Click Next. 30

31 5. Choose the frequency at which changes will be sent to the Replica server. Click Next. 6. In the Configure Additional Recovery Points wizard, user can either select Maintain only the latest recovery point or Create additional hourly recovery points. If the user selects Create additional hourly recovery points, then the user can specify the coverage provided by additional recovery points (in hours). Then click Next. 7. In the next step, the user can select the Initial Replication Method and schedule the Initial Replication. a. Using network Send initial copy over the network. b. Using external media Send initial copy using external media (User needs to specify the location to export initial copy). c. Using existing VM Use an existing VM on the Replica server as the initial copy. Specify when to start the initial replication immediately or on specific date and time. Click Next. 31

32 8. The final step is to check the summary of replication and click Finish. 32

33 9. Clicking Finish will create the Replica VM on any one of the hosts in the Replica site cluster (for example, SITEB_R2). Follow the onscreen instructions if any to configure the VM manually for any settings. 10. The Replica virtual machine will be in powered off state on the Replica server. To replicate any VM on the Replica server (i.e., Reverse replication), repeat the steps under Steps to Enable Replication on a virtual machine using Failover Cluster Manager ; specify the primary cluster as the Replica server (e.g., Replica_1123 ) and add the CSV of the primary cluster. To perform planned or unplanned failover, follow the steps explained in Appendix A. In a cluster environment, the user needs to execute all the steps using Failover Cluster Manager. 33

34 For more information Resources, contacts, or additional links For more information about the HP Matrix Operating Environment, see the documentation at: References Overview of Microsoft Hyper-V Replica is available at: Learn more at Sign up for updates hp.com/go/getupdated Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein. Microsoft, Microsoft Windows, Microsoft Hyper-V are trademarks of the Microsoft group of companies , May 2015