Veeam Powered Network: Azure and Remote Site Configuration

This week we announced the offical GA of Veeam Recovery to Microsoft Azure featuring Veeam Powered Network (Veeam PN). This new product also features Director Restore to Microsoft Azure in combination with Veeam PN to create a solution that allows you to recover VMs into Azure and then have those VMs accessible on the original network by extending the on-premises network to the Azure networks. From there remote users can also connect into the Azure based Veeam PN Gateway and access services in all connected sites.

I’m going to step through the deployment of Veeam PN from the Azure Marketplace and then extend two remote sites into the Azure Virtual Network created during the initial configuration from the Azure Marketplace. Below is a logical drawing of the extended recovery network.

Components

Azure Subscription

Veeam PN Azure Marketplace Hub Appliance x 1

Veeam PN Site Gateway x 2

OpenVPN Client

The OVA is 1.5GB and when deployed the Virtual Machine has the base specifications of 1x vCPU, 1GB of vRAM and a 16GB of storage, which if thin provisioned consumes a tick over 5GB initially.

Veeam PN Azure Marketplace Deployment:

Once logged into the Azure portal, head to the Azure Marketplace and search for Veeam. You should see Veeam PN for Microsoft Azure.

Click on that that and then click on the Create button at the bottom of the Marketplace description.

From here you are presented with a six step process that configures the Veeam PN Azure VM and allows you to configure networking, initial security and site-to-site and point-to-site settings.

For my deployment location I have chosen Southeast Asia which is in Singapore. The username and password you select here will be used to access the Veeam PN web console and the VM via SSH.

Step 2 includes choose the VM size which I have set from Standard A1 to a Basic A1. The biggest difference from Standard to Basic is the inclusion of a Load Balancer service. One thing to note here is that when considering sizing for any VPN technology CPU and RAM is critical as that becomes the limiting factors in being able to process the encrypted connectivity. We will shortly have an offical sizing guide for Veeam PN but for the purpose of connecting up two sites with some external users the Basic A1 instance will do.

In the image above i’ve also configured the 172.16.0.0/16 Virtual Network. The default that Azure gives you is 10.0.0.0/16 which overlaps with subnets in the Columbus lab which is why I chose another private network range.

The last step shown above is configuring the subnet where the Veeam PN VM will be deployed into. This network can also be used by Direct Restore to Azure to place recovered VMs into.

This next step has you choosing the encryption key size for you VPN connections. We have put in a couple of options and depending on your requirements you can select relatively weak keys to very strong keys. As the note says next to the 2048 key recommendation, this does impact the deployment time as the time to generate higher key sizes. This means that you will need to wait at least 10-15 minutes after deployment to access the Web Console to complete configuration.

Setting up the VPN information is straight forward. In my example I have changed the port for the Point-to-Site connections to 6180 as I know this is a commonly opened port in our corporate network.

The final steps show you a summary and final confirmation to purchase the Marketplace item. There is no cost involved with Veeam PN its self, but be aware that you will be charged for all Azure resource consumption.

Once the job is submitted the deployment creates the Veeam PN VM and injects all the settings specified during this process. Taking a look at the Azure Resources created during the process you can see a number of different components listed.

Ill be putting together another post to dive into a few of those resources to show what is happening under the hood in terms of networking when other sites are added.

Finalising Veeam PN and Azure Configuration:

Once the Veeam PN appliance has been deployed successfully you need to complete a couple more steps to hook the Veeam PN service into Azure to allow the automatic injection of routes. To access the Veeam PN web console you enter in the DNS Name created during the initial setup. To view this after deployment is complete and also see the allocated Public IP click on the publicIP group in the Azure Portal.

If the Azure Marketplace deployment has been successful you we be greeted with an Azure Setup Wizard after logging into the Veeam PN web console.

NOTE: If you don’t get the Azure wizard and get the Out of Box Veeam PN setup prompt you haven’t waited long enough for the encryption keys to generate.

As explained this setup creates an Azure user to have access to the Virtual Network Routing Table. After hitting next you need to authenticate the Veeam PN appliance with Azure by clicking on the link provided and entering in the code to authenticate.

Once completed you can further confirm the setup was successful by clicking on Settings and then look at the Services tab. You should see all three options toggled to On.

Clicking on the Azure Tab will show details of the Azure network and deployment settings.

Veeam PN Site Gateway Deployment and Configuration:

I’ve covered in detail during the RC period of Veeam PN how to setup and deploy site gateways to connect back into the Hub. The Hub doesn’t have to live in Azure and there are use cases for Veeam PN to be used standalone, but lets continue with this setup. I went and configured the two sites as shown below. You can now see their subnet addresses in the web console…another added feature in the GA release.

I’ve also configured the Standalone Client that will enable me to connect from my MBP into the Hub and then get access to the networking resources. One new GA feature that has been added here is the ability to enable all traffic to flow through the Hub server as the default gateway…meaning all traffic will pass through Hub.

At each site a Veeam PN Site Gateway appliance gets deployed and is configured with the generated configuration files done in the steps above. Once connected the Overview page will show all sites connected via the Site-to-Site VPN. As of now, Azure, Columbus and my Home Lab are all part of the one extended network.

Backing Up Veeam PN Config and Version Updates:

For the GA version, we have introduced a couple new UI features based on feedback and usability. The first thing to do once you have finished the initial configuration is to head to the System Tab under Settings and Backup the config. This will download a configuration file that can be imported into a clean Veeam PN appliance if anything happened to the production instance.

There is also a new Updates tab which will Check for Updates and, if available Update to a newer build while retaining the current configuration.

Conclusion:

Once everything is connected and in place we can now restore a VM from anywhere and make it available to the extended networks configured in this example. There are a few more things to cover in regards to making the recovered application available from it’s origin network however I will cover that off in future posts.

Below is a summary what I have shown in this post:

Deploy Veeam PN from Azure Marketplace

Finalise Azure setup from Veeam PN Web Console

Setup Site Configurations

Deploy Veeam PN OVA to each site and import site configuration

Backup Veeam PN Hub configuration

Those five steps took me less than 30 minutes which also took into consideration the OVA deployments as well…that to me is extremely streamlined, efficient process to achieve what in the past, could have taken hours and certainly would have involved a more complex set of commands and configuration steps. The simplicity of the solution is what makes the solution very attractive…it just works!

Share this:

Related

5 comments

How long will it take to restore to Azure is the question?I see this working well for SME’s where we could offer this as a DR solution ..however if a clinet has a 1 TB VM..it is going to ake a considerable time to restore to Azure …Can it be seeded in any way ? Or is this on demand?

Hey here. We have labeled this recovery to Azure and specifically not Disaster Recovery to Azure. The reason for that is because there is a time cost associated with the restoration process from VBR into Azure. This is something that can’t be controlled and is dependant on a number of factors and therefore attaching an SLA to the recovery process would be difficult. This is not an instant DR solution where a VM is seeded or replicated to Azure before disaster strikes. It’s on demand and as quickly as you can restore into Azure from the on-premises location into Azure.