分散複製型ブロック・デバイス、DRBD による高可用性

Linux と DRBD による高可用性ストレージ

Linux® カーネル 2.6.33 で、DRBD (Distributed Replicated Block Device) と呼ばれる便利な新しいサービスが導入されました。実行中にネットワーク接続された別のホストにブロック・デバイス全体をミラーリングするこのサービスは、ブロック・データの高可用性クラスターの開発を可能にします。この記事を読んで、DRBD を支える概念と Linux カーネルでの DRBD 実装について学んでください。

M. Tim Jones, Independent author

M. Tim JonesM. Tim Jones は組み込みソフトウェアのエンジニアであり、『Artificial Intelligence: A Systems Approach』、『GNU/Linux Application Programming』現在、第 2 版です) や『AI Application Programming』(こちらも現在、第 2 版です)、それに『BSD Sockets Programming from a Multilanguage Perspective』などの著者でもあります。技術的な経歴は静止軌道衛星用のカーネル開発から、組み込みシステム・アーキテクチャーやネットワーク・プロトコル開発まで、広範にわたっています。また、コロラド州ロングモン所在のEmulex Corp. の顧問エンジニアでもあります。



2010年 8月 04日

Tim とつながるには

Tim は developerWorks で人気の高いお馴染みの著者の 1 人です。Tim が書いたすべての developerWorks 記事を閲覧してみてください。また、My developerWorks では、Tim のプロフィールを調べることや、彼やその他の著者、そして他の読者とつながることができます。

データ・ミラーリングをネットワーク上で行う DRBD (Distributed Replicated Block Device) は、RAID (Redundant Array of Independent Disk) では RAID-1 に分類されます。まずは高可用性 (HA) と RAID について簡単に紹介した後、DRBD のアーキテクチャーおよび使用方法を探っていきます。

高可用性の概要

高可用性 (HA) とは、可用性を高めるためのシステム設計原則のことです。可用性 (システムが継続して稼働できる能力の指標) は、一般に 1 年間のアップタイムのパーセンテージで定義されます。例えば、あるシステムが 99% の時間利用できたとすると、1 年間のダウンタイムは 3.65 日ということになります。この 99% という値は通常、ツー・ナインと呼ばれます。この値がファイブ・ナイン (99.999%) になると、1 年間で最大のダウンタイムは 5.26 分にまで減少します。これはかなりの違いであり、ここまでの可用性を実現するには、慎重な設計と高い品質が要求されます。

HA を目的とした最も一般的な実装は、フェイルオーバーによる冗長化です。このモデルでは、例えば特定のリソースに対して複数のパスを定義し、使用中の有効なパスとは別に、障害発生時に使用するための冗長パスを用意することができます。2 つのアクセス・ポートを提供するエンタープライズ・クラスのディスク・ドライブは、この概念の好例です (一般ユーザー向けのドライブには、1 つのアクセス・ポートしかありません)。

私は Boeing 757 の機内でこの記事を書いているところですが、飛行機の 2 つの翼にはそれぞれに専用のジェット・エンジンがあります。エンジンの信頼性は極めて高いとは言え、万が一どちらかのエンジンが故障したとしても、飛行機は残りのエンジンで安全に飛行を続けることができます。これがまさに (冗長化による) HA であり、多くのアプリケーションやシナリオに適用されています。

私の初めての仕事は、静止通信衛星を作る大きな軍需会社が相手でした。これらの衛星のコアとなっていたのは放射線に耐えられるように強化されたコンピューティング・システムで、このシステムがコマンドと遠隔測定 (衛星のユーザー・インターフェース)、電源および温度の管理、そしてポインティング (電話の会話とテレビのコンテンツのフロー維持) を行います。可用性に関しては、このコンピューティング・システムは冗長設計となっており、プロセッサーとバスのセットが 2 つあり、マスターが応答しないことが判明した場合にはマスターとスレーブを切り替える機能が備わっています。要するに、システム設計での冗長化は、ハードウェア (およびソフトウェア) を追加するという代償と引き換えに可用性を高めるための一般的手法だということです。

ストレージの冗長化

Linux カーネルへの統合

Linux カーネルに DRBD を統合するプロセスは、2007年7月から始まっています。その時点での DRBD はバージョン 8.0 でした。DRBD が主流のカーネル 2.6.33 に取り込まれたのは、それから 2 年半後の 2009年12月です (DRBD バージョン 8.3.7)。現在、DRBD のリリース 8.3.8 が現行の Linux カーネル 2.6.35 に組み込まれています。

当然のことながら、ストレージ・システムを冗長化するのも一般的になっています。エンタープライズ・クラスの設計では特にそうですが、ストレージの冗長化はごく一般的に行われるため、標準手法 (RAID) で基礎とするアルゴリズムには、それぞれに異なる機能と特性を備えた多種多様なものがあります。

RAID は 1987年、カリフォルニア大学バークレー校で初めて定義されました。従来の RAID レベルには、(冗長化ではなく) パフォーマンスを目的に複数台のディスクでストライピングを実装する RAID-0、2 台のディスクでミラーリングを実装し、情報の 2 つのコピーが存在するようにする RAID-1 があります。RAID-1 の場合、一方のディスクが故障しても、もう一方のコピーから情報を入手することができます。他の RAID レベルには、パリティー・コードを複数台のディスクに分散し、ブロック単位でのストライピングを組み込む RAID-5、二重にパリティーを分散してブロック単位のストライピングを行う RAID-6 もあります。RAID-5 では 1 台のドライブの障害をサポートできる一方、RAID-6 では 2 台のドライブの故障をサポートすることができます (ただし、パリティー情報を使用するために容量の使用量が増えます)。RAID-1 は単純な仕組みですが、容量の使用効率の点で無駄があります。RAID-5 と RAID-6 はストレージ容量を節約するものの、この 2 つのレベルには通常、パリティー計算でプロセッサーに負担をかけないために追加のハードウェア処理が必要になります。このように、例によってトレードオフだらけです。図 1 に、RAID-0 と RAID-1 の方式の概略図を示します。

図 1. RAID レベル 0 およびレベル 1 の概略図
RAID レベル 0 およびレベル 1 の概略図

RAID 技術はいわゆる非標準手法の数々を取り込んで、今でも進化し続けています。これらの非標準手法には、RAID-5 の書き込みホール問題を解決する Oracle の RAID-Z スキーマ、RAID-6 を拡張した NetApp の RAID-DP (Diagonal Parity の略)、奇数台のディスクでストライピング (RAID-0) とミラーリング (RAID-1) を実装する IBM の RAID 1E (Enhanced の略) などが挙げられます。また、この他にも従来からの RAID 方式、新しい RAID 方式がさまざまにあります。詳細については「参考文献」のリンクを参照してください。


DRBD の動作

アーキテクチャーの詳細を探る前に、DRBD の基本的な動作をおさえておきましょう。図 2 は、2 台のサーバーが独自のストレージ・リソースを提供するというコンテキストでの DRBD の概略図です。一般に、2 台のサーバーの一方はプライマリー・サーバーとして定義され、もう一方は (通常はクラスタリング・ソリューションの一部として) セカンダリー・サーバーとして定義されます。ユーザーは、従来のローカル・ブロック・デバイスあるいはストレージ・エリア・ネットワーク (ネットワークで接続されたストレージ) ソリューションとして DRBD ブロック・デバイスにアクセスします。プライマリー・サーバーとセカンダリー・サーバーとの間でのユーザー単位の読み取り/書き込み操作の同期、そしてその他の同期操作は、DRBD ソフトウェアが行います。

図 2. 基本的な DRBD 動作モデル
基本的な DRBD 動作モデル

現用/予備モデルでは、すべてのユーザーの書き込み/読み取り操作にプライマリー・ノードが使用されます。クラスタリング・ソリューションでプライマリー・ノードの停止状態が検出されると、セカンダリー・ノードがプライマリー・ノードにプロモートされます。プライマリー・ノードで書き込み操作が実行されると、ローカル・ストレージだけでなく、セカンダリー・ストレージに対しても同時に書き込みが行われます (図 3 を参照)。DRBD が書き込み操作に対してサポートするモードには、完全同期モード、非同期モードの 2 つがあります。

完全同期モードでは、書き込み操作が両方のノードのストレージで正常に完了した後で、ライターに対して書き込みトラザクションの完了が通知されます。非同期モードで書き込みトランザクションが完了したと通知されるのは、書き込みデータがローカル・ノードのストレージに保管された時点です。この場合、データはバックグラウンドでピア・ノードに複製されます。非同期モードでは、データが複製される前に障害が発生する可能性が残されているため、完全同期モードと比べると安全性に劣りますが、速度には勝っています。データを保護するためには、最も安全なモードとして完全同期モードが推奨されるものの、非常に距離の離れた地点間 (地理的災害回復のシナリオでのワイド・エリア・ネットワークなど) で複製が行われる場合には、非同期モードが役立ちます。一方、読み取り操作はローカル・ストレージを使用して行われます (ただし、ローカル・ディスクで障害が発生した場合には、セカンダリー・ノードを介してセカンダリー・ストレージが使用されます)。

図 3. DRBD での読み取り/書き込み操作
DRBD での読み取り/書き込み操作

DRBD は、現用/現用モデルもサポートします。このモデルでは、いわゆる共有ディスク・モードの状態で、読み取り/書き込み操作が両方のサーバーで同時に行われます。この共有ディスク・モードでは、GFS (Global File System) や OCFS2 (Oracle Cluster File System version 2) などの分散ロック管理機能を備えた共有ディスク・ファイルシステムが必須です。


DRBD のアーキテクチャー

DRBD は 2 つの独立した部分で構成されます。1 つは、DRBD の振る舞いを実装するカーネル・モジュール、もう 1 つは DRBD ディスクの管理に使用するユーザー空間の管理アプリケーション一式です (図 4 を参照)。カーネル・モジュールは、(ネットワーク上でローカル・ディスクとリモート・ディスクとの間で複製される) 仮想ブロック・デバイス用のドライバーを実装します。また DRBD は仮想ディスクとして、多種多様なアプリケーション (ファイルシステムから、データベースなどのロー・ディスクを利用可能なアプリケーションまで) が利用できる柔軟なモデルになります。DRBD モジュールは、ベースで使用されるブロック・ドライバー (drbd.conf のディスク構成項目で定義) へのインターフェースを実装するだけでなく、ネットワーク・スタック (そのエンドポイントは、同じく drbd.conf の IP アドレスとポート番号で定義) へのインターフェースも実装します。

図 4. Linux アーキテクチャーでの DRBD
Linux アーキテクチャーでの DRBD

ユーザー空間に DRBD が提供するのは、複製されたディスクを管理するための一連のユーティリティーです。Linux カーネルで DRBD モジュールを構成するには drbdsetup ユーティリティーを使用し、DRBD のメタデータ構造体を管理するには drbdmeta を使用します。この 2 つのユーティリティーの両方を使用するのが、ラッパー・ユーティリティーの drbdadm です。この高度な管理ツール drbdadm は、とても一般的に使われているツールであり (/etc/drbd.conf の DRBD 構成ファイルから詳細を取得します)、前述のユーティリティーへのフロントエンドとして、DRBD を管理するために最もよく使われます。

DRBD はディスク・モデルを使用して、通常のディスクとまったく同じように使える特殊なデバイス (/dev/drbdX) をエクスポートします。リスト 1 に、ファイルシステムを作成して、ホストが使用できるように DRBD をマウントする方法を示します (このリストではその他の必要な構成ステップは省略しています。これらのステップについては、「参考文献」セクションを参照してください)。

リスト 1. プライマリー DRBD ディスクでのファイルシステムの作成およびマウント
# mkfs.ext3 /dev/drbd0
# mkdir /mnt/drbd
# mount -t ext3 /dev/drbd0 /mnt/drbd

DRBD が提供する仮想ディスクは、他のあらゆるディスクと同じように使用することができます。複製は、水面下でトランスペアレントに行われます。それでは次に、自己回復機能などの DRBD の主要な機能をいくつか紹介します。


DRBD の主要な機能

複製型ディスクの概念は理論的には単純です (開発するのも比較的容易です)。けれども堅牢な実装となると、複製型ディスクに特有の複雑さを伴います。例えば、ブロックをネットワークで接続されたドライブに複製するのは極めて簡単ですが、障害と一時的機能停止 (そしてその後のドライブの同期) を扱うところから、真のソリューションが始まります。このセクションでは、DRBD がサポートする多様な障害モデルを含め、DRBD が提供する主要な機能について説明します。

複製モード

この記事の前半で、ノード間でのさまざまなデータ複製モデル (具体的には、完全同期と非同期の 2 つ) について検討しましたが、DRBD がサポートする各手法のバリエーションは、パフォーマンスを若干犠牲にするものの、非同期よりも多少強力にデータを保護します。メモリー同期 (半同期) モードは、同期と非同期両方のバリエーションです。このモードでの書き込み操作は、データがローカル・ディスクに保管されてピア・ノードのメモリーにミラーリングされてから、書き込みトランザクションが完了したと通知されます。メモリー同期モードでは、データが不揮発性ディスクではなく、別のノードの揮発性メモリーに直接ミラーリングされるため、データ保護を強化することができます。データを失う可能性がなくなるわけではありませんが (例えば、両方のノードに障害が発生した場合)、プライマリー・ノードに障害が発生しても、データはすでに複製されているため、データ損失という結果を招くことはありません。

オンライン・デバイス検証

DRBD では、オンライン形式で (入力/出力が行われている間に) ローカル・デバイスとピア・デバイスを検証することができます。オンラインで検証するということは、ローカル・ディスクとリモート・ディスクのどちらかがもう一方のディスクの複製であることを DRBD が検証するという意味なので、時間のかかる操作になる可能性があります。けれども DRBD ではノード間でデータをやり取りして検証するのではなく、遥かに効率的な手法を採用しています。ノード間の帯域幅 (おそらく制約されたリソース) を確保するため、DRBD は検証のためにノード間でデータそのものを移動することはせず、暗号化されたデータのダイジェスト (ハッシュ) を受け渡します。この方法では、ノードはブロックのハッシュを計算して、大幅に小さいサイズのシグニチャーをピア・ノードに転送することになります。同じくピア・ノードもハッシュを計算して、両方のハッシュを比較します。両方のハッシュが同じであれば、ブロックは正しく複製されているということです。ハッシュが同じでない場合は、古くなったブロックに同期外れのマークが付けられることになり、その後の同期でブロックを適切に同期させることができます。

通信の完全性

ノード間での通信が原因で、複製されたデータにエラーが発生する可能性もあります (ソフトウェアやファームウェアのバグ、あるいは TCP/IP のチェックサムでは検出されないエラーなどが原因です)。データの完全性を確実にするため、DRBD はメッセージ完全性コードを計算して、ノード間で送受信されるデータに添付します。これにより、受け取り側のノードは受信したデータを検証し、エラーを検出した場合には再送信を要求することができます。DRBD は Linux の暗号化アプリケーション・プログラミング・インタフェースを利用するため、使用される完全性アルゴリズムについては柔軟に対応します。

自動回復

DRBD はさまざまな種類のエラーから回復できますが、エラーのなかで最もたちの悪いのは、いわゆる「分離脳」という事態です。このエラーのシナリオでは、ノード間での通信リンクが切断され、両方のノードのそれぞれがプライマリー・ノードであると自認します。プライマリーとして、それぞれのノードは書き込み操作を許可しますが、これらの操作は他方のノードには伝播されていません。そのため、各ノードのストレージが矛盾するという結果につながります。

大抵の場合、分割脳からの回復は手動で行われますが、DRBD ではこの事態から自動的に回復するための手段をいくつか用意しています。使用される回復アルゴリズムは、ストレージが実際にどのように使用されているかによって異なります。

リンクがダウンしている間、一方のノードで何の変更も行われていなければ、分割脳の発生後にストレージを同期させるのはごく簡単です。この場合、変更が行われた方のノードが、その変更をピアに同期させるだけでよいのです。別の単純な方法としては、変更数の少ない方のノードから変更を破棄するという方法もあります。こうすると、変更数の多い方のノードをそのままの状態で維持することはできますが、もう一方のホストに対する変更は失われることになります。

別の 2 つの手法では、ノードの一時的状態に基づいて変更を破棄します。1 つは、最後にプライマリーに切り替えられたノードから変更を破棄するという手法、もう 1 つは、最も古いプライマリー・ノード (最初にプライマリーに切り替えられたノード) から変更を破棄するという手法です。これらのノードは DRBD 構成ファイルで個別に操作することができますが、ノードをどのように使用するかは、最終的にはストレージを使用するアプリケーション、そしてデータを破棄できるか、あるいは手動による回復が必要かどうかによって決まります。

同期の最適化

複製型ストレージ・デバイスの重要な側面となるのは、ノード間のデータを効率的に同期させる方法です。DRBD が使用する同期方式には、アクティビティー・ログと簡易同期ビットマップの 2 つが含まれます。アクティビティー・ログは、最近書き込みが行われたブロックを保管し、障害の解消後に同期が必要となるブロックを定義します。簡易同期ビットマップは、接続切断中に同期 (または同期外れ) しているブロックを定義します。ノードの接続が回復すると、このビットマップを使用した同期によって、素早くノードを同期させ、ノード同士の正確な複製にすることができます。同期にかかる時間は重要です。なぜなら、この時間中にセカンダリー・ディスクと整合しなくなる可能性があるためです。


まとめ

データの可用性向上を目指しているとしたら、例え商用ハードウェアに対してでも DRBD は素晴らしい資産となります。DRBD をカーネル・モジュールとしてインストールするのも、使用可能な管理ツールとラッパーを使って構成するのも簡単です。さらに嬉しいことに、DRBD はオープンソースなので、必要に応じてカスタマイズすることができます (ただし、その前に DRBD のロードマップを調べて、必要とする作業がすでに行われているかどうかを確認してください)。DRBD は数多くの便利なオプションをサポートしているので、それぞれのアプリケーションに合わせて独自に最適化することができます。

参考文献

学ぶために

  • DRBD Web サイトに、DRBD の最新情報、現在の機能リスト、ロードマップ、この技術についての説明が記載されています。また、DRBD に関する記事とプレゼンテーションのリストもあります。DRBD は主流のカーネルに組み込まれていますが (2.6.33 以降)、最新のソース TAR 書庫を入手するには LINBIT にアクセスしてください。
  • 高可用性は、稼働率を確実にするためのシステム・プロパティーです。このプロパティーには通常、単一障害点を回避するための手段として冗長化が関わってきます。可用性を高めるには、フォールトトレランス・システム設計も重要な側面です。
  • RAID の概念は、1987年カリフォルニア大学バークレー校で誕生しました。RAID はレベル別に定義され、各レベルがストレージを保護するためのアーキテクチャーおよび特性を指定します。誕生当時の RAID の概念について詳しく学ぶには、論文「A Case for Redundant Arrays of Inexpensive Disks (RAID)」を読んでください。
  • Ubuntu に、DRBD を構成および使用する上で参考になるページが掲載されています。このページでは、プライマリー・ホストとセカンダリー・ホストでの DRBD の構成方法と、さまざまな障害シナリオで DRBD をテストする方法について説明しています。
  • DRBD は、クラスター・アプリケーションと組み合わせて使用すると特に有益です。幸い、DRBD マニュアルの「DRBDとアプリケーションの組み合わせ」セクションには、クラスター・アプリケーションや他のアプリケーション (Pacemaker, Heartbeat, Logical Volume Manager, GFS, and OCFS2 など) の詳細と、これらのアプリケーションに DRBD を統合する方法が説明されています。
  • この記事では、共有ディスク・ファイルシステムとして GFSOCFS2 に言及しました。この 2 つはどちらも、ハイパフォーマンスと HA を統合したクラスター・ファイルシステムです。
  • developerWorks Linux ゾーンで、Linux 開発者および管理者向けのハウツー記事とチュートリアル、そしてダウンロード、ディスカッション、フォーラムなど、豊富に揃った資料を探してください。
  • さまざまな IBM 製品および IT 業界についての話題に絞った developerWorks の Technical events and webcasts で時代の流れをキャッチしてください。
  • 無料の developerWorks Live! briefing に参加して、IBM 製品およびツール、そして IT 業界の傾向を素早く学んでください。
  • developerWorks の on-demand demos で、初心者向けの製品のインストールおよびセットアップから熟練開発者向けの高度な機能に至るまで、さまざまに揃ったデモを見てください。
  • Twitter で developerWorks をフォローするか、developerWorks で Linux に関するツイートのフィードに登録してください。

製品や技術を入手するために

  • ご自分に最適な方法で IBM 製品を評価してください。評価の方法としては、製品の試用版をダウンロードすることも、オンラインで製品を試してみることも、クラウド環境で製品を使用することもできます。また、SOA Sandbox では、数時間でサービス指向アーキテクチャーの実装方法を効率的に学ぶことができます。

議論するために

  • My developerWorks コミュニティーに加わってください。ここでは他の developerWorks ユーザーとのつながりを持てる他、開発者が主導するブログ、フォーラム、グループ、ウィキを調べることができます。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux
ArticleID=516732
ArticleTitle=分散複製型ブロック・デバイス、DRBD による高可用性
publish-date=08042010