At this point in the migration process, an organization would have migrated the initial 3-5 simple workloads (Virtual Machines) to Azure. Also, they will have gotten familiar with Azure administration and management and have run the Cloudamize tool to assess the next series of workloads that will be migrated to Azure.
With an additional 12-15 servers being targeted for migration to Azure, the organization may need to extend their initial network integration to Azure with a more Advanced Networking solution. More robust networking scenarios may need to be implemented to provide redundant connections to Azure to implement high availability, load balancing or integrated Virtual Networks (VNets) or Border Gateway Protocol (BGP) configurations to Azure.
With plans to migrate additional workloads to Azure, organizations typically want to improve redundancy and high availability to Azure, exceeding that of the initial single virtual network established in the migration of the first couple workloads to Azure. Within Azure, one can connect virtual networks to each other that span multiple Azure regions or have multiple connections from on-premises datacenters to an Azure virtual network, or both. You can also advertise your Azure subnets with your existing BGP to the on-premises network. All these work hand in hand to increase the redundancy and availability of your Azure workloads.
In the initial Azure Site-to-Site network connection, the network connection from the customer datacenter to Azure was created, establishing a simple extension of the customer's datacenter to Azure. A common next step in networking is to create a Virtual Network to Virtual Network (VNet-to-VNet) connection and configuration.
This establishes a second connection from a customer's on premise network to Microsoft Azure. This is typically done where the second connection interconnects to an additional (different) Azure site or region. This dual-site/region connection extends Azure connectivity so that if there is an Azure site failure, another site (or region) is connected to the organization's datacenter. This provides redundancy in the network connectivity to (and across) Azure sites.
Important notes:
Following the guide here, provision a second Virtual Network and Virtual Network Gateway and connect it to the first virtual network. This guide assumes there is not an existing virtual network, so if you are using an existing network such as the one from the start of this document, pick up at Step 6.
Once the networks are connected, you can migrate workloads to the second Virtual Network which now offer high-availability to the workloads in the first network. Workloads such as a SQL Server Always On Availability groups can benefit from such a setup.
Another common request by organizations to extend Azure in a more robust configuration is to tie the networking in Azure to the customer's existing BGP network configuration. BGP is a common routing protocol that advertises network segments and routes as part of a networking environment. With BGP configured and enabled, Azure routes and networks interact better with on-premise BGP advertisements and routing management.
Configuring BGP on your Azure VPN gateway enables Azure network to advertise the routes into the on-premises network and save the need to add static routes. This is also a stepping stone to the next example: multiple and redundant gateways to Azure.
Important notes:
Following the guide here, configure the virtual network for BGP. The virtual network created at the beginning of this document or the virtual network created above with the VNet-to-VNet connection can be reconfigured for BGP routing and it does not require creating all new networks. Once this configuration is done, check the advertised BGP routes in the on-premises router to be sure peering is successful and the correct routes are advertised.
Just as multiple Virtual Networks enabled redundancy and even geo-redundancy on the Azure side of networking, configuring a secondary gateway in Azure allows for the interconnection of Azure to multiple on-premise networks. Multiple gateways increase redundancy of the VPN connection as well as connecting the on-premises network from multiple locations.
Important notes:
Following the guide here, configure the virtual network gateway for high availability. Like in the last section, the guide assumes you are creating new networks. This is not necessary if they already exist. Part 4 covers reconfiguring an existing gateway to be an active-active gateway by assigning the second IP and updating the SKU. From there you can continue with Part 1, Step 2 as the ASN still needs to be set along with the rest of the BGP configuration.
Once both gateways are configured on the Azure side and the on-premises side, this configuration will be both highly-available and redundant. Traffic will be balanced between the 4 tunnels, though traffic state will be respected. There may be a performance increase, but the goal is availability more than performance.
With workloads likely needing to be highly available, an Azure load balancer is recommended to distribute traffic among healthy instances. It can be configured to balance Internet traffic or internal traffic to the load balanced set and also specific monitors can be created for the load balancer to check health of the members.
Following the guide here, deploy an internal load balancer and add network interfaces to workloads in need of high availability. Test connectivity from the on-premises network to the load balancer IP to ensure that local network machines can access the workload behind the Azure load balancer. Depending on how the workload handles load-balanced connections, you may need to adjust the distribution mode ("stickiness" or affinity) of the load balancer as detailed here.
This advanced networking scenarios guide was intended to help an Azure architect with the more complex integration of on-premise networks with Azure networking, a common requirement as 10, 20, or more workloads are deployed into Azure. With a more robust network implementation, the organization can begin the task of migrating more complex workloads like SharePoint, Exchange, SQL Servers and the like to Azure, leveraging tools like Azure Site Recovery as the replication and migration solution.
The MSP Azure Migration program has additional library resources that will provide guidance for the architects on more complex workloads like full SQL Server migrations, Clustered Server migrations, Linux workload migrations and the full implementation of Azure Site Recovery for workload replication and failover to Azure.