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

Azure VM 上的SQL Server

本文介绍适用于 Azure 虚拟机中的 SQL Server（VM）的 AlwaysOn 可用性组（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 不能同时参与这两者。

虽然可用性区域可能比可用性集提供更好的可用性，但性能也应该考虑在内。 可用性集中的 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 Native Client 的连接字符串关键字
• 将客户端连接到数据库镜像会话（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 租约机制和 AlwaysOn 运行状况检测确定 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 虚拟机中的 AG 时，通常需要将这些阈值设置得不同于本地环境。 若要根据Azure VM 的最佳做法配置阈值设置，请参阅 Cluster 最佳做法。

网络配置

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

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

基本可用性组

由于基本可用性组不允许使用多个次要副本，且没有对次要副本的读取访问权限，因此可以对基本可用性组使用数据库镜像连接字符串。 使用连接字符串可以无需侦听器。 删除侦听器依赖项对于在 Azure 虚拟机上使用可用性组非常有帮助，因为这消除了需要负载均衡器的需求，或者在您有多个侦听器用于其他数据库时，必须向负载均衡器添加其他 IP 地址的需求。

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

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

部署选项

有多个选项可用于将可用性组部署到 Azure VM 上的SQL Server，有些 VM 具有比其他 VM 更多的自动化。

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

相关内容

• HADR 配置最佳做法（Azure VM 上的SQL Server）
• Tutorial：多个子网中可用性组的先决条件（Azure VM 上的SQL Server）
• Azure 上的虚拟机中的 Windows Server 故障转移群集和 SQL Server
• Always On 可用性组概述