Azure Global VNET Peering and SQL Distributed AlwaysOn Group

SQL AlwaysOn Group is a HADR feature introduced from SQL 2012. It is working pretty well in most HADR scenarios. Recently, we are working on one Azure project, which requires the SQL AlwaysOn Group across the regions. As per Microsoft online documentation, this can be easily done with the distributed AlwaysOn group if using SQL 2016. The step by step instruction can be found here https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/configure-distributed-availability-groups?view=sql-server-2016. This is no difference with on premises deployment.

However, once we deployed the AlwaysOn group in each region, we found that SQL listeners can't communicate with each other across the regions, but we can communicate between the backend SQL servers themselves. Comparing the SQL AlwaysOn Group deployment difference between Azure and on premises, still as per Microsoft online documentation, the SQL AlwaysOn Group listeners need use Azure Load Balancer, also the IP address on Azure Load Balancer must be the same IP address as SQL AlwaysOn Group listener's IP address, https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sql/virtual-machines-windows-portal-sql-alwayson-int-listener

Further digging, the Global VNET Peering has certain limitations, https://blogs.msdn.microsoft.com/azureedu/2018/04/24/how-to-setup-global-vnet-peering-in-azure/

******

What are some limitations of Global VNet peering?

You cannot use Global VNet peering to communicate with VIPs of load balancers in another region. VIP communication requires source IP to be on the same VNet as the LB IP:

• Resources in one virtual network cannot communicate with the IP address of an Azure internal load balancer in the peered virtual network. The load balancer and the resources that communicate with it must be in the same virtual network.

This is a big one as it bit us with a customer. You must not check ‘use remote gateways’ or ‘allow gateway transit’ like you select when setting up intra regional VNet peering:

• You cannot use remote gateways or allow gateway transit. To use remote gateways or allow gateway transit, both virtual networks in the peering must exist in the same region.

VNet Global peerings are not transitive meaning downstream VNets in one region cannot talk with downstream VNets in another region.

******

So, basically, Azure Global VNET Peering and SQL Distributed AlwaysOn Group can't work together at this point of time. The only option to setup SQL Distributed AlwaysOn Group across regions is to use VNET-to-VNET peering, instead of Global VNET peering. However, VNET-to-VNET peering is a step backward. Hope Microsoft will release the solution to fix this soon.