DRBDが、(実際のハードウェア障害または手動による介入によって)
対向ノードが停止していることを検出すると、
DRBDの接続状態がConnectedからWFConnectionに変化し、
対向ノードが再表示されるまで待機します。
そして、DRBDリソースが切断モードで動作します。
切断モードでは、リソースおよびリソースに関連付けられた
ブロックデバイスが完全に利用可能で、
必要に応じて昇格したり降格したりします。
ただし、ブロックの変更は対向ノードにレプリケートされません。
代わりに、切断中に変更されたブロックについての内部情報をDRBDが格納します。
たとえば、RAMを交換することによって解決できるメモリの問題など、 現在、セカンダリロールのリソースを所有しているノードに一時的な障害が発生した場合は、 障害が発生したノードを修復してオンラインに戻す以外、 介入は必要ありません。 このような場合は、単にシステム起動時に2つのノードが接続を再確立するだけです。 後は、その間にプライマリノードに加えられた変更内容すべてをDRBDがセカンダリノードにレプリケートします。
![[重要項目]](images/important.png) | 重要項目 |
|---|---|
この時点で、DRBDの再同期アルゴリズムの性質により、 セカンダリノードのリソースの一貫性が一時的に失われます。 この短時間の再同期の間は、対向ホストが使用できない場合でも、 セカンダリノードをプライマリロールに切り替えることができません。 したがって、セカンダリノードの実際のダウンタイムとその後の再同期の間は、 クラスタが冗長性を持たない期間になります。 |
DRBDからみると、プライマリノードの障害とセカンダリノードの障害はほぼ同じです。 生き残ったノードが対向ノードの障害を検出し、切断モードに切り替わります。 DRBDは生き残ったノードをプライマリロールに昇格しません。 昇格はクラスタ管理アプリケーションが実行します。
障害が発生したノードが修復されてクラスタに戻る際に、セカンダリロールになります。 すでに述べたように、それ以上の手動による介入は必要ありません。 このときもDRBDはリソースのロールを元に戻しません。 変更を行うように設定されている場合は、 クラスタマネージャがこの変更を行います。
プライマリノードに障害が発生すると、 DRBDは特別なメカニズムによってブロックデバイスの整合性を確保します。 詳細は、「アクティビティログ」を参照してください。
ノードに回復不可能な問題が発生した場合や ノードが永久的に破損した場合は、次の手順を行う必要があります。
障害が発生したハードウェアを 同様のパフォーマンスとディスク容量を持つハードウェアと交換します。
![[注意]](images/note.png)
注意 障害が発生したノードを、 それよりパフォーマンスが低いものと置き換えることも可能ですが、 お勧めはできません。 障害が発生したノードを、 それよりディスク容量が小さいものと置き換えることはできません。 この場合、DRBDを置き換えたノードに接続できません。
OSとアプリケーションをインストールします。
DRBD をインストールし、生き残ったノードから
/etc/drbd.confをコピーします。5章DRBDの設定に記載された手順を行います (「デバイスの初期同期」 の前まで実行)。
この時点で、デバイスの完全同期を手動で開始する必要はありません。 生き残ったプライマリノードへの接続時に、同期が自動的に開始します。