第6章トラブルシューティングとエラーからの回復

第6章トラブルシューティングとエラーからの回復
	パート III. DRBDの使い方

この章では、ハードウェアやシステムに障害が発生した場合に必要な手順について説明します。

6.1. ハードドライブの障害の場合

ハードドライブの障害への対処方法は、DRBDがディスクI/Oエラーを処理する方法(「ディスクエラー処理ストラテジー」を参照)、また設定されているメタデータの種類(「DRBDメタデータ」を参照)によって異なります。

	注記
	ほとんどの場合、ここで取り上げる手順はDRBDを直接物理ハードドライブ上で実行している場合にのみ適用されます。次に示す層の上でDRBDを実行している場合には通常は適用されません。

MDソフトウェアRAIDセット(この場合は mdadm を使用してドライブ交換を管理)
デバイスマッパRAID(`dmraid`を使用)
ハードウェアRAID機器(障害が発生したドライブの扱いについては、ベンダの指示に従う)
一部の非標準デバイスマッパ仮想ブロックデバイス(デバイスマッパのマニュアルを参照)

6.1.1. 手動でDRBDをハードドライブから切り離す

DRBDがI/Oエラーを渡すように設定されている場合(非推奨)、まずDRBDリソースを切り離すとよいでしょう。つまり補助記憶装置から切り離します。

drbdadm detach <resource>

`drbdadm dstate`コマンドを実行して、リソースがディスクレスモードになったことを確認します。

drbdadm dstate <resource>
Diskless/UpToDate

ディスク障害がプライマリノードで発生した場合、スイッチオーバーと、この手順を組み合わせることもできます。

6.1.2. I/Oエラー時の自動切り離し

DRBDがI/Oエラー時に自動的に切り離しを行うように設定(推奨オプション)されている場合、手動での操作なしで、DRBDはすでにリソースを下位ストレージから自動的に切り離しているはずです。その場合でも drbdadm dstate コマンドを使用して、リソースが実際にディスクレスモードで実行されているか確認します。

6.1.3. 障害が発生したディスクの交換(内部メタデータを使用している場合)

内部メタデータを使用している場合、新しいハードディスクで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>

新しいハードディスクの完全同期が瞬時に自動的に始まります。通常のバックグラウンド同期と同様、同期の進行状況を /proc/drbd で監視することができます。

6.1.4. 障害の発生したディスクの交換(外部メタデータを使用している場合)

外部メタデータを使用している場合でも、手順は基本的に同じです。ただし、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 コマンドが同期をトリガーします。この場合でも、同期の進行状況は /proc/drbd で確認できます。

6.2. ノード障害に対処する

DRBDが(実際のハードウェア障害であれ手動による介入であれ)対向ノードがダウンしていることを検出すると、DRBDは自身の接続状態を Connected から WFConnection に変更し、対向ノードが再び現れるのを待ちます。その後、DRBDリソースは切断モードで動作します。切断モードでは、リソースおよびリソースに関連付けられたブロックデバイスが完全に利用可能で、必要に応じて昇格したり降格したりします。ただし、ブロックの変更は対向ノードにレプリケートされません。切断中に変更されたブロックについての内部情報はDRBDが格納します。

6.2.1. 一時的なセカンダリノードの障害に対処する

現時点でセカンダリロールでリソースを持っているノードに一時的に障害が生じた場合(たとえばメモリ交換で直るようなメモリの問題)には、障害が発生したノードを修復してオンラインに戻すだけで十分です。修正したノードを起動すると、ノード間の接続が再確立され、停止中にプライマリノードに加えられた変更内容すべてがセカンダリノードに同期されます。

	重要
この時点で、DRBDの再同期アルゴリズムの性質により、セカンダリノードのリソースの一貫性が一時的に失われます。この短時間の再同期の間は、対向ホストが使用できない場合でも、セカンダリノードをプライマリロールに切り替えることができません。したがって、セカンダリノードの実際のダウンタイムとその後の再同期の間は、クラスタが冗長性を持たない期間になります。

重要

この時点で、DRBDの再同期アルゴリズムの性質により、セカンダリノードのリソースの一貫性が一時的に失われます。この短時間の再同期の間は、対向ホストが使用できない場合でも、セカンダリノードをプライマリロールに切り替えることができません。したがって、セカンダリノードの実際のダウンタイムとその後の再同期の間は、クラスタが冗長性を持たない期間になります。

6.2.2. 一時的なプライマリノードの障害に対処する

DRBDからみると、プライマリノードの障害とセカンダリノードの障害はほぼ同じです。生き残ったノードが対向ノードの障害を検出し、切断モードに切り替わります。DRBDは生き残ったノードをプライマリロールに昇格しません。昇格はクラスタ管理システムが管理します。

障害が発生したノードが修復されてクラスタに戻る際に、セカンダリロールになります。すでに述べたように、それ以上の手動による介入は必要ありません。このときもDRBDはリソースのロールを元に戻しません。変更を行うように設定されている場合は、クラス管理システムがこの変更を行います。

プライマリノードに障害が発生すると、DRBDはアクティビティログというメカニズムによってブロックデバイスの整合性を確保します。詳細は「アクティビティログ」を参照してください。

6.2.3. 永続的なノード障害に対処する

ノードに回復不能な問題が発生した場合やノードが永久的に破損した場合は、次の手順を行う必要があります。

障害が発生したハードウェアを同様のパフォーマンスとディスク容量を持つハードウェアと交換します。

	注記
	障害が発生したノードを、それよりパフォーマンスが低いものと置き換えることも可能ですが、お勧めはできません。障害が発生したノードを、それよりディスク容量が小さいものと置き換えることはできません。この場合、DRBDを置き換えたノードに接続できません。

OSとアプリケーションをインストールします。
DRBDをインストールし、生き残ったノードから /etc/drbd.conf と、全ての /etc/drbd.d/ をコピーします。
4章DRBDの設定に記載された手順を行います。「デバイスの初期同期」の前まで実行します。

この時点で、デバイスの完全同期を手動で開始する必要はありません。生き残ったプライマリノードへの接続時に、同期が自動的に開始します。

6.3. スプリットブレインからの手動回復

ノード間の接続が可能になると、ノード間で初期ハンドシェイクのプロトコルが交換されます。この時点でDRBDはスプリットブレインが発生したかどうかを判断できます。両方のノードがプライマリロールであるか、もしくは切断中に両方がプライマリロールになったことを検出すると、DRBDは即座にレプリケーション接続を切断します。その場合、システムログにたとえば次のようなメッセージが記録されます。

Split-Brain detected, dropping connection!

スプリットブレインが検出されると、1つのノードは常に StandAlone の状態でリソースを保持します。もう一方のノードもまた StandAlone 状態になるか(両方のノードが同時にスプリットブレインを検出した場合)、または WFConnection 状態になります(一方のノードがスプリットブレインを検出する前に対向ノードが切断をした場合)。

DRBDがスプリットブレインから自動的に回復するように設定されていない場合は、この時点で手動で介入して、変更内容を破棄するほうのノードを選択する必要があります。(このノードはスプリットブレインの犠牲ノードと呼ばれる)。この介入は次のコマンドで行います。

注記

スプリットブレインの犠牲ノードは StandAlone の接続状態である必要があり、そうでなければ次のコマンドはエラーを返してきます。次のコマンド実行で確実にstandaloneにできます。

drbdadm disconnect <resource>

drbdadm secondary <resource>
drbdadm connect --discard-my-data <resource>

他方のノード(スプリットブレインの生存ノード)の接続状態も StandAlone の場合には、次のコマンド実行します。

drbdadm connect <resource>

ノードがすでに WFConnection 状態の場合は自動的に再接続するので、この手順は省略できます。

スプリットブレインの影響を受けるリソースがスタックリソースの場合は、単に drbdadm ではなく、 drbdadm --stacked を使用します。

接続すると、スプリットブレインの犠牲ノードの接続状態がすぐに SyncTarget に変化し、残ったプライマリノードによって変更内容が上書きされます。

	注記
	スプリットブレインの犠牲ノードは、デバイスのフル同期の対象にはなりません。代わりに、ローカル側での変更がロールバックされ、スプリットブレインの生存ノードに対して加えられた変更が犠牲ノードに伝播されます。

再同期が完了すると、スプリットブレインが解決したとみなされ、2つのノードが再び完全に一致した冗長レプリケーションストレージシステムとして機能します。


第5章一般的な管理作業		パート IV. DRBDとアプリケーションの組み合わせ