We are ready to failover our on-premises vSphere virtual machines to Azure. Before we do it’s important to verify that our Configuration Server and Master Target Server are functioning correctly.
In the Azure Portal, select Recovery Services > VMFocusVault > Servers > Configuration Servers > Select Configuration Server. Verify that displayed details are healthy.
Before we proceed any further, it’s worthwhile noting that Azure Site Recovery is in it’s infancy from an on-premises vSphere to Azure perspective. Therefore it’s worthwhile noting that:
- Only unplanned failover is supported
- If you want your data to be consistent, shutdown your protected VM’s on-premises and wait for the next replication interval to complete
We need to create a Recovery Plan (which I would expect you to have in place already). The purpose of a Recovery Plan is to group together virtual machines which should failover together.
- Virtual Machines across different Protection Groups can be in the same Recovery Plan. The use case for this is perhaps you have a three tier application where VM1 RPO is daily, VM2 PPO is 4 Hourly and VM3 is Hourly.
- Once in a Recovery Plan, virtual machine start up order can be determined
- Before a virtual machine is started a manual action can be inserted e.g. prompt to verify that a service has been checked before moving onto the next step
- Before or after a virtual machines is started a script can be triggered
To create a Recovery Plan select Recovery Services > VMFocusVault > Recovery Plans > Create Recovery Plan
I’m going to create a single Recovery Plans called VMF-RP01:
- Virtual machine VMF-AZ01 needs to maintain it’s current IP address, as if I had stretched my on-premises layer 2 network into Azure
- Virtual machine VMF-AZ02 need a new IP address and therefore will be RE-IP’d as part of this process
- VMF-AZ01 needs to start before VMF-AZ02
The screenshot below confirms the name of the Recovery Plan I have created called VMF-RP01.
As described the Protected Entities are VMF-AZ01 and VMF-AZ02.
Once the Recovery Plan is created. Select the it by clicking on it’s name (in my case VMF-RP01) and you will see the following screen.
By default all VM’s will be started and stopped at the same time. To change this select the Group+ icon and you will see a Group 2 has been created.
Expand Group 1 and Select VMF-AZ02 and Select Move Virtual Machine > Group 2
Once done it should look like this
Note: Don’t forget to save your changes to the Recovery Plan
Time to failover, to test things properly, I’m going to mimic an actual disaster in which our on-premises virtual machines are unable to communicate with Azure Site Recovery. The easiest way for us to do this is to disable the virtual NICs on our on-premises Process Server, VMF-AZ01 and VMF-AZ02 in vCenter.
Back to the Azure Portal, Select Recovery Services > VMFocusVault> Recovery Plans > Failover
Select either Latest Recovery Point In Time or Latest Application Consistent Recovery Point
That’s it sit back and make a cup of tea whilst our Recovery Plan goes into full effect. If however, you do want to monitor the Job, select View Job.
In total VMF-RP01 took 24 minutes to complete.
We should now see two more virtual machine instances available.
Checking the virtual machines, I can verify the following:
- VMF-AZ01 is on IP Address 10.3.2.74 which is our extended on-premises Layer 2 network
- VMF-AZ02 is on IP Address 192.168.37.75 which is our routed Layer 3 network
Interestingly, EndPoints aren’t configured for RDP and PowerShell as per a standard virtual machine deployed in Azure. External access if required, will need to be configured manually.
In the next blog post, we are going to reprotect and failback to on-premises.
3 thoughts on “Failing Over To Azure Site Recovery”
Hi There, I have noticed that when I recover my VM’s its not domain joined. My recovery plan is configured to bring Domain Controllers first then run a script to add remote and Powershell endpoints. Then recover the rest of the vms. All my vms can ping each other but all is showing as not connected to a domain network. They show as public network. Even the domain controllers is showing up as public network. In my ASR setup I’m replicating vms across the Internet. Have you came across this problem? Am I missing something. All Vms has been recovered with the exact same IP addresses as on-premises….
Thank you in advanced
Hi Warren, thank you for reading the blog series. First of all I would recommend having Domain Controllers already up and running in Azure with AD Connect, so you don’t need to fail these over.
In relation to the network, have you specified which vNET you want your VM’s to come up in? This can only be performed after the initial replication. See bottom of part of this post https://vmfocus.com/2015/10/28/how-to-install-configure-azure-site-recovery-part-4/