内部メタデータを使用するようにリソースを設定すると、DRBDはメタデータを実際の本稼働データと同じ下位レベルの物理デバイスに格納します。デバイスの末尾の領域がメタデータを格納するための領域として確保されます。

メリット. メタデータは実際のデータと密接にリンクされているため、ハードディスクに障害が発生しても、管理者は特に何かする必要はありません。メタデータは実際のデータとともに失われ、ともに復元されます。

デメリット. RAIDセットではなく、下位レベルデバイスが唯一の物理ハードディスクの場合は、内部メタデータが原因で書き込みスループットが低下することがあります。アプリケーションによる書き込み要求の実行により、DRBDのメタデータの更新が引き起こされる場合があります。メタデータがハードディスクの同じ磁気ディスクに格納されている場合は、書き込み処理によって、ハードディスクの書き込み/読み取りヘッドが2回余分に動作することになります。

注意

すでにデータが書き込まれているディスク領域を下位デバイスに指定してDRBDでレプリケートする場合で、内部メタデータを使うには、DRBDのメタデータに必要な領域を必ず確保してください。そうでない場合、DRBDリソースの作成時に、新しく作成されるメタデータによって下位レベルデバイスの末尾のデータが上書きされ、既存のファイルが破損します。以下のいずれかの方法でこれを避けることができます。 下位レベルデバイスを拡張します。これには、LVMやEVMSなどの論理ボリューム管理機能を使用します。ただし、対応するボリュームグループまたはコンテナに空き領域が必要です。ハードウェアストレージソリューションを使用することもできます。 下位レベルデバイスの既存のファイルシステムを縮小します。ファイルシステムによっては実行できない場合があります。 上記の2つが不可能な場合は、代わりに外部メタデータ を使用します。 下位レベルデバイスをどの程度拡張するか、またはファイルシステムをどの程度縮小するかについては、 「メタデータサイズの見積り」を参照してください。

外部メタデータは、本稼働データを格納するものとは異なる個別の専用ブロックデバイスに格納します。

メリット. 一部の書き込み処理では、外部メタデータを使用することにより、待ち時間をいくらか短縮できます。

デメリット. メタデータが実際の本稼働データに密接にリンクされません。つまり、ハードウェア障害により本稼働データだけが破損したか、DRBD メタデータは破損しなかった場合、手動による介入が必要です。生き残ったノードから切り替えるディスクに、手動でデータの完全同期を行う必要があります。

次のすべての項目に該当する場合は、外部メタデータを使用する以外ありません。

デバイスのメタデータを格納する専用ブロックデバイスが必要とするサイズについては、「メタデータサイズの見積り」を参照してください。

次の式を使用して、DRBDのメタデータに必要な領域を正確に計算できます。

式18.1 DRBD メタデータサイズの計算 (正確)

Csはセクタ単位のデータデバイスサイズです。

	注記
	デバイスサイズは、 blockdev --getsz deviceを実行して取得できます。

結果のMsもセクタ単位です。MBに変換する場合は2048で割ります(512バイトをセクタサイズとする、s390を除くすべての標準のLinuxプラットフォームの場合)。

実際には、次の計算で得られる大まかな見積りで十分です。この式では、単位はセクタではなくメガバイトです。

式18.2 DRBD メタデータサイズの見積り (概算)