Skip to main content

SQL Server Always On AG（WSFC)配置指南(11) - Azure上配置AG和本地有什么不同

分类:  SQL Server ◆ 标签:  #SQL Server #SQL Server Always on AG ◆ 发布于: 2026-03-16 19:05:50

我们之前的一系列文章完整的学习了配置SQL Server Always on AG核心要点，继续学习如何在SQL Server on Azure VM配置。

SQL Server Always On AG的核心机制在 Azure 和本地是一样的(都依赖 WSFC),但 Azure 的网络、IP、故障转移、仲裁（Quorum）、存储和运维边界都不同, 这就导致了在Azure上配置和本地主要区别在于：

  • 仲裁见证配置上不一样，本地我们使用共享文件witness, 但在Azure上我们要使用cloud Witness, 例如Azure Storage。
  • Listener 配置上不一样，Azure有两种常用种方式：
    • 所有的SQL节点都配置在同一个VNET下的子网里，需要新建一个内部的Load balancer来和Listener`配合。
    • 使用故障转移集群的DNN (Distributed Network Name) 配合DNS， 客户端加参数：MultiSubnetFailover=True

其他的部分都是一致的。

核心要点：AG并不是Azure的能力，它是SQL Server + Windows Server Failover Cluster的能力。

在Azure上配置cloud witness

在Azure上使用Azure Storage Blob来配置cloud witness。

创建好Azure Storage之后，在Azure Portal上找到这个资源，从左侧的菜单里选择"Security + Networking" -> "Access Key", 如下图：


拷贝Key1。

在配置故障转移集群仲裁见证时选择"Configure a cloud witness`:


输入您的Azure Storage account名字，key 以及endpoint后缀就可以配置成功了。

在Azure上配置AG Listener

这部分可以参考文档：https://learn.microsoft.com/zh-cn/azure/azure-sql/virtual-machines/windows/availability-group-load-balancer-portal-configure?view=azuresql#add-load-balancing-rule-for-distributed-availability-group

在Azure上采用单子网 + Virtual network name + LB的方式配置的时候，除了witness 之外，正常创建完Listener 之后，还需要：

  1. 创建一个内部的LB, 并设置LB的frontend ip和AG Listener的IP一致，并且一定是要静态的ip。
  2. 配置该LB的后端池要将所有的SQL节点的网卡加入到后端池，配置类型也是必须选择NIC。
  3. 配置的探测端口是任何没有被使用的端口，例如文档中提到的59999
  4. 创建LB的规则时，一定要选择：浮动 IP(Enable Floating IP)
  5. 配置好LB之后，还需要在SQL节点上同时配置影响LB的探测端口。

详细的步骤如下：

  1. 我们已经按照之前文章创建了所有的一切，也已经创建了名称为testdb， 静态ip地址为192.168.1.25的AG Listener
  2. 在Azure Portal创建Stand的Azure Load balancer:


    类型和SKU按图片选择。

  3. Frontend IP Configuration:



    注意这里：

    • 网络必须是同一个，同一个子网
    • 类型必须是选择静态的
    • ip地址必须是和之前创建的AG Listner一致 (注意：这里只是为了演示，实际情况根据您自己的来配置)
  4. Backend Pool必须选择类型NIC, 然后加入你所创建的SQL节点的NIC:



    注意，只选择SQL节点的(故障转移结群节点的)， 如下图：dbad是我的域控，因此不能选入后端池：



  5. 其他的配置在创建完成了之后再配置，因此这里直接创建结束。

  6. 创建完成之后，找到该资源，从Azure Portal左侧的菜单里，选择"Health Probes", 选择ADD添加新的探测：


    注意这里的端口是要在故障转移集群上没有被使用过的端口。

  7. 继续在Azure Portal上创建Load Balancer Rules, 在Azure Portal上找到资源，左侧菜单 Settings -> Load Balancer Rules -> Add:



详细的说明文档可以查看微软的官方文档。

创建好LB之后，还需要回到故障转移集群上配置探测端口

登录到故障转移集群的Primary节点上，注意一定是要主节点, 运行如下命令：

Import-Module FailoverClusters
Get-ClusterResource | Where-Object {$_.ResourceType -eq "IP Address"}  //确认当前的listener

注意第二行的返回可能是如下的结果：

PS C:\Users\ghw.HONG> Get-ClusterResource | Where-Object {$_.ResourceType -eq "IP Address"}

Name                 State  OwnerGroup    ResourceType
----                 -----  ----------    ------------
Cluster IP Address   Online Cluster Group IP Address
testdb4-ag_10.16.0.8 Online testdb4-ag    IP Address

注意观察，这里的testdb4-ag_10.16.0.8 就是我们的AG Listner IP的名字

接下来：

Import-Module FailoverClusters

$ProbePort = 59999
$ListenerIP = "testdb4-ag_10.16.0.8"

Get-ClusterResource $ListenerIP | Set-ClusterParameter -Multiple @{
    "ProbePort" = $ProbePort
}

这样就在AG Listener的ip地址上配置了和LB的探测端口，并响应它，WSFC只会在主节点上响应这个探测。

最后一步：

确认在所有的SQL节点上都放通了59999的端口，我这里在创建LB的时候选择了探测59999的端口，如果你使用了其他端口就填你自己的。

注意
探测端口和SQL Server服务的监听端口没有任何关系，这里主要是给给故障转移集群使用的。因此一定不是1433, 千万注意这一点。

如果选择Azure 单子网 + VNN + AG Listener 这个方案的话，配置到这里结束了。