Single VMM Server deployment topologies for Windows Azure Hyper-V Recovery Manager

First published on TECHNET on Dec 16, 2013

Business requirements should drive topology decisions. Based on these requirements an organization might choose to have multiple data centers managed by a single management head or multiple management heads managing different data centers. This blog covers how an organization deploy an SCVMM (System Center Virtual Machine Manager) Server while using a single VMM Server to protect workloads through HRM (Windows Azure Hyper-V Recovery Manager).

Based on the design principle of simplicity, HRM is modelled in a manner to allow administrators to build a disaster recovery solution on top of their existing data center topologies. HRM thus enables various organizations to choose a topology that best satisfies their business needs without being limited by technical constraints.

HRM is built on top of Microsoft System Center Virtual Machine Manager (SCVMM) that allows the customers to sync the existing on premise VMM clouds and VMs to the service. Thus, using HRM, customers can protect workloads on a VMM server on a primary site to a VMM Server managing the secondary site. Hence, in the event of a disaster, all the workloads are seamlessly failed over from the primary site to the secondary site being managed by the secondary VMM server. However, some organizations might want to use a single VMM Server to manage all their data centers in order to avoid management overhead. For a customer with this topology it is imperative to be able to recover the VMM server before the workloads can be recovered. Hence a customer must cautiously deploy the VMM Server in order to make his workloads ‘disaster-proof’.

It is recommended to deploy the VMM Server in one of the following topologies to be able to recover the workloads with the best possible RTO (Recovery Time Objective) and RPO (Recovery Point Objective). The choice of deployment depends on whether

a) The VMM Server is on a cluster and is highly available or

b) The VMM Server is a standalone instance.

Highly Available VMM Server on a multi-site cluster

Deploying a VMM server as highly available is a method of making the VMM service itself cluster aware. This deployment option is extremely helpful when critical workloads are being managed by a VMM Server and it is extremely important to have it available at all times. Making the service cluster aware helps in protecting the VMM server against hardware failure of the host that the VMM Server is running on, as well as, any issues that may exist on the virtual machine the VMM Server is running on. Deploying as an HAVMM requires the VMM Server to be present on a Windows Server Failover Cluster. You can find details on how to deploy a VMM as highly available here .

When protecting workloads using HRM, this VMM server should be deployed over a stretch cluster extending across geographically separated sites. The SQL Database that the VMM Server is pointing to should be protected using AlwaysOn availability groups with a secondary replica on the recovery site.

In the event of a disaster, the VMM Server and the corresponding SQL DB will be automatically failed over to the recovery site following which all the workloads can be failed over using HRM.

VMM on a VM using Hyper-V Replica

If the VMM server has been deployed as a standalone VMM Server, it should be deployed on a virtual machine and protected to the secondary site using Hyper-V Replica. To reduce downtime, the SQL DB can be ideally installed on the same VM. If the VMM Server is using remote SQL, it will be required to first recover the SQL DB in order to recover the VMM Server.

The steps to deploy a single VMM on a VM with Hyper-V Replica enabled are:

1)      Setup the VMM on a VM with SQL DB installed.

2)      Add the hosts to be managed to clouds on this VMM server.

3)      Proceed to the Hyper-V Recovery Manager service by logging into the portal and configure the clouds for protection.

4)      Enable replication on all the VMs that need to be protected from the VMM server.

5)     Enable replication on the VMM VM using Hyper-V Replica from the Hyper-V Manager console. Please ensure that the VMM VM is not added to the clouds being protected by the Hyper-V Recovery Manager service so that the Hyper-V Replication settings are not overridden.

Thus, in the event of a disaster the workloads can be recovered using the following steps:

1)      Failover the replica VM with the VMM to the recovery site from Hyper-V Manager.

2)      After the VMM VM has been recovered, the user can login to the Hyper-V Recovery Manager from the portal and do an unplanned failover of the resources from the primary to the recovery site.

3)      After the unplanned failover is complete, the user can access all the resources at the primary site.

This topology would however require the user to manually failover his VMM VM to the secondary site before he can failover his workloads.

Hence for an organization, it is recommended to install one VMM Server each on both the primary and recovery sites for a seamless disaster recovery. However, if customer cannot install two VMM servers due to business objectives, he should use one of the above mentioned topologies.

We will soon be publishing a detailed whitepaper explaining the above topologies with detailed steps to failover the workloads when using these topologies.