第11章 一般的な管理作業

目次

11.1. DRBDの設定
11.1.1. 下位レベルストレージの準備
11.1.2. ネットワーク構成の準備
11.1.3. リソースの設定
11.1.4. ネットワークコネクションの定義
11.1.5. トランスポートプロトコルの設定
11.1.6. リソースを初めて有効にする
11.1.7. デバイスの初期同期
11.1.8. トラックベースのレプリケーションの使用
11.1.9. 4ノードでの構成例
11.2. DRBDのステータスを確認する
11.2.1. drbdmon でステータスを取得する
11.2.2. drbdtop でDRBDのステータス取得し対話する
11.2.3. /proc/drbd でのステータス情報
11.2.4. drbdadm でのステータス情報
11.2.5. drbdsetup events2 を使用した一回のみ、またはリアルタイムでの監視
11.2.6. コネクションステータス
11.2.7. 複製ステータス
11.2.8. リソースのロール
11.2.9. ディスク状態
11.2.10. 接続情報データ
11.2.11. パフォーマンス指標
11.3. リソースの有効化と無効化
11.3.1. リソースの有効化
11.3.2. リソースを無効にする
11.4. リソースの再設定
11.5. リソースの昇格と降格
11.6. 基本的な手動フェイルオーバ
11.7. DRBDのアップグレード
11.7.1. 概要
11.7.2. リポジトリのアップデート
11.7.3. DRBDの状態を確認する
11.7.4. クラスタを停止する
11.7.5. パッケージのアップグレード
11.7.6. 新しいカーネルモジュールのロード
11.7.7. 設定ファイルの移行
11.7.8. メタデータの変更
11.7.9. DRBDを再び起動する
11.7.10. DRBD9からDRBD9
11.8. デュアルプライマリモードを有効にする
11.8.1. 永続的なデュアルプライマリモード
11.8.2. 一時的なデュアルプライマリモード
11.9. オンラインデバイス照合の使用
11.9.1. オンライン照合を有効にする
11.9.2. オンライン照合の実行
11.9.3. 自動オンライン照合
11.10. 同期速度の設定
11.10.1. 同期速度の計算
11.10.2. 可変同期速度設定
11.10.3. 永続的な固定同期速度の設定
11.10.4. 同期に関するヒント
11.11. チェックサムベース同期の設定
11.12. 輻輳ポリシーと中断したレプリケーションの構成
11.13. I/Oエラー処理方針の設定
11.14. レプリケーショントラフィックの整合性チェックを設定
11.15. リソースのサイズ変更
11.15.1. オンライン拡張
11.15.2. オフライン拡張する
11.15.3. オンライン縮小
11.15.4. オフライン縮小
11.16. 下位デバイスのフラッシュを無効にする
11.17. スプリットブレイン時の動作の設定
11.17.1. スプリットブレインの通知
11.17.2. スプリットブレインからの自動復旧ポリシー
11.18. スタック3ノード構成の作成
11.18.1. デバイススタックの留意事項
11.18.2. スタックリソースの設定
11.18.3. スタックリソースを有効にする
11.19. 永続的なディスクレスノード
11.20. データ再配置
11.20.1. ビットマップスロットの用意
11.20.2. 新しいノードの用意と有効化
11.20.3. 初期同期の開始
11.20.4. 接続確認
11.20.5. 初期同期後
11.20.6. クリーニング
11.20.7. まとめと他のステップ
11.21. クォーラム設定
11.21.1. 保証された最低限の冗長化
11.21.2. クォーラムを失った時の動作
11.21.3. タイブレーカーとしてのディスクレスノードを使用

この章では一般的なオペレーションでの管理作業を説明します。トラブルシューティングについては扱いません。トラブルシューティングについては13章トラブルシューティングとエラーからの回復を参照ください。

11.1. DRBDの設定

11.1.1. 下位レベルストレージの準備

DRBDをインストールしたら、両方のクラスタノードにほぼ同じ容量の記憶領域を用意する必要があります。これがDRBDリソースの 下位レベルデバイス になります。システムの任意のブロックデバイスを下位レベルデバイスとして使用できます。たとえば、次のようなものがあります。

  • ハードドライブのパーティション(または物理ハードドライブ全体)
  • ソフトウェアRAIDデバイス
  • LVM論理ボリュームまたはLinuxデバイスマッパインフラストラクチャによって構成されるその他のブロックデバイス
  • システム内のその他のブロックデバイス

リソースを スタッキング(積み重ね) することもできます。つまり、DRBDデバイスを他のDRBDデバイスの下位レベルのデバイスとして利用することができます。リソースの積み重ねにはいくつかの注意点があります。詳しくは「スタック3ノード構成の作成」を参照ください。

[注記]注記

ループデバイスをDRBDの下位レベルデバイスとして使用することもできますが、デッドロックの問題があるためお勧めできません。

DRBDリソースを作成する前に、そのストレージ領域を空にしておく 必要はありません 。DRBDを使用して、非冗長のシングルサーバシステムから、2ノードのクラスタシステムを作成することは一般的なユースケースですが、いくつか重要な注意点があります。(その場合には「DRBDメタデータ」を参照ください)

本ガイドの説明は、次のようなとてもシンプルな構成を前提としています。

  • 両ホストには使用可能な(現在未使用の) /dev/sda7 というパーティションがある。
  • 内部メタデータを使用する。

11.1.2. ネットワーク構成の準備

必須要件ではありませんが、DRBDによるレプリケーションの実行には、専用接続を使用することをお勧めします。この書き込みには、ギガビットイーサネット同士をケーブルで直結した接続が最適です。DRBDをスイッチを介して使用する場合には、冗長コンポーネントと bonding ドライバ(active-backup モードで)の使用を推奨します。

一般に、ルータを介してDRBDレプリケーションを行うことはお勧めできません。スループットと待ち時間の両方に悪影響を及ぼし、パフォーマンスが大幅に低下します。

ローカルファイアウォールの要件として重要な点は、通常、DRBDは7788以上のTCPポートを使用し、それぞれのTCPリソースが個別のTCPポート上で待機するということです。DRBDは 2つ のTCP接続を使用します。これらの接続が許可されるようにファイアウォールを設定する必要があります。

SELinuxやAppArmorなどのMAC (Mandatory Access Control)スキーマが有効な場合は、ファイアウォール以外のセキュリティ要件も考慮する場合があります。DRBDが正しく機能するように、 必要に応じてローカルセキュリティポリシーを調整してください。

また、DRBDに使用するTCPポートを別のアプリケーションが使用していないことも確認してください。

現時点では1つのDRBDリソースに複数のTCPコネクション・ペアを設定することはできません。DRBD接続に負荷分散や冗長性が必要な場合は、イーサネットレベルで簡単に実現できます(この場合も bonding ドライバを使用してください)。

本ガイドの説明は、次のようなとてもシンプルな構成を前提としています。

  • 2つのDRBDホストそれぞれに、現在使用されていないネットワークインタフェース eth1 が存在する(IPアドレスはそれぞれ 10.1.1.3110.1.1.32)。
  • どちらのホストでも他のサービスがTCPポート7788〜7799を使用していない。
  • ローカルファイアウォール設定は、これらのポートを介したホスト間のインバウンドとアウトバウンドの両方のTCP接続を許可する。

11.1.3. リソースの設定

DRBDのすべての機能は、設定ファイル /etc/drbd.conf で制御されます。通常、この設定ファイルは、次のような内容となっています。

include "/etc/drbd.d/global_common.conf";
include "/etc/drbd.d/*.res";

通例では、/etc/drbd.d/global_common.conf にはDRBD設定の globalcommon セクションが含まれます。また、.res ファイルには各 リソース セクションが含まれます。

drbd.confinclude ステートメントを使用せずにすべての設定を記載することも可能です。しかし、設定の見やすさの観点から、複数のファイルに分割することをお勧めします。

いずれにしても drbd.conf や、その他の設定ファイルは、すべてのクラスタノードで 正確に同じ である必要があります。

DRBDのソースtarファイルの scripts サブディレクトリに、サンプル設定ファイルがあります。バイナリインストールパッケージの場合、サンプル設定ファイルは直接 /etc にインストールされるか、/usr/share/doc/packages/drbd などのパッケージ固有の文書ディレクトリにインストールされます。

このセクションは、DRBDを稼働させるために理解しておく必要のある設定ファイルの項目についての説明です。設定ファイルの構文と内容の詳細については drbd.conf マニュアルページを参照ください。

11.1.3.1. 設定例

本ガイドでの説明は、前章であげた例をもとにする最小限の構成を前提にしています。

シンプルなDRBD構成例 (/etc/drbd.d/global_common.conf). 

global {
  usage-count yes;
}
common {
  net {
    protocol C;
  }
}

シンプルなDRBDリソースの構成例 (/etc/drbd.d/r0.res). 

resource r0 {
  on alice {
    device    /dev/drbd1;
    disk      /dev/sda7;
    address   10.1.1.31:7789;
    meta-disk internal;
  }
  on bob {
    device    /dev/drbd1;
    disk      /dev/sda7;
    address   10.1.1.32:7789;
    meta-disk internal;
  }
}

この例では、DRBDが次のように設定されます。

  • DRBDの使用状況の統計をオプトインとして含める(usage-count参照)。
  • 特に他の指定がない限り完全に同期したレプリケーションを使用するようにリソースを設定する(プロトコルC)。
  • クラスタには2つのノード alicebob がある。
  • r0 という名前のリソース(名前は自由に設定可能)があり /dev/sda7 を下位レベルデバイスとして使用し、また、内部メタデータを構成する。
  • リソースはネットワーク接続にTCPポート7789を使用し、それぞれIPアドレス10.1.1.31と10.1.1.32にバインドされる(これが暗黙的に使用するネットワークコネクションを定義する)。

暗黙的に、上記の設定はリソースの1つのボリュームを作成し、番号 ゼロ(0) が付与されます。1つのリソースに複数のボリュームを設定する場合には、次のようにします(両ノードで下位デバイスとして同レベルでストレージブロックデバイスを使用する場合)。

複数ボリュームのDRBDリソース構成例(/etc/drbd.d/r0.res). 

resource r0 {
  volume 0 {
    device    /dev/drbd1;
    disk      /dev/sda7;
    meta-disk internal;
  }
  volume 1 {
    device    /dev/drbd2;
    disk      /dev/sda8;
    meta-disk internal;
  }
  on alice {
    address   10.1.1.31:7789;
  }
  on bob {
    address   10.1.1.32:7789;
  }
}

[注記]注記

ボリュームは既存のデバイスの動作中にも追加できます。「新しいDRBDボリュームを既存のボリュームグループへ追加する」をご参照ください。

11.1.3.2. global セクション

このセクションは設定の中で1回しか使用できません。通常この設定は /etc/drbd.d/global_common.conf ファイルに記述します。設定ファイルが1つの場合は、設定ファイルの一番上に記述します。このセクションで使用できるオプションはわずかですが、ほとんどのユーザーの場合、必要なのは次の1つだけです。

usage-countDRBDプロジェクトはさまざまなバージョンのDRBDの使用状況について統計を取ります。これは、システムに新規のDRBDバージョンがインストールされるたびに、HTTPサーバに接続することにより実行されます。これを無効にするには、 usage-count no; を指定します。デフォルトは usage-count ask; で、 DRBDをアップグレードするたびにプロンプトが表示されます。

DRBDの使用状況の統計は公開されています。http://usage.drbd.orgを参照ください。

11.1.3.3. common セクション

このセクションで、各リソースに継承される設定を簡単に定義できます。通常この設定は /etc/drbd.d/global_common.conf に指定します。ここで定義するオプションは、リソースごとに定義することもできます。

common セクションは必須ではありませんが、複数のリソースを使用する場合は、記述することを強くお勧めします。これにより、オプションを繰り返し使用することによって設定が複雑になることを回避できます。

上の例では net { protocol C; }common セクションで指定されているため、設定されているすべてのリソース(r0 含む)がこのオプションを継承します。ただし、明示的に別の protocol オプションが指定されている場合は除きます。使用可能なその他の同期プロトコルについては、「レプリケーションのモード」を参照してください。

11.1.3.4. resource セクション

各リソースの設定ファイルは、通常 /etc/drbd.d/resource.res という名前にします。定義するDRBDリソースは、設定ファイルでresource nameを指定して名前を付ける必要があります。通常は文字または数字、アンダースコアのみを使用します。

各リソースには各クラスタノードに最低2つの on <host> サブセクションも必要です。その他すべての設定は common セクション(記述した場合)から継承されるか、DRBDのデフォルト設定から取得されます。

さらに、オプションの値が両方のホストで等しい場合は、直接 resource セクションで指定することができます。このため、設定例は次のように短くすることができます。

resource r0 {
  device    /dev/drbd1;
  disk      /dev/sda7;
  meta-disk internal;
  on alice {
    address   10.1.1.31:7789;
  }
  on bob {
    address   10.1.1.32:7789;
  }
}

11.1.4. ネットワークコネクションの定義

現時点では、DRBD9の通信リンクはフルメッシュである必要があります。つまり、全リソース全ノードが他の全ノードに直接のコネクションを持っている必要があります(当然、自ノードに対しては不要です)。

ホスト2台のシンプルな構成の場合、使い勝手と後方互換性のため、drbdadm は(1つの)ネットワークコネクションを自身で挿入します。

必要なネットワークコネクション数はホスト数の二次関数です。"従来の"2ノードでは1コネクションが必要でしたが、3つのホストでは3対、4つのホストでは6対、5つのホストでは10対のコネクションが…というように必要になってきます。32ノードであれば496対のコネクションが必要になります。

図11.1 N 個のホストの時のコネクション数

connection-mesh

以下は3つのホストでの設定ファイルの例です。

resource r0 {
  device    /dev/drbd1;
  disk      /dev/sda7;
  meta-disk internal;
  on alice {
    address   10.1.1.31:7000;
    node-id   0;
  }
  on bob {
    address   10.1.1.32:7001;
    node-id   1;
  }
  on charlie {
    address   10.1.1.33:7002;
    node-id   2;
  }
  connection {
    host alice   port 7010;
    host bob     port 7001;
  }
  connection {
    host alice   port 7020;
    host charlie port 7002;
  }
  connection {
    host bob     port 7012;
    host charlie port 7021;
  }

}

on host セクションの address 値でのポート番号は任意指定です。ただし各コネクションごとに異なるポート番号を指定する必要があります。

[注記]注記

プレリリース版では、コネクションメッシュ全体を定義する必要があります。

今後のリリースで、DRBDはハンドシェイク中にどの対向ノードと通信しているかを判定できるようになり、各ノード1ポートで済む予定です。

connection-mesh オプションを使うと、上記と同じ3ノード構成を以下のように設定できます。

resource r0 {
  device    /dev/drbd1;
  disk      /dev/sda7;
  meta-disk internal;
  on alice {
    address   10.1.1.31:7000;
    node-id   0;
  }
  on bob {
    address   10.1.1.32:7001;
    node-id   1;
  }
  on charlie {
    address   10.1.1.33:7002;
    node-id   2;
  }
  connection-mesh {
    hosts alice bob charlie;
    net {
        use-rle no;
    }
  }

}

サーバに十分なネットワークカードがあれば、サーバ間をクロスケーブルで直結できます。 1つ4ポートのイーサネットカードであれば、4ノードのフルメッシュにするために1つの管理インターフェースと3つの他サーバへの接続を行うことができます。

この場合には直接接続に異なるIPアドレスを指定することができます。

resource r0 {
  ...
  connection {
    host alice   address 10.1.2.1 port 7010;
    host bob     address 10.1.2.2 port 7001;
  }
  connection {
    host alice   address 10.1.3.1 port 7020;
    host charlie address 10.1.3.2 port 7002;
  }
  connection {
    host bob     address 10.1.4.1 port 7021;
    host charlie address 10.1.4.2 port 7012;
  }
}

管理とデバッグを容易にするため、エンドポイントごとに異なるポートを使用することをお勧めします。tcpdump 使用の際にパケットの追跡が容易になります。

以下の例は2サーバのみで使用するものです。4ノードでの例は「4ノードでの構成例」を参照ください。

11.1.5. トランスポートプロトコルの設定

DRBDは複数のネットワーク転送プロトコルに対応しています。トランスポートプロトコルの設定はリソースの各コネクションごとに設定できます。

11.1.5.1. TCP/IP

resource <resource> {
  net {
    transport "tcp";
  }
  ...
}

デフォルトは tcp です。トランスポートオプションを設定していない場合は TCP トランスポートが使用されます。

tcp トランスポートオプションでは次のnetオプションが設定できます。sndbuf-sizercvbuf-sizeconnect-int、` sock-check-timeo`、ping-timeotimeout

11.1.5.2. RDMA

resource <resource> {
  net {
    transport "rdma";
  }
  ...
}

rdma トランスポートでは次のnetオプションが設定できます。sndbuf-sizercvbuf-sizemax_buffersconnect-intsock-check-timeoping-timeotimeout

rdma トランスポートはゼロコピーレシーブ転送です。その関係で、max_buffers の設定オプションはすべての rcvbuf-size を保持するのに十分なサイズにする必要があります。

[注記]注記

rcvbuf-size はバイト単位で設定しますが、max_buffers はページ単位で設定します。パフォーマンス最適化のためには、 max_buffers はすべての rcvbuf-size と、下位デバイスとの間の全通信量を合わせたものよりも大きい必要があります。

[ヒント]ヒント

InfiniBand HCAで rdma トランスポートを使っている場合、IPoIBも設定する必要があります。IPアドレスはデータ転送では使用しませんが、コネクションを確立する際に正しいアダプタとポートを見つけるために使用します。

[注意]注意

設定オプションの sndbuf-sizercvbuf-size はコネクションが確立される時に考慮されます。つまり、接続が確立している時は変更する事ができますが、その変更が反映されるのは、再接続後になります。

11.1.5.3. RDMAのパフォーマンスにおける考慮事項

擬似ファイル/sys/kernel/debug/drbd/<リソース>/connections/<対向ノード>/transportを見れば、使用可能な受信識別子(rx_desc)と送信識別子(tx_desc)の数を監視できます。識別子が枯渇した場合には sndbuf-size または rcvbuf-size を増やす必要があります。

11.1.6. リソースを初めて有効にする

すでに述べた手順に従って最初のリソース設定を完了したら、リソースを稼働させます。

両方のノードに対して、次の手順を行います。

さきほどの構成例(resource r0{ … })では、<resource>r0 となります。

メタデータを作成する. この手順は、最初にデバイスを作成するときにのみ必要です。これにより、DRBDのメタデータを初期化します。

# drbdadm create-md <resource>
v09 Magic number not found
Writing meta data...
initialising activity log
NOT initializing bitmap
New drbd meta data block sucessfully created.

メタデータに割り当てられるビットマップスロットの数はリソースのホストの数に依存します。デフォルトではリソース設定のホストの数をカウントします。 メタデータの作成前にすべてのホストが指定されていれば、そのまま動作します。後から追加ノード用のビットマップを付け足すことも可能ですが、手動での作業が必要になります。

リソースを有効にする. これにより、リソースとその下位デバイス(マルチボリュームリソースの場合は、すべてのデバイス)とを結びつけます。また、対向ノードのリソースと接続します。

# drbdadm up <resource>

drbdadm status でステータスを確認する. drbdsetup のステータス出力は次のような情報を表示します。

# drbdadm status r0
r0 role:Secondary
  disk:Inconsistent
  bob role:Secondary
    disk:Inconsistent
[注記]注記

この時点では Inconsistent/Inconsistent のディスク状態になっているはずです。

これで、DRBDがディスクリソースとネットワークリソースに正しく割り当てられ、稼働できるようになりました。次に、どちらのノードをデバイスの初期同期のソースとして使用するか指定する必要があります。

11.1.7. デバイスの初期同期

DRBDを完全に機能させるには、さらに次の2つの手順が必要です。

同期元を選択する. 新しく初期化した空のディスクを使用する場合は、任意のディスクを同期元にできます。いずれかのノードにすでに重要なデータが格納されている場合は、 十分注意して、必ず そのノードを同期元として選択してください。デバイスの初期同期の方向が誤っていると、データを失うおそれがあります。慎重に行ってください。

初期フル同期を開始する. この手順は、最初のリソース設定の際に、同期ソースとして選択した1つのノードに対してのみ実行します。次のコマンドで実行します。

# drbdadm primary --force <resource>

このコマンドを指定すると、初期フル同期が開始します。drbdadm status で同期の進行状況を監視できます。デバイスのサイズによっては、同期に時間がかかる場合があります。

この時点で、初期同期が完了していなくてもDRBDデバイスは完全に稼働します(ただし、パフォーマンスは多少低いです)。空のディスクから開始した場合は、デバイスにファイルシステムを作成してもかまいません。これを下位ブロックデバイスとして使用し、マウントして、アクセス可能なブロックデバイスとしてさまざまな操作を実行することができます。

リソースに対して一般的な管理タスクを行う場合は、パートIV「DRBDの使い方」に進んでください。

11.1.8. トラックベースのレプリケーションの使用

リモートノードに同期するデータを前もってロードし、デバイスの初期同期をスキップする場合は、次の手順を行います。

初期設定済みで プライマリ に昇格し、相手ノードとの接続を切断した状態のDRBDリソースが必要です。つまり、デバイスの設定が完了し、両方のノードに同一の drbd.conf のコピーが存在し 最初のリソース昇格をローカルノードで実行するコマンドを発行した後、 — リモートノードがまだ接続されていない状態です。

  • ローカルノードで次のコマンドを実行します。

    # drbdadm new-current-uuid --clear-bitmap <resource>/<volume>

    または

    # drbdsetup new-current-uuid --clear-bitmap <minor>
  • リソースのデータ およびそのメタデータ の正確に同一のコピーを作成します。たとえば、ホットスワップ可能な RAID-1ドライブの一方を抜き取ります。この場合は、もちろん 新しいドライブをセットしてRAIDセットを再構築しておくべきでしょう。 抜き取ったドライブは、正確なコピーとして リモートサイトに移動できます。別の方法としては、ローカルのブロックデバイスがスナップショットコピーをサポートする場合 (LVMの上位でDRBDを使用する場合など)は、dd を使用してスナップショットのビット単位のコピーを作ってもかまいません。
  • ローカルノードで次のコマンドを実行します。

    # drbdadm new-current-uuid <resource>

    または drbdsetup コマンドを使用します。

    この2回目のコマンドには --clear-bitmap がありません。

  • 対向ホストの設置場所にコピーを物理的に移動します。
  • コピーをリモートノードに追加します。ここでも物理ディスクを接続するか、リモートノードの既存のストレージに移動したデータのビット単位のコピーを追加します。レプリケートしたデータだけでなく、関連するDRBDメタデータも必ず復元するかコピーしてください。そうでない場合、ディスクの移動を正しく行うことができません。
  • 新しいノードでメタデータのノードIDを修正し、2つのノード間で対抗ノードの情報を交換する必要があります。リソース r0 ボリューム 0 上でnode idを2から1に変更するには、次の行を参照ください。

    これはボリュームが未使用中のときに実行する必要があります。

    V=r0/0
    NODE_FROM=2
    NODE_TO=1
    
    drbdadm -- --force dump-md $V > /tmp/md_orig.txt
    sed -e "s/node-id $NODE_FROM/node-id $NODE_TO/" \
            -e "s/^peer.$NODE_FROM. /peer-NEW /" \
            -e "s/^peer.$NODE_TO. /peer[$NODE_FROM] /" \
            -e "s/^peer-NEW /peer[$NODE_TO] /" \
            < /tmp/md_orig.txt > /tmp/md.txt
    
    drbdmeta --force $(drbdadm sh-minor $V) v09 $(drbdadm sh-ll-dev $V) internal restore-md /tmp/md.txt

    NOTE. バージョン 8.9.7 以前の drbdmeta 順不同の対抗ノードセクションを扱えません。エディタを用いてブロックを交換する必要があります。

  • リモートノードで次のコマンドを実行します。

    # drbdadm up <resource>

2つのホストを接続しても、デバイスのフル同期は開始されません。代わりに、 drbdadm{nbsp}--clear-bitmap{nbsp}new-current-uuid の呼び出し以降に変更されたブロックのみを対象とする自動同期が開始されます。

以降、データの変更が 全くない 場合でも、セカンダリでアクティビティログを含む領域がロールバックされるため、同期が短時間行われることがあります。これはチェックサムベースの同期を使用することで緩和されます。

この手順は、リソースが通常のDRBDリソースの場合でもスタックリソースの場合でも使用できます。スタックリソースの場合は、-S または --stacked オプションを drbdadm に追加します。

11.1.9. 4ノードでの構成例

以下は4ノードクラスタの例です。

なお、connection セクション(および個別のポート)はDRBD9.0.0では必須ではありません。略式の書式があります。

resource r0 {
  device      /dev/drbd0;
  disk        /dev/vg/r0;
  meta-disk   internal;

  on store1 {
    address   10.1.10.1:7100;
    node-id   1;
  }
  on store2 {
    address   10.1.10.2:7100;
    node-id   2;
  }
  on store3 {
    address   10.1.10.3:7100;
    node-id   3;
  }
  on store4 {
    address   10.1.10.4:7100;
    node-id   4;
  }

  # All connections involving store1
  connection {
    host store1  port 7012;
    host store2  port 7021;
  }
  connection {
    host store1  port 7013;
    host store3  port 7031;
  }
  connection {
    host store1  port 7014;
    host store4  port 7041;
  }

  # All remaining connections involving store2
  connection {
    host store2  port 7023;
    host store3  port 7032;
  }
  connection {
    host store2  port 7024;
    host store4  port 7042;
  }

  # All remaining connections involving store3
  connection {
    host store3  port 7034;
    host store4  port 7043;
  }

  # store4 already done.
}

上記と同様の設定は以下のように記述することができます。

resource r0 {
  device      /dev/drbd0;
  disk        /dev/vg/r0;
  meta-disk   internal;

  on store1 {
    address   10.1.10.1:7100;
    node-id   1;
  }
  on store2 {
    address   10.1.10.2:7100;
    node-id   2;
  }
  on store3 {
    address   10.1.10.3:7100;
    node-id   3;
  }
  on store4 {
    address   10.1.10.4:7100;
    node-id   4;
  }

  connection-mesh {
        hosts     store1 store2 store3 store4;
  }
}

connection-mesh 設定を確認したい場合には drbdadm dump <resource> -v を実行します。

別の例として、4ノードに直接接続でフルメッシュにできるだけのインターフェースがある場合には、[6]インターフェースにIPアドレスを指定することができます。

resource r0 {
  ...

  # store1 has crossover links like 10.99.1x.y
  connection {
    host store1  address 10.99.12.1 port 7012;
    host store2  address 10.99.12.2 port 7021;
  }
  connection {
    host store1  address 10.99.13.1  port 7013;
    host store3  address 10.99.13.3  port 7031;
  }
  connection {
    host store1  address 10.99.14.1  port 7014;
    host store4  address 10.99.14.4  port 7041;
  }

  # store2 has crossover links like 10.99.2x.y
  connection {
    host store2  address 10.99.23.2  port 7023;
    host store3  address 10.99.23.3  port 7032;
  }
  connection {
    host store2  address 10.99.24.2  port 7024;
    host store4  address 10.99.24.4  port 7042;
  }

  # store3 has crossover links like 10.99.3x.y
  connection {
    host store3  address 10.99.34.3  port 7034;
    host store4  address 10.99.34.4  port 7043;
  }
}

IPアドレスやポート番号の付け方には注意してください。別のリソースであれば同じIPアドレスを使用することができますが、71xy、72xy のようにずらしてください。

11.2. DRBDのステータスを確認する

11.2.1. drbdmon でステータスを取得する

DRBDの状態を見るのに便利な方法の1つは drbdmon ユーティリティを使うことです。これはリアルタイムでDRBDリソースの状態を更新します。

11.2.2. drbdtop でDRBDのステータス取得し対話する

その名前が示すように drbdtophtop のようなツールと似ています。一方では、DRBDリソースの監視と対話(例えば Primary への切り替え、あるいはスプリット・ブレーンの解決など)を行うことができます。詳細は https://linbit.github.io/drbdtop/ を参照ください。

11.2.3. /proc/drbd でのステータス情報

[注記]注記

'/proc/drbd' は非推奨です。8.4系でこの機能を取り除く予定はありませんが、他の方法を使用することをおすすめします。drbdadm でのステータス情報」や、より便利なモニタリングとしてdrbdsetup events2 を使用した一回のみ、またはリアルタイムでの監視」など

/proc/drbd はDRBDモジュールの基本情報を表示する仮想ファイルです。 DRBD8.4まで広く使用されていましたが、DRBD9の情報量を表示するためには対応できません。

$ cat /proc/drbd
version: 9.0.0 (api:1/proto:86-110) FIXME
GIT-hash: XXX build by linbit@buildsystem.linbit, 2011-10-12 09:07:35

1行目にはシステムで使用するDRBDの バージョン を表示します。2行目にはビルド特有の情報を表示します。

11.2.4. drbdadm でのステータス情報

一番シンプルなものとして、1つのリソースのステータスを表示します。

# drbdadm status home
home role:Secondary
  disk:UpToDate
  nina role:Secondary
    disk:UpToDate
  nino role:Secondary
    disk:UpToDate
  nono connection:Connecting

ここではリソース home がローカルと ninanino にあり、UpToDateセカンダリ であることを示しています。つまり、3ノードが同じデータをストレージデバイスに持ち、現在はどのノードでもデバイスを使用していないという意味です。

ノード nono は接続していません。Connecting のステータスになっています。詳細は「コネクションステータス」を参照してください。

drbdsetup--verbose および/または --statistics の引数を付けると、より詳細な情報を得ることができます。

# drbdsetup status home --verbose --statistics
home node-id:1 role:Secondary suspended:no
    write-ordering:none
  volume:0 minor:0 disk:UpToDate
      size:1048412 read:0 written:1048412 al-writes:0 bm-writes:48 upper-pending:0
                                        lower-pending:0 al-suspended:no blocked:no
  nina local:ipv4:10.9.9.111:7001 peer:ipv4:10.9.9.103:7010 node-id:0
                                               connection:Connected role:Secondary
      congested:no
    volume:0 replication:Connected disk:UpToDate resync-suspended:no
        received:1048412 sent:0 out-of-sync:0 pending:0 unacked:0
  nino local:ipv4:10.9.9.111:7021 peer:ipv4:10.9.9.129:7012 node-id:2
                                               connection:Connected role:Secondary
      congested:no
    volume:0 replication:Connected disk:UpToDate resync-suspended:no
        received:0 sent:0 out-of-sync:0 pending:0 unacked:0
  nono local:ipv4:10.9.9.111:7013 peer:ipv4:10.9.9.138:7031 node-id:3
                                                           connection:Connecting

この例では、ローカルノードについては多少異なりますが、このリソースで使用しているノードすべてを数行ごとにブロックで表示しています。以下で詳細を説明します。

各ブロックの最初の行は node-id です。(現在のリソースに対してのものです。ホストは異なるリソースには異なる node-id がつきます) また、role (「リソースのロール」参照)も表示されています。

次に重要な行が、volume の表示がある行です。通常は0から始まる数字ですが、設定によっては別のIDをつけることもできます。この行では replicationコネクションステータス(「コネクションステータス」参照)を、disk でリモートのディスク状態(「ディスク状態」参照)が表示されます。 また、ボリュームの統計情報が少し表示される行もあります。データの receivedsent , out-of-sync などです。詳細は 「パフォーマンス指標」「接続情報データ」を参照してください。

ローカルノードでは、最初の行はリソース名を表示します。この例では home です。最初の行には常にローカルノードが表示されますので、 Connection やアドレス情報は表示されません。

より詳細な情報については、drbd.conf マニュアルページをご覧ください。

この例のブロックになっている他の4行は、すべての設定のあるDRBDデバイスごとになっており、最初にデバイスマイナー番号がついています。この場合にはデバイス /dev/drbd0 に対応して 0 です。

リソースごとの出力には様々なリソースに関する情報が含まれています。

11.2.5. drbdsetup events2 を使用した一回のみ、またはリアルタイムでの監視

[注記]注記

この機能はユーザスペースのDRBDが8.9.3より後のバージョンでのみ使用できます

これはDRBDから情報を取得するための下位機能です。監視など自動化ツールでの使用に向いています。

一番シンプルな使用方法では、以下のように現在のステータスのみを表示します(端末上で実行した場合には色も付いています)。

# drbdsetup events2 --now r0
exists resource name:r0 role:Secondary suspended:no
exists connection name:r0 peer-node-id:1 conn-name:remote-host connection:Connected role:Secondary
exists device name:r0 volume:0 minor:7 disk:UpToDate
exists device name:r0 volume:1 minor:8 disk:UpToDate
exists peer-device name:r0 peer-node-id:1 conn-name:remote-host volume:0
    replication:Established peer-disk:UpToDate resync-suspended:no
exists peer-device name:r0 peer-node-id:1 conn-name:remote-host volume:1
    replication:Established peer-disk:UpToDate resync-suspended:no
exists -

'--now' を付けないで実行した場合には動作し続け、以下のように更新を続けます。

# drbdsetup events2 r0
...
change connection name:r0 peer-node-id:1 conn-name:remote-host connection:StandAlone
change connection name:r0 peer-node-id:1 conn-name:remote-host connection:Unconnected
change connection name:r0 peer-node-id:1 conn-name:remote-host connection:Connecting

そして監視用途に、'--statistics'という別の引数もあります。これはパフォーマンスその他のカウンタを作成するものです。

'drbdsetup' の詳細な出力(読みやすいように一部の行は改行しています)

# drbdsetup events2 --statistics --now r0
exists resource name:r0 role:Secondary suspended:no write-ordering:drain
exists connection name:r0 peer-node-id:1 conn-name:remote-host connection:Connected
                                                        role:Secondary congested:no
exists device name:r0 volume:0 minor:7 disk:UpToDate size:6291228 read:6397188
            written:131844 al-writes:34 bm-writes:0 upper-pending:0 lower-pending:0
                                                         al-suspended:no blocked:no
exists device name:r0 volume:1 minor:8 disk:UpToDate size:104854364 read:5910680
          written:6634548 al-writes:417 bm-writes:0 upper-pending:0 lower-pending:0
                                                         al-suspended:no blocked:no
exists peer-device name:r0 peer-node-id:1 conn-name:remote-host volume:0
          replication:Established peer-disk:UpToDate resync-suspended:no received:0
                                      sent:131844 out-of-sync:0 pending:0 unacked:0
exists peer-device name:r0 peer-node-id:1 conn-name:remote-host volume:1
          replication:Established peer-disk:UpToDate resync-suspended:no received:0
                                     sent:6634548 out-of-sync:0 pending:0 unacked:0
exists -

'--timestamp' パラメータも便利な機能です。

11.2.6. コネクションステータス

リソースのコネクションステータスは drbdadm cstate コマンドで確認することができます。

# drbdadm cstate <resource>
Connected
Connected
StandAlone

確認したいのが1つのコネクションステータスだけの場合にはコネクション名を指定してください。

デフォルトでは設定ファイルに記載のある対向ノードのホスト名です。

# drbdadm cstate <peer>:<resource>
Connected

リソースのコネクションステータスには次のようなものがあります。

StandAloneネットワーク構成は使用できません。リソースがまだ接続されていない、管理上の理由で切断している(`drbdadm disconnect`を使用)、認証の失敗またはスプリットブレインにより接続が解除された、のいずれかが考えられます。

Disconnecting切断中の一時的な状態です。次の状態は StandAlone です。

Unconnected 接続を試行する前の一時的な状態です。次に考えられる状態は、 Connecting です。

Timeout対向ノードとの通信のタイムアウト後の一時的な状態です。次の状態は Unconnected です。

BrokenPipe対向ノードとの接続が失われた後の一時的な状態です。次の状態は Unconnected です。

NetworkFailure対向ノードとの接続が失われた後の一時的な状態です。次の状態は Unconnected です。

ProtocolError対向ノードとの接続が失われた後の一時的な状態です。次の状態は Unconnected です。

TearDown一時的な状態です。対向ノードが接続を閉じています。次の状態は Unconnected です。

Connecting 対向ノードがネットワーク上で可視になるまでノードが待機します。

Connected DRBDの接続が確立され、データミラー化がアクティブになっています。これが正常な状態です。

11.2.7. 複製ステータス

各ボリュームは接続を介した複製ステータスを持ちます。可能な複製ステータスは以下になります。

Off ボリュームはこの接続を通して複製されていません。接続が Connected になっていません。す。次の状態は Unconnected です。

Established このボリュームへのすべての書き込みがオンラインで複製されています。これは通常の状態です。

StartingSyncS 管理者により開始されたフル同期が始まっています。次に考えられる状態は SyncSource または PausedSyncS です。

StartingSyncT 管理者により開始されたフル同期が始まっています。次の状態は WFSyncUUID です。

WFBitMapS 部分同期が始まっています。次に考えられる状態は SyncSource または PausedSyncS です。

WFBitMapT 部分同期が始まっています。次に考えられる状態は WFSyncUUID です。

WFSyncUUID 同期が開始されるところです。次に考えられる状態は SyncTarget または PausedSyncT です。

SyncSource 現在、ローカルノードを同期元にして同期を実行中です。

SyncTarget 現在、ローカルノードを同期先にして同期を実行中です。

PausedSyncS ローカルノードが進行中の同期の同期元ですが、現在は同期が一時停止しています。原因として、別の同期プロセスの完了との依存関係、または drbdadm pause-sync を使用して手動で同期が中断されたことが考えられます。

PausedSyncT ローカルノードが進行中の同期の同期先ですが、現在は同期が一時停止しています。原因として、別の同期プロセスの完了との依存関係、または drbdadm pause-sync を使用して手動で同期が中断されたことが考えられます。

VerifyS ローカルノードを照合元にして、オンラインデバイスの照合を実行中です。

VerifyT 現在、ローカルノードを照合先にして、オンラインデバイスの照合を実行中です。

Ahead リンクが負荷に対応できないので、データの複製が中断しました。このステータスは on-congestion オプションの設定で有効にできます(「輻輳ポリシーと中断したレプリケーションの構成」を参照)。

Behind リンクが負荷に対応できないので、データの複製が対抗ノードによって中断されました。このステータスは対抗ノードの on-congestion オプション設定で有効にできま>す(「輻輳ポリシーと中断したレプリケーションの構成」を参照)。

11.2.8. リソースのロール

リソースのロールはdrbdadm role コマンドを実行することで確認できます。

# drbdadm role <resource>
Primary

以下のいずれかのリソースのロールが表示されます。

Primaryリソースは現在プライマリロールで読み書き加能です。2つのノードの一方だけがこのロールになることができます。ただし、デュアルプライマリモードの場合は例外です。

Secondaryリソースは現在セカンダリロールです。対向ノードから正常に更新を受け取ることができますが(切断モード以外の場合)、このリソースに対して読み書きは実行できません。1つまたは両ノードがこのロールになることができます。

Unknownリソースのロールが現在不明です。ローカルリソースロールがこの状態になることはありません。切断モードの場合に、対向ノードのリソースロールにのみ表示されます。

11.2.9. ディスク状態

リソースのディスク状態は drbdadm dstate コマンドを実行することで確認できます。

# drbdadm dstate <resource>
UpToDate

ディスク状態は以下のいずれかです。

DisklessDRBDドライバにローカルブロックデバイスが割り当てられていません。原因として、リソースが下位デバイスに接続されなかった、drbdadm detach を使用して手動でリソースを切り離した、または下位レベルのI/Oエラーにより自動的に切り離されたことが考えられます。

Attachingメタデータ読み取り中の一時的な状態です。

Detaching 切断され、進行中のIO処理が完了するのを待っている一時的な状態。

FailedローカルブロックデバイスがI/O障害を報告した後の一時的な状態です。次の状態は Diskless です。

Negotiatingすでに Connected のDRBDデバイスで attach が実行された場合の一時的状態です。

Inconsistentデータが一致しません。新規リソースを作成した直後に(初期フル同期の前に)両方のノードがこの状態になります。また、同期中には片方のノード(同期先)がこの状態になります。

Outdatedリソースデータは一致していますが、無効です。

DUnknownネットワーク接続を使用できない場合に、対向ノードディスクにこの状態が使用されます。

Consistent接続していない状態でノードのデータが一致しています。接続が確立すると、データが UpToDateOutdated か判断されます。

UpToDateデータが一致していて最新の状態です。これが正常な状態です。

11.2.10. 接続情報データ

localネットワークファミリ、ローカルアドレス、対向ノードから接続を許可されたポートを表示します。

peerネットワークファミリ、ローカルアドレス、接続に使用しているポートを表示します。

congestedデータのTCP送信バッファを80%より多く使用している場合にこのフラグがつきます。

11.2.11. パフォーマンス指標

drbdadm status の出力には、以下のカウンタと指標があります。

send (network send). ネットワークを通じて相手に送信された正味データ量(kibyte単位)。

receive (network receive). ネットワークを通じて相手から受信した正味データ量(kibyte単位)。

read (disk write). ローカルのハードディスクに書き込んだ正味データ量(kibyte単位)。

written (disk read). ローカルのハードディスクから読み込んだ正味データ量(kibyte単位)。

al-writes (activity log). メタデータのアクティビティログエリアのアップデート数。

bm-writes (bit map). メタデータのビットマップエリアのアップデート数。

lower-pending (local count). DRBDが発行したローカルI/Oサブシステムへのオープンリクエストの数。

pending相手側に送信したが相手から応答がないリクエスト数。

unacked (unacknowledged). ネットワーク接続を通じて相手側が受信したが応答がまだないリクエスト数。

upper-pending (application pending). まだDRBDから応答がないDRBDへのブロックI/Oリクエスト数。

write-ordering (write order). 現在使用中の書き込み順序制御方法: b(barrier)、f(flush)、d(drain)、n(none)

out-of-sync現在同期していない正味ストレージ容量(kibyte単位)

resync-suspended現在再同期が中断されているかどうか。値は nouserpeerdependency のいずれかです。

blockedローカルI/Oの輻輳を示します。

  • no:輻輳なし
  • uppeer: ファイルシステムなどDRBD より上位 のI/Oがブロックされている。代表的なものには以下がある。

  • lower: 下位デバイスの輻輳

upper、lower の値を見ることも可能です。

11.3. リソースの有効化と無効化

11.3.1. リソースの有効化

通常、自動的にすべての設定済みDRBDリソースが有効になります。これは、

  • クラスタ構成に応じたクラスタ管理アプリケーションの操作によるものであり、
  • またはシステム起動時の /etc/init.d/drbd によっても有効になります。

手動でリソースを起動する必要がある場合には、以下のコマンドの実行によって行うことができます。

# drbdadm up <resource>

他の場合と同様に、特定のリソース名の代わりにキーワード all を使用すれば、/etc/drbd.conf で設定しているすべてのリソースを一度に有効にできます。

11.3.2. リソースを無効にする

特定のリソースを一時的に無効にするには、次のコマンドを実行します。

# drbdadm down <resource>

ここでも、リソース名の代わりにキーワード all を使用して、1回で /etc/drbd.conf に記述しているすべてのリソースを一時的に無効にできます。

11.4. リソースの再設定

DRBDの動作中にリソースを再設定することができます。次の手順を行います。

  • /etc/drbd.conf のリソース設定を変更します。
  • 両方のノードで /etc/drbd.conf ファイルを同期します。
  • `drbdadm adjust <resource>`コマンドを 両ノードで実行します。

drbdadm adjustdrbdsetup を通じて実行中のリソースを調整します。保留中の drbdsetup 呼び出しを確認するには、drbdadm-d (dry-run,予行演習)オプションを付けて実行します。

[注記]注記

/etc/drbd.confcommon セクションを変更して一度にすべてのリソースに反映させたいときには drbdadm adjust all を実行します。

11.5. リソースの昇格と降格

手動でリソースロールをセカンダリからプライマリに切り替える(昇格)、またはその逆に切り替える(降格)には、次のコマンドを実行します。

# drbdadm primary <resource>
# drbdadm secondary <resource>

DRBDがシングルプライマリモード(DRBDのデフォルト)で、コネクションステータスConnected の場合、任意のタイミングでどちらか1つのノード上でのみリソースはプライマリロールになれます。したがって、あるリソースが他のノードに対してプライマリロールになっているときに drbdadm primary <resource> を実行すると、エラーが発生します。

リソースがデュアルプライマリモードに対応するよう設定している場合には、両方のノードをプライマリロールに切り替えることができます。これは、例えば仮想マシンのオンラインマイグレーションの際に利用できます。

11.6. 基本的な手動フェイルオーバ

Pacemakerを使わず、パッシブ/アクティブ構成でフェイルオーバを手動で制御するには次のようにします。

現在のプライマリノードでDRBDデバイスを使用するすべてのアプリケーションとサービスを停止し、リソースをセカンダリに降格します。

# umount /dev/drbd/by-res/<resource>/<vol-nr>
# drbdadm secondary <resource>

プライマリにしたいノードでリソースを昇格してデバイスをマウントします。

# drbdadm primary <resource>
# mount /dev/drbd/by-res/<resource>/<vol-nr> <mountpoint>

自動プロモート 機能を使用している場合はロール(プライマリ/セカンダリ)を手動で変更する必要はありません。それぞれサービス停止とアンマウント、マウントの操作のみ必要です。

11.7. DRBDのアップグレード

DRBDのアップグレードは非常にシンプルな手順です。この章ではDRBD8.4から9.0へのアップグレード手順を説明します。DRBD9系内でのアップグレードの手順についてはより簡単ですので以下の項目を参照ください。

11.7.1. 概要

8.4から9.0へのアップグレード手順の概要は以下の通りです。

11.7.2. リポジトリのアップデート

8.4と9.0のブランチ間の様々な変更のため、各々に別のリポジトリを作成しています。各サーバでリポジトリのアップデートを行います。

11.7.2.1. RHEL/CentOSのシステム

/etc/yum.repos.d/linbit.repo ファイルに以下の変更を反映します。

[drbd-9.0]
name=DRBD 9.0
baseurl=http://packages.linbit.com/<hash>/yum/rhel7/drbd-9.0/<arch>
gpgcheck=0
[注記]注記

<hash>と<arch>の箇所は置き換えてください。<hash>はLINBITサポートから提供されるものです。

11.7.2.2. Debian/Ubuntuのシステム

/etc/apt/sources.list(または /etc/apt/sources.d/ にあるファイル)に以下の変更を反映します。

deb http://packages.linbit.com/<hash>/ stretch drbd-9.0

wheezy リリースを使用していない場合でも、また他のリリースの場合でも、この変更は必要です。

[注記]注記

<hash>の箇所は置き換えてください。<hash>はLINBITサポートから提供されるものです。

次にDRBDの署名キーを信頼済みキーに追加してもよいでしょう。

# gpg --keyserver subkeys.pgp.net --recv-keys  0x282B6E23
# gpg --export -a 282B6E23 | apt-key add -

最後に apt update を実行してリポジトリのアップデートを認識させます。

# apt update

11.7.3. DRBDの状態を確認する

リソースが同期していることを確認します。cat /proc/drbdUpToDate/UpToDate を出力しています。(これは、DRBD8系 以下 でのみ有効です)

bob# cat /proc/drbd

version: 8.4.9-1 (api:1/proto:86-101)
GIT-hash: e081fb0570183db40caa29b26cb8ee907e9a7db3 build by linbit@buildsystem, 2016-11-18 14:49:21

 0: cs:Connected ro:Secondary/Secondary ds:UpToDate/UpToDate C r-----
    ns:0 nr:211852 dw:211852 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:d oos:0

11.7.4. クラスタを停止する

リソースが同期している事を確認したら、セカンダリノードをアップグレードします。この手順は手動で行うことができます。またはPacemakerを使用している場合にはノードをスタンバイモードにしておきます。両手順は以下の通りです。Pacemakerの動作中は手動では操作しないでください。

  • 手動手順
bob# /etc/init.d/drbd stop
  • Pacemaker

セカンダリノードをスタンバイモードにします。この例では bob はセカンダリです。

bob# crm node standby bob
[注記]注記

クラスタの状態を crm_mon -rf で確認することができます。または、リソースの状態を、もし "Unconfigured" と表示されていなければ cat /proc/drbd で確認することができます。

11.7.5. パッケージのアップグレード

パッケージをyumまたはaptでアップデートします。

bob# yum upgrade
bob# apt upgrade

アップグレードが完了すると、最新のDRBD9のカーネルモジュールとdrbd-utilsがセカンダリノードの bob にインストールされています。

しかしカーネルモジュールはまだ有効化されていません。

11.7.6. 新しいカーネルモジュールのロード

現時点でDRBDモジュールは使用していませんので、以下コマンドでアンロードします。

bob# rmmod drbd

" ERROR : Module drbd is in use " のようなメッセージが出る場合は、まだすべてのリソースが正常に停止していません。「DRBDのアップグレード」を再実行し、そして/またはどのリソースがまだ稼働しているのか確認するため drbdadm down all を実行します。

よくあるアンロードを妨げる原因には以下のものがあります。

  • DRBDが下位デバイスのファイルシステムにNFSエクスポートがある(exportfs -v の出力を確認)
  • ファイルシステムをマウント中 - grep drbd /proc/mounts を確認
  • ループバックデバイスがアクティブ (losetup -l)
  • デバイスマッパーが直接または間接的にDRBDを使用している。(dmsetup ls --tree)
  • DRBDデバイスが物理ボリュームとなっていて、そのLVMがアクティブ (pvs)

上記はよくあるケースであり、すべてのケースを網羅するものではないという事に注意ください。

これで、DRBDモジュールをロードすることができます。

bob# modprobe drbd

/proc/drbd の出力を確認し、正しく(新しい)バージョンがロードされたか確認してください。もしインストールされているパッケージが間違ったカーネルバージョンのものだった場合には、 modprobe は有効ですが、古いバージョンが残っていれば再び有効にすることもできます。

cat /proc/drbd の出力は9.0.xを表示し、次のようになっているでしょう。

version: 9.0.0 (api:2/proto:86-110)
GIT-hash: 768965a7f158d966bd3bd4ff1014af7b3d9ff10c build by root@bob, 2015-09-03 13:58:02
Transports (api:10): tcp (1.0.0)
[注記]注記

プライマリノードのaliceでは、cat /proc/drbd はアップグレードをするまでは以前のバージョンを表示します。

11.7.7. 設定ファイルの移行

DRBD 9.0は8.4の設定ファイルに後方互換性がありますが、一部の構文は変更しています。変更点の全一覧は「設定上の構文の変更点」を参照してください。drbdadm dump all コマンドを使えば古い設定を簡単に移すことができます。これは、新しいリソース設定ファイルに続いて新しいグローバル設定も両方とも出力します。この出力を使って適宜変更してください。

11.7.8. メタデータの変更

次にオンディスクのメタデータを新しいバージョンに変更します。この手順はとても簡単で、1つコマンドを実行して2つの質問に答えるだけです。

たくさんのノードを変更したい場合には、追加のビットマップに十分なスペースを確保するため、すでに下位デバイスの容量を拡張していることでしょう。この場合には以下のコマンドを追加の引数 --max-peers=<N> を付けて実行します。対向ノードの数(予定)を決める時には、「DRBDクライアント」も考慮に入れてください。

DRBDのメタデータのアップグレードはとても簡単で、1つコマンドを実行して2つの質問に答えるだけです。

# drbdadm create-md <resource>
You want me to create a v09 style flexible-size internal meta data block.
There appears to be a v08 flexible-size internal meta data block
already in place on <disk> at byte offset <offset>

Valid v08 meta-data found, convert to v09?
[need to type 'yes' to confirm] yes

md_offset <offsets...>
al_offset <offsets...>
bm_offset <offsets...>

Found some data

 ==> This might destroy existing data! <==

Do you want to proceed?
[need to type 'yes' to confirm] yes

Writing meta data...
New drbd meta data block successfully created.
success

もちろん、リソース名を all にすることも可能です。また、以下のようにすれば質問されるのを回避することができます(コマンド内の順序が重要です)。

drbdadm -v --max-peers=<N>  -- --force create-md <resources>

11.7.9. DRBDを再び起動する

あとはDRBDデバイスを再びupにして起動するだけです。単純に、drbdadm up all で済みます。

次は、クラスタ管理ソフトを使用しているか、手動でリソースを管理しているかによって方法が異なります。

  • 手動

    bob# /etc/init.d/drbd start
  • Pacemaker

    # crm node online bob

    これによってDRBDは他のノードに接続し、再同期プロセスが開始します。

すべてのリソースが2つのノードで UpToDate になったら、アップグレードしたノード(ここでは bob )にアプリケーションを移動させることができます。そして、まだ8.4が稼働しているノードで同じ手順を行ってください。

11.7.10. DRBD9からDRBD9

既にDRBD9を使っている場合には新しいバージョンのパッケージをインストールすることができます。クラスタノードをスタンバイにして、カーネルモジュールをアンロード/リロードし、リソースを起動、そしてクラスタノードを再度 online にします。[7]

個々の手順については上述の項の通りですので、ここでは省略します。

11.8. デュアルプライマリモードを有効にする

デュアルプライマリモードではリソースが複数ノードで同時にプライマリになることができます。永続的でも一時的なものでも可能です。

[注記]注記

デュアルプライマリモードではリソースが同期レプリケート(プロトコルC)で設定されていることが必要です。そのためレイテンシに過敏となり、WAN環境には向いていません。

さらに、両リソースが常にプライマリとなるので、いかなるノード間のネットワーク不通でもスプリットブレインが発生します。

[警告]警告

DRBD 9.0.xのデュアルプライマリモードは、ライブマイグレーションで使用する 2 プライマリに制限されています。

11.8.1. 永続的なデュアルプライマリモード

デュアルプライマリモードを有効にするため、リソース設定の net セクションで、allow-two-primaries オプションを yes に指定します。

resource <resource>
  net {
    protocol C;
    allow-two-primaries yes;
    fencing resource-and-stonith;
  }
  handlers {
    fence-peer "...";
    unfence-peer "...";
  }
  ...
}

そして、両ノード間で設定を同期することを忘れないでください。両ノードで drbdadm adjust <resource> を実行してください。

これで drbdadm primary <resource> で、両ノードを同時にプライマリのロールにすることができます。

[注意]注意

適切なフェンシングポリシーを常に実装すべきです。フェンシングなしで allow-two-primaries を設定するのは危険です。これはフェンシングなしで、シングルプライマリを使うことより危険になります。

11.8.2. 一時的なデュアルプライマリモード

通常はシングルプライマリで稼動しているリソースを、一時的にデュアルプライマリモードを有効にするには次のコマンドを実行してください。

# drbdadm net-options --protocol=C --allow-two-primaries <resource>

一時的なデュアルプライマリモードを終えるには、上記と同じコマンドを実行します。ただし --allow-two-primaries=no としてください(また、適切であれば希望するレプリケーションプロトコルにも)。

11.9. オンラインデバイス照合の使用

11.9.1. オンライン照合を有効にする

オンラインデバイス照合はデフォルトでは有効になっていません。有効にするには /etc/drbd.conf のリソース設定に以下の行を追加します。

resource <resource>
  net {
    verify-alg <algorithm>;
  }
  ...
}

<algorithm> は、システムのカーネル構成内のカーネルcrypto APIでサポートされる任意のメッセージダイジェストアルゴリズムです。通常は sha1md5crc32c から選択します。

既存のリソースに対してこの変更を行う場合は、drbd.conf を対向ノードと同期し、両方のノードで drbdadm adjust <resource> を実行します。

11.9.2. オンライン照合の実行

オンライン照合を有効にしたら、次のコマンドでオンライン照合を開始します。

# drbdadm verify <resource>

コマンドを実行すると、DRBDが _<resource>_ に対してオンライン照合を実行します。同期していないブロックを検出した場合は、ブロックに非同期のマークを付け、カーネルログにメッセージを書き込みます。このときにデバイスを使用しているアプリケーションは中断なく動作し続けます。また、リソースロールの切り替えも行うことができます。

照合中に同期していないブロックが検出された場合は、照合の完了後に、次のコマンド使用して再同期できます。

# drbdadm disconnect <resource>
# drbdadm connect <resource>

11.9.3. 自動オンライン照合

通常は、オンラインデバイス照合を自動的に実行するほうが便利です。自動化は簡単です。一方 のノードに /etc/cron.d/drbd-verify という名前で、次のような内容のファイルを作成します。

42 0 * * 0    root    /sbin/drbdadm verify <resource>

これにより、毎週日曜日の午前0時42分に、cron がデバイス照合を呼び出します。そのため、月曜の朝にリソース状態をチェックして結果を確認することができます。デバイスが大きくて32時間では足りなかった場合、 コネクションステータスが VerifyS または VerifyT になっています。これは verify がまだ動作中であることを意味しています。

オンライン照合をすべてのリソースで有効にした場合(例えば /etc/drbd.d/global_common.confcommon セクションに verify-alg <アルゴリズム> を追加するなど)には、以下のようにします。

42 0 * * 0    root    /sbin/drbdadm verify all

11.10. 同期速度の設定

バックグラウンド同期中は同期先のデータとの一貫性が一時的に失われるため、同期はできるだけ短時間で完了させるべきです。ただし、すべての帯域幅がバックグラウンド同期に占有されてしまうと、フォアグラウンドレプリケーションに使用できなくなり、アプリケーションのパフォーマンス低下につながります。これは避ける必要があります。同期用の帯域幅はハードウェアに合わせて設定する必要があります。

[重要]重要

同期速度をセカンダリノードの最大書き込みスループットを上回る速度に設定しても意味がありません。デバイス同期の速度をどれほど高速に設定しても、セカンダリノードがそのI/Oサブシステムの能力より高速に書き込みを行うことは不可能です。

また、同じ理由で、同期速度をレプリケーションネットワークの帯域幅の能力を上回る速度に設定しても意味がありません。

11.10.1. 同期速度の計算

[ヒント]ヒント

概算としては使用可能なレプリケーション帯域幅の30%程度を想定するのがよいでしょう。400MB/sの書き込みスループットを維持できるI/Oサブシステム、および110MB/sのネットワークスループットを維持できるギガビットイーサネットネットワークの場合は、ネットワークがボトルネックになります。速度は次のように計算できます。

図11.2 syncer 速度の例(有効帯域幅が110MB/sの場合)

sync-rate-example1

この結果、resynce-rate オプションの推奨値は 33M になります。

一方、最大スループットが80MB/sのI/Oサブシステム、およびギガビットイーサネット接続を使用する場合は、I/Oサブシステムが律速要因になります。速度は次のように計算できます。

図11.3 syncer 速度の例(有効帯域幅が80MB/sの場合)

sync-rate-example2

この場合、resync-rate オプションの推奨値は 24M です。

同じようにして800MB/sのストレージ速度で10Gbeのネットワークコネクションであれば、〜240MB/sの同期速度が得られます。

11.10.2. 可変同期速度設定

複数のDRBDリソースが1つのレプリケーション/同期ネットワークを共有する場合、同期が固定レートであることは最適なアプローチではありません。そのためDRBD 8.4.0から可変同期速度がデフォルトで有効になっています。このモードではDRBDが自動制御のループアルゴリズムで同期速度を決定して調整を行います。このアルゴリズムはフォアグラウンド同期に常に十分な帯域幅を確保し、バックグラウンド同期がフォアグラウンドのI/Oに与える影響を少なくします。

最適な可変同期速度の設定は、使用できるネットワーク帯域幅、アプリケーションのI/Oパターンやリンクの輻輳によって変わります。DRBD Proxyの有無によっても適切な設定は異なります。DRBDの機能を最適化するためにコンサルタントを利用するのもよいでしょう。以下は(DRBD Proxy使用を想定した環境での)設定の 一例 です。

resource <resource> {
  disk {
    c-plan-ahead 5;
    c-max-rate 10M;
    c-fill-target 2M;
  }
}
[ヒント]ヒント

c-fill-target の初期値は BDP✕2 がよいでしょう。BDP とはレプリケーションリンク上の帯域幅遅延積(Bandwidth Delay Product)です。

例えば、1GBit/sの接続の場合、200µsのレイテンシになります。[8]1GBit/sは約120MB/sです。120掛ける200*10-6秒は24000Byteです。この値はMB単位まで丸めてもよいでしょう。

別の例をあげると、100MBitのWAN接続で200msのレイテンシなら12MB/s掛ける0.2sです。2.5MBくらいになります。c-fill-target の初期値は3MBがよいでしょう。

他の設定項目については drbd.conf のマニュアルページを参照してください。

11.10.3. 永続的な固定同期速度の設定

ごく限られた状況[9]では、固定同期速度を使うことがあるでしょう。この場合には、まず c-plan-ahead 0; にして可変同期速度調節の機能をオフにします。

そして、リソースがバックグラウンド再同期に使用する最大帯域幅をリソースの resync-rate オプションによって決定します。この設定はリソースの /etc/drbd.confdisk セクションに記載します。

resource <resource>
  disk {
    resync-rate 40M;
    ...
  }
  ...
}

同期速度の設定は1秒あたりの バイト 単位であり ビット 単位でない点に注意してください。デフォルトの単位は kibibyte で、 4096 であれば 4MiB となります。

[注記]注記

これはあくまでDRBDが行おうとする速度にすぎません。低スループットのボトルネック(ネットワークやストレージの速度)がある場合、設定した速度(いわゆる"理想値")には達しません。

11.10.4. 同期に関するヒント

同期すべきデータ領域の一部が不要になった場合、例えば、対向ノードとの接続が切れている時にデータを削除した場合などには「Trim/Discardのサポート」の有効性が感じられるかもしれません。

c-min-rate は間違われやすいです。これは同期速度の 最低値 ではなくて、この速度以上の速度低下を 意図的に 行わないという制限です。ネットワークとストレージの速度、ネットワーク遅延(これは回線共有による影響が大きいでしょう)、アプリケーションIO(関与することは難しいかもしれません)に応じた同期速度の管理まで 手が及ぶか どうかによります。

11.11. チェックサムベース同期の設定

チェックサムベース同期はデフォルトでは有効になっていません。有効にするには、/etc/drbd.conf のリソース構成に次の行を追加します。

resource <resource>
  net {
    csums-alg <algorithm>;
  }
  ...
}

<algorithm> は、システムのカーネル構成内のカーネルcrypto APIでサポートされる任意のメッセージダイジェストアルゴリズムです。通常は sha1md5crc32c から選択します。

既存のリソースに対してこの変更を行う場合は、drbd.conf を対向ノードと同期し、両方のノードで drbdadm adjust <resource> を実行します。

11.12. 輻輳ポリシーと中断したレプリケーションの構成

レプリケーション帯域幅が大きく変動する環境(WANレプリケーション設定で典型的)の場合、レプリケーションリンクは時に輻輳します。デフォルト設定では、プライマリノードのI/Oのブロックを引き起こし、望ましくない場合があります。

その代わりに、進行中の同期を suspend (中断)に設定し、プライマリのデータセットをセカンダリから pull ahead (引き離す)にします。このモードではDRBDはレプリケーションチャネルを開いたままにし、切断モードにはしません。しかし十分な帯域幅が利用できるようになるまで実際にはレプリケートを行いません。

次の例は、DRBD Proxy構成のためのものです。

resource <resource> {
  net {
    on-congestion pull-ahead;
    congestion-fill 2G;
    congestion-extents 2000;
    ...
  }
  ...
}

通常は congestion-fillcongestion-extentspull-ahead オプションと合わせて設定するのがよい方法でしょう。

congestion-fill の値は以下の値の90%にするとよいでしょう。

  • DRBD Proxy越しの同期の場合のDRBD Proxyのバッファメモリの割り当て、または
  • DRBD Proxy構成でない環境でのTCPネットワークの送信バッファ

congestion-extents の値は、影響するリソースの al-extents に設定した値の90%がよいでしょう。

11.13. I/Oエラー処理方針の設定

DRBDが 下位レベルI/Oエラーを処理する際の方針は、リソースの /etc/drbd.confdisk セクションの on-io-error で指定します。

resource <resource> {
  disk {
    on-io-error <strategy>;
    ...
  }
  ...
}

すべてのリソースのグローバルI/Oエラー処理方針を定義したい場合は、これを common セクションで設定します。

<strategy> は以下のいずれかを指定します。

detachこれがデフォルトで、推奨オプションです。下位レベルI/Oエラーが発生すると、DRBDはそのノードの下位デバイスを切り離し、ディスクレスモードで動作を継続します。

pass-on上位層にI/Oエラーを通知します。プライマリノードの場合は、マウントされたファイルシステムに通知されます。セカンダリノードの場合は無視されます(セカンダリノードには通知すべき上位層がないため)。

call-local-io-errorローカルI/Oエラーハンドラとして定義されたコマンドを呼び出します。このオプションを使うには、対応する local-io-error ハンドラをリソースの handlers セクションに定義する必要があります。local-io-error で呼び出されるコマンド(またはスクリプト)にI/Oエラー処理を実装するかどうかは管理者の判断です。

[注記]注記

DRBDの以前のバージョン(8.0以前)にはもう1つのオプション panic があり、これを使用すると、ローカルI/Oエラーが発生するたびにカーネルパニックによりノードがクラスタから強制的に削除されました。このオプションは現在は使用できませんが、 local-io-error / call-local-io-error インタフェースを使用すると同じような動作を実現します。ただし、この動作の意味を十分理解した上で使用してください。

次のコマンドで、実行中のリソースのI/Oエラー処理方針を再構成することができます。

  • /etc/drbd.d/<resource>.res のリソース構成の編集
  • 構成の対向ノードへのコピー
  • 両ノードでの drbdadm adjust <resource> の実行

11.14. レプリケーショントラフィックの整合性チェックを設定

レプリケーショントラフィックの整合性チェック はデフォルトでは有効になっていません。有効にする場合は、/etc/drbd.conf のリソース構成に次の行を追加します。

resource <resource>
  net {
    data-integrity-alg <algorithm>;
  }
  ...
}

<algorithm> は、システムのカーネル構成内のカーネルcrypto APIでサポートされる任意のメッセージダイジェストアルゴリズムです。通常は sha1md5crc32c から選択します。

既存のリソースに対してこの変更を行う場合は、drbd.conf を対向ノードと同期し、両方のノードで drbdadm adjust <resource> を実行します。

[警告]警告

この機能は本番環境での使用は想定していません。データ破壊の問題や、通信経路(ネットワークハードウェア、ドライバ、スイッチ)に障害があるかどうかを診断する場合にのみ使用してください。

11.15. リソースのサイズ変更

11.15.1. オンライン拡張

動作中(オンライン)に下位ブロックデバイスを拡張できる場合は、これらのデバイスをベースとするDRBDデバイスについても動作中にサイズを拡張することができます。その際に、次の2つの条件を満たす必要があります。

  1. 影響を受けるリソースの下位デバイスが、LVMやEVMSなどの論理ボリューム管理サブシステムによって管理されている。
  2. 現在、リソースのコネクションステータスが Connected になっている。

両方のノードの下位ブロックデバイスを拡張したら、一方のノードだけがプライマリ状態であることを確認してください。プライマリノードで次のように入力します。

# drbdadm resize <resource>

新しいセクションの同期がトリガーされます。同期はプライマリノードからセカンダリノードへ実行されます。

追加する領域がクリーンな場合には、追加領域の同期を--assume-cleanオプションでスキップできます。

# drbdadm -- --assume-clean resize <resource>

11.15.2. オフライン拡張する

外部メタデータを使っている場合、DRBD停止中に両ノードの下位ブロックデバイスを拡張すると、新しいサイズが自動的に認識されます。管理者による作業は必要ありません。両方のノードで次にDRBDを起動した際に、DRBDデバイスのサイズが新しいサイズになり、ネットワーク接続が正常に確立します。

DRBDリソースで内部メタデータを使用している場合は、リソースのサイズを変更する前に、メタデータを拡張されるデバイス領域の後ろの方に移動させる必要があります。これを行うには次の手順を実行します。

[警告]警告

これは高度な手順です。慎重に検討した上で実行してください。

  • DRBDリソースを停止します。
# drbdadm down <resource>
  • 縮小する前に、メタデータをテキストファイルに保存します。
# drbdadm dump-md <resource> > /tmp/metadata

各ノードごとにそれぞれのダンプファイルを作成する必要があります。この手順は、両方のノードでそれぞれ実行します。一方のノードのメタデータのダンプを対向ノードに コピーしないでください。DRBDは 動作しなくなります

  • 両方のノードの下位ブロックデバイスを拡大します。
  • /tmp/metadata ファイルのサイズ情報(la-size-sect)を書き換えます。la-size-sect は、必ずセクタ単位で指定する必要があります。
  • メタデータ領域の再初期化をします。
# drbdadm create-md <resource>
  • 両ノードで修正したメタデータをインポートします。
# drbdmeta_cmd=$(drbdadm -d dump-md <resource>)
# ${drbdmeta_cmd/dump-md/restore-md} /tmp/metadata
Valid meta-data in place, overwrite? [need to type 'yes' to confirm]
yes
Successfully restored meta data
[注記]注記

この例では bash パラメータ置換を使用しています。他のシェルの場合、機能する場合もしない場合もあります。現在使用しているシェルが分からない場合は、SHELL 環境変数を確認してください。

  • 再度DRBDリソースを起動します。
# drbdadm up <resource>
  • 一方のノードでDRBDリソースを昇格します。
# drbdadm primary <resource>
  • 最後に、拡張したDRBDデバイスを活用するために、ファイルシステムを拡張します。

11.15.3. オンライン縮小

[警告]警告

警告 : オンラインでの縮小は外部メタデータ使用の場合のみサポートしています。

DRBDデバイスを縮小する前に、DRBDの上位層(通常はファイルシステム)を縮小 しなければいけません 。ファイルシステムが実際に使用している容量を、DRBDが知ることはできないため、データが失われないように注意する必要があります。

[注記]注記

ファイルシステムをオンラインで縮小できるかどうかは、使用しているファイルシステムによって異なります。ほとんどのファイルシステムはオンラインでの縮小をサポートしません。XFSは縮小そのものをサポートしません。

オンラインでDRBDを縮小するには、その上位に常駐するファイルシステムを縮小した_後に_、次のコマンドを実行します。

# drbdadm resize --size=<new-size> <resource>

<new-size> には通常の乗数サフィックス(K、M、Gなど)を使用できます。DRBDを縮小したら、DRBDに含まれるブロックデバイスも縮小できます(デバイスが縮小をサポートする場合)。

[注記]注記

DRBDのメタデータがボリュームの想定される箇所に 実際に 書き込まれるように下位デバイスのリサイズ後に drbdadm resize <resource> を実行してもよいでしょう。

11.15.4. オフライン縮小

DRBDが停止しているときに下位ブロックデバイスを縮小すると、次にそのブロックデバイスを接続しようとしてもDRBDが拒否します。これは、ブロックデバイスが小さすぎる(外部メタデータを使用する場合)、またはメタデータを見つけられない(内部メタデータを使用する場合)ことが原因です。この問題を回避するには、次の手順を行います (オンライン縮小を使用出来ない場合)。

[警告]警告

これは高度な手順です。慎重に検討した上で実行してください。

  • DRBDがまだ動作している状態で、一方のノードのファイルシステムを縮小します。
  • DRBDリソースを停止します。
# drbdadm down <resource>
  • 縮小する前に、メタデータをテキストファイルに保存します。
# drbdadm dump-md <resource> > /tmp/metadata

各ノードごとにそれぞれのダンプファイルを作成する必要があります。この手順は、両方のノードでそれぞれ実行します。一方のノードのメタデータのダンプを対向ノードに コピーしないでください。DRBDは 動作しなくなります

  • 両方のノードの下位ブロックデバイスを縮小します。
  • /tmp/metadata ファイルのサイズ情報(la-size-sect)を書き換えます。la-size-sect は、必ずセクタ単位で指定する必要があります。
  • *内部メタデータを使用している場合は、メタデータ領域を再初期化します(この時点では、縮小によりおそらく内部メタデータが失われています)。

    # drbdadm create-md <resource>
  • 両ノードで修正したメタデータをインポートします。

    # drbdmeta_cmd=$(drbdadm -d dump-md <resource>)
    # ${drbdmeta_cmd/dump-md/restore-md} /tmp/metadata
    Valid meta-data in place, overwrite? [need to type 'yes' to confirm]
    yes
    Successfully restored meta data
[注記]注記

この例では bash パラメータ置換を使用しています。他のシェルの場合、機能する場合もしない場合もあります。現在使用しているシェルが分からない場合は、SHELL 環境変数を確認してください。

  • 再度DRBDリソースを起動します。

    # drbdadm up <resource>

11.16. 下位デバイスのフラッシュを無効にする

[注意]注意

バッテリバックアップ書き込みキャッシュ(BBWC)を備えたデバイスでDRBDを実行している場合にのみ、デバイスのフラッシュを無効にできます。ほとんどのストレージコントローラは、バッテリが消耗すると書き込みキャッシュを自動的に無効にし、バッテリが完全になくなると即時書き込み(ライトスルー)モードに切り替える機能を備えています。このような機能を有効にすることを強くお勧めします。

BBWC機能を使用していない、またはバッテリが消耗した状態でBBWCを使用しているときに、DRBDのフラッシュを無効にすると、 データが失われるおそれがあります したがって、これはお勧めできません。

DRBDは下位デバイスのフラッシュを、レプリケートされたデータセットとDRBD独自のメタデータについて、個別に有効と無効を切り替える機能を備えています。この2つのオプションはデフォルトで有効になっています。このオプションのいずれか(または両方)を無効にしたい場合は、DRBD設定ファイルの /etc/drbd.confdisk セクションで設定できます。

レプリケートされたデータセットのディスクフラッシュを無効にするには、構成に次の行を記述します。

resource <resource>
  disk {
    disk-flushes no;
    ...
  }
  ...
}

DRBDのメタデータのディスクフラッシュを無効にするには、次の行を記述します。

resource <resource>
  disk {
    md-flushes no;
    ...
  }
  ...
}

リソースの構成を修正し、また、もちろん両ノードの /etc/drbd.conf を同期したら、両ノードで次のコマンドを実行して、これらの設定を有効にします。

# drbdadm adjust <resource>

1台のサーバのみがBBWCがある場合[10]には、ホストセクションに以下のような設定をしてください。

resource <resource> {
  disk {
    ... common settings ...
  }

  on host-1 {
    disk {
      md-flushes no;
    }
    ...
  }
  ...
}

11.17. スプリットブレイン時の動作の設定

11.17.1. スプリットブレインの通知

スプリットブレインが 検出される と、DRBDはつねに split-brain ハンドラを呼び出します(設定されていれば)。このハンドラを設定するには、リソース構成に次の項目を追加します。

resource <resource>
  handlers {
    split-brain <handler>;
    ...
  }
  ...
}

<handler> はシステムに存在する任意の実行可能ファイルです。

DRBDディストリビューションでは /usr/lib/drbd/notify-split-brain.sh という名前のスプリットブレイン対策用のハンドラスクリプトを提供しています。これは指定したアドレスに電子メールで通知を送信するだけのシンプルなものです。root@localhost (このアドレス宛のメールは実際のシステム管理者に転送されると仮定)にメッセージを送信するようにハンドラを設定するには、split-brain handler を次のように記述します。

resource <resource>
  handlers {
    split-brain "/usr/lib/drbd/notify-split-brain.sh root";
    ...
  }
  ...
}

実行中のリソースで上記の変更を行い(ノード間で設定ファイルを同期すれば)、後はハンドラを有効にするための他の操作は必要ありません。次にスプリットブレインが発生すると、DRBDが新しく設定したハンドラを呼び出します。

11.17.2. スプリットブレインからの自動復旧ポリシー

[注意]注意

スプリットブレイン(またはその他)のシナリオの結果、データの相違状況を自動的に解決するDRBDの構成は、潜在的な 自動データ損失 を構成することを意味します。その意味をよく理解し、それを意味しない場合は設定しないでください。

[ヒント]ヒント

むしろ、フェンシングポリシー、クォーラム設定、クラスタマネージャの統合、クラスタマネージャの冗長化通信リンクなどを調べて、まず最初にデータの相違状況をつくらないようにすべてきです。

スプリットブレインからの自動復旧ポリシーには、状況に応じた複数のオプションが用意されています。DRBDは、スプリットブレインを検出したときのプライマリロールのノードの数にもとづいてスプリットブレイン回復手続きを適用します。そのために、DRBDはリソース設定ファイルの net セクションの次のキーワードを読み取ります。

after-sb-0priスプリットブレインが検出されたときに両ノードともセカンダリロールの場合に適用されるポリシーを定義します。次のキーワードを指定できます。

  • disconnect: 自動復旧は実行されません。split-brain ハンドラスクリプト(設定されている場合)を呼び出し、 コネクションを切断して切断モードで続行します。
  • discard-younger-primary: 最後にプライマリロールだったホストに加えられた変更内容を破棄して ロールバックします。
  • discard-least-changes:変更が少なかったほうのホストの変更内容を破棄してロールバックします。
  • discard-zero-changes: 変更がなかったホストがある場合は、他方に加えられたすべての変更内容を適用して 続行します。

after-sb-1priスプリットブレインが検出されたときにどちらか1つのノードがプライマリロールである場合に適用されるポリシーを定義します。次のキーワードを指定できます。

  • disconnect: after-sb-0pri と同様に split-brain ハンドラスクリプト(構成されている場合)を呼び出し、 コネクションを切断して切断モードで続行します。
  • consensus: after-sb-0pri で設定したものと同じ復旧ポリシーが適用されます。これらのポリシーを適用した後で、 スプリットブレインの犠牲ノードを選択できる場合は自動的に解決します。それ以外の場合は、disconnect を指定した場合と同様に動作します。
  • call-pri-lost-after-sb: after-sb-0pri で指定した復旧ポリシーが適用されます。 これらのポリシーを適用した後で、スプリットブレインの犠牲ノードを選択できる場合は、犠牲ノードで pri-lost-after-sb ハンドラを起動します このハンドラは handlers セクションで設定する必要があります。また、クラスタからノードを強制的に削除します。
  • discard-secondary: 現在のセカンダリロールのホストを、スプリットブレインの犠牲ノードにします。

after-sb-2priスプリットブレインが検出されたときに両ノードともプライマリロールである場合に適用されるポリシーを定義します。このオプションは after-sb-1pri と同じキーワードを受け入れます。ただし、discard-secondaryconsensus は除きます。

[注記]注記

上記の3つのオプションで、DRBDは他のキーワードも認識しますが、それらはめったに使用されないためここでは省略します。ここで説明されていないスプリットブレインの復旧キーワードに関しては drbd.conf のマニュアルページを参照ください。

たとえば、デュアルプライマリモードでGFSまたはOCFS2ファイルシステムのブロックデバイスとして機能するリソースの場合、次のように復旧ポリシーを定義できます。

resource <resource> {
  handlers {
    split-brain "/usr/lib/drbd/notify-split-brain.sh root"
    ...
  }
  net {
    after-sb-0pri discard-zero-changes;
    after-sb-1pri discard-secondary;
    after-sb-2pri disconnect;
    ...
  }
  ...
}

11.18. スタック3ノード構成の作成

3ノード構成では、1つのDRBDデバイスを別のデバイスの上に スタック (積み重ね)します。

[注記]注記

DRBD9.xでは1つの階層で複数ノードを使用できるのでスタッキングは非推奨です。詳細は 「ネットワークコネクションの定義」をご参照ください。

11.18.1. デバイススタックの留意事項

次のような事項に注意する必要があります。

  • スタックデバイス側が利用可能です。1つのDRBDデバイス /dev/drbd0 を設定して、その上位にスタックデバイス /dev/drbd10 があるとします。この場合は、/dev/drbd10 がマウントして使用するデバイスになります。
  • 下位のDRBDデバイス および スタックDRBDデバイス(上位DRBDデバイス)の両方にそれぞれメタデータが存在します。上位デバイスには、必ず 内部メタデータを使用してください。このため、3ノード構成時の使用可能なディスク領域は、 2ノード構成に比べてわずかに小さくなります。
  • スタックした上位デバイスを実行するには、下位のデバイスが プライマリロールになっている必要があります。
  • バックアップノードにデータを同期するには、アクティブなノードのスタックデバイスがプライマリモードで動作している必要があります。

11.18.2. スタックリソースの設定

次の例では alicebobcharlie という名前のノードがあり、alicebob が2ノードクラスタを構成し、charlie がバックアップノードになっています。

resource r0 {
  protocol C;
  device    /dev/drbd0;
  disk      /dev/sda6;
  meta-disk internal;

  on alice {
    address    10.0.0.1:7788;
  }

  on bob {
    address   10.0.0.2:7788;
  }
}

resource r0-U {
  protocol A;

  stacked-on-top-of r0 {
    device     /dev/drbd10;
    address    192.168.42.1:7789;
  }

  on charlie {
    device     /dev/drbd10;
    disk       /dev/hda6;
    address    192.168.42.2:7789; # Public IP of the backup node
    meta-disk  internal;
  }
}

他の drbd.conf 設定ファイルと同様に、この設定ファイルもクラスタのすべてのノード(この場合は3つ)に配布する必要があります。非スタックリソースの設定にはない、次のキーワードにご注意ください。

stacked-on-top-ofこのオプションによって、DRBDに含まれるリソースがスタックリソースであることをDRBDに知らせます。これは、通常リソース設定内にある on セクションのうちの1つを置き換えます。stacked-on-top-of は下位レベルのリソースには使用しないでください。

[注記]注記

スタックリソースにProtocol Aを使用することは必須ではありません。アプリケーションに応じて任意のDRBDのレプリケーションプロトコルを選択できます。

図11.4 単一スタックの構成

single-stacked

11.18.3. スタックリソースを有効にする

スタックリソースを有効にするには、まず、下位レベルリソースを有効にしてどちらか一方をプライマリに昇格します。

drbdadm up r0
drbdadm primary r0

非スタックリソースと同様に、スタックリソースの場合もDRBDメタデータを作成する必要があります。次のコマンドで実行します。次に、スタックリソースを有効にします。

# drbdadm create-md --stacked r0-U

この後でバックアップノードのリソースを起動し、3ノードレプリケーションを有効にします。

# drbdadm up --stacked r0-U
# drbdadm primary --stacked r0-U

この後でバックアップノードのリソースを起動し、3ノードレプリケーションを有効にします。

# drbdadm create-md r0-U
# drbdadm up r0-U

クラスタ管理システムを使えばスタックリソースの管理を自動化できます。Pacemakerクラスタ管理フレームワークで管理する方法については、「PacemakerクラスタでスタックDRBDリソースを使用する」を参照してください。

11.19. 永続的なディスクレスノード

ノードはしばしDRBDの中で永続的にディスクレスになるときがあります。以下はディスクをもつ3つのノードと永続的なディスクレスノードの構成例です。

resource kvm-mail {
  device      /dev/drbd6;
  disk        /dev/vg/kvm-mail;
  meta-disk   internal;

  on store1 {
    address   10.1.10.1:7006;
    node-id   0;
  }
  on store2 {
    address   10.1.10.2:7006;
    node-id   1;
  }
  on store3 {
    address   10.1.10.3:7006;
    node-id   2;
  }

  on for-later-rebalancing {
    address   10.1.10.4:7006;
    node-id   3;
  }

  # DRBD "client"
  floating 10.1.11.6:8006 {
    disk      none;
    node-id   4;
  }

  # rest omitted for brevity
  ...
}

永続的なディスクレスノードはビットマップスロットが割り当てられません。このようなノードのステータスは、エラーでも予期せぬ状態でもないので緑で表示されます。

[注記]注記

DRBDクライアントはワイアデータ通信の簡単な実装ですが、iSCSIの Persistent Reservations のような高度な機能はありません。しかし、仮想マシン等で使われる read, write, trim/discard, resize のような基本的なIOのみが必要な場合には、適切に動作します。

11.20. データ再配置

以下の例では、すべてのデータ領域は3台に冗長化するポリシーを想定しています。したがって最小構成で3台のサーバが必要です。

しかし、データ量が増えてくると、サーバ追加の必要性に迫られます。その際には、また新たに3台のサーバを購入する必要はなく、1つのノードだけを追加をしてデータを 再配置 することができます。

図11.5 DRBDデータ再配置

rebalance

上の図では、3ノードの各々に25TiBのボリュームがある合計75TiBの状態から、4ノードで合計100TiBの状態にしています。

データを再配置する時には、新しい ノードとDRBDリソースを削除したいノードを選択する必要があります。現在 アクティブ なノードからリソースを削除する場合には注意が必要です。DRBDが プライマリ のノードからリソースを削除する場合にはサービスを移行するか、そのノードのリソースをDRBDクライアントとして稼働させるかにしてください。通常は セカンダリ のノードから選ぶほうが簡単です(それができない場合もあるでしょうが)。

11.20.1. ビットマップスロットの用意

移動するリソースには一時的に未使用のビットマップスロット用のスペースが必要です。

drbdadm create-md の時にもう一つ割り当てます。または、drbdadm がもう1つスロットを取っておくように設定にプレースホルダを設けてもよいでしょう。

resource r0 {
  ...
  on for-later-rebalancing {
    address   10.254.254.254:65533;
    node-id   3;
  }
}
[注記]注記

このスロットを実際に利用するには以下が必要です。

  1. メタデータをダンプする,
  2. メタデータ領域を拡大する,
  3. ダンプファイルを編集する,
  4. メタデータをロードする

今後のバージョンの drbdadm ではショートカットキーが用意されます。drbdadm resize --peers N が使用できるようになる予定であり、カーネルがメタデータを書き換えられるようになります。

11.20.2. 新しいノードの用意と有効化

まずは新しいノードに(lvcreate 等で)下位のストレージリュームを作成する必要があります。 次に設定ファイルのプレイスホルダーに現在のホスト名、アドレス、ストレージのパスを書き込みます。そしてすべての必要なノードにリソース設定をコピーします。

新しいノードでメタデータを次のようにして(一度だけ)初期化します

# drbdadm create-md <resource>
v09 Magic number not found
Writing meta data...
initialising activity log
NOT initializing bitmap
New drbd meta data block sucessfully created.

11.20.3. 初期同期の開始

新しいノードでデータを受け取ります。

そのために以下のようにして既存のノードでネットワークコネクションを定義します。

# drbdadm adjust <resource>

そして新しいノードでDRBDデバイスを開始します。

# drbdadm up <resource>

11.20.4. 接続確認

この時に、新しいノードで以下のコマンドを実行してください。

# drbdadm status <resource>

他のノード すべて が接続しているか確認します。

11.20.5. 初期同期後

新しいノードが UpToDate になったらすぐに、設定中の他のノードのうち1つが for-later-rebalancing に変更できるようになり、次のマイグレーション用にキープしておけるようになります。 

[注記]注記

次の再配置用に小さなビットマップスロットしかない新規ノードに drbdadm create-md をすることにはリスクがあると思う方もいることでしょう。あらかじめIPアドレスとホスト名を用意しておくのが簡単な方法でしょう。

再度変更した設定をコピーして、以下のコマンドを

# drbdadm adjust <resource>

全ノードで実行します。

11.20.6. クリーニング

今までデータのあったノードでは、もうリソースを使用しない場合にはDRBDデバイスを次のようにして停止できます。

# drbdadm down <resource>

これで下位デバイスを使用しなくなり、他の用途で使用することができるようになります。論理ボリュームであれば lvremove でボリュームグループに戻すことができます。

11.20.7. まとめと他のステップ

1つのリソースを新しいノードに移動しました。同様の手順で1つまたはそれ以上のリソースを、クラスタ内の既存の2つまたは3つのノードの空きスペースに行う事も可能です。

再び3重の冗長化を行うのに必要な空き容量のあるノードが揃えば、新しいリソースを設定することが出来ます。

なお、上記の手順をDRBD Manageを使用して行う場合については「DRBD Manageでのデータ再配置」をご参照ください。

11.21. クォーラム設定

スプリットブレインや複製データの相違を防ぐために、フェンシングを構成する必要があります。フェンシングのすべてのオプションは、最後には冗長な通信路に依存します。それはノードが対向ノードのIPMIネットワークインタフェースに接続する形かもしれません。crm-fence-peerスクリプトの場合、DRBDのネットワークリンクが切断されたときに、pacemaker の通信が有効であることが必要になります。

一方クォーラムは完全に異なるアプローチをとります。基本的な考え方は、通信できるノードの数がノード総数の半分を超える場合、クラスタパーティションは複製されたデータセットを変更できるということです。そのようなパーティションのノードは、クォーラムを持つといいます。言い換えると、クォーラムを持たないノードは、複製されたデータを変更しないことを保証します。これはデータの相違を作成しないことを意味します。

DRBDのクォーラムの実装は、quorum リソースに majority , all または数値を設定することで有効にできます。 majority の動作が、前の文章で説明した動作になります。

11.21.1. 保証された最低限の冗長化

デフォルトでは、ディスクを持つすべてのノードがクォーラム選挙で投票権を持ちます。言い換えると、ディスクレスノードだけが持ちません。従って、3ノードクラスタでは、 Inconsistent ディスクを持つ2つのノード、UpToDate を持つ1つノードは、クォーラム投票権を持つことができます。 quorum-minimum-redundancy を設定することによって、UpToDate ノードだけがクォーラム選挙で投票権を持つように変更することもできます。このオプションは quorum オプションと同じ引数をとります。

このオプションを使用すると、サービスを開始する前に必要な再同期操作が完了するまで待機する、ということも表現できます。 したがって、データの最低限の冗長性がサービスの可用性よりも保証されることを好む方法です。金融データとサービスなどはその一例です。

以下に5ノードクラスタの設定例を示します。パーティションは少なくとも3つのノードが必要であり、そのうち2つは UpToDate である必要があります。

resource quorum-demo {
  quorum majority;
  quorum-minimum-redundancy 2;
  ...
}

11.21.2. クォーラムを失った時の動作

サービスを実行しているノードがクォーラムを失うと、すぐにデータセットの書き込み操作を中止する必要があります。これはIOがすぐにすべてのIO要求をエラーで完了し始めることを意味します。通常、これは、正常なシャットダウンが不可能であることを意味します。これはデータセットをさらに変更する必要があるためです。IOエラーはブロックレベルからファイルシステムに、ファイルシステムからユーザースペースアプリケーションに伝わります。

理想的には、IOエラーの場合、アプリケーションを単に終了させることです。これはその後、Pacemaker がファイルシステムをアンマウントし、DRBDリソースを降格させセカンダリロールに移すことを可能にします。その場合は、on-no-quorum リソースに io-error を設定してください。以下はその設定例です。

resource quorum-demo {
  quorum majority;
  on-no-quorum io-error;
  ...
}

アプリケーションが最初のIOエラーで終了しない場合は、IOをフリーズさせノードをリブートさせることもできます。以下はその設定例です。

resource quorum-demo {
  quorum majority;
  on-no-quorum suspend-io;
  ...

  handlers {
    quorum-lost "echo b > /proc/sysrq-trigger";
  }
  ...
}

11.21.3. タイブレーカーとしてのディスクレスノードを使用

クラスタ内のすべてのノードに接続されているディスクレスノードを利用して、クォーラムネゴシエーションプロセスのタイブレークを解消できます。

ノードAがプライマリで、ノードBがセカンダリである、次の2ノードクラスタを考えます。

quorum-tiebreaker-without

2つのノード間の接続が失われるとすぐに、2つのノードはクォーラムを失い、クラスタ上のアプリケーションはデータを書き込めなくなります。

quorum-tiebreaker-without-disconnect

3番目のノードCをクラスタに追加し、それをディスクレスとして構成すると、タイブレーカーメカニズムを利用できます。

quorum-tiebreaker

この場合、プライマリノードとセカンダリノードが接続を失っても、両ノードはディスクレスタイブレーカーとの接続をまだ維持しています。このため、プライマリは機能し続けることができますが、セカンダリはそのディスクをOutdatedに降格させるため、サービスをそこに移行することはできません。

quorum-tiebreaker-disconnect

同時に2つの接続が失われる場合は特別なケースであり、次に説明します。

quorum-tiebreaker-disconnect-case2

この場合、タイブレーカーノードはプライマリとパーティションを形成します。そのため、プライマリはクォーラムを維持し、セカンダリは古くなります。セカンダリのディスクの状態は "UpToDate" のままですが、クォーラムがないためにプライマリに昇格できません。

プライマリがタイブレーカーとの接続を失う可能性を考えてみます。

quorum-tiebreaker-disconnect-case3

この場合、プライマリは使用できなくなり、"クォーラム中断" 状態になります。これにより、DRBD上のアプリケーションが I/O エラーを受信します。その後、クラスタマネージャはノードBをプライマリに昇格させ、代わりにそこでサービスを実行し続けることができます。

ディスクレスタイブレーカーが "サイドを切り替える" 場合、データの相違を避ける必要があります。このシナリオを考えます。

quorum-tiebreaker-disconnect-case1a

プライマリとセカンダリ間の接続が失われ、プライマリのディスクレスノードへの接続が突然失われた場合でも、アプリケーションはプライマリ上で実行を継続しています。

この場合は、どのノードもプライマリに昇格できず、クラスタは動作を継続できません。

[注記]注記

データの分離を避けることは、サービスの可用性を確保することよりも常に優先されます。

他のシナリオを見てみます。

quorum-tiebreaker-disconnect-case2a

ここでは、アプリケーションはプライマリで実行されていますが、セカンダリは利用できません。その後、タイブレーカーはプライマリへの接続を失い、次にセカンダリに再接続します。ここで重要なのは、クォーラムを失ったノードは、ディスクレスノードに接続してもクォーラムを取り戻すことはできないことです。したがって、この場合、どのノードもクォーラムを持たず、クラスタは停止します。



[6] 例:3つのノード間接続用と最低1つの外部接続/管理用インターフェース

[7] 少なくとも、過去にあった書き込み時の状態;)

[8] 概算は ping の結果を使用しています

[9] ベンチマークなど

[10] 例えばDRサイトでは異なるハードウェアを使うでしょう