Orchestrate protection and recovery of private clouds
Windows Azure Hyper-V Recovery Manager can help you protect important services by coordinating the replication and recovery of System Center 2012 private clouds at a secondary location.
System Center 2012 Virtual Machine Manager private clouds can be protected through automating the replication of the virtual machines that compose them at a secondary location. The ongoing asynchronous replication of each VM is provided by Windows Server 2012 Hyper-V Replica and is monitored and coordinated by Hyper-V Recovery Manager.
The service helps automate the orderly recovery in the event of a site outage at the primary datacenter. VMs can be brought up in an orchestrated fashion to help restore service quickly. This process can also be used for testing recovery, or temporarily transferring services.
So how does Windows Azure Hyper-V Recovery Manager work ?
Most important is the hyper-v server should be able to replicate, The HRM is only the orchestrator in this process there will be no vm’s replicated to the cloud and back.
What Do you need to use this you can use this with one SCVMM server and two Hyper-v servers to place the VM’s and they should not be in the same cloud.
Or use the scenario as above two VMM servers in two Data Centers, with replications and connected to Azure.
To start we need a Certificate this is most important.
You can create a self-signed certificate using the makecert tool, or use any valid SSL certificate issued by a Certification Authority (CA) trusted by Microsoft, whose root certificates are distributed via the Microsoft Root Certificate Program. For more information about this program, see Microsoft article Windows Root Certificate Program members.
To obtain a self-signed certificate
- Obtain the Makecert tool as described in MakeCert. Note that when installing the Windows SDK, you can install makecert.exe only by selecting the optionTools under.Net Development and leave everything else unchecked.
- Open Command Prompt (cmd.exe) with Administrator privileges and run the following command, replacing CertificateNamewith the name of your certificate and specifying the actual expiration date of your certificate after
makecert.exe -r -pe -n CN=CertificateName -ss my -sr localmachine -eku 220.127.116.11.18.104.22.168.2 -len 2048 -e 01/01/2016 CertificateName.cer
On the SCVMM2012 Server run this :
makecert.exe -r -pe -n CN=Hyperv_replica -ss my -sr localmachine -eku 22.214.171.124.126.96.36.199.2 -len 2048 -e 01/01/2016 Hyperv_replica.cer
as you can see the Hyperv_replica.cer file is there and also the certificate is saved to disk and in the certificate store.
the certificate saved on disk is for the azure HRM and you will need a export with private key from this certificate you must use this certificate on all your other SCVMM2012 servers that you will protect. remember this else everything will fail.
We Export the certificate and this certificate must be imported on the other VMM server ( if you use one vmm server you don’t need to import this cert again )
- Copy the private-key (.pfx) certificate files to a location on the local server.
- In the Certificates MMC snap-in select Computer account and click Next.
- Select Local Computer and click Finish. You are returned to the Add/Remove Snap-in dialog box, click OK.
- Import the Certificate.
We have a certificate and we are ready to create a vault in Azure. Go to the azure site and login.
First we have to create a vault that holds our SCVMM servers
select recovery services and click new
It will take a moment to create the vault and now in just 5 steps you will protect your VM’s with Windows Azure Hyper-V Recovery Manager
select the vault you have just created
Our first step is import the certificate.
In the bottom is a little icon with 2 you can click that and will see the progress
Now that the certificate is in place we can go on.
But just to make sure we have the right certificate we can check this.
on the VMM server go to the certificate and open the cert that you created.
And in azure click on the dashboard you will see the certificate thumbprint this must bee the same.
If not you imported the wrong Certificate.
Installing the Agent
I downloaded the agent and placed the file in a folder for later usage
Before we run the agent stop the VMM Services only the manager service.
Download and install the agent
Install the Hyper-V Recovery Manager provider agent on each VMM server that contains virtual machines you want to protect. Agents are accessed on the Windows Azure Download Center, and have their own setup process. When setup runs the agent is installed, and the VMM server is registered with the vault, as follows:
On the Quick Start page, click Download Agent. Run Setup to start the installation wizard.
After the agent installation is complete, the VMM server is registered with the vault. During registration you do the following:
- Specify how the agent running on the VMM server connects to the Internet. The agent can use the default Internet connection settings, or you can configure specific proxy settings.
Select the .pfx file that corresponds to the .cer that you uploaded to the vault. The private key of the certificate is used to register the VMM server to the vault.
But remember The imported Certificate must be the one with the private Key!
Else it will not show the certificate.
This step by step process will install the agent and will register the SCVMM server to the Windows Azure Hyper-V Recovery Manager.
The next step is connecting the VMM clouds and create a protection configuration
You can select dashboard and or the configure protection
In this screen wizard we select the source cloud where the VM’s are that we will protect and the target cloud where the VM’s are replicated to when needed.
I played a bit to much with this and the following items have the server and clouds different names.
as you can see I created several recovery plans in this case it is on the same VMM server but if you use the same certificate on all your VMM servers and during the agent install pointed them to the same vault the vmm servers will be in the same vault. for Demo sake I created several vaults with several VMM server each with a different scenario to test all servers are clusters
Our next step will be connecting the networks
We select the networks that are used by the clouds In my case I keep the naming the same on all my hyper-v servers / clouds but it can me a different network in the other data center , with this you will map the networks to getter.
Next step is create a recovery plan Select the VM’s that we will manage with HRM
here we select the MVV server and the VM’s that are running on this server and the option of enable recovery will be there.
Now that everything is in place the enable recovery option is there and ready to start
In VMM we enable the recovery. there is a quick progress bar in VMM.
checking the azure website, in our vault we see our VM and we created a recovery plan in just a few steps
Select a vm or more that will used by this recovery plan. I use only one in this vault.
Then we do our first failover, and what the Windows Azure Hyper-V Recovery Manager does is quite nice it creates and configures the replica settings in the Hyper-v Or cluster and start replicating the VM to the other Cloud based all on your own replication settings
The next step Is just a brief overview In the azure Job list you can see all the steps
Windows Azure Hyper-V Recovery Manager did his job and as we can see in VMM the VM is stopped on the left01 and is replicated to the Right01 and turned on.
Great option and yes there could be improvements
If you want to see more watch Channel 9
Challenges in Disaster Recovery
10 thoughts on “#WindowsAzure Hyper-V Recovery Manager #azure #Hyperv #recovery #msteched #TEE13 #DRaaS”
I’ve been playing with HRM. But I found when the VMs are recovered at the DR site, the network isn’t attached – despite the mapping. Any theories why that might happen? Did you check to see the network was functional on the recovered VMs?
Yes all vm’s are running fine. to make sure I used the same network name on both sites. and you did the network linking.
I was involved in an early beta so my test have seen alot of issues but at the end it all worked fine.
try to test this with a fresh setup in HRM.