DRBDブロックストレージ同期レプリケーション本番導入｜スプリットブレイン対処・昇格フロー・検証設計

DRBDが選ばれる場面と2026年時点の立ち位置

DRBD（Distributed Replicated Block Device）は、ネットワーク越しにブロックデバイスをリアルタイムに同期するLinuxカーネルモジュールです。NFSやGlusterFSのようなファイルシステム層ではなく、ブロックレイヤーで複製するため、ゲスト側はローカルディスクとまったく同じ感覚で使えます。

クラウドが普及した2026年現在でも、オンプレミスのデータベースサーバや規制上クラウド移行が難しい基幹システムのHA（高可用性）構成として現役です。PacemakerとCorosyncを組み合わせたクラシックなスタックに加え、PostgreSQL Patroniのストレージ層として使う構成も広がっています。DRBD 9系ではマルチプライマリ構成や最大32ノードのメッシュレプリケーションがサポートされており、DRBD 8系とは設定ファイル構造が異なる点に注意が必要です。

本記事では2ノードの同期レプリケーション（プロトコルC）を前提に、本番導入に必要な設計判断・手順・検証・切り戻しを順に整理します。

アーキテクチャ設計と前提条件の整理

導入前に決めるべき事項が複数あります。後から変更が難しいものから先に固めます。

レプリケーションプロトコルの選択

DRBDのプロトコルはA（非同期）・B（半同期）・C（同期）の3種類です。本番HA用途では、書き込みがセカンダリの永続化まで完了してからアプリに完了を返すプロトコルCが標準です。ネットワーク遅延が書き込みレイテンシに直接影響するため、レプリケーション用NICは専用の低遅延回線（1GbEでも可だが10GbE推奨）を用意してください。ストレージとデータ用ネットワークを同一NICで共有すると、高負荷時にレプリケーション遅延がスパイクします。

デバイス構成とメタデータ領域

DRBDはブロックデバイスの末尾に内部メタデータ領域を確保します（デフォルト）。外部メタデータを使う場合は別パーティションを用意します。内部メタデータはシンプルですが、LVMのLVを使う場合はデバイスサイズ変更時の手順が増えます。本番ではLVM上にLVを作成し、DRBDリソースとして割り当てる構成が一般的です。

2ノード構成の最低要件：

• 両ノードに同一サイズのブロックデバイス（LVまたはパーティション）
• レプリケーション専用ネットワーク（可能であれば冗長化）
• 両ノード間のNTPまたはchrony時刻同期（スプリットブレイン判定に影響）
• fencing機構（IPMI/iDRAC/PDU等のSTONITH）

fencing機構を省略した構成はテスト環境限定と考えてください。後述するスプリットブレイン発生時に自動回復が困難になります。

インストールから初期同期・昇格フローまで

パッケージインストールと設定ファイル

RHEL 9系／AlmaLinux 9ではELRepoリポジトリ、Ubuntu 22.04以降はAPTで配布されています。2026年時点の現行安定版はDRBD 9.1系です。

# AlmaLinux 9の場合
dnf install -y elrepo-release
dnf install -y kmod-drbd9x drbd9x-utils

# Ubuntu 24.04の場合
apt install -y drbd-utils

DRBD 9系の設定は /etc/drbd.d/ 以下にリソース単位で .res ファイルを置く構成です。グローバル設定は /etc/drbd.d/global_common.conf に集約します。以下は2ノード同期構成のリソース定義の例です（想定例）。

resource r0 {
  protocol C;
  net {
    allow-two-primaries no;
    after-sb-0pri discard-zero-changes;
    after-sb-1pri discard-secondary;
    after-sb-2pri disconnect;
  }
  on node1 {
    device    /dev/drbd0;
    disk      /dev/vg_data/lv_drbd;
    address   192.168.10.11:7789;
    meta-disk internal;
  }
  on node2 {
    device    /dev/drbd0;
    disk      /dev/vg_data/lv_drbd;
    address   192.168.10.12:7789;
    meta-disk internal;
  }
}

初期同期の実行

両ノードでリソースを作成し、片系からプライマリ昇格と初期同期を開始します。

# 両ノードで実行
drbdadm create-md r0
drbdadm up r0

# node1でのみ実行（初回同期開始）
drbdadm primary --force r0

# 同期状態の確認
drbdadm status r0

drbdadm status の出力で replication:SyncSource または replication:SyncTarget が表示され、進行率（%）が上昇すれば初期同期中です。replication:Established になれば同期完了です。大容量ディスクの初期同期は時間がかかるため、本番切り替え前夜ではなく余裕をもったスケジュールで実施してください。

フェイルオーバー時の昇格フロー

Pacemakerと組み合わせる場合、昇格はリソースエージェント（ocf:linbit:drbd）が自動制御します。手動フェイルオーバーを行う場合の基本手順は以下の通りです。

1. 現プライマリ（node1）でアプリを停止し、ファイルシステムをアンマウント
2. node1を drbdadm secondary r0 でセカンダリに降格
3. node2で drbdadm primary r0 を実行してプライマリに昇格
4. node2でファイルシステムをマウントしてアプリを起動

ステップ2と3の間に両ノードが接続状態（peer-node-state:Secondary/Unknown でなく Connected）であることを確認してから昇格してください。接続が切れた状態で昇格するとスプリットブレイン状態が引き起こされます。

スプリットブレイン：検知・対処ポリシー・手動回復

スプリットブレインとは、ネットワーク断などにより両ノードが同時にプライマリを名乗り、独立して書き込みが発生した状態を指します。DRBDが最も重大視する障害シナリオです。

自動対処ポリシーの設定方針

先述のリソース定義に含まれる after-sb-*pri の設定が自動対処ポリシーです。

• after-sb-0pri discard-zero-changes：スプリットブレイン後に両ノードがセカンダリに降格している場合（Pacemakerのfencingが成功した場合など）、変更量ゼロのノードを自動破棄して再接続します。
• after-sb-1pri discard-secondary：一方がプライマリの場合、セカンダリ側のデータを破棄してプライマリに追従させます。
• after-sb-2pri disconnect：両ノードがプライマリのままの場合は接続を切断し、手動介入を待ちます。これが最も安全なデフォルト設定です。

after-sb-2pri disconnect が発動した場合、drbdadm status の出力に split-brain が表示されます。このときは必ずどちらのノードのデータが正しいかを業務的に判断してから回復操作を行ってください。

手動回復手順

以下は「node2のデータを捨ててnode1を正とする」場合の回復手順です（想定例）。

# node2で実行（破棄するノード側）
drbdadm secondary r0
drbdadm disconnect r0
drbdadm -- --discard-my-data connect r0

# node1で実行（正とするノード側）
drbdadm connect r0

--discard-my-data は不可逆操作です。実行前にnode2のデータを別領域にスナップショット等でバックアップしてから行うことを推奨します。回復後は drbdadm status で replication:SyncTarget → replication:Established の遷移を確認してください。

よくあるつまずきとして、fencing機構が未設定の環境でネットワーク障害が発生すると、Pacemakerがnode2をfencingできないまま昇格を試みてスプリットブレインが頻発します。STONITH無効化（stonith-enabled=false）はテスト環境のみに限定してください。

本番前検証設計：確認すべき6つのシナリオ

DRBD導入後の受け入れ試験では、以下のシナリオを最低限カバーしてください。

1. 計画フェイルオーバー：手順通りにプライマリを切り替え、アプリが再起動することを確認。RTO（目標復旧時間）を計測します。
2. ネットワーク断（レプリケーション回線のみ）：レプリケーション専用NICを物理的に抜いてSplit-brainにならないこと、再接続後に同期が自動再開することを確認します。
3. プライマリノードの電源断：fencingが正常に動作してセカンダリが昇格することを確認します。fencingが失敗する場合のアラート経路も合わせて確認します。
4. 大量書き込み中のフェイルオーバー：ファイルシステムの整合性（fsck）が許容時間内に完了するかを確認します。journaledなext4またはXFSであれば通常は短時間で完了します。
5. 同期遅延（Diskless/OutOfSync状態）確認：帯域を意図的に絞った状態でWriteを行い、drbdadm status でOut-of-Sync量を確認。アプリ側に遅延アラートが届くかを確認します。
6. 手動スプリットブレイン回復の演習：本番担当者が実際に手順を実施できるかを確認します。手順書の正確さと、権限設定（sudoersの範囲）の確認も兼ねます。

検証結果は実施日時・ノード状態・所要時間を記録として残してください。特にRTOの実測値はSLA策定の根拠になります。

2026年現行環境の差分と移行時の注意点

DRBD 8系（DRBD 8.4.x）からDRBD 9系への移行では、設定ファイルの構造が大きく変わっています。DRBD 8では /etc/drbd.conf に全設定を書くスタイルが主流でしたが、DRBD 9では /etc/drbd.d/ 以下にリソース単位で分割する構成が標準です。旧設定を流用する場合は構造変換が必要です。

カーネルモジュールの観点では、RHEL 9系のカーネルアップデート後にkmod-drbd9xが自動再ビルドされない問題が過去に報告されています。DKMS（Dynamic Kernel Module Support）を利用する構成に切り替えることでカーネルアップデート追従を自動化できます。

モニタリング面では、Prometheus用の非公式エクスポーター（drbd_exporter）がコミュニティで開発されており、drbdadm status --statistics の出力をメトリクス化できます。Out-of-Sync量・レプリケーション帯域・接続状態をGrafanaで可視化し、閾値アラートを設定することが本番運用の前提となりつつあります。

Linbit社（DRBDの開発元）はDRBD 9.xのアップストリームサポートを継続しており、商用サポート版の「LINBIT SDS」ではLinstor（クラスタストレージオーケストレーター）と組み合わせたKubernetes CSIドライバも提供しています。コンテナワークロードへの展開を検討する際はこの方向性も選択肢に入ります。

DRBDはシンプルな2ノードHAから複数ノードメッシュまでカバーする成熟したOSSです。設定の複雑さはfencing設計に集中しているため、そこを丁寧に設計することが安定運用の鍵になります。