PacemakerクラスターでDRBDを無効にする理由
DRBDのドキュメント（セクション DRBDとPacemakerクラスターの統合 ）では、PacemakerクラスターでDRBDを無効にすることを推奨しています。
DRBD OCFリソースエージェントを使用している場合は、DRBDの起動、シャットダウン、昇格、および降格をOCFリソースエージェントにのみ延期することをお勧めします。つまり、DRBD initスクリプトを無効にする必要があります：
chkconfig drbd off。
Systemdでは、これはsystemctl disable drbd.service。
この推奨事項にもかかわらず、DRBDを有効にすることに害はありますか？アイデアは、DRBDを有効にするが、CorosyncとPacemakerを無効にすることです。これにより、クラスターノードに障害が発生して再起動した後も、DRBD同期データを受信し続けますが、それ以外の場合は「パッシブ」のままになります。これにより、クラスターに再び入る前に障害のあるノードを分析できるようになりますが、その間、両方のクラスターノードにまだライブデータが保存されています。この理論的根拠を上回る推奨の背後にある理論的根拠は何ですか？
OSレベルでDRBDサービスを無効にする目的は、すべてがペースメーカーによって制御されることです。 2つのサービス（PCMKとOSなど）が開始/停止/昇格/降格などを試みている場合、スプリットブレインのリスクがあります。制御されたクラスター環境の場合、クラスターノード間の混乱を避けるために、すべてはクラスターリソースマネージャー（この場合はペースメーカー）で処理する必要があります。スプリットブレインなどの場合、CRMはSTONITHまたはフェンスのいずれかを行うか、他のノードで構成されたクォーラムを使用して解決します。
クラスターリソースマネージャーを使用する場合、どのリソースもリソースマネージャーによって制御される必要があります。クラスターリソースマネージャーの外部から有効/無効にされたリソースは、管理者とリソースマネージャーの両方にとって混乱の原因となる可能性があります。
すでに2つの回答がありますが、これは悪いアイデアである理由とその理由を明確に示していますが、おそらくそれがあなたにとってどのようにうまくいかないのか、そしてPacemakerを使用してこれらの問題に対処する方法についての詳細は、あなたや他の人を説得するのに役立ちますこのようにしないでください。
最初に、Pacemakerはログに記録し、リソースの障害について説明します。ノードから「禁止」される前のリソースのデフォルトの失敗回数は、resource-failure-timeoutウィンドウ内で3つで、デフォルトではタイムアウトしません。したがって、DRBDリソース（またはそのほかのリソース）が3回続けて失敗すると、強力な（無限）「負の場所の制約」を使用して、現在アクティブなノードから禁止されます。つまり、リソースはどこでも実行できますが、現在アクティブなノード。そのルールが整ったら、リソースは可能であれば別の場所に移動するか、障害が解決されるまで停止します。
ご覧のとおり、Pacemakerはこれらの障害を独自に適切に処理するように作成できます。
Pacemakerとは何か、Pacemakerの外部の状態を強制するリソースの管理がなぜ悪いのかを理解する必要があります。 Pacemakerは有限状態システムです。それは、管理するリソースを完全に制御して、障害から正常に回復し、リソースが本来あるべき場所で停止または開始されるようにする必要があります。
一度に1つのノードでのみ実行する必要がある単純なリソースを検討してください。「スプリットブレイン」になり、発散するデータセットが作成されないようにしてください。発生する可能性のある最悪の事態についてです。データの損失を防ぐためにオペレーターが注意を払う。
Pacemakerはこのリソースを制御し、ノード「Able」でソフトウェアのインスタンスを起動します。善意の管理者は、サービスがAbleで開始されているが、そのsystemdユニットファイルが「無効」になっていることを発見しました。その管理者はユニットファイルを有効にして、再起動時にサービスが「復帰」するようにします。Pacemakerがすでにこれを処理していることは知らされていません。 systemdユニットファイルは、多くの場合と同様に、障害時にリソースを再起動するように設定されています。
PacemakerがこのリソースをAbleからクラスター「ベイカー」の2番目のノードに移行しようとすると、サービスが強制終了されたにもかかわらずリソースが停止エラーに遭遇しましたが、どういうわけかそれはまだ生きていて、ゾンビの黙示録の真っ只中にいます。リソースは停止できないため、スプリットブレイン状態を引き起こさずにBakerで起動することはできません。 systemdとPacemakerが制御を争うため、リソースは停止と開始の間でフラップします。最終的に、Pacemakerはリソースを「解放」して「非管理モード」にします。これは、そのリソースに対して開始または停止操作が実行されないことを意味します。
したがって、そのシナリオでは、Pacemakerよりも「愚かでしつこい」ため、Systemdが勝ちました。 PacemakerとSystemdの両方の動作に精通していない管理者が理解するのは、Pacemakerがいたるところに失敗しているように見えるため、これは非常に困難です-実際には、状況に応じて実際に想定されていることを実行しています手元に。
また、上記のシナリオが、その条件に対して可能な限り最高の終了であったことも考慮してください。わずかなインフラストラクチャ障害が発生した場合、クラスターはスプリットブレインになり、両方のノードでそのリソースがアクティブになります。
余談ですが、STONTIHを介したフェンシングはそのシナリオでクラスターがスプリットブレインになるのを防ぎますが、STONITHはクラスターの安定性の最後の手段ですが、上記の条件はほぼ最初の手段です。そしていつものように、STONITHはクラスターを本番環境に対応させる必要があります。