Author: Craig

In the previous blog post, I covered an creating virtual networks and Azure vault followed by installing the Configuration Server.  Now we move onto the Master Target Server,

Back over to the Azure portal.  We now need to access Recovery Services > VMFocusVault > Deploy Master Target Server

Give your Master Target Server a name, select the OS, choose the size (I’m rolling with A4) and enter in your credentials. Next select your Configuration Server and give the Master Target Server an IP address.

Time for a cup of tea as it will take a while for the Master Target Server to be created.

Make sure you take note of the external IP address of our Master Target Server as we will need to RDP onto it in order to complete the configuration tasks.

The external IP can be found under Virtual Machines > Select VM > Dashboard 

Log onto your Master Target Server, the first thing you will see is a PowerShell script being executed, make sure to leave this running.

The Host Agent Config dialogue box will appear after a little while.  Enter in the IP Address of your Configuration Server, Port Number (443) if on the same subnet and the Passphrase.   Finally hit OK.

Rather than waiting for the connection to be established to the Configuration Server which can take sometime.  We can bypass this by clicking on Recovery Services > VMFocusVault > Servers > Refresh

If everything has gone correctly you should see the Master Target Server connected to your Configuration Server.

In the next blog post, we will move onto configuring the on-premises Process Server.

In the previous blog post, I covered an introduction to Azure Site Recovery and the components that make up the solution.  In this post I will cover the initial configuration in the Azure Portal.

If you don’t have one already, I would suggest signing up for an Azure Free Trial, this includes £125 worth of credits.

Once you are logged into the Azure Portal, the first thing we want to do is create out virtual networks.  I’m going to create two:

• VMFocus_DR_L2 – Layer 2 network extension from on-premises, to keep same IP Address
• VMFocus_DR_L3 – Layer 3 network, to force VM’s to change IP Address

Select Networks > Create a Virtual Network

Provide a name and select the location for the network

Next enter in your DNS Servers and and VPN details.  I’m not federated against my local domain, nor do I have any domain controllers deployed so for now I will leave this part blank.

Finally complete your address space and subnets then wait for the network to be created.

Next we need to create a vault for recovery services.   The process is straight forward.  Select Recovery Services > Site Recovery Vault > Quick Create > Enter Name & Region

Now that the Site Recovery Vault is created.  We can move onto deploying our Configuration Server.

Select Quick Start and select your Recovery Type.  In this deployment, I will be using VMware to Azure.  Next select Deploy Configuration Server

Enter the required details ensuring that the required Azure Virtual Networks is selected.

As I will be replicating data over the public internet, we need to take note of the external IP address of our Configuration Server.  This can be found on the Virtual Machine status panel.

The next step is to download a registration key.  This is found on the Recovery Services > Select your Vault > Download Registration Key

Log into your Configuration Server and the automatic deployment process will prompt you to start the installation process.  Click Next and Accept the MySQL license terms.

Enter your MySQL credentials and click next.

Select your proxy settings and hit next.  Now we need to install our Configuration Server Key.  Browse to the saved location and select the key.

Click Finish to exit Setup.

This next part is really important, ensure that you capture the passphrase for the Configuration Server.

Onto credentials now.  We need to add an account that has the credentials to install the ‘Mobility Service’ onto virtual machines.   I have created an account called Service.Azure as per the dialog box below.

Always best to ensure that your account displays correctly.

In the next blog post we will move onto deploying the Master Target Server.

When Microsoft released Azure Site Recovery, I have to say it caught my attention since it claimed to be a single solution which can orchestrate, and automate the protection, and recovery of on-premises physical servers and virtual machines based on Hyper-V or VMware with replication, failover and failback to Azure.

Components of Azure Site Recovery

• On-Premises Process Server – This receives replication data from the Mobility Service (in-guest agent)  using disk based cache.  It is used to compress and encrypt data on-premises before sending it over internet/VPN/Express Route to the Master Target server in Azure

• On-Premises Mobility Service – This can be pushed out automatically by the Process Server or performed manually.  Essentially it is an IO splitter that takes a write to disk, holds it in memory and sends it across to the Process Server

• Azure Configuration Server – This is the brains, it co-ordinates communication between all components both on-premises and in Azure.  Each Configuration Server can support up to 100 source virtual machines.
  

• Azure Master Target – Receives incoming replication traffic from the on-premises Process Server. Each protected VM is added as a VHD using ‘blob’ storage.

• Replication – Azure Site Recovery uses streaming ‘a synch’ replication.  It’s worth noting that maximum throughput is 80Mbps when using Site to Site VPN or any form of normal internet connection.

• Licensing – Is per protected VM

The diagram below shows the relationship between all the components.

What Are The Gotcha’s?

The gotcha’s I’m aware of at the moment are as follows:

• Currently you are unable to perform test failovers.  The work round is to create ‘test VM’s’ failover to Azure and then destroy them.
• You are unable to seed data into or out of Azure Site Recovery.  Thought needs to be how long it will take to protect virtual machines and failback to on-premises
• Protected VM’s are limited to those supported in Azure
• Protected VM’s can only migrate within their series type e.g. A1 to A4, but they cannot move into D series.

I’m sure Microsoft are working on these and will provide updates in the near future.

In my next blog post, I will start configuring Azure Site Recovery Manager with on-premises VMware virtual machines.