Distributed Replicated Block Device
(DRBD から転送)
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2026/05/17 03:14 UTC 版)
|
 
Distributed Replicated Block Devic® の公式ロゴマーク
|
|||
| 開発元 | LINBIT (http://www.linbit.com) | ||
|---|---|---|---|
| 最新版 |
|
||
| リポジトリ | |||
| 対応OS | Linux | ||
| 種別 | 運用管理、分散ストレージシステム | ||
| ライセンス | GPL 2.0 | ||
| 公式サイト | drbd |
||
Distributed Replicated Block Devic (DRBD) は、Linuxプラットフォームの分散ストレージシステムである。
解説
 |
この節の内容の信頼性について検証が求められています。
|
カーネルモジュール、管理アプリケーション、シェルスクリプトで構成され、高可用 (HA) クラスタで使うのが一般的である。DRBDはRAID 1に似ているが、ネットワーク上で動作する点が異なる。
DRBDはソフトウェアを指すと同時に、そのソフトウェアで管理される論理ブロックデバイスも指す。「DRBDデバイス」とか「DRBDブロックデバイス」といった呼称も見受けられるが、RAS症候群の一種であることは言うまでもない。
DRBDは自由ソフトウェアであり、GNU General Public License version 2 でライセンスされている。
運用モード
DRBDの論理ブロックデバイス（通常 /dev/drbdX で、X はマイナー番号）は既存のブロックデバイス群の上に存在し、クラスタノードを構成している。プライマリノードへの書き込みは下層のブロックデバイスへ転送され、同時にセカンダリノードへも伝播される。セカンダリノードは、書き込みデータを対応する下層のブロックデバイスへ転送する。読み出しは全てローカルに行う。
プライマリノードで障害が発生すると、クラスタ管理プロセスがセカンダリノードをプライマリ状態にする。この遷移の際に、fsckやジャーナルリプレイといったDRBD上のファイルシステムの完全性検証を必要とする場合もある。障害の発生した元のプライマリノードが復旧したら、それを再びプライマリにする場合もあり、その際にはデバイスデータの再同期が必要になる。DRBDの同期アルゴリズムは、デバイス全体ではなく停止していた間に更新されたブロックだけを再同期するもので、効率的である。
DRBDはHeartbeatクラスタマネージャと共に使うことが多いが、他のクラスタ管理フレームワークと組み合わせることもできる。Xenのような仮想化技術と組み合わせたり、Linuxの論理ボリュームマネージャと組み合わせることもできる[2]。
2007年1月にリリースされたDRBD version 8は負荷分散構成もサポートしており、両方のノードで同時に読み書きできる構成も可能である[3]。そのような構成では分散ロックマネージャが必須となる。
共用クラスタストレージに対する優位点
クラスタシステムは一般に共用ストレージを使い、クラスタリソースに使うデータを格納する。この方式には以下のような欠点があり、DRBDはこれに対処できる。
- 共用ストレージは単一障害点になりやすい。各ノードの障害に対してはサービスを継続可能だが、共有ストレージの故障はサービス停止を引き起こす。これに対応するため、共有ストレージはコントローラを含めたモジュールの多重化などで対応してきたが、結果として装置が高価なものになった。DRBDでは、データは共有されるのではなく複製されるため、ネットワーク設計等関連するモジュールの設計・設定が適切であれば、単一障害点になるようなポイントがなく、高価な装置も不要である。
- スプリットブレインシンドロームが発生すると、共用ストレージが問題となる。つまり、ノード間の通信に障害が発生し、各ノードが自分だけが動作していると判断した場合、クラスタリソースを全て獲得しようとする。すると共用ストレージに両系から同時に書き込みが発生し内容を破壊してしまう可能性がある。通常はクラスタコントローラ（クラスタソフトウェア）と共有ストレージの協調（例えばSCSI3 Persistent Reservationの利用）によりスプリットブレインに対して対処している。DRBDではデータは共有せずに複製しているので、（プライマリノードが信頼できるかセカンダリノードが信頼できるかの問題はあるが）少なくとも内容が破壊されるような事態にはならない。
- 共用ストレージとしては、SANやNASが使われ、読み込みにもなんらかのオーバーヘッドがある。通常、これらのオーバーヘッドはキャッシュ等で隠ぺいされ、ピークパフォーマンスも高価なストレージを採用することで対処することになるが、DRBDでは読み書きはローカルに行うので、相対的にオーバーヘッドが小さくなることが期待できる。当然、相対的に安価に構築が可能となる。
総じて、共有ストレージに対して、安価で冗長構成が可能となるところに、優位点がある。
課題
DRBDは安価で、かつ汎用性の高い構成で冗長化を構成できるメリットがある反面、いくつかの課題も存在する。
- ネットワーク構成が複雑になりやすい。ネットワークは冗長化を念頭におく必要があり、絶対パフォーマンスを引き上げるには10ギガビット・イーサネットを採用する必要がある。特に、10ギガビット・イーサネットを前提とした場合、FC-HBAにファブリックSWを利用した場合のほうが安価なことがある。
- 障害発生時のメタデータの消失の可能性。プライマリノードに書き込んだ後、セカンダリノードに同期される前にプライマリノード（や中間のネットワーク）で障害が発生した場合、プライマリノード・セカンダリノード間でデータが同期されていない可能性がある。この状況が許容できないアプリケーションは、セカンダリノードで正常に稼働できない可能性があり、結果として冗長化の意味を失うことがある。共有ストレージでは、原理的にこのような問題は発生しない。
- データ多重化に伴う必要容量の増加。プライマリノード・セカンダリノードともに記憶領域が必要となるため、全体として倍のストレージを準備する必要があることになる。昨今のビッグデータではペタバイト級のストレージが要求されるが、このクラスのストレージを倍の容量用意する場合、共有ストレージとの価格的優位性が低下あるいはなくなる可能性がある。片方の障害によりペタバイト級の同期が必要となる場合の、ネットワーク設備の性能や負荷に対する考慮も必要となる可能性がある。
総じて、中・小規模システムへの適用には向いているが、大規模構成への適用には向いていない可能性を考慮しなければならない。
用途
DRBDはLinuxのブロックデバイスとして次の用途に使用可能である。
- 普通のファイルシステム
- GFSやOCFS2などの共有ディスクファイルシステム
- 例えばLVMで論理ブロックデバイスとして使用する。
- ブロックデバイスへの直接アクセスを必要とするアプリケーションで使用する。
DRBDを使ったクラスタは、ファイルサーバやデータベース（MySQLなど）といった負荷に同期レプリケーションと高可用性を提供するのに使われる。
Linuxカーネルでの採用
DRBD開発者は、このソフトウェアをLinuxカーネルコミュニティに2007年7月に提出し、将来のLinuxカーネルにDRBDを含めることを希望していた[4]。長い議論の末、2010年2月24日にリリースされたLinuxカーネル 2.6.33に取り込まれた。
脚注
- ↑ “Release 9.3.2” (2026年4月23日). 2026年4月24日閲覧。
- ↑ Haas, Florian; Reisner, Philipp; Ellenberg, Lars, The DRBD User's Guide 2008年3月31日閲覧。
- ↑ Reisner, Philipp (2005年10月11日). “DRBD v8 - Replicated Storage with Shared Disk Semantics” (PDF). Proceedings of the 12th International Linux System Technology Conference. Hamburg, Germany.
- ↑ Ellenberg, Lars (2007年7月21日). “DRBD wants to go mainline”. linux-kernel (Mailing list). 2007年8月3日閲覧.
外部リンク
- “Distributed Replicated Block Devic公式サイト”. 2016年9月27日閲覧。
- “High-Availability Linuxプロジェクト公式サイト”. 2016年9月27日閲覧。
- Distributed Replicated Block Deviceのページへのリンク
