双多区区域部署模式

IBM Cloud 配置为 Windows Server Failover Cluster (WSFC) 节点的 Windows Server 2019 Standard 虚拟服务器，以及在每个节点上配置了 Always On 可用性组的企业版，构成了双多区区域 (MZR) 部署模式的基础。SQL Server SQL Server 这种架构与 MS ADDNS 一起为灾难恢复提供了 SQL Server 部署。

所示的双 MZR 部署模式利用了双可用区 (AZ) 模式，并对其进行了扩展，使数据库在远程区域有一个副本；因此，这种模式适用于需要灾难恢复的生产数据库，并利用了以下核心技术：

一个 IBM Cloud VPC，子网位于两个 MZR 中。
安全组用于控制组件之间的流量。
一台或多台用于服务器管理访问的堡垒主机。
浮动 IP (FIP) 连接到堡垒主机，允许访问互联网。
三台 Windows Server 2019 Standard 虚拟服务器，主 MZR 的每个 AZ 和恢复 MZR 的第三个 AZ 各一台，它们都是同一 forest\domain 中的 Active Directory 域控制器。
三台 Windows Server 2019 Standard 虚拟服务器，主 MZR 和恢复 MZR 中的每个 AZ 各一台，它们将成为 Windows Server 故障转移群集 (WSFC) 节点。
Always On 可用性组提供了在一个或多个群集节点上保持一组离散数据库高度可用的能力，并在数据库级别上运行。可用性组由一个主副本和最多八个辅助副本组成，使用同步或异步数据复制。在此部署中：
- 在主 MZR 的两个 AZ 之间使用同步复制。
- 在 MZR 之间使用异步复制。
分布式网络名称是 WSFC 和 Always On 可用性组中的名称资源，用于群集资源的名称解析。

在此部署中不需要文件共享见证，因为节点数为奇数，将使用Node多数法定人数模式

Windows 服务器故障转移群集

在 Windows 上为 HA 部署 Always On 可用性组需要使用 Windows Server Failover Cluster (WSFC)。可用性组的每个可用性副本必须位于 WSFC 的不同节点上。为简化可用性数据库的安全配置，建议在域服务账户下运行 SQL 服务器实例（服务账户）。

Windows Server Failover Cluster (WSFC) 是 Windows Server 的一项功能，作为群集节点的每台服务器都必须启用此功能。 WSFC 依靠法定人数投票来防止“分脑”综合症，法定人数模式有多种：

Node多数 - 活跃的群集节点决定法定人数。至少要有一半的赞成票，组群才能保持健康状态。
Node和文件共享多数 - 远程文件共享充当参与法定人数投票的活动节点的投票见证人。与“Node多数”一样，必须至少有一半的赞成票才能使群集保持健康状态。
Node和磁盘多数 - 共享磁盘与参与法定人数投票的活动节点一起充当投票见证人。
仅磁盘 - 共享磁盘充当见证人，法定人数取决于哪些节点可以访问磁盘。没有最低票数要求。

微软对 SQL 服务器的建议如下：

当投票节点数量为奇数时，使用Node多数法定人数模式。
当投票节点数量为偶数时，使用Node和文件共享多数法定人数模式。

始终可用组

可用性组支持一组主数据库和最多八组辅助数据库。辅助数据库不是备份，因此必须定期备份数据库及其事务日志。始终可用群组需要以下三种群集类型选项之一：WSFC、外部、无。

WSFC - 使用 Windows Server 故障转移群集 (WSFC) 管理群集故障转移。这是 Windows 服务器上高可用性群组的前提条件。
外部 - 使用外部群集管理器。例如，Linux 上的 SQL Server 支持 Pacemaker。 Linux 集群上的可用性组至少需要两个同步副本才能保证 HA，但至少需要三个副本才能实现自动恢复，因此建议至少在三个节点上设置一个可用性组。
无 - 被称为无群集可用性组，或最初被称为读取规模可用性组。不过，该选项只提供可用性组功能的一个子集，不包括自动故障切换。这些功能包括手动计划和强制故障切换、同步和异步复制模式、可读辅助节点和辅助副本备份。没有 WSFC 集群的可用性组仍可提供可读辅助节点、只读路由和负载平衡。可使用外部工具自动进行故障切换。 SQL Server 2019 的一项新功能可通过自动流量重定向帮助缓解这一问题，该功能可将读/写流量路由回主节点，并且不需要监听器。

以下术语用于描述可用性组概念：

可用性组 - 为一组离散的用户数据库提供复制环境。
HA 可用性组 - 一组可一起故障切换的数据库。
读取规模可用性组 - 复制到其他 SQL Server 实例的数据库组，用于只读工作负载。
主副本 - 使主数据库可用于客户端的读写连接，并将每个主数据库的事务日志记录发送到每个辅助数据库。
辅助副本 - 最多 8 个辅助副本，每个副本托管一组辅助数据库，并作为 HA 可用性组的潜在故障转移目标。

同步模式

可用性组辅助副本可使用以下一种同步模式进行配置：

同步 - 在每个辅助副本上加固日志（事务提交到事务日志），然后再在主副本上提交事务。这保证了零数据丢失，但如果网络延迟较高，则可能会影响高度事务性工作负载的性能。每个 AG 可以有两个同步提交副本。该模式最适合同一 AZ 或 MZR 中的实例。
异步 - 一旦事务在主副本的事务日志中被加固，该事务即被视为已提交。如果在所有二级副本的日志加固之前出现问题，数据就有可能丢失，恢复点将是最近在所有二级副本上成功提交的事务。这种模式更适合不同 MZR 中的实例或 AZ 与内部部署之间的实例。

故障切换模式

当可用性组发生故障时，辅助副本会成为新的主副本，而主副本（如果可用）会成为辅助副本。

自动故障切换 - 自动故障切换提供 HA，并依靠正确配置的监听器和 WSFC 对象取得成功。只有同步提交可用性模式副本才能成为自动故障转移的目的地。您可以按 1 到 5 的范围配置提示自动故障转移的条件，其中 1 表示只有主副本上的 SQL Server 服务完全中断才会启动故障转移，而 5 则表示一系列严重到不太严重的 SQL Server 错误中的任何一个。默认值为 3，在主副本中断或无响应的情况下，以及在某些关键服务器条件下，会提示自动故障。这些“灵活的故障切换策略”条件详见为 "始终在线 "可用性组配置灵活的自动故障切换策略。
计划内故障切换 - 只有在数据不可能丢失的情况下，才能进行计划内故障切换。具体来说，这意味着发生故障切换时，无需使用 FORCE 参数来确认代码或 SSMS 对话框中的警告。只有在同步提交可用性模式下，才可能有计划地故障切换到辅助副本。您可以将异步提交可用性模式副本移动到同步模式，等待 SYNCHRONIZED 状态，然后在不丢失数据的情况下发出计划的故障转移。计划的故障切换应始终通过 SSMS、T-SQL 或 PowerShell 启动。
强制故障切换 - 只有在出现主节点丢失等不利群集条件时，才可手动启动强制故障切换。通过 SSMS 向导、T-SQL 命令或 PowerShell 启动，最后才通过 Windows Server 故障转移群集管理器启动。
如果 WSFC 法定人数下降，则强制故障转移 - 如果 WSFC 没有法定人数，则无法强制基于 WSFC 的可用性组进行故障转移。首先，您需要在配置管理器中通过“操纵”投票和修改节点权重来强制达到法定人数。只有在紧急情况下，如灾难导致大部分群集节点瘫痪时，才应考虑这一步骤。这可以通过 PowerShell 脚本来实现，在没有多数票的情况下强制在线节点承担主要角色。

故障切换不是由数据库问题引起的，如数据库因数据文件丢失或事务日志损坏而变得可疑。

其他类型的可用性组

本部署模式中不使用以下可用性组，但希望调整或扩展本部署模式的解决方案提供者可能会对此感兴趣：

基本可用性组 - 可用性组的有限版本，仅支持 SQL Server 标准版。单个辅助副本不可读取或备份，每个基本可用性组只能支持两个副本，但每个服务器可配置多个基本可用性组。基本可用性组具有与可用性组相同的许多功能，包括同步或异步复制、手动或自动故障切换。
分布式可用性组 - 这允许一个可用性组将另一个可用性组作为辅助副本。只读辅助副本可在全球范围内分散，将工作负载卸载到区域只读辅助副本。这两个可用性组各自有自己的监听器，不必位于同一个网络或 WSFC 中。这样就可以在多站点部署中实现地理位置上的远程 HA 和 DR。有了分布式可用性组，WSFC 就不需要跨区域。主可用性组和辅助可用性组之间没有自动故障切换。非主可用性组只能为只读查询提供服务，但本身有一个主副本。辅助可用性组中的主副本负责将事务复制到辅助可用性组中的其他辅助副本。这种架构对于操作系统和 SQL Server 版本升级非常有用，因为您可以在每个可用性组中使用不同版本的 Windows Server。虽然分布式方案中的每个可用性组都有自己的监听器，但分布式可用性组作为一个整体却没有。应用程序（可能借助 DNS 别名）将在故障切换后直接连接到每个可用性组，以利用可读的辅助副本。

分布式网络名称

该部署使用分布式网络名称 (DNN)，这是 WSFC 和 Always On 可用性组中的名称资源，用于群集资源的名称解析。它不同于标准的网络名称资源，因为它不需要节点 IP 地址之外的独立 IP 地址，也不需要在发生故障切换时在网络上使用免费地址解析协议（GARP）。在 Windows Server 2019 中，WSFC 的名称（也是 Active Directory 域服务中的群集名称对象 (CNO)）和数据库监听器都可以使用 DNN 创建。