Share via

Linux 上的可用性组和故障转移群集实例的 Pacemaker

  • 项目

适用于：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。 堆栈的所有组件如下：

  • Pacemaker。 核心群集组件，可以在群集计算机之间进行协调。
  • Corosync。 框架和一组 API，提供仲裁、重启失败进程等功能。
  • libQB。 提供日志记录等功能。
  • 资源代理。 提供特定功能，以便应用程序可以与 Pacemaker 集成。
  • 隔离代理。 脚本/功能，有助于隔离节点并在遇到问题时对其进行处理。

注意

在 Linux 环境中，群集堆栈通常被称为 Pacemaker。

此解决方案在某些方面与使用 Windows 部署群集配置相似，但在许多方面不同。 在 Windows 中，群集的可用性形式称为 Windows 服务器故障转移群集 (WSFC)，它内置于操作系统中，并且默认情况下启用创建 WSFC（故障转移群集）的功能处于禁用状态。 在 Windows 中，AG 和 FCI 基于 WSFC 构建，并且由于 SQL Server 提供的特定资源 DLL 而共享紧密集成。 这种紧密耦合的解决方案在很大程度上是可能的，因为它都来自一个供应商。

Diagram of high availability basics.

在 Linux 上，虽然每个支持的分发版都有可用的 Pacemaker，但每个分发版都可以自定义，且具有稍微不同的实现和版本。 本文说明部分将介绍其中一些差异。 群集层是开放源代码，因此即使它随分发版一起发布，也不像 Windows 下的 WSFC 那样紧密集成。 这就是 Microsoft 提供 mssql-server-ha 的原因，这样 SQL Server 和 Pacemaker 堆栈就可以为 AG 和 FCI 提供接近但不完全相同的体验，就像在 Windows 下一样。

有关 Pacemaker 的完整文档，包括关于 RHEL 和 SLES 的所有内容更深入的阐释和完整的参考信息：

Ubuntu 没有可用性指南。

有关整个堆栈的详细信息，另请参阅 ClusterLabs 站点上的官方 Pacemaker 文档页。

Pacemaker 概念和术语

本节介绍了 Pacemaker 实现的常见概念和术语。

节点

节点是参与群集的服务器。 Pacemaker 群集本机最多支持 16 个节点。 如果 Corosync 未在其他节点上运行，则可以超过此数量，但 SQL Server 需要 Corosync。 因此，对于任何基于 SQL Server 的配置，群集可以拥有的最大节点数都是 16；这是 Pacemaker 限制，与 SQL Server 施加的 AG 或 FCI 的最大限制无关。

资源

WSFC 和 Pacemaker WSFC 群集都有资源的概念。 资源是在群集上下文中运行的特定功能，例如磁盘或 IP 地址。 例如，在 Pacemaker 下，可以创建 FCI 和 AG 资源。 这与在 WSFC 中完成的操作没有什么不同，在配置 AG 时，你可以看到 FCI 或 AG 资源的 SQL Server 资源，但是由于 SQL Server 与 Pacemaker 集成方式的潜在差异，又并不完全相同。

Pacemaker 具有标准资源和克隆资源。 克隆资源是在所有节点上同时运行的资源。 例如，在多个节点上运行以实现负载均衡的 IP 地址。 为 FCI 创建的任何资源都使用标准资源，因为在任何给定时间只有一个节点可以托管 FCI。

注意

无偏差通信

本文包含对术语“从属”的引用，Microsoft 认为该术语在此上下文中存在冒犯性。 本文使用该术语的原因是，当前软件中存在该术语。 在从软件中删除该术语后，我们会将其从本文中删除。

创建 AG 时，它需要一种特殊形式的克隆资源（称为多状态资源）。 虽然 AG 只有一个主要副本，但 AG 本身可以跨所有配置的节点运行，并且可能允许诸如只读访问之类的操作。 因为这是对节点的“实时”使用，所以资源有两种状态的概念：已提升（以前称为主状态）和未提升（以前称为从状态）。 有关详细信息，请参阅多状态资源：具有多种模式的资源。

资源组/集

与 WSFC 中的角色类似，Pacemaker 群集也具有资源组的概念。 资源组（在 SLES 中称为“集”）是一起运行的资源集合，可以作为单个单元从一个节点故障转移到另一个节点。 资源组不能包含配置为已提升或未提升的资源；因此，它们不能用于 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 群集。 有关更多信息，请参阅 高可用性群集中的隔离 (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 群集

使用虚拟机为 AG 和 FCI 部署基于 Linux 的 SQL Server 部署的规则与基于 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 可以找到某个位置。

有关更多详细信息，请参阅：

网络

与 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 群集的详细信息，请参阅文章配置多个子网。

仲裁和 STONITH

仲裁配置和要求与 SQL Server 的 AG 或 FCI 特定部署相关。

支持的 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。

相关内容