排查 Azure 中的 RHEL Pacemaker 群集服务和资源启动问题

适用于：✔️ Linux VM 总结本文讨论 RedHat Enterprise Linux （RHEL） Pacemaker 群集资源或服务中启动问题的最常见原因，并提供识别和解决问题的指导。场景 1：群集服务无法启动，原因是仲裁问题方案 1 的症状 - 群集节点在群集重启后不会加入群集。 - 节点报告为 UNCLEAN (offline)。 - 当前 DC 报告为 NONE. - sudo pcs quorum status 返回以下错误消息：

适用于：✔️ Linux VM

总结

本文讨论 RedHat Enterprise Linux （RHEL） Pacemaker 群集资源或服务中启动问题的最常见原因，并提供识别和解决问题的指导。

场景 1：群集服务无法启动，原因是仲裁问题

方案 1 的症状

群集节点在群集重启后不会加入群集。
节点报告为 UNCLEAN (offline)。

当前 DC 报告为 NONE.

sudo pcs status

Cluster name: rhel-cluster
Cluster Summary:
  * Stack: corosync (Pacemaker is running)
  * Current DC: vm-mce-hana02 (version 2.1.9-1.2.el9_6-49aab9983) - partition with quorum
  * Last updated: Wed Jan  7 09:17:50 2026
  * Last change:  Wed Jan  7 08:38:25 2026 by root via root on vm-mce-hana01
  * 2 nodes configured
  * 9 resource instances configured

Node List:
  * Node vm-mce-hana01: UNCLEAN (offline)
  * Node vm-mce-hana02: UNCLEAN (offline)

sudo pcs quorum status 返回以下错误消息：

sudo pcs quorum status

Error: Unable to get quorum status: Unable to start votequorum status tracking: CS_ERR_BAD_HANDLE

请检查错误：/var/log/messeges 中未配置 Corosync 仲裁。

Jan  7 09:20:50 vm-mce-hana01 pacemaker-controld[28982]: error: Corosync quorum is not configured
Jan  7 09:21:20 vm-mce-hana01 pacemaker-controld[29026]: error: Corosync quorum is not configured

方案 1 的原因

VoteQuorum 服务是 corosync 项目的一个组件。为了防止脑裂情形，可选择将该服务加载到 corosync 集群的节点中。群集中的每个系统都会被分配一定数量的票数以达成仲裁。这确保只有在大多数票被投出时，才可以进行集群操作。每个节点都必须加载服务，或者所有节点都不加载服务。如果服务加载到群集节点的子集，结果不确定。

以下 /etc/corosync/corosync.conf 设置在 corosync 中启用 VoteQuorum 服务：

quorum {
    provider: corosync_votequorum
    two_node: 1
}

VoteQuorum 从 /etc/corosync/corosync.conf中读取其配置。某些值可以在运行时更改，而其他值只能在 corosync 启动时读取。重要的是，这些值在所有参与群集的节点中都是一致的。否则，投票法定人数行为是不可预测的。

方案 1 的解决方法

在进行任何更改之前，请确保具有备份或快照。有关详细信息，请参阅 Azure VM 备份。
检查/etc/corosync/corosync.conf中是否缺少仲裁部分。将现有 corosync.conf 备份与可用的 /etc/corosync/任何备份进行比较。

将群集置于维护模式：

sudo pcs property set maintenance-mode=true

在/etc/corosync/corosync.conf中更新更改。

双节点群集的示例：

sudo cat /etc/corosync/corosync.conf

totem {
  version: 2
  cluster_name: rhel-cluster
  transport: knet
  token: 30000
  crypto_cipher: aes256
  crypto_hash: sha256
  cluster_uuid: df29c619ef55405ab6dc9ba1364ea315
}

nodelist {
    node {
        ring0_addr: vm-mce-hana01
        name: vm-mce-hana01
        nodeid: 1
    }

    node {
        ring0_addr: vm-mce-hana02
        name: vm-mce-hana02
        nodeid: 2
    }
}

quorum {
    provider: corosync_votequorum
    two_node: 1
}

logging {
    to_logfile: yes
    logfile: /var/log/cluster/corosync.log
    to_syslog: yes
    timestamp: on
}

从维护模式中删除群集。

sudo pcs property set maintenance-mode=false

同步群集：
```
sudo pcs cluster sync
```
重新加载 corosync：
```
sudo pcs cluster reload corosync
```

情景 2：群集 VIP 资源中的问题

方案 2 的症状

虚拟 IP 资源（IPaddr2 资源）未在 Pacemaker 中启动或停止。

以下错误条目已记录在/var/log/pacemaker/pacemaker.log中：

Jan 03 13:46:30  IPaddr2(vip_HN1_00)[345260]:    ERROR: [findif] failed
Jan 03 13:46:30.641 vm-mce-hana01 pacemaker-execd     [2162] (log_op_output)    info: vip_HN1_00_monitor_10000[345260] error output [ ocf-exit-reason:[findif] failed ]
Jan 03 13:47:18.067 vm-mce-hana01 pacemaker-schedulerd[2164] (unpack_rsc_op_failure)    warning: Unexpected result (error: [findif] failed) was recorded for monitor of vip_HN1_00 on vm-mce-hana01 at Jan  3 13:46:20 2026 | exit-status=1 id=vip_HN1_00_last_failure_0
Jan 03 13:47:18  IPaddr2(vip_HN1_00)[347048]:    WARNING: [findif] failed

也可以在运行 sudo pcs status时观察到此错误：

sudo pcs status

Failed Resource Actions:
  * vip_HN1_00 10s-interval monitor on vm-mce-hana01 returned 'error' ([findif] failed) at Sat Jan  3 14:04:58 2026 after 37ms

方案 2 的原因

若要选择要在其上启动IPAddr2资源的网络适配器（NIC），请调用IPaddr2中定义的findif()函数，该函数包含在/usr/lib/ocf/resource.d/heartbeat/IPaddr2包中。

正确的网络适配器由在IPAddr2资源上设置的选项决定，例如ip（必需）、cidr_netmask和broadcast。

例如：

检查IPaddr2的设置：

sudo pcs resource config vip_HN1_00

Resource: vip_HN1_00 (class=ocf provider=heartbeat type=IPaddr2)
  Attributes: vip_HN1_00-instance_attributes
    cidr_netmask=24
    ip=10.33.0.9
Operations:
  monitor: vip_HN1_00-monitor-interval-10s
    interval=10s timeout=20s
  start: vip_HN1_00-start-interval-0s
    interval=0s timeout=20s
  stop: vip_HN1_00-stop-interval-0s
    interval=0s timeout=20s

尝试手动确定 NIC 信息。在此示例中，根据 IP 地址和 netmask，我们可以从路由表成功找到 eth0 ：

sudo ip -o -f inet route list match 10.33.0.9/24 scope link

10.33.0.0/24 dev eth0 proto kernel src 10.33.0.5 metric 100

在关闭 NIC (eth0) 的情况下，无法手动查找 NIC 信息，这可能会导致 [findif] 失败。替换 10.33.0.9/24 并 eth0 根据需要。
```
sudo ip link set eth0 down
```
```
sudo ip -o -f inet route list match 10.33.0.9/24 scope link 
```

方案 2 的解决方法

如果与 VIP 默认路由表中不匹配的路由，可以在 Pacemaker 资源中指定 NIC 名称，以便可以将其配置为绕过检查：

在进行任何更改之前，请确保具有备份或快照。有关详细信息，请参阅 Azure VM 备份。

将群集置于维护模式：

sudo pcs property set maintenance-mode=true

更新NIC资源：

sudo pcs resource update vip_HN1_00 nic=eth0

NIC 重启资源：

sudo pcs resource restart vip_HN1_03

vip_HN1_03 successfully restarted

从maintenance-mode中删除群集：

sudo pcs property set maintenance-mode=false

验证IP资源：

sudo pcs resource config show vip_HN1_00

Resource: vip_HN1_00 (class=ocf provider=heartbeat type=IPaddr2)
  Attributes: vip_HN1_00-instance_attributes
    cidr_netmask=24
    ip=10.33.0.9
    nic=eth0
  Operations:
    monitor: vip_HN1_00-monitor-interval-10s
      interval=10s timeout=20s
    start: vip_HN1_00-start-interval-0s
      interval=0s timeout=20s
    stop: vip_HN1_00-stop-interval-0s
      interval=0s timeout=20s

有关此方案的详细信息，请参阅以下 Red Hat 文章：“ERROR： [findif] failed”，如 Pacemaker 中所示。

方案 3：SAP HANA中的问题（高性能分析设备）

方案 3，症状 1：SAP HANA DB 未启动并生成未知错误

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

在 /var/log/messages 日志部分中，记录了一个 SRHOOK()=SFAIL 条目。这表示群集节点不同步。

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

sudo pcs status --full

* Node vm-mce-hana01 (1):
    + hana_XXX_clone_state              : PROMOTED  
    + hana_XXX_sync_state               : PRIM      
    + hana_XXX_roles                    : 4:P:master1:master:worker:master

* Node vm-mce-hana02 (2):
    + hana_XXX_clone_state              : WAITING4PRIM  
    + hana_XX_sync_state                : SFAIL      
    + hana_XXX_roles                    : 4:S:master1:master:worker:slave

备注

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

运行 sudo pcs status时，群集状态如下所示：

sudo pcs status

 * 2 nodes configured
 * 9 resource instances configured

Node List:
  * Online: [ vm-mce-hana01 vm-mce-hana02 ]

Full List of Resources:
  * rsc_st_azure        (stonith:fence_azure_arm):       Started vm-mce-hana01
  * Clone Set: health-azure-events-clone [health-azure-events]:
    * Started: [ vm-mce-hana01 vm-mce-hana02 ]
  * Resource Group: g_ip_HN1_00:
    * nc_HN1_00 (ocf:heartbeat:azure-lb):        Started vm-mce-hana02
    * vip_HN1_00        (ocf:heartbeat:IPaddr2):         Started vm-mce-hana02
  * Clone Set: SAPHanaTopology_HN1_00-clone [SAPHanaTopology_HN1_00]:
    * Started: [ vm-mce-hana01 vm-mce-hana02 ]
  * Clone Set: SAPHana_HN1_00-clone [SAPHana_HN1_00] (promotable):
    * Promoted: [ vm-mce-hana01 ]
    * Stopped: [ vm-mce-hana02 ]

Failed Resource Actions:
  * SAPHana_HN1_00 start on vm-mce-hana02 returned 'not running' at Wed Jan  7 13:39:14 2026 after 739ms

方案 3 的原因，症状 1

如果主节点和辅助节点之间存在SYN故障，Pacemaker 将无法启动SAP HANA资源。给定命令将SAP HANA数据库的复制状态显示为 UNKNOWN，这确认 HANA DB 之间的复制失败。

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

  |Database |Host          |Port  |Service Name |Volume ID |Site ID |Site Name |Secondary     |Secondary |Secondary |Secondary |Secondary          |Replication |Replication |Replication    |Secondary    |
  |         |              |      |             |          |        |          |Host          |Port      |Site ID   |Site Name |Active Status      |Mode        |Status      |Status Details |Fully Synced |
  |-------- |------------- |----- |------------ |--------- |------- |--------- |------------- |--------- |--------- |--------- |------------------ |----------- |----------- |-------------- |------------ |
  |SYSTEMDB |vm-mce-hana01 |30001 |nameserver   |        1 |      1 |Site1     |vm-mce-hana02 |    30001 |        2 |Site2     |CONNECTION TIMEOUT |SYNC        |UNKNOWN     |               |       False |
  |HN1      |vm-mce-hana01 |30007 |xsengine     |        2 |      1 |Site1     |vm-mce-hana02 |    30007 |        2 |Site2     |CONNECTION TIMEOUT |SYNC        |UNKNOWN     |               |       False |
  |HN1      |vm-mce-hana01 |30003 |indexserver  |        3 |      1 |Site1     |vm-mce-hana02 |    30003 |        2 |Site2     |CONNECTION TIMEOUT |SYNC        |UNKNOWN     |               |       False |

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

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

  mode: PRIMARY
  site id: 1
  site name: Site1

重要

SAPHanaSR-showAttr 仅支持 RHEL 7，在 RHEL 8.4+ 中弃用，并在 RHEL 9 中完全删除。因此，替代命令应用于查找复制状态，例如 sudo pcs status --full 或“crm_attribute”。

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

如果主群集节点与辅助群集节点之间存在SYN故障，则 Pacemaker 无法启动SAP HANA资源。若要缓解此问题，必须在主节点和辅助节点之间手动启用 SYN 。

重要

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

在进行任何更改之前，请确保具有备份或快照。有关详细信息，请参阅 Azure VM 备份。
将群集置于维护模式：

    sudo pcs property set maintenance-mode=true

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

a. 验证主节点和辅助节点是否都在运行 SAP 数据库和相关 SAP 进程。其中一个应充当主节点，另一个应用作辅助节点。这可确保两个节点上的数据库保持同步。

b. 在每个节点上切换到<SID>adm并运行HDB info，检查每个节点上正在运行的与 SAP 相关的进程。 SAP 管理员应能够确认所需的进程正在这两个节点上运行。

      HDB info
      ```
      ```output
      USER          PID     PPID  %CPU        VSZ        RSS COMMAND
      hn1adm       5261     5260   0.0       8892       5376 -sh
      hn1adm      13183     5261   0.0       7516       4096  \_ /bin/sh /usr/sap/HN1/HDB00/HDB info
      hn1adm      13212    13183   0.0      10020       3712      \_ ps fx -U hn1adm -o user:8,pid:8,ppid:8,pcpu:5,vsz:10,rss:10,args
      hn1adm      12034        1   0.3      23900      14204 /usr/lib/systemd/systemd --user
      hn1adm      12036    12034   0.0     176000       8732  \_ (sd-pam)
      hn1adm       5219        1   0.0     566736      40900 hdbrsutil  --start --port 30003 --volume 3 --volumesuffix mnt00001/hdb00003.00003 --identifier 1767858538
      hn1adm       4764        1   0.0     566664      40956 hdbrsutil  --start --port 30001 --volume 1 --volumesuffix mnt00001/hdb00001 --identifier 1767858528
      hn1adm       4288        1   0.0       9308       3172 sapstart pf=/usr/sap/HN1/SYS/profile/HN1_HDB00_vm-mce-hana01
      hn1adm       4297     4288   0.2     455668      88620  \_ /usr/sap/HN1/HDB00/vm-mce-hana01/trace/hdb.sapHN1_HDB00 -d -nw -f /usr/sap/HN1/HDB00/vm-mce-hana01/daemon.ini pf=/usr/sap/HN1/SYS/profile/HN1_HDB00_vm-mce-hana01
      hn1adm       4324     4297  10.4    6460472    3496360      \_ hdbnameserver
      hn1adm       4999     4297   0.4     935604     181024      \_ hdbcompileserver
      hn1adm       5002     4297   0.4    1174076     195664      \_ hdbpreprocessor
      hn1adm       5044     4297  19.9    6972960    3707744      \_ hdbindexserver -port 30003
      hn1adm       5047     4297   2.8    4401136    1263592      \_ hdbxsengine -port 30007
      hn1adm       5689     4297   1.2    2237896     436604      \_ hdbwebdispatcher
      hn1adm       1482        1   0.0     500636      58040 /usr/sap/HN1/HDB00/exe/sapstartsrv pf=/usr/sap/HN1/SYS/profile/HN1_HDB00_vm-mce-hana01

c. 如果 SAP DB 和服务在节点上未处于活动状态，我们建议你与 SAP 管理员联系，查看和停止 SAP DB 服务，首先在辅助节点中，然后在主节点中：

      sudo HDB stop

or:

      sudo sapcontrol -nr <SAPInstanceNo> -function Stop

d. 停止操作完成后，先在主节点启动 HANA DB，然后在辅助节点启动。根据需要进行修改 <SAPInstanceNo> 。

      sudo HDB start

or:

      sudo sapcontrol -nr <SAPInstanceNo> -function Start

如果数据库节点仍未同步，SAP 管理员应通过查看 SAP 日志来排查此问题，以确保数据库节点正确同步。

备注

SAP 管理员必须确定应将哪个节点指定为主节点，以及哪个节点作为辅助节点，以确保在此过程中不会丢失任何数据库数据。
启用复制后，请使用 SAP 系统管理员帐户检查系统复制状态。在这种情况下，用户管理员帐户为 hn1adm。

在主节点上，验证整个系统复制状态是否为 ACTIVE。

如果数据库节点仍未同步，SAP 管理员应通过查看 SAP 日志来排查问题，以确保数据库节点正确同步：

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

    |Database |Host          |Port  |Service Name |Volume ID |Site ID |Site Name |Secondary     |Secondary |Secondary |Secondary |Secondary     |Replication |Replication |Replication    |Secondary    |
    |         |              |      |             |          |        |          |Host          |Port      |Site ID   |Site Name |Active Status |Mode        |Status      |Status Details |Fully Synced |
    |-------- |------------- |----- |------------ |--------- |------- |--------- |------------- |--------- |--------- |--------- |------------- |----------- |----------- |-------------- |------------ |
    |SYSTEMDB |vm-mce-hana01 |30001 |nameserver   |        1 |      1 |Site1     |vm-mce-hana02 |    30001 |        2 |Site2     |YES           |SYNC        |ACTIVE      |               |        True |
    |HN1      |vm-mce-hana01 |30007 |xsengine     |        2 |      1 |Site1     |vm-mce-hana02 |    30007 |        2 |Site2     |YES           |SYNC        |ACTIVE      |               |        True |
    |HN1      |vm-mce-hana01 |30003 |indexserver  |        3 |      1 |Site1     |vm-mce-hana02 |    30003 |        2 |Site2     |YES           |SYNC        |ACTIVE      |               |        True |

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

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

    mode: PRIMARY
    site id: 1
    site name: Site1

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

   sudo pcs property set maintenance-mode=false

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

方案 3，症状 2：SAP HANA由于复制失败而无法启动

SAP HANA资源遇到启动失败，其 hana_xxx_roles 属性显示 1:N:master1::worker:。状态 N 指示资源未同步并在独立模式下运行。数据库资源既不是任何节点上的主资源，也不是辅助资源。

运行 sudo pcs status --full 命令时， node attributes 状态如下所示：

  sudo pcs status --full

    Node Attributes:
    * Node: vm-mce-hana01 (1):
      * azName                            : vm-mce-hana01
      * azure-events-az_curNodeState      : AVAILABLE 
      * hana_XXX_clone_state              : PROMOTED  
      * hana_XXX_op_mode                  : logreplay 
      * hana_XXX_remoteHost               : vm-mce-hana02
      * hana_XXX_roles                    : 4:P:master1:master:worker:master
      * hana_XXX_site                     : Site1     
      * hana_XXX_srah                     : -         
      * hana_XXX_srmode                   : sync      
      * hana_XXX_sync_state               : PRIM      
      * hana_XXX_version                  : 2.00.083.00
      * hana_XXX_vhost                    : vm-mce-hana01
      * lpa_XXX_lpt                       : 1767866244
      * master-SAPHana_HN1_00             : 150       
    * Node: vm-mce-hana02 (2):
      * azName                            : vm-mce-hana02
      * hana_XXX_clone_state              : UNDEFINED 
      * hana_XXX_op_mode                  : logreplay 
      * hana_XXX_remoteHost               : vm-mce-hana01
      * hana_XXX_roles                    : 4:N:master1:master:worker:master
      * hana_XXX_site                     : Site2     
      * hana_XXX_srah                     : -         
      * hana_XXX_srmode                   : sync      
      * hana_XXX_sync_state               : SOK       
      * hana_XXX_version                  : 2.00.083.00
      * hana_XXX_vhost                    : vm-mce-hana02
      * lpa_XXX_lpt                       : 30

此迁移摘要指示SAP HANA资源（SAPHana_XXX_00）无法在两个节点上启动（vm-mce-hana01 和 vm-mce-hana02）。失败计数被设置为 1000000（即无穷大）。

  sudo pcs status

  Migration Summary:
    * Node: vm-mce-hana01 (1):
      * SAPHana_HN1_00: migration-threshold=5000 fail-count=1 last-failure='Thu Jan  8 07:56:30 2026'
    * Node: vm-mce-hana02 (2):
      * SAPHana_HN1_00: migration-threshold=5000 fail-count=1000000 last-failure='Thu Jan  8 07:48:34 2026'

  Failed Resource Actions:
    * SAPHana_HN1_00_monitor_59000 on vm-mce-hana01 'promoted (failed)' (9): call=41, status='complete', last-rc-change='Thu Jan  8 07:56:30 2026', queued=0ms, exec=0ms
    * SAPHana_HN1_00_start_0 on vm-mce-hana02 'not running' (7): call=38, status='complete', last-rc-change='Thu Jan  8 07:48:34 2026', queued=0ms, exec=745ms

方案 3 的原因，症状 2

如果数据库已修改（手动停止或启动、复制暂停等），群集处于维护模式，则经常会出现此问题。

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

备注

步骤 1 到 5 应由 SAP 管理员执行。

在进行任何更改之前，请确保具有备份或快照。有关详细信息，请参阅 Azure VM 备份。

将群集置于维护模式：

sudo pcs property set maintenance-mode=true

在主节点上手动启动群集外部的数据库：
```
sudo HDB start
```
在主节点上启动复制。根据需要替换 <site id> 。
```
sudo hdbnsutil -sr_enable --name=<site id>
```

在从节点上初始化复制。替换 <primary node>、<Instance id> 和 <side id>。

sudo hdbnsutil -sr_register --remoteHost=<primary node> --remoteInstance=<Instance id> --replicationMode=sync --name=<site id>

在辅助节点上手动启动群集外部的数据库：
```
sudo HDB start
```
验证复制是否按预期运行。为此，请在两个节点上运行以下命令：
```
sudo hdbnsutil -sr_state
```

从维护模式中删除群集。

sudo pcs property set maintenance-mode=false

清空SAP HANA资源的失败计数。将 <SAPHana resource name> 替换为 SAP Pacemaker 群集设置。
```
sudo pcs resource cleanup <SAPHana resource name>
```

有关此方案的详细信息，请参阅以下 Red Hat 文章：SAPHana 资源在 hana_xxx_roles Reporting N (Standalone) 时出现启动失败。

方案 3，症状 3：SAP HANA资源由于 hdbdaemon 问题而无法启动

SAP HANA资源启动失败，并显示错误消息，如下所示：

'FAIL: process hdbdaemon HDB Daemon not running'

sudo pcs status --full 命令还可用于查看此错误，因为它导致SAP HANA Pacemaker 群集资源故障转移错误。

Failed Resource Actions:
  * SAPHana_XXX_00_monitor_0 on vm-mce-hana01 'error' (1): call=25, status='complete', last-rc-change='Thu Jan  2 08:01:54 2026', queued=0ms, exec=1604ms

方案 3 的原因，症状 3

对 /var/log/messages 日志的审查表明 hbddaemon 因以下错误而未启动：

Jan  2 08:01:54 vm-mce-hana01 SAPHana(SAPHana_HXXX_00)[5296]: ERROR: ACT: SAP HANA: Instance HN1-HDB00 start failed: #01202.01.2026 08:01:54#012WaitforStarted#012FAIL: process hdbdaemon HDB Daemon not running
Jan  2 08:01:55 vm-mce-hana01 SAPHana(SAPHana_XXX_00)[5314]: INFO: RA ==== end action start_clone with rc=1 (0.162.3) (22s)====
Jan  2 08:01:55 vm-mce-hana01 SAPHana(SAPHana_XXX_00)[5320]: error output [ tput: No value for $TERM and no -T specified ]
Jan  2 08:01:55 vm-mce-hana01 SAPHana(SAPHana_XXX_00)[5324]: error output [ tput: No value for $TERM and no -T specified ]
Jan  2 08:01:55 vm-mce-hana01 SAPHana(SAPHana_XXX_00)[5328]: error output [ tput: No value for $TERM and no -T specified ]
Jan  2 08:01:55 vm-mce-hana01 pacemaker-attrd[2161]: error output [ Error performing operation: No such device or address ]
Jan  2 08:01:55 vm-mce-hana01 SAPHana(SAPHana_XXX_00)[5339]: INFO: RA ==== end action start_clone with rc=1 (0.162.3) (22s)====
Jan  2 08:01:55 vm-mce-hana01 pacemaker-controld[2163]: notice: Result of start operation for SAPHana_XXX_00 on vm-mce-hana01: error
Jan  2 08:01:55 vm-mce-hana01 pacemaker-controld[2163]: notice: vm-mce-hana01-SAPHana_XXX_00_start_0:33 [ tput: No value for $TERM and no -T specified\ntput: No value for $TERM and no -T specified\ntput: No value for $TERM and no -T specified\nError performing operation: No such device or address\n ]
Jan  2 08:01:55 vm-mce-hana01 pacemaker-attrd[2161]: notice: Setting last-failure-SAPHana_XXX_00#start_0[vm-mce-hana01] in instance_attributes: (unset) -> 1767340915
Jan  2 08:01:55 vm-mce-hana01 pacemaker-attrd[2161]: notice: Setting fail-count-SAPHana_XXX_00#start_0[vm-mce-hana01] in instance_attributes: (unset) -> INFINITY

方案 3 的解决方案，症状 3

请参阅以下 Red Hat 文章：SAPHana 资源启动失败并出现错误“FAIL：进程 hdbdaemon HDB 守护程序未运行”。

方案 4：影响 ASCS 和 ERS 资源的问题

方案 4 的症状

ASCS 和 ERS 实例无法在群集控制下启动。日志 /var/log/messages 指示以下错误：

Jan  7 23:29:16 vm-mce-hana01 SAPHN1_01[340480]: Unable to change to Directory /usr/sap/RH2/ERS01/work. (Error 2 No such file or directory) [ntservsserver.cpp 3845]
Jan  7 23:29:16 vm-mce-hana01 SAPHN1_00[340486]: Unable to change to Directory /usr/sap/Rh2/ASCS01/work. (Error 2 No such file or directory) [ntservsserver.cpp 3845]

方案 4 的原因

由于错误 InstanceName 和 START_PROFILE 属性，SAP 实例（如 ASCS 和 ERS）未在群集控制下启动。

方案 4 的解决方法

备注

只有在InstanceName和START_PROFILE为单独文件时，此分辨率才适用。

在进行任何更改之前，请确保具有备份或快照。有关详细信息，请参阅 Azure VM 备份。

将群集置于维护模式：

sudo pcs property set maintenance-mode=true

从pf(profile)文件验证/usr/sap/sapservices路径。

sudo cat /usr/sap/sapservices

LD_LIBRARY_PATH=/usr/sap/HN1/ASCS01/exe:$LD_LIBRARY_PATH;export LD_LIBRARY_PATH;/usr/sap/RH2/ASCS00/exe/sapstartsrv pf=/usr/sap/HN1/SYS/profile/START_ASCS01_nodeci -D -u rh2adm
LD_LIBRARY_PATH=/usr/sap/HN1/ERS01/exe:$LD_LIBRARY_PATH;export LD_LIBRARY_PATH;/usr/sap/RH2/ERS10/exe/sapstartsrv pf=/usr/sap/HN1/ERS01/profile/START_ERS01_nodersvi -D -u rh2adm

更正InstanceName和START_PROFILE属性值中的群集配置资源代理SAPInstance。

示例：
```
sudo pcs resource update ASCS_RH2_ASCS01 InstanceName=HN1_ASCS01_nodeci START_PROFILE=/usr/sap/HN1/SYS/profile/START_ASCS01_nodeci
```
将 HN1_ASCS01_nodeci 和 /usr/sap/HN1/SYS/profile/START_ASCS01_nodeci 替换为相应的值。
```
sudo pcs resource update ERS_HN1_ERS01 InstanceName=HN1_ERS01_nodersvi START_PROFILE=/usr/sap/HN1/ERS01/profile/START_ERS01_nodersvi
```
将 HN1_ERS01_nodersvi 和 /usr/sap/HN1/ERS01/profile/START_ERS01_nodersvi 替换为相应的值。

从维护模式中删除群集：

sudo pcs property set maintenance-mode=false

方案 5：隔离节点不重新加入群集

方案 5 的症状

隔离作完成后，受影响的节点通常不会重新加入 Pacemaker 群集，并且 Pacemaker 和 Corosync 服务都会停止，除非手动启动群集以联机还原群集。

方案 5 的原因

在节点被隔离保护并重启其群集服务后，它随后会收到一条消息，指出 We were allegedly just fenced。这会导致它关闭 Pacemaker 和 Corosync 服务，并阻止群集启动。 vm-mce-hana01 针对 vm-mce-hana02 启动 STONITH 操作。在 03:27:23解决网络问题时，vm-mce-hana02 重新加入 Corosync 集群。因此，一个新的双节点成员关系已经建立，如/var/log/messages``vm-mce-hana01所示。

Feb 20 03:26:56 vm-mce-hana01 corosync[1722]:  [TOTEM ] A processor failed, forming new configuration.
Feb 20 03:27:23 vm-mce-hana01 corosync[1722]:  [TOTEM ] A new membership (1.116f4) was formed. Members left: 2
Feb 20 03:27:24 vm-mce-hana01 corosync[1722]:  [QUORUM] Members[1]: 1
...
Feb 20 03:27:24 vm-mce-hana01 pacemaker-schedulerd[1739]: warning: Cluster node vm-mce-hana02 will be fenced: peer is no longer part of the cluster
...
Feb 20 03:27:24 vm-mce-hana01 pacemaker-fenced[1736]: notice: Delaying 'reboot' action targeting vm-mce-hana02 using  for 20s
Feb 20 03:27:25 vm-mce-hana01 corosync[1722]:  [TOTEM ] A new membership (1.116f8) was formed. Members joined: 2
Feb 20 03:27:25 vm-mce-hana01 corosync[1722]:  [QUORUM] Members[2]: 1 2
Feb 20 03:27:25 vm-mce-hana01 corosync[1722]:  [MAIN  ] Completed service synchronization, ready to provide service.

vm-mce-hana01 收到 vm-mce-hana02 已成功重启的确认，如 vm-mce-hana02 所示 /var/log/messages 。

Feb 20 03:27:46 vm-mce-hana01 pacemaker-fenced[1736]: notice: Operation 'reboot' [43895] (call 28 from pacemaker-controld.1740) targeting vm-mce-hana02 using xvm2 returned 0 (OK)

若要完全执行 STONITH 动作，系统必须向每个节点传递确认消息。由于 vm-mce-hana02 在 03:27:25 重新加入该组，并且因为令牌和共识超时尚未到期，因此尚未形成排除 vm-mce-hana02 的新成员资格，确认消息会延迟，直到 vm-mce-hana02 启动后重新启动其集群服务。收到消息后，vm-mce-hana02 识别出它已被隔离保护，因此关闭了其服务，如下所示：

/var/log/messages 在 vm-mce-hana01 中：

Feb 20 03:29:02 vm-mce-hana01 corosync[1722]:  [TOTEM ] A processor failed, forming new configuration.
Feb 20 03:29:10 vm-mce-hana01 corosync[1722]:  [TOTEM ] A new membership (1.116fc) was formed. Members joined: 2 left: 2
Feb 20 03:29:10 vm-mce-hana01 corosync[1722]:  [QUORUM] Members[2]: 1 2
Feb 20 03:29:10 vm-mce-hana01 pacemaker-fenced[1736]: notice: Operation 'reboot' targeting vm-mce-hana02 by vm-mce-hana01 for pacemaker-controld.1740@vm-mce-hana01: OK
Feb 20 03:29:10 vm-mce-hana01 pacemaker-controld[1740]: notice: Peer vm-mce-hana02 was terminated (reboot) by vm-mce-hana01 on behalf of pacemaker-controld.1740: OK
...
Feb 20 03:29:11 vm-mce-hana01 corosync[1722]:  [CFG   ] Node 2 was shut down by sysadmin
Feb 20 03:29:11 vm-mce-hana01 corosync[1722]:  [TOTEM ] A new membership (1.11700) was formed. Members left: 2
Feb 20 03:29:11 vm-mce-hana01 corosync[1722]:  [QUORUM] Members[1]: 1
Feb 20 03:29:11 vm-mce-hana01 corosync[1722]:  [MAIN  ] Completed service synchronization, ready to provide service.

/var/log/messages 在 vm-mce-hana02 中：

Feb 20 03:29:11 [1155] vm-mce-hana02 corosync notice  [TOTEM ] A new membership (1.116fc) was formed. Members joined: 1
Feb 20 03:29:11 [1155] vm-mce-hana02 corosync notice  [QUORUM] Members[2]: 1 2
Feb 20 03:29:09 vm-mce-hana02 pacemaker-controld  [1323] (tengine_stonith_notify)  crit: We were allegedly just fenced by vm-mce-hana01 for vm-mce-hana01!

方案 5 的解决方法

为 Crosync 服务配置启动延迟。此暂停为新的已关闭进程组（CPG）提供了足够的时间来形成新成员资格，并排除已隔离的节点，从而确保 STONITH 重启过程能够完成，因为这确保了完成消息传达给所有成员资格中的节点。

若要实现此效果，请运行以下命令：

将群集置于维护模式：

sudo pcs property set maintenance-mode=true

在群集中的所有节点上创建一个 systemd 配置覆盖文件：

编辑 Corosync 文件：
```
sudo systemctl edit corosync.service
```
添加以下行：
```
[Service]
ExecStartPre=/bin/sleep 60
```
保存文件并退出文本编辑器后，重新加载 systemd Manager 配置：
```
sudo systemctl daemon-reload
```

从维护模式中删除群集：

sudo pcs property set maintenance-mode=false

有关更多信息，请参见隔离节点在无人工干预下无法重新加入集群。

排查 Azure 中的 RHEL Pacemaker 群集服务和资源启动问题 - Virtual Machines

总结

场景 1：群集服务无法启动，原因是仲裁问题

方案 1 的症状

方案 1 的原因

方案 1 的解决方法

情景 2：群集 VIP 资源中的问题

方案 2 的症状

方案 2 的原因

方案 2 的解决方法

方案 3：SAP HANA中的问题（高性能分析设备）

方案 3，症状 1：SAP HANA DB 未启动并生成未知错误

方案 3 的原因，症状 1

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

方案 3，症状 2：SAP HANA由于复制失败而无法启动

方案 3 的原因，症状 2

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

方案 3，症状 3：SAP HANA资源由于 hdbdaemon 问题而无法启动

方案 3 的原因，症状 3

方案 3 的解决方案，症状 3

方案 4：影响 ASCS 和 ERS 资源的问题

方案 4 的症状

方案 4 的原因

方案 4 的解决方法

方案 5：隔离节点不重新加入群集

方案 5 的症状

方案 5 的原因

方案 5 的解决方法

资料来源与适用范围