DRBDでブロックデバイスを複製する本番HA設計｜同期モード選択と分断時のスプリットブレイン対処

DRBDが本番HA構成で選ばれ続ける理由

DRBD（Distributed Replicated Block Device）は、Linuxカーネルのブロックデバイス層でディスクを2ノード間にリアルタイム複製するOSSです。2024年にDRBD 9系がLinuxカーネルメインラインに正式マージされたことで、カーネルモジュールの別途管理が不要になりつつあり、運用コストが大きく下がりました。

ファイルシステムやデータベースの種類を問わず、ブロックデバイスそのものを複製するアーキテクチャは、アプリケーション層の改修なしにHAを実現できる点で依然として有力です。Pacemaker/Corosyncと組み合わせたActive/Standby構成は、PostgreSQLやMariaDBのデータディレクトリ保護に現場で広く使われています。

同期プロトコルA・B・Cの選択基準

DRBDの書き込み完了タイミングは3つのプロトコルで制御されます。本番運用でどれを選ぶかは、レイテンシ許容量とデータ損失許容量のトレードオフで決まります。

• プロトコルA（非同期）：プライマリ側のディスク書き込みとTCPバッファへの書き出しが完了した時点でアプリケーションに応答を返します。スタンバイへの転送は非同期です。広域レプリケーションや帯域の狭い拠点間で使われますが、フェイルオーバー時に未転送分のデータが失われるリスクがあります。
• プロトコルB（メモリ同期）：スタンバイ側のメモリ受信を確認してから応答を返します。スタンバイ側のディスクへの書き込みは保証されないため、スタンバイノードごと電源断すると損失が生じえます。AとCの中間的な選択肢です。
• プロトコルC（同期）：スタンバイ側のディスク書き込み完了まで待機してから応答を返します。RPO（目標復旧時点）をゼロに近づけたい本番DBサーバーでは、レイテンシが許す限りCを選ぶのが定石です。同一データセンター内の低レイテンシ接続（1ms以下）であれば、スループットへの影響は実用範囲に収まります。

レイテンシが10msを超えるようなWAN構成でプロトコルCを強制すると、書き込みのたびにアプリケーションが待機させられ、実用的なスループットが出ません。そうした環境ではプロトコルAとバックアップによるRPO設計を組み合わせる判断が現実的です。

2ノード構成の基本セットアップ手順

以下はRHEL系（AlmaLinux 9 / Rocky Linux 9）を前提にした手順例です。Ubuntu 24.04 LTSでもパッケージ名が一部異なるだけで流れは同じです。

まずelrepo経由でDRBDをインストールします。カーネル9.1系はAlmaLinux 9のkABI対応モジュールが提供されています。

# 両ノードで実施
dnf install -y elrepo-release
dnf install -y kmod-drbd9x drbd9x-utils

次に/etc/drbd.d/global_common.confと個別リソース定義ファイル（例：data.res）を作成します。リソース定義の要点は次の通りです。

resource data {
  protocol C;
  net {
    verify-alg sha256;
  }
  on node1 {
    device    /dev/drbd1;
    disk      /dev/sdb;
    address   192.168.10.1:7789;
    meta-disk internal;
  }
  on node2 {
    device    /dev/drbd1;
    disk      /dev/sdb;
    address   192.168.10.2:7789;
    meta-disk internal;
  }
}

meta-disk internalはデータディスク末尾にメタデータ領域を確保する設定です。専用のメタディスクを用意する場合はデバイスパスを指定します。

両ノードでリソースを初期化したあと、プライマリノードで初回同期を開始します。

# 両ノードで
drbdadm create-md data
drbdadm up data

# プライマリノードのみ（初回のみ）
drbdadm primary --force data

同期状況はdrbdadm statusまたはcat /proc/drbdで確認できます。ds:UpToDate/UpToDateが両ノードに表示されれば初期同期完了です。

スプリットブレイン発生時の対処手順

スプリットブレインは、2ノード間のネットワークが切断された状態で両ノードがプライマリに昇格した場合に起こります。DRBD自体はデータの整合性を守るために自動的に接続を拒否し、片方のノードをStandAlone状態に遷移させます。

drbdadm statusを実行するとpeer-node-id:... connection:StandAloneと表示され、dmesgにもスプリットブレイン検出のメッセージが残ります。この状態では自動での再接続は行われません。

対処の基本方針は「どちらのデータを正とするかを明示的に決定してから再同期する」です。誤った操作でデータを上書きする事故が多いため、手順を明確にしておくことが重要です。

• ステップ1：廃棄するノード（古いデータ側）を特定します。Pacemakerのフェイルオーバーログやアプリケーションのトランザクションログを照合して判断します。
• ステップ2：廃棄するノード側でdrbdadm disconnect dataを実行したあと、drbdadm secondary dataでセカンダリに降格させます。
• ステップ3：廃棄ノードでdrbdadm connect --discard-my-data dataを実行します。これにより自ノードのデータを放棄して正規プライマリからの再同期を受け入れる準備をします。
• ステップ4：正規プライマリ側でdrbdadm connect dataを実行し、再同期を開始します。drbdadm statusでresyncingが表示されることを確認します。

--discard-my-dataは取り消しのきかない操作です。実行前に廃棄対象ノードのスナップショットやバックアップを取得しておくことが、現場での標準手順として定着しています。

自動回復ポリシーの設定と限界

DRBDにはスプリットブレイン検出時の自動処理ポリシーが用意されています。split-brain-handlerディレクティブでafter-sb-0pri（接続断時に両ノードがセカンダリだった場合）、after-sb-1pri（片方がプライマリだった場合）、after-sb-2pri（両方がプライマリだった場合）をそれぞれ設定できます。

net {
  after-sb-0pri discard-zero-changes;
  after-sb-1pri discard-secondary;
  after-sb-2pri disconnect;
}

discard-secondaryはセカンダリだったノードのデータを廃棄して自動再同期するため、2priの場面では使えません。after-sb-2pri disconnectは最も安全な設定で、自動では何もせず管理者に判断を委ねます。本番環境では2priをdisconnectにしておき、判断を自動化しないことが原則です。Pacemakerのfencing（STONITH）が正しく機能していれば、そもそも両ノード同時プライマリの状況は防げますが、fencingデバイスの故障を含むシナリオを念頭に置いた設計が必要です。

2026年現行環境での運用差分と注意点

DRBD 9.2以降とsystemdを組み合わせる環境では、従来の/etc/init.d/drbdスクリプトではなくdrbd.serviceで管理します。ただしPacemakerと共存する場合は、systemdによるDRBDの自動起動を無効化し、Pacemakerのリソースエージェント（ocf:linbit:drbd）に一元管理させることが推奨されています。二重管理になるとフェイルオーバー時の競合が起きます。

# Pacemaker管理下ではsystemdの自動起動を無効化
systemctl disable drbd.service
systemctl mask drbd.service

カーネルモジュールについては、RHEL 9系ではkABI安定版モジュールがelrepoから提供されていますが、カーネルアップデートのたびにモジュールの互換確認が必要です。DKMS版はカーネル更新時に自動再ビルドされますが、ビルド失敗時にDRBDが起動しない事態を避けるため、カーネルアップデートはステージング環境で先行検証する運用が広がっています。

Ubuntu 24.04 LTSではDRBD 9.xが公式リポジトリに含まれており、apt install drbd-utilsで導入できます。カーネルモジュールはlinux-modules-extra-$(uname -r)パッケージに同梱されているため、別途elrepoのような外部リポジトリは不要です。この点はRHEL系との大きな差分です。

ネットワーク構成では、DRBDのレプリケーション専用インターフェースを用意することが強く推奨されます。本番トラフィックと同一NICを共有すると、高負荷時にレプリケーション遅延が生じてスプリットブレインの引き金になります。NICボンディングとの組み合わせで冗長化するのが現在の標準的な構成です。

verify-alg（sha256など）を設定してオンライン整合性検証を定期実行することも、長期運用では欠かせません。drbdadm verify dataをcronやsystemd timerで週次実行し、不一致ブロックをゼロに保つ運用が現場のベストプラクティスとして定着しています。