この機能は本番環境での使用は想定していません。データ破壊の問題や、通信経路(ネットワークハードウェア、ドライバ、スイッチ)に障害があるかどうかを診断する場合にのみ使用してください。動作中(オンライン)に下位ブロックデバイスを拡張できる場合は、これらのデバイスをベースとするDRBDデバイスについても動作中にサイズを拡張することができます。その際に、次の2つの条件を満たす必要があります。LVMやEVMSなどの論理ボリューム管理サブシステムによって管理されている。両方のノードの下位ブロックデバイスを拡張したら、一方のノードだけがプライマリ状態であることを確認してください。プライマリノードで次のように入力します。<resource>新しいセクションの同期がトリガーされます。同期はプライマリノードからセカンダリノードへ実行されます。追加する領域がクリーンな場合には、追加領域の同期を—​assume-cleanオプションでスキップできます。オフライン拡張する外部メタデータを使っている場合、DRBD停止中に両ノードの下位ブロックデバイスを拡張すると、新しいサイズが自動的に認識されます。管理者による作業は必要ありません。両方のノードで次にDRBDを起動した際に、DRBDデバイスのサイズが新しいサイズになり、ネットワーク接続が正常に確立します。DRBDリソースで内部メタデータを使用している場合は、リソースのサイズを変更する前に、メタデータを拡張されるデバイス領域の後ろの方に移動させる必要があります。これを行うには次の手順を実行します。これは高度な手順です。慎重に検討した上で実行してください。DRBDリソースを停止します。<resource>縮小する前に、メタデータをテキストファイルに保存します。/tmp/metadata各ノードごとにそれぞれのダンプファイルを作成する必要があります。この手順は、両方のノードでそれぞれ実行します。コピーしないでください。両方のノードの下位ブロックデバイスを拡大します。セクタ単位で指定する必要があります。メタデータ領域の再初期化をします。<resource>両ノードで修正したメタデータをインポートします。パラメータ置換を使用しています。他のシェルの場合、機能する場合もしない場合もあります。環境変数を確認してください。再度DRBDリソースを起動します。<resource>一方のノードでDRBDリソースを昇格します。<resource>最後に、拡張したDRBDデバイスを活用するために、ファイルシステムを拡張します。オンラインでの縮小は外部メタデータ使用の場合のみサポートしています。しなければいけません。ファイルシステムが実際に使用している容量を、DRBDが知ることはできないため、データが失われないように注意する必要があります。ファイルシステムをオンラインで縮小できるかどうかは、使用しているファイルシステムによって異なります。ほとんどのファイルシステムはオンラインでの縮小をサポートしません。XFSは縮小そのものをサポートしません。オンラインでDRBDを縮小するには、その上位に常駐するファイルシステムを縮小した_後に_、次のコマンドを実行します。通常の乗数サフィックス(K、M、Gなど)を使用できます。DRBDを縮小したら、DRBDに含まれるブロックデバイスも縮小できます(デバイスが縮小をサポートする場合)。実行してもよいでしょう。オフライン縮小DRBDが停止しているときに下位ブロックデバイスを縮小すると、次にそのブロックデバイスを接続しようとしてもDRBDが拒否します。これは、ブロックデバイスが小さすぎる(外部メタデータを使用する場合)、またはメタデータを見つけられない(内部メタデータを使用する場合)ことが原因です。(オンライン縮小を使用出来ない場合)。これは高度な手順です。慎重に検討した上で実行してください。DRBDがまだ動作している状態で、一方のノードのファイルシステムを縮小します。DRBDリソースを停止します。<resource>縮小する前に、メタデータをテキストファイルに保存します。/tmp/metadata各ノードごとにそれぞれのダンプファイルを作成する必要があります。この手順は、両方のノードでそれぞれ実行します。コピーしないでください。両方のノードの下位ブロックデバイスを縮小します。セクタ単位で指定する必要があります。*内部メタデータを使用している場合は、メタデータ領域を再初期化します(この時点では、縮小によりおそらく内部メタデータが失われています)。<resource>両ノードで修正したメタデータをインポートします。パラメータ置換を使用しています。他のシェルの場合、機能する場合もしない場合もあります。環境変数を確認してください。再度DRBDリソースを起動します。下位デバイスのフラッシュを無効にするバッテリバックアップ書き込みキャッシュ(BBWC)を備えたデバイスでDRBDを実行している場合にのみ、デバイスのフラッシュを無効にできます。ほとんどのストレージコントローラは、バッテリが消耗すると書き込みキャッシュを自動的に無効にし、バッテリが完全になくなると即時書き込み(ライトスルー)モードに切り替える機能を備えています。このような機能を有効にすることを強くお勧めします。したがって、これはお勧めできません。DRBDは下位デバイスのフラッシュを、レプリケートされたデータセットとDRBD独自のメタデータについて、個別に有効と無効を切り替える機能を備えています。この2つのオプションはデフォルトで有効になっています。セクションで設定できます。レプリケートされたデータセットのディスクフラッシュを無効にするには、構成に次の行を記述します。...}DRBDのメタデータのディスクフラッシュを無効にするには、次の行を記述します。同期したら、両ノードで次のコマンドを実行して、これらの設定を有効にします。<resource>1台のサーバのみがBBWCがある場合[7]には、ホストセクションに以下のような設定をしてください。ハンドラを呼び出します(設定されていれば)。このハンドラを設定するには、リソース構成に次の項目を追加します。システムに存在する任意の実行可能ファイルです。いう名前のスプリットブレイン対策用のハンドラスクリプトを提供しています。これは指定したアドレスに電子メールで通知を送信するだけのシンプルなものです。次のように記述します。...}実行中のリソースで上記の変更を行い(ノード間で設定ファイルを同期すれば)、後はハンドラを有効にするための他の操作は必要ありません。次にスプリットブレインが発生すると、DRBDが新しく設定したハンドラを呼び出します。構成することを意味します。その意味をよく理解し、それを意味しない場合は設定しないでください。フェンシングポリシー、クォーラム設定、クラスタマネージャの統合、クラスタマネージャの冗長化通信リンクなどを調べて、まず最初にデータの相違状況をつくらないようにすべてきです。スプリットブレインからの自動復旧ポリシーには、状況に応じた複数のオプションが用意されています。DRBDは、スプリットブレインを検出したときのプライマリロールのノードの数にもとづいてスプリットブレイン回復手続きを適用します。セクションの次のキーワードを読み取ります。after-sb-0priスプリットブレインが検出されたときに両ノードともセカンダリロールの場合に適用されるポリシーを定義します。次のキーワードを指定できます。自動復旧は実行されません。コネクションを切断して切断モードで続行します。discard-least-changes:変更が少なかったほうのホストの変更内容を破棄してロールバックします。after-sb-1priスプリットブレインが検出されたときにどちらか1つのノードがプライマリロールである場合に適用されるポリシーを定義します。次のキーワードを指定できます。コネクションを切断して切断モードで続行します。設定したものと同じ復旧ポリシーが適用されます。スプリットブレインの犠牲ノードを選択できる場合は自動的に解決します。指定した場合と同様に動作します。指定した復旧ポリシーが適用されます。セクションで設定する必要があります。クラスタからノードを強制的に削除します。スプリットブレインの犠牲ノードにします。after-sb-2priスプリットブレインが検出されたときに両ノードともプライマリロールである場合に適用されるポリシーを定義します。同じキーワードを受け入れます。上記の3つのオプションで、DRBDは他のキーワードも認識しますが、それらはめったに使用されないためここでは省略します。マニュアルページを参照ください。デュアルプライマリモードでGFSまたはOCFS2ファイルシステムのブロックデバイスとして機能するリソースの場合、次のように復旧ポリシーを定義できます。DRBD9.xでは1つの階層で複数ノードを使用できるのでスタッキングは非推奨です。ネットワークコネクションの定義をご参照ください。次のような事項に注意する必要があります。スタックデバイス側が利用可能です。マウントして使用するデバイスになります。スタックDRBDデバイス(上位DRBDデバイス)の両方にそれぞれメタデータが存在します。内部メタデータを使用してください。2ノード構成に比べてわずかに小さくなります。プライマリロールになっている必要があります。アクティブなノードのスタックデバイスがプライマリモードで動作している必要があります。バックアップノードになっています。設定ファイルと同様に、この設定ファイルもクラスタのすべてのノード(この場合は3つ)に配布する必要があります。非スタックリソースの設定にはない、次のキーワードにご注意ください。stacked-on-top-ofこのオプションによって、DRBDに含まれるリソースがスタックリソースであることをDRBDに知らせます。セクションのうちの1つを置き換えます。下位レベルのリソースには使用しないでください。Aを使用することは必須ではありません。アプリケーションに応じて任意のDRBDのレプリケーションプロトコルを選択できます。スタックリソースを有効にするスタックリソースを有効にするには、まず、下位レベルリソースを有効にしてどちらか一方をプライマリに昇格します。r0非スタックリソースと同様に、スタックリソースの場合もDRBDメタデータを作成する必要があります。次のコマンドで実行します。次に、スタックリソースを有効にします。r0-Uこの後でバックアップノードのリソースを起動し、3ノードレプリケーションを有効にします。r0-Uこの後でバックアップノードのリソースを起動し、3ノードレプリケーションを有効にします。r0-Uクラスタ管理システムを使えばスタックリソースの管理を自動化できます。Pacemakerクラスタ管理フレームワークで管理する方法については、PacemakerクラスタでスタックDRBDリソースを使用するを参照してください。永続的なディスクレスノードノードはしばしDRBDの中で永続的にディスクレスになるときがあります。以下はディスクをもつ3つのノードと永続的なディスクレスノードの構成例です。...}永続的なディスクレスノードはビットマップスロットが割り当てられません。このようなノードのステータスは、エラーでも予期せぬ状態でもないので緑で表示されます。ような高度な機能はありません。ような基本的なIOのみが必要な場合には、適切に動作します。以下の例では、すべてのデータ領域は3台に冗長化するポリシーを想定しています。したがって最小構成で3台のサーバが必要です。データ量が増えてくると、サーバ追加の必要性に迫られます。上の図では、3ノードの各々に25TiBのボリュームがある合計75TiBの状態から、4ノードで合計100TiBの状態にしています。ノードとDRBDリソースを削除したいノードを選択する必要があります。ノードからリソースを削除する場合には注意が必要です。ノードからリソースを削除する場合にはサービスを移行するか、そのノードのリソースをDRBDクライアントとして稼働させるかにしてください。ノードから選ぶほうが簡単です(それができない場合もあるでしょうが)。移動するリソースには一時的に未使用のビットマップスロット用のスペースが必要です。時にもう一つ割り当てます。1つスロットを取っておくように設定にプレースホルダを設けてもよいでしょう。}}このスロットを実際に利用するには以下が必要です。ショートカットキーが用意されます。使用できるようになる予定であり、カーネルがメタデータを書き換えられるようになります。等で)下位のストレージリュームを作成する必要があります。次に設定ファイルのプレイスホルダーに現在のホスト名、アドレス、ストレージのパスを書き込みます。すべての必要なノードにリソース設定をコピーします。新しいノードでデータを受け取ります。そのために以下のようにして既存のノードでネットワークコネクションを定義します。<resource>そして新しいノードでDRBDデバイスを開始します。接続確認この時に、新しいノードで以下のコマンドを実行してください。接続しているか確認します。変更できるようになり、次のマイグレーション用にキープしておけるようになります。することにはリスクがあると思う方もいることでしょう。IPアドレスとホスト名を用意しておくのが簡単な方法でしょう。<resource>全ノードで実行します。クリーニング今までデータのあったノードでは、もうリソースを使用しない場合にはDRBDデバイスを次のようにして停止できます。<resource>これで下位デバイスを使用しなくなり、他の用途で使用することができるようになります。ボリュームグループに戻すことができます。まとめと他のステップ1つのリソースを新しいノードに移動しました。同様の手順で1つまたはそれ以上のリソースを、クラスタ内の既存の2つまたは3つのノードの空きスペースに行う事も可能です。3重の冗長化を行うのに必要な空き容量のあるノードが揃えば、新しいリソースを設定することが出来ます。Manageを使用して行う場合については[s-dm-rebalance]をご参照ください。クォーラム設定スプリットブレインや複製データの相違を防ぐために、フェンシングを構成する必要があります。フェンシングのすべてのオプションは、最後には冗長な通信路に依存します。それはノードが対向ノードのIPMIネットワークインタフェースに接続する形かもしれません。通信が有効であることが必要になります。クォーラムは完全に異なるアプローチをとります。基本的な考え方は、通信できるノードの数がノード総数の半分を超える場合、クラスタパーティションは複製されたデータセットを変更できるということです。そのようなパーティションのノードは、クォーラムを持つといいます。言い換えると、クォーラムを持たないノードは、複製されたデータを変更しないことを保証します。これはデータの相違を作成しないことを意味します。数値を設定することで有効にできます。動作が、前の文章で説明した動作になります。保証された最低限の冗長化デフォルトでは、ディスクを持つすべてのノードがクォーラム選挙で投票権を持ちます。言い換えると、ディスクレスノードだけが持ちません。持つ1つノードは、クォーラム投票権を持つことができます。ノードだけがクォーラム選挙で投票権を持つように変更することもできます。オプションと同じ引数をとります。このオプションを使用すると、サービスを開始する前に必要な再同期操作が完了するまで待機する、ということも表現できます。したがって、データの最低限の冗長性がサービスの可用性よりも保証されることを好む方法です。金融データとサービスなどはその一例です。以下に5ノードクラスタの設定例を示します。クォーラムを失った時の動作サービスを実行しているノードがクォーラムを失うと、すぐにデータセットの書き込み操作を中止する必要があります。これはIOがすぐにすべてのIO要求をエラーで完了し始めることを意味します。通常、これは、正常なシャットダウンが不可能であることを意味します。これはデータセットをさらに変更する必要があるためです。IOエラーはブロックレベルからファイルシステムに、ファイルシステムからユーザースペースアプリケーションに伝わります。理想的には、IOエラーの場合、アプリケーションを単に終了させることです。ファイルシステムをアンマウントし、DRBDリソースを降格させセカンダリロールに移すことを可能にします。以下はその設定例です。...}アプリケーションが最初のIOエラーで終了しない場合は、IOをフリーズさせノードをリブートさせることもできます。以下はその設定例です。タイブレーカーとしてのディスクレスノードを使用クラスタ内のすべてのノードに接続されているディスクレスノードを利用して、クォーラムネゴシエーションプロセスのタイブレークを解消できます。ノードAがプライマリで、ノードBがセカンダリである、次の2ノードクラスタを考えます。2つのノード間の接続が失われるとすぐに、2つのノードはクォーラムを失い、クラスタ上のアプリケーションはデータを書き込めなくなります。3番目のノードCをクラスタに追加し、それをディスクレスとして構成すると、タイブレーカーメカニズムを利用できます。この場合、プライマリノードとセカンダリノードが接続を失っても、両ノードはディスクレスタイブレーカーとの接続をまだ維持しています。このため、プライマリは機能し続けることができますが、セカンダリはそのディスクをOutdatedに降格させるため、サービスをそこに移行することはできません。同時に2つの接続が失われる場合は特別なケースであり、次に説明します。この場合、タイブレーカーノードはプライマリとパーティションを形成します。そのため、プライマリはクォーラムを維持し、セカンダリは古くなります。ままですが、クォーラムがないためにプライマリに昇格できません。プライマリがタイブレーカーとの接続を失う可能性を考えてみます。