私たちはSLES 12 SP4を使用しています。
今日のテストでは、いくつかの事実を観察しました。ステップは次のとおりです。
ステップ1: "Node01 で) コマンドを使用してカーネルパニックを生成する場合エコ 'b' > /proc/sysrq-trigger「または」エコ 'c' > /proc/sysrq-triggerリソースが実行されているノードでは、クラスタは変更を検出しますが、他のアクティブノードでリソース(SBDを除く)を開始することはできません。
ステップ2:ログによると、次のエラーが見つかります。
pengine: info: LogActions: Leave stonith-sbd (Started node02)
pengine: notice: LogAction: * Start pri-javaiq (node02 ) due to unrunnable nfs_filesystem start (blocked)
pengine: notice: LogAction: * Start lb_health_probe (node02 ) due to unrunnable nfs_filesystem start (blocked)
pengine: notice: LogAction: * Start pri-ip_vip (node02 ) due to unrunnable nfs_filesystem start (blocked)
pengine: notice: LogAction: * Start nfs_filesystem (node02 ) blocked
ステップ3:しかし、ノード(「カーネルパニック」を生成した)で「init 6」を実行すると、驚くべきことに他のノードのリソースが正常に起動して実行されます。
答え1
私の考えでは、ウォッチドッグを正しく設定または構成していないようです。
SBDフェンシングは2つの部分で構成されているため動作します。まず、共有ストレージを介して誤動作するノードに「ポイズンフィル」が渡される。 SBDが失敗した場合、監視装置はノードを再起動し、ノードは「自殺」できません。
ノードがクラッシュ/パニック状態になるようなので、その時点で自己分離する方法はなく、システムを再起動するために監視デバイスに依存する必要があります。これはまた、watchdogが何をするのかを手動で効果的に実行したため、init 6を実行したときに期待どおりに機能する理由も説明します。
SuSEには、監視が必要な理由や構成方法の説明など、優れたSBD保護文書があります。https://documentation.suse.com/sle-ha/15-SP1/html/SLE-HA-all/cha-ha-storage-protect.html
答え2
ついに私たちはその理由を見つけました。これは、起動時にPacemakerサービスが有効になるためです。ペースメーカーサービスを無効にしても問題はありません。