排查 Azure Linux SUSE Pacemaker 群集中的意外节点重启问题

适用于：✔️ Linux VM 总结本文为排查、分析和解决 SUSE Pacemaker 群集内意外节点重启的最常见情况提供指导。先决条件 - 请确保按照 SUSE 中提供的准则正确配置 Pacemaker 群集设置 - 在 Azure(/zh-cn/azure/sap/workloads/high-availability-guide-suse-pacemaker) 中的 SUSE Linux Enterprise Server 上设置 Pacema

适用于：✔️ Linux VM

总结

本文为排查、分析和解决 SUSE Pacemaker 群集内意外节点重启的最常见情况提供指导。

先决条件

请确保按照 SUSE 中提供的准则正确配置 Pacemaker 群集设置 - 在 Azure 中的 SUSE Linux Enterprise Server 上设置 Pacemaker。
有关在使用 Azure Fence Agent 作为 STONITH（Shoot-The-Other-Node-In-The-Head）设备的 Microsoft Azure Pacemaker 群集的文档，请参阅 SUSE - 创建 Azure Fence Agent 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 crm 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 标准的资源代理可以创建不可预知的行为，包括节点重启。
- 资源启动/停止参数错误：群集配置中未正确调整的启动/停止参数可能会导致节点在资源恢复期间重启。
Corosync 配置问题：
- 非优化网络设置：多播/单播配置不正确可能会导致心跳通信失败。 ring0 和 ring1 网络配置不匹配可能导致分裂脑现象和节点隔离措施。
- 令牌超时不匹配：与环境延迟不匹配的令牌超时值可能会触发节点隔离和重新启动。
- 若要查看 Corosync 配置，请运行以下命令：
```
sudo cat /etc/corosync/corosync.conf
```

方案 2 的解决方法

按照适当的准则设置 SUSE Pacemaker 群集。此外，请确保为 SAP HANA 或 SAP NetWeaver 等应用程序分配适当的资源，如Microsoft文档中指定。
对群集配置进行必要更改的步骤：
1. 在两个节点上停止应用程序。
2. 将群集置于维护模式。
```
crm configure property maintenance-mode=true 
```
3. 编辑群集配置：
```
crm configure edit 
```
4. 保存更改。
5. 从维护模式中删除群集。
```
crm configure property maintenance-mode=false
```

方案 3：从本地迁移到 Azure

将 SUSE Pacemaker 群集从本地环境迁移到 Azure 时，可能会由于特定的配置错误或被忽略的依赖项而导致意外重启。

方案 3 的原因

以下是此类别中的常见错误：

STONITH 配置不完整或不正确：
- 未正确配置 STONITH 或隔离配置错误：未正确配置 STONITH（射杀对方节点）可能会导致节点被标记为不正常，并触发不必要的重启。
- 错误的 STONITH 资源设置：Azure隔离代理（如 fence_azure_arm）的参数不正确可能会导致节点在故障转移期间意外重启。
- 权限不足：用于隔离的Azure资源组或凭据可能缺少所需的权限并导致 STONITH 失败。必须在隔离代理中正确配置关键的 Azure 特定参数，例如订阅 ID、资源组或 VM 名称。此处的遗漏可能会导致围栏故障和意外重启。
有关详细信息，请参阅排查 SUSE 中的 Azure 隔离代理启动问题和排查 SUSE Pacemaker 群集中的 SBD 服务故障
网络配置错误：配置错误的 VNet、子网或安全组规则可能会阻止重要的群集通信，并导致感知到的节点故障和重启。

有关详细信息，请参阅 Azure 中的虚拟网络和虚拟机
元数据服务问题：必须正确处理Azure的云元数据服务。否则，资源检测或启动进程可能会失败。

有关详细信息，请参阅Azure实例元数据服务和Azure元数据服务：Linux VM 的计划事件
性能和延迟不匹配：
- VM 大小调整不足：已迁移的工作负荷可能与所选Azure VM（虚拟机）大小不一致。这会导致过度使用资源并触发重启。
- 磁盘 I/O 不匹配：具有高 IOPS（每秒输入/输出操作）的本地工作负荷必须与适当的Azure磁盘或存储性能层配对。
有关详细信息，请参阅收集 Linux VM 的性能指标
安全和防火墙规则：
- 端口块：本地群集通常具有开放的内部通信。此外，Azure NSG（网络安全组）或防火墙可能会阻止 Pacemaker 或 Corosync 通信所需的端口。
有关详细信息，请参阅网络安全组测试

方案 3 的解决方法

按照适当的准则设置 SUSE Pacemaker 群集。此外，请确保为 SAP HANA 或 SAP NetWeaver 等应用程序分配适当的资源，如Microsoft文档中指定。

方案 4： `HANA_CALL` 60 秒后超时

Azure SUSE 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>

方案 4 的原因

SAP HANA超时消息通常被视为内部应用程序超时。因此，SAP 供应商应参与其中。

方案 4 的解决方法

若要确定问题的根本原因，请查看 OS 性能。
应特别注意内存压力和存储设备及其配置。如果 HANA 托管在网络文件系统（NFS）、Azure NetApp 文件（ANF）或Azure 文件存储上，则尤其如此。
排除外部因素（如平台或网络中断）后，建议联系应用程序供应商进行跟踪呼叫分析和日志评审。

方案 5： `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

方案 5 的原因

资源 ASCS/ERS 被视为 SAP Netweaver 集群的应用程序。当相应的群集监视资源超时时，它会触发故障转移机制。

解决方法方案 5

若要确定问题的根本原因，建议查看 OS 性能。
应特别注意内存压力和存储设备及其配置。如果 SAP Netweaver 托管在网络文件系统（NFS）、Azure NetApp 文件（ANF）或Azure 文件存储上，则尤其如此。
排除外部因素（如平台或网络中断）后，建议让应用程序供应商参与跟踪呼叫分析和日志评审。

排查 Azure Linux SUSE Pacemaker 群集中的意外节点重启问题 - Virtual Machines

总结

先决条件

方案 1：网络中断

方案 1 的原因

方案 1 的解决方法

方案 2：群集配置错误

方案 2 的原因

方案 2 的解决方法

方案 3：从本地迁移到 Azure

方案 3 的原因

方案 3 的解决方法

方案 4： `HANA_CALL` 60 秒后超时

方案 4 的原因

方案 4 的解决方法

方案 5： `ASCS/ERS` SAP Netweaver 群集中的超时

方案 5 的原因

解决方法方案 5

资料来源与适用范围

总结

先决条件

方案 1：网络中断

方案 1 的原因

方案 1 的解决方法

方案 2：群集配置错误

方案 2 的原因

方案 2 的解决方法

方案 3：从本地迁移到 Azure

方案 3 的原因

方案 3 的解决方法

方案 4： HANA_CALL 60 秒后超时

方案 4 的原因

方案 4 的解决方法

方案 5： ASCS/ERS SAP Netweaver 群集中的超时

方案 5 的原因

解决方法方案 5

资料来源与适用范围

方案 4： `HANA_CALL` 60 秒后超时

方案 5： `ASCS/ERS` SAP Netweaver 群集中的超时