通过

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

适用于：✔️ Linux VM

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

方案 1：由于仲裁，无法启动群集服务

方案 1 的症状

  • 群集节点在群集重启后不会加入群集。

  • 节点报告为 UNCLEAN (offline)。

  • 当前 DC 报告为 NONE.

    sudo pcs status

    Cluster name: my_cluster
Status of pacemakerd: 'Pacemaker is running' (last updated 2024-06-25 16:34:49 -04:00)
Cluster Summary:
* Stack: corosync
* **Current DC: NONE**
* Last updated: Tue Jun 25 14:34:49 2024
* Last change:  Tue Jun 25 14:29:51 2024 by root via cibadmin on node-0
* 2 nodes configured
* 9 resource instances configured

Node List:
* **Node node-0: UNCLEAN (offline)**
* **Node node-1: 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
Check for the error: Corosync quorum is not configured in /var/log/messeges:
Jun 16 11:17:53 node-0 pacemaker-controld[509433]: error: Corosync quorum is not configured

方案 1 的原因

VoteQuorum 服务是 corosync 项目的一个组件。 为了防止拆分脑方案，可以选择将此服务加载到共同同步群集的节点中。 群集中的每个系统都会获得一定数量的投票来实现此仲裁。 这可确保仅当大多数投票被强制转换时，才能执行群集作。 每个节点或任何节点都必须加载服务。 如果服务加载到群集节点的子集，结果不确定。

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

quorum {
    provider: corosync_votequorum
}

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

方案 1 的解决方法

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

  2. 检查中 /etc/corosync/corosync.conf是否存在缺失的仲裁部分。 将现有 corosync.conf 备份与可用的 /etc/corosync/任何备份进行比较。

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

    sudo pcs property set maintenance-mode=true

  4. 更新更改。/etc/corosync/corosync.conf

    双节点群集的示例：

    sudo cat /etc/corosync/corosync.conf

    totem {
version: 2
cluster_name: my_cluster
transport: knet
token: 30000
crypto_cipher: aes256
crypto_hash: sha256
cluster_uuid: afd62fe2045b43b9a102de76fdf4659a
}
nodelist {
node {
    ring0_addr: node-0
    name: node-0
    nodeid: 1
}

node {
    ring0_addr: node-1
    name: node-1
    nodeid: 2
}
}

**quorum {
provider: corosync_votequorum
two_node: 1
}**

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

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

    sudo pcs property set maintenance-mode=false

  6. 同步群集：

    sudo pcs cluster sync

  7. 重新加载 corosync：

    sudo pcs cluster reload corosync

方案 2：群集 VIP 资源中的问题

方案 2 的症状

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

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

25167 IPaddr2(VIP)[16985]:    2024/09/07_15:44:19 ERROR: Unable to find nic or netmask.
25168 IPaddr2(VIP)[16985]:    2024/09/07_15:44:19 ERROR: [findif] failed

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

sudo pcs status

vip_HN1_03_start_0 on node-1 'unknown error' (1): call=30, status=complete, exit-reason='[findif] failed', last-rc-change='Thu Jan 07 17:25:52 2025', queued=0ms, exec=57ms

方案 2 的原因

  1. 若要选择要启动资源的IPAddr2IPaddr2网络适配器（NIC），请调用findif()包中包含的/usr/lib/ocf/resource.d/heartbeat/IPaddr2resource-agents函数。

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

    例如：

    IPaddr2检查设置：

    sudo pcs resource show vip_HN1_03

    Resource: vip_HN1_03 (class=ocf provider=heartbeat type=IPaddr2)
Attributes: ip=172.17.10.10 cidr_netmask=24 nic=ens6
Operations: start interval=0s timeout=20s (vip_HN1_03-start-timeout-20s)
            stop interval=0s timeout=20s (vip_HN1_03-stop-timeout-20s)
            monitor interval=10s timeout=20s (vip_HN1_03-monitor-interval-10s)

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

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

    172.17.10.0/24 dev ens6 proto kernel src 172.17.10.7

  4. 在关闭 NIC (ens6) 的情况下，无法手动查找 NIC 信息，这可能会导致 [findif] 失败。 替换 172.17.10.10/24 并 ens6 根据需要。

    sudo ip link set ens6 down

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

方案 2 的解决方法

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

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

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

    sudo pcs property set maintenance-mode=true

  3. NIC更新资源：

    sudo pcs resource update vip_HN1_03 nic=ens6

  4. NIC 重启资源：

    sudo pcs resource restart vip_HN1_03

    vip_HN1_03 successfully restarted

  5. 从以下中删除 maintenance-mode群集：

    sudo pcs property set maintenance-mode=false

  6. IP验证资源：

    sudo pcs resource show vip_HN1_03

    Warning: This command is deprecated and will be removed. Please use 'pcs resource config' instead.
Resource: vip_HN1_03 (class=ocf provider=heartbeat type=IPaddr2)
  Attributes: cidr_netmask=32 ip=172.17.223.36 nic=vlan10
  Meta Attrs: resource-stickiness=INFINITY
  Operations: monitor interval=10s timeout=20s (vip_HN1_03-monitor-interval-10s)
              start interval=0s timeout=20s (vip_HN1_03-start-interval-0s)
              stop interval=0s timeout=20s (vip_HN1_03-stop-interval-0s)

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

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

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

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

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

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

    sudo pcs status --full

    * Node node-0 (1):
    + hana_XXX_clone_state              : PROMOTED  
    + hana_XXX_sync_state               : PRIM      
    + hana_XXX_roles                    : 2:P:master1:master:worker:slave

* Node node-1 (2):
    + hana_XXX_clone_state              : WAITING4PRIM  
    + hana_XX_sync_state                : SFAIL      
    + hana_XXX_roles                    : 2:S:master1:master:worker:slave

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

    sudo pcs status

    2 nodes configured
8 resources configured

Online: [ node-0 node-1 ]

Full list of resources:

  rsc_st_azure	(stonith:fence_azure_arm):	Started node-1
  Clone Set: cln_SAPHanaTopology [rsc_SAPHanaTopology]
      Started: [ node-0 node-1 ]
  Master/Slave Set: msl_SAPHana [rsc_SAPHana]
      Master: [ node-1 ]
      Slave:  [ node-0 ]
  Resource Group: g_ip_HN1_HBD00
      vip_HN1_HBD00	(ocf::heartbeat:IPaddr2):	Started node-0 
      nc_HN1_HBD00	(ocf::heartbeat:azure-lb):	Started node-0 


Failed Resource Actions:
* rsc_SAPHana_monitor_61000 on node-0 'unknown error' (1): call=32, status=complete, exitreason='',
    last-rc-change='Sat May 22 09:29:20 2021', queued=0ms, exec=0ms
* rsc_SAPHana_start_0 on node-1 'not running' (7): call=55, status=complete, exitreason='',
    last-rc-change='Sat May 22 09:36:32 2021', queued=0ms, exec=3093ms

方案 3 的原因，症状 1

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

sudo SAPHanaSR-showAttr

Global cib-time                 maintenance
--------------------------------------------
global Fri Aug 23 11:47:32 2024 false

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

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

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

重要

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

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

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

    sudo pcs property set maintenance-mode=true

  3. 检查 SAP HANA DB 并处理状态：

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

    b. 在每个节点上运行 HDB info ，检查节点上运行的与 SAP 相关的进程。 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_node-0
a00adm     5377   5369  1.8 582944 292720  \_ /usr/sap/A00/HDB00/node-0/trace/hdb.sapA00_HDB00 -d -nw -f /usr/sap/A00/HDB00/node-0/daemon.ini pf=/usr/sap/A00/SYS/profile/A00_HDB00_node-0
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_node-0 -D -u a00adm
a00adm     2004      1  0.0  31844  2352 /usr/lib/systemd/systemd --user
a00adm     2008   2004  0.0  63796  2620  \_ (sd-pam)

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

    sudo HDB stop

    或：

    sudo sapcontrol -nr <SAPInstanceNo> -function stop

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

    sudo HDB start

    或：

    sudo sapcontrol -nr <SAPInstanceNo> -function start

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

    备注

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

  5. 启用复制后，请使用 SAP 系统管理员帐户检查系统复制状态。 在这种情况下，用户管理员帐户为 hn1adm。

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

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

    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-0 | 30007 | xsengine     |         2 |       1 | node-0    | sapn2     |     30007 |         2 | node-1     | YES          | SYNC        | ACTIVE      |                |
| node-0 | 30001 | nameserver   |         1 |       1 | node-0    | sapn2     |     30001 |         2 | node-1     | YES          | SYNC        | ACTIVE      |                |
| node-0 | 30003 | indexserver  |         3 |       1 | node-0    | sapn2     |     30003 |         2 | node-1     | 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-0

  6. 运行以下命令再次验证 SAP HANA 系统复制状态：

    sudo SAPHanaSR-showAttr

    Global cib-time                 maintenance
--------------------------------------------
global Mon Oct 14 10:25:51 2024 false

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

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

    sudo pcs property set maintenance-mode=false

  8. 确保 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: node-0 (1):
    * hana_XXX_clone_state            : UNDEFINED
    * hana_XXX_op_mode			          : logreplay
    * hana_XXX_remoteHost             : node-1
    * hana_XXX_roles                  : 1:N:master1::worker:
    * hana_XXX_site                   : SITE1    
    * hana_XXX_srah                   : -        
    * hana_XXX_srmode                 : sync     
    * hana_XXX_version                : 2.00.079.00
    * hana_XXX_vhost                  : node-0
    * lpa_XXX_lpt                     : 10       
  * Node: node-1 (2):
    * hana_XXX_clone_state            : UNDEFINED
    * hana_XXX_op_mode                : logreplay
    * hana_XXX_remoteHost             : node-0
    * hana_XXX_roles                  : 4:N:master1:master:worker:master
    * hana_XXX_site                   : SITE2
    * hana_XXX_sra                    : -        
    * hana_XXX_srah                   : -        
    * hana_XXX_srmode                 : sync     
    * hana_XXX_sync_state		          : PRIM     
    * hana_XXX_version			          : 2.00.079.00
    * hana_XXX_vhost				          : node-1
    * lpa_XXX_lpt				              : 1733552029
    * master-SAPHana_XXX_00		        : 150

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

sudo pcs status

Migration Summary:
  * Node: node-0 (1):
    * SAPHana_XXX_00: migration-threshold=1000000 fail-count=1000000 last-failure='Sat Dec  7 15:17:16 2024'
  * Node: node-1 (2):
    * SAPHana_XXX_00: migration-threshold=1000000 fail-count=1000000 last-failure='Sat Dec  7 15:48:57 2024'

Failed Resource Actions:
  * SAPHana_XXX_00_start_0 on node-1 'not running' (7): call=74, status='complete', last-rc-change='Sat Dec  7 15:17:14 2024', queued=0ms, exec=1715ms
  * SAPHana_XXX_00_start_0 on node-0 'not running' (7): call=30, status='complete', last-rc-change='Sat Dec  7 15:49:12 2024', queued=0ms, exec=1680ms

方案 3 的原因，症状 2

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

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

备注

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

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

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

    sudo pcs property set maintenance-mode=true

  3. 在主节点上手动启动群集外部的数据库：

    sudo HDB start

  4. 在主节点上启动复制。 根据需要替换 <site id> 。

    sudo hdbnsutil -sr_enable --name=<site id>

  5. 初始化辅助节点上的复制。 替换 <primary node>， <Instance ##> 并 <side id> 适当地替换。

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

  6. 在辅助节点上手动启动群集外部的数据库：

    sudo HDB start

  7. 验证复制是否按预期运行。 为此，请在两个节点上运行以下命令：

    sudo hdbnsutil -sr_state

  8. 从维护模式中删除群集。

    sudo pcs property set maintenance-mode=false

  9. 清除 SAP HANA 资源的失败计数。 替换为 <SAPHana resource name> SAP Pacemaker 群集设置。

    sudo pcs resource cleanup <SAPHana resource name>

有关此方案的详细信息，请参阅以下 Red Hat 文章： HANA_XXX_ROLES报告 N （独立）时遇到启动失败的 SAPHana 资源。

方案 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_start_0 on node-0 'error' (1): call=44, status='complete', exitreason='', last-rc-change='2024-07-07 06:15:45 -08:00', queued=0ms, exec=51659ms

方案 3 的原因，症状 3

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

Jun  7 02:25:09 node-0 SAPHana(SAPHana_XXX_00)[12336]: ERROR: ACT: SAPHana Instance ECR-HDB00 start failed: #01201.03.2024 02:25:09#012WaitforStarted#012FAIL: process hdbdaemon HDB Daemon not running
Jun  7 02:25:09 node-0 SAPHana(SAPHana_XXX_00)[12336]: INFO: RA ==== end action start_clone with rc=1 (0.154.0) (25s)====
Jun  7 02:25:09 node-0 pacemaker-execd[8567]: notice: SAPHana_XXX_00_start_0[12336] error output [ tput: No value for $TERM and no -T specified ]
Jun  7 02:25:09 node-0 pacemaker-execd[8567]: notice: SAPHana_XXX_00_start_0[12336] error output [ tput: No value for $TERM and no -T specified ]
Jun  7 02:25:09 node-0 pacemaker-execd[8567]: notice: SAPHana_XXX_00_start_0[12336] error output [ tput: No value for $TERM and no -T specified ]
Jun  7 02:25:09 node-0 pacemaker-execd[8567]: notice: SAPHana_XXX_00_start_0[12336] error output [ Error performing operation: No such device or address ]
Jun  7 02:25:09 node-0 pacemaker-controld[8570]: notice: Result of start operation for SAPHana_XXX_00 on node-0: error
Jun  7 02:25:09 node-0 pacemaker-controld[8570]: notice: node-0-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 ]
Jun  7 02:25:09 node-0 pacemaker-attrd[8568]: notice: Setting fail-count-SAPHana_XXX_00#start_0[node-0]: (unset) -> INFINITY
Jun  7 02:25:09 node-0 pacemaker-attrd[8568]: notice: Setting last-failure-SAPHana_XXX_00#start_0[node-0]: (unset) -> 1709288709

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

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

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

方案 4 的症状

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

Jun  9 23:29:16 nodeci SAPRh2_10[340480]: Unable to change to Directory /usr/sap/RH2/ERS10/work. (Error 2 No such file or directory) [ntservsserver.cpp 3845]
Jun  9 23:29:16 nodeci SAPRH2_00[340486]: Unable to change to Directory /usr/sap/Rh2/ASCS00/work. (Error 2 No such file or directory) [ntservsserver.cpp 3845]

方案 4 的原因

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

方案 4 的解决方法

备注

如果和START_PROFILE单独文件，则此分辨率适用InstanceName。

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

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

    sudo pcs property set maintenance-mode=true

  3. pf(profile)验证文件的路径/usr/sap/sapservices：

    sudo cat /usr/sap/sapservices

    LD_LIBRARY_PATH=/usr/sap/RH2/ASCS00/exe:$LD_LIBRARY_PATH;export LD_LIBRARY_PATH;/usr/sap/RH2/ASCS00/exe/sapstartsrv pf=/usr/sap/RH2/SYS/profile/START_ASCS00_nodeci -D -u rh2adm
LD_LIBRARY_PATH=/usr/sap/RH2/ERS10/exe:$LD_LIBRARY_PATH;export LD_LIBRARY_PATH;/usr/sap/RH2/ERS10/exe/sapstartsrv pf=/usr/sap/RH2/ERS10/profile/START_ERS10_nodersvi -D -u rh2adm

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

    示例：

    sudo pcs resource update ASCS_RH2_ASCS00 InstanceName=RH2_ASCS00_nodeci START_PROFILE=/usr/sap/RH2/SYS/profile/START_ASCS00_nodeci

    将 RH2_ASCS00_nodeci 和 /usr/sap/RH2/SYS/profile/START_ASCS00_nodeci 替换为相应的值。

    sudo pcs resource update ERS_RH2_ERS10 InstanceName=RH2_ERS10_nodersvi START_PROFILE=/usr/sap/RH2/ERS10/profile/START_ERS10_nodersvi

    将 RH2_ERS10_nodersvi 和 /usr/sap/RH2/ERS10/profile/START_ERS10_nodersvi 替换为相应的值。

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

    sudo pcs property set maintenance-mode=false

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

方案 5 的症状

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

方案 5 的原因

在节点隔离并重启并重新启动其群集服务后，它随后会收到一条消息，指出 We were allegedly just fenced。 这会导致它关闭 Pacemaker 和 Corosync 服务，并阻止群集启动。 Node1 针对 node2 启动 STONITH作。 当 03:27:23网络问题得到解决时，node2 会重新加入 Corosync 成员身份。 因此，将建立一个新的双节点成员身份，如 node1 所示 /var/log/messages ：

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

Node1 收到节点 2 已成功重启的确认，如 node2 所示 /var/log/messages 。

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

若要完全完成 STONITH作，系统必须向每个节点传递确认消息。 由于 node2 重新加入组， 03:27:25 并且由于令牌和共识超时未过期而尚未形成排除的 node2 的新成员身份，因此在启动后 node2 重启其群集服务之前，确认消息将延迟。 收到消息后，node2 会识别它已被隔离，因此，关闭其服务，如下所示：

/var/log/messages 在 node1 中：

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

/var/log/messages 在 node2 中：

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

方案 5 的解决方法

为 Crosync 服务配置启动延迟。 此暂停为新的已关闭进程组（CPG）成员身份提供足够的时间来形成和排除隔离节点，以便 STONITH 重启过程可以通过确保完成消息到达成员身份中的所有节点来完成。

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

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

    sudo pcs property set maintenance-mode=true

  2. 在群集中的所有节点上创建系统放置文件：

  • 编辑 Corosync 文件：
    sudo systemctl edit corosync.service
  • 添加以下行：
    [Service]
ExecStartPre=/bin/sleep 60
  • 保存文件并退出文本编辑器后，重新加载 systemd Manager 配置：
    sudo systemctl daemon-reload
  1. 从维护模式中删除群集：
sudo pcs property set maintenance-mode=false

有关详细信息， 请参阅隔离节点无法在不手动干预的情况下重新加入群集

后续步骤

有关其他帮助，请使用以下说明打开支持请求。 提交请求时，请附加 群集中所有节点的 SOS 报告 以进行故障排除。

联系我们寻求帮助

如果你有任何疑问或需要帮助，请创建支持请求或联系 Azure 社区支持。 还可以向 Azure 反馈社区提交产品反馈。

第三方信息免责声明

本文中提到的第三方产品由 Microsoft 以外的其他公司提供。 Microsoft 不对这些产品的性能或可靠性提供任何明示或暗示性担保。