Azure Web App connecting to SQL FO Group over Private Link

0
votes

I would like to know few things about my web apps hosted in Central US connecting to Azure SQL FO group connection string. The Primary SQL is hosted in the same region which is Central US and the Secondary Replica is hosted in East US 2. I am considering using Private Link for Azure SQL.So in order for my web app to talk to the Azure SQL over the private endpoint, i have to enable regional VNET integration for my Web App as i read in MS Docs. So at the moment i have two subnets in Central US and one of the subnets i have to dedicate for creating VNET integration for my Web Apps. The other subnet will be hosting my SQL Private Endpoint. I have already enabled Global VNET peering between Primary Central US and the Secondary VNET in East US 2. So i would like to know whether during a disaster and after a failover happens for my SQL from Primary Central US to secondary East US 2, will my Web Apps automatically connect to the SQL FO group read/write listener after i enable private link for my Azure SQL. I don't understand what it means by this below as per the link :

https://docs.microsoft.com/en-us/azure/architecture/example-scenario/private-web-app/private-web-app

Global peering Any service in any Azure region that can connect through the Virtual Network can reach the database's private endpoint, for example through Virtual Network peering in hub-and-spoke topologies. However, for App Service regional VNet Integration, the peered Virtual Networks must be located in the same Azure region.

As per the line "However, for App Service regional VNet Integration, the peered Virtual Networks must be located in the same Azure region.", my peered virtual network is from Central US to East US 2 which is like Global Peering. So how this statement applies to in my case.

Looking forward to some pointers

1
azureazure-web-app-serviceazure-sql-databaseazure-virtual-network
Does KarthikBhyresh-MT's answer useful to you ? If yes, I will give him 100 reputation bounty. – Ivan Yang
That statement is describing a scenario when the DBs have failed over to secondary region while Web App remains active on primary region - it isn't supported. You have not made it clear but for the DR to really work you must have the App Service also created in secondary region. During the DR secondary region would be used for both App Service and SQL, and in this case the private endpoint would continue to work. – amit_g
amit_g I have tested failing over the SQL from Primary to Secondary Private Endpoint. My web apps were still connecting to the Secondary Instance being in the primary region. Why you say it isn't supported? This is the case of a partial failover where you fail over just one service and keep the other service in the primary. You can have partial failover or a complete failover. Both are mentioned in the article docs.microsoft.com/en-us/azure/architecture/example-scenario/… – Pallab

1 Answers

0
votes

Update-- to answer to the point, how the line below applies to your case.

line: "However, for App Service regional VNet Integration, the peered Virtual Networks must be located in the same Azure region."

VNet is scoped to a single region/location; however, multiple virtual networks from different regions can be connected together using Virtual Network Peering. Peering virtual networks in different regions is also referred to as Global VNet Peering.

Using regional VNet Integration enables your app to access:

  1. Resources in a VNet in the same region as your app.
  2. Resources in VNets peered to the VNet your app is integrated with.
  3. Service endpoint secured services.
  4. Resources across Azure ExpressRoute connections.
  5. Resources in the VNet you're integrated with.
  6. Resources across peered connections, which include Azure ExpressRoute connections.
  7. Private endpoints

There are some limitations with using VNet Integration with VNets in the same region:

  1. The app and the VNet must be in the same region.

  2. You can't reach resources across global peering connections. (That is when your VNet is peered with a VNet in another region)

Global VNet peering in Azure is the ability to peer VNets or virtual networks across regions. It enables resources in your virtual network to communicate across Azure regions privately through the Microsoft backbone.

Hope you got this....

Below if explaining partial failover setup and suggestion to you if you require setup a complete regional failover architecture.

For regional integration to work both deployments should reside in the same region. However, in your case if I understand correctly, you can try Multi-region web app with private connectivity to database

You have to do the following if not already......

To offer high availability, this solution:

  • Deploys a secondary instance of the solution in another Azure region.
  • Uses auto-failover groups for geo-replication and high availability of the database. You can achieve high availability with a complete region failover. However, this solution uses a partial region failover. With this approach, only components with issues fail over:

Your case--

If the primary database fails over, the web app in the primary region connects to the newly activated secondary database while maintaining private connectivity.

If the app goes down in the primary region, the instance in the secondary region takes over. That instance connects to the primary database, which is still active.

A partial region failover involves cross-region connectivity

Architecture

Instead of using a partial region failover, you can use a complete region failover. As Highly available multi-region web application explains, when a single component fails with this approach, the architecture fails over the entire region. For example, an issue in the primary region web app can trigger a database failover.

No No...

A complete region failover requires no cross-region connectivity. Instead, you treat your entire solution as an isolated deployment stamp that moves from one region to another as one unit. But this approach has disadvantages. Triggering a database failover can cause data loss because of the asynchronous nature of database replication. This loss can occur even when the database has no issues.