DRBD（Distributed Replicated Block Device）とは何か：DRBDの仕組みを学ぶ（1）（2/2 ページ）

障害監視ツールなどと一緒に使うことで、サービスの継続提供を助けるDRBD。Linuxカーネルに統合されている機能ですが、上手に使いこなしているでしょうか？ 本連載では、DRBDの動作や使いどころを順を追って紹介していきます。

[澤田健，株式会社サードウェア]

DRBDの基本的な構成はどんなものか？

　ここからは、DRBDの使い方を知る前に、どのような構成でどう動作するかについて、イメージをつかんでいきましょう。

基本はサーバー2台の冗長構成

　DRBDはブロックデバイス単位でリアルタイムレプリケートするためのソフトウエアです。複製（レプリケート）するので、基本はサーバー2台の冗長構成になります。一番シンプルな構成は図3のようになります。

図3　DRBDの基本構成イメージ

　左側のサーバーをプライマリ機、右側のサーバーをセカンダリ機とします。通常の運用では、プライマリ機を使用します。この際、DRBDはプライマリ機に書き込まれたデータを、もう一台のサーバー（セカンダリ機）にリアルタイムで複製します。

　ここでは、仮にプライマリ機をファイルサーバーとして考えてみましょう。

　ユーザーは常にプライマリ機にアクセスし、WordやExcelなどの「ファイル」を格納します。格納した「ファイル」のデータはリアルタイムでセカンダリ機に複製されます。セカンダリ機はユーザーにアクセスさせずに待機状態とします。

　ここまでの流れだと「セカンダリ機にリアルタイムでコピーしているということは、DRBDはバックアップにもなるのか」と思われるかもしれませんが、DRBDは残念ながらバックアップにはなりません。DRBDの目的はあくまでも「サーバーを冗長化し、サービスを継続させること」にあります。図3の例でいうと「ファイルサーバーとしての機能を提供し続けること」を目的としているといえます。

障害発生時の挙動とサービス継続

　では、サーバーを冗長化し、サービスを継続させるために、DRBDはどのような働きをしているのでしょうか？ ここでは、先ほど紹介した基本構成で障害が発生した場合を考えてみましょう。

　プライマリ機側で障害が発生したとします。障害発生時の対処方法としてプライマリ機をセカンダリ機に切り替え、セカンダリ機をプライマリ機に変更します。そしてデータの書き込み先を変更し、図4の右側のサーバーで継続します。

図4　障害発生時の切り替え

　このようにDRBD構成でサーバーを冗長化しておけば、障害が発生してもファイルサーバーとしてのサービスは継続することができます。また、リアルタイムでデータのレプリケートをしているために、サーバーは障害発生直前と同じ状態が保たれています。

　アプリケーション側にも高可用性のための機能（HA：High Availability機能）が盛り込まれていますが、サービス継続に焦点を絞った場合であれば、DRBDを使うことでシンプルな冗長構成を考えることができます。アプリケーションに依存せずに利用できるため、運用面で統一性を持たせやすい点も利点といえるでしょう。実運用では「Heartbeat」や「Corosync」のような死活監視ツールと組み合わせて利用することで、障害発生の自動検出とサーバー自動切り替えも実現できます。

　次回は、実際にDRBDに触れ、使い方を深掘りしていきます。お楽しみに！

筆者紹介

澤田健（さわだ けん）

株式会社サードウェア

さまざまなIT関連業務経験ののちに2013年よりインフラエンジニアとして

の業務に携わる。また、DRBDを始めとするオープンソースソフトウェアのサポート業務にも携わっている。ツイッターでDRBDの情報発信も行っている。TwitterID：@ksawada1979。