How To: Veeam Cloud Connect Replication and Partial Failover to Microsoft Azure
Hey CDub here – Happy Friday the 13th!
This is blog post is meant to completely document the entire process of getting Veeam Backup & Replication Replication operating with Veeam Cloud Connect running in Microsoft Azure and able to perform a partial failover of a Hyper-V replica.
Earlier this year at Microsoft Build the public announcement of nested virtualization (sometimes called paravirtualization) within Azure would be supported with the new Dv3 or Ev3 VM sizes.
These VMs are the first of their kind for Microsoft for a few reasons:
- These hosts run on Windows Server 2016
- Hosts based on the Intel Broadwell E5-2673 v4 2.3GHz and the Intel Haswell 2.4GHz E5-2673 v3 processor. These new processor types enable the ability to introduce Hyper-Threading and a shift from physical cores to virtual CPUs (vCPU) in the Azure VM sizing.
Microsoft has a few great articles and videos that illustrate how to get this setup within Azure – so I’m not going to focus on that. I’ll just point out that within Azure MAC spoofing is not supported and will not work so you’ll need to create a NAT Network for the level-2 VMs that are running on the Hyper-V host. This process is fully documented by Microsoft and is, in fact, a fully supported configuration.
In my testing, I utilized the US East data center and the Standard D16s v3 VM with 16 vCPU / 64 GB RAM. I also added a 1 TB data disk to the VM (G:) with ReFS 3.1 for my VMs. I also added a second data 1 TB data disk (H:) again formatted with ReFS 3.1 which would be used as a Cloud Repository for Cloud Connect backups. This drive could also be used for host-based backup of your level 2 VMs running on your nested Hyper-V host (yes, this works with on-host proxy mode). For this post, I’m utilizing Cloud Connect Replication acting as a Service Provider type setup. The great part about Cloud Connect is it doesn’t require an Azure ExpressRoute or any type of direct connection to Azure. All of the traffic goes over the internet secured by TLS along with a provider controlled certificate.
One additional configuration in Azure needs to happen – On the Network Security Group that your Hyper-V / Veeam nodes reside you should create Inbound and Outbound security rules to allow:
- TCP 6180
- TCP 1195
The port requirements for Veeam Cloud Connect are documented here.
The Virtual Switch Manager (seen below) shows that I have created an external vSwitch as well as an internal vSwitch named VmNAT. The level 2 VMs are placed on the VmNAT network. You can statically assign IP address to these VMs or if you choose, set up a DHCP server so that as new VMs are provisioned on the VmNAT network they’re automatically assigned an IP within the correct range and are able to get out to the internet.
Once we have our host networking correctly configured the remainder of the steps completed are done within the Service Provider and Tenant Veeam Backup & Replication consoles. In this case, Veeam is installed on the same Hyper-V host as my VMs – everything is completely self-contained on this single Hyper-V node. I’ve also added the standalone Hyper-V node to my Veeam console. With this, we can now set up our Cloud Gateway, Cloud Backup Storage, AND Hardware Plan.
1.) Service Provider Hardware Plan Creation
The Hardware Plan is the main point of this blog post as this is where we define the amount of Compute, Memory, Storage, and Networking that the tenant replicas have access to. Essentially is like a hardware quota per se.
2.) Service Provider Tenant Creation & Assignment
The Tenant account is responsible for defining a set of resources that an on-premises Veeam Backup & Replication server is able to consume. These resources can be either Cloud Backup or Cloud Replication – these are simply defined in the New Tenant Wizard.
Assign the correct Hardware Plan to the tenant account and choose to utilize the built-in network management capabilities during the failover. This will deploy the Network Extension Appliance (NEA) within your Azure Hyper-V host as well as on the tenant side as well. The NEA is a virtual appliance based on OpenVPN that’s responsible for bridging Layer 2 network connectivity between the tenant side and the replica running in Azure. During the partial failover scenario both NEAs are automatically powered on so that users can access the application/service/VM just as they would during normal operation – the only difference is that it is running in the Cloud and not at the primary site.
One of the most important steps of this entire configuration process is next, so pay attention 🙂 The NEA should be edited in the wizard and given a static IP address on the VmNAT network so that the VM that’s being failed over can have external access to the internet.
Once we finish the wizard we’ll now see that we have in Hyper-V Manager, an NEA deployed (powered off). In a scenario where multiple tenant accounts are created, each NEA deployed has the tenant name within the “Name”.
We’re now ready to configure the Tenant side and start our replication!
3.) Tenant Configuration
The large majority of the configuration is now completed and our Azure instance is ready to receive our Veeam Backup & Replication Hyper-V Replicas.
Within the Tenant Veeam Backup & Replication console navigate to the Backup Infrastructure pane and add the FQDN of your Azure instance.
After the connection to the Azure-based Service Provider is the tenant can see the backup resources as well as the hardware plan that they have been assigned. As we mentioned earlier, the NEA is deployed both in the Cloud as well as on-premises. The tenant should also assign the NEA a static IP address – this is done here:
After completing the wizard the NEA is deployed to the specified Hyper-V host or cluster on-premises and left in a powered off state. Once the partial failover is initiated the NEA will be powered on and the VPN connection between the provider and the tenant is established.
4.) Replicate to Azure!
With the first few steps completed, we’re now set to replicate our first VM to Azure. If you’ve used Veeam before to replicate to another Hyper-V environment the steps are exactly the same.
We’ll want to enable the network remapping since the source and destination networks are different.
Now we need to pick the critical VMs we’d like to replicate to our Azure provider. The difference being that for on-premises/private cloud replication you’d pick Hyper-V from the drop down – in this instance, we’re replicating to our Cloud host.
Network re-mapping, choose the source Network as well as the Network defined within the Hardware plan. If any type of VLAN tagging is being utilized on-premises you’ll want to make sure you note this here.
The rest of the replication job creation is straightforward. If your VM has an application like Active Directory, SQL Server or Oracle you’ll want to use the Guest Processing/Application-Aware-Image Processing.
5.) The Wrap Up
Now that we’ve set everything up and our replication is happening, its inevitable – things break! So lets take a quick look at the partial failover. This is initiated through the On-Premises Veeam Backup & Replication console – so it’s initiated by the tenant. This is kicked off by choosing Failover Now…
Here are a few illustrations of the job log from a Failover, Failback and Commit Failback.
Failover:
Failback:
Commit Failback:
Note: Veeam Cloud Connect is an available technology primarily for Service Providers. This tech is also available Enterprise Customers that have a Microsoft Enterprise Agreement (EA) or VMware Enterprise License Agreement (ELA).
For the complete demo of the entire partial failover process as well as how to commit changes and failback to the production site, check-out this video!
