本章ではDRBDの有用な機能とその背景にある情報を紹介します。いくつかの機能はほとんどのユーザーにとって重要な機能ですが、別のいくつかの機能については特定の利用目的においてのみ関係します。これらの機能を使うために必要な設定方法については、DRBDの使い方およびトラブルシューティングとエラーからの回復を参照してください。任意の時点でクラスタメンバのどれか1台のみプライマリになれます。どれか1台のクラスタノードのみがデータを更新できることが保証されるため、従来の一般的なファイルシステム(ext3、ext4、XFSなど)を操作するのに最適な処理モードと言えます。一般的なハイアベイラビリティクラスタ(フェイルオーバタイプ)を実現する場合、DRBDをシングルプライマリモードで設定してください。デュアルプライマリモードデュアルプライマリモードでは、すべてのリソースが任意の時点で両方のノード上でプライマリロールになれます。両方のノードから同一のデータに同時にアクセスできるため、分散ロックマネージャを持つ共有クラスタファイルシステムの利用がこのモードには必要です。利用できるファイルシステムにはGFSやOCFS2があります。2つのノード経由でのデータへの同時アクセスが必要なクラスタシステムの負荷分散をはかりたい場合、デュアルプライマリモードが適しています。ライブマイグレーションが必要な仮想化環境などです。このモードはデフォルトでは無効になっており、DRBD設定ファイルで明示的に有効にする必要があります。特定のリソースに対して有効にする方法については、デュアルプライマリモードを有効にするを参照してください。レプリケーションのモードDRBDは3種類のレプリケーションモードをサポートしています。プロトコルA非同期レプリケーションプロトコルプライマリノードでのディスクへの書き込みは、自機のディスクに書き込んだ上でレプリケーションパケットを自機のTCP送信バッファに送った時点で、完了したと判断されます。システムクラッシュなどの強制的なフェイルオーバが起こると、データを紛失する可能性があります。クラッシュが原因となったフェイルオーバが起こった場合、待機系ノードのデータは整合性があると判断されますが、クラッシュ直前のアップデート内容が反映されない可能性があります。プロトコルAは、遠隔地へのレプリケーションに最も適しています。Proxyと組み合わせて使用すると、効果的なディザスタリカバリソリューションとなります。Proxyによる遠距離レプリケーションを参照ください。プロトコルBメモリ同期(半非同期)レプリケーションプロトコル。プライマリノードでのディスクへの書き込みは、自機のディスクに書き込んだ上でレプリケーションパケットが他機に届いた時点で、完了したと判断されます。通常、システムクラッシュなどの強制的なフェイルオーバでのデータ紛失は起こりません。両ノードに同時に電源障害が起こり、プライマリノードのストレージに復旧不可能な障害が起きると、プライマリ側にのみ書き込まれたデータを失う可能性があります。プロコトルC同期レプリケーションプロトコルプライマリノードでのディスクへの書き込みは、両ノードのディスクへの書き込みが終わった時点で完了したと判断されます。このため、どちらかのノードでデータを失っても、系全体としてのデータ紛失には直結しません。当然ながら、このプロトコルを採用した場合であっても、両ノードまたはそのストレージサブシステムに復旧できない障害が同時に起こると、データは失われます。このような特質にもとづき、もっとも一般的に使われているプロトコルはCです。レプリケーションプロトコルを選択するときに考慮しなければならない要因が2つあります。ほとんど影響しません。レプリケーションプロトコルの設定例については、リソースの設定を参照してください。2重以上の冗長性DRBD9では同時に2つ以上のクラスタノードにデータを書き込むことができます。これはスタッキングを通じても可能でしたが、DRBD9では枠を超えて32ノードまで対応しました。(実際の環境では、DRBDを通じて3重、4重、または5重の冗長化は、ダウンタイムを招く原因になることがあります。)スタッキングを用いる場合との最大の違いは、同一の階層でデータのレプリケーションを行うのでパフォーマンスの低下が少ないことです。コマンドを使用しました。オプションが有効になっていればDRBDが自動的にリソースをプライマリにして、ボリュームをマウントや書き込みが可能になります。全ボリュームがアンマウントされると、すぐにセカンダリロールに変更されます。自動プロモーションは、それが可能なクラスタ状態の時にのみ成功します。コマンドの実行が成功する場合)そうでなければ、DRBD9以前と同様にマウントやデバイスのオープンは行えません。複数の転送プロトコルDRBDは複数のネットワークプロトコルに対応しています。現在、TCPとRDMAの2つのトランスポートに対応しています。各トランスポートの実装はOSのカーネルモジュールを使用しています。含まれ、これによって実装されています。その名の通り、TCP/IPプロトコルを使ってマシン間のデータ転送を行います。DRBDのレプリケーションおよび同期フレームワークのソケットレイヤーは複数のトランスポートプロトコルに対応しています。IPv4標準的かつDRBDのデフォルトのプロトコルです。IPv4が有効なすべてのシステムで利用できます。IPv6レプリケーションと同期用のTCPソケットの設定においては、IPv6もネットワークプロトコルとして使用できます。アドレシング方法が違うだけで、動作上もパフォーマンス上もIPv4と変わりはありません。SDPSDPは、InfiniBandなどのRDMAに対応するBSD形式ソケットです。SDPはIPv4形式のアドレシングに使用しますインフィニバンドを内部接続に利用すると、SDPによる高スループット、低レイテンシのDRBDレプリケーションネットワークを実現することができます。SuperSocketsスーパーソケットはTCP/IPスタック部分と置き換え可能なソケット実装で、モノリシック、高効率、RDMA対応などの特徴を持っています。レイテンシが低いレプリケーションを実現できるプロトコルとして、DRBDはSuperSocketsをサポートしています。Solutionsが販売するハードウェアの上でのみ利用できます。カーネルモジュールを使用する事もできます。HCAsやiWARPが使えるNIC、またはRoCEが使えるNICでデータ転送をします。APIでは非常に低いCPU負荷でデータ転送が行えます。転送プロトコルの決定TCPトランスポートのCPUロード/メモリ帯域が制約要因であれば、高い転送率が可能となります。適切なハードウェアでRDMAトランスポートを使用すれば高い転送率を実現することができます。転送プロトコルはリソースのコネクションごとに設定することができます。詳細はトランスポートプロトコルの設定を参照ください。同期ならびに再同期は、レプリケーションとは区別されます。レプリケーションは、プライマリノードでのデータの書き込みに伴って実施されますが、同期はこれとは無関係です。同期はデバイス全体の状態に関わる機能です。プライマリノードのダウン、セカンダリノードのダウン、レプリケーション用ネットワークのリンク中断など、さまざまな理由によりレプリケーションが一時中断した場合、同期が必要になります。DRBDの同期は、もともとの書き込み順序ではなくリニアに書き込むロジックを採用しているため、効率的です。何度も書き込みが行われたブロックの場合でも、同期は1回の書き込みですみます。このため、同期は高速です。ディスク上のブロックレイアウトを考慮して、わずかなシークですむよう、同期は最適化されています。同期実行中は、スタンバイノードの一部のデータブロックの内容は古く、残りは最新の状態に更新されています。(不一致)と呼びます。DRBDでは、同期はバックグラウンドで実行されるので、アクティブノードのサービスは同期によって中断されることはありません。重要:データに不一致箇所が残っているノードは、多くの場合サービスに利用できません。このため、不一致である時間を可能な限り短縮することが求められます。そのため、DRBDは同期直前のLVMスナップショットを自動で作成するLVM統合機能を実装しています。これは同期中であっても対向ノードと_consistent_(一致する)一致するコピーを保証します。この機能の詳細についてはDRBD同期中の自動LVMスナップショットの使用をご参照ください。可変レート同期(8.4以降のデフォルト)の場合、DRBDは同期のネットワーク上で利用可能な帯域幅を検出し、それと、フォアグランドのアプリケーションI/Oからの入力とを比較する、完全自動制御ループに基づいて、最適な同期レートを選択します。固定レート同期の場合、同期ホストに対して送信される1秒あたりのデータ量(同期速度)には設定可能な静的な上限があります。この上限に基づき、同期に必要な時間は、次の簡単な式で予測できます。同期所要時間の予測値です。同期が必要なデータ量で、リンクが途絶えていた間にアプリケーションによって更新されたデータ量です。設定ファイルに指定した同期速度です。実際の同期速度はネットワークやI/Oサブシステムの性能による制約を受けます。固定レート同期に関する設定の詳細については同期速度の設定を参照してください。チェックサムベース同期DRBDの同期アルゴリズムは、データダイジェスト(チェックサム)を使うことによりさらに効率化されています。チェックサムベースの同期を行うことで、より効率的に同期対象ブロックの書き換えが行われます。DRBDは同期を行う前にブロックを_読み込み_ディスク上のコンテンツのハッシュを計算します。このハッシュと、相手ノードの同じセクタのハッシュを比較して、値が同じであれば、そのブロックを同期での書き換え対象から外します。これにより、DRBDが切断モードから復旧し再同期するときなど、同期時間が劇的に削減されます。同期に関する設定の詳細はチェックサムベース同期の設定をご参照ください。レプリケーションの中断DRBDが正しく設定されていれば、DRBDはレプリケーションネットワークが輻輳していることを検出することが可能です。この時、プライマリノードはセカンダリとの通信を切断するので一時的に同期しない状態になりますが、セカンダリでは整合性のとれたコピーを保持しています。帯域幅が確保されると、自動で同期が再開し、バックグラウンド同期が行われます。レプリケーションの中断は、データセンタやクラウドインスタンス間との共有接続で遠隔地レプリケーションを行うような、可変帯域幅での接続の場合に通常利用されます。輻輳のポリシーとレプリケーションの停止についてほ詳細は輻輳ポリシーと中断したレプリケーションの構成をご参照ください。オンライン照合オンライン照合機能を使うと、2ノードのデータの整合性を、ブロックごとに効率的な方法で確認できます。いうのはネットワーク帯域幅を効率的に利用することを意味しています。照合によって冗長性が損なわれることはありません。オンライン照合はCPU使用率やシステム負荷を高めます。この意味では、オンライン照合はリソースを必要とします。)で、低レベルストレージデバイスのブロックごとのダイジェストを計算します。)に転送し、そこでローカルの対応するブロックのダイジェストと照合します。ダイジェストが一致しないブロックはout-of-syncとマークされ、後で同期が行われます。DRBDが転送するのはダイジェストであって、ブロックのデータそのものではありません。このため、オンライン照合はネットワーク帯域幅をきわめて効率的に活用します。このプロセスは、照合対象のDRBDリソースを利用したまま実行できます。これが_オンライン_の由来です。照合によるパフォーマンス低下は避けられませんが、照合およびその後の同期作業全体を通じてサービスの停止やシステム全体を停止する必要はありません。オンライン照合は、週または月に1回程度の頻度でcronデーモンから実行するのが妥当です。オンライン照合機能を有効にして実行する方法や、これを自動化する方法については、オンラインデバイス照合の使用をご参照ください。レプリケーション用トラフィックの整合性チェックDRBDは、MD5、SHA-1またはCRD-32Cなどの暗号手法にもとづきノード間のメッセージの整合性チェックができます。Linuxカーネルの暗号APIが提供する機能を単に利用するだけです。したがって、カーネルが備えるアルゴリズムであれば、どのようなものでも利用可能です。本機能を有効にすると、レプリケート対象のすべてのデータブロックごとのメッセージダイジェストが計算されます。レプリケート先のDRBDは、レプリケーション用パケットの照合にこのメッセージダイジェストを活用します。データの照合が失敗したら、レプリケート先のDRBDは、失敗したブロックに関するパケットの再送を求めます。この機能を使うことで、データの損失を起こす可能性がある次のようなさまざまな状況への備えが強化され、DRBDによるレプリーションが保護されます。送信側ノードのメインメモリとネットワークインタフェースの間で生じたビット単位エラー(ビット反転)。この種のエラーは、多くのシステムにおいてTCPレベルのチェックサムでは検出できません。受信側ノードのネットワークインタフェースとメインメモリの間で生じたビット反転。TCPチェックサムが役に立たないのは前項と同じです。何らかのリソース競合やネットワークインタフェースまたはそのドライバのバグなどによって生じたデータの損傷。ノード間のネットワークコンポーネントが再編成されるときなどに生じるビット反転やデータ損傷。このエラーの可能性は、ノード間をネットワークケーブルで直結しなかった場合に考慮する必要があります。レプリケーショントラフィックの整合性チェックを有効にする方法については、レプリケーショントラフィックの整合性チェックを設定をご参照ください。なった場合に、スプリットブレインの状態に陥ります。それぞれのノードでデータの書き換えが行われることが可能になってしまうため、この状態はきわめて危険です。2つの分岐したデータセットが作られてしまう軽視できない状況に陥る可能性が高くなります。クラスタのスプリットブレインは、Heartbeatなどが管理するホスト間の通信がすべて途絶えたときに生じます。これとDRBDのスプリットブレインは区別して考える必要があります。このため、本書では次のような記載方法を使うことにします。DRBDのスプリットブレインと表記します。スプリットブレインに陥ったことを検出すると、DRBDは電子メールまたは他の方法によって管理者に自動的に通知できます。この機能を有効にする方法についてはスプリットブレインの通知をご参照ください。実施した後、根本原因を取り除くことです。ときにはこのプロセスを自動化する方がいい場合もあります。自動化のために、DRBDは以下のいくつかのアルゴリズムを提供します。プライマリに切り替わったノードのデータを切り捨てます。プライマリに切り替わったノードの変更を切り捨てます。片ノードにスプリットブレインの間にまったく変更がなかった場合、DRBDは正常に回復し、修復したと判断します。いった状況はほとんど考えられません。仮にリードオンリーでファイルシステムをマウントしただけでも、デバイスへの書き換えが起きるためです。自動修復機能を使うべきかどうかの判断は、個々のアプリケーションに強く依存します。データベースをレプリケーションしている場合を例とすると、変更量が少ないノードのデータを切り捨てるアプローチは、ある種のWebアプリケーションの場合には適しているかもしれません。変更でも自動的に切り捨てることは受け入れがたく、いかなるスプリットブレインの場合でも手動回復が望ましいでしょう。スプリットブレイン自動修復機能を使う場合、アプリケーションの特性を十分に考慮してください。DRBDのスプリットブレイン自動修復機能を設定する方法については、スプリットブレインからの自動復旧ポリシーを参照してください。ディスクフラッシュのサポートローカルディスクやRAID論理ディスクでライトキャッシュが有効な場合、キャッシュにデータが記録された時点でデバイスへの書き込みが完了したと判断されます。このモードは一般にライトバックモードと呼ばれます。このような機能がない場合の書き込みはライトスルーモードです。ライトバックモードで運用中に電源障害が起きると、最後に書き込まれたデータはディスクにコミットされず、データを紛失する可能性があります。この影響を緩和するために、DRBDはディスクフラッシュを活用します。ディスクフラッシュは書き込みオペレーションのひとつで、対象のデータが安定した(不揮発性の)ストレージに書き込まれるまで完了しません。キャッシュへの書き込みではなくディスクへの書き込みを保証します。DRBDは、レプリケートするデータとそのメタデータをディスクに書き込むときに、フラッシュ命令を発行します。実際には、DRBDはアクティビティログの更新時や書き込みに依存性がある場合などにはライトキャッシュへの書き込みを迂回します。このことにより、電源障害の可能性に対する信頼性が高まっています。DRBDがディスクフラッシュを活用できるのは、直下のディスクデバイスがこの機能をサポートしている場合に限られることに注意してください。最近のカーネルは、ほとんどのSCSIおよびSATAデバイスに対するフラッシュをサポートしています。(md)は、直下のデバイスがサポートする場合に限り、RAID-1に対してフラッシュをサポートします。デバイスマッパ(LVM2、dm-raid、マルチパス)もフラッシュをサポートしています。電池でバックアップされた書き込みキャッシュ(BBWC)は、電池からの給電による不揮発性ストレージです。このようなデバイスは、電源障害から回復したときに中断していたディスクへの書き込みをディスクにフラッシュできます。このため、キャッシュへの書き込みは、事実上安定したストレージへの書き込みと同等とみなせます。この種のデバイスが使える場合、DRBDの書き込みパフォーマンスを向上させるためにフラッシュを無効に設定するのがよいかもしれません。詳細は下位デバイスのフラッシュを無効にするをご参照ください。ある範囲のデータ領域が既に使用済みで不要になって[1]、他のデータ領域として再利用してよいことをストレージに伝えるコマンドで、どちらも同じ意味を持ちます。これらは、フラッシュストレージで使用されている機能です。フラッシュストレージ(SSD、FusionIOカードなど)では上書きが困難であり、通常は消去してから新しいデータを書き込む必要があります。