适用于：✔️ Linux VM
总结
本文为 RedHat Enterprise Linux （RHEL） Pacemaker 集群中意外节点重启的常见情况提供故障排除、分析和解决方案的指导。
先决条件
- 按照 在 Azure 上的 Red Hat Enterprise Linux 中设置 Pacemaker 中提供的准则，确保正确配置 Pacemaker 集群。
- 有关使用Azure隔离代理作为 STONITH（拍摄-Other-Node-in-The-Head）设备的 Microsoft Azure Pacemaker 群集，请参阅 RHEL - 创建Azure隔离代理 STONITH 设备文档。
- 对于使用 SBD（STONITH 块设备）存储保护作为 STONITH 设备的 Microsoft Azure Pacemaker 群集，请选择以下设置选项之一（请参阅相关文档以获取详细信息）：
- 带 iSCSI 目标服务器的 SBD
- 具有Azure共享磁盘的 SBD
方案 1：网络中断
- 群集节点遇到
corosync通信错误。 这会导致连续重新传输，因为无法建立节点之间的通信。 此问题会触发应用程序超时，并最终导致节点隔离和后续重启。 - 依赖于网络连接的服务，例如
waagent，在日志中生成与通信相关的错误条目。 这些条目进一步表明与网络相关的中断。
日志中 /var/log/messages 记录了以下消息：
从 node 01：
Aug 21 01:48:00 node 01 corosync[19389]: [TOTEM ] Token has not been received in 30000 ms
Aug 21 01:48:00 node 01 corosync[19389]: [TOTEM ] A processor failed, forming new configuration: token timed out (40000ms), waiting 48000ms for consensus.
从 node 02：
Aug 21 01:47:27 node 02 corosync[15241]: [KNET ] link: host: 2 link: 0 is down
Aug 21 01:47:27 node 02 corosync[15241]: [KNET ] host: host: 2 (passive) best link: 0 (pri: 1)
Aug 21 01:47:27 node 02 corosync[15241]: [KNET ] host: host: 2 has no active links
Aug 21 01:47:31 node 02 corosync[15241]: [TOTEM ] Token has not been received in 30000 ms
方案 1 的原因
由于网络维护活动或服务中断，发生意外的节点重启。 若要验证，可以通过在Azure门户中查看 Azure 维护通知来匹配时间戳。 有关Azure计划事件的详细信息，请参阅 Azure 元数据服务：Linux VM 的计划事件。
方案 1 的解决方法
如果意外的重启时间戳与维护活动保持一致，则分析会确认平台或网络维护影响了群集。
如需进一步的帮助或其他查询，可以按照 以下说明提出支持请求。
方案 2：群集配置错误
群集节点遇到意外的故障转移或节点重启。 这些问题通常是因为群集配置错误而影响 Pacemaker 群集的稳定性。
若要查看群集配置，请运行以下命令：
sudo pcs configure show
方案 2 的原因
Azure SUSE Pacemaker 群集中的意外重启通常因配置错误而发生：
-
STONITH 配置不正确：
- STONITH 或隔离未正确配置：如果未正确配置 STONITH，可能会导致节点被标记为不正常，并触发不必要的重启。
- 错误的 STONITH 资源设置：Azure隔离代理的参数不正确，例如
fence_azure_arm，可能会导致节点在故障转移期间意外重启。 - 权限不足：用于隔离的Azure资源组或凭据可能缺少所需的权限并导致 STONITH 失败。
-
资源约束缺失或不正确：设置不当的约束可能会导致不必要地重新分发资源。 这种情况反过来又可能导致节点重载和重启。 未对齐的资源依赖项配置可能会导致节点失败或进入重启循环。
-
群集阈值和超时错误配置：
failure-time-out、migration-threshold或monitor-time-out值可能会导致节点过早重启。- 心跳超时设置：心跳间隔的错误设置
corosync可能导致节点自动判断其他节点处于离线状态。 这种情况可能会触发不必要的重启。
-
缺少适当的运行状况检查：未为关键服务（如 SAP HANA（高性能 ANalytic 应用程序）设置正确的运行状况检查间隔可能会导致资源或节点故障。
-
资源代理配置错误：
- 与群集不对齐的自定义资源代理：不符合 Pacemaker 标准的资源代理可以创建不可预知的行为，包括节点重启。
- 资源启动/停止参数错误：群集配置中未正确调整的启动/停止参数可能会导致节点在资源恢复期间重启。
方案 2 的解决方法
- 按照正确的准则设置 RHEL Pacemaker 群集。 此外，请确保为 SAP HANA 或 SAP NetWeaver 等应用程序分配适当的资源，如Microsoft文档中指定。
- 对群集配置进行必要更改的步骤：
-
在两个节点上停止应用程序。
-
将群集置于维护模式：
sudo pcs property set maintenance-mode=true -
编辑群集配置：
sudo pcs configure edit -
保存更改。
-
从维护模式中删除群集。
sudo pcs property set maintenance-mode=false
-
重要
排查意外节点重启或故障问题时，评估系统上安装的安全工具的影响至关重要。 这些工具可能会通过阻止基本进程或修改系统文件来干扰群集作。 这种情况可能会导致不稳定、意外超时或节点重启。
为了缓解此类风险，我们建议在运行 Pacemaker 群集的系统上禁用安全工具。 或者，可以配置适当的排除项，以防止与群集及其关联的应用程序发生冲突。
方案 3：从本地迁移到 Azure
将 SUSE Pacemaker 群集从本地迁移到Azure时，可能会因特定配置错误或忽略依赖项而发生意外重启。
方案 3 的原因
以下是在此类别中发生的常见错误：
-
STONITH 配置不完整或不正确：
- 没有 STONITH 或隔离错误配置：未正确配置 STONITH 可能会导致节点标记为不正常，并触发不必要的重启。
- 错误的 STONITH 资源设置：Azure隔离代理（如
fence_azure_arm）的参数不正确可能会导致节点在故障转移期间意外重启。 - 权限不足：用于隔离的Azure资源组或凭据可能缺少所需的权限并导致 STONITH 失败。 必须在隔离代理中正确配置 Azure 特定的重要参数，例如订阅 ID、资源组或虚拟机（VM）名称。 此处的遗漏可能会导致击剑失败和意外重启。
有关详细信息，请参阅 在 RHEL 中解决 Azure Fence 代理启动问题和 在 RHEL Pacemaker 群集中的解决 SBD 服务故障
-
网络配置错误：配置错误的 VNet、子网或安全组规则可能会阻止重要的群集通信，并导致感知到的节点故障和重启。
有关详细信息，请参阅 Azure 中的虚拟网络和虚拟机
-
元数据服务问题：必须正确处理Azure的云元数据服务。 否则，资源检测或启动进程可能会失败。
有关详细信息，请参阅Azure实例元数据服务和Azure元数据服务：Linux VM 的计划事件
-
性能和延迟不匹配：
- VM 大小不当：迁移的工作负荷可能与所选的 Azure VM 大小不一致。 这会导致过度使用资源并触发重启。
- 磁盘 I/O 不匹配：具有高 IOPS（每秒输入/输出操作）要求的本地工作负荷必须与相应的Azure磁盘或存储性能层配对。
有关详细信息，请参阅 收集 Linux VM 的性能指标
-
安全和防火墙规则：
- 端口块：本地群集通常具有开放的内部通信。 此外，Azure NSG（网络安全组）或防火墙可能会阻止 Pacemaker 或 Corosync 通信所需的端口。
有关详细信息，请参阅 网络安全组测试
方案 3 的解决方法
按照适当的准则设置 RHEL Pacemaker 群集。 此外，请确保为 SAP HANA 或 SAP NetWeaver 等应用程序分配适当的资源，如Microsoft文档中指定。
方案 4：RHEL 8 发生故障转移后两个集群节点停止运行
Pacemaker 群集预计服务中断，并继续触发故障转移事件。 在双节点群集配置中，两个节点都终止并保持脱机状态，直到手动干预发生。
日志指示 STONITH 设备 python-user触发这两个节点的关闭指令。
方案 4 的原因
在服务中断（例如平台或网络中断请参见场景 1）期间，两个节点都尝试向 STONITH 设备写入数据，以屏蔽另一个节点，因为它们会丢失 Totem 令牌。 通常，STONITH 设备从第一个可用节点获取指令来写入它，以便关闭另一个节点。 如果两个节点都被允许写入 STONITH 设备，则它们可能会彼此终止。
方案 4 的解决方法
建议使用 priority-fencing-delay 或 pcmk_delay_max 参数，以便 STONITH 设备仅确认一个 VM：
-
在维护模式下设置群集：
sudo pcs property set maintenance-mode=true -
编辑群集配置：
sudo pcs configure edit -
如果 Pacemaker 版本低于
2.0.4-6.el8，请添加pcmk_delay_max参数：sudo pcs property set pcmk_delay_max=15s如果 Pacemaker 版本晚于
2.0.4-6.el8以下，请改用priority-fencing-delay参数：sudo pcs property set priority-fencing-delay=15s -
保存更改，并从维护模式中删除群集：
sudo pcs property set maintenance-mode=false
有关详细信息，请参阅 RHEL - 创建Azure隔离代理 STONITH 设备。
方案 5：HANA_CALL 超时时间为 60 秒
Azure RHEL Pacemaker 群集运行 SAP HANA 作为应用程序，并在一个或两个 Pacemaker 群集节点上意外地经历重启。 根据/var/log/messages或/var/log/pacemaker.log日志记录，节点重启是由于HANA_CALL超时引起的，如下所示：
2024-06-04T09:25:37.772406+00:00 node01 SAPHanaTopology(rsc_SAPHanaTopology_H00_HDB02)[99440]: WARNING: RA: HANA_CALL timed out after 60 seconds running command 'hdbnsutil -sr_stateConfiguration --sapcontrol=1'
2024-06-04T09:25:38.711650+00:00 node01 SAPHana(rsc_SAPHana_H00_HDB02)[99475]: WARNING: RA: HANA_CALL timed out after 60 seconds running command 'hdbnsutil -sr_stateConfiguration'
2024-06-04T09:25:38.724146+00:00 node01 SAPHana(rsc_SAPHana_H00_HDB02)[99475]: ERROR: ACT: check_for_primary: we didn't expect node_status to be: <>
2024-06-04T09:25:38.736748+00:00 node01 SAPHana(rsc_SAPHana_H00_HDB02)[99475]: ERROR: ACT: check_for_primary: we didn't expect node_status to be: DUMP <00000000 0a |.|#01200000001>
方案 5 的原因
SAP HANA超时消息通常被视为内部应用程序超时。 因此，SAP 供应商应参与其中。
方案 5 的解决方法
- 若要确定问题的根本原因，请查看 OS 性能。
- 应特别注意内存压力和存储设备及其配置。 如果 HANA 托管在网络文件系统（NFS）、Azure NetApp 文件（ANF）或Azure 文件存储上，则尤其如此。
- 排除外部因素（如平台或网络中断）后，建议联系应用程序供应商进行跟踪呼叫分析和日志评审。
方案 6： ASCS/ERS SAP Netweaver 群集中的超时
Azure SUSE Pacemaker 群集正在以应用程序的形式运行 SAP Netweaver ASCS/ERS，但在 Pacemaker 群集中的一个或两个节点上出现意外重启情况。 日志中 /var/log/messages 记录了以下消息：
2024-11-09T07:36:42.037589-05:00 node 01 SAPInstance(RSC_SAP_ERS10)[8689]: ERROR: SAP instance service enrepserver is not running with status GRAY !
2024-11-09T07:36:42.044583-05:00 node 01 pacemaker-controld[2596]: notice: Result of monitor operation for RSC_SAP_ERS10 on node01: not running
2024-11-09T07:39:42.789404-05:00 node01 SAPInstance(RSC_SAP_ASCS00)[16393]: ERROR: SAP Instance CP2-ASCS00 start failed: #01109.11.2024 07:39:42#012WaitforStarted#012FAIL: process msg_server MessageServer not running
2024-11-09T07:39:420.796280-05:00 node01 pacemaker-execd[2404]: notice: RSC_SAP_ASCS00 start (call 78, PID 16393) exited with status 7 (execution time 23.488s)
2024-11-09T07:39:42.828845-05:00 node 01 pacemaker-schedulerd[2406]: warning: Unexpected result (not running) was recorded for start of RSC_SAP_ASCS00 on node01 at Nov 9 07:39:42 2024
2024-11-09T07:39:42.828955-05:00 node 01 pacemaker-schedulerd[2406]: warning: Unexpected result (not running) was recorded for start of RSC_SAP_ASCS00 on node01 at Nov 9 07:39:42 2024
方案 6 的原因
资源 ASCS/ERS 被视为 SAP Netweaver 集群的应用程序。 当相应的群集监视资源超时时，它会触发故障转移机制。
方案 6 的解决方法
- 若要确定问题的根本原因，建议查看 OS 性能。
- 应特别注意内存压力和存储设备及其配置。 如果 SAP Netweaver 托管在网络文件系统（NFS）、Azure NetApp 文件（ANF）或Azure 文件存储上，则尤其如此。
- 排除外部因素（如平台或网络中断）后，建议让应用程序供应商参与跟踪呼叫分析和日志评审。