GlusterFSとDRBDの比較：複製単位・整合性・HAの選び方
EdwardMoon
GlusterFSとDRBDはいずれもネットワーク経由でデータを複製しますが、単純な代替関係にはありません。GlusterFSは複数のbrick上にファイル名前空間を提供する分散ファイルシステムで、DRBDはファイルシステムの下でブロックデバイスを複製します。まずアプリケーションが必要とするアクセスの性質を決めなければ、製品選定を誤ります。
この記事では「ファイルサーバーならGlusterFS、データベースならDRBD」と単純化せず、書き込み完了の時点、同時マウント、ネットワーク分断、quorum、fencing、heal、フェイルオーバーの責任範囲を比較します。実際の状態確認コマンドと選択用チェックリストも示します。
アーキテクチャの違い
| 項目 | GlusterFS Replica | DRBD 9 |
|---|---|---|
| 複製する層 | ファイル、ディレクトリ、メタデータ | ブロックデバイスの変更ブロック |
| I/O経路 | クライアント・FUSEが複数brickと通信 | カーネルモジュールがローカルのブロックI/Oをpeerへ転送 |
| 上位のファイルシステム | GlusterFS自身が共有名前空間を提供 | ext4・XFS、または条件付きでクラスターファイルシステムが必要 |
| 一般的なアクセス | 複数クライアントが同時マウント | single-primaryのActive-Passiveが代表的 |
| 拡張方法 | replica setを分散して容量とクライアントを拡張 | 複数peerへの複製に対応するが、分散ファイルシステムではない |
| 復旧単位 | ファイルごとのhealとsplit-brain判定 | dirty bitmapに基づくブロック再同期 |
選択の基本
- 複数サーバーが同じファイルツリーを同時に読み書きするなら、GlusterFSの共有ファイル機能を検討する。
- 1つのサービスのローカルブロックデバイスを別ノードへ引き継いで動かすなら、DRBD single-primaryを検討する。
- どちらも複製はバックアップではなく、削除、ランサムウェア、論理エラーも複製される場合がある。
書き込み完了と遅延
GlusterFSのreplica volumeでは、クライアントがAFR層を通じてreplica setのbrickへファイル操作を送ります。障害後はhealが必要になる場合があり、分断された双方で同じファイルが変更されると、正しいコピーを自動判定できないsplit-brainが起こり得ます。replica数を増やすだけでquorum方針が完成するわけではありません。
DRBDのProtocol Cは、ローカルとリモートのディスク書き込みを確認してから上位層へ完了を返す同期複製です。1ノード喪失時のRPOを小さくできる一方、通信の往復遅延と両ストレージの書き込み遅延がアプリケーションへ反映されます。Protocol A・Bでは完了基準が異なるため、DRBDが常に同期式だと決めつけないでください。
ブロックが一致していても、データベーストランザクションやファイルシステムが正常とは限りません。電源断時のキャッシュの永続性、ファイルシステムのジャーナル、アプリケーションのfsync、強制終了からの復旧を別途検証します。
同時アクセスの正確な意味
GlusterFSは複数クライアントからのマウントを想定していますが、brickの下層ディレクトリをアプリケーションが直接読み書きする方法は、対応する共有アクセス経路ではありません。AFRの整合性とhealメタデータを維持するため、必ずGlusterクライアントプロトコルを通してください。
DRBD single-primaryでは、ext4やXFSなどの通常のファイルシステムを1つのPrimaryだけでマウントする構成が標準的です。dual-primaryにも対応しますが、同時マウントにはGFS2・OCFS2など分散ロックを備えたクラスターファイルシステムとfencingが必要です。通常のXFSを2ノードから同時マウントすると、ファイルシステムが破損する場合があります。
quorumとsplit-brain
replica 2はネットワーク分断時に整合性と可用性を同時に最大化できません。Gluster公式資料では、replica 3またはarbiter volumeとclient quorumを、split-brainのリスクを減らす方法として説明しています。arbiterはデータ全体の3つ目のコピーではなく、メタデータを使って正しい側を判定する投票役です。
GlusterFSの状態を読み取り専用で確認する
sudo gluster peer status
sudo gluster volume list
sudo gluster volume info <VOLNAME>
sudo gluster volume status <VOLNAME> detailhealとsplit-brainの一覧を確認する
sudo gluster volume heal <VOLNAME> info summary
sudo gluster volume heal <VOLNAME> info
sudo gluster volume heal <VOLNAME> info split-brainsplit-brainの復旧時にサイズや更新時刻だけでsource brickを選ぶと、正常なデータを上書きするおそれがあります。アプリケーション管理者と正本を決め、バックアップを確保してから、ファイルごとの復旧手順を適用します。
現在のquorumオプションを確認する
sudo gluster volume get <VOLNAME> cluster.quorum-type
sudo gluster volume get <VOLNAME> cluster.quorum-count
sudo gluster volume get <VOLNAME> cluster.server-quorum-type
sudo gluster volume get <VOLNAME> all | grep -Ei 'quorum|arbiter'DRBD 9の役割、プロトコル、quorum
DRBDリソースはPrimaryまたはSecondaryの役割を持ちます。single-primaryが一般的なHA構成ですが、DRBD 9は2ノード専用ではなく、1リソースを複数ホストへ複製できます。ただし、ノードが増えると接続、メタデータ、再同期、quorum設計が複雑になります。対応可能であることと、運用に適することを区別してください。
DRBDの状態と複製の進行を確認する
sudo drbdadm status
sudo drbdsetup status --statistics
cat /proc/drbd
journalctl -k -b | grep -i drbd変更前にdry-runを行う
sudo drbdadm -d adjust <RESOURCE>
sudo drbdadm dump <RESOURCE>DRBD自身は、生き残ったSecondaryをPrimaryへ昇格させてアプリケーションを起動しません。Pacemaker、DRBD Reactor、または厳密な手動手順で、サービス停止、アンマウント、役割変更、マウント、VIPとサービスの起動順序を管理する必要があります。
quorumと役割を確認する
sudo drbdsetup status --verbose --statistics
sudo drbdadm status <RESOURCE>
# Pacemakerを併用する場合
sudo crm_mon -1Arf2ノードだけの構成で通信が切れると、どちらが稼働する正本なのかをネットワークだけで判定できません。DRBD 9のdiskless tiebreaker・quorum、Pacemakerのfencing・STONITH、独立した電源とネットワーク経路を併せて設計してください。
フェイルオーバーの違い
| 段階 | GlusterFS | DRBD |
|---|---|---|
| 障害検出 | クライアントがbrick接続失敗を検出 | peer接続・ディスク状態の変化を検出 |
| 書き込み許可の判断 | AFR client quorumとvolume状態 | 役割、disk state、DRBD quorum |
| データ経路の切り替え | クライアントが稼働中のbrickと通信 | クラスター管理ソフトが昇格、マウント、サービス起動を実施 |
| 復旧 | ファイル単位のhealとsplit-brain判定 | ブロック再同期と役割への再参加 |
| 必要な外部要素 | 正常な複数volfile serverと監視 | 通常はクラスター管理ソフトとfencing |
GlusterFSの経路回避とDRBDのサービスフェイルオーバーは、同じ「自動切り替え」ではありません。前者は分散ファイルクライアントのI/O経路の変更で、後者はブロックデバイス上のファイルシステムとアプリケーションまで順に移すクラスター操作です。
ワークロード別の選択
以下はアクセス方式に基づく比較です。新規導入前には、GlusterFSコミュニティまたはディストリビューション提供元のセキュリティサポートと、DRBD kernel module・utilsのホストカーネル互換性を別途確認します。機能が要件に合っていても、保守可能なパッケージ供給元がなければ運用候補から外してください。
| 要件 | 優先して検討 | 理由と注意点 |
|---|---|---|
| 複数Webノードでアップロードファイルを共有 | GlusterFS | 同時ファイルアクセスに適するが、小ファイル性能とhealを検証する |
| ローカルFSを使う単一DBのActive-Passive | DRBD | Protocol Cとクラスター管理を検討し、DB固有の複製方式とも比較する |
| 水平拡張するオブジェクトストレージ | 両方とも再検討 | S3互換ストレージの方がアクセス要件に合う場合がある |
| VMライブマイグレーション | 条件付きでDRBD | dual-primary、クラスターFS、fencing、または専用の仮想化連携が必要 |
| 大容量の読み取り専用配布物 | GlusterFSまたはオブジェクトストレージ | キャッシュ、CDN、配布パイプラインも比較する |
| バックアップと長期保存 | どちらも単独では不足 | バージョン、不変性、遠隔地からの復旧を備えた別のバックアップが必要 |
選択前に答えるべきこと
- 複数ノードが同じファイルシステムへ同時に書く必要があるか、1ノードだけでよいか。
- 許容RPO・RTOはどれほどか。同期複製の遅延を許容できるか。
- ネットワーク分断時に可用性と整合性のどちらを優先するか。
- quorumとfencingのための独立した3つ目の投票経路があるか。
- 正常複製、縮退状態での書き込み、再同期中の性能をそれぞれ測定したか。
- 削除、破損、ランサムウェアに備えた独立バックアップと実際の復旧試験があるか。
運用チェックリスト
- 複製リンクをサービストラフィックから分離し、遅延、損失、帯域幅を監視する。
- 正常時だけでなく、1ノード障害、リンク断、再起動、再同期中のサービスを試験する。
- GlusterFSのheal backlogとsplit-brain、DRBDのrole・disk・connection・quorumを警報対象にする。
- 運用者が任意に両側を書き込み可能にするforce手順を、通常のrunbookから除く。
- 複製とは別に、保持期間を定めた不変・遠隔地バックアップを運用し、定期的に復元を検証する。
公式資料と関連ガイド
- GlusterFSのボリューム構成
- GlusterFSのhealとsplit-brain
- GlusterFSのarbiterとquorum
- DRBD 9公式ユーザーガイド
- GlusterFS構築ガイド
- DRBD・Pacemaker構築ガイド
まとめ
選択の中心は製品名ではなく、共有ファイルとブロックデバイスのフェイルオーバーのどちらが必要かという点です。GlusterFSはファイル単位の分散名前空間とheal、DRBDはブロック複製と明示的な役割変更を提供します。どちらもquorum、fencing、状態監視、独立バックアップを含む障害モデル全体を設計して初めて、高可用性を実現できます。