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

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

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

注意

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

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

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

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

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

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

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

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

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

	注意
	デバイスサイズは、 blockdev --getsz deviceを実行して取得できます。 ただし、 echo $(( $(blockdev --getsize64 device) / 512))は 2TBを超えるブロックデバイスにも使用できるため、こちらのほうが便利です。

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

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

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