适用于：SQL Server 在 Linux 上
从 SQL Server 2017（14.x）开始，Linux 和 Windows 都支持SQL Server。 与基于Windows SQL Server部署一样，SQL Server数据库和实例需要在 Linux 下高度可用。 本文涵盖了了解 Pacemaker 和 Corosync 的基本信息，以及如何规划和部署它以用于 SQL Server 配置。
HA 加载项/扩展基础知识
所有当前支持分发版都提供基于 Pacemaker 群集堆栈的高可用性加载项/扩展。 此堆栈包含两个关键组件：Pacemaker 和 Corosync。 堆栈的所有组件如下：
- 起搏器。 核心群集组件，可以在群集计算机之间进行协调。
- Corosync。 框架和一组 API 接口，提供仲裁、重启失败进程等功能。
- libQB。 提供日志记录等功能。
- 资源代理。 提供特定功能，以便应用程序可以与 Pacemaker 集成。
- 隔离代理。 脚本/功能，有助于隔离节点并在遇到问题时对其进行处理。
注意
在 Linux 环境中，群集堆栈通常被称为 Pacemaker。
此解决方案的一些方式类似于，但在许多方面与使用 Windows 部署群集配置不同。 在Windows中，群集的可用性形式称为Windows Server故障转移群集（WSFC）内置于操作系统中，默认情况下禁用启用 WSFC 创建故障转移群集的功能。 在 Windows 中，AG 和 FCI 建立在 WSFC 之上，并由于由 SQL Server 提供的特定资源 DLL，而实现了紧密集成。 这种紧密耦合的解决方案在很大程度上是可能的，因为它都来自一个供应商。
在 Linux 上，虽然每个支持的分发版都有可用的 Pacemaker，但每个分发版都可以自定义，且具有稍微不同的实现和版本。 本文说明部分将介绍其中一些差异。 聚类层是开源的，因此，即使它随发行版一起提供，它也不像 WSFC 在 Windows 下那样紧密集成。 这就是为什么 Microsoft 提供 mssql-server-ha，以便 SQL Server 和 Pacemaker 堆栈可以为 AGs 和 FCIs 提供接近但不完全相同的体验，如同在 Windows 下的环境中。
有关 Pacemaker 的完整文档，包括关于 RHEL 和 SLES 的所有内容更深入的阐释和完整的参考信息：
注意
从 SQL Server 2025（17.x）开始，不支持 SUSE Linux Enterprise Server （SLES）。
有关整个堆栈的详细信息，另请参阅 ClusterLabs 站点上的官方 Pacemaker 文档页。
Pacemaker 概念和术语
本节介绍了 Pacemaker 实现的常见概念和术语。
Node
节点是参与群集的服务器。 Pacemaker 群集本机最多支持 16 个节点。 如果 Corosync 未在其他节点上运行，但 SQL Server 需要 Corosync，则可以超过此数字。 因此，群集对于任何基于SQL Server的配置可以拥有的最大节点数为 16;这是 Pacemaker 限制，与SQL Server施加的 AG 或 FCI 的最大限制无关。
资源
WSFC 和 Pacemaker 群集都有关于资源的概念。 资源是在群集上下文中运行的特定功能，例如磁盘或 IP 地址。 例如，在 Pacemaker 下，可以创建 FCI 和 AG 资源。 在这点上，它并不与 WSFC 中的做法截然不同。在配置 AG 时，您可以看到一个用于 FCI 或 AG 的 SQL Server 资源，但由于 SQL Server 与 Pacemaker 的集成方式存在根本差异，因此两者并不完全相同。
Pacemaker 具有标准资源和克隆资源。 克隆资源是在所有节点上同时运行的资源。 例如，在多个节点上运行以实现负载均衡的 IP 地址。 为 FCI 创建的任何资源都使用标准资源，因为在任何给定时间只有一个节点可以托管 FCI。
注意
本文包含对术语从属的引用，该术语Microsoft不再使用。 从软件中删除术语后，我们会将其从本文中删除。
创建 AG 时，它需要一种特殊形式的克隆资源（称为多状态资源）。 虽然 AG 只有一个主要副本，但它可以在所有配置的节点上运行，并可能提供只读访问等功能。 因为这是对节点的“实时”使用，所以资源有两种状态的概念：已提升（以前称为主状态）和未提升（以前称为从状态）。 有关详细信息，请参阅多状态资源：具有多种模式的资源。
资源组/集合
与 WSFC 中的角色类似，Pacemaker 群集也具有资源组的概念。 资源组（在 SLES 中称为“集”）是一起运行的资源集合，可以作为单个单元从一个节点故障转移到另一个节点。 资源组不能包含配置为 Promoted 或 Unpromoted 的资源；因此，它们无法用于可用性组 (AG)。 虽然资源组可用于 FCI，但通常不建议使用该配置。
约束
WSFC 具有各种资源参数以及依赖项，以此说明 WSFC 两个不同资源之间的父/子关系。 依赖项只是一个规则，指示 WSFC 哪个资源需要首先联机。
Pacemaker 群集没有依赖项的概念，但有一些约束。 有三种约束：托管、位置和排序。
- 一个共同定位约束会确定两个资源是否应在同一节点上运行。
- 位置约束用于指示 Pacemaker 群集中资源允许或不允许运行的位置。
- 排序约束指示 Pacemaker 群集资源启动的顺序。
注意
资源组中的资源不需要托管约束，因为所有这些资源都被视为一个单元。
仲裁、围栏代理和 STONITH
Pacemaker 下的仲裁机制在概念上与 WSFC 相似。 群集仲裁机制的主要目的是确保群集保持正常运行。 用于 Linux 分发版的 WSFC 和 HA 加载项都具有投票的概念，其中每个节点都计入仲裁。 你需要大多数投票支持，否则，在最糟糕的情况下，群集将被关闭。
与 WSFC 不同，没有见证资源可用于仲裁。 与 WSFC 一样，目标都是保持投票人数为奇数。 仲裁配置对 AG 的考虑因素与 FCI 不同。
WSFC 监视参与节点的状态，并在出现问题时进行处理。 WSFC 更高版本提供了诸如隔离行为不正常或不可用的节点（节点未打开、网络通信关闭等）等功能。 在 Linux 端，这种类型的功能是由隔离代理提供的。 此概念有时被称为隔离。 不过，这些隔离代理通常是特定于部署的，并且由硬件供应商和部分软件供应商（例如提供虚拟机监控程序的供应商）提供。 例如，VMware 提供了一个隔离代理，可用于使用 vSphere 虚拟化的 Linux VM。
仲裁和隔离与另一个被称为 STONITH（即“关闭另一节点”）的概念相关联。 STONITH 需要在所有 Linux 分发版上都支持 Pacemaker 群集。 有关更多信息，请参阅 Red Hat 高可用性群集中的围栏 (RHEL)。
corosync.conf
corosync.conf 文件包含群集的配置。 该文件位于 /etc/corosync。 在正常日常操作过程中，如果群集设置正确，则永远不必编辑此文件。
群集日志位置
Pacemaker 群集的日志位置因分发版而异。
- RHEL 和 SLES：
/var/log/cluster/corosync.log - Ubuntu：
/var/log/corosync/corosync.log
若要更改默认日志记录位置，请修改 corosync.conf。
规划 SQL Server Pacemaker 群集
本部分讨论 Pacemaker 集群的重要规划要点。
虚拟化适用于 SQL Server 的基于 Linux 的 Pacemaker 群集
使用虚拟机部署基于 Linux 的 SQL Server 实例（用于 AG 和 FCI），其规则与基于 Windows 的实例相同。 在由 Microsoft 提供的 《适用于在硬件虚拟化环境中运行的 Microsoft SQL Server 产品的支持策略》 中，存在一套基础规则用于虚拟化 SQL Server 部署的支持性。 不同的虚拟机监控程序（例如 Microsoft 的 Hyper-V 和 VMware 的 ESXi）可能因为平台本身的差异而表现出不同的变体。
对于虚拟化下的 AG 和 FCI，请确保为给定 Pacemaker 群集的节点设置了反关联性。 在 AG 或 FCI 配置中配置为高可用性时，托管SQL Server的 VM 不应在同一虚拟机监控程序主机上运行。 例如，如果部署了双节点 FCI，则需要至少有三个虚拟化主机，以确保在某个主机发生故障时，尤其是在使用 Live Migration 或 vMotion 功能时，能够有一个 VM 托管节点迁移到其他主机。
关于Hyper-V文档，请参阅 使用来宾群集实现高可用性
网络
与 WSFC 不同，Pacemaker 不需要 Pacemaker 群集本身的专用名称或至少一个专用 IP 地址。 由于没有网络名称资源，AG 和 FCI 将需要 IP 地址（请参阅每个文档以获取更多信息），但不需要名称。 SLES 允许配置 IP 地址用于管理目的，但不是必需的，如创建 Pacemaker 群集中所示。
与 WSFC 一样，Pacemaker 更倾向于使用冗余网络，即具有独立 IP 地址的不同网卡（用于物理的 NIC 或 pNIC）。 就群集配置而言，每个 IP 地址都具有所谓的其自己的环。 但是，与如今的 WSFC 一样，许多实现都是虚拟化的，或者在公有云中，只有一个虚拟化 NIC (vNIC) 呈现给服务器。 如果所有 pNIC 和 vNIC 都连接到同一个物理或虚拟交换机上，那么在网络层上就没有真正的冗余，因此配置多个 NIC 对虚拟机来说是一种错觉。 网络冗余设计通常会在虚拟化部署中的虚拟机管理程序内设置，并且肯定会在公有云内设置。
多个 NIC 和 Pacemaker 与 WSFC 的区别在于，Pacemaker 允许在同一子网上使用多个 IP 地址，而 WSFC 则不允许。 有关多个子网和 Linux 群集的详细信息，请参阅文章配置多子网 Always On 可用性组和故障转移群集实例。
仲裁和 STONITH
仲裁配置和要求与 AG 或 FCI 特定的 SQL Server 部署相关。
受支持的 Pacemaker 集群需要 STONITH。 使用分发版中的文档来配置 STONITH。 相关示例，请参阅 SLES 的 Storage-based Fencing（基于存储的隔离）。 对于基于 ESXi 的解决方案，还有一个针对 VMware vCenter 的 STONITH 代理。 有关详细信息，请参阅 Stonith Plugin Agent for VMWare VM VCenter SOAP Fencing (Unofficial)（适用于 VMWare VM VCenter SOAP 隔离的 Stonith 插件代理（非正式））。
互操作性
本部分介绍基于 Linux 的群集如何与 WSFC 或 Linux 的其他分发版进行交互。
WSFC
目前，WSFC 和 Pacemaker 群集无法直接协同工作。 这意味着无法创建适用于 WSFC 和 Pacemaker 的 AG 或 FCI。 但是，有两种互操作性解决方案，这两种解决方案都是为 AG 设计的。 FCI 参与跨平台配置的唯一方法是，它作为实例参与以下两种跨平台配置场景之一：
- 群集类型为 None 的 AG。 有关详细信息，请参阅 Windows 可用性组文档。
- 分布式 AG 是一种特殊类型的可用性组，允许将两个不同的 AG 配置为自己的可用性组。 有关分布式 AG 的详细信息，请参阅文档分布式可用性组。
其他 Linux 分发版
在 Linux 上，Pacemaker 群集的所有节点必须位于同一分发版上。 例如，这意味着 RHEL 节点不能属于具有 SLES 节点的 Pacemaker 群集。 关于这一点，之前说明的主要原因是：分发版可能具有不同的版本和功能，因此无法正常工作。 混合发行版与混合 WSFC 和 Linux 的情况相同：使用 None 或分布式 AG。