Condividi tramite

Recent Updates to setting up SQL Server Availability Groups in Azure VM with AAD Domain Services

  • Articolo

Reviewed by: Dimitri Furman, Kun Cheng

This blog is an extension to the one that was published in February 2017 . In these eight months there has been some notable improvements to AAD Domain Services (AAD DS) and Azure Virtual Network (VNET) capabilities. Now, it's even more easier and convenient to leverage AAD DS for setting up SQL Server Availability Groups (AG) in Azure VMs.

As a recap, following scenarios were covered in the blog linked above:

Scenario 1: Enabling AAD Domain Services in Classic Virtual Network, deploying two SQL Server 2016 Classic VMs (Windows Server 2012), and then setting up AG

Scenario 2: Leveraging AAD Domain Services enabled in Classic Virtual Network from an ARM virtual network by adding an ARM based SQL Server 2016 VM as a replica to the existing AG.

Summary of recent improvements to AAD DS and new VNET capability:

  1. AAD DS is generally available in many Azure regions now. Check here to find out availability by region (AAD DS is under Security + Identity?).
  2. General availability of AAD DS support for Azure Resource Manager (ARM) based VNET. This was eagerly expected by customers. You can read more about it here.
  3. General availability of AAD DS in the new Azure Portal (portal.azure.com).
  4. Public preview for Global VNET Peering. VNET peering is a powerful feature allowing you to peer virtual networks in Azure. Peering VNETs in the same region is generally available, and the ability to peer VNETs across different Azure regions is in preview. You can read more about it here.

With these improvements, scenarios covered in previous blog can be done in a different way. A new scenario is enabled as well.

Scenario 1: This can be implemented in ARM only mode with no need to create any classic resources. Good news is it can be done in new Azure Portal (portal.azure.com).

Scenario 2: Since AAD DS can be enabled on ARM VNET now, you can peer it with another ARM VNET, or with a Classic VNET if there is a specific need.

Scenario 3: This is a new scenario possible with Global VNET Peering to connect an Azure region designated as your DR with your primary Azure region. Asynchronous AG replica in your Azure DR region would connect to primary replica over VNET Peering and provide failover capabilities in the event of disaster. We tried this setup and it works just as expected.

Go ahead and explore these new capabilities and scenarios and let us know if you have any questions or comments.

Comments

  • Anonymous
    November 07, 2017
    You no longer need a Classic VNet. This is GA supported in ARM now too.
    • Anonymous
      November 07, 2017
      You are right Steve. There is no need for any classic resources.