適用対象: ✔️ Linux VM
この記事では、SUSE Enterprise Linux Pacemaker クラスターで STONITH Block Device (SBD) サービスが開始されない一般的なシナリオについて説明します。 この記事では、この問題を特定して解決するためのガイダンスも提供します。
SBD のしくみ
SBD デバイスには、インターネット Small Computer System Interface (iSCSI) ターゲット サーバーとして機能し、SBD デバイスを提供する仮想マシン (VM) が少なくとも 1 つ必要です。 これらの iSCSI ターゲット サーバーは、他の Pacemaker クラスターと共有することもできます。 SBD を使用する利点は、オンプレミスで既に使用している場合、SBD デバイスでは Pacemaker クラスターの操作方法を変更する必要が出ないということです。
SBD ストレージ保護を備える Microsoft Azure Pacemaker クラスターの場合、セットアップには次のいずれかのオプションを使用できます。 これらのメカニズムの詳細については、以下を参照してください。
問題を診断する方法
次の例では、クラスターの起動の問題が SBD サービスの障害によって発生していることを確認する方法を示します。
クラスターの状態を確認します。
sudo crm statusERROR: status: crm_mon (rc=102): Error: cluster is not available on this nodePacemaker サービスが開始されるかどうかを確認します。 次の出力例は、1 つ以上の依存サービスが機能していないために 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: iSCSI エラーが原因で SBD サービスが失敗しました
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 iscsidiscsidサービスとiscsiサービスが実行されていることを確認します。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-1SBD 構成ファイルに記載されているすべての 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 discovery。sudo 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: フェンス後にノードがクラスターに再参加しない
フェンス 処理が完了した後、ノードの 1 つがクラスターに再び参加しません。 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 clearLOCALの代わりにノード名を指定して、クラスター内の任意のノードからコマンドを実行することもできます。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
Note
これらのコマンドでは、 <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 startSBD サービスが正常に開始されたかどうかを確認します。
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 フィードバック コミュニティに製品フィードバックを送信することもできます。
サードパーティの情報に関する免責事項
この資料に記載されているサードパーティ製品は、マイクロソフトと関連のない他社の製品です。 明示的か黙示的かにかかわらず、これらの製品のパフォーマンスや信頼性についてマイクロソフトはいかなる責任も負わないものとします。