DRBD.CONF(5)

NAME
drbd.conf - DRBD 構成ファイル

INTRODUCTION

DRBD は、データをクラスタのすべてのノードに複製するブロックデバイスを実装する。実際のデータおよび関連するメタデータは、通常、各クラスタノードの「通常の」ブロックデバイスに格納される。

複製されたブロックデバイスは、 デフォルトで /dev/drbdminor で呼ばれる。それらはリソースにグループ化され、リソースごとに 1 つ以上のデバイスが含まる。リソース内のデバイス間のレプリケーションは、時間順に行われる。DRBD では、リソース内のデバイスを volumes で参照する。

DRBD 9 では、2 つ以上のクラスタノード間でリソースを複製できる。クラスタノード間の接続はポイントツーポイントリンクであり、TCP または TCP のようなプロトコルを使用する。すべてのノードを直接接続する必要がある。

DRBD は、カーネルと相互作用し、基本的な操作を実行する低レベルのユーザー空間コンポーネント （drbdsetup、 drbdmeta） 、DRBD の構成を理解、処理し、それを低レベルコンポーネントの基本操作に変換する高レベルのユーザー空間コンポーネント（drbdadm）、およびカーネルコンポーネントで構成される。

デフォルトの DRBD 構成は、 /etc/drbd.conf とそこからインクルードされる追加のファイル、通常は、 /etc/drbd.d/ の global_common.conf, すべての *.res ファイルから成り立つ。各リソースを *.res ファイルで別々に定義することは有用である。

構成ファイルは、各クラスタノードがクラスタ構成全体で同一のコピーを含むことができるように設計されている。各ノードのホスト名によって、構成のどの部分が適用されるかが決まるuname -n）。すべてのノードのクラスタ構成を同期させておくことを推奨する。手動でノードをすべてのノードにコピーするか、 csync2 または同様のツールそ使用する。

設定ファイルの例

    global {
    	usage-count yes;
    	udev-always-use-vnr;
    }
    resource r0 {
          net {
    	      cram-hmac-alg sha1;
    	      shared-secret "FooFunFactory";
          }
          volume 0 {
    	      device    /dev/drbd1;
    	      disk      /dev/sda7;
    	      meta-disk internal;
          }
          on alice {
    	      node-id   0;
    	      address   10.1.1.31:7000;
          }
          on bob {
    	      node-id   1;
    	      address   10.1.1.32:7000;
          }
          connection {
    	      host      alice  port 7000;
    	      host      bob    port 7000;
    	      net {
    			protocol C;
    	      }
          }
    }

この例では、ボリューム番号が 0 の単一の複製デバイスが含まれるリソース r0 を定義する。このリソースは、ホスト alice, bob 間で複製され、それぞれ IPv4 アドレス 10.1.1.31, 10.1.1.32、ノード識別子 0, 1 を持つ。両方のホストで複製されたデバイスは /dev/drbd1 で呼び出され、実際のデータとメタデータは下位のデバイス /dev/sda7 に格納される。ホスト間の接続はプロトコル C を使用する。

詳しくは DRBD User's Guide[1] を参照。

FILE FORMAT

DRBD 構成ファイルはセクションで構成され、セクションには他のセクションとパラメータが含まれる。各セクションは、1 つ以上のキーワード、場合によってはセクション名、開始ブレース（“{”）、セクションの内容、および閉じ括弧（“}”） で構成される。セクション内のパラメータは、キーワード、1 つ以上のキーワードまたは値、セミコロン（“;”） で構成される。

一部のパラメータ値には、素の数値が指定されたときに適用されるデフォルトのスケールがある（たとえば、Kilo は数値の1024倍）。このようなデフォルトのスケールは、接尾辞を使用して上書きすることができる。（メガの場合は M）。共通の接尾語 K = 2^10 = 1024, M = 1024 K, G = 1024 M はサポートされている。

コメントはハッシュ記号で始まり（“＃”）、行の最後までコメントとみなされる。さらに、どのセクションにもキーワード skip 接頭辞を付けることができ、セクションおよびすべてのサブセクションを無効にするのに使用できる。。

追加ファイルは include file-pattern キーワードでインクルードできる。サポートされている形式は glob(7) マニュアルを参照。インクルード形式はセクションの外部でのみ許可される。

次のセクションが定義されている（インデントはどのコンテキストにあるかを示す）。

    common
       [disk]
       [handlers]
       [net]
       [options]
       [startup]
    global
    resource
       connection
          path
          net
            volume
               peer-device-options
          [peer-device-options]
       connection-mesh
          net
       [disk]
       floating
       handlers
       [net]
       on
          volume
             disk
             [disk]
       options
       stacked-on-top-of
       startup

角括弧 [] 内のセクションは、設定の他の部分にも影響する。 common セクションはすべてのリソースに適用される。resource または on 内の disk セクションは、そのリソース内のすべてのボリュームに適用される。resource 内のnet セクションはそのリソースのすべての接続に適用される。これにより、各リソース、接続、またはボリュームに対して同じオプションを繰り返すのを避けることができる。オプションは resource, connection, on, volume セクションでオーバーライドできる。

peer-device-options は resync-rate, c-plan-ahead, c-delay-target, c-fill-target, c-max-rate, c-min-rate のどれかである. 後方互換性のため、disk オプションセクションでも指定できる。それらはすべての関連する接続に継承される。connection レベルでそれらが与えられた場合、その接続上のすべてのボリュームに継承される。peer-device-options セクションは disk キーワードで始まる。

  セクション

common
    このセクションには、disk, handlers, net, options, startup セクションが含まれる。すべてのリソースは、これらのセクションのパラメータをデフォルト値として継承する。

connection [name]
    2 つのホスト間の接続を定義する。このセクションには、2 つの host パラメータまたは複数のpath sections を含む必要がある。オプション name は、システムログやその他のメッセージの接続を参照するために使用する。name を指定しない場合、代わりに対向ノードのホスト名が使用される。

path
    2 つのホスト間のパスを定義する。このセクションには、2 つの host パラメータを含む必要がある。

connection-mesh
    複数のホスト間に接続網を定義する。このセクションは、 ホスト名を引数とする hosts パラメータを含む必要がある。このセクションは、同じネットワークオプションを共有する多くの接続を定義するためのショートカットである。

disk
    ボリュームのパラメータを定義する。このセクションのすべてのパラメータはオプションである。

floating [address-family] addr:port
    on と同様であるが、ホスト名の代わりにネットワークアドレスが floating セクションとマッチするかに使用される。

    このセクションの node-id パラメータは必須である。address パラメータが指定されていない場合、デフォルトで対向ノードへの接続は作成されない。device, disk, meta-disk パラメータは定義もしくは継承されている必要がある。

global
    いくつかのグローバルパラメータを定義する。このセクションのすべてのパラメータはオプションである。global セクションは一回だけ記述できる。

handlers
    特定のイベントが発生したときに呼び出されるハンドラを定義する。カーネルは、コマンドラインの最初の引数にリソース名を渡し、イベントのコンテキストに応じて次の環境変数を設定する。

        • 特定のデバイスに関連するイベントの場合、デバイスのマイナー番号は DRBD_MINOR、デバイスのボリューム番号は DRBD_VOLUME に設定される。

        • 特定の対向ノード上の特定のデバイスに関連するイベントの場合、 DRBD_MY_ADDRESS, DRBD_MY_AF, DRBD_PEER_ADDRESS, DRBD_PEER_AF; デバイスのローカルマイナー番号は DRBD_MINOR, デバイスのボリューム番号は DRBD_VOLUME に設定される。

        • 特定の接続に関連するイベントの場合、接続エンドポイントは DRBD_MY_ADDRESS, DRBD_MY_AF, DRBD_PEER_ADDRESS, DRBD_PEER_AF; その接続用に定義された各デバイスについて、デバイスのマイナー番号は DRBD_MINOR_volume-number に設定される。

        • デバイスを識別するイベントの場合、下位デバイスが接続されている場合は、下位デバイスのデバイス名が渡される DRBD_BACKING_DEV （またはDRBD_BACKING_DEV_volume-number）。

    このセクションのすべてのパラメータはオプションである。イベントごとに 1 つのハンドラしか定義できない。ハンドラが定義されていなければ何も起こらない。

net
    接続のパラメータを定義する。このセクションのすべてのパラメータはオプションである。

on host-name [...]
    特定のホストまたはホストのセット上のリソースのプロパティを定義する。複数のホスト名を指定することは、たとえば IP アドレスのフェイルオーバーを使用する設定で意味がある。host-name 引数は Linux のホスト名と一致する必要がある （uname -n）。

    通常、少なくとも 1 つの volume セクションを含むか継承する。node-id と address パラメータはこのセクションで定義する必要がある。device, disk, meta-disk パラメータは定義もしくは継承されている必要がある。

    通常の構成ファイルには、各リソースで 2 つ以上の on セクションが含まれる。floating セクションも参照。

options
    リソースのパラメータを定義する。このセクションのすべてのパラメータはオプションである。

resource name
    リソースを定義する。通常、少なくとも 2 つの on セクションと少なくとも 1 つの connection セクションを含む。

stacked-on-top-of resource
    3〜4 つのノードを持つスタック型リソースを構成するため on セクションに代わり使われる。

    DRBD 9 以降、スタッキングは推奨しない。代わりに 2 つ以上のノード間で複製されるリソースを使用することを推奨する。

startup
    このセクションのパラメータは、起動時のリソースの動作を決定する。

volume volume-number
    リソース内のボリュームを定義する。リソースの volume セクションのボリューム番号は、どのホスト上のどのデバイスが複製されたデバイスを形成するかを定義する。

  connection セクションのパラメータ

host name [address [address-family] address] [port port-number]
    接続のエンドポイントを定義する。各 host ステートメントは、リソースの on セクションを参照する。ポート番号が定義されている場合、このエンドポイントは、on セクションで定義されたポートの代わりに指定されたポートを使用する。各 connection セクションには 2 つ host パラメータが必要である。2 つ host パラメータに代わって、複数の path セクションを含むかもしれない。

  path セクションのパラメータ

host name [address [address-family] address] [port port-number]
    接続のエンドポイントを定義する。各 host ステートメントは、リソースの on セクションを参照する。ポート番号が定義されている場合、このエンドポイントは、on セクションで定義されたポートの代わりに指定されたポートを使用する。各 path セクションには 2 つ host パラメータが必要である。

  connection-mesh セクションのパラメータ

hosts name...
    すべてのノード網を定義する。各 name は、リソースの on セクションを参照する。on セクションで定義されているポートが使用される。

  disk セクションのパラメータ

al-extents extents
    DRBD は、直近の書き込み活動に基づいて、すぐに書き直される可能性のある「ホット」または「アクティブ」ディスク領域を自動的に維持する。「アクティブ」ディスク領域はすぐに書き込むことができるが、「非アクティブ」ディスク領域は最初に「アクティブ化」する必要があり、このためのメタデータ書き込みが必要である。このアクティブなディスク領域を「アクティビティログ」として参照する。

    アクティビティーログはメタデータに書き込まれるが、失敗したノードのリカバリー時にはログ全体を再同期化する必要がある。アクティビティログのサイズは、再同期にかかる時間やクラッシュ後に複製されるディスクが整合状態になる時間に影響を与える。

    アクティビティログは、4メガバイトのセグメントから構成される。その al-extents パラメータは、同時にアクティブにできるセグメントの数を決定する。al-extents のデフォルト値は 1237、 最小値は 7、 最大値は 65536 である。

    有効な最大値はもっと小さくなる点に注意が必要であり、メタデータのデバイスの作成方法によっても異なる。次のマニュアルページを参照、drbdmeta(8)。有効な最大値は 919 * (使用できる オンディスクのアクティビティログのリングバッファ領域 /4KB -1) である。リングバッファはデフォルトで 32KB で、有効な最大値は 6433 である (データは 25GiB 以上カバーしている)。下位デバイスの量とレプリケーションリンク全体が 5 分以内で再同期できるようにすることを推奨する。

al-updates {yes | no}
    このパラメータを使用すると、アクティビティログを完全にオフにすることができる（al-extents パラメータを参照）。メタデータの書き込みが少なくて済むため、書き込みが高速になるが、故障したプライマリノードの回復のためにデバイス全体を再同期する必要がある。al-updates のデフォルト値は yes である。

disk-barrier,
disk-flushes,
disk-drain
    DRBD は、依存書き込みリクエストの順序を処理する 3 つの方法がある:

    disk-barrier
        ディスクバリアを使用して、リクエストが正しい順序でディスクに書き込まれるようにする。バリアの前に提出されたすべてのリクエストが、バリアの後に提出されたリクエストの前にディスクに書き込まれることを保証する。これは、SCSI デバイスの 'tagged command queuing' と SATA デバイスの 'native command queuing' を使用して実装される。一部のデバイスおよびデバイススタックのみがこの方法をサポートする。デバイスマッパー （LVM） は、一部の構成でのみバリアをサポートする。

        ディスクバリアをサポートしていないシステムで、このオプションを有効にするとデータが消失または破損する可能性がある。DRBD 8.4.1 までは、下位デバイスがバリアをサポートする場合 disk-barrier が有効でした。しかし、linux-2.6.36 （または RHEL6 の 2.6.32） 以降のカーネルでは、バリアがサポートされているかどうかを検出できなくなりました。drbd-8.4.2 以降、このオプションはデフォルトでは無効であり、使用する場合は明示的に有効にする必要がある。

    disk-flushes
        依存書き込みリクエスト間でディスクフラッシュを使用する（ドライブベンダーにより 'force unit access' とも呼ばれる）。これにより、すべてのデータが強制的にディスクに格納される。このオプションは、デフォルトで有効である。

    disk-drain
        依存書き込みリクエストを送信する前に、リクエストキューが排出されるまで待つ（つまり、リクエストが完了するのを待つ）。この方法は、リクエストが完了するとディスク上で安定している。DRBD 8.0.9 より前は、これが実装された唯一の方法でした。このオプションは、デフォルトで有効である。運用環境では無効にしないことを推奨する。

    これらの3つの方法から、DRBD は設定が有効で、下位デバイスもサポートしている最初のものを使用する。これらの3つのオプションがすべて無効になっている場合、DRBD は依存関係を気にせずに書き込みリクエストを送信する。下位デバイスによって、書き込みリクエストを並べ替えることができ、異なるクラスタノード上で異なる順序で書き込みリクエストを送信できる。これは、データの損失または破損の原因となる。したがって、書き込み順序を制御する 3 つの方法をすべて無効にしないことを推奨する。

    書込み順序を設定する一般的なガイドラインは、揮発性書込みキャッシュを備えた通常のディスク（または通常のディスクアレイ）を使用する場合は、disk-barrier または disk-flushes を使用することである。キャッシュを持たないストレージまたはバッテリバックアップのライトキャッシュでは、 disk-drain が適している。

disk-timeout
    DRBD デバイスのデータを格納する下位レベルデバイスが、指定した disk-timeout 以内で I/O リクエストを完了しない場合、DRBD はこれを障害とみなす。下位デバイスは切り離され、デバイスのディスク状態はディスクレス状態になる。DRBD が 1 台以上の対向ノードに接続したとき、失敗したリクエストはそのうちの 1 台に伝えられる。

    このオプションは カーネルパニックを引き起こす可能性があり、注意が必要である。

    リクエストの「中断」あるいはディスクの強制切り離しは、完全に下位デバイスをブロックまたはハンギングして、リクエストをまったく処理せずエラーも処理しなくなる。この状況ではハードリセットとフェイルオーバ以外になす術がない。

    「中断」すると、基本的にローカルエラーの完了を装い、すみやかにサービスの移行を行うことで安全な切り替えを行う。それでもなお、影響を受けるノードは "すぐ" に再起動される必要はある。

    リクエストを完了することで、上位レイヤーに関連するデータページを再利用させることができる。

    後にローカルの下位デバイスが「復帰」すると、ディスクから元のリクエストページへの DMA のデータは、うまくいくと未使用のページへランダムなデータを送るが、多くの場合その間に関係のないデータに変形してしまい、様々なダメージの原因になる。

    つまり遅延した正常な完了は、特に読み込みリクエストの場合 panic() の原因になる。遅延した「エラー」完了は、その都度に通知は行うが、問題ないと考えてよい。

    disk-timeout のデフォルト値は 0 であり、無限のタイムアウトを意味する。タイムアウトは 0.1 秒単位で指定する。このオプションは DRBD 8.3.12. から有効である。

md-flushes
    メタデータデバイスでディスクフラッシュとディスクバリアを有効にする。このオプションは、デフォルトで有効である。disk-flushes のパラーメータを参照。

on-io-error handler
    DRBD が下位レベルデバイスの I/O エラーにどのように反応するかを設定する。次のポリシーが定義される:

    pass_on
        ディスクのステータスを inconsistent(不整合) にし、 I/O エラーを起こしたブロックに対応するビットマップにマークをつけ、リモートのクラスターノード上で I/O 操作を再度行う。

    call-local-io-error
        local-io-error ハンドラを呼び出す (handlers セクションを参照)。

    detach
        下位レベルデバイスを切り離し、ディスクレスモードで続行する。

read-balancing policy
    policy 定義された読み取りリクエストで、クラスターノード間に負荷分散する。次のポリシーがサポートされる: prefer-local (デフォルト), prefer-remote, round-robin, least-pending, when-congested-remote, 32K-striping, 64K-striping, 128K-striping, 256K-striping, 512K-striping and 1M-striping.

    このオプションは、DRBD 8.4.1 から有効である。

resync-after res-name/volume
    デバイスは、指定されたデバイスの後でのみ再同期する必要があることを定義する。デフォルトでは、デバイス間の順序は定義されず、すべてのデバイスが並行して再同期される。下位レベルデバイスの構成、および使用可能なネットワークとディスクの帯域幅によっては、全体の再同期プロセスが遅くなる可能性がある。このオプションは、デバイス間の依存関係チェーンやツリーを形成するために使用できる。

rs-discard-granularity byte
    rs-discard-granularity がゼロ以外の正の値に設定されている場合、DRBD はこのサイズで再同期操作をリクエストする。そのようなブロックが同期ソースノード上にゼロバイトしか含まない場合、同期ターゲットノードは、その領域に対して discard/trim/unmap コマンドを発行する。

    この値は、下位ブロックデバイスの discard 粒度によって制約される。 rs-discard-granularity が下位ブロックデバイスの discard 粒度の乗数でない場合、DRBD はそれを切り上げる。この機能は、下位ブロックデバイスが discard コマンドの後に、ゼロを読み戻す場合にのみアクティブになる。

    デフォルト値は 0 である。このオプションは 8.4.7 から有効である。

discard-zeroes-if-aligned {yes | no}
    Linux のブロックデバイスで discard/trim/unmap のサポートにはいくつかの側面がある。discard が一般的にサポートされていても、暗黙に失敗したり、discard リクエストを部分的に無視したりすることがある。デバイスは、また、マップされていないブロックからの読み込みが、定義済みのデータ（通常はゼロ）、未定義のデータ（おそらく古いデータか、ゴミ）のどちらを返すか通知する。

    異なるノードで DRBD が discard 特性が異なるデバイスによって構成されている場合、discard はデータの不一致（古いデータまたはゴミが 1 つのバックエンドに残り、別のバックエンドではゼロが残る）の原因となる。オンライン照合は、数多くの偽の差異を報告する可能性がある。たぶんほとんどのユースケース （ファイルシステム上の fstrim） では無害であるが、DRBD はそれを持つことはできない。

    安全に動作させるには、ローカルのバックエンド（プライマリ上）が "discard_zeroes_data=true" をサポートしていない場合、 discard のサポートを無効にする必要がある。受信側（セカンダリ）がマップされていなかった領域を割り当て、 "discard_zeroes_data = true" をサポートしていない場合、受信側で discard を明示的にゼロに変換する必要がある。

    discard をサポートしているのに、discard_zeroes_data = false をアナウンスするデバイス（特に LVM/DM シンプロビジョニング）がある。DM-thin の場合、チャンクサイズに合わせた discard はマップされず、マッピングされていないセクタからの読み込みはゼロを返す。ただし、discard リクエストのアライメントされていない部分ヘッドまたはテール領域は暗黙に無視する。

    整列したフル・チャンクの discard をパスし、これらの整列していない部分領域を明示的にゼロ・アウトするヘルパーを追加すると、そのようなデバイスでは discard_zeroes_data = true を効果的に達成する。

    discard-zeroes-if-aligned を yes に設定すると、 discard_zeroes_data = false を通知するバックエンドであっても DRBD は discard を使用し、 discard_zeroes_data = true を通知する。

    discard-zeroes-if-aligned を no に設定すると、それぞれのバックエンドが discard_zeroes_data = false をアナウンスする場合、DRBD は常に受信側でゼロアウトにフォールバックし、プライマリ側では discard に関して通知しない。

    私たちは、 discard_zeroes_data 設定を完全に無視していました。確立し、期待された動作を壊さず、シンプロビジョニング LV の fstrim がスペースを解放する代わりにスペースを使い果たさないためのデフォルト値は yes である。

    このオプションは 8.4.7 から有効である。

  peer-device-options セクションのパラメータ

disk キーワードでセクションを開くこともできる。

c-delay-target delay_target,
c-fill-target fill_target,
c-max-rate max_rate,
c-plan-ahead plan_time
    再同期速度を動的に制御する。これは c-plan-ahead を正の値に設定すると有効になる。c-fill-target が指定されている場合は、バッファが指定された値を満たすよう、c-delay-target が指定されている場合は、指定した遅延になるように制御する。最大帯域幅は、 c-max-rate で制限する。

    c-plan-ahead は、DRBD が再同期速度の変化にどのくらい速く適応するかを定義する。ネットワークのラウンドトリップタイム (RTT) の 5 倍以上に設定するのが望まれる。「通常の」データパスで c-fill-target の共通の値の範囲は 4K から 100K である。drbd-proxy を使用している場合は、 c-fill-target の代わりに c-delay-target を使用することを推奨する。c-delay-target は、 c-fill-target が定義されていないか、または 0 に設定されているときに使用される。c-delay-target は、ネットワークのラウンドトリップタイム (RTT) の 5 倍以上に設定するのが望まれる。c-max-rate には DRBD 間または DRBD-Proxy 間の帯域幅あるいはディスク帯域幅を指定する。

    これらのパラメータのデフォルト値は次のとおり。 c-plan-ahead = 20 （0.1 秒単位）、 c-fill-target = 0 （セクタ単位）、 c-delay-target = 1 （単位 0.1 秒）、および c-max-rate = 102400 （単位 KiB/s）。

    動的な再同期速度制御は DRBD 8.3.9 から有効である。

c-min-rate min_rate
    同期元のプライマリノードは、アプリケーションの書き込みと再同期の書き込みの配分を管理する必要がある。c-min-rate は、再同期の書き込みに使用できる帯域幅を制限する。残りの帯域幅はアプリケーションの書き込みに使用される。

    c-min-rate の値 0 は、再同期の書き込みに使用できる帯域幅に制限がないことを意味する。これにより、アプリケーションの書き込みが大幅に遅くなる可能性がある。再同期速度の最低値は 1（1 KiB/s） である。

    c-min-rate のデフォルト値は 4096 で、 単位は KiB/s である。

resync-rate rate
    DRBD が再同期に使用できる帯域幅を定義する。DRBD では、再同期中でも「通常の」アプリケーション I/O が可能である。再同期の帯域幅が大きすぎると、アプリケーション I/O が非常に遅くなる可能性がある。このパラメータは、これを避けることができる。これは、動的な再同期コントローラが無効の場合にのみ機能する。

  global セクションのパラメータ

dialog-refresh time
    DRBD init スクリプトを使用してDRBD デバイスを構成および起動することができる。これには、他のクラスタノードを待機する必要がある。待機中、init スクリプトは残りの待機時間を表示する。dialog-refresh は、そのカウントダウンの更新間隔（秒）を定義する。デフォルト値は 1 で、0 はカウントダウンを無効にする。

disable-ip-verification
    通常、DRBD は構成内の IP アドレスがホスト名と一致することを確認する。これらのチェックを無効にするには disable-ip-verification を使用する。

usage-count {yes | no | ask}
    DRBD のオンライン利用カウンター[2]で説明されているように、DRBD には、どのバージョンを使用しているかを匿名でカウントするメカニズムがある。結果は誰でも見ることができるウェブページ上で公開されている。

    このパラメータは、クラスタノードが利用カウンターに参加するかどうかを定義する。サポートされている値は yes, no, ask（ユーザーに聞く、デフォルト） である。

    DRBD の開発を推進する貴重なフィードバックを得るため、ユーザーにオンライン利用カウンターへの参加を依頼したいと考えている。

udev-always-use-vnr
    udev が drbdadm にデバイス関連のシンボリックリンクのリストを要求すると、drbdadm は、リソースに明示的な volume VNR { } 定義があるか、暗黙的なボリューム番号 0 を持つ単一のボリュームしかないかによって、異なる命名規則でシンボリックリンクを提示する：

        # implicit single volume without "volume 0 {}" block
        DEVICE=drbd<minor>
        SYMLINK_BY_RES=drbd/by-res/<resource-name>
        SYMLINK_BY_DISK=drbd/by-disk/<backing-disk-name>
        # explicit volume definition: volume VNR { }
        DEVICE=drbd<minor>
        SYMLINK_BY_RES=drbd/by-res/<resource-name>/VNR
        SYMLINK_BY_DISK=drbd/by-disk/<backing-disk-name>

    global セクションでこのパラメータを定義すると、drbdadm は常に .../VNR の部分を追加し、ボリューム定義が暗黙的であるか明示的であるかを気にしない。

    過去との互換性のために、これはデフォルトでは無効になっているが、有効にすることを推奨する。

  handlers セクションのパラメータ

after-resync-target cmd
    再同期が完了したとき、ノードの状態が Inconsistent から Consistent に変化したときに再同期ターゲットで呼び出される。このハンドラは before-resync-target ハンドラで作成したスナップショットを削除するのに使用できる。

before-resync-target cmd
    再同期の開始前に再同期ターゲットで呼び出される。このハンドラは、再同期中に下位レベルのデバイスのスナップショットを作成するために使用できる。再同期中に再同期ソースが使用できなくなった場合、スナップショットに戻すことで consistent 状態が復元される。

fence-peer cmd
    ノードが特定の対向ノード上のリソースをフェンシングする必要があるときに呼び出される。ハンドラは、DRBD が対向ノードとのコミュニケーションに使用するのと同じ通信パスを使用すべきでない。

unfence-peer cmd
    ノードが他のノードからのフェンシング制約を削除するときに呼び出される。

initial-split-brain cmd
    DRBD が対向ノードに接続し、対向ノードがローカルノードとスプリットブレイン状態にあることを検出すると呼び出される。このハンドラは自動解決されるスプリットブレインシナリオでも呼び出される。

local-io-error cmd
    下位レベルのデバイスで I/O エラーが発生したときに呼び出される。

pri-lost cmd
    ノードが現在プライマリであるにもかかわらず、 DRBD が同期先だと判断した場合に呼び出される。ノードは、プライマリ役割を断念すべきである。

pri-lost-after-sb cmd
    ノードが現在プライマリで、スプリットブレイン後の自動回復プロセスが失敗したときに呼び出される。ノードのデータは放棄されるべきである。

pri-on-incon-degr cmd
    ローカルノードはプライマリであり、ローカルの下位レベルのデバイスも対向ノードの下位レベルのデバイスも最新でないときに呼び出される。（プライマリには読み書きするデバイスがない）。

split-brain cmd
    DRBD が自動的に解決できないスプリットブレイン状況を検出した。修復のための手作業が必要なので、このハンドラは、管理者の注意を呼び出すために使用できる。

  net セクションのパラメータ

after-sb-0pri policy
    スプリットブレインが検出され、2 つのノードのいずれもプライマリでない場合の対応方法を定義する。（2 つのノードが接続されたときにスプリットブレインを検出する、スプリットブレインの決定は常に2つのノード間である） 定義されたポリシーは次のとおり:

    disconnect
        自動再同期はしない。単に切断する。

    discard-younger-primary,
    discard-older-primary
        最初（discard-younger-primary）、または最後（discard-older-primary） にプライマリなったノード から再同期する。両方のノードが独立してプライマリになった場合、 discard-least-changes ポリシーが使用される。

    discard-zero-changes
        スプリットブレイン状況が検出されてからノードの 1 つだけがデータを書き込んだ場合は、このノードからもう 1 つのノードに再同期する。両方のノードがデータを書き込んだ場合は切断する。

    discard-least-changes
        より多くの変更されたブロックを持つノードから再同期する。

    discard-node-nodename
        名前付きノードと常に再同期する。

after-sb-1pri policy
    1 つのノードがプライマリ、もう 1 つのノードをセカンダリのときに、スプリットブレインが検出された場合の対応方法を定義する。（2 つのノードが接続されたときにスプリットブレインを検出する、スプリットブレインの決定は常に2つのノード間である） 定義されたポリシーは次のとおり:

    disconnect
        自動再同期を行わず接続を切断する。

    consensus
        after-sb-0pri アルゴリズムの結果が現在のセカンダリノードのデータを破棄することになる場合、セカンダリノードのデータを破棄する。それ以外の場合は切断する。

    violently-as0p
        プライマリのデータに大きな変更がある場合でも、常に after-sb-0pri アルゴリズムの判断を採用する。このポリシーは allow-two-primaries オプションを指定し、 1 ノードファイルシステム (OCF2 や GFS ではない) を使用している場合のみ有用である。このオプションを使用すると、プライマリノードがクラッシュする可能性があり、推奨しない。

    discard-secondary
        セカンダリノード上のデータを破棄する。

    call-pri-lost-after-sb
        常に after-sb-0pri アルゴリズムの判断を採用する。プライマリノードでデータを破棄することになる場合は、 プライマリノードで pri-lost-after-sb ハンドラを呼び出す。

after-sb-2pri policy
    スプリットブレインが検出され、両方のノードがプライマリである場合の対応方法を定義する。（2 つのノードが接続されたときにスプリットブレインを検出する、スプリットブレインの決定は常に2つのノード間である） 定義されたポリシーは次のとおり:

    disconnect
        自動再同期を行わず接続を切断する。

    violently-as0p
        after-sb-1pri の violently-as0p ポリシーを参照。

    call-pri-lost-after-sb
        そのマシンがセカンダリに降格できる場合を除いて、いずれかのマシンの pri-lost-after-sb ヘルパープログラムを呼び出す。ヘルパープログラムはマシンを再起動することが期待され、ノードをセカンダリにする。どのマシンがヘルパープログラムを実行するかは、 after-sb-0pri ポリシーによって決定される。

allow-two-primaries
    DRBD デバイスを構成する最も一般的な方法は、一度に 1 つのノードのみをプライマリ（したがって書き込み可能）にすることである。

    いくつかのシナリオでは、2 つのノードを一度にプライマリにしたい場合がある。 DRBD 以外のメカニズムで、共有され複製されたデバイスへの書き込みが調整される方法を使用する必要がある。これは、OCFS2 や GFS などの共有ストレージクラスタファイルシステム、または仮想マシンイメージと仮想マシンを物理マシン間で移動できる仮想マシンマネージャを使用して実行できる。

    allow-two-primaries は、2つのノードを同時にプライマリにすることを DRBD に指示する。非分散ファイルシステムを使用する場合は、このオプションを有効にしてはならない。データ破損とノードクラッシュが発生する。

always-asbp
    通常、3 番目のノードが存在しないことが現在の UUID 値から明らかな場合のみ、スプリットブレイン発生後の修復ポリシーだけが適用される。

    このオプションを指定すると、両ノードのデータに関連性があるとして、スプリットブレイン発生後のポリシーが適用される。UUID の分析により 3 番目のノードの存在が疑われる場合には、フル同期が行われることがある。(または、なんらかの別の原因によって間違った UUID セットで判断してしまった場合)

connect-int time
    2つのノード間の接続が drbdsetup connect で構成される、DRBD はすぐに接続を確立しようとする。これが失敗すると、DRBD はconnect-int 秒後に接続を試みる。connect-int のデフォルト値は 10 秒である。

cram-hmac-alg hash-algorithm
    対向ノードの認証に使用するハッシュベースのメッセージ認証コード （HMAC） またはセキュアハッシュアルゴリズムを構成する。カーネルはいくつかの異なるアルゴリズムをサポートしており、その中にはカーネルモジュールとしてロード可能なものもある。/proc/crypto にリストされている shash アルゴリズムを参照。デフォルトで cram-hmac-alg は設定されていない。対向ノードの認証には、shared-secret も構成する必要がある。

csums-alg hash-algorithm
    通常、2 つのノードが再同期するとき、同期ターゲットは同期ソースから非同期データを要求し、同期ソースはデータを送信する。多くの使用パターンで、それらのブロックのかなりの数が実際には同一になっている。

    csums-alg アルゴリズムが指定されている場合、同期ターゲットは、非同期データの要求と、現在持っているデータのハッシュ値も送信する。同期ソースは、このハッシュ値とそれ自身のバージョンのデータを比較する。ハッシュ値が異なる場合、新しいデータを同期ターゲットに送信し、そうでない場合はデータが同じであることを通知する。これにより、必要なネットワーク帯域幅が削減されるが、CPU 使用率が高くなり、同期ターゲットの I/O が増加する可能性がある。

    csums-alg は、カーネルによってサポートされている安全なハッシュアルゴリズムの 1 つに設定できる。 /proc/crypto にリストされている shash アルゴリズムを参照。デフォルトでは、 csums-alg 設定されていない。

csums-after-crash-only
    このオプション（および上記の csums-alg） を有効にすると、プライマリクラッシュ後の最初の再同期に対してのみチェックサムベースの再同期を使用するが、その後の「ネットワーク復帰」では使用しない。

    ほとんどの場合、再同期が必要であるとマークされたブロックは実際に変更されているため、チェックサムの計算、および再同期ターゲット上のブロックの読み書きはすべてオーバーヘッドである。

    チェックサムベースの再同期の利点は、大部分がプライマリのクラッシュリカバリの後である。リカバリでは、アクティビティログでカバーされるより大きな領域が再同期が必要なものとしてマークされている。8.4.5 から導入された。

data-integrity-alg alg
    DRBD は通常、 TCP/IP プロトコルに組み込まれたデータ整合性チェックに依存するが、データ整合性アルゴリズムが設定されている場合は、さらに、このアルゴリズムを使用して、ネットワーク経由で受信したデータが送信者のものと一致することを確認する。データの整合性エラーが検出された場合、DRBD はネットワーク接続を閉じ、再接続し、再同期を行う。

    data-integrity-alg は、カーネルによってサポートされている安全なハッシュアルゴリズムの 1 つに設定できる。 /proc/crypto にリストされている shash アルゴリズムを参照。デフォルトでは、このメカニズムは無効である。

    CPU のオーバーヘッドが発生するため、本番環境でこのオプションを使用しないことを推奨する。また、「データ整合性に関する注意」も参照。

fencing fencing_policy
    フェンシングは、両方のノードがプライマリで切断されている状態を回避するための予防措置である。これはスプリットブレイン状態とも呼ばれている。DRBDは、次のフェンシングポリシーをサポートする：

    dont-care
        フェンシングのためのアクションを実行しない。これがデフォルトのポリシーである。

    resource-only
        ノードが切り離されたプライマリ状態になると、対向ノードをフェンシングしようとする。この動作は fence-peer ハンドラによって行われる。このハンドラは、レプリケーション用とは別のネットワーク経由で対向ノードにアクセスし、 そこで 'drbdadm outdate minor' の実行を想定する。

    resource-and-stonith
        ノードが切り離されたプライマリ状態になると、 DRBD はすべてのディスク I/O を停止して fence-peer ハンドラを呼び出す。このハンドラは、レプリケーション用とは別のネットワーク経由で対向ノードにアクセスし、 そこで 'drbdadm outdate minor' の実行を想定する。これが実行できない場合、 STONITH 機能を使って対向ノードを強制排除する。これらが完了したら、ディスク I/O を再開する。fence-peer ハンドラが失敗した場合、 'drbdadm resume-io' コマンドでディスク I/O を再開できる。

ko-count number
    セカンダリノードが書き込みリクエストを timeout 内で ko-count 回以上失敗した場合、そのセカンダリノードはクラスタから排除される。プライマリノードは、このセカンダリノードへの接続をスタンドアロンに設定する。この機能を無効にするには、明示的に 0 に設定する必要がある。デフォルトはバージョン間で変更されている。8.4 は 7 がデフォルト値である。

max-buffers number
    再同期、オンライン照合を行う際に、受信側で DRBD マイナーデバイスあたりに使用するメモリを制限する。単位は PAGE_SIZE で、ほとんどのシステムで 4KiB である。設定できる最小値は 32 (=128 KiB) でハードコードされている。これらバッファはディスクからの読み書きの際にデータブロックを保持するために使用される。輻輳時のデッドロックを回避するために、この設定はハード制限というよりは閾値として使用される。最大バッファページが使用されると、プールからのそれ以上の割り当てが制限される。受信側の I/O バックエンドに余裕がない場合には、 max-buffers を増やすとよい。

max-epoch-size number
    書き込みバリアを発行する前に DRBD が発行できる書き込みリクエストの最大数を定義する。デフォルト値は 2048 で、最小値は 1 、最大値は 20000 である。このパラメータを 10 未満の値に設定すると、パフォーマンスが低下する可能性がある。

on-congestion policy,
congestion-fill threshold,
congestion-extents threshold
    デフォルトでは、 TCP 送信キューが一杯になると、 DRBD は書き込みをブロックする。これにより、より多くのバッファスペースが再び利用可能になるまで、アプリケーションがさらに書き込みリクエストを生成するのを防ぐ。

    DRBD を DRBD-proxy と一緒に使用する場合は、 送信キューがいっぱいになる前に DRBD を AHEAD/BEAIND モードに切り替える pull-ahead on-congestion ポリシーといっしょに使用することが望ましい。DRBD は、自身と対向ノードとの間の違いをビットマップに記録するが、もはや対向ノードに複製はしない。十分なバッファスペースが再び利用可能になると、ノードは対向ノードと同期を再開し、通常の複製に戻る。

    これには、キューがいっぱいになってもアプリケーションの I/O をブロックしないという利点があるが、対向ノードの同期が大幅に遅れるという欠点もある。また、再同期している間、対向ノードは inconsistent(不整合) になる。

    利用可能な congestion ポリシーは block (デフォルト), pull-ahead である。congestion-fill は、この接続で動作中に許可されているデータ量を定義する。デフォルト値は 0 で、この輻輳制御のメカニズムを無効にする（最大 10 ギガバイト）。congestion-extents は、 AHEAD/BEAIND モードに切り替える前にアクティブにできるビットマップエクステントの数を定義する。 al-extents と同じデフォルトと制限をもつ。congestion-extents は、 al-extents より小さい値に設定した場合のみ有効である。

    AHEAD/BEHIND モードは DRBD 8.3.10 から有効である。

ping-int interval
    対向ノードへの TCP/IP 接続で ping-int 秒間に何も通信が行われなかった場合、DRBD はキープアライブパケットを送信して、対向ノードまたはネットワーク接続の失敗がすぐに検出されるようにする。デフォルト値は 10 秒で、最小値は 1 、最大値は 120 秒である。単位は秒である。

ping-timeout timeout
    キープアライブパケットへの応答のタイムアウトを定義する。対向ノードが ping-timeout 間で応答しない場合、 DRBD は接続を終了し、再接続しようとする。デフォルト値は 0.5 秒で、最小値は 0.1 秒、最大値は 3 秒である。単位は 10 分の 1 秒である。

socket-check-timeout timeout
    DRBD-Proxy を使っていて大量のバッファを確保する必要がある環境では ping-timeout に非現実的な大きな値を指定しなければならないことがある。TCP コネクションが開始したときの安定するのを待つ局面でも、 DRBD はデフォルトで ping-timeout を使ってしまう。DRBD-Proxy は通常、同じデータセンターに配置されているため、長い待機時間は DRBD の接続プロセスを妨げる可能性がある。

    このような場合、socket-check-timeout に DRBD と DRBD-Proxy 間の round trip time(RTT) を設定するとよい。たいていの場合 1 である。

    デフォルトの単位は 10 分の 1 秒である。デフォルト値は 0 で socket-check-timeout 値の代わりに ping-timeout 値を使用する。8.4.5 から導入された。

protocol name
    この接続で指定されたプロトコルを使用する。サポートされているプロトコルは次のとおり:

    A
        DRBD デバイスへの書き込みは、ローカルディスクへの書き込みと TCP/IP 送信バッファに到達した時点で完了とする。

    B
        DRBD デバイスへの書き込みは、ローカルディスクへの書き込みと、すべての対向ノードが書き込みリクエストを受信をした時点で完了とする。

    C
        DRBD デバイスへの書き込みは、ローカルディスクとすべてのリモートディスクへの書き込みが終わった時点で完了とする。

rcvbuf-size size
    TCP/IP 受信バッファのサイズを指定する。0（デフォルト） を指定すると、バッファサイズが動的に調整される。このパラメータは通常設定する必要はないが、最大 10MiB まで設定できる。デフォルトの単位はバイトである。

rr-conflict policy
    このオプションは、再同期決定の結果がクラスタ内の現在のロール割り当てと互換性がない場合を解決するのに役立つ。定義されたポリシーは次のとおり:

    disconnect
        自動再同期を行わず接続を切断する。

    violently
        プライマリノードへの再同期が許可され、ブロックデバイス上のデータがノードの 1 つに対して安定しているという前提に反す。このオプションは危険であり、使ってはならない。

    call-pri-lost
        どこか 1 つのマシンで pri-lost ハンドラを呼び出す。ハンドラはマシンを再起動することが期待され、ノードをセカンダリにする。

shared-secret secret
    対向ノードの認証に使用する共有秘密鍵を設定する。secret は 64 文字までで指定する。対向ノードの認証には、 cram-hmac-alg も設定する必要がある。

sndbuf-size size
    TCP/IP 送信バッファのサイズを指定する。DRBD 8.0.13/8.2.7 以降、 0 （デフォルト） を指定すると、バッファサイズが動的に調整される。32 KiB 未満の値は、この接続のスループットに有害である。大きなバッファサイズは、プロトコル A が遅延の大きいネットワークで使用される場合に特に有用である。サポートされる最大値は 10 MiB である。

tcp-cork
    デフォルトで、DRBD は TCP_CORK ソケットオプションを使用して、カーネルが部分的なメッセージを送信しないようにする。その結果、ネットワーク上のパケット量が少なくなり、サイズが大きくなる。一部のネットワークスタックでは、この最適化で悪化する可能性がある。tcp-cork を使用してこの最適化を無効にすることができる。

timeout time
    ネットワークを介した応答のタイムアウトを定義する。対向ノードが指定された timeout 時間内で応答を送信しない場合、対向ノードが死んだと判断して TCP/IP コネクションを切断する。タイムアウト値は、 connect-int、ping-int より小さい値でなければならない。デフォルトは 6 秒である。値は 10 分の 1 秒単位で指定する。

use-rle
    クラスタノード上の複製された各デバイスには、それぞれの対向ノードデバイス用の個別のビットマップがあある。このビットマップは、ローカルデバイスと対向ノードデバイスの違いを追跡するために使用される。クラスタの状態によっては、デバイスのビットマップ、対向ノードデバイスのビットマップ、または両方のビットマップにディスクが異なるとマークできる。2つのクラスタノードが接続すると、相互のビットマップを交換し、ローカルと対向ノードのビットマップを検査して全体的な違いを判断する。

    非常に大きなデバイスのビットマップは比較的大きいが、通常、ランレングス符号化を使用して非常にうまく圧縮される。これにより、ビットマップ転送の時間と帯域幅を節約できる。

    use-rle は run-length エンコーディングを使用するかどうかを指定する。DRBD 8.4.0 以降デフォルトで有効である。

verify-alg hash-algorithm
    オンライン照合（drbdadm verify） は、ディスクブロックのチェックサム（すなわち、ハッシュ値）を計算して比較し、それらが異なるかどうかを検出する。verify-alg は、これらのチェックサムに使用するアルゴリズムを決定する。オンライン照合を使用するには、カーネルでサポートされている安全なハッシュアルゴリズムの1つに設定する必要がある。 /proc/crypto にリストされている shash アルゴリズムを参照。

    低負荷の期間（例えば、月に1回）で定期的にオンライン照合をスケジュールすることを推奨する。また、「データ整合性に関する注意」も参照。

  on セクションのパラメータ

address [address-family] address:port
    接続エンドポイントのアドレスファミリ、アドレス、およびポートを定義する。

    アドレスファミリは ipv4, ipv6, ssocks (Dolphin Interconnect Solutions の「スーパーソケット」), sdp (Infiniband Sockets Direct Protocol), sci がサポートされる (sci は ssocks の別名である)。アドレスファミリが指定されていない場合、 ipv4 が仮定される。ipv6 アドレスファミリ以外は、 address に IPv4 アドレス表記を使用する（たとえば、1.2.3.4）。ipv6 アドレスは角括弧で囲み、 IPv6 アドレス表記法を使用する（たとえば、 [fd01：2345：6789：abcd :: 1]）。ポートは常に 1〜65535 の 10 進数で指定される。

    各ホストで、ポート番号は各アドレスごとに一意でなければならない。ポートは共有できない。

node-id value
    クラスタ内のノードの一意のノード識別子を定義する。ノード識別子は、ネットワークプロトコル内の個々のノードを識別し、ビットマップスロットをメタデータ内のノードに割り当てるために使用される。

    ノード識別子は、クラスタがダウンしている場合にのみ、クラスタ内で再割り当てすることができる。構成内およびデバイスメタデータ内のノード識別子が、すべてのホスト上で一貫して変更されることが不可欠である。メタデータを変更するには、 drbdmeta dump-md でダンプし、ビットマップスロット割り当てを調整し、drbdmeta restore-md でメタデータを更新する。

    node-id パラメータは DRBD 9 以降存在する。その値の範囲は 0 から 16 である。デフォルトはない。

  options セクションのパラメータ (リソース options)

auto-promote bool-value
    書き込みのためにデバイスをマウントまたはオープンする前に、リソースをプライマリに昇格させる必要がある。

    DRBD 9 より前は、これを明示的に行う必要があった（ "drbdadm primary"）。DRBD 9 以降、 auto-promote を使用すると、デバイスの 1 つが書き込み用にマウントまたはオープンされるときに、リソースをプライマリに自動的に昇格させることができる。すべてのデバイスがアンマウントされるか、オープンしているユーザがいなくなると、すぐにリソースの役割がセカンダリになる。

    自動プロモーションは、クラスタの状態が許可する場合にのみ成功する（つまり、明示的な drbdadm primary コマンドが成功するなら）。それ以外の場合は、DRBD 9 より前と同様にデバイスのマウントまたはオープンが失敗する: mount(2) システムコールは、 errno を EROFS（読み取り専用ファイルシステム） に設定して失敗する。open(2) システムコールは、 errno を EMEDIUMTYPE（メディアタイプが間違っている） に設定してが失敗する。

    auto-promote の設定に関係なく、デバイスが明示的に昇格された場合 （drbdadm primary）、明示的に降格する必要がある（drbdadm secondary）。

    auto-promote は DRBD 9.0.0 から有効で、デフォルトは yes である。

cpu-mask cpu-mask
    DRBD のカーネルスレッドに CPU アフィニティマスクを設定する。CPU マスクは 16 進数で指定する。デフォルト値は 0 で、スケジューラがどの CPU 上でカーネルスレッドを実行するかを決定する。システムに存在しない cpu-mask CPU番号は無視される。

on-no-data-accessible policy
    要求されたデータがローカルまたはリモートで使用できない場合に（たとえば、すべてのディスクに障害が発生した場合など）、どのように I/O 要求を処理するかを決定する。定義されたポリシーは次のとおり:

    io-error
        errno を EIO に設定してシステムコールは失敗する。

    suspend-io
        リソースは I/O を中断する。下位レベルのデバイスを接続（再接続）したり、データにアクセスできる対向ノードに接続したり、drbdadm resume-io res で DRBD に I/O を再開させたりすることで、 再開できる。データがない場合、 I/O を強制的に再開すると、 io-error ポリシーと同じ結果になる。

    この設定は、DRBD 8.3.9 から有効である。デフォルトのポリシーは io-error である。

peer-ack-window value
    各ノード上の各デバイスのために、DRBD は、ローカルデータと各対向ノードデバイスのリモートデータの差分のビットマップを維持する。例えば、それぞれが単一デバイスを有する 3 ノード構成 （ノード A、B、C） において、各ノードは、各対向ノードに対して 1 つのビットマップを維持する。

    ノードが書き込みリクエストを受け取ると、書き込みノードのビットマップを更新する方法はわかるが、ノード間のビットマップを更新する方法はわからない。この例では、書き込みリクエストがノード A から B および C に伝搬するとき、ノード B および C はノード A と同じデータを有するが、両方が同じデータを有するか不明である。

    是正措置として、書き込みノードは、時には、相手との間にどのような状態があるかを示すピアツーピアパケットを対向ノードに送信する。

    peer-ack-window は、peer-ack パケットを送信する前に、プライマリノードが送信するデータ量を指定する。値が小さいとネットワークトラフィックが増加する。値が大きいとネットワークトラフィックは減少するが、セカンダリノードのメモリ消費量が大きくなり、プライマリノードの障害後に、セカンダリノード間の再同期時間が長くなる。（注：peer-ack パケットは、他の理由でも送信される場合がある。たとえば、メンバーシップの変更または peer-ack-delay タイマーの満了など）。

    peer-ack-window のデフォルト値は、2 MiB であり、単位はセクタである。このオプションは 9.0.0 から有効である。

peer-ack-delay expiry-time
    最後に終了した書き込みリクエストの後に expiry-time 間、新しい書き込みリクエストが発行されない場合、peer-ack パケットが送信される。タイマーが満了する前に新しい書き込みリクエストが発行されると、タイマーは expiry-time にリセットされる。（注：peer-ack パケットは、他の理由でも送信される場合がある。たとえば、メンバーシップの変更または peer-ack-window オプションなど）。

    このパラメータは、リモートノードの再同期動作に影響を与える可能性がある。対向ノードは、 AL-extent のロックを解除する peer-ack を受信するまで待つ必要がある。対向ノード間の再同期操作は、これらのロックを待つ必要がある。

    peer-ack-delay のデフォルト値は、100 ミリ秒であり、単位はミリ秒である。このオプションは 9.0.0 から有効である。

quorum value
    有効にすると、レプリケートされたデータセットを変更するために、クラスタパーティションはクォーラムを必要とする。つまり、クラスタパーティション内のノードは、クラスタパーティションにクォーラムがある場合にのみプライマリに昇格できる。昇格すべきノードにディスクが直接接続されているすべてのノードが対象である。プライマリノードが書き込みリクエストを実行する必要があるが、クラスタパーティションがクォーラムを失った場合、 I/O をフリーズするか、または書き込みリクエストを拒否する（on-no-quorum の設定に依存）。クォーラムが失われると、プライマリは常に quorum-lost ハンドラを呼び出す。ハンドラは通知のためのものであり、リターンコードは無視される。

    オプションの値は、 off, majority, all, または数値である。数値を設定する場合は、値がノード数の半分を超えていることを確認すること。クォーラムはデータの不一致を回避するメカニズムであり、2 つ以上の複製が存在する場合にフェンシングの代わりに使用されるときがある。デフォルトは off である。

    切断されたノードがすべて outdated(無効) としてマークされている場合、パーティションのサイズに関係なく、常にクォーラムを持つ。つまり、すべてのセカンダリノードを正常に切断すると、1 つのプライマリが動作し続ける。1 つのセカンダリが切断された瞬間に、切断されたすべてのセカンダリノードがパーティションを形成すると仮定する。パーティションが他のパーティションよりも小さい場合、この時点ではクォーラムは失われる。

    ディスクレスノードがクォーラムを常に取得できるようにする場合、majority, all オプションは使用しないことを推奨する。クラスタ内のディスクフルノードの完全な数を決定するための DBRD のヒューリスティックな方法は正確でないため、絶対数を指定することを推奨する。

    クォーラムの実装は、DRBD カーネルドライバのバージョン 9.0.7 から有効である。

quorum-minimum-redundancy value
    このオプションは、パーティションがクォーラムを獲得できるように UpToDate のディスクを持つノードの必要最小限の数を設定する。これは、素の quorum とは異なる要件である。

    オプションの値は、 off, majority, all, または数値である。数値を設定する場合は、値がノード数の半分を超えていることを確認すること。

    ディスクレスノードがクォーラムを常に取得できるようにする場合、majority, all オプションは使用しないことを推奨する。クラスタ内のディスクフルノードの完全な数を決定するための DBRD のヒューリスティックな方法は正確でないため、絶対数を指定することを推奨する。

    このオプションは、DRBD カーネルドライバのバージョン 9.0.10 から有効である。

on-no-quorum {io-error | suspend-io}
    デフォルトで DRBD はクォーラムを失うと、デバイス上の I/O をフリーズする。on-no-quorum を io-error に設定すると、クォーラムが失われた場合、すべての I/O 操作をエラーで完了する。

    on-no-quorum オプションは、DRBD カーネルドライバのバージョン 9.0.8 から有効である。

  startup セクションのパラメータ

このセクションのパラメータは、DRBD init スクリプトでシステム起動時の DRBD の動作を定義する。システムが起動し、実行後には効果がない。

degr-wfc-timeout timeout
    システムが停止したとき、クラスタが単一ノードで構成されている場合、すべてのピアが接続されるまで待機する時間を定義する。このパラメータは通常、 wfc-timeout より小さい値に設定する。再起動前に到達できなかった対向ノードが再起動後に到達できる可能性は低いため、待機が助けになる可能性は低いということである。

    タイムアウトは秒単位で指定する。デフォルト値は 0 であり、無限のタイムアウトを意味する。wfc-timeout パラーメータも参照。

outdated-wfc-timeout timeout
    システムが停止したとき、すべての対向ノードが outdated(無効) であった場合、すべての対向ノードが接続されるまで待機する時間を定義する。このパラメータは通常、 wfc-timeout より小さい値に設定する。outdated(無効) の対向ノードがその間にプライマリになることはできないので、以前に生存していたノードを待つ必要がないということである。

    タイムアウトは秒単位で指定する。デフォルト値は 0 であり、無限のタイムアウトを意味する。wfc-timeout パラーメータも参照。

stacked-timeouts
    スタックデバイスでは、通常は wfc-timeout および degr-wfc-timeout は無視される。これらのタイムアウト値には、代わりにconnect-int の 2 倍のタイムアウト値が使われる。stacked-timeouts パラメータを指定すると、DRBD はスタックデバイスに対しても wfc-timeout および degr-wfc-timeout にもとづいて動作するようになる。スタックデバイスの対向ノードが多くの場合に利用できないケースや対向ノードがプライマリにならない場合に限って、このオプションを指定すべきである。このパラメータを誤って使用すると、スプリットブレインにつながる可能性がある。

wait-after-sb
    このパラメータは、スプリットブレイン状況が検出された場合でも、DRBD が init スクリプトで待機し続けるため、ノード間の接続が拒否される。

wfc-timeout timeout
    すべての対向ノードが接続されるまで init スクリプトが待機する時間を定義する。これは、DRBD リソースを管理できないクラスタマネージャと組み合わせて使用する場合に便利である。クラスタマネージャが起動すると、DRBD リ ソースはすでに起動して実行されている。Pacemaker などのより優れたクラスターマネージャを使用すると、クラスターマネージャが DRBD リソースを制御できるようになる。タイムアウトは秒単位で指定する。デフォルト値は 0 であり、無限のタイムアウトを意味する。degr-wfc-timeout パラーメータも参照。

  volume セクションのパラメータ

device /dev/drbdminor-number
    複製されたブロックデバイスのデバイス名とマイナー番号を定義する。これは、アプリケーションがアクセスするデバイスである。ほとんどの場合、デバイスは直接使用されるのではなく、ファイルシステムとして使用される。このパラメータは必須で、標準のデバイス命名規則が適用される。

    このデバイスに加えて、udev は、 /dev/drbd/by-res/resource/volume, /dev/drbd/by-disk/lower-level-device シンボリックリンクをデバイスに作成する。

disk {[disk] | none}
    DRBD が実際のデータを格納するために使用する下位ブロックデバイスを定義する。複製された DRBD デバイスが設定されている間は、下位レベルのデバイスを直接使用してはならない。読み取りアクセス専用のツール dumpe2fs(8) や同様のツールも許可されない。キーワード none は、下位ブロックデバイスが設定されていないことを指定する。下位レベルデバイスの継承もこれにより上書きされる。

meta-disk internal,
meta-disk device,
meta-disk device [index]
    複製されたブロックデバイスのメタデータが存在する場所を定義する。 internal は、下位レベルのデバイスにデータとメタデータの両方が含まれていることを意味する。別のデバイスに格納されている場合は、これを指定する。

    index を指定すると、複数のレプリケートされたデバイスが同じメタデータデバイスを共有でき、それぞれ別のインデックスを使用する。各インデックスは 128 MiB のデータを占有し、2 つのクラスタノードで最大 4 TiB の複製されたデバイスサイズに対応する。メタデータデバイスは共有しないで、必要に応じて lvm ボリュームマネージャを使用してメタデータデバイスを作成することを推奨する。

    index を指定しない場合、下位レベルのデバイスのサイズによってメタデータのサイズが決定される。必要なサイズは 36 KiB +（下位デバイスのサイズ） / 32K *（ノード数-1） である。もし メタデータデバイスがそれよりも大きい場合、余分なスペースは使用されない。

    このパラメータは、disk が none 以外に設定されている場合は必須で、disk が none に設定されている場合は無視される。disk パラメータなしの meta-disk パラメータは使用できない。

データ整合性に関する注意

DRBD は、データの整合性チェックのための 2 つの異なるメカニズムをサポートする。 data-integrity-alg ネットワークパラメータを使用すると、ネットワーク経由で送信されたデータにチェックサムを追加できる。もう １ つのオンライン照合メカニズム（drbdadm verify, verify-alg パラメータ）を使用すると、ディスク上のデータの違いをチェックできる。

両方のメカニズムは、データが I/O 中に変更された場合（つまり、ネットワークを介して送信されている間、またはディスクに書き込まれている間）、誤検出を引き起こす可能性がある。これは常に問題を示すとは限らない。たとえば、一部のファイルシステムやアプリケーションでは、特定の操作のために I/O 下のデータを変更する。スワップ領域も I/O 中に変更される可能性がある。

ネットワークデータの整合性チェックは、データの送信後に送信側のチェックサムを検証することによって、 I/O 中のデータ変更を識別しようとする。不一致が検出された場合は、エラーを記録する。また、受信側も、不一致を検出するとエラーをログに記録する。したがって、受信側でのみ記録されるエラーはネットワーク上のエラーを示し、両側に記録されたエラーは I/O でのデータ変更を示す。

直近の例 (2007 年) では系統的なデータ損傷のケースがあり、特定の種類のギガビット NIC の TCP オフロードエンジンとドライバのバグが原因であった。データの破損が、コアメモリからカードへの DMA 転送で発生していた。TCP チェックサムはカード上で計算されたため、 TCP/IP プロトコルチェックサムではこの問題を検出できませんでした。

VERSION

このドキュメントは DRBD バージョン 9.0.0 向けに改訂されている。

AUTHOR

Written by Philipp Reisner <philipp.reisner@linbit.com> and Lars Ellenberg <lars.ellenberg@linbit.com>.

REPORTING BUGS

Report bugs to <drbd-user@lists.linbit.com>.

COPYRIGHT

Copyright 2001-2018 LINBIT Information Technologies, Philipp Reisner, Lars Ellenberg. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

SEE ALSO

drbd(8), drbdsetup(8), drbdadm(8), DRBD User's Guide[1], DRBD Web Site[3]

NOTES

1.  DRBD User's Guide
    http://www.drbd.org/users-guide/

2.  オンライン利用カウンター
    http://usage.drbd.org

3.  DRBD Web Site
    http://www.drbd.org/