Azure

This is going to be my first time attending the Technology User Group event in London on 5th May at Grange St Paul´s Hotel, 10 Godliman Street, EC4V 5AJ.

For those of you who don’t know, TechUG is a independent community of IT Professionals spread around 8 cities in the UK & Ireland. Focused on technology areas such as Virtualisation, Cloud, Storage, Data Centre, Open Source and DevOps, communities are run locally by a group of volunteer committee members and supported by a central team. TechUG runs free community events twice yearly in each city and also collaborate with other user groups.

For the London gathering on 5th May, the event team, have lined up a great group of presenters, including Chris Kranz, who will bring his insights on AWS and it’s use cases apart from IaaS. Also Peter von Oven, author of Mastering VMware Horizon 6 who will be sheep dipping us in the key areas of a desktop transformation project.

I’m also lucky enough to be presenting and if you are their from the kick off, you can hear my dulcet tones covering the topic ‘What’s Azure Site Recovery All About?’ which will provide a look at Microsoft’s DR platform.  In this session I will cover the challenges around traditional disaster recovery and Microsoft’s answer to these challenges.

If you haven’t already I suggest you register to attend over here.

Purpose

The purpose of this blog post is to give you an insight into the lessons learnt during a recent installation of Azure Site Recovery.

Background

Existing on-premises environment runs vSphere 5.5 Enterprise Plus and has a 500Mbps ExpressRoute connection into Microsoft Azure.

Active Directory Federation Services is deployed in Microsoft Azure providing authorisation and authentication services.

Design

The design was quite straight forward, to meet customer requirements, we needed to:

• Protect three seperate vSphere VM’s three tier application (web, middleware, database)
• Perform a test failover using two groups protection groups
• Perform a planned failover and planned failback
• Perform an unplanned failover and planned failback
• Perform an unplanned failover and planned failback to an alternative datacentre

A logical overview of the topology used is shown below.

Lessons Learnt

Enable Protection Fails

Installation of the Mobility Service will fail if the virtual machine you are trying to protect as a restart pending.

Re-Protect Fails

To protect workloads for failback the on-premises Azure Site Recovery Process Server needs to be the same as the workloads it’s protecting.  For example if you use a physical Process Server, you cannot failback from Azure.

Cache Disk

The installation location of Azure Site Recovery cannot be used as a cache disk.

Add Credentials to Process Server

Launch cspconfigtool from C:Program Files (x86)Microsoft Azure Site Recoveryhomesvsystemsbin

Microsoft Documentation

Fail Back VMware VMs and Physical Servers shows ability to add Configuration Server when deploying an Azure Process Server.  This is incorrect, the correct procedure is to login to the Azure Process Server and  enter Configuration Server IP Address and Configuration Passphrase of your on-premises Process Server.

Once linked you can confirm this by selecting Servers > Configuration Servers and your Azure Process Server should be listed under the on-premises Process Server

Microsoft Planned Reprotect Workflow

On Reprotect workflow, you select you Cache Disk for example E:.

During monitoring, the Cache Disk on your on-premises Process Server is not used.  Instead a VMDK is added to your on-premises Process Server for each protected VM

Planned Test Failback

No option to perform a test fail back to on-premises

Planned Failback IP Address & Port Group

Failback no option to change target IP Address or Port Group

Planned Failback Recovery Plan

Planned failback cannot be ran at Recovery Plan level.

Planned Failback Start-up Order

As no recovery plan is available.  A manual list of VM start up orders and actions needs to be maintained.

IP Address

If a VM has been failed over to Microsoft Azure previously.  The IP Address it was assigned is not available for use.  Even thought the output from the PowerShell command shows that the IP Address is available.

#Check IP Address Available

Test-AzureStaticVNetIP -VNetName "VMF-VNET" -IPAddress 10.3.240.102

Failback New Location

Microsoft require the original on-premises Process Server to be available to perform a failback to a new datacentre.

Final Thoughts

Microsoft has improved the Azure Site Recovery product with the ‘Enhanced’ version.  However a limitation at the moment is that for each protected VM you are tied to original on-premises Process Server.  Hopefully, the ability to decouple this and change Process Servers is on the roadmap.

As the product evolves it would be good to see the ability to perform Test Failbacks and use a Recovery Plan to failback to on-premises.  Having to failback VM’s on an individual basis is cumbersome and error prone.