Previous Post in Series: Part 4: ASR Enable Replication for VMware VMs
Overview
Welcome back folks, in this part of the guide we’ll be running through a DR-Drill for one of the VMs we protected in the last section. Feel free to extend this drill to include multiple VMs if you’re feeling fruity 🙂
A couple of things to note before continuing:
- Did you make sure to enable RDP on the public profile?
- Or are you connecting to the VMs over a VPN connection?
- Did you apply all pending Windows Updates?
- If not, these will be applied as soon as the VM comes up in Azure, locking you out from RDP for a bit
So assuming we’re all good, let’s continue.
Kick off a Test Failover
For test failovers, we’d generally want to create a Virtual Network that’s basically a carbon copy of our Production Virtual Network, i.e. same address space, same subnets etc.
Ahh Screw it!, we should probably just go and do that…OCD for the win.
Before continuing, go and create the following resources:
- A new Resource Group in the same region as your ASR resources, name it “ASR-TestFailover-RG”, so something similar
- Create a new Virtual Network (VNET) and place it in the above Resource Group
- Use the same “Address space” you used for your Recovery Services VNET earlier in the guide
- Deploy it into the same region as the above Resource Group
- Configure the “Subnet(s)” exactly as you did for the RSV production VNET you created earlier in the guide, including using the same names for the subnets
- You’ll receive a warning if you’re doing it correctly, ignore it:
- Create an NSG in the resource region and resource group as the above VNET
You can find the process for creating both of these earlier in the guide, HERE
OK, now that’s out the way, we can do this right.
NOTE: In a production scenario, it’s likely that you’ll have to consider Active Directory and DNS in your DR plans. You can find more details on that HERE. As we’re just lab’ing this though, it doesn’t matter so we can skip that step…well that and I don’t have an AD/DNS server to replicate.
We’ll start by picking a VM to run a test failover against.
- Within your RSV, navigate to “Replicated items”
- Select the VM you want to run a test failover against
The VM is “Healthy” and “Protected”, so we’re good to continue. This next step is optional, but hey why not:
- Click the VM and navigate to the “Compute and Network” blade
- Click “Edit” in the top left
- Change the “Name”, “Resource Group” and “Size” of the VM
- When you’re finished, click “Save”
We’re not in a good place to initiate the test failover.
- Navigate to the “Overview” blade
- Click “Test Failover”
- Choose the “Latest processed” Recovery Point to provide the best RTO
- Select the test failover VNET you created earlier
- Click “OK”
…and now we wait. You can monitor the progress of the job from the “Site Recovery Jobs” blade.
Clicking the job will give you a more detailed breakdown of which step it’s on.
As you can see from the screenshot, the job completed before I had a chance to look.
Let’s go and have a look at our shiny new/existing VM.
- Navigate to the test failover Resource Group you created earlier.
- Select the Virtual Machine
If we look at the “Boot Diagnostics” blade we can see that the VM is up and running with a network connection
So before we go and close this one off as successful, let’s actually RDP onto the VM.
- Navigate to the “Networking” blade of the VM
You should see the “Allow_RDP” rule we added to our NSG earlier in the guide. You should also notice there is no “Public IP” listed, let’s remedy that.
- Click the “Networking Interface” link
- Click the “IP Configurations” blade
- Click the only existing IP configuration
- Select “Enabled” for “Public IP address”
- Click “IP address”
- Select “Create new”
- Change the “Assignment” to “Static”
- Click “OK”
- Click “Save”
We should now be able to connect to our ASR test failover VM.
- Navigate back to the VM “Overview” blade
- Click “Connect”
- Click “Download RDP File”
- Click “Open” on the download pop-up
- Log in with any crednentials enabled for remote logon
Here’s a look at the VM happily running from Azure with its new improved resource allowance.
Operation Failover Clean-up
OK, so failover works and we no longer need this VM running, time to clean up after ourselves. You can see the status of the protected VM we have a test failover for has changed to “Clean test failover pending”
- Click on the relevant protected VM
- In the “Overview” blade, click “Cleanup test failover”
- Populate the “Notes” field with something deep and inciteful
- Place a tick in “Testing is complete…”
- Click “OK”
NOTE: This will go ahead and delete the failover VM that was deployed including all supporting resources…with the exception of the Public IP address we created manually.
You can view the progress of the clean-up job from the “Site Recovery Jobs” blade
Once the clean-up job has completed, the status of your protected VM should revert back to “Protected”
Here’s what the Resource Group we deployed our failover VM into should now look like, post clean-up. At the very least, I would go ahead and delete the Public IP address or you can delete the entire Resource Group, although it’s probably worth leaving that for future failover tests.
That should do it for this section. In the next part of the guide we’ll be running through an actual DR invocation…hope to see you then.