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

学习完了如何在本地以及Azure上配置AG，这一节深入学习一下Listener。

• Listener是如何工作的？
• 为什么Azure上需要LB
• 为什么DNN不需要创建Listener?

Listener是如何工作的

Listener并不是SQL Server的资源，它是WSFC管理的资源，它包含如下几个组件：

• Network Name 虚拟的计算机对象： 这个对象有几个作用：用来注册DNS地址，kerborse认证
• IP地址： 集群内谁是主节点，这个ip地址就被分配谁，并绑定到它的网卡上(本地)
• 以及它依附的AG Group

当故障转移发生时会发生什么：

假设Failover发生前是这样的情况：

AG Primary → SQLNODE1
Listener IP → 10.0.0.100（在 SQLNODE1）
DNS → AGLISTENER → 10.0.0.100

现在触发了Failover:

• WSFC 判断 SQLNODE1 不健康
• 选择 SQLNODE2
• AG 在 SQLNODE2 上变成 Primary
• Listener IP 被 Online 到 SQLNODE2
• SQLNODE2 向网络发送 Gratuitous ARP
• 网络设备更新 MAC → IP 映射

这里还是有一些要点：

• WSFC判断健康与否：通过集群的机制来判断，例如节点挂了，服务挂了，手动触发等等。
• Listener IP 是如何被online到新主节点上,也就是SQLNode2?
  通过简单的网络知识我们知道ip实际上是要映射到网卡的物理地址Mac地址上的，因此Listener IP 会被故障转移集群通过调用Windows的API在SQLNode2上绑定网卡的Mac, 这样新的ip就到了新的主节点上。
• 新节点在绑定ip后，会向网络上所有的设备发送Gratuitous ARP广播，告诉所有的设备，Listener IP 绑到了它这里，其他设备接受了这个广播之后就会更新mac地址和ip地址的映射。

由于是在本地网络，而且是发生在网络的layer-2上，这个arp应答会非常快，对于应用来说基本是感知不到。

这就是本地Listener的基本流程和原理。

为什么Azure上需要LB

这是因为几乎所有的云厂商都禁止了发生在网络layer-2上的arp广播，这样也就没有办法进行arp应答了。因此必须借助LB来实现。

• LB上主要是通过探测端口确认流量应该往哪个网卡转发。
• WSFC上规定只有主节点会响应LB的探测，当WSFC发生了Failover之后，响应探测的节点也就发生了变化。
• LB通过我们定义的探测规则，配合浮动ip将流量转发给主节点。
• 特别强调的是LB的前端ip必须和AG Listner一致，并且必须是静态ip也是因为这个原因。

DNN为甚不需要AG Listener

• DNN 本身就是 Listener 的“替代品”
• 它存在的目的就是 不再创建 VNN Listener

DNN主要是依赖DNS解析到所有的SQL节点上，同时客户端配合探测多个节点，另外SQL Server会自己判断如果是主节点返回连接，非主节点跳过。

注意
看上去DNN可能有很多优点，但是要注意的是DNN无法支持通过路由列表访问可读辅助性节点。这一点很重要。