Azure VM 上的 SQL Server 的 Always On 可用性组

适用于：Azure VM 上的 SQL Server

本文介绍 Azure 虚拟机 (VM) 上 SQL Server 的 Always On 可用性组 (AG)。

若要开始，请参阅可用性组教程。

概述

Azure 虚拟机上的 Always On 可用性组类似于本地 Always On 可用性组，并依赖于基础 Windows Server 故障转移群集。 但是，由于虚拟机托管在 Azure 中，还存在其他一些注意事项，例如 VM 冗余以及 Azure 网络上的流量路由。

下图演示了 Azure VM 上的 SQL Server 可用性组：

VM 冗余

要增加冗余和提高可用性，SQL Server VM 应位于相同的可用性集或不同的可用性区域中。

将一组 VM 放在同一可用性集中可以保护数据中心免受设备故障（可用性集中的 VM 不共享资源）或更新（可用性集内的 VM 不同时更新）造成的停机的影响。

可用性区域可保护免受整个数据中心故障的影响，其中每个区域表示一个地区内的一组数据中心。 通过确保资源放在不同的可用性区域，任何数据中心级别的中断都没法导致所有 VM 脱机。

创建 Azure VM 时，必须选择配置可用性集还是配置可用性区域。 一个 Azure VM 不能同时加入这两者。

尽管可用性区域可能会提供比可用性集更高的可用性（分别为 99.99% 和 99.95%），但还应考虑性能。 可用性集中的 VM 可以放置在邻近放置组中，这可以保证它们彼此接近，最大程度降低它们之间的网络延迟。 位于不同可用性区域中的 VM 之间具有更大的网络延迟，这可能会增加在主副本和次要副本之间同步数据所需的时间。 这可能会导致主副本延迟，并在发生计划外故障转移时增加数据丢失的几率。 务必在负载下测试建议的解决方案，并确保满足性能和可用性方面的 SLA。

连接

若要在连接到可用性组侦听程序方面提供与本地体验一致的体验，请将 SQL Server VM 部署到同一虚拟网络中的多个子网。 如果有多个子网，则无需额外依赖于 Azure 负载均衡器或分布式网络名称 (DNN) 将流量路由到侦听器。

如果将 SQL Server VM 部署到单个子网，则可以配置虚拟网络名称 (VNN) 和 Azure 负载均衡器，或者配置分布式网络名称 (DNN) 以将流量路由到可用性组侦听程序。 查看两者之间的差异；然后，为可用性组部署分布式网络名称 (DNN) 或虚拟网络名称 (VNN)。

使用 DNN 时，大多数 SQL Server 功能透明地适用于可用性组，但是某些功能可能需要特殊考虑。 有关详细信息，请参阅 AG 和 DNN 互操作性。

此外，VNN 侦听器和 DNN 侦听器功能之间有一些行为差异，必须注意，具体包括：

• 故障转移时间：使用 DNN 侦听器时，故障转移时间更短，因为不需要等待网络负载均衡器来检测失败事件和更改其路由。
• 现有连接：与故障转移可用性组中特定数据库之间的连接将会关闭，但与主要副本的其他连接将保持打开状态，因为在故障转移过程中，DNN 将保持联机状态。 这不同于传统的 VNN 环境。在传统 VNN 环境中，主要副本的所有连接通常在可用性组故障转移时关闭，侦听器进入脱机状态，而主要副本转换为次要角色。 使用 DNN 侦听器时，可能需要调整应用程序连接字符串，以确保在故障转移时将连接重定向到新的主要副本。
• 开放事务：针对故障转移可用性组中的数据库的开放事务将关闭并回滚，你需要手动重新连接。 例如，在 SQL Server Management Studio 中，关闭查询窗口并打开一个新窗口。

在 Azure 中设置 VNN 侦听器时需要负载均衡器。 对于 Azure 中的负载平衡器，有两个主要选项：外部（公共）或内部。 外部（公共）负载均衡器是面向 Internet 的，并与可通过 Internet 访问的公共虚拟 IP 相关联。 内部负载均衡器仅支持同一虚拟网络内的客户端。 对于任一负载均衡器类型，都必须启用直接服务器返回。

仍可通过直接连接到服务实例，单独连接到每个可用性副本。 此外，由于可用性组与数据库镜像客户端向后兼容，因此可以像数据库镜像伙伴一样连接到可用性副本，只要这些副本配置得类似于数据库镜像即可：

• 有一个主要副本和一个次要副本。
• 将辅助副本配置为不可读（“可读辅助副本”选项设置为“否”）。

下面是一个示例客户端连接字符串，它对应于这个使用 ADO.NET 或 SQL Server 本机客户端的类似于数据库镜像的配置：

Data Source=ReplicaServer1;Failover Partner=ReplicaServer2;Initial Catalog=AvailabilityDatabase;

有关客户端连接的详细信息，请参阅：

• 将连接字符串关键字用于 SQL Server 本机客户端
• 将客户端连接到数据库镜像会话 (SQL Server)
• 在混合 IT 环境中连接到可用性组侦听器
• 可用性组侦听器、客户端连接和应用程序故障转移 (SQL Server)
• 将数据库镜像连接字符串用于可用性组

单个子网需要负载均衡器

在传统的本地 Windows Server 故障转移群集 (WSFC) 创建可用性组侦听器时，会使用你提供的 IP 地址为侦听器创建 DNS 记录，并且此 IP 地址映射到本地网络上交换机和路由器的 ARP 表中当前主要副本的 MAC 地址。 群集通过使用免费 ARP (GARP) 执行此操作，每当故障转移后选出一个新的主节点时，群集就会将最新的 IP 到 MAC 地址映射广播到网络。 在这种情况下，IP 地址是侦听器，MAC 是当前主要副本。 GARP 强制对交换机和路由器的 ARP 表条目进行更新，并且连接到侦听器 IP 地址的任何用户将无缝路由到当前主要副本。

出于安全原因，不允许在任何云（Azure、Google、AWS）上进行广播，因此不支持在 Azure 上使用 ARP 和 GARP。 为了克服网络环境中的这种差异，单个子网可用性组中的 SQL Server VM 依靠负载均衡器将流量路由到相应的 IP 地址。 负载均衡器配置有对应于侦听器的前端 IP 地址，并分配了探测端口，以便 Azure 负载均衡器定期轮询可用性组中副本的状态。 由于只有主要副本 SQL Server VM 响应 TCP 探测，因此传入流量随后会路由到成功响应探测的 VM。 此外，相应的探测端口配置为 WSFC 群集 IP，确保主要副本响应 TCP 探测。

在单个子网中配置的可用性组必须使用负载均衡器或分布式网络名称 (DNN) 将流量路由到相应的副本。 若要避免这些依赖项，请在多个子网中配置可用性组，以便在每个子网中为可用性组侦听器配置副本的 IP 地址，并且可以相应地路由流量。

如果已在单个子网中创建可用性组，可以将其迁移到多子网环境。

租用机制

对于 SQL Server，AG 资源 DLL 基于 AG 租用机制和 Always On 运行状况检测来确定 AG 的运行状况。 AG 资源 DLL 通过 IsAlive 操作公开资源运行状况。 资源监视器按群集检测信号间隔（由 CrossSubnetDelay 和 SameSubnetDelay 的群集范围值来设置）轮询 IsAlive。 在主节点上，只要资源 DLL 的 IsAlive 调用返回的 AG 运行不正常，群集服务就会启动故障转移。

AG 资源 DLL 监视内部 SQL Server 组件的状态。 Sp_server_diagnostics 按照某个间隔（由 HealthCheckTimeout 控制）向 SQL Server 报告这些组件的运行状况。

与其他故障转移机制不同，SQL Server 实例在租用机制中发挥着积极的作用。 租用机制用于充当群集资源主机与 SQL Server 进程之间的 LooksAlive 验证机制。 该机制用于确保双方（群集服务器和 SQL Server 服务）通信频繁，检查彼此的状态并最终避免出现裂脑情况。

在 Azure VM 中配置 AG 时，通常需要以不同于在本地环境中配置的方式来配置这些阈值。 若要根据 Azure VM 的最佳实践配置阈值设置，请参阅群集最佳实践。

网络配置

尽可能将 SQL Server VM 部署到多个子网，以避免依赖于 Azure 负载均衡器或分布式网络名称 (DNN) 来将流量路由到可用性组侦听程序。

在 Azure VM 故障转移群集上，建议为每个服务器（群集节点）设置一个 NIC。 Azure 网络具有物理冗余，这使得在 Azure VM 故障转移群集上不需要额外的 NIC。 虽然群集验证报告会发出警告，指出节点只能在单个网络上访问，但在 Azure VM 故障转移群集上可以安全地忽略此警告。

基本可用性组

由于基本可用性组不允许使用多个次要副本，且没有对次要副本的读取访问权限，因此可以对基本可用性组使用数据库镜像连接字符串。 使用连接字符串便无需侦听器。 摆脱侦听器依赖项对于 Azure VM 上的可用性组很有用，因为这样便不需要负载均衡器，如果有多个侦听器用于附加数据库，则无需向负载均衡器中添加其他 IP。

例如，若要使用 TCP/IP 显式连接到基本 AG（或者只有一个次要副本并且次要副本中不允许读取访问权的任何 AG）的 Replica_A 或 Replica_B 上的 AG 数据库 AdventureWorks，客户端应用程序可以提供以下数据库镜像连接字符串以成功连接到 AG

Server=Replica_A; Failover_Partner=Replica_B; Database=AdventureWorks; Network=dbmssocn

部署选项

有多个选项来将可用性组部署到 Azure VM 上的 SQL Server，某些选项的自动化程度比其他的高。

下表提供了可用选项的比较：

后续步骤

若要开始，请查看 HADR 最佳做法，然后通过可用性组教程手动部署可用性组。

若要了解更多信息，请参阅以下文章：

• Windows Server 故障转移群集与 Azure VM 上的 SQL Server
• Always On 可用性组概述