52CE 我爱测NETWORK OBSERVATORY 网络诊断 · 技术资料 · 运维工具
首页/信息库/启动与虚拟机故障
启动与虚拟机故障

排查 SUSE Pacemaker 群集中的启动问题 - Virtual Machines

· 52CE 我爱测

适用于：✔️ Linux VM 总结 本文列出了 Pacemaker 服务启动问题的常见原因，并提供解决问题的解决方案。 方案 1：由于 SysRq 触发的重新启动，Pacemaker 启动失败 如果上次启动是由 SysRq作触发的，Pacemaker 服务不会启动。 正常重启后，Pacemaker 服务可以成功启动。 此问题由 STONITH 块设备（SBD）msgwait 时间与这些 Azure 虚拟机（VM）的快速重启时间之间的冲突引起（如 /etc

适用于：✔️ Linux VM

总结

本文列出了 Pacemaker 服务启动问题的常见原因，并提供解决问题的解决方案。

方案 1：由于 SysRq 触发的重新启动，Pacemaker 启动失败

如果上次启动是由 SysRq作触发的，Pacemaker 服务不会启动。 正常重启后，Pacemaker 服务可以成功启动。 此问题由 STONITH 块设备（SBD）msgwait 时间与这些 Azure 虚拟机（VM）的快速重启时间之间的冲突引起（如 /etc/sysconfig/sbd 文件中指定的）：

## Type: yesno / integer
## Default: no
#
# Whether to delay after starting sbd on boot for "msgwait" seconds.
# This may be necessary if your cluster nodes reboot so fast that the # other nodes are still waiting in the fence acknowledgement phase.
# This is an occasional issue with virtual machines.
#
# This can also be enabled by being set to a specific delay value, in # seconds. Sometimes a longer delay than the default, "msgwait", is # needed, for example in the cases where it's considered to be safer to 
# wait longer than:
# corosync token timeout + consensus timeout + pcmk_delay_max + msgwait # # Be aware that the special value "1" means "yes" rather than "1s".
#
# Consider that you might have to adapt the startup-timeout accordingly # if the default isn't sufficient. (TimeoutStartSec for systemd) # # This option may be ignored at a later point, once Pacemaker handles 
# this case better.
SBD_DELAY_START=no

方案 1 的解决方法

  1. 将群集置于维护模式：

    sudo crm configure property maintenance-mode=true

  2. 编辑/etc/sysconfig/sbd文件以将SBD_DELAY_START参数更改为yes。

  3. 从维护模式中删除群集：

    sudo crm configure property maintenance-mode=false

  4. 重启 Pacemaker 和 SDB 服务，或重启这两个节点：

    sudo systemctl restart sbd
sudo systemctl restart Pacemaker

方案 2：Pacemaker 在节点隔离后不启动并返回代码 100

隔离群集节点后，Pacemaker 服务会退出而不启动，并返回 100** 的退出状态代码**。

systemctl status Pacemaker.service

● Pacemaker.service - Pacemaker High Availability Cluster Manager
   Loaded: loaded (/usr/lib/systemd/system/Pacemaker.service; enabled; vendor preset: disabled)
   Active: inactive (dead) since Wed 2020-05-13 23:38:21 UTC; 25s ago
     Docs: man:Pacemakerd
           https://clusterlabs.org/Pacemaker/doc/en-US/Pacemaker/1.1/html-single/Pacemaker_Explained/index.html
 Main PID: 1570 (code=exited, status=100)

方案 2 的原因

如果节点在被隔离后尝试在超时结束前重新加入群集，Pacemaker 服务不会启动。 相反，服务返回的退出状态代码为 100。 若要解决此问题，请启用 SBD_DELAY_START 设置，并为 sbd.service 的启动指定 msgwait 延迟。 这样，节点就可以有更多的时间重新加入群集，并确保节点可以重新加入，而不会发生 msgwait 冲突。

请留意，如果使用了 SBD_DELAY_START 设置，并且 SBD msgwait 值很高，则可能会出现其他潜在问题。 有关详细信息，请参阅 SBD_DELAY_START中有关长时间超时的设置。

方案 2 的解决方法 A

  1. 将群集置于维护模式：

    sudo crm configure property maintenance-mode=true

  2. 编辑/etc/sysconfig/sbd文件以将SBD_DELAY_START参数更改为yes。

  3. 创建sbd.service的副本

    cp /usr/lib/systemd/system/sbd.service /etc/systemd/system/sbd.service

  4. 在/etc/systemd/system/sbd.service和[Unit]节中编辑[Service]，以添加以下行：

    [Unit]
Before=corosync.service
[Service]
TimeoutSec=144

  5. 从维护模式中删除群集：

    sudo crm configure property maintenance-mode=false

  6. 重启 Pacemaker 和 SDB 服务，或重启这两个节点：

    sudo systemctl restart sbd
sudo systemctl restart Pacemaker

方案 2 的解决方案 B

将 SDB 设备 msgwait 的超时设置调整为比完成 SBD 隔离操作所需的时间更短，并确保在 sbd.service 重启后恢复原设置。 将 watchdog 参数编辑为新 msgwait 超时值的 50%。 这是一个优化过程，必须逐系统进行调整。

方案 3：Azure 事件代理资源中出现问题

方案 3 的症状

crm status输出显示影响Azure事件监视器资源的“失败资源操作”错误：

'Failed Resource Actions:
* rsc_azure-events_monitor_10000 on node1 'error' (1): call=82, status='complete', exitreason='getInstanceInfo: Unable to get instance info', last-rc-change='2024-09-26 06:51:31 +10:00', queued=0ms, exec=94ms'

方案 3 的原因

运行群集节点的Azure平台主机（物理服务器）接收平台级主机维护更新。 如果此更新的持续时间超过了群集资源启动重启所需的时间，则资源作会失败。

在群集节点上的 /var/log/messages 中记录以下错误数据：

python3[11159]: 2024-09-25T20:51:34.040196Z ERROR ExtHandler ExtHandler Error fetching the goal state: [ProtocolError] Error fetching goal state: [ResourceGoneError] [HTTP Failed] [410: Gone] b'<?xml version="1.0" encoding="utf-8"?>\n<Error xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">\n    <Code>ResourceNotAvailable</Code>\n    <Message>The resource requested is no longer available. Please refresh your cache.</Message>\n   <Details></Details>\n</Error>'
2024-09-26T06:51:34.040396+10:00 node1 python3[11159]: Traceback (most recent call last):
2024-09-26T06:51:34.040432+10:00 node1 python3[11159]:   File "/usr/lib/python3.6/site-packages/azurelinuxagent/common/protocol/wire.py", line 776, in update_goal_state
2024-09-26T06:51:34.040475+10:00 node1 python3[11159]:    self._goal_stateupdate(silent=silent)
2024-09-26T06:51:34.040507+10:00 CVCJLPPAP001 python3[11159]:   File "/usr/lib/python3.6/site-packages/azurelinuxagent/common/protocol/goal_state.py", line 147, in update
...
...
2024-09-26T06:51:34.040902+10:00 node1 python3[11159]:     raise ResourceGoneError(response_error)
2024-09-26T06:51:34.040949+10:00 node1 python3[11159]: azurelinuxagent.common.exception.ResourceGoneError: [ResourceGoneError] [HTTP Failed] [410: Gone] b'<?xml version="1.0" encoding="utf-8"?>\n<Error xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">\n   <Code>ResourceNotAvailable</Code>\n    <Message>The resource requested is no longer available. Please refresh your cache.</Message>\n   <Details></Details>\n</Error>'

在群集节点上的 /var/log/messages 中记录以下错误数据：

2024-09-26T06:51:30.997118+10:00 node1 azure-events: WARNING: Failed to reach the server: Gone
2024-09-26T06:51:31.005469+10:00 node1 azure-events: ERROR: getInstanceInfo: Unable to get instance info
2024-09-26T06:51:31.013735+10:00 node1 pacemaker-execd[10439]:  notice: rsc_azure-events_monitor_10000[2080672] error output [ ocf-exit-reason:getInstanceInfo: Unable to get instance info ]
2024-09-26T06:51:31.014026+10:00 node1 pacemaker-controld[10442]: notice: Result of monitor operation for rsc_azure-events on node1: error

2024-09-26T06:51:33.562902+10:00 node1 python3[11159]: 2024-09-25T20:51:33.562638Z WARNING MonitorHandler ExtHandler Error in SendHostPluginHeartbeat: [ResourceGoneError] [HTTP Failed] [410: Gone] b'<?xml version="1.0" encoding="utf-8"?>\n<Error xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">\n   <Code>ResourceNotAvailable</Code>\n    <Message>The resource requested is no longer available. Please refresh your cache.</Message>\n   <Details></Details>\n</Error>' --- [NOTE: Will not log the same error for the next hour]
2024-09-26T06:51:34.040307+10:00 node1 python3[11159]: 2024-09-25T20:51:34.040196Z ERROR ExtHandler ExtHandler Error fetching the goal state: [ProtocolError] Error fetching goal state: [ResourceGoneError] [HTTP Failed] [410: Gone] b'<?xml version="1.0" encoding="utf-8"?>\n<Error xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">\n    <Code>ResourceNotAvailable</Code>\n    <Message>The resource requested is no longer available. Please refresh your cache.</Message>\n   <Details></Details>\n</Error>'
2024-09-26T06:51:34.040396+10:00 node1 python3[11159]: Traceback (most recent call last):
2024-09-26T06:51:34.040432+10:00 node1 python3[11159]: File "/usr/lib/python3.6/site-packages/azurelinuxagent/common/protocol/wire.py", line 776, in update_goal_state
2024-09-26T06:51:34.040475+10:00 node1 python3[11159]: self._goal_state.update(silent=silent)
...
...
2024-09-26T06:51:34.040902+10:00 node1 python3[11159]: raise ResourceGoneError(response_error)
2024-09-26T06:51:34.040949+10:00 node1 python3[11159]: azurelinuxagent.common.exception.ResourceGoneError: [ResourceGoneError] [HTTP Failed] [410: Gone] b'<?xml version="1.0" encoding="utf-8"?>\n<Error xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">\n   <Code>ResourceNotAvailable</Code>\n    <Message>The resource requested is no longer available. Please refresh your cache.</Message>\n   <Details></Details>\n</Error>'

如果资源未启动三次，则完全失败。 这需要管理员手动干预才能解决问题并执行清理：

pacemaker-schedulerd[8995]:  warning: Unexpected result (error: getInstanceInfo: Unable to get instance info) was recorded for monitor of rsc_azure-events:0 on node1 at Sep 26 06:51:31 2024 
pacemaker-schedulerd[8995]:  warning: cln_azure-events cannot run on node1 due to reaching migration threshold (clean up resource to allow again)

备注

如果未从平台层捕获指示主机级更新或连接问题的相关日志条目，请配置 rtmon 以确保 OS 记录必要的详细信息以识别根本原因，即使平台未捕获日志也是如此。

方案 3 的解决方法

确保为Azure计划事件正确配置 Pacemaker。 有关详细信息，请参阅 为 Azure 计划事件配置 Pacemaker。

建议修改 rsc_azure-events 资源基元配置，在重启操作开始前加入 60 秒的延迟。 这种延迟允许Azure代理完成主机级维护任务，而不会触发完整的资源故障。 有关详细信息，请参阅以下 SUSE 知识库文章：rsc_azure事件资源失败并出现错误：无法获取实例信息。

为此，请按照下列步骤操作：

  1. 将群集置于维护模式：

    sudo crm configure property maintenance-mode=true

  2. 输入交互式配置模式：

    sudo crm configure edit health-azure-events

  3. 修改health-azure-events的参数，如以下输出所示：

    primitive health-azure-events azure-events-az \
     meta failure-timeout=120s \
     op start start-delay=60s interval=0s \
     op monitor interval=10s

  4. 保存更改并退出编辑器。

  5. 验证更改：

    sudo crm config show

  6. 从维护模式中删除群集：

    sudo crm configure property maintenance-mode=false

方案 4：SAP HANA DB 资源未启动

方案 4，症状 1 - SAP HANA DB 资源由于超时错误而失败

SAP 高性能分析设备数据库群集资源（例如：rsc_SAPHANA_DB01 HANA DB）的启动操作失败，并返回超时错误。 但是，当群集处于维护模式时，可以手动（在群集控制外部）成功启动 HANA DB：

pacemaker-execd[xxx]:  warning: rsc_SAPHANA_DB01_start_0 process (PID xxx) timed out
pacemaker-execd[xxx]:  warning: rsc_SAPHANA_DB01_start_0:xxx - timed out after 3600000ms
pacemaker-execd[xxx]:  notice: finished - rsc: rsc_SAPHANA_DB01 action:start call_id:25 pid:xxx exit-code:1 exec-time:3604053ms queue-time:0ms
pacemaker-controld[xxx]:  error: Result of start operation for rsc_SAPHANA_DB01 on xxx: Timed Out

方案 4 的原因，症状 1

方案 4 的解决方法，症状 1

若要解决此问题，请扩展 HANA DB 资源的启动和停止 timeout 参数， rsc_SAPHANA_DB01如 SUSE 知识库文章中建议的那样， HANA DB 资源无法启动。

示例

  1. 将群集置于维护模式：

    sudo crm configure property maintenance-mode=true

  2. 若要防止群集重启 HANA DB，如果群集报告了由于启动失败而导致的错误，请清理先前失败的资源：

    sudo crm resource cleanup

  3. 编辑群集配置以更新 timeout 启动和停止操作的参数。

    sudo crm config edit

    之前：

     primitive rsc_SAPHANA_DB01 ocf:suse:SAPHana \
     op start interval=0 timeout=3600 \
     op stop interval=0 timeout= 3600 \

    之后：

    primitive rsc_SAPHANA_DB01 ocf:suse:SAPHana \
    op start interval=0 timeout=7200 \
    op stop interval=0 timeout=7200 \

  4. 禁用群集维护模式：

    sudo crm configure property maintenance-mode=false

  5. 验证是否已进行更改：

    sudo crm config show

方案 4，症状 2 - SAP HANA DB 资源未启动并返回 unknown error

SAP HANA DB 未启动，并返回 unknown error 消息。

当出现此问题时，以下文本将作为 sudo crm status 输出显示：

    2 nodes configured
    8 resources configured
    
    Node node-1: 
    Node node-2: 
    
    Active resources:
    
     Clone Set: cln_SAPHanaTopology [rsc_SAPHanaTopology]
         rsc_SAPHanaTopology    (ocf::suse:SAPHanaTopology):    Started node-1 
         rsc_SAPHanaTopology    (ocf::suse:SAPHanaTopology):    Started node-2 
     Master/Slave Set: msl_SAPHana [rsc_SAPHana]
         rsc_SAPHana_P40_HDB00    (ocf::suse:SAPHana):    Stopped node-1 (Monitoring)
     Resource Group: g_ip_P40_HDB00
         rsc_ip_P40_HDB00    (ocf::heartbeat:IPaddr2):    Started node-1 
         rsc_nc_P40_HDB00    (ocf::heartbeat:azure-lb):    Started node-1 
     rsc_st_azure    (stonith:fence_azure_arm):    Started node-2 
    
    Failed Resource Actions:
    * rsc_SAPHana_P40_HDB00_monitor_61000 on node-1 'unknown error' (1): call=32, status=complete, exitreason='',
        last-rc-change='Fri Jun 10 00:33:41 2024', queued=0ms, exec=0ms
    * rsc_SAPHana_P40_HDB00_start_0 on node-2 'not running' (7): call=55, status=complete, exitreason='',
        last-rc-change='Fri Jun 10 00:33:41 2024', queued=0ms, exec=3093ms

方案 4 的原因，症状 2

如果主节点和辅助节点之间存在 SYN failures，Pacemaker 将无法启动SAP HANA资源。

辅助群集节点处于 WAITING4PRIM 状态。

该 /var/log/messages 文件夹包含以下 SRHOOK=SFAIL 邮件：

2024-06-10T00:31:40.106622+02:00 node-1 SAPHana(rsc_SAPHana_P2H_HDB00)[55890]: INFO: RA: SRHOOK1=
2024-06-10T00:31:40.149443+02:00 node-1 SAPHana(rsc_SAPHana_P2H_HDB00)[55890]: INFO: RA: SRHOOK2=SFAIL
2024-06-10T00:31:40.155744+02:00 node-1 SAPHana(rsc_SAPHana_P2H_HDB00)[55890]: INFO: RA: SRHOOK3=SFAIL

备注

术语通知：本文仅引用某些旧术语（如 主、 从属和 辅助角色 ），因为它们出现在现有软件项目和命令输出中。 它们的包含对于技术正确性是必要的，并且不会传达其功能使用之外的任何隐含含义。

运行 sudo SAPHanaSR-showAttr时，将显示主数据库节点和辅助数据库节点的以下同步状态：

sudo SAPHanaSR-showAttr

 Global cib-time                 maintenance
 --------------------------------------------
 global Mon Jun 10 01:47:32 2024 false
  
 Hosts         clone_state lpa_fh9_lpt node_state op_mode   remoteHost
roles                            score site  srmode  sync_state version                vhost
 ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 node-1 UNDEFINED   10          online     logreplay node-2 0:P::::                          5     DC1 syncmem SFAIL      2.00.046.00.1581325702 node-1
 node-2 PROMOTED    1693237652  online     logreplay node-1 4:P:master1:master:worker:master 150   DC2 syncmem PRIM       2.00.046.00.1581325702 node-2

方案 4 的解决方法，症状 2

如果主群集节点和辅助群集节点之间存在 SYN failures，Pacemaker 将无法启动SAP HANA资源。 若要缓解此问题，请在主节点和辅助节点之间手动启用 SYN 。

重要

使用 SAP 管理员帐户执行步骤 2、3 和 4。 这是因为这些步骤使用 SAP 系统 ID 手动停止、启动和重新启用复制。

  1. 将群集置于维护模式：

    sudo crm configure property maintenance-mode=true

  2. 检查 SAP HANA 数据库和进程状态：

    • 检查节点中运行的与 SAP 相关的进程。 为此，请在每个节点上运行 HANA 数据库（HBD）信息。 SAP 管理员应能够确认在两个节点上运行所需的进程，以及这两个节点上的数据库是否保持同步。

       HDB info

       USER        PID   PPID %CPU    VSZ   RSS COMMAND
 a00adm     5183   5178  0.0  87684  1804 sshd: a00adm@pts/0
 a00adm     5184   5183  0.0  14808  3624  \_ -sh
 a00adm     5994   5184  0.0  13200  1824      \_ /bin/sh /usr/sap/A00/HDB00/HDB info
 a00adm     6019   5994  0.0  26668  1356          \_ ps fx -U a00adm -o user,pid,ppid,pcpu,vsz,rss,args
 a00adm     5369      1  0.0  20932  1644 sapstart pf=/usr/sap/A00/SYS/profile/A00_HDB00_node1
 a00adm     5377   5369  1.8 582944 292720  \_ /usr/sap/A00/HDB00/node1/trace/hdb.sapA00_HDB00 -d -nw -f /usr/sap/A00/HDB00/node1/daemon.ini pf=/usr/sap/A00/SYS/profile/A00_HDB00_node1
 a00adm     5394   5377  9.3 3930388 1146444      \_ hdbnameserver
 a00adm     5548   5377 21.3 2943472 529672      \_ hdbcompileserver
 a00adm     5550   5377  4.4 2838792 465664      \_ hdbpreprocessor
 a00adm     5571   5377 91.6 7151116 4019640      \_ hdbindexserver
 a00adm     5573   5377 21.8 4323488 1203128      \_ hdbxsengine
 a00adm     5905   5377 18.9 3182120 710680      \_ hdbwebdispatcher
 a00adm     2104      1  0.0 428748 27760 /usr/sap/A00/HDB00/exe/sapstartsrv pf=/usr/sap/A00/SYS/profile/A00_HDB00_node1 -D -u a00adm
 a00adm     2004      1  0.0  31844  2352 /usr/lib/systemd/systemd --user
 a00adm     2008   2004  0.0  63796  2620  \_ (sd-pam)

    • 如果节点上的 SAP DB 和服务未处于活动状态，请联系 SAP 管理员查看并排查问题：

      sudo HDB stop

      或

      sudo sapcontrol -nr <SAPInstanceNo.> -function Stop

    替换 <SAPInstanceNo.> 为需要停止的实例编号。

    • 完成停止操作后，先在主节点启动 HANA DB，然后在辅助节点启动。

      sudo HDB start

      或

      sudo sapcontrol -nr <SAPInstanceNo.> -function Start

  3. 通常，HANA DB 的停止和启动作应同步这两个节点。 如果数据库节点仍未同步，SAP 管理员应通过查看 SAP 日志来排查此问题，以确保数据库节点正确同步。

    备注

    SAP 管理员必须确定应将哪个节点指定为主节点，以及哪个节点作为辅助节点，以确保在此过程中不会丢失任何数据库数据。

  4. 启用复制后，请使用 SAP 系统管理员帐户检查系统复制状态。 在本例中，用户管理员帐户为 hn1adm。

    sudo su - hn1adm -c "python /usr/sap/HN1/HDB03/exe/python_support/systemReplicationStatus.py"

    | Host   | Port  | Service Name | Volume ID | Site ID | Site Name  | Secondary | Secondary | Secondary | Secondary | Secondary     | Replication | Replication | Replication    |
|        |       |              |           |         |            | Host      | Port      | Site ID   | Site Name | Active Status | Mode        | Status      | Status Details |
| -----  | ----- | ------------ | --------- | ------- | ---------  | --------- | --------- | --------- | --------- | ------------- | ----------- | ----------- | -------------- |
| node-1 | 30007 | xsengine     |         2 |       1 | node-1     | node-2     |     30007 |         2 | node-2     | YES           | SYNC        | ACTIVE      |                |
| node-1 | 30001 | nameserver   |         1 |       1 | node-1     | node-2     |     30001 |         2 | node-2     | YES           | SYNC        | ACTIVE      |                |
| node-1 | 30003 | indexserver  |         3 |       1 | node-1     | node-2     |     30003 |         2 | node-2     | YES           | SYNC        | ACTIVE      |                |

status system replication site "2": ACTIVE
overall system replication status: ACTIVE

Local System Replication State
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

mode: PRIMARY
site id: 1
site name: node-1

    在次要节点中，检查输出以确定模式是否设置为 。

    this system is either not running or not primary system replication site

Local System Replication State
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

mode: SYNC
site id: 2
site name: node-2
active primary site: 1
primary master: node-1

  5. 还可以运行以下命令来验证SAP HANA系统复制：

    sudo SAPHanaSR-showAttr

    Global cib-time                 maintenance
--------------------------------------------
global Mon Jun 10 01:57:32 2024 false

Hosts clone_state lpa_fh9_lpt node_state op_mode   remoteHost roles                         score site  srmode  sync_state version                vhost
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
node-1 PROMOTED   1693237652  online     logreplay node-2 4:P:master1:master:worker:master   150    DC1   syncmem PRIM       2.00.046.00.1581325702 node-1
node-2 DEMOTED    10          online     logreplay node-1 4:P:master1:master:worker:master   100    DC2   syncmem SOK        2.00.046.00.1581325702 node-2

  6. 退出 SAP 管理员帐户，并从维护模式中删除群集：

    sudo crm configure property maintenance-mode=false

  7. 确保 Pacemaker 群集资源已成功运行。

第三方信息免责声明

本文讨论的第三方产品由独立于Microsoft的公司制造。 Microsoft对这些产品的性能或可靠性不作任何默示或其他保证。

资料来源与适用范围

资料来源
微软官方 Linux 虚拟机排障文档
适用范围
Azure Linux 虚拟机；按正文发行版、内核及代理版本
内容语言
中文；命令、路径和错误标识保留技术原文
本地收录日期
2026-10-26
授权说明
CC BY 4.0

正文与所需资源由本站本地存储。查看来源及更新记录 ↗

请按适用版本和实际日志确认原因；本站没有对每一种系统或设备逐项执行文中的操作。