スクリプトを使用して、両方のノードにcrm-fence-peer.9.shDRBDリソースレベルの保護を実装しました。crm-unfence-peer.9.sh
これで、ラップノードで次の動作が発生します。
どちらのノードもオンライン
otrs1です。otrs2リソースが実行中です。
otrs1drbdadm statusotrs1主な役割を果たすこととotrs2小さな役割を果たすことによって
再起動すると、次のメッセージが表示されますotrs1。otrs2
リソースが次に移動したことを確認できますotrs2。
生成された位置制約を表示できます。
レプリケーションリンクが再び機能し、DRBD が同期プロセスを完了すると、制約は削除されます。これで、クラスタ管理者はリソースを自由に昇格できます。実際、制約は取り除かれました。
otrs2ただし、（現在アクティブなノード）でNICを無効にすると、分割脳が発生することがわかります。
明らかに、これは分割脳のシナリオです。なぜですか？だから
crm-fence-peerスクリプトの場合、DRBDへのネットワークリンクがハングしたときにPacemakers通信を引き続き使用できる必要があります。
源泉https://docs.linbit.com/docs/users-guide-9.0/#s-automatic-split-brain-recovery-configuration
ベストアンサー1
正しい。これは、次の理由による可能性が高いです。
crm-fence-peerスクリプトの場合、DRBDへのネットワークリンクがハングしたときにPacemakers通信を引き続き使用できる必要があります。
NIC/ネットワークリンクが1つしかないとします。したがって、NICを削除すると、Pacemakerクラスタが分割されます。クラスタノードはもうまったく通信できないため、現在のマスターはピアと通信できないため、ピアのCIBに制約を適用できません。
このシナリオで分割ブレーンを回避するには、真のノードレベル保護（STONITH）またはCorosyncへの少なくとも複数の通信パスが必要です。