目次
この章では、ハードウェアやシステムに障害が発生した場合に必要な手順について説明します。
ハードドライブの障害への対処方法は、DRBDがディスクI/Oエラーを処理する方法(「ディスクエラー処理ストラテジー」参照)、また設定されているメタデータの種類(「DRBDメタデータ」参照)によって異なります。
![]() | 注記 |
---|---|
ほとんどの場合、ここで取り上げる手順はDRBDを直接物理ハードドライブ上で実行している場合にのみ適用されます。次に示す層の上でDRBDを実行している場合には通常は適用されません。
|
DRBDがI/Oエラーを伝えるように設定(非推奨)している場合、まずDRBDリソースを切り離すとよいでしょう。つまり、下位デバイスからの切り離しです。
# drbdadm detach <resource>
drbdadm status
[10]コマンドを実行することで、現在の状態を確認することができます。
# drbdadm status <resource> <resource> role:Primary volume:0 disk:Diskless <peer> role:Secondary volume:0 peer-disk:UpToDate # drbdadm dstate <resource> Diskless/UpToDate
ディスク障害がプライマリノードで発生した場合、スイッチオーバーと、この手順を組み合わせることもできます。
DRBDがI/Oエラー時に自動的に切り離しを行うように設定(推奨オプション)されている場合、
手動での操作なしで、DRBDはすでにリソースを下位ストレージから自動的に切り離しているはずです。その場合でも drbdadm status
コマンドを使用して、リソースが実際にディスクレスモードで実行されているか確認します。
内部メタデータを使用している場合、新しいハードディスクでDRBDデバイスを再構成するだけで十分です。交換したハードディスクのデバイス名が交換前と異なる場合は、DRBD設定ファイルを適切に変更してください。
# drbdadm create-md <resource> v08 Magic number not found Writing meta data... initialising activity log NOT initializing bitmap New drbd meta data block successfully created. # drbdadm attach <resource>
新しいハードディスクの完全同期がただちに自動的に始まります。通常のバックグラウンド同期と同様、同期の進行状況を drbdadm status
--verbose
で監視することができます。
外部メタデータを使用している場合でも、手順は基本的に同じです。ただし、DRBDだけではハードドライブが交換されたことを認識できないため、追加の手順が必要です。
# drbdadm create-md <resource> v08 Magic number not found Writing meta data... initialising activity log NOT initializing bitmap New drbd meta data block successfully created. # drbdadm attach <resource> # drbdadm invalidate <resource>
![]() | 警告 |
---|---|
|
上記の drbdadm invalidate
コマンドが同期をトリガーします。この場合でも、同期の進行状況は drbdadm status
--verbose
で確認できます。
DRBDが(実際のハードウェア障害であれ手動による介入であれ)対向ノードがダウンしていることを検出すると、DRBDは自身のコネクションステータスを
Connected
から WFConnection
に変更し、対向ノードが再び現れるのを待ちます。その後、DRBDリソースは
disconnected mode(切断モード)
で動作します。切断モードでは、リソースおよびリソースに関連付けられたブロックデバイスが完全に利用可能で、必要に応じて昇格したり降格したりします。ただし、ブロックの変更は対向ノードにレプリケートされません。切断中に変更されたブロックについての内部情報は対向ノードごとにDRBDが格納します。
セカンダリロールでリソースを持っているノードに一時的に障害が生じた場合(たとえばメモリ交換で直るようなメモリの問題)には、障害が発生したノードを修復してオンラインに戻すだけで十分です。修正したノードを起動すると、ノード間の接続が再確立され、停止中にプライマリノードに加えられた変更内容すべてがセカンダリノードに同期されます。
![]() | 重要 |
---|---|
この時点で、DRBDの再同期アルゴリズムの性質により、セカンダリノードのリソースの一貫性が一時的に失われます。この短時間の再同期の間は、対向ホストが使用できない場合でも、セカンダリノードをプライマリロールに切り替えることができません。したがって、セカンダリノードの実際のダウンタイムとその後の再同期の間は、クラスタが冗長性を持たない期間になります。 |
DRBD9では各リソースに3ノード以上が接続することができます。そのため、例えば4ノードでは一度フェイルオーバーしてもまだ2回フェイルオーバーすることができます。
DRBDからみると、プライマリノードの障害とセカンダリノードの障害はほぼ同じです。生き残ったノードが対向ノードの障害を検出し、切断モードに切り替わります。DRBDは生き残ったノードをプライマリロールに 昇格しません。これはクラスタ管理システムが管理します。
障害が発生したノードが修復されてクラスタに戻る際に、セカンダリロールになります。すでに述べたように、それ以上の手動による介入は必要ありません。このときもDRBDはリソースのロールを元に戻しません。変更を行うように設定されている場合は、クラス管理システムがこの変更を行います。
プライマリノードに障害が発生すると、DRBDはアクティビティログというメカニズムによってブロックデバイスの整合性を確保します。詳細は「アクティビティログ」を参照ください。
ノードに回復不能な問題が発生した場合やノードが永久的に破損した場合は、次の手順を行う必要があります。
障害が発生したハードウェアを同様のパフォーマンスと ディスク容量を持つハードウェアと交換します。
![]() | 注記 |
---|---|
障害が発生したノードを、それよりパフォーマンスが低いものと置き換えることも可能ですが、お勧めはできません。障害が発生したノードを、それよりディスク容量が小さいものと置き換えることはできません。このような場合には、DRBDを置き換えたノードへの接続は拒否されます。[11] |
/etc/drbd.conf
と、全ての /etc/drbd.d/
を コピーします。
この時点で、デバイスの完全同期を手動で開始する必要はありません。生き残ったプライマリノードへの接続時に、同期が自動的に開始します。
ノード間の接続が可能になると、ノード間で初期ハンドシェイクのプロトコルが交換されます。この時点でDRBDはスプリットブレインが発生したかどうかを判断できます。両方のノードがプライマリロールであるか、もしくは切断中に両方がプライマリロールになったことを検出すると、DRBDは即座にレプリケーション接続を切断します。その場合、システムログにたとえば次のようなメッセージが記録されます。
Split-Brain detected, dropping connection!
スプリットブレインが検出されると、1つのノードは常にStandAlone の状態でリソースを保持します。もう一方のノードもまた StandAlone 状態になる(両方のノードが同時にスプリットブレインを検出した場合)、または WFConnection 状態になります(一方のノードがスプリットブレインを検出する前に対向ノードが切断をした場合)。
DRBDがスプリットブレインから自動的に回復するように設定されていない場合は、この時点で手動で介入して、変更内容を破棄するほうのノードを選択する必要があります(このノードは スプリットブレインの犠牲ノード と呼ばれる)。この介入は次のコマンドで行います。
![]() | 警告 |
---|---|
ここは現在 作業中 です。 構成の変更が行われる予定です。 |
# drbdadm disconnect <resource> # drbdadm secondary <resource> # drbdadm connect --discard-my-data <resource>
他方のノード(スプリットブレインの生存ノード)のコネクションステータスも StandAlone
の場合には、次のコマンド実行します。
# drbdadm disconnect <resource> # drbdadm connect <resource>
ノードがすでに Connecting の状態の場合は自動的に再接続するので、この手順は省略できます。
接続すると、スプリットブレインの犠牲ノードのコネクションステータスがすぐに SyncTarget に変化し、他のノードによって変更内容が上書きされます。
![]() | 注記 |
---|---|
スプリットブレインの犠牲ノードは、デバイスのフル同期の対象にはなりません。代わりに、ローカル側での変更がロールバックされ、スプリットブレインの生存ノードに対して加えられた変更が犠牲ノードに伝播されます。 |
再同期が完了すると、スプリットブレインが解決したとみなされ、2つのノードが再び完全に一致した冗長レプリケーションストレージシステムとして機能します。