Previous Post in Series: Part 3: ASR Deploy a Configuration Server
Overview
Welcome back folks. In this section of the guide we’ll be setting up the replication of our VMware VMs to a recovery vault in our Azure subscription. Once we’ve successfully replicated one or more of our VMs, we also run a DR-Drill to confirm that’s all working as intended (next section of the guide). Let’s get on with it:
Enable VM Replication
A couple of points before we get started, I may have already covered these earlier but they bear repeating anyway:
NOTE: When enabling replication, the OS drive must have at least 1 GB of free space.
NOTE: VM data disks can be dynamic, but the OS disk must be “Basic”
As you’d expect, we’ll be carrying out the next few steps from our Recovery Services Vault, so…
- From your RSV, select the “Site Recovery” blade (under “Getting Started”)
- Select “Step 1: Replicate Application”
Once the “Source” blade has loaded:
- For “Source”, select “On-premises”
- For “Source location”, make sure your Configuration Server is selected
- For “Machine Type”, select “Virtual Machines”
- For “vCenter server/vSphere host”, make sure your vCenter server is selected
If you’ve been following this guide, your Process server role is co-located with your Configuration server, if you have a dedicated Process server feel free to use it:
- For “Process server”, select your “Configuration Server” or dedicated process server
- Click “OK”
Now we’ll configure our “Target” blade
- Confirm you have the correct subscription selected
- For “Post-failover resource group” selected an appropriate RG
NOTE: I’ve selected the same Resource Group I’ve been working with since the start of the guide, in production you’d likely select a different Resource Group here.
- For “Post-failover deployment model”, make sure “Resource Manager” is selected
- For “Azure network”, select “Configure now for selected machines”
- For “Post-failover Azure network”, select the VNET you deployed earlier in the guide
- For “Subnet”, select the “default” subnet you created with the VNET
- Click “OK”
Now on to the “Virtual Machines” blade
- Select whichever VMs you want to enable replication for
- Click “OK”
On to the “Properties” blade
Here you can configure the “Default user account” which will apply the same setting to each replicated VM. You can also then choose to overrule specific properties on a per VM basis. In this guide though, I’ll be using the same settings for all VMs.
- For the “Default user account”, select the “Managed Disk Type” that best covers the majority of the VMs you profiled earlier in the guide
- For the “Cache Storage Account”, let the wizard create a new one
- For the “User account to install Mobility Service”, select the local administrator account you created on each VM earlier in the guide
NOTE: The last step is dependent on whether your machines are domain joined or not and what accounts you added when setting up your Configuration Server.
NOTE: By default “All disks” are replicated but you can overrule this as required, however there are a few caveats to this. You need to have already installed the Mobility Service manually, also, OS disks and dynamic disks cannot be excluded and must be replicated.
- Change the properties of specific VMs as required, or leave the defaults
- Click “Create target resources”
Almost done…on the “Replication settings” blade
- Confirm the correct “Replication policy” is selected
- View the specific properties of that policy to make sure you’re happy with them before continuing
NOTE: You have the option at this stage to create a new “Replication Group” to enable “Multi-VM consistency”…this will group machines together for replication and failover. For the purposes of this guide, we’ll replicate and failover our VMs individually.
- Click “OK”
Assuming everything went as expected, you should now be looking at a whole bunch of green ticks.
- Click “Enable replication”
NOTE: At this point the “Mobility Service” will be installed onto each VM that’s being enabled for replication.
We can monitor the progress of our replication jobs:
- Navigate to the “Site Recovery Jobs” blade, under “Monitoring”
…and now we wait.
In the interest of transparency 🙂 One of my “Enable replication” jobs actually failed:
Clicking on the error to see why immediately pointed at it being my fault and apparent inability to follow my own instructions.
The high level error details:
Now I’d already worked out by this point what was causing my issue, but here’s the specific error details anyway just to confirm it.
Basically, I’d deployed the “DF-Jumpbox” VM recently with the intention of using replicating it to Azure, however as I did this a while ago I’d forgot to add the firewall rules required to install the Mobility Service via the “push” method.
With that in mind, I ran the PowerShell I included earlier in the guide, HERE
With that attended to, I restarted the “Enable replication” job for that VM.
About 15 minutes later, all was well, both VMs are now being replicated.
Time for a coffee? I think so.
Walkthrough of a Protected VM
OK, so coffee now in hand, let’s have a look at what information we get regarding out protected VMs…well the first question should be, are the fully protected yet? Well that depends on the size of your VM(s) and how long it took you to get that coffee 🙂
Let’s have a look at the replication progress:
- Select the “Replicated items” blade under “Protected items”
Here we can see one of my VMs is now fully protected while the 2nd one is still “Synchronising”
Let’s leave that VM to get on with it for a bit and instead look at the one that’s completed synchronisation.
- Select any VM you’ve protected that’s showing as “Protected”
Now we’ll step through each blade and cover the highlights.
Overview Blade
The Overview blade shows the kind of information you’d expect, current “Replication health”, “Last successful failover”, “Agent version”, “Errors” etc. however, there are a few really nice bits of information on this page, for example:
Recovery Point information
- Click the “Latest recovery points” link in the top right, here you see:
- The latest crash-consistent and app-consistent RP
- The most recent 5 RPs, including their type
The Overview blade is also the place where you would action your DR-drills (Test failovers) from, including after the fact clean-up operations etc.
At the bottom of the page, we’re also presented with an “Infrastructure” view in the context of the current VM. This can be viewed in two ways, as a “Diagram” or a “Table”:
NOTE: Switch between both modes by clicking the link (see screenshot)
Diagram:
Table:
Properties Blade
We won’t go into too much detail on this one as it’s pretty self-explanatory but worth having a look at when you get a second.
A few key pieces of information you’ll find here are:
- Replication Policy used
- Operating system
- RPO
- Daily data change rate
- Target role size
Compute and Network Blade
This blade is where you can make changes to the compute and network properties of your protected VM that’ll be used in the event of a failover (invoked or drill). As an example, let’s say I’m not happy with the VM SKU ASR has chosen, “F2s_v2”, we can change that:
- Click “Edit” in the top left
- Click the drop-down under for “Size”, “Microsoft Azure”
- Select another sensible SKU from the list, e.g. “D2s_v3”
In addition to the above, you can also specify that you are able to make use of “Azure Hybrid Benefits” to license your Windows VM
NOTE: For AHB licensing, that means you have subscription based Windows Server licenses or you have Software Assurance on them.
With regards to on-premises network for your VM, Azure picks the NIC with a default gateway configured and sets it as the “Primary”, you can overrule that here if required.
I’ll now go ahead and apply by changes:
- Click “Save” in the top left
Disks Blade
Again, not too much beyond the obvious here, this blade provides a breakdown of the disks that are being replicated as part of your protected VM. A couple of bits of information worth mentioning calling out:
- Disk “Volume” letters
- Disk status e.g. “Protected”
- Disk “Size”
- Disk “Type”
If you’re interested, go and have a look in the Resource Group you targeted when enabling protection, you should see the following new resources:
- A managed disk for each protected VM disk
- A new Storage Account
Before we move on we should probably check on the status of each of our protected VMs:
Nice, we’re all good, hope to see you for the next part of the guide where we’ll be running through a DR-Drill.