适用于：✔️ Linux VM
本文概述了 STONITH 块设备（SBD）服务未在 SUSE Enterprise Linux Pacemaker 群集中启动的常见方案。 本文还提供了有关识别和解决此问题的指导。
SBD 的工作原理
SBD 设备需要至少一台充当 Internet 小型计算机系统接口（iSCSI）目标服务器的虚拟机（VM），并提供 SBD 设备。 这些 iSCSI 目标服务器也可以与其他 Pacemaker 群集共享。 使用 SBD 的优势在于，如果已在本地使用 SBD 设备，则 SBD 设备无需更改 Pacemaker 群集的运行方式。
对于具有 SBD 存储保护的 Microsoft Azure Pacemaker 群集，可以使用以下任一选项进行设置。 有关这些机制的详细信息，请参阅：
如何诊断问题
以下示例演示如何确定群集启动问题是由 SBD 服务故障引起的。
检查群集的状态：
sudo crm statusERROR: status: crm_mon (rc=102): Error: cluster is not available on this node检查 Pacemaker 服务是否启动。 以下示例输出指示 Pacemaker 服务失败，因为一个或多个依赖服务未正常工作：
sudo systemctl status pacemakerpacemaker.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'.检查 Pacemaker 服务的依赖项服务树：
sudo systemctl list-dependencies pacemakerpacemaker.service ● ├─corosync.service ● ├─dbus.service ● ├─sbd.service ● ├─system.slice ● ├─resource-agents-deps.target ● └─sysinit.target检查每个服务的状态。 在以下示例中，可以看到所有依赖项服务（如 Corosync）都处于活动状态，但 SBD 服务未运行：
sudo systemctl status corosynccorosync.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 ]检查 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 服务失败。
解决方法
- 确保正确配置设置，如 SUSE 中所述 - 在 Azure 中的 SUSE Linux Enterprise Server 上设置 Pacemaker。
- 将群集置于维护模式：
sudo crm configure property maintenance-mode=true - 请确保
iscsid已启用和服务iscsi：sudo systemctl enable iscsisudo systemctl enable iscsid iscsidiscsi验证服务和服务是否正在运行：sudo systemctl status iscsi
如果服务正常工作，输出应如下所示：sudo systemctl status iscsidiscsi.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.- 从维护模式中删除群集：
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
解决方法
执行以下检查：
验证两个群集节点上的发起程序名称：
sudo cat /etc/iscsi/initiatorname.iscsiInitiatorName=iqn.2006-04.nfs-0.local:nfs-0sudo cat /etc/iscsi/initiatorname.iscsiInitiatorName=iqn.2006-04.nfs-1.local:nfs-1尝试列出 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"根据提供的错误消息，检查 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.若要修复此错误，请在群集的两个节点上运行以下步骤，在确保 SBD 服务器正在运行且可访问后连接到 iSCSI 设备。 在以下示例中，
iqn.2006-04.nfs.local:nfs是运行第一个命令时列出的目标名称：iscsiadm -m discoverysudo iscsiadm -m discovery10.0.0.17:3260 via sendtargets 10.0.0.18:3260 via sendtargets 10.0.0.19:3260 via sendtargetssudo iscsiadm -m discovery --type=st --portal=10.0.0.17:326010.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:nfssudo iscsiadm -m node -T iqn.2006-04.nfs.local:nfs --login --portal=10.0.0.17:3260Logging 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=automaticsudo 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运行相同的命令以连接到其余设备。 此外，请在群集中的其他节点上运行相同的命令集。
检测到 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/sdgsudo lsblkNAME 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 在节点的槽中检测到隔离消息，并阻止它加入群集，直到手动清除问题。
若要清除节点槽，请执行以下步骤：
清除本地节点的隔离消息：
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清除节点槽后，应能够启动群集服务。 如果服务再次失败，请运行以下命令来解决此问题：
sudo iscsiadm -m node -usudo 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 群集，以便更改在群集控制下生效：
在所有群集节点上重启群集服务：
sudo crm cluster stop sudo crm cluster start检查 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)检查 SBD 设备列表是否提供所需的输出：
sudo sbd -d /dev/disk/by-id/scsi-360014056eadbecfeca042d4a66b9d779 list0 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 失败。
后续步骤
有关其他帮助，请使用以下说明打开支持请求。 提交请求时，请附加 supportconfig 和 hb_report 日志以进行故障排除。
联系我们寻求帮助
如果你有任何疑问或需要帮助，请创建支持请求或联系 Azure 社区支持。 你还可以将产品反馈提交到 Azure 反馈社区。
第三方信息免责声明
本文中提到的第三方产品由 Microsoft 以外的其他公司提供。 Microsoft 不对这些产品的性能或可靠性提供任何明示或暗示性担保。