排查 SAP 的高可用性配置问题

在 SAP on Google Cloud 的高可用性配置中，导致出现问题的根本原因可能在于集群软件、SAP 软件、Google Cloud 基础架构或这些因素的一些组合。

分析 Cloud Logging 中的 Pacemaker 日志

以下视频展示了如何开始使用 Cloud Logging 排查 Google Cloud 上的 SAP 高可用性配置问题。

故障切换后，Linux 集群中的故障节点无法正确重启

如果您的 Linux 高可用性集群使用 fence_gce 防护代理，并且经过防护的虚拟机在故障切换后无法重新加入集群，则您可能需要在防护后的虚拟机重启时延迟 Corosync 软件的启动。

问题

在故障切换期间，fence_gce 代理会防护发生故障的 Compute Engine 虚拟机，该虚拟机会在 Pacemaker 将防护操作注册为完成之前重启并重新加入集群。由于防护操作尚未注册为完成，因此重启后的虚拟机会关闭其 Pacemaker 和 Corosync 服务并退出集群。

诊断

如需确认这就是您的问题所在，请执行以下操作：

确保您的集群使用的是 fence_gce 代理：

RHEL

pcs config

SLES

crm config show

防护代理定义包括 fence_gce。

RHEL

Stonith Devices:
Resource: STONITH-example-ha-vm1 (class=stonith type=fence_gce)
Attributes: port=example-ha-vm1 project=example-project-123456 zone=us-central1-a
Operations: monitor interval=300s timeout=120s (STONITH-example-ha-vm1-monitor-interval-60s)
Resource: STONITH-example-ha-vm2 (class=stonith type=fence_gce)
Attributes: port=example-ha-vm2 project=example-project-123456 zone=us-central1-c
Operations: monitor interval=300s timeout=120s (STONITH-example-ha-vm2-monitor-interval-60s)

SLES

primitive fence-example-ha-vm1 stonith:fence_gce \
 op monitor interval=300s timeout=120s \
 op start interval=0 timeout=60s \
 params port=example-ha-vm1 zone=us-central1-a project=example-project-123456
primitive fence-example-ha-vm2 stonith:fence_gce \
 op monitor interval=300s timeout=120s \
 op start interval=0 timeout=60s \
 params port=example-ha-vm2 zone=us-central1-c project=example-project-123456

检查系统日志中是否出现以下消息：

DATESTAMP> node2 stonith-ng[1106]:  notice: Operation reboot of node2 by node1 for stonith_admin.1366@node1.c3382af8: OK
DATESTAMP> node2 stonith-ng[1106]:   error: stonith_construct_reply: Triggered assert at commands.c:2343 : request != NULL
DATESTAMP> node2 stonith-ng[1106]: warning: Can't create a sane reply
DATESTAMP> node2 crmd[1110]:    crit: We were allegedly just fenced by node1 for node1!
DATESTAMP> node2 pacemakerd[1055]: warning: Shutting cluster down because crmd[1110] had fatal failure

解决方案

在两个集群节点中配置操作系统以延迟 Corosync 的启动，从而确保防护操作有时间向新的主节点上的 Pacemaker 注册为完成。此外，还需设置 Pacemaker 的重启超时值，以将该延迟考虑在内。

如需配置 Corosync 的延迟启动，请执行以下操作：

将集群置于维护模式：

RHEL

pcs property set maintenance-mode=true

SLES

crm configure property maintenance-mode="true"

在每个集群节点上，以根用户身份为 Corosync 设置启动延迟：
1. 创建 systemd 普适性文件：
```
systemctl edit corosync.service
```
2. 将以下代码行添加到文件中：
```
[Service]
ExecStartPre=/bin/sleep 60
```
3. 保存文件并退出编辑器。
4. 重新加载 systemd 管理器配置。
```
systemctl daemon-reload
```
在任一集群节点上，以根用户的身份为两个防护代理设置重启的 Pacemaker 超时值：
1. 检查 pcmk_reboot_timeout 值：
```
crm_resource --resource FENCE_AGENT_NAME --get-parameter=pcmk_reboot_timeout
```
  将 FENCE_AGENT_NAME 替换为防护代理的名称。
2. 如果未找到 pcmk_reboot_timeout 参数，或将其设置为小于 300 的值，请在这两个防护代理上设置该值：
```
crm_resource --resource FENCE_AGENT_NAME --set-parameter=pcmk_reboot_timeout --parameter-value=300
```
  将 FENCE_AGENT_NAME 替换为防护代理的名称。
  
  pcmk_reboot_timeout 值应大于以下各项之和：
  - Corosync token 超时
  - Corosync 共识超时，默认情况下是 token * 1.2 的乘积
  - 重启操作完成所需的时长，包括任何延迟特性。
  在 Google Cloud 上，对于大多数集群来说，300 秒就足够了。
3. 确认新的 pcmk_reboot_timeout 值：
```
crm_resource --resource FENCE_AGENT_NAME --get-parameter=pcmk_reboot_timeout
```
  将 FENCE_AGENT_NAME 替换为防护代理的名称。

让集群退出维护模式：

RHEL

pcs property set maintenance-mode=false

SLES

crm configure property maintenance-mode="false"

支持特定节点的意外节点亲和性

使用集群命令在高可用性集群中手动移动资源时，您会发现自动亲和性或客户端偏好设置被设置为支持特定节点。

问题

在适用于 SAP HANA 或 SAP NetWeaver 的 Linux Pacemaker 高可用性集群中，SAP HANA 系统或 SAP NetWeaver 中央服务等资源仅在一个特定的集群节点上运行，并且在节点故障事件期间不会按预期进行故障切换。

因此，您可能会遇到以下问题：

当您通过发出 Pacemaker 命令将资源 move 到集群节点来触发 SAP NetWeaver ASCS 服务故障切换时，资源不会启动并显示 stopped 状态。
向一个集群节点发出 standby 命令以强制将所有资源移至另一个节点时，这些资源将不会启动。

诊断

检查 Pacemaker 日志，了解提及特定资源且无法在任何位置运行的消息。例如：

2021-05-24 21:39:58 node_1 pacemaker-schedulerd (native_color) info:
 Resource NW1-ASCS01 cannot run anywhere

检查您的 Pacemaker 位置限制条件配置，以确定任何可能阻止资源在特定集群节点上运行的限制条件。

要检查 Pacemaker 位置限制条件配置，请按以下步骤操作：
1. 显示位置限制条件：
```
cibadmin --query --scope constraints | grep rsc_location
```
2. 验证位置限制条件：
  - 显式位置限制条件：您会找到得分为 INFINITY（首选节点）或 -INFINITY（避免节点）的位置限制条件。例如：
```
<rsc_location id="loc-constraint" rsc="NW1-ASCS01" score="INFINITY" node="nw-ha-1"/>
```
    除了防护代理之外，不得存在任何得分为 INFINITY 或 -INFINITY 的位置限制条件。在所有高可用性集群中，防护代理是在得分为 -INFINITY 的位置限制条件中定义的，以防止它们在作为防护目标的节点上运行。
  - 隐式位置限制条件：当您发出 Pacemaker 命令以将资源移动到集群节点或禁止资源在集群节点上运行时，前缀为 cli-ban 或 cli-prefer 的隐式位置限制条件会添加到限制条件 ID 中。例如：
```
<rsc_location id="cli-prefer-NW1-ASCS01" rsc="NW1-ASCS01" role="Started" node="nw-ha-2" score="INFINITY"/>
```

解决方案

确保按照我们的部署指南中的说明指定位置限制条件：
如需修复显式位置限制条件，请删除位置限制条件：
RHEL
```
pcs constraint remove RESOURCE_LOCATION_ID
```
SLES
```
crm configure delete RESOURCE_LOCATION_ID
```
将 RESOURCE_LOCATION_ID 替换为位置限制条件 ID。
如需修复隐式位置限制条件，请移除对指定资源定义的所有限制条件。

在您移动或禁止资源的每个命令后，请运行以下命令移除所有限制条件：
RHEL
```
pcs resource clear RESOURCE_NAME
```
SLES
```
crm resource clear RESOURCE_NAME
```
将 RESOURCE_NAME 替换为您要移动的资源的名称。

防护代理遇到操作错误

防护代理已报告集群状态错误。

问题

在适用于 SAP HANA 或 SAP NetWeaver 的 Linux Pacemaker 高可用性集群中，防护代理已报告集群状态错误。例如：

Failed Resource Actions:
   STONITH-ha-node-01_monitor_300000 on ha-node-02 'unknown error' (1): call=153, status=Timed Out, exitreason='',  last-rc-change='Mon Dec 21 23:40:47 2023', queued=0ms, exec=60003ms

诊断

部署在 SAP HANA 或 SAP NetWeaver 高可用性集群中的防护代理会定期访问 Compute Engine API 服务器以检查防护目标实例的状态。如果 API 调用响应出现暂时性延迟或网络中断，则防护代理监控操作可能会失败或超时。

如需检查防护代理状态，请运行以下命令：

RHEL

pcs status

SLES

crm status

如果防护代理状态为 stopped，请使用其中一个解决方案选项来解决该错误。

防护代理操作错误可能会导致防护代理停止，但 Pacemaker 仍会在防护事件中使用停止指令调用防护代理。

解决方案

如果防护代理状态为 stopped，请执行以下操作之一：

如需手动重置失败计数并重启防护代理，请运行以下命令：
RHEL
```
pcs resource cleanup FENCE_AGENT_NAME
```
SLES
```
crm resource cleanup FENCE_AGENT_NAME
```
将 FENCE_AGENT_NAME 替换为防护代理的名称。
如需自动移除防护代理操作错误，请配置 failure-timeout 参数。

failure-timeout 参数会在指定时长后重置失败计数，并清除所有操作错误。应用此参数不要求重启集群或将集群置于维护模式。

如需配置 failure-timeout 参数，请运行以下命令：
```
crm_resource --meta --resource FENCE_AGENT_NAME --set-parameter failure-timeout --parameter-value DURATION
```
请替换以下内容：
- FENCE_AGENT_NAME：防护代理的名称。
- DURATION：上次操作失败后的时长，在此之后，会重置失败计数并重启防护代理。

资源代理已停止

资源代理未能启动并保持 Stopped 状态。

问题

在适用于 SAP HANA 或 SAP NetWeaver 的 Linux Pacemaker 高可用性集群中，资源代理已报告一个集群状态错误。例如：

Failed Resource Actions:
   rsc_SAPHana_DV0_HDB00_start_0 on ha-node-02 'error' (1): call=91, status='complete', last-rc-change='Wed Oct 18 18:00:31 2023', queued=0ms, exec=19010ms

诊断

如果正在运行的资源代理失败，则 Pacemaker 会尝试停止并重启代理。如果启动操作因任何原因失败，则 Pacemaker 会将资源失败计数设置为 INFINITY，并尝试在其他节点上启动代理。如果资源代理无法在任何节点上启动，则该资源代理将保持 Stopped 状态。

如需检查资源代理状态，请运行以下命令：

RHEL

pcs status

SLES

crm status

对于 SAP HANA，以下示例展示了节点 hana-b 上处于 Stopped 状态的资源代理：

Full List of Resources:
  * STONITH-hana-a        (stonith:external/gcpstonith):   Started hana-b
  * STONITH-hana-b        (stonith:external/gcpstonith):   Started hana-a
  * Resource Group: g-primary:
    * rsc_vip_int-primary       (ocf::heartbeat:IPaddr2):        Started hana-a
    * rsc_vip_hc-primary        (ocf::heartbeat:anything):       Started hana-a
  * Clone Set: cln_SAPHanaTopology_DV0_HDB00 [rsc_SAPHanaTopology_DV0_HDB00]:
    * Started: [ hana-a hana-b ]
  * Clone Set: msl_SAPHana_DV0_HDB00 [rsc_SAPHana_DV0_HDB00] (promotable):
    * Masters: [ hana-a ]
    * Stopped: [ hana-b ]
  * STONITH-scaleup-majority    (stonith:external/gcpstonith):   Started hana-b

解决方案

如果资源代理处于 Stopped 状态，请执行以下操作：

通过重置失败计数手动启动资源代理：
RHEL
```
pcs resource cleanup RESOURCE_AGENT_NAME
```
SLES
```
crm resource cleanup RESOURCE_AGENT_NAME
```
将 RESOURCE_AGENT_NAME 替换为资源代理的名称。例如 rsc_SAPHana_DV0_HDB00。
确保资源代理的状态处于 Started 状态：
```
crm_mon
```
如果资源代理仍无法启动，请收集相关诊断信息并与支持团队联系。