配置 Ubuntu 群集和可用性组资源

适用于: SQL Server(所有受支持的版本)- Linux

本文介绍如何在 Ubuntu 20.04 上创建三节点群集,以及如何将先前创建的可用性组添加为群集中的资源。 若要实现高可用性,Linux 上的可用性组需要三个节点,请参阅可用性组配置的高可用性和数据保护

SQL Server 在 Linux 上与 Pacemaker 集成不及在 Windows 上与 WSFC 集成的耦合性高。 在 SQL Server 内部,无法了解到群集是否存在,所有业务流程都是由外至内,并且群集管理器将该服务作为一个独立实例控制。 此外,虚拟网络名称特定于 WSFC,Pacemaker 中无相同的等效项。 查询群集信息的 Always On 动态管理视图会返回空行。

仍可创建一个侦听器,用于故障转移后的透明重新连接,但需要使用创建虚拟 IP 资源所用的 IP 在 DNS 服务器中手动注册侦听器名称(如以下部分所述)。

以下部分介绍了设置故障转移群集解决方案的步骤。

路线图

在 Linux 服务器上创建可用性组以获得高可用性的步骤与 Windows Server 故障转移群集上的步骤不同。 下面的列表对高级步骤进行了说明:

  1. 在群集节点上配置 SQL Server

  2. 创建可用性组

  3. 配置 Pacemaker 等群集资源管理器。 本文档中包含这些说明。

    配置群集资源管理器的方式取决于特定的 Linux 分发版。

    生产环境需要 STONITH 等隔离代理,以实现高可用性。 本文档中的演示不使用隔离代理。 演示仅用于测试和验证目的。

    Linux 群集使用隔离将群集返回到某个已知状态。 配置隔离的方式取决于分发版和环境。 目前,隔离在某些云环境中不可用。 有关详细信息,请参阅 RHEL 高可用性群集的支持策略 - 虚拟化平台

    通常在操作系统上实现隔离,并取决于环境。 在操作系统分销商文档中查找有关隔离的说明。

  4. 将可用性组添加为群集中的资源

在每个群集节点上安装和配置 Pacemaker

  1. 在所有节点上打开防火墙端口。 对 Pacemaker 高可用性服务、SQL Server 实例和可用性组终结点打开此端口。 运行 SQL Server 的服务器的默认 TCP 端口是 1433。

    sudo ufw allow 2224/tcp
    sudo ufw allow 3121/tcp
    sudo ufw allow 21064/tcp
    sudo ufw allow 5405/udp
    
    sudo ufw allow 1433/tcp # Replace with TDS endpoint
    sudo ufw allow 5022/tcp # Replace with DATA_MIRRORING endpoint
    
    sudo ufw reload
    

    或者,可以直接禁用防火墙:

    sudo ufw disable
    
  2. 安装 Pacemaker 包。 在所有节点上运行以下命令:

    sudo apt-get install pacemaker pcs fence-agents resource-agents
    
  3. 为安装 Pacemaker 和 Corosync 包时创建的默认用户设置密码。 在所有节点上使用相同的密码。

    sudo passwd hacluster
    

启用并启动 pcsd 服务和 Pacemaker

以下命令将启用并启动 pcsd 服务和 Pacemaker。 在所有节点上运行。 这样,节点就可以在重新启动后重新加入群集。

sudo systemctl enable pcsd
sudo systemctl start pcsd
sudo systemctl enable pacemaker

enable pacemaker 命令完成后可能出现以下错误:

pacemaker Default-Start contains no runlevels, aborting.

这个错误是无关紧要的,群集配置可继续进行。

创建群集

  1. 从所有节点中删除所有现有群集配置。

    运行 sudo apt-get install pcs 将同时安装 pacemaker、corosync 和 pcs,并开始运行这 3 个服务。 启动 corosync 将生成 /etc/cluster/corosync.conf 模板文件。 若要成功执行后续步骤,不应存在此文件 - 因此解决方法是停止 pacemaker 或corosync 并删除 /etc/cluster/corosync.conf,之后,后续步骤便可成功完成。 pcs cluster destroy 命令的作用相同,可将其用作一次性初始群集设置步骤。

    以下命令将删除所有现有群集配置文件并停止所有群集服务,永久性地破坏了群集。 请在预生产环境中将其作为第一个步骤运行。 请注意,pcs cluster destroy 禁用了 Pacemaker 服务,需要重新启用。 在所有节点上运行以下命令。

    警告

    该命令会销毁所有现有群集资源。

    sudo pcs cluster destroy 
    sudo systemctl enable pacemaker
    
  2. 创建群集。

    启动群集 (pcs cluster start) 可能会失败并出现以下错误,这是因为在运行群集设置命令时创建的 /etc/corosync/corosync.conf 中配置的日志文件是错误的。 为了解决此问题,请将日志文件更改为 /var/log/corosync/corosync.log。 或者,可以自行创建 /var/log/cluster/corosync.log 文件。

    Job for corosync.service failed because the control process exited with error code. 
    See "systemctl status corosync.service" and "journalctl -xe" for details.
    

    以下命令将创建一个三节点群集。 在运行该脚本之前,替换 < ... > 之内的值。 在主要节点上运行以下命令。

    sudo pcs host auth <node1> <node2> <node3> -u hacluster -p <password for hacluster>
    sudo pcs cluster setup <clusterName> <node1> <node2> <node3>
    sudo pcs cluster start --all
    sudo pcs cluster enable --all
    

    在 SQL Server 资源代理的当前实现中,节点名称必须与实例中的 ServerName 属性匹配。 例如,如果节点名称为 node1,请确保 SERVERPROPERTY('ServerName') 在 SQL Server 实例中返回 node1。 如果存在不匹配,则在创建 Pacemaker 资源后,副本将进入“正在解析”状态。

    此规则非常重要的一种情况是使用完全限定的域名 (FQDN)。 例如,如果在群集设置过程中将 node1.yourdomain.com 用作节点名称,请确保 SERVERPROPERTY('ServerName') 返回 node1.yourdomain.com,而不只是返回 node1。 此问题的可能解决方法包括:

    • 将主机名重命名为 FQDN,并使用 sp_dropserversp_addserver 存储过程来确保 SQL Server 中的元数据与更改匹配。
    • 使用 pcs cluster auth 命令中的 addr 选项将节点名称与 SERVERPROPERTY('ServerName') 值匹配,并将静态 IP 用作节点地址。

    如果以前已在相同节点上配置了群集,则需要在运行 pcs cluster setup 时使用 --force 选项。 这相当于运行 pcs cluster destroy,需要使用 sudo systemctl enable pacemaker 重新启用 Pacemaker 服务。

配置隔离 (STONITH)

Pacemaker 群集供应商需要启用 STONITH,并为受支持的群集安装程序配置隔离设备。 (STONITH 表示“shoot the other node in the head”(将其他节点爆头))。群集资源管理器无法确定节点的状态或节点上资源的状态时,通过隔离使群集再次处于已知状态。

资源级别隔离可确保发生中断时,不会发生任何数据损坏。 例如,可将资源级别隔离用于 DRBD(分布式复制块设备),从而在通信链接出现故障时将节点上的磁盘标记为过时。

节点级别隔离可确保节点不会运行任何资源。 重置节点可实现此目的,并且其 Pacemaker 实现被称为 STONITH。 Pacemaker 支持多种隔离设备,例如,不间断电源或服务器的管理接口卡。

有关详细信息,请参阅从头构建 Pacemaker 群集隔离和 Stonith

由于节点级别隔离配置在很大程度上取决于你的环境,因此我们在本教程中禁用它(稍后可以对其进行配置)。 在主要节点上运行以下脚本:

sudo pcs property set stonith-enabled=false

在本例中,禁用 STONITH 仅出于测试目的。 如果计划在生产环境中使用 Pacemaker,则应根据环境来计划 STONITH 实现,并使其处于启用状态。 有关针对任何特定分发隔离代理的详细信息,请与操作系统供应商联系。

设置群集属性 cluster-recheck-interval

cluster-recheck-interval 属性表示群集检查资源参数、约束或其他群集选项中的更改的轮询间隔。 如果副本发生故障,群集将尝试按 failure-timeout 值和 cluster-recheck-interval 值所绑定的间隔重启副本。 例如,如果 failure-timeout 设置为 60 秒且 cluster-recheck-interval 设置为 120 秒,则会在 60 秒至 120 秒的间隔内尝试重启。 应将 failure-timeout 设置为 60 秒,并将 cluster-recheck-interval 设置为一个大于 60 秒的值。 不建议将 cluster-recheck-interval 设置为较小的值。

若要将属性值更新为 2 minutes,请运行:

sudo pcs property set cluster-recheck-interval=2min

如果已拥有由 Pacemaker 群集管理的可用性组资源,请注意,当 start-failure-is-fatal 群集设置的值为 false 时,所有使用 Pacemaker 包 1.1.18-11.el7 的分发版都会为该设置引入行为更改。 此更改会影响故障转移工作流。 如果主要副本发生中断,群集应故障转移到其中一个可用的次要副本。 然而,用户会注意到群集一直尝试启动发生故障的主要副本。 如果该主要副本由于永久性中断而永远不联机,群集就永远不会将故障转移到另一个可用的次要副本。 由于此更改,先前建议使用的用于设置 start-failure-is-fatal 的配置不再有效,并且必须将该设置还原为其默认值 true

此外,必须更新 AG 资源以包含 failover-timeout 属性。

若要将属性值更新为 true,请运行:

sudo pcs property set start-failure-is-fatal=true

若要将现有 AG 资源属性 failure-timeout 更新为 60s,请运行以下命令(将 ag1 替换为你的可用性组资源的名称):

pcs resource update ag1 meta failure-timeout=60s

安装 SQL Server 资源代理以与 Pacemaker 集成

在所有节点上运行以下命令。

sudo apt-get install mssql-server-ha

为 Pacemaker 创建 SQL Server 登录名

  1. 在所有 SQL Server 上,为 Pacemaker 创建 Server 登录名。 以下 Transact-SQL 创建登录名:

    USE [master]
    GO
    CREATE LOGIN [pacemakerLogin] with PASSWORD= N'ComplexP@$$w0rd!';
    
    ALTER SERVER ROLE [sysadmin] ADD MEMBER [pacemakerLogin];
    

    创建可用性组时,在创建该可用性组之后到向其中添加任何节点之前,pacemaker 用户需要对可用性组的 ALTER、CONTROL 和 VIEW DEFINITION 权限。

  2. 在所有 SQL Server 上,保存 SQL Server 登录名的凭据

    echo 'pacemakerLogin' >> ~/pacemaker-passwd
    echo 'ComplexP@$$w0rd!' >> ~/pacemaker-passwd
    sudo mv ~/pacemaker-passwd /var/opt/mssql/secrets/passwd
    sudo chown root:root /var/opt/mssql/secrets/passwd
    sudo chmod 400 /var/opt/mssql/secrets/passwd # Only readable by root
    

创建可用性组资源

若要创建可用性组资源,请使用 pcs resource create 命令并设置资源属性。 以下命令将为可用性组创建一个名为 ag1ocf:mssql:ag 主要/副本类型的资源。

sudo pcs resource create ag_cluster ocf:mssql:ag ag_name=ag1 meta failure-timeout=30s promotable notify=true

注意

创建资源并在之后定期更新,Pacemaker 资源代理会根据可用性组的配置自动设置可用性组上的 REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT 值。 例如,如果可用性组具有三个同步副本,则代理将 REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT 设置为 1。 有关详细信息和其他配置选项,请参阅可用性组配置的高可用性和数据保护

创建虚拟 IP 资源

若要创建虚拟 IP 地址资源,请在一个节点上运行以下命令。 使用网络中的可用静态 IP 地址。 运行此脚本前,请使用有效的 IP 地址替换 < ... > 之内的值。

sudo pcs resource create virtualip ocf:heartbeat:IPaddr2 ip=<10.128.16.240>

Pacemaker 中不存在等效的虚拟服务器名称。 若要使用指向字符串服务器名称的连接字符串,而不是使用 IP 地址,请在 DNS 中注册 IP 资源地址和所需的虚拟服务器名称。 对于 DR 配置,请在主站点和 DR 站点上使用 DNS 服务器注册所需的虚拟服务器名称和 IP 地址。

加主机托管约束

Pacemaker 群集中的几乎所有决策(例如,选择资源运行的位置)都通过比较分数来完成。 分数按资源计算,群集资源管理器选择特定资源分数最高的节点。 (如果节点的某一资源分数为负,则该资源无法在此节点上运行。)

使用约束来配置群集的决策。 约束具有一个分数。 如果约束的分数低于 INFINITY,则它仅作为建议项。 分数为 INFINITY 则表明它是必需项。

若要确保主要副本和虚拟 IP 资源位于同一主机上,请定义一个分数为 INFINITY 的主机托管约束。 若要添加主机托管约束,请在一个节点上运行以下命令。

sudo pcs constraint colocation add virtualip with master ag_cluster-clone INFINITY

添加排序约束

主机托管约束具有隐式排序约束。 在移动可用性组资源前,它会移动虚拟 IP 资源。 默认情况下的事件序列为:

  1. 用户发出 pcs resource move,将资源从 node1 的可用性组主要副本移动到 node2

  2. 虚拟 IP 资源在 node1 上停止。

  3. 虚拟 IP 资源在 node2 上启动。

    此时,IP 地址暂时指向 node2,同时 node2 仍为故障转移前的次要副本。

  4. node1 上的可用性组主要副本降级为次要副本。

  5. node2 上的可用性组次要副本提升为主要副本。

若要防止 IP 地址暂时指向具有故障转移前的次要副本的节点,请添加排序约束。

若要添加排序约束,请在一个节点上运行以下命令:

sudo pcs constraint order promote ag_cluster-clone then start virtualip

配置群集并将可用性组添加为群集资源后,无法使用 Transact-SQL 对可用性组资源进行故障转移。 Linux 上的 SQL Server 群集资源与此操作系统的耦合性不及在 Windows Server 故障转移群集 (WSFC) 上的耦合性高。 SQL Server 服务无法识别此群集是否存在。 所有业务流程都通过群集管理工具完成。 在 RHEL 或 Ubuntu 中,应使用 pcs

后续步骤