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

排查 SUSE Pacemaker 群集中的 SBD 服务故障 - Virtual Machines

· 52CE 我爱测

适用于：✔️ Linux VM 总结 本文概述了 STONITH 块设备（SBD）服务未在 SUSE Enterprise Linux Pacemaker 群集中启动的常见方案。 本文还提供了有关识别和解决此问题的指导。 SBD 的工作原理 SBD 设备需要至少一台虚拟机（VM），该虚拟机充当 Internet 小型计算机系统接口（iSCSI）目标服务器并提供 SBD 设备。 这些 iSCSI 目标服务器也可以与其他 Pacemaker 群集共享。 使用

适用于：✔️ Linux VM

总结

本文概述了 STONITH 块设备（SBD）服务未在 SUSE Enterprise Linux Pacemaker 群集中启动的常见方案。 本文还提供了有关识别和解决此问题的指导。

SBD 的工作原理

SBD 设备需要至少一台虚拟机（VM），该虚拟机充当 Internet 小型计算机系统接口（iSCSI）目标服务器并提供 SBD 设备。 这些 iSCSI 目标服务器也可以与其他 Pacemaker 群集共享。 使用 SBD 的优势在于，如果已在本地使用 SBD 设备，则 SBD 设备无需更改 Pacemaker 群集的运行方式。

对于具有 SBD 存储保护的 Microsoft Azure Pacemaker 群集，可以使用以下任一选项进行设置。 有关这些机制的详细信息，请参阅：

如何诊断问题

以下示例演示如何确定群集启动问题是由 SBD 服务故障引起的。

  1. 检查群集的状态：

    sudo crm status

    ERROR: status: crm_mon (rc=102): Error: cluster is not available on this node

  2. 检查 Pacemaker 服务是否启动。 以下示例输出指示 Pacemaker 服务失败，因为一个或多个依赖服务未正常工作：

    sudo systemctl status pacemaker

    pacemaker.service - Pacemaker High Availability Cluster Manager
   Loaded: loaded (/usr/lib/systemd/system/pacemaker.service; enabled; vendor preset: disabled)
   Active: inactive (dead) since Thu 2024-08-01 04:56:39 UTC; 2min 39s ago
     Docs: man:pacemakerd
https://clusterlabs.org/pacemaker/doc/en-US/Pacemaker/1.1/html-single/Pacemaker_Explained/index.html

Aug 01 04:59:07 nfs-0 systemd[1]: Dependency failed for Pacemaker High Availability Cluster Manager.
Aug 01 04:59:07 nfs-0 systemd[1]: pacemaker.service: Job pacemaker.service/start failed with result 'dependency'.

  3. 检查 Pacemaker 服务的依赖服务树：

    sudo  systemctl list-dependencies pacemaker

    pacemaker.service
● ├─corosync.service
● ├─dbus.service
● ├─sbd.service
● ├─system.slice
● ├─resource-agents-deps.target
● └─sysinit.target

  4. 检查每个服务的状态。 在以下示例中，可以看到所有依赖项服务（如 Corosync）都处于活动状态，但 SBD 服务未运行：

    sudo systemctl status corosync

    corosync.service - Corosync Cluster Engine
  Loaded: loaded (/usr/lib/systemd/system/corosync.service; disabled; vendor preset: disabled)
  Active: active (running) since Thu 2024-08-01 04:49:15 UTC; 38s ago
 Process: 23972 ExecStop=/usr/share/corosync/corosync stop (code=exited, status=0/SUCCESS)
 Process: 24075 ExecStart=/usr/share/corosync/corosync start (code=exited, status=0/SUCCESS)
Main PID: 24094 (corosync)
   Tasks: 2 (limit: 4096)
  CGroup: /system.slice/corosync.service
          └─24094 corosync

Aug 01 04:49:15 nfs-0 corosync[24094]:   [TOTEM ] A new membership (10.0.0.6:32) was formed. Members joined: 2
Aug 01 04:49:15 nfs-0 corosync[24094]:   [CPG  ] downlist left_list: 0 received in state 2
Aug 01 04:49:15 nfs-0 corosync[24094]:   [VOTEQ ] Waiting for all cluster members. Current votes: 1 expected_votes: 2
Aug 01 04:49:15 nfs-0 corosync[24094]:   [QUORUM] This node is within the primary component and will provide service.
Aug 01 04:49:15 nfs-0 corosync[24094]:   [QUORUM] Members[2]: 1 2
Aug 01 04:49:15 nfs-0 corosync[24094]:   [MAIN ] Completed service synchronization, ready to provide service.
Aug 01 04:49:15 nfs-0 corosync[24075]: Starting Corosync Cluster Engine (corosync): [ OK ]

  5. 检查 SBD 服务状态。 在此示例中，服务不会启动，并返回 Failed to start Shared-storage based fencing daemon 错误消息：

    sudo systemctl status sbd

    ● sbd.service - Shared-storage based fencing daemon
   Loaded: loaded (/usr/lib/systemd/system/sbd.service; enabled; vendor preset: disabled)
   Active: failed (Result: timeout) since Thu 2024-08-01 04:59:07 UTC; 3min 3s ago
     Docs: man:sbd(8)
  Process: 25251 ExecStart=/usr/sbin/sbd $SBD_OPTS -p //run/sbd.pid watch (code=killed, signal=TERM)

Aug 01 04:57:37 nfs-0 systemd[1]: Starting Shared-storage based fencing daemon...
Aug 01 04:57:37 nfs-0 sbd[25251]:  warning: open_any_device: Failed to open /dev/disk/by-id/scsi-360014056eadbecfeca042d4a66b9d779. Trying any o...ithin 120s
Aug 01 04:59:07 nfs-0 systemd[1]: sbd.service: Start operation timed out. Terminating.
Aug 01 04:59:07 nfs-0 systemd[1]: Failed to start Shared-storage based fencing daemon.
Aug 01 04:59:07 nfs-0 systemd[1]: sbd.service: Unit entered failed state.
Aug 01 04:59:07 nfs-0 systemd[1]: sbd.service: Failed with result 'timeout'.

原因 1：SBD 服务因 iSCSI 故障而失败

Pacemaker 服务未运行，SBD 服务在这两个群集节点上处于失败状态。 iSCSI 服务使用 iSCSI 限定名称（IQN）在发起方和目标节点之间进行通信。 如果服务未运行，SBD 磁盘可能会变得不可访问。 这反过来又会导致 SBD 和 Pacemaker 服务失败。

解决方法

  1. 请确保根据SUSE-在 Azure 的 SUSE Linux Enterprise Server 上配置 Pacemaker 的文档，正确配置设置。

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

    sudo crm configure property maintenance-mode=true

  3. 请确保 iscsid 和 iscsi 服务已启用。

    sudo systemctl enable iscsi

    sudo systemctl enable iscsid

  4. iscsid和iscsi服务是否正在运行，进行验证：

    sudo systemctl status iscsi

    sudo systemctl status iscsid

如果服务正常工作，输出应如下所示：

```output
iscsi.service - Login and scanning of iSCSI devices
Loaded: loaded (/usr/lib/systemd/system/iscsi.service; enabled; vendor preset: enabled)
Active: active (exited) since Thu 2024-08-01 04:18:51 UTC; 31min ago
Docs: man:iscsiadm(8)
man:iscsid(8)
Main PID: 1823 (code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 4096)
CGroup: /system.slice/iscsi.service

Aug 01 04:18:51 nfs-0 systemd[1]: Starting Login and scanning of iSCSI devices...
Aug 01 04:18:51 nfs-0 iscsiadm[1823]: Logging in to [iface: default, target: iqn.2006-04.nfs.local:nfs, portal: 10.0.0.17,3260]
Aug 01 04:18:51 nfs-0 iscsiadm[1823]: Logging in to [iface: default, target: iqn.2006-04.nfs.local:nfs, portal: 10.0.0.18,3260]
Aug 01 04:18:51 nfs-0 iscsiadm[1823]: Logging in to [iface: default, target: iqn.2006-04.nfs.local:nfs, portal: 10.0.0.19,3260]
Aug 01 04:18:51 nfs-0 systemd[1]: Started Login and scanning of iSCSI devices.
```

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

    sudo crm configure property maintenance-mode=false

原因 2：配置问题

错误的 SBD 配置（例如，缺少或错误命名的 SBD 设备或语法错误）可能会导致 SBD 服务失败。

解决方法 1

验证 SBD 配置文件是否 /etc/sysconfig/sbd包含建议的参数和正确的 SBD 设备：

SBD_PACEMAKER=yes
SBD_STARTMODE=always
SBD_DELAY_START=no
SBD_WATCHDOG_DEV=/dev/watchdog
SBD_WATCHDOG_TIMEOUT=5
SBD_TIMEOUT_ACTION=flush,reboot
SBD_MOVE_TO_ROOT_CGROUP=auto
SBD_OPTS=
SBD_DEVICE="/dev/disk/by-id/scsi-xxxxxxxxxxxxxxxxxx;/dev/disk/by-id/scsi-xxxxxxxxxxxxxxxxx;/dev/disk/by-id/scsi-xxxxxxxxxxxxxxxxxx"

解决方案 2

运行以下命令验证 STONITH 资源配置：

sudo crm configure show

primitive stonith-sbd stonith:external/sbd \
params pcmk_delay_max=30s \
op monitor interval="600" timeout="15"
stonith-enabled=true \
stonith-timeout=144 \

原因 3：iSCSI 设备在群集节点上不可用

运行 lscsi 或 lsblk 命令时，SBD 磁盘不会显示在输出中：

sudo lsscsi

[0:0:0:0]    disk    Msft    Virtual Disk     1.0   /dev/sda
[0:0:0:1]    disk    Msft    Virtual Disk     1.0   /dev/sdb
[1:0:0:0]    disk    Msft    Virtual Disk     1.0   /dev/sdc
[1:0:0:1]    disk    Msft    Virtual Disk     1.0   /dev/sdd

sudo lsblk

NAME                MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                   8:0    0  100G  0 disk
├─sda1                 8:1    0   2M  0 part
├─sda2                 8:2    0 512M  0 part /boot/efi
├─sda3                 8:3    0   1G  0 part /boot
└─sda4                8:4    0 98.5G  0 part /
sdb                   8:16   0   14G  0 disk
└─sdb1                8:17   0   14G  0 part /mnt
sdc                   8:32   0  100G  0 disk
└─sdc1                8:33   0  100G  0 part
 └─vg--NW1--NFS-NW1 254:0    0  100G  0 lvm
sdd                   8:48   0  100G  0 disk
└─sdd1                8:49   0  100G  0 part
 └─vg--NW2--NFS-NW2 254:1    0  100G  0 lvm

解决方法

执行以下检查：

  1. 验证两个群集节点上的发起者名称：

    sudo cat /etc/iscsi/initiatorname.iscsi

    InitiatorName=iqn.2006-04.nfs-0.local:nfs-0

    sudo cat /etc/iscsi/initiatorname.iscsi

    InitiatorName=iqn.2006-04.nfs-1.local:nfs-1

  2. 尝试列出 SBD 配置文件中提及的所有 SBD 设备：

    sudo grep SBD_DEVICE /etc/sysconfig/sbd

    # SBD_DEVICE specifies the devices to use for exchanging sbd messages
SBD_DEVICE="/dev/disk/by-id/scsi-360014056eadbecfeca042d4a66b9d779;/dev/disk/by-id/scsi-36001405cbac988092e448059d25d1a4a;/dev/disk/by-id/scsi-36001405a29a443e4a6e4ceeae822e5eb"

  3. 根据提供的错误消息，检查 SBD 服务器是否正在运行并可访问：

    sudo /usr/sbin/sbd -d /dev/disk/by-id/scsi-360014056eadbecfeca042d4a66b9d779 list

    == disk /dev/disk/by-id/scsi-360014056eadbecfeca042d4a66b9d779 unreadable!
sbd failed; please check the logs.

  4. 若要修复此错误，请在群集的两个节点上运行以下步骤，在确保 SBD 服务器正在运行且可访问后连接到 iSCSI 设备。 在以下示例中，iqn.2006-04.nfs.local:nfs是运行第一个命令时列出的目标名称： iscsiadm -m discovery

    sudo iscsiadm -m discovery

    10.0.0.17:3260 via sendtargets
10.0.0.18:3260 via sendtargets
10.0.0.19:3260 via sendtargets

    sudo iscsiadm -m discovery --type=st --portal=10.0.0.17:3260

    10.0.0.17:3260,1 iqn.2006-04.dbnw1.local:dbnw1
10.0.0.17:3260,1 iqn.2006-04.ascsnw1.local:ascsnw1
10.0.0.17:3260,1 iqn.2006-04.nfs.local:nfs

    sudo iscsiadm -m node -T iqn.2006-04.nfs.local:nfs --login --portal=10.0.0.17:3260

    Logging in to [iface: default, target: iqn.2006-04.nfs.local:nfs, portal: 10.0.0.17,3260]
Login to [iface: default, target: iqn.2006-04.nfs.local:nfs, portal: 10.0.0.17,3260] successful.

    sudo iscsiadm -m node -p 10.0.0.17:3260 -T iqn.2006-04.nfs.local:nfs --op=update --name=node.startup --value=automatic

    sudo  lsscsi

    [0:0:0:0]    disk    Msft     Virtual Disk     1.0   /dev/sda
[0:0:0:1]    disk    Msft     Virtual Disk     1.0   /dev/sdb
[1:0:0:0]    disk    Msft     Virtual Disk     1.0   /dev/sdc
[1:0:0:1]    disk    Msft     Virtual Disk     1.0   /dev/sdd
[2:0:0:0]    disk    LIO-ORG  sbdnfs           4.0   /dev/sde

    运行相同的命令以连接到其余设备。 此外，请在群集中的其他节点上运行相同的命令集。

  5. 检测到 iSCSI 设备后，命令输出应反映 SBD 设备：

    sudo lsscsi

    [0:0:0:0]    disk    Msft    Virtual Disk     1.0   /dev/sda
[0:0:0:1]    disk    Msft    Virtual Disk     1.0   /dev/sdb
[1:0:0:0]    disk    Msft    Virtual Disk     1.0   /dev/sdc
[1:0:0:1]    disk    Msft    Virtual Disk     1.0   /dev/sdd
[2:0:0:0]    disk    LIO-ORG sbdnfs           4.0   /dev/sde
[3:0:0:0]    disk    LIO-ORG sbdnfs           4.0   /dev/sdf
[4:0:0:0]    disk    LIO-ORG sbdnfs           4.0   /dev/sdg

    sudo lsblk

    NAME                MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                   8:0    0  100G  0 disk
├─sda1                 8:1    0   2M  0 part
├─sda2                 8:2    0 512M  0 part /boot/efi
├─sda3                 8:3    0   1G  0 part /boot
└─sda4                8:4    0 98.5G  0 part /
sdb                   8:16   0   14G  0 disk
└─sdb1                8:17   0   14G  0 part /mnt
sdc                   8:32   0  100G  0 disk
└─sdc1                8:33   0  100G  0 part
└─vg--NW1--NFS-NW1 254:0    0  100G  0 lvm
sdd                   8:48   0  100G  0 disk
└─sdd1                8:49   0  100G  0 part
└─vg--NW2--NFS-NW2 254:1    0  100G  0 lvm
sde                   8:64   0   50M  0 disk
sdf                   8:80   0   50M  0 disk
sdg                   8:96   0   50M  0 disk

原因 4：隔离后节点不会重新加入群集

隔离过程完成后，其中一个节点不会重新加入群集。 SBD处于故障状态，另一节点处于挂起状态。

解决方法 1

SBD 槽可能未处于干净状态。 因此，节点在隔离重启后无法重新加入群集。 运行以下命令来检查 SBD 状态。 如果 SBD 槽不干净，则 SBD 状态显示 reset：

sudo lsscsi

[0:0:0:0]    disk    Msft    Virtual Disk     1.0   /dev/sda
[0:0:0:1]    disk    Msft    Virtual Disk     1.0   /dev/sdb
[1:0:0:0]    disk    Msft    Virtual Disk     1.0   /dev/sdc
[1:0:0:1]    disk    Msft    Virtual Disk     1.0   /dev/sdd
[2:0:0:0]    disk    LIO-ORG sbdnfs           4.0   /dev/sde
[3:0:0:0]    disk    LIO-ORG sbdnfs           4.0   /dev/sdf
[4:0:0:0]    disk    LIO-ORG sbdnfs           4.0   /dev/sdg

sudo ls -l /dev/disk/by-id/scsi-*

sudo sbd -d /dev/sde list

0       nfs-0   clear
1       nfs-1   reset  nfs-0

解决方案 2

验证/etc/sysconfig/sbd配置文件，并检查SBD_STARTMODE参数是否设置为always或clean。

sudo grep -i SBD_STARTMODE  /etc/sysconfig/sbd

SBD_STARTMODE=clean

该 SBD_STARTMODE 参数确定节点是否可以重新加入群集。 如果设置为 always，则节点将重新加入群集，即使它以前被隔离。 如果参数设置为 clean，则节点仅在恢复到干净状态后才会重新加入。

这是预期的行为。 SBD 在节点的槽位中检测到围栏信息，并阻止它加入群集，直到手动清除问题。

若要清除节点槽，请执行以下步骤：

  1. 清除本地节点的隔离信号：

    sudo sbd -d <SBD_DEVICE> message LOCAL clear

    还可以通过指定节点名称而不是 LOCAL从群集中的任何节点运行命令：

    sudo sbd -d <DEVICE_NAME> message <NODENAME> clear

    指定的节点名称应为隔离节点，并且无法加入群集：

    sudo sbd -d /dev/sde message nfs-1 clear

  2. 清除节点槽后，应能够启动群集服务。 如果服务再次失败，请运行以下命令来解决此问题：

    sudo iscsiadm -m node -u

    sudo iscsiadm -m node -l

注意

在这些命令中，按群集设置用实际值替换<SBD_DEVICE>``<DEVICE_NAME>和<NODENAME>。

原因 5：添加新 SBD 设备后 SBD 服务不会启动

创建 SBD 设备或向群集添加一个设备后，会收到错误消息 sbd failed; please check the logs 。

检查向 SBD 设备发送消息时是否收到错误消息：

sudo sbd -d  /dev/disk/by-id/scsi-360014056eadbecfeca042d4a66b9d779 message node1 test

如果遇到此问题，您将看到以下错误：

sbd failed; please check the logs.

从 /var/log/messages：

/var/log/messages 
Mar  2 06:58:06 node1 sbd[11105]: /dev/disk/by-id/scsi-360014056eadbecfeca042d4a66b9d779:    error: slot_msg: slot_msg(): No recipient / cmd specified.
Mar  2 06:58:06 node1 sbd[11104]: warning: messenger: Process 11105 failed to deliver!

解决方法

使用 SBD 作为隔离设备并为其启用 Pacemaker 群集时，必须在群集控制下管理服务。 因此，无法手动启动或停止它们。 此外，启用 SBD 设备或将其添加到群集时，应重启 Pacemaker 群集，以便更改在群集控制下生效：

  1. 在所有群集节点上重启群集服务：

    sudo crm cluster stop
sudo crm cluster start

  2. 检查 SBD 服务是否成功启动：

    sudo systemctl status sbd.service 

    ● sbd.service - Shared-storage based fencing daemon
   Loaded: loaded (/usr/lib/systemd/system/sbd.service; enabled; vendor preset: disabled)
   Active: active (running)

  3. 检查 SBD 设备列表是否提供所需的输出：

    sudo sbd -d /dev/disk/by-id/scsi-360014056eadbecfeca042d4a66b9d779 list

    0   node1   clear   
1   node2   clear

原因 6：SLES 12 升级到 SLES 15 后，SBD 不会启动

将 SLES 12 系统升级到 SLES 15 后，iSCSI 客户端信息可能不存在。 此条件会导致通过 iSCSI 连接到远程文件系统失败。

解决方法

在 SLES 15 中，已弃用 targetcli-fb 的包已替换为 python3-targetcli-fb 或 python2-targetcli-fb。 这会导致系统服务信息重置为默认值（已禁用/停止）。 若要解决此问题，必须手动启用和启动 targetcli 服务。 有关详细信息，请参阅 升级至 SLES15 后的 SBD 失败。

资料来源与适用范围

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

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

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