DRBDのコア機能はLinuxのカーネルモジュールとして実装されています。OSのI/Oスタックの下位の階層でDRBDは仮想的なブロックデバイスを作ります。このために、DRBDは非常に柔軟で応用範囲が広く、さまざまなアプリケーションの可用性を高めるために利用できます。

その定義とLinuxカーネルアーキテクチャとの関連にもとづき、DRBDは上位レイヤに関して一切関知しません。このため、DRBDは上位レイヤに対しては何ら機能を付与できません。たとえば、DRBDはファイルシステムの障害を検出できません。またext3やXFSなどのファイルシステムに対してアクティブ-アクティブクラスタ機能を追加することもできません。

DRBDにはカーネルモジュールと通信を行う管理ツールがいくつか用意されています。トップレベルのものからボトムレベルの順に以下に説明します。

DRBD-utilsプログラムスイートの高度な管理ツール。設定ファイル /etc/drbd.conf からすべてのDRBD設定パラメータを取得し、drbdsetup と drbdmeta のフロントエンドとして機能します。drbdadm には、-d オプションを付けて呼び出すことで、実際にそれらのコマンドを呼び出さずに drbdadm が発行する drbdsetup と drbdmeta の呼び出しを表示する「ドライラン」モードがあります。

カーネルにロードされたDRBDモジュールを設定します。 drbdsetup の全パラメータはコマンドラインで指定する必要があります。 drbdadm と drbdsetup を分離していることで最大限の柔軟性を確保しています。ほとんどのユーザーは drbdsetup を使う事はないでしょう。

DRBDメタデータ構造を作成、ダンプ、復元、および変更する機能を提供します。drbdsetup と同様に、ほとんどのユーザーは直接 drbdmeta を使用する必要はほとんどありません。

DRBDでは、レプリケートするデータセットに関するさまざまな属性を総称して リソース と呼びます。リソースは以下の要素で構成されます。

個々のリソースを区別するために、ホワイトスペース以外のUS-ASCII文字で表される任意の名前を与えることができます。

どのリソースも、複数のレプリケーションストリームを共有する ボリュームのうちの１つを構成するレプリケーショングループですDRBDは、リソース内のすべてのボリューム間で書き込みの忠実性を保証します。ボリュームは 0 から番号付けされ、1つのリソースにおいて、最大で65,535ボリュームまで可能です。ボリュームにはレプリケートされたデータセットを含み、DRBD内部で使用するメタデータのセットも含みます。

drbdadm コマンドでは、リソース内のボリュームを、リソース名とボリューム名を <resource>/<volume> のように記述して指定します。

DRBDが管理する仮想的なブロックデバイスです。DRBDが管理する仮想的なブロックデバイスで、147のメジャー番号を持ち、minor番号は0から順次割り振られます。各DRBDデバイスは、リソース内の1つのボリュームに該当します。関連付けられたブロックデバイスは通常 /dev/drbdX の形式になり、 X はデバイス番号です。通常 udev は #/dev/drbd/by-res/#resource/vol-nr にあるリソース名とボリューム名を含むシンボリックリンクも作成します。

コネクション はレプリケートされるデータセットを共有する、2つのホスト間の通信リンクです。DRBD9では、各リソースが複数のホストで設定できますが、この場合、現在のバージョンではホスト間にフルメッシュ型の接続が必要です。つまり、リソース用に各ホストは他のホストへの接続が必要です。

drbdadm では、コネクションはリソース名とコネクション名(デフォルトでは対向のホスト名)で指定されます。

DRBDのすべての リソース は プライマリ または セカンダリ のどちらかのロール(役割)を持っています。

リソースのロールは、もちろん 手動で切り替えできる他に、クラスタ管理アプリケーションの何らかの自動化アルゴリズムによって、または 自動プロモーション でも切り替えられます。セカンダリからプライマリへの切り替えを 昇格 と呼びます。一方プライマリからセダンダリの切り替えは 降格 と呼びます。

DRBD のハードウェア、環境の要件と制限を以下に示します。DRBD は、数 KiB の物理ストレージとメモリで動作しますし、数 TiB のストレージと数 MiB メモリで動作するようにスケールアップもできます。

この標準は、暗号モジュールの設計および実装に使用されます。 — NIST’s FIPS 140-3 publication

DRBDバージョン9.2.6以降、 TLS機能 を使用してDRBDトラフィックを暗号化することが可能になりました。ただし、DRBD自体には暗号モジュールが含まれていません。DRBDは、ktls-utils パッケージ（ tlshd デーモンで使用される）または Linuxカーネル暗号API で参照される 暗号モジュールを使用します。いずれの場合も、DRBDがトラフィックを暗号化するために使用する暗号モジュールは、FIPS準拠であり、FIPSモードが有効になっているオペレーティングシステムを使用している限り、FIPS準拠になります。

TLS機能を有効にしていない場合、DRBDは暗号モジュールを使用しません。

DRBDのバージョン9.2.6以前では、暗号化を利用する場合、DRBD自体ではなく別のブロックレイヤーで実装する必要がありました。Linux Unified Key Setup（LUKS）はそのような実装の一例です。 LINSTORユーザーガイド には、LINSTORをDRBDレイヤーの下にLUKSレイヤーを重ねる方法についての詳細が記載されています。

シングルプライマリモードでは、個々の リソース は、任意の時点でクラスタメンバのどれか1台のみプライマリになれます。どれか1台のクラスタノードのみがデータを更新できることが保証されるため、従来の一般的なファイルシステム(ext3、ext4、XFSなど)を操作するのに最適な処理モードと言えます。

一般的なハイアベイラビリティクラスタ(フェイルオーバタイプ)を実現する場合、DRBDをシングルプライマリモードで設定してください。

デュアルプライマリモードでは、リソースは一度に 2 つのノードでプライマリの役割を担うことができます。したがって、データへの同時アクセスが可能であるため、このモードでは通常、分散ロックマネージャーを利用する共有クラスターファイルシステムを使用する必要があります。 利用できるファイルシステムには GFS や OCFS2 があります。

2つのノード経由でのデータへの同時アクセスが必要なクラスタシステムの負荷分散をはかりたい場合、デュアルプライマリモードが適しています。例えばライブマイグレーションが必要な仮想化環境などです。 このモードはデフォルトでは無効になっており、DRBD設定ファイルで明示的に有効にする必要があります。

特定のリソースに対して有効にする方法については、 デュアルプライマリモードを有効にする を参照してください。

DRBDは3種類のレプリケーションモードをサポートしています。

非同期レプリケーションプロトコルプライマリノードでのディスクへの書き込みは、自機のディスクに書き込んだ上でレプリケーションパケットを自機のTCP送信バッファに送った時点で、完了したと判断されます。システムクラッシュなどの強制的なフェイルオーバが起こると、データを紛失する可能性があります。クラッシュが原因となったフェイルオーバが起こった場合、待機系ノードのデータは整合性があると判断されますが、クラッシュ直前のアップデート内容が反映されない可能性があります。プロトコルAは、遠隔地へのレプリケーションに最も適しています。 DRBD Proxyと組み合わせて使用すると、効果的なディザスタリカバリソリューションとなります。詳しくは DRBD Proxyによる遠距離レプリケーション を参照ください。

メモリ同期(半非同期)レプリケーションプロトコル。プライマリノードでのディスクへの書き込みは、自機のディスクに書き込んだ上でレプリケーションパケットが他機に届いた時点で、完了したと判断されます。通常、システムクラッシュなどの強制的なフェイルオーバでのデータ紛失は起こりません。しかし、両ノードに同時に電源障害が起こり、プライマリノードのストレージに復旧不可能な障害が起きると、プライマリ側にのみ書き込まれたデータを失う可能性があります。

同期レプリケーションプロトコルプライマリノードでのディスクへの書き込みは、両ノードのディスクへの書き込みが終わった時点で完了したと判断されます。このため、どちらかのノードでデータを失っても、系全体としてのデータ紛失には直結しません。当然ながら、このプロトコルを採用した場合であっても、両ノードまたはそのストレージサブシステムに復旧できない障害が同時に起こると、データは失われます。

このような特質にもとづき、もっとも一般的に使われているプロトコルはCです。

レプリケーションプロトコルを選択するときに考慮しなければならない要因が2つあります。 データ保護 と レイテンシ遅延 です。一方で、レプリケーションプロトコルの選択は スループット にはほとんど影響しません。

レプリケーションプロトコルの設定例については、 リソースの設定 を参照してください。

DRBD9では同時に2つ以上のクラスタノードにデータを書き込むことができます。

これは スタッキング を通じても可能でしたが、DRBD9では枠を超えて32ノードまで対応しました。 (実際の環境では、DRBDを通じて3重、4重、または5重の冗長化は、ダウンタイムを招く原因になることがあります。)

スタッキングを用いる場合との最大の違いは、同一の階層でデータのレプリケーションを行うのでパフォーマンスの低下が少ないことです。

DRBD9以前は、リソースを昇格するときには drbdadm primary コマンドを使用しました。DRBD9では、 auto-promote オプションが有効になっていればDRBDが自動的にリソースをプライマリにして、ボリュームをマウントや書き込みが可能になります。全ボリュームがアンマウントされると、すぐにセカンダリロールに変更されます。

自動プロモーションは、それが可能なクラスタ状態の時にのみ成功します。(つまり drbdadm primary コマンドの実行が成功する場合)そうでなければ、DRBD9以前と同様にマウントやデバイスのオープンは行えません。

DRBDは複数のネットワークプロトコルに対応しています。現在、TCPとRDMAの2つのトランスポートに対応しています。各トランスポートの実装はOSのカーネルモジュールを使用しています。

DRBDは接続ごとに複数のパスを設定することができます。TCP転送では、接続ごとに通常1つのパスしか使用されませんが、 TCPロードバランシング機能 を設定している場合は複数のパスを利用できます。一方、RDMA転送では、1つの接続の複数のパスでネットワークトラフィックのバランスを取ることができます。詳細については、 複数の経路の設定 を参照してください。

同期ならびに再同期は、レプリケーションとは区別されます。レプリケーションは、プライマリノードでのデータの書き込みに伴って実施されますが、同期はこれとは無関係です。同期はデバイス全体の状態に関わる機能です。

プライマリノードのダウン、セカンダリノードのダウン、レプリケーション用ネットワークのリンク中断など、さまざまな理由によりレプリケーションが一時中断した場合、同期が必要になります。DRBDの同期は、もともとの書き込み順序ではなくリニアに書き込むロジックを採用しているため、効率的です。

DRBDでは、同期はバックグラウンドで実行されるので、アクティブノードのサービスは同期によって中断されることはありません。

DRBDが正しく設定されていれば、DRBDはレプリケーションネットワークが輻輳していることを検出することが可能です。その場合にはレプリケーションを 中断 します。この時、プライマリノードはセカンダリとの通信を切断するので一時的に同期しない状態になりますが、セカンダリでは整合性のとれたコピーを保持しています。帯域幅が確保されると、自動で同期が再開し、バックグラウンド同期が行われます。

レプリケーションの中断は、データセンタやクラウドインスタンス間との共有接続で遠隔地レプリケーションを行うような、可変帯域幅での接続の場合に通常利用されます。

輻輳のポリシーとレプリケーションの停止についてほ詳細は 輻輳ポリシーと中断したレプリケーションの構成 をご参照ください。

オンライン照合機能を使うと、2ノードのデータの整合性を、ブロックごとに効率的な方法で確認できます。

ここで 効率的 というのはネットワーク帯域幅を効率的に利用することを意味しています。照合によって冗長性が損なわれることはありません。しかしオンライン照合はCPU使用率やシステム負荷を高めます。この意味では、オンライン照合はリソースを必要とします。

一方のノード( 照合ソース )で、低レベルストレージデバイスのブロックごとのダイジェストを計算します。DRBDはダイジェストを他方のノード( 照合ターゲット )に転送し、そこでローカルの対応するブロックのダイジェストと照合します。ダイジェストが一致しないブロックはout-of-syncとマークされ、後で同期が行われます。DRBDが転送するのはダイジェストであって、ブロックのデータそのものではありません。このため、オンライン照合はネットワーク帯域幅をきわめて効率的に活用します。

このプロセスは、照合対象のDRBDリソースを利用したまま実行できます。これが オンライン の由来です。照合によるパフォーマンス低下は避けられませんが、照合およびその後の同期作業全体を通じてサービスの停止やシステム全体を停止する必要はありません。

オンライン照合は、週または月に1回程度の頻度でcronデーモンから実行するのが妥当です。オンライン照合機能を有効にして実行する方法や、これを自動化する方法については、 オンラインデバイス照合の使用 をご参照ください。

DRBDは、MD5、SHA-1またはCRD-32Cなどの暗号手法にもとづきノード間のメッセージの整合性チェックができます。

DRBD自身はメッセージダイジェストアルゴリズムは 備えていません 。Linuxカーネルの暗号APIが提供する機能を単に利用するだけです。したがって、カーネルが備えるアルゴリズムであれば、どのようなものでも利用可能です。

本機能を有効にすると、レプリケート対象のすべてのデータブロックごとのメッセージダイジェストが計算されます。レプリケート先のDRBDは、レプリケーション用パケットの照合にこのメッセージダイジェストを活用します。 データの照合が失敗したら、レプリケート先のDRBDは、失敗したブロックに関するパケットの再送を求めます。 この機能を使うことで、データの損失を起こす可能性がある次のようなさまざまな状況への備えが強化され、DRBDによるレプリーションが保護されます。

レプリケーショントラフィックの整合性チェックを有効にする方法については、 レプリケーショントラフィックの整合性チェックを設定 をご参照ください。

クラスタノード間のすべての通信が一時的に中断され、クラスタ管理ソフトウェアまたは人為的な操作ミスによって両方のノードが プライマリ になった場合に、スプリットブレインの状態に陥ります。それぞれのノードでデータの書き換えが行われることが可能になってしまうため、この状態はきわめて危険です。つまり、2つの分岐したデータセットが作られてしまう軽視できない状況に陥る可能性が高くなります。

クラスタのスプリットブレインは、Pacemaker などが管理するホスト間の通信がすべて途絶えたときに生じます。これとDRBDのスプリットブレインは区別して考える必要があります。このため、本書では次のような記載方法を使うことにします。

スプリットブレインに陥ったことを検出すると、DRBDは電子メールまたは他の方法によって管理者に自動的に通知できます。この機能を有効にする方法については スプリットブレインの通知 をご参照ください。

スプリットブレインへの望ましい対処方法は、 手動回復 を実施した後、根本原因を取り除くことです。しかし、ときにはこのプロセスを自動化する方がいい場合もあります。自動化のために、DRBDは以下のいくつかのアルゴリズムを提供します。

自動修復機能を使うべきかどうかの判断は、個々のアプリケーションに強く依存します。データベースをレプリケーションしている場合を例とすると、変更量が少ないノードのデータを切り捨てるアプローチは、ある種のWebアプリケーションの場合には適しているかもしれません。一方で、金融関連のデータベースアプリケーションでは、 いかなる 変更でも自動的に切り捨てることは受け入れがたく、いかなるスプリットブレインの場合でも手動回復が望ましいでしょう。スプリットブレイン自動修復機能を使う場合、アプリケーションの特性を十分に考慮してください。

DRBDのスプリットブレイン自動修復機能を設定する方法については、 スプリットブレインからの自動復旧ポリシー を参照してください。

ローカルディスクやRAID論理ディスクでライトキャッシュが有効な場合、キャッシュにデータが記録された時点でデバイスへの書き込みが完了したと判断されます。このモードは一般にライトバックモードと呼ばれます。このような機能がない場合の書き込みはライトスルーモードです。ライトバックモードで運用中に電源障害が起きると、最後に書き込まれたデータはディスクにコミットされず、データを紛失する可能性があります。

これを解消するために、DRBDはディスクフラッシュを使用しています。ディスクフラッシュとは、関連するデータが安定した（不揮発性の）ストレージに確保された時点で完了する書き込み操作のことです。つまり、データがディスクに書き込まれたときにのみ完了し、キャッシュではなくディスクに書き込まれたことを意味します。DRBDは、複製されたデータセットとメタデータの両方に対して書き込み操作にディスクフラッシュを使用します。実際には、DRBDは、 アクティビティログ の更新や暗黙の書き込み後書き込み依存関係の強制など、必要と判断される状況で書き込みキャッシュを迂回します。これにより、停電の際でも追加の信頼性が得られます。

しかしDRBDがディスクフラッシュを活用できるのは、直下のディスクデバイスがこの機能をサポートしている場合に限られることに注意してください。最近のカーネルは、ほとんどのSCSIおよびSATAデバイスに対するフラッシュをサポートしています。LinuxソフトウェアRAID (md)は、直下のデバイスがサポートする場合に限り、RAID-1に対してフラッシュをサポートします。デバイスマッパ(LVM2、dm-raid、マルチパス)もフラッシュをサポートしています。

電池でバックアップされた書き込みキャッシュ(BBWC)は、電池からの給電による不揮発性ストレージです。このようなデバイスは、電源障害から回復したときに中断していたディスクへの書き込みをディスクにフラッシュできます。このため、キャッシュへの書き込みは、事実上安定したストレージへの書き込みと同等とみなせます。この種のデバイスが使える場合、DRBDの書き込みパフォーマンスを向上させるためにフラッシュを無効に設定するのがよいかもしれません。詳細は 下位デバイスのフラッシュを無効にする をご参照ください。

Trim と Discard は、ある範囲のデータ領域が既に使用済みで不要になって^[2]、他のデータ領域として再利用してよいことをストレージに伝えるコマンドで、どちらも同じ意味を持ちます。これらは、フラッシュストレージで使用されている機能です。フラッシュストレージ(SSD、FusionIOカードなど)では上書きが困難であり、通常は消去してから新しいデータを書き込む必要があります(これにより多少のレイテンシが発生します)。詳細は wikipedia page を参照ください。

DRBDは8.4.3から trim/discard をサポートしています。設定や有効化を行う必要はありません。DRBDはローカル(下位の)ストレージシステムがそれらのコマンドをサポートしていることを検出すると、自動的に利用します。

その効果の例をあげると、大部分または全てのストレージ領域が無効になったとDRBDに伝えることで(DRBDはこれをすべての接続しているノードにリレーします）、比較的最近のmkfs.ext4であれば、初期同期時間を数TBのボリュームでも数秒から数分ほどに短縮することができます。

その後そのノードに接続する後続のリソースは Trim/Discard 要求ではなく、フル同期を行います。カーネルバージョンやファイルシステムによっては fstrim が効果を持つことがあります。

どちらかのノードのDRBD下位ブロックデバイスがI/Oエラーを返したときに、DRBDがそのエラーを上位レイヤ(多くの場合ファイルシステム)に伝えるかどうかを制御できます。

pass_onを設定すると、下位レベルのエラーをDRBDはそのまま上位レイヤに伝えます。したがって、そのようなエラーへの対応(ファイルシステムをリードオンリーでマウントしなおすなど)は上位レイヤに任されます。このモードはサービスの継続性を損ねることがあるので、多くの場合推奨できない設定だといえます。

detach を設定すると、最初の下位レイヤでのI/Oエラーに対して、DRBDは自動的にそのレイヤを切り離します。上位レイヤにI/Oエラーは伝えられず、該当ブロックのデータはネットワーク越しに対向ノードに書き込まれます。その後DRBDはディスクレスモードと呼ばれる状態になり、すべてのI/Oは対向ノードに対して読み込んだり、書き込むようになります。このモードでは、パフォーマンスは犠牲になりますが、サービスは途切れることなく継続できます。また、都合のいい任意の時点でサービスを対向ノードに移動させることができます。

I/Oエラー処理方針を設定する方法については I/Oエラー処理方針の設定 を参照してください。

DRBDはデータの inconsistent(不整合状態) と outdated(無効状態) を区別します。不整合とは、いかなる方法でもアクセスできずしたがって利用できないデータ状態です。たとえば、進行中の同期先のデータが不整合データの例です。この場合、ノードのデータは部分的に古く、部分的に新しくなっており、ノード間の同期は不可能になります。下位デバイスの中にファイルシステムが入っていたら、このファイルシステムは、マウントはもちろんチェックも実行できません。

無効データは、セカンダリノード上のデータで、整合状態にあるもののプライマリ側と同期していない状態のデータをさします。一時的か永続的かを問わず、レプリケーションリンクが途切れたときに、この状態が生じます。リンクが切れている状態でのセカンダリ側の無効データは、クリーンではあるものの、対向ノードのデータ更新が反映されず古いデータ状態になっている可能性があります。サービスが無効データを使ってしまうことを防止するために、DRBDは無効データを プライマリに切り替える ことを許可しません。

DRBDにはネットワークの中断時にセカンダリノードのデータを無効に設定するためのインタフェースがあります。DRBDは無効データをアプリケーションが使ってしまうことを防止するために、このノードがプライマリになることを拒絶します。 本機能の完全は実装は、DRBDレプリケーションリンクから独立した通信経路を使用する Pacemakerクラスタ管理フレームワーク 用になされていますが、しかしこのAPIは汎用的なので、他のクラスタ管理アプリケーションでも容易に本機能を利用できます。

レプリケーションリンクが復活すると、無効に設定されたリソースの無効フラグは自動的にクリアされます。そして バックグラウンド同期 が実行されます。

3ノードレプリケーションとは、2ノードクラスタに3番目のノードを追加してDRBDでレプリケーションするものです。この方法は、バックアップやディザスタリカバリのために使われます。 このタイプの構成では一般的に DRBD Proxyによる遠距離レプリケーション の内容も関係します。

3ノードレプリケーション既存のDRBDリソースの上にもうひとつのDRBDリソースを スタック(積み重ね) することによって実現されます。次の図を参照してください。

下位リソースのレプリケーションには同期モード(DRBDプロトコルC)を使いますが、上位リソースは非同期レプリケーション(DRBDプロトコルA)で動作させます。

3ノードレプリケーションは、常時実行することも、オンデマンドで実行することもできます。常時レプリケーションでは、クラスタ側のデータが更新されると、ただちに3番目のノードにもレプリケートされます。オンデマンドレプリケーションでは、クラスタシステムとバックアップサイトの通信はふだんは停止しておき、cronなどによって定期的に夜間などに同期をはかります。

DRBDの プロトコルA は非同期モードです。しかし、ソケットの出力バッファが一杯になると(drbd.conf マニュアルページの sndbuf-size を参照ください)、アプリケーションからの書き込みはブロックされてしまいます。帯域幅が狭いネットワークを通じて書き込みデータが対向ノードに送られるまで、そのデータを書き込んだアプリケーションは待たなければなりません。

平均的な書き込み帯域幅は、利用可能なネットワークの帯域幅によって制約されます。ソケットの出力バッファに収まるデータ量までのバースト的な書き込みは、問題なく処理されます。

オプション製品のDRBD Proxyのバッファリング機構を使って、この制約を緩和できます。DRBDプライマリノードからの書き込みデータは、DRBD Proxyのバッファに格納されます。DRBD Proxyのバッファサイズは、アドレス可能空間や搭載メモリの範囲内で自由に設定できます

データ圧縮を行うように設定することも可能です。圧縮と伸長(解凍)は、応答時間をわずかに増やしてしまいます。しかしネットワークの帯域幅が制約要因になっているのなら、転送時間の短縮効果は、圧縮と伸長(解凍)によるオーバヘッドを打ち消します。

圧縮伸長(解凍)機能は複数CPUによるSMPシステムを想定して実装され、複数CPUコアをうまく活用できます。

多くの場合、ブロックI/Oデータの圧縮率は高く、帯域幅の利用効率は向上します。このため、DRBD Proxyを使うことによって、DRBDプロトコルBまたはCを使うことも現実的なものとなります。

DRBD Proxyの設定については DRBD Proxyの使用 を参照ください。

トラック輸送(またはディスク輸送)によるレプリケーションは、ストレージメディアを遠隔サイトに物理的に輸送することによるレプリケーションです。以下の制約がある場合に、この方法はとくに有効です。

このような状況にある場合、トラック輸送を使わなければ、きわめて長期間(数日から数週間またはそれ以上)の初期同期が必要になってしまいます。トラック輸送でデータを遠隔サイトに輸送する場合、初期同期時間を劇的に短縮できます。詳細は トラックベースのレプリケーションの使用 を参照ください。

DRBDのやや特殊な使用方法に 動的対向ノード があります。動的対向ノードを設定すると、DRBDの対向同士は(通常設定の)特定のホスト名を持つノードには接続せず、いくつかのホスト間を動的に選択して接続するする事ができます。この設定において、DRBDは対向ノードをホスト名ではなくIPアドレスで識別します。

動的対向ノードの設定については 2セットのSANベースPacemakerクラスタ間をDRBDでレプリケート を参照ください。

例えば、会社のポリシーで3重の冗長化が要求される場合、少なくとも3台のサーバが必要になります。

しかし、データ量が増えてくると、サーバ追加の必要性に迫られます。その際には、また新たに3台のサーバを購入する必要はなく、１つのノードだけを追加をしてデータを 再配置 することができます。

上の図では、3ノードの各々に25TiBのボリュームがある合計75TiBの状態から、4ノードで合計100TiBの状態にしています。

これらはDRBD9ではオンラインで行うことができます。実際の手順については データ再配置 ご覧ください。

DRBDの複数の対向ノード機能に、 DRBDクライアント などの新しいユースケースが追加されました。

基本的にDRBD バックエンド は3〜4、またはそれ以上(冗長化の要件に応じて)で構成できます。しかしDRBD9はそれ以上でも接続することができます。なお1つのビットマップslot^[3]が ディスクレスプライマリ ( DRBDクライアント )用に予約されます。

プライマリの DRBDクライアント で実行されるすべての書き込み要求は、ストレージを備えたすべてのノードに送られます。読み込み要求は、サーバーノードの1つにのみ送られます。 DRBDクライアント は、使用可能なすべてのサーバーノードに均等に読み読み要求を送ります。

詳細は 永続的なディスクレスノード を参照ください。

DRBDクォーラムは、高可用性クラスターにおいてスプリットブレイン状況やデータの乖離を避けるのに役立つ機能です。DRBDクォーラムを使用することで、フェンシングやSTONITHソリューションに頼る必要はありませんが、必要に応じてこれらを使用することもできます。DRBDクォーラムには少なくとも3つのノードが必要ですが、アービトレータとして機能する第三のノードはディスクレスであることができます。アービトレータノードは、クラスター内のディスクフルストレージノードと同じハードウェア仕様を持つ必要はありません。例えば、Raspberry Piのような低消費電力のシングルボードコンピュータでさえ十分な場合があります。

DRBD クォーラムの背後にある機能コンセプトは、クラスターノードが、自身を含む、通信可能なデータセットの DRBD 実行中ノード数が、クォーラムオプションを有効にした際に指定した要件を満たす場合にのみ、DRBD レプリケーションされたデータセットを変更できるということです。ほとんどの構成では、これはノード数の過半数になります。運行中のデータセットの総ノード数の半分よりも大きい数を過半数とします。指定されたパーティション内のノードのうち、そのノード自体を含む半数以上にネットワークアクセス権限を持つノードにのみデータ書き込みを許可することで、DRBDクォーラム機能は、データセットの発散を引き起こす状況を回避できるようにします。

ただし、DRBDプライマリノードがデータセットに書き込むことができるためには、3ノードクラスターで常に2つ以上の稼働ノードが必要というわけではありません。例外もあります。たとえば、二次ノードをすべて正常に切断すると、DRBDはそれらがクラスターを離れる際にデータを古いものとしてマークします。このようにして、単一のDRBDプライマリノードがデータを書き込み続けても安全であると “判断” できるのです。この状況は、たとえばクラスター内のノードでシステムメンテナンスを実行している間などに発生する可能性があります。この方法により、アプリケーションやサービスの停止時間を引き起こさずに、クラスター内のノードを維持することができます。

DRBDのクォーラムを使用することは、Pacemakerクラスターの実行と互換性があります。Pacemakerは、DRBDリソースのマスタースコアを通じて、クォーラムまたはクォーラム喪失について通知を受けます。

DRBDのクォーラム機能に関連する構成オプションや動作にはさまざまな選択肢があります。たとえば、クラスターでクォーラムを定義する方法や、ノードがクォーラムを喪失した際にDRBDが取る可能性のあるアクションなどがあります。これに関する情報については、 クォーラム設定 セクションを参照してください。

DRBD は必要なすべての再同期操作を並行して実行するため、ノードはできるだけ早く最新のデータと再統合されます。これは、下位ディスクごとに 1 つの DRBD リソースがある場合にうまく機能します。

しかし、DRBD リソースが物理ディスクを共有している場合 (または単一のリソースが複数のボリュームにまたがっている場合)、これらのリソース (またはボリューム) を並行して再同期すると、非線形のアクセス パターンが発生します。ハードディスクは、線形アクセスパターンではるかに優れたパフォーマンスを発揮します。このような場合、DRBD リソース構成ファイルの disk セクション内で resync-after キーワードを使用して、再同期をシリアル化できます。

例としては こちら を参照ください。

多くのシナリオでは、DRBD をフェールオーバークラスターのリソースマネージャーと組み合わせると便利です。DRBD は、DRBD Reactor やそのプロモータープラグイン (Pacemaker) などのクラスターリソースマネージャー (CRM) と統合して、フェイルオーバークラスターを作成できます。

DRBD Reactor は、DRBD イベントを監視して対応するオープンソースツールです。そのプロモータープラグインは、systemd ユニット ファイルまたは OCF リソースエージェントを使用してサービスを管理します。DRBD Reactor は DRBD のクラスタ通信のみに依存しているため、独自の通信の設定は必要ありません。

DRBD Reactor では、監視している DRBD リソースでクォーラムが有効になっている必要があるため、フェイルオーバークラスターには少なくとも 3 つのノードが必要です。制限は、コロケーションされたサービスに対してのみサービスの順序をサポートすることです。その利点の 1 つは、一時的なネットワーク障害の後にクラスターを完全に自動回復できることです。これは、その単純さと相まって、推奨されるフェールオーバークラスターマネージャーになります。さらに、DRBD Reactor は、3 つ以上のノード (クォーラム用) のデプロイメントで STONITH や冗長ネットワークを必要としないため、クラウドへの展開に完全に適しています。

Pacemaker は、高可用性クラスター向けの最も長く利用されているオープンソースクラスターのリソースマネージャーです。独自の通信レイヤー (Corosync) が必要であり、さまざまなシナリオに対処するには STONITH が必要です。STONITH には専用のハードウェアが必要な場合があり、サービス障害の影響範囲が広がる可能性があります。Pacemaker はおそらく、リソースの場所と順序の制約を表現するための最も柔軟なシステムを備えています。ただし、この柔軟性により、セットアップが複雑になる可能性があります。

さらに、Linux 用 SIOS LifeKeeper、Linux 用 HPE Serviceguard、Veritas Cluster Server など、DRBD と連携するフェイルオーバークラスターの独自のソリューションもあります。

Veritas Cluster Server (or Veritas Infoscale Availabilty) はオープンソースであるPacemakerの代替となる商用製品です。DRBDリソースをVSCセットアップとともに使用する場合は github の drbd-utils/scripts/VCS の README を参照ください。

DRBDプロジェクトのスポンサー企業であるLINBITは、商用サポートの顧客向けにバイナリパッケージを提供しています。これらのパッケージはリポジトリやパッケージマネージャーのコマンド（例： apt, dnf）を通じて利用可能であり、適切な場合はLINBITのDockerレジストリを通じても利用できます。これらのソースからのパッケージやイメージは「公式」ビルドと見なされています。

これらのビルドは次のディストリビューションで入手できます。

特定の配布情報に署名されたDRBDカーネルモジュールの詳細な情報については、 セキュアブートのための LINBIT カーネルモジュール署名 セクションを参照してください。

他のディストリビューションのビルドも用意していますが、十分なテストは経ていません。

LINBIT社では、新規のDRBDソースのリリースと並行してバイナリビルドをリリースしています。

SLES、RHEL、AlmaLinuxなどのRPMベースのシステムでのパッケージのインストールは、単純に dnf install （新規インストール用）または dnf update （アップグレード用）を使用することで行われます。

DEBベースのシステム（Debian GNU/Linux、Ubuntu）では、 drbd-utils および drbd-module-`uname -r` パッケージは apt install を使用してインストールされます。

LINBITは商用サポートカスタマー向けにDockerレポジトリを提供します。レポジトリはホスト名 ‘drbd.io’ 経由でアクセスします。

イメージを取得する前に、レジストリにログインする必要があります。

ログインに成功するとイメージを取得できます。ログインしてテストするには以下のコマンド実行してください。

コンパイル済みバイナリパッケージを含め、いくつかのディストリビューションでDRBDが配布されています。これらのパッケージに対するサポートは、それぞれのディストリビュータが提供します。リリースサイクルは、DRBDソースのリリースより遅れる場合があります。

github で git tags によって生成されたリリースはある時点での git レポジトリのスナップショットです。これらはマニュアルページや configure スクリプト、あるいはその他の生成されるファイルが不足しているかもしれません。tarball からビルドするなら、 こちら を使用してください。

すべてのプロジェクトは標準のビルドスクリプト (eg, Makefile, configure) を含みます。ディストリビューション毎に固有の情報をメンテナンスすることは手間がかかり、また歴史的にすぐに最新でなくなってしまいました。標準的な方法でソフトウェアをビルドする方法を知らない場合は、LINBITによって供給されるパッケージを使ってください。

現在のDRBDリリースと過去のリリースのソースtarファイルは、 https://pkg.linbit.com/ からダウンロード可能です。ソースtarファイルは通常、drbd-x.y.z.tar.gz という名前が付けられています。例えば、drbd-utils-x.y.z.tar.gz のように、x、y、z はメジャー番号、マイナー番号、バグ修正リリース番号を表します。

DRBDの圧縮されたソースアーカイブは、サイズが半メガバイト未満です。tarファイルをダウンロードした後は、tar -xzf コマンドを使用してその内容を展開して、現在の作業ディレクトリにダウンロードすることができます。

組織的な目的で、通常ソースコードを保管するディレクトリ（たとえば /usr/src や /usr/local/src など）に DRBD を展開してください。このガイドの例では /usr/src を前提としています。

DRBDのソースコードは公開されたGitリポジトリに保管されています。このリポジトリは https://github.com/LINBIT からオンラインで閲覧できます。DRBDソフトウェアは以下のプロジェクトから構成されています。

ソースコードは、Gitリポジトリをクローンするか、リリース用のtarファイルをダウンロードして取得できます。展開されたソースtarファイルと同じリリースのGitチェックアウトとの間には、わずかな違いが2つ存在します:

DRBDおよび関連ユーティリティのソースコードリポジトリをローカルホストにクローンした後、そのソースコードからDRBDをビルドする作業に進むことができます。

DRBDのビルドが成功した場合、次のコマンドを入力することでDRBDをインストールできます。

DRBDのユーザースペース管理ツール（drbdadm、drbdsetup、drbdmeta）は、通常 /sbin/ などの configure に渡された prefix パスにインストールされます。

カーネルをアップグレードする際には、新しいカーネルに合わせて、DRBDカーネルモジュールを再構築して再インストールする必要があります。

一部のディストリビューションでは、カーネルモジュールのソースディレクトリを登録しておくことで、必要に応じて再構築が行われます。例えば、Debianでは dkms(8) を参照してください。

一方で、DRBDのユーザースペースツールは、新しいDRBDバージョンにアップグレードする際には、再構築して再インストールするだけで済みます。新しいカーネルと新しいDRBDバージョンの両方にアップグレードする場合、両コンポーネントをアップグレードする必要があります。

DRBDビルドシステムには、DRBDのソースツリーから直接RPMパッケージをビルドする機能が含まれています。RPMをビルドする際には、make でビルドおよびインストールする場合と基本的に同様に ビルドの前提条件の確認 が適用されますが、もちろんRPMビルドツールも必要です。

もし、実行中のカーネルとプリコンパイル済ヘッダを使用せずにビルドする場合は、 カーネルソースツリーの準備 も参照してください。

ビルドシステムは、RPMをビルドするための2つのアプローチを提供しています。より簡単な方法は、単にトップレベルのMakefileで rpm ターゲットを呼び出すことです。

このアプローチは、事前定義されたテンプレートから仕様ファイルを自動生成し、その仕様ファイルを使用してバイナリのRPMパッケージをビルドします。

make rpm のアプローチは、複数のRPMパッケージを生成します。

もう一つの、柔軟なアプローチは、configure にスペックファイルを生成させ、必要な変更を加え、その後 rpmbuild コマンドを使用する方法です。

RPMは、システムのRPM構成（またはあなたの個人の ~/.rpmmacros 構成）に応じて作成されます。

これらのパッケージを作成した後、システム内の他の任意のRPMパッケージと同様に、それらをインストール、アップグレード、アンインストールすることができます。

注意：どんなカーネルのアップグレードでも、新しいカーネルに合わせて新しい「kmod-drbd」パッケージを生成する必要があります。詳細は 一部のディストリビューションにおいて、カーネルアプリケーションバイナリインターフェースの警告が発生しています。 も参照してください。

一方、DRBDユーザーランドパッケージは、新しいDRBDバージョンにアップグレードする際にのみ再作成する必要があります。新しいカーネルと新しいDRBDバージョンの両方にアップグレードする場合は、両方のパッケージをアップグレードする必要があります。

DRBDのビルドシステムには、DRBDのソースツリーから直接Debianパッケージをビルドするための機能が含まれています。Debianパッケージをビルドする場合、make でビルドおよびインストールする場合と基本的に同じように ビルドの前提条件の確認 が適用されますが、Debianのパッケージングツールを含む dpkg-dev パッケージと、DRBDを非rootユーザーとしてビルドする場合には fakeroot も必要です（強く推奨）。全てのDRBDのサブプロジェクト（カーネルモジュールと drbd-utils ）は、Debianパッケージのビルドをサポートしています。

もし、実行中のカーネルとプリコンパイル済ヘッダを使用せずにビルドする場合は、 カーネルソースツリーの準備 も参照してください。

DRBDのソースツリーには、Debianパッケージングに必要なファイルが含まれている`debian` サブディレクトリがあります。ただし、そのサブディレクトリはDRBDソースtarファイルには含まれていません。その代わりに、特定のDRBDリリースに関連付けられた「タグ」を使用して Gitをチェックアウトする 必要があります。

この手法でチェックアウトを作成した後、DRBDのDebianパッケージをビルドするために以下のコマンドを発行することができます。

このビルドプロセスにより、以下のDebianパッケージが作成されます。

これらのパッケージを作成した後は、システム内の他のDebianパッケージと同様に、それらをインストール、アップグレード、アンインストールすることができます。

drbd-utils パッケージは、Debianの dpkg-reconfigure 機能をサポートしており、デフォルトで表示されるmanページのバージョンを切り替えるために使用することができます（8.3、8.4、または9.0）。

インストールされたモジュールのソースパッケージから実際のカーネルモジュールをビルドしてインストールすることは、Debianの module-assistant ツールを使用することで簡単に行うことができます。

上記のコマンドの省略形も使用することができます。

新しいカーネルへのアップグレードでは、その新しいカーネルに合わせてカーネルモジュールを再構築する必要があります（前述のように module-assistant を使用して）。対照的に、drbd-utils および drbd-module-source パッケージは、新しいDRBDバージョンにアップグレードするときにのみ再作成する必要があります。新しいカーネルと新しいDRBDバージョンの両方にアップグレードする場合は、両方のパッケージをアップグレードする必要があります。

DRBD9からは、dkms(8) を利用してDRBDカーネルモジュールの自動更新が可能になりました。drbd-dkms Debianパッケージをインストールすれば、簡単に更新することができます。

DRBDの動作中にリソースを再設定することができます。次の手順を行います。

drbdadm adjust は drbdsetup を通じて実行中のリソースを調整します。保留中の drbdsetup 呼び出しを確認するには、 drbdadm を -d (dry-run,予行演習)オプションを付けて実行します。

手動で リソースロール をセカンダリからプライマリに切り替える(昇格)、またはその逆に切り替える(降格)には、次のコマンドを実行します。

DRBDが シングルプライマリモード (DRBDのデフォルト)で、 コネクションステータス が Connected の場合、任意のタイミングでどちらか1つのノード上でのみリソースはプライマリロールになれます。したがって、あるリソースが他のノードに対してプライマリロールになっているときに drbdadm primary <resource> を実行すると、エラーが発生します。

リソースが デュアルプライマリモード に対応するよう設定している場合には、両方のノードをプライマリロールに切り替えることができます。これは、例えば仮想マシンのオンラインマイグレーションの際に利用できます。

Pacemakerを使わず、パッシブ/アクティブ構成でフェイルオーバを手動で制御するには次のようにします。

現在のプライマリノードで、DRBDデバイスを使用しているすべてのアプリケーションやサービスを停止し、DRBDデバイスをアンマウントし、リソースをセカンダリに降格させてください。

プライマリにしたいノードでリソースを昇格してデバイスをマウントします。

自動プロモート 機能を使用している場合はロール(プライマリ/セカンダリ)を手動で変更する必要はありません。それぞれサービス停止とアンマウント、マウントの操作のみ必要です。

drbd-utils バージョン9.26.0以降には、「円滑な停止」サービスである drbd-graceful-shutdown.service が含まれています。このサービスは、ノードをシャットダウンする際にクラスター全体においてDRBDの “「最後の1台」”の動作が適用されるようにし ます。

最初のDRBDデバイスが作成された時点で、優雅なシャットダウンサービスはudevサービスによって自動的に起動されます。システムをシャットダウンする際、優雅なシャットダウンサービスは、DRBDリソースをホストしているすべてのノードが正しい順序でサービスをシャットダウンし、最後のノードがクォーラムを維持できるようにします。

通常のシステムシャットダウンシーケンスでは、この介入なしには、ネットワーキングがシステムがファイルシステムをアンマウントし、DRBDデバイスを停止する前に停止することがよくあります。Graceful shutdownサービスがない場合、最後にシャットダウンする ノードがDRBDクオーラムを保持するようにするには、ノードをシャットダウンする前にファイルシステムを手動でアンマウントし、DRBDリソースを停止する必要があります。

ノード上で実行されているGraceful Shutdownサービスのおかげで、シャットダウン時にノードは自身のDRBDリソースを時代遅れとマ ークし、実行中のDRBDサービスを停止し、その後にネットワーキングサービスを停止させます。このシャットダウン手順により、クラスタを離れるDRBDノードは、ネットワークを介してその時代遅れの状態を最後のノードに伝えることができます。この方法で、クラスタを離れる最後のノードはクォーラムを維持することができます。

DRBDのアップグレードは比較的簡単なプロセスです。このセクションには、特定のDRBD 9バージョンから別のDRBD 9バージョンへのアップグレードに関する警告や重要な情報が含まれています。

DRBDを8.4.xから9.xにアップグレードする場合は、 付録 の手順に従ってください。

デュアルプライマリモードではリソースが複数ノードで同時にプライマリになることができます。永続的でも一時的なものでも可能です。

バックグラウンド同期中は同期先のデータとの一貫性が一時的に失われるため、同期はできるだけ短時間で完了させるべきです。ただし、すべての帯域幅がバックグラウンド同期に占有されてしまうと、フォアグラウンドレプリケーションに使用できなくなり、アプリケーションのパフォーマンス低下につながります。これは避ける必要があります。同期用の帯域幅はハードウェアに合わせて設定する必要があります。

また、同じ理由で、同期速度をレプリケーションネットワークの帯域幅の能力を上回る速度に設定しても意味がありません。

チェックサムベース同期 はデフォルトでは有効になっていません。有効にするには、 /etc/drbd.conf のリソース構成に次の行を追加します。

<algorithm> は、システムのカーネル構成内のカーネルcrypto APIでサポートされる任意のメッセージダイジェストアルゴリズムです。通常は sha1 、 md5 、 crc32c から選択します。

既存のリソースに対してこの変更を行う場合は、 drbd.conf を対向ノードと同期し、両方のノードで drbdadm adjust <resource> を実行します。

レプリケーション帯域幅が大きく変動する環境(WANレプリケーション設定で典型的)の場合、レプリケーションリンクは時に輻輳します。デフォルト設定では、プライマリノードのI/Oのブロックを引き起こし、望ましくない場合があります。

その代わりに、進行中の同期を suspend (中断)に設定し、プライマリのデータセットをセカンダリから pull ahead (引き離す)にします。このモードではDRBDはレプリケーションチャネルを開いたままにし、切断モードにはしません。しかし十分な帯域幅が利用できるようになるまで実際にはレプリケートを行いません。

次の例は、DRBD Proxy構成のためのものです。

通常は congestion-fill と congestion-extents を pull-ahead オプションと合わせて設定するのがよい方法でしょう。

congestion-fill の値は以下の値の90%にするとよいでしょう。

congestion-extents の値は、影響するリソースの al-extents に設定した値の90%がよいでしょう。

DRBDが 下位レベルI/Oエラーを処理する際の方針 は、リソースの /etc/drbd.conf の disk セクションの on-io-error で指定します。

すべてのリソースのグローバルI/Oエラー処理方針を定義したい場合は、これを common セクションで設定します。

on-io-error オプションは on-no-data-accessible オプションとは独立しています。一部の on-io-error ストラテジーは、ピアディスク上でI/Oリクエストを再試行することを含みます。 on-no-data-accessible オプションの設定は、すべてのディスクでI/Oリクエストが失敗した場合のDRBDの動作を指示します。

on-io-error の <strategy> を次のうちの一つに設定できます:

これがデフォルトで、推奨オプションです。下位レベルI/Oエラーが発生すると、DRBDはそのノードの下位デバイスを切り離し、ディスクレスモードで動作を継続します。

これにより、DRBDはディスクの状態を Inconsistent に変更し、失敗したブロックをDRBDクイック同期ビットマップで不一致としてマークし、I/O操作をサテライト（セカンダリノード）ディスク上で再試行します。少なくとも1つのサテライトでI/O操作が成功した場合、書き込み操作は成功と見なされます。DRBDは、さらに試行可能なサテライトディスクがなくなるまで読み取り操作を再試行します。

ローカルI/Oエラーハンドラとして定義されたコマンドを呼び出します。このオプションを使うには、対応する local-io-error ハンドラをリソースの handlers セクションに定義する必要があります。local-io-error で呼び出されるコマンド(またはスクリプト)にI/Oエラー処理を実装するかどうかは管理者の判断です。

次のコマンドで、実行中のリソースのI/Oエラー処理方針を再構成することができます。

レプリケーショントラフィックの整合性チェック はデフォルトでは有効になっていません。有効にする場合は、 /etc/drbd.conf のリソース構成に次の行を追加します。

<algorithm> は、システムのカーネル構成内のカーネルcrypto APIでサポートされる任意のメッセージダイジェストアルゴリズムです。通常は sha1 、 md5 、 crc32c から選択します。

既存のリソースに対してこの変更を行う場合は、 drbd.conf を対向ノードと同期し、両方のノードで drbdadm adjust <resource> を実行します。

DRBD ボリュームを拡張する場合は、下から上に拡張する必要があります。最初に、すべてのノードで下位ブロックデバイスを拡張する必要があります。次に、DRBD に新しいスペースを使用するように指示します。

DRBD ボリュームが拡張された後、DRBD を使用しているものにそれを伝える必要があります。ファイルシステムを拡張する、あるいはこのボリュームが接続された状態で実行されている VM に新しい「ディスクサイズ」を認識させます。

これは通常、次のようになります。

次のセクション オンライン拡張 も参照ください。

ファイルシステムが異なれば、機能や管理ツールのセットも異なることに注意してください。例えば、XFS は拡張しかできません。また、引数にアクティブなマウントポイントを指定します: xfs_growfs /where/you/have/it/mounted

EXT ファミリは、拡張（オンラインでも）と縮小（オフラインのみ。最初にマウントを解除する必要があります）の両方が可能です。 ext3 または ext4 のサイズを変更するには、引数にマウントポイントではなく、（マウントされた）ブロックデバイスを指定します: resize2fs /dev/drbd#

当然、正しいDRBD（ mount や df -T で表示されるもの）を使用してください。バッキング・ブロック・デバイスを使ってはいけません。DRBDが稼働している場合、それは動作しないはずです（ resize2fs: Device or resource busy while trying to open /dev/mapper/VG-LV Couldn’t find valid filesystem superblock. ）。 もしDRBDを停止させてオフラインで行おうとした場合、バッキングのLVやパーティションに直接ファイルシステムツールを実行したら、DRBDメタデータが破損する可能性があります。ですので、やめておいてください。

プライマリでアクティブなDRBDデバイスに対して、ファイルシステムのリサイズは 1 回だけ 実行します。DRBDはファイルシステム構造の変更をレプリケートします。そのためにDRBDを使用しています。

また、XFS ボリュームで resize2fs を使用したり、EXT で XFS ツールを使用したりしないでください。使用中のファイルシステムに適したツールを使用してください。

resize2fs で /dev/drbd7 をオープンしたとき、スーパーブロックの不正なマジックナンバーは、これが EXT ファイルシステムではないことを伝えているので、代わりに他のツールを試す必要があります。例えば xfs_growfs です。ブロックデバイスではなく、マウントポイントを引数として取ることに注意してください。

DRBDボリュームを縮小する場合、トップからボトムに向かって縮小する必要があります。まず、切り詰めたいスペースが誰も使用していないことを確認してください。次にファイルシステムを縮小します（ファイルシステムがその機能をサポートしている場合）。その後、DRBDにそのスペースの使用を停止するよう指示します。DRBD内部のメタデータは、バッキングデバイスの「末尾」にあるため、これは簡単ではありません。

DRBD がスペースを使用しないことが確実になったら、たとえば lvreduce を使用して、下位デバイスからスペースを切り離すことができます。

オンライン縮小, オフライン縮小 も参照ください。

BBWC機能を使用していない、またはバッテリが消耗した状態でBBWCを使用しているときに、DRBDのフラッシュを無効にすると、 データが失われるおそれがあります したがって、これはお勧めできません。

DRBDは 下位デバイスのフラッシュ を、レプリケートされたデータセットとDRBD独自のメタデータについて、個別に有効と無効を切り替える機能を備えています。この2つのオプションはデフォルトで有効になっています。このオプションのいずれか(または両方)を無効にしたい場合は、DRBD設定ファイルの /etc/drbd.conf の disk セクションで設定できます。

レプリケートされたデータセットのディスクフラッシュを無効にするには、構成に次の行を記述します。

DRBDのメタデータでディスクフラッシュを無効にするには、次の行を含めます：

リソースの構成を修正し、また、もちろん両ノードの /etc/drbd.conf を同期したら、両ノードで次のコマンドを実行して、これらの設定を有効にします。

1台のサーバのみがBBWCがある場合^[7]には、ホストセクションに以下のような設定をしてください。

3ノード構成では、1つのDRBDデバイスを別のデバイスの上に スタック (積み重ね)します。

ノードはしばしDRBDの中で永続的にディスクレスになるときがあります。以下はディスクをもつ３つのノードと永続的なディスクレスノードの構成例です。

永続的なディスクレスノードはビットマップスロットが割り当てられません。このようなノードのステータスは、エラーでも予期せぬ状態でもないので緑で表示されます。詳細は クライアントモード を参照ください。

以下の例では、すべてのデータ領域は3台に冗長化するポリシーを想定しています。したがって最小構成で3台のサーバが必要です。

しかし、データ量が増えてくると、サーバ追加の必要性に迫られます。その際には、また新たに3台のサーバを購入する必要はなく、１つのノードだけを追加をしてデータを 再配置 することができます。

上の図では、3ノードの各々に25TiBのボリュームがある合計75TiBの状態から、4ノードで合計100TiBの状態にしています。

データを再配置する時には、 新しい ノードとDRBDリソースを削除したいノードを選択する必要があります。現在 アクティブ なノードからリソースを削除する場合には注意が必要です。 DRBDが プライマリ のノードからリソースを削除する場合にはサービスを移行するか、そのノードのリソースを DRBDクライアント として稼働させるかにしてください。通常は セカンダリ のノードから選ぶほうが簡単です(それができない場合もあるでしょうが)。

このセクションでは、高可用性クラスターにおいてスプリットブレイン状況やデータの発散を回避するために DRBDクォーラム機能 を設定する方法について説明します。

DRBDリソースのクォーラムを有効にするには、DRBDリソース構成ファイルの options セクション内にある quorum オプションを majority 、 all 、または数値に設定することで設定します。デフォルトでは、DRBDのクォーラムは有効になっておらず、オプションは off に設定されています。

DRBDクォーラムを有効にするDRBDリソース構成の例は次の通りです。

quorum オプションを /etc/drbd.d/global_common.conf というグローバルDRBD構成ファイルの common セクション内の options サブセクションで設定することで、クォーラムをグローバルに有効にすることもできます。グローバル構成ファイル内でクォーラムを有効にし、他の関連するオプションを設定すると、特定のDRBDリソース構成ファイル内で同じオプションが設定されていない限り、すべてのDRBDリソースに影響が及びます。その場合、DRBDリソース構成ファイル内で設定されたオプション値が優先されます。

DRBD クォーラムを有効にする例として、次のようなグローバル構成があります。

DRBD を削除する場合は、以下のステップに従います。

DRBD ProxyはDRBDに完全に透過的です。通常、データパケットの送信数が多いことが予想されるため、アクティビティログは十分に大きくする必要があります。これにより、プライマリノードの障害後に再同期が長くなる可能性があるため、DRBDの csums-alg 設定を有効にすることが推奨されています。

DRBD Proxyのより詳細な情報については DRBD Proxyによる遠距離レプリケーション をご参照ください。

DRBD Proxy 3は、2.6.26以降でしか利用できない複数のカーネル機能を使用しているため、古いシステム（例：RHEL 5）で実行することはできません。ただし、ここでは、まだDRBD Proxy 1のパッケージを提供することができます。 though^[9]

DRBD Proxyを入手するには、(日本では)サイオステクノロジー株式会社またはその販売代理店に連絡してください。特別な理由がない限り、常に最新バージョンのDRBD Proxyを使用してください。

DebianとDebianベースのシステム上でDRBD Proxyをインストールするには、dpkgを次のように使用します(DRBD Proxyのバージョンとアーキテクチャは、ターゲットのアーキテクチャに合わせてください)。

RPMベースのシステム(SLESやRedhat)にDRBD Proxyをインストールする場合は、次のコマンドを使用します(DRBD Proxyのバージョンとアーキテクチャは、ターゲットのアーキテクチャに合わせてください)。

DRBD Proxyの設定にはdrbdadmが必要なので、これもインストールします。

これにより、DRBD Proxyのバイナリがインストールされ、通常は /etc/init.d に配置されるinitスクリプトが追加されます。DRBD Proxyを起動/停止する際には常にinitスクリプトを使用してください。なぜなら、それによって drbdadm ツールを使用してDRBD Proxyの設定も行うからです。

DRBD Proxyの実行には、ライセンスファイルが必要です。DRBD Proxyを実行したいマシンにライセンスファイルを設定してくださいこのファイルは drbd-proxy.license と呼ばれ、対象マシンの /etc ディレクトリにコピーされ、また drbdpxy ユーザー/グループに所有されている必要があります。

DRBD Proxyは、LINSTORを使用して設定することができます。詳細は LINSTORユーザーガイド に記載されています。

DRBD Proxyはリソースファイルを編集することで設定することもできます。proxy という追加セクションやホストセクション内の proxy on セクションを追加することで構成されます。

DRBDノードで直接実行されるプロキシのDRBD Proxyの設定例を次に示します。

inside IPアドレスはDRBDとDRBD Proxyとの通信に使用し、 outside IPアドレスはプロキシ間の通信に使用します。後者はファイヤーウォール設定で許可する必要があります。

drbdadm には proxy-up および proxy-down サブコマンドがあり、名前付きDRBDリソースのローカルDRBD Proxyプロセスとの接続を設定したり削除したりできます。これらのコマンドは、/etc/init.d/drbdproxy が実装する start および stop アクションによって使用されます。

DRBD Proxyには drbd-proxy-ctl という下位レベル構成ツールがあります。このツールをオプションを指定せずに呼び出した場合は、対話型モードで動作します。

対話型モードをにせずコマンドを直接渡すには、 '-c' パラメータをコマンドに続けて使用します。

使用可能なコマンドを表示するには次のようにします。

コマンドの周りのダブルクォートは読み飛ばされる点に注意ください。

以下にコマンドを列挙します。最初のいくつかのコマンドは通常は直接使用することはありません( drbdadm proxy-up や drbdadm proxy-down コマンド経由で使用されます)。それ以降のものは様々なステータスや情報を表示します。

DRBD Proxyのバージョン3から、プロキシではWAN接続用にいくつかの特定のプラグインを有効にすることが可能です。現在利用可能なプラグインは、 zstd 、 lz4 、 zlib 、 および lzma （すべてソフトウェア圧縮）です。

zstd（Zstandard）は、高い圧縮比を提供するリアルタイム圧縮アルゴリズムです。非常に広い圧縮速度トレードオフの範囲を提供しており、非常に高速なデコーダーに支えられています。圧縮率は「レベル」パラメータに依存しており、1から調整することができます。 22. レベル20を超えると、DRBD Proxyはより多くのメモリを必要とします。

lz4 は非常に高速な圧縮アルゴリズムです。 通常データを1/2から1/4に圧縮でき、使用するネットワーク帯域も1/2から3/2程度になります。

zlib プラグインは、圧縮にGZIPアルゴリズムを使用しています。 lz4 よりもCPUを多く使用しますが、圧縮率は1:3から1:5の比率を提供します。

lzma プラグインは liblzma2 ライブラリを使用しています。このプラグインは数百 MiB の辞書を使用できます。これにより、小さな変更でも繰り返しデータの非常に効率的なデルタ圧縮が可能です。lzma は zlib よりもはるかに高い圧縮率を実現しますが、より多くの CPU とメモリを必要とします。仮想マシンが DRBD の上にある実世界のテストでは、1:10 から 1:40 の比率を実現しました。lzma プラグインはライセンスで有効にする必要があります。

お客様の環境に最適な設定を見つけるには、CPU（速度、スレッド数）、利用可能なメモリ、入力および利用可能な出力帯域幅、予想されるI/Oスパイクに依存します。すでに1週間分の sysstat データが利用可能であれば、構成を決定する際に役立ちます。 LINBITにお問い合わせいただくと良いです。

DRBD Proxy は LOG_DAEMON ファシリティを使用して syslog を介してイベントをログします。通常、/var/log/daemon.log に DRBD Proxy のイベントが記録されています。

DRBD Proxyでデバッグモードを有効にするには次のようにします。

たとえば、DRBD Proxyが接続に失敗すると、 Rejecting connection because I can’t connect on the other side というようなメッセージがログに記録されます。その場合は、DRBDが(スタンドアローンモードでなく)両方のノードで動作していて、両方ノードでプロキシが動作していることを確認してください。また、両方のノードで設定値を確認してください。

DRBDおよびDRBD管理ツールである drbdadm は、POSIXエラーコードを返します。特定のエラーコード番号について詳細な情報が必要な場合は、環境にPerlがインストールされている場合、次のコマンドを使用できます。例えば、エラーコード番号11について情報を取得するには、次のように入力してください:

ハードドライブの障害への対処方法は、DRBDがディスクI/Oエラーを処理する方法( ディスクエラー処理ストラテジー 参照)、また設定されているメタデータの種類( DRBDメタデータ 参照)によって異なります。

DRBDが(実際のハードウェア障害であれ手動による介入であれ)対向ノードがダウンしていることを検出すると、DRBDは自身のコネクションステータスを Connected から WFConnection に変更し、対向ノードが再び現れるのを待ちます。その後、DRBDリソースは disconnected mode(切断モード) で動作します。切断モードでは、リソースおよびリソースに関連付けられたブロックデバイスが完全に利用可能で、必要に応じて昇格したり降格したりします。ただし、ブロックの変更は対向ノードにレプリケートされません。切断中に変更されたブロックについての内部情報は対向ノードごとにDRBDが格納します。

ノード間の接続が可能になると、ノード間で初期ハンドシェイクのプロトコルが交換されます。この時点でDRBDはスプリットブレインが発生したかどうかを判断できます。両方のノードがプライマリロールであるか、もしくは切断中に両方がプライマリロールになったことを検出すると、DRBDは即座にレプリケーション接続を切断します。その場合、システムログにたとえば次のようなメッセージが記録されます。

スプリットブレインが検出されると、1つのノードは常に StandAlone の状態でリソースを保持します。もう一方のノードもまた StandAlone 状態になる(両方のノードが同時にスプリットブレインを検出した場合)、または WFConnection 状態になります(一方のノードがスプリットブレインを検出する前に対向ノードが切断をした場合)。

DRBDがスプリットブレインから自動的に回復するように設定されていない場合は、この時点で手動で介入して、変更内容を破棄するほうのノードを選択する必要があります(このノードは スプリットブレインの犠牲ノード と呼ばれる)。この介入は次のコマンドで行います。

他方のノード(スプリットブレインの生存ノード)のコネクションステータスも StandAlone の場合には、次のコマンド実行します。

ノードがすでに Connecting の状態の場合は自動的に再接続するので、この手順は省略できます。

接続すると、スプリットブレインの犠牲ノードのコネクションステータスがすぐに SyncTarget に変化し、他のノードによって変更内容が上書きされます。

再同期が完了すると、スプリットブレインが解決したとみなされ、2つのノードが再び完全に一致した冗長レプリケーションストレージシステムとして機能します。

DRBD 管理ツール drbdadm には、強制セカンダリオプション secondary --force が含まれています。 DRBD クォーラム喪失時のアクションが I/O 操作を一時停止するように構成されている場合、force secondary オプションを使用すると、クォーラムを失ったノードを正常に回復し、他のノードと再統合できます。

要件:

クォーラムを失ったプライマリノードを回復させる場合、コマンド drbdadm secondary --force <all|resource_name> を使用して、プライマリノードをセカンダリに降格できます。このコマンドの引数は、単一の DRBD リソース名か、すべての DRBD リソースをセカンダリロールにノードを降格させる all のいずれかです。

クォーラムを失い中断された I/O 操作を伴うプライマリノードでこのコマンドを使用すると、中断されたすべての I/O 要求と新しく送信された I/O 要求が I/O エラーで終了します。その後、通常はファイル システムをアンマウントし、ノードをクラスター内の他のノードに再接続できます。例外は、I/O をまったく行わずにアイドル状態になるだけのファイルシステムオープナーです。このようなプロセスは、アンマウントが成功する前に手動で削除するか、 fuser -k などの外部ツールやクラスター化されたセットアップの OCF ファイル システム リソースエージェントを使用して削除する必要があります。

DRBD 管理ツールの強制セカンダリオプションに加えて、 on-suspended-primary-outdated オプションを DRBD リソース構成ファイルに追加し、キーワード値 force-secondary を設定することもできます。また、リソースロールの競合 (rr-conflict) オプションを DRBD リソース構成ファイルの net セクションに追加し retry-connect に設定することも必要です。これにより、DRBD は、中断された I/O 操作でクォーラムを失ったプライマリ ノードを自動的に回復できます。これらのオプションを設定すると、そのようなノードがより新しいデータセットを持つクラスターパーティションに接続すると、DRBD はクォーラムを失い、I/O 操作を中断したプライマリノードを自動的に降格させます。リソース構成ファイルの handlers セクションなどの追加構成や、クラスターマネージャー内の追加構成も、完全に自動化された復旧セットアップを完了するために必要になる場合があります。

このシナリオをカバーする DRBD リソース構成ファイルの options セクション内の設定は、次のようになります。

DRBD Reactorは、プロジェクトのGitHubリポジトリ( https://github.com/LINBIT/drbd-reactor )で見つかるソースファイルからインストールすることができます。詳細や前提条件についてはそちらの指示をご覧ください。

また、LINBIT のお客様は DRBD Reactor を LINBIT の drbd-9 パッケージリポジトリからビルド済みパッケージとしてインストールすることも可能です。

インストール後、 drbd-reactor --version コマンドを使用して、DRBD Reactor のバージョン番号を確認できます。

DRBD Reactorはさまざまな用途があるため、コアコンポーネントとプラグインコンポーネントに分割されました。

DRBD Reactorを実行する前に、その設定を行う必要があります。グローバル設定はメインのTOML設定ファイル内で行われます。このファイルはこちらに作成されるべきです： /etc/drbd-reactor.toml 。このファイルは有効なTOML (https://toml.io) ファイルである必要があります。プラグインの設定はスニペットファイル内で行われるべきで、これらはデフォルトのDRBD Reactorスニペットディレクトリである /etc/drbd-reactor.d に配置されるか、メイン設定ファイルで別のディレクトリが指定されている場合はそれに配置されます。DRBD Reactor GitHubリポジトリの example ディレクトリには 設定ファイルの例 が見つかります。

文書化の目的でのみ、上記で言及されている例の設定ファイルには、例のプラグインの設定が含まれています。しかしながら、展開時には、プラグインの設定は常にスニペットファイル内で行うべきです。