Azure Multi-VNET Topologies in the ARM Era (Part 1)

If you have visited before on the pages of this blog, you may have seen this article : “Azure VNET to VNET VPN, across regions and data centers: not so complicated”. At that point, I wrote about how to put in place a connection between multiple Azure Virtual Networks, in particular a VNET-to-VNET-to-VNET relationship. All based on PowerShell scripting and classic deployment in Azure.

Today is the time to write again about this subject, but this time under a new cover related to several aspects: ARM (Azure Resource Manager) deployment,  usage of the new Azure Portal, and application of new networking concepts in Azure, like VNET Peering.

This is a two-part series of articles on these aspects. The series is related to the publication of a dedicated MS Experiences Online recording. In the recording we speak about these concepts, so I will focus here mainly on detailing and documenting the forenamed recording.

The first article includes the business case, the networking concepts and topologies and their applicability in Azure, and the technical solution we propose for the given use case.

Business Case

We propose to make communicating multiple environments (or resources) between each-other, in a IaaS (networking) context. That may be within the same Azure data center or region, or across regions. For this, we are required to put in place network connectivity between these environments.

To put it even more concrete, we chose to facilitate the deployment of a SQL Server AlwaysOn Cluster (available with SQL Server 2012 editions and later ones), cluster to be deployed as follows:

- 1 primary replica in Dublin (North Europe region)
- 1 secondary replica in Dublin
- 1 secondary replica in Amsterdam (West Europe region)

The solution will be focused on the network connectivity aspects, and not on the network security ones.

Azure Technical Concepts and Services

The following concepts will be used in the next lines, so we need to reference first the corresponding definitions in the Azure documentation:

- VNET – Virtual Network, Subnet [https://docs.microsoft.com/fr-fr/azure/virtual-network/]
- Public IP [https://docs.microsoft.com/fr-fr/azure/virtual-network/virtual-network-ip-addresses-overview-arm]
- Network Interface Card [https://docs.microsoft.com/fr-fr/azure/virtual-network/virtual-network-network-interface-overview]
- VPN Gateway [https://docs.microsoft.com/fr-fr/azure/vpn-gateway/]
- ExpressRoute [https://docs.microsoft.com/fr-fr/azure/expressroute/]
- VNET Peering [https://docs.microsoft.com/fr-fr/azure/virtual-network/virtual-network-peering-overview]
- Network Security Group [https://docs.microsoft.com/fr-fr/azure/Virtual-Network/virtual-networks-overview]
- Virtual Appliances [https://docs.microsoft.com/fr-fr/azure/virtual-network/virtual-networks-overview]
- User Defined Routes [https://docs.microsoft.com/fr-fr/azure/virtual-network/virtual-networks-udr-overview]

Most of these are already known and used from some time. I will insist on one concept only: the VNET Peering. As stated in the documentation, it practically allows you to join 2 VNETs located in the same region, by passing directly through the local backbone without needing a VPN gateway. This is very practical, as the VMs across the 2 VNETs will communicate with each-other on a bandwidth limited by the VMs’ network cards only.

Initial Environment

Let’s take a look at the networking structure of the original environment as we assumed it in our scenario.

The first VNET, named “net1dublin”, based in Dublin DC (North Europe): a classical VNET configuration, with a 10.0.1.0/24 range and composed from a single subnet named “default” having 10.0.1.0/25 range.

clip_image002_thumb[1]_thumb

There is a single virtual machine deployed in this subnet, named “vm1net1”, having attached one network card with the IP address 10.0.1.4. As remark, the access to the VM is controlled via the Network Security Group “nsg1net1”.

Similarly, we have a second VNET in Dublin, “net2dublin”, range 10.0.2.0/24, containing the VM “vm2net2” with the IP address 10.0.2.4.

clip_image003_thumb[1]_thumb

Finally, the third VNET, deployed in Amsterdam DC (West Europe), is named “net3amsterdam”, has an IP range of 10.0.3.0/24 and contains the VM “vm3net3” having the IP address 10.0.3.4.

clip_image004_thumb[1]_thumb

In our scenario – a SQL Server AlwaysOn cluster – we would have:

- “vm2net2” : primary replica (“master”) in Dublin
- “vm1net1” : a synchronous secondary replica in the same region
-“ vm3net3” : an asynchronous secondary replica in Amsterdam.

Networking Architectures and Topologies

1. Simple hybrid topology

First of all, will remind the simple topologies, starting with the “classical” hybrid Azure-VNET-to-On-premises-Network:

image

This “point-to-point” topology es at the base of all coming ones. The connection is made either over public internet (IPSec Site-to-Site VPN Azure, via an VPN Gateway in Azure and a network gateway device on-premises), or over private infrastructure (Azure ExpressRoute + typical MPLS infrastructure put in place for you by the provider of your choice and availability). You can have – if you need, for example, in a HA / DR architecture – both S2S VPN and ExpressRoute working at once.

2. Simple cloud-only topology

Now we’ll apply the same concepts for S2S VPN, but this time between 2 VNETs (in the same region or across regions):

image

So the solution is quite similar, but you will simply pass through the Microsoft backbone infrastructure. Note that you can make profit of your hybrid ExpressRoute circuit – if any – to put in connection Azure VNETs also. In that case, the S2S VPN Gateways will be replaced by ExpressRoute ones.

Under the same simple cloud-only topology, you may have this time a VNET Peering put in place (if the VNETs are in the same region):

image

Note that you can connect either ARM-to-ARM VNETs or ARM-to-Classic VNETs. This is a perfect solution for Azure “legacy” infrastructure” (a bit strange to speak about “legacy” in Azure Smile ) deployed on classic networks, in order to avoid their migration to ARM if not absolutely necessary, while still let them communicate with all the new [ARM] deployments.

3. Complex topologies: Hub & Spoke

When the requirements become more complicated, we will use adapted connectivity patterns to cover them. Here is the “Hub & Spoke” topology.

Cases are when there is a central system which needs to communicate with “satellite” systems. In the case of an SQL Server AlwaysOn cluster with multiple replicas for higher availability and throughput, the VNET of the master replica will be “surrounded” by the VNETs corresponding of secondary replicas.

image

In this case, we will configure simple bidirectional communications between the master VNET end the satellite VNETs. Any of the direct connectivity options described before (IPSec VPN, ExpressRoute if the case, or Peering) can be used here.

Note that the Hub & Spoke topology doesn’t imply connectivity transitivity : the left VNET won’t (necessarily) communicate with the right one.

4. Complex topologies: Daisy Chain

The transitivity comes into the game in the Daisy Chain topology. The left VNET will communicate with the right one via specific routing configuration set up in the middle VNET:image

This can be achieved in Azure via User Defined Routes functionality. But you will find another solution out a bit later in the article.

If the Daisy Chain topology has the advantage of getting profit of a connection already established (e.g. center with right) for the usage of another VNET (left one), you may have surely seen its inconvenient also: if the VNET on the center (or its gateway) loses its connectivity, it will also affect the connectivity between the lateral VNETs.

5. Complex topologies: (Full) Mesh

The Full Mesh let you master with precision the direct connectivity between various VNETs, without having dependencies on intermediate VNETs or their gateways :

image

On the other side, definitely there is much more work to getting it done; also, the complexity increases exponentially with each new VNET you want to add to the topology.
You may remark, by the way, that the picture reflects a Mesh which is not “full” actually; it’s up to you to decide if you want the left VNET communicate with the right VNET.

How do you implement a topology like this in Azure? The VPN gateways let you create this type of connectivity, but you can put it in place very quickly with multiple VNET peerings.

 

Technical Solution for the Given Scenario

Let’s depict the technical solution we propose for our business case:

image

So, recall that we have a primary replica in VNET2, and we need a secondary replica in VNET1 and another one in VNET3.

The solution is composed of 3 main segments:
1. VNET Peering between VNET2 and VNET1 (both VNETs being in the same region)
2. Site-to-Site VPN connection between VNET1 (Dublin) and VNET3 (Amsterdam), with VPN Gateways deployed in both VNETs
3. Transitivity for the VNET2 to VNET3 through the VPN Gateway 1. This connection transitivity will be configured in the VNET Peering settings directly.

Implementation

You will find the implementation of this solution in the next (and last) article of this series: http://blog.lecampusazure.net/2016/11/azure-multi-vnet-topologies-in-arm-era.html.

Aucun commentaire:

Enregistrer un commentaire