Azure Site Recovery: An Introduction

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.

Azure Site Recovery v0.1

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.

Azure Site Recovery Components v0.1

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.

Azure Networking Overview

The purpose of this post is to explain my understanding of the different networking options with Azure, it is meant to be an overview and not a deep dive into each area.  If you notice any areas which are incorrect, feel free to make a comment and I will update this post.

Endpoints

Endpoints are the most basic configuration offering when it comes to Azure networking.  Each virtual machine is externally accessible over the internet using RDP and Remote PowerShell. Port forwarding is used to access the VM.  For example 12.3.4.1:6510 resolves to azure.vmfocus.com which is then port forwarded to an internal VM on 10.0.0.1:3389 Azure Input Endpoints

  • Public IP Address (VIP) is mapped to the Cloud Service Name e.g. azure.vmfocus.com
  • The port forward can be changed if required and additional services can be opened or the defaults of RDP and Remote PowerShell can be closed
  • It is important to note that the public IP is completely open and the only security offered is password authentication into the virtual machine
  • Each virtual machine has to have an exclusive port mapped see diagram below

Azure Input Endpoints Multiple VM

Endpoint Access Control Lists

To provide some mitigation to having virtual machines completely exposed to the internet, you can define an basic access control list (ACL).  The ACL is based on source public IP Address with a permit or deny to a virtual machine.

  • Maximum of 50 rules per virtual machine
  • Processing order is from top down
  • Suggested configuration would be to white list on-premises external public IP address

Load Balancing

Multiple virtual machines are given the same public port for example 80.  Azure load balancing then distributes traffic using round robin.

  • Health probes can be used every 15 seconds on a private internal port to ensure the service is running.
  • The health probe uses TCP ACK for TCP queries
  • The health probe can use HTTP 200 responses for UDP queries
  • If either probe fails twice the traffic to the virtual machine stops.  However the probe continues to ‘beacon’ the virtual machine and once a response is received it is re-entered into round robin load balancing

Azure Load Balancing

Virtual Networks

Virtual networks enable you to create secure isolated networks within Azure to maintain persistent IP addresses.  Used for virtual machines which require static IP Addresses.

  • Enables you to extend your trust boundary to federate services whether this is Active Directory Replication using AD Connect or Hybrid Cloud connections
  • Can perform internal load balancing using internal virtual networks using the same principle as load balancing endpoints.

Hybrid Options

This is probably the most interesting part for me, as this provides the connectivity from your on-premises infrastructure to Azure.

Point to Site Point to site uses certificate based authentication to create a VPN tunnel from a client machine to Azure.

  • Maximum of 128 client machines per Azure Gateway
  • Maximum bandwidth of 80 Mbps
  • Data is sent over an encrypted tunnel via certificate authentication on each individual client machine
  • No performance commitment from Microsoft (makes sense as they don’t control the internet)
  • Once created certificates could be deployed to domain joined client devices using group policy
  • Machine authentication not user authentication

Azure Point to Site Site to Site Site to site sends data over an encrypted IPSec tunnel.

  • Requires public IP Address as the source tunnel endpoint and a physical or virtual device that supports IPSec with the following:
    • IKE v1 v2
    • AES 128 256
    • SHA1 SHA2
  • Microsoft keep a known compatible device list located here
  • Requires manual addition of new virtual networks and on-premises networks
  • Again no performance commitment from Microsoft
  • Maximum bandwidth of 80 Mpbs
  • The gateway roles in Azure have two instances active/passive for redundancy and an SLA of 99.9%
  • Can use RRAS if you feel that way inclined to create the IPSec tunnel
  • Certain devices have automatic configuration scripts generated in Azure based

Azure Site to Site Express Route A dedicated route is created either via an exchange provider or a network service provider using a private dedicated network.

  • Bandwidth options range from 10 Mbps to 10 Gbps
  • Committed bandwidth and SLA of 99.99%
  • Predictable network performance
  • BGP is the routing protocol used with ‘private peering’
  • Not limited to VM traffic also Azure Public Services can be sent across Express Route
  • Exchange Providers
    • Provide datacenters in which they connect your rack to Azure
    • Provide unlimited inbound data transfer as part of the exchange provider package
    • Outbound data transfer is included in the monthly exchange provider package but will be limited
  • Network Service Provider
    • Customers who use MPLS providers such as BT & AT&T can add Azure as another ‘site’ on their MPLS circuit
    • Unlimited data transfer in and out of Azure

Azure Express Route

Traffic Manager

Traffic Manager is a DNS based load balancer that offer three load balancing algorithms

  • Performance
    • Traffic Manager makes the decision on the best route for the client to the service it is trying to access based on hops and latency
  • Round Robin
    • Alternates between a number of different locations
  • Failover
    • Traffic always hits your chosen datacentre unless there is a failover scenario

Traffic Manager relies on mapping your DNS domain to x.trafficmanager.net with a CNAME e.g. vmfocus.com to vmfocustm.trafficmanager.net. Then Cloud Service URL’s are mapped to global datacentres to the Traffic Manager Profile e.g. east.vmfocus.com west.vmfocus.com north.vmfocus.com Azure Traffic Manager