いうもう1つのボリュームグループの唯一のPVになる。(6GiB)というさらに2つの論理ボリュームが含まれる。この構成を有効にするために、次の手順を行います。オプションを設定する。"r|.*|"]このフィルタ表現が、SCSIおよびDRBDデバイスで見つかったPVシグネチャを受け入れ、その他すべてを拒否(無視)します。コマンドを実行します。LVMは構成キャッシュを破棄し、デバイスを再スキャンしてPVシグネチャを見つけます。削除して、古いキャッシュを削除してください。ここで、2つのSCSIパーティションをPVとして初期化します。いう名前の下位レベルVGを作成します。下位デバイスとして使用する論理ボリュームを作成可能です。created対向ノードでも、ここまでのすべての手順を繰り返します。いう名前の新しいリソースを作成。内容を対向ノードにコピーします。リソースを初めて有効にするに従って(両方のノードの)リソースを初期化します。一方のノードリソースを昇格する。r0リソースを昇格したノードで、DRBDデバイスを新しい物理ボリュームとして初期化します。いうVGを作成します。created最後に、新しく作成したこのVG内に新しい論理ボリュームを作成します。VGを他ノードに移動する他のノードでも使用できるように、プライマリノードで次のコマンドを実行します。r0次に他のノード(まだセカンダリの)でコマンドを発行します。他の(現在はプライマリの)ノードで有効になります。Pacemakerによる高可用性LVM対向ノード間でのボリュームグループの転送と、対応する有効な論理ボリュームの作成のプロセスは自動化することができます。リソースエージェントはまさにこのために作られています。シェルで次のコマンドを実行してみましょう。ボリュームグループを有効にします。DRBDでGFSを使用する本章では共有グローバルファイルシステム(GFS)のブロックデバイスをDRBDリソースとするために必要な手順を説明します。GFS、GFS2の両方に対応しています。DRBD上でGFSを使用するためには、デュアルプライマリモードでDRBDを設定する必要があります。DRBDリソース経由だけでなくSTONITHもです。killされる必要があります。次のような設定がよいでしょう。キャッシュである必要があります。Hatによる実装です。同様のファイルシステムのように、GFSでも複数のノードが読み取り/書き込みモードで、安全に同時に同じストレージデバイスにアクセスすることが可能です。Manager)が使用されています。本来、GFSは従来型の共有ストレージデバイスを管理するために設計されたものですが、デュアルプライマリモードでDRBDをGFS用のレプリケートされたストレージデバイスとして問題なく使用することができます。アプリケーションについては、読み書きの待ち時間が短縮されるというメリットがあります。これは、GFSが一般的に実行されるSANデバイスとは異なり、DRBDが通常はローカルストレージに対して読み書きを行うためです。DRBDは各GFSファイルシステムに物理コピーを追加して、冗長性を確保します。(CLVM)を使用します。このような対応関係が、GFSのデータストレージとしてDRBDを使用することと、従来のLVMの物理ボリュームとしてDRBDを使用することとの間に存在します。Clusterと密接に結合されています。Clusterの観点から説明します。(RHEL)と、CentOSなどの派生ディストリビューションで入手できます。GNU/Linuxでも入手できます。LinuxシステムでGFSを実行することを前提にしています。GFS用のDRBDリソースの作成GFSは共有クラスタファイルシステムで、すべてのクラスタノードからストレージに対して同時に読み取り/書き込みアクセスが行われることを前提としています。したがって、GFSファイルシステムを格納するために使用するDRBDリソースはデュアルプライマリモードで設定する必要があります。スプリットブレインからの自動回復のための機能を利用することをおすすめします。そのためには、以下の設定をリソース設定ファイルに加えてください。...}回復ポリシーを設定することは、事実上、自動データロス設定を行うことです。十分にご理解のうえご使用ください。これらのオプションを新規に設定したリソースに追加したら、通常通りにリソースを初期化できます。設定されているので、両ノードのリソースをプライマリにすることができます。DRBDリソースを認識するようにLVMを設定するGFSでは、ブロックデバイスを利用するためにクラスタ対応版のLVMであるCLVMを使用しています。DRBDでCLVMを使用するために、LVMの設定を確認してください。以下のオプション設定をしてください。3DRBDベースの物理ボリュームを認識させるためにDRBDデバイスをスキャンします。これは、従来の(非クラスタの)LVMのように適用されます。詳細はDRBDリソースを物理ボリュームとして構成するを参照してください。新規DRBDリソースを作成し、初期クラスタ設定を完了したら、両ノードで以下のサービスを有効にして起動する必要があります。GFSファイルシステムの作成デュアルプライマリのDRBDリソースでGFSファイルシステムを作成するために、まずLVMの論理ボリュームとして初期化する必要があります。従来のクラスタ非対応のLVM設定とは異なり、CLVMはクラスタ対応のため以下の手順は必ず1ノードでのみ実行してください。createdこの例ではボリュームリソースが1つの場合を前提にしています。CLVMは即座に変更を対向ノードに伝えます。)を対向ノードで実行すれば、新規作成の論理ボリュームが表示されます。ファイルシステムの作成を行います。/dev/<vg-name>/<lv-name>GFS2ファイルシステムの場合は以下になります。オプションは、GFSで保持するジャーナルの数を指定します。なるノード数と同じである必要があります。ノードをサポートしていないので、ここで設定するのは常に2です。オプションはGFS2ファイルシステムでのみ使用できます。ロックテーブル名を定義します。定義したクラスタ名と一致する必要があります。そのため、そのクラスタメンバーのみがファイルシステムを使用することができます。クラスタ内で一意の任意のファイルシステム名を使用できます。追加することができます。0GFS2の場合にはファイルシステムタイプを変更します。0この変更は必ずクラスタの両ノードで行ってください。サービスを(両ノードで)開始することで、新規ファイルシステムをマウントすることができます。サービスの前にDRBDが自動起動するよう設定してあれば、従来の共有ストレージのようにGFSファイルシステムを使用することができます。(OCFS2)を格納するブロックデバイスとしてDRBDリソースを設定する方法を説明します。DRBDリソース経由だけでなくSTONITHもです。killされる必要があります。次のような設定がよいでしょう。キャッシュである必要があります。Corporationが開発した同時アクセス共有ストレージファイルシステムです。前バージョンのOCFSはOracleデータベースペイロード専用に設計されていましたが、OCFS2はほとんどのPOSIXセマンティクスを実装する汎用ファイルシステムです。(RAC)ですが、OCFS2は負荷分散NFSクラスタなどでも使用できます。DRBDでも問題なく使用できます。OCFS2が通常実行されるSANデバイスとは異なり、DRBDはローカルストレージに対して読み書きを行うため、ファイルシステムからデータを読み取るアプリケーションの読み取り待ち時間が短縮できるというメリットがあります。DRBDの場合は、単一のファイルシステムイメージを単に共有するのではなく、各ファイルシステムイメージにさらにコピーを追加するため、OCFS2に冗長性が加わります。GFSなど他の共有クラスタファイルシステムと同様に、OCFS2で複数のノードが読み取り/書き込みモードで同じストレージデバイスに同時にアクセスできます。データが破損するおそれはありません。Manager)が使用されます。OCFS2は組み込みクラスタ通信層を使用して、クラスタメンバシップおよびファイルシステムのマウントとマウント解除操作を管理したり、これらのタスクをPacemakerクラスタインフラストラクチャに委ねることができます。Editionで利用できます。(RHEL)用のパッケージも提供しています。ServerシステムでOCFS2を実行することを前提にしています。OCFS2用のDRBDリソースの作成OCFS2は共有クラスタファイルシステムで、すべてのクラスタノードからストレージに対して同時に読み取り/書き込みアクセスが行われることを前提としています。したがって、OCFS2ファイルシステムを格納するために使用するDRBDリソースは、デュアルプライマリモードで設定する必要があります。スプリットブレインからの自動回復のための機能を利用することをおすすめします。そのためには、以下の設定をリソース設定ファイルに加えてください。...}回復ポリシーを設定することは、事実上、自動データロス設定を行うことです。十分にご理解のうえご使用ください。するのはお勧めできません。これは、最初のリソース同期が完了してから有効にしてください。これらのオプションを新規に設定したリソースに追加したら、通常通りにリソースを初期化できます。すると、両方のノードのリソースをプライマリロールに昇格することができます。することが可能になる予定です。して冗長性を高めることができます。コマンドを使って、OCFS2ファイルシステムを作成します。呼び出し時に、その他のオプションを指定することもできます。システムマニュアルページを参照ください。設定でPacemakerリソース管理に追加することができます。これはPacemakerのマスター/スレーブのデュアルマスターモードを有効にします。DRBD設定で設定されている必要があります。設定していない場合にはリソースの検証中に設定エラーが発生します。OCFS2をPacemakerで管理するにはOCFS2とロックマネージャ(DLM)の分散カーネルを管理するために、Pacemakerは、3つの異なるリソースエージェントを使用します。作成することによって、OCFS2の管理に必要なPacemakerリソースをすべてのノードで起動できます。リソースタイプのインスタンスを起動します。リソースエージェントを使います。これはクローンモードであっても同様です。p_fs_ocfs2この例ではボリュームリソースが1つの場合を前提にしています。OCFS2ファイルシステムを管理するPacemakerの制約の追加すべてのOCFS2関連のリソースとクローンを結びつけるには、Pacemaker構成に以下の制約を加えてください。DLMをサポートしない旧バージョンのPacemakerしか使えない場合、この節が参考になります。この節は以前の方式を使っている方の参照のためにだけ残してあります。新規インストールの場合にはPacemaker方式を使ってください。OCFS2クラスタを作成する際には、必ず、両方のホストを設定ファイルに追加してください。クラスタの相互接続通信には、通常はデフォルトポート(7777)が適切です。(および他の設定済みTCP/IP)が使用する既存のポートと衝突しないポートを選択する必要があります。いうグラフィカルな構成ユーティリティを使用することもできます。通常はこちらのほうが便利です。ファイルの内容はおおよそ次のようになります。使用して構成をクラスタの両方のノードに配布します。オプションを利用することができます。オプションは使用できません。パッケージを再設定してドライバを有効にします。OCFS2ファイルシステムの使用クラスタ構成を完了して、ファイルシステムを作成すると、他のファイルシステムと同様にマウントすることができます。コマンドで表示されるカーネルログに次のような行が見つかるはずです。mode.その時点から、両方のノードでOCFS2ファイルシステムに読み取り/書き込みモードでアクセスできるようになります。仮想ブロックデバイス)としてDRBDを使用する方法を説明します。(現在はCitrix傘下)が維持管理しています。(リリース5)など、ほとんどのLinuxディストリビューションの比較的新しいリリースにはXenが含まれています。準仮想化が使用されます。これは、仮想化ホストとゲスト仮想マシンの高度な協調を必要とする仮想化方式です。従来のハードウェアエミュレーションにもとづく仮想化ソリューションよりも高いパフォーマンスを実現します。適切な仮想化拡張機能をサポートするCPUの場合、Xenは完全なハードウェアエミュレーションもサポートします。ハードウェア支援仮想マシン」)と呼ばれます。(SVM、以前の「Pacifica」)です。これは、実行中のゲストオペレーティングシステムを1つの物理ホストからもう1つへ中断なく転送する機能です。DRBDリソースをレプリケートされたXen用仮想ブロックデバイス(VBD)として設定すると、2つのサーバの両方でdomUの仮想ディスクとして使えます。自動フェイルオーバさせることも可能になります。このように、DRBDは、仮想化以外の他の用途と同様に、Linuxサーバに冗長性を提供するだけでなく、Xenによって仮想化できる他のオペレーティングシステムにも冗長性を提供します。これには32ビットまたは64ビットIntel互換アーキテクチャで実行可能な実質上すべてのオペレーティングシステムが含まれます。設定してDRBDモジュールをロードすることをお勧めします。作成するか開いて、次の行を入力します。VBDとして適切なDRBDリソースを作成するXenの仮想ブロックデバイスとして使用するDRBDリソースの設定は比較的簡単です。基本的には、他の目的に使用するDRBDリソースの構成とほぼ同様です。ライブマイグレーションを有効にしたい場合は、そのリソースのデュアルプライマリモードを有効にする必要があります。...}デュアルプライマリモードを有効にするのは、Xenがライブマイグレーションを開始する前にすべてのVBDの書き込みアクセスをチェックするためです。リソースは、移行元ホストと移行先ホストの両方で使用されるように設定されます。domU設定に次のような行を追加する必要があります。してdomUで使用できるようにします。複数のDRBDリソースを単一のdomUで使用することもできます。オプションにさらに項目を追加します。次に示す3つの状況ではこの方法を使用できません。構文をサポートしない場合。構文をサポートしない場合。構文をサポートしない擬似ブートローダの例です。デバイス構文、およびリソース名ではなく、リソースに関連付けられたDRBDデバイス名を使用する必要があります。リソースタイプを使用する場合より柔軟性が低下します。DRBDで保護されたdomUの開始、停止、移行domUの開始DRBDで保護されたdomUを設定したら、通常のdomUと同様に開始できます。<domU>このとき、VBDとして設定したDRBDリソースは、プライマリロールに昇格され、通常どおりにXenにアクセスできるようになります。domUの停止これも同様に簡単です。terminated.この場合も、domUが正常にシャットダウンされると、DRBDリソースがセカンダリロールに戻ります。domUの移行これも通常のXenツールで実行します。<destination-host>この場合、短時間に連続して複数の管理ステップが自動的に実行されます。リソースがプライマリロールに昇格されます。ライブマイグレーションがローカルホストで開始します。ローカル側でリソースがセカンダリロールに降格されます。最初にリソースをデュアルプライマリモードに設定するのは、両方のリソースを短時間だけ両方のホストでプライマリロールとして実行する必要があるためです。DRBDとXen統合の内部Xenはネイティブで次のタイプの仮想ブロックデバイスをサポートします。phyこのデバイスタイプは、ホスト環境で使用可能な「物理的な」ブロックデバイスをゲストdomUに基本的には透過的な方法で渡します。fileこのデバイスタイプは、ファイルベースのブロックデバイスイメージをゲストdomUで使用するためのものです。デバイスタイプとほぼ同じ方法でdomUに渡します。いうヘルパースクリプトが使用されます。この章の前半で述べたように、このスクリプトは必要に応じてDRBDリソースの状態遷移を制御します。VBDのメリットを十分に活用するためにheartbeatを使用し、関連するdomUをheartbeatリソースとして管理することをお勧めします。domUをPacemakerリソースとして構成し、フェイルオーバを自動化することができます。OCFリソースエージェントを使用します。ヘルパースクリプトによって必要なリソース移行がすべて実行されます。ほとんど意味がありません。したがって、I/Oスループットを測定する際には、必ずDRBDがある場合とない場合の両方を測定する必要があります。ここで説明するテストは過激なものです。データが上書きされるため、DRBDデバイスの同期が失われます。そのためこのテストは、テストが完了したら破棄できるスクラッチボリュームで行ってください。I/Oスループットを見積もるには、比較的大きなデータチャンクをブロックデバイスに書き込み、システムが書き込み操作を完了するまでの時間を測定します。使用して簡単に測定できます。比較的新しいバージョンにはスループット見積もり機能が組み込まれています。ベースのスループットベンチマークは、たとえば次のようになります。いう名前のスクラッチリソースが現在接続されており、両方のノードでセカンダリロールになっています。doneこのテストでは、512MのデータチャンクをDRBDデバイスに書き込み、次に比較のために下位デバイスに書き込みます。両方のテストをそれぞれ5回繰り返し、統計平均を求めます。生成したスループット測定値です。実行ではパフォーマンスがかなり低くなりますが、これは正常な状態です。アクティビティログがいわゆる「コールド」な状態のためで、問題はありません。パフォーマンスの参考値についてはDRBDのスループット最適化をご参照ください。レイテンシの測定レイテンシ測定はスループット測定とはまったく異なります。I/Oレイテンシテストでは非常に小さいデータチャンク(理想的にはシステムが処理可能な最も小さいデータチャンク)を書き込み、書き込みが完了するまでの時間を測定します。通常はこれを何度か繰り返して、通常の統計変動を相殺します。ユーティリティを使用できますが、異なる設定とまったく異なった測定を行います。ベースの待ち時間のマイクロベンチマークです。いう名前のスクラッチリソースが現在接続されており、両方のノードでセカンダリロールになっています。oflag=directこのテストでは、4kiBのデータチャンクをDRBDデバイスに1,000回書き込み、次に比較のために下位デバイスにも1000回書き込みます。4096バイトはLinuxシステム(s390以外のすべてのアーキテクチャ)が扱うことができる最小のブロックサイズです。生成するスループット測定はこのテストではまったく意味がなく、ここで重要なのは、1,000回の書き込みが完了するまでにかかった時間です。この時間を1,000で割ると、1つのセクタへの書き込みの平均待ち時間を求めることができます。これは、シングルスレッドで厳密に1つずつ書き込みをしますので、最悪のケースではあります。I/O-depthが1の場合などです。IOPsをご参照ください。参考情報としてDRBDレイテンシの最適化もご参照ください。DRBDのスループット最適化この章では、DRBDのスループットの最適化について説明します。スループットを最適化するためのハードウェアに関する検討事項と、チューニングを行う際の詳細な推奨事項について取り上げます。ハードウェアの検討事項DRBDのスループットは、配下のI/Oサブシステム(ディスク、コントローラおよび対応するキャッシュ)の帯域幅とレプリケーションネットワークの帯域幅の両方の影響を受けます。I/OサブシステムのスループットI/Oサブシステムのスループットは主に並行して書き込み可能なストレージユニットの数と種類(ハードディスク、SSD、その他のフラッシュストレージ{FusionIOなど}...​)によって決まります。比較的新しいSCSIまたはSASディスクの場合、一般に1つのディスクに約40MB/sでストリーミング書き込みを行うことができます。SSDなら300MiB/s、最新のフラッシュストレージ(NVMe)なら1GiB/sほどになります。ストライピング構成で配備する場合は、I/Oサブシステムにより書き込みがディスク間に並列化されます。この場合、スループットは、1つのディスクのスループットに構成内に存在するストライプの数を掛けたものになります。3つのストライプがある場合は同じ40MB/sのディスクのスループットが120MB/sになり、5つのストライプがある場合は200MB/sになります。SSDとNVMeまたはNVMeのみで構成すれば容易に1GiB/s超になるでしょう。バッテリーバックアップされたバッファメモリを持つRAIDコントローラでは少量の書き込みの速度は、それらがバッファリングされることによって大幅に加速されます。非常に短い測定テストでは1GiBを示すかもしれません。持続的な書き込みではバッファがフルになるので速度は低下します。ハードウェアのディスク_ミラーリング_(RAID-1)は、一般にスループットにはほとんど影響ありません。ディスクの_パリティ付きストライピング_(RAID-5)はスループットに影響し、通常はストライピングに比べてスループットが低下します。ソフトウェアRAIDのRAID-5やRAID-6であればさらに低下します。ネットワークのスループットネットワークスループットは一般にネットワーク上に存在するトラフィック量と経路上にあるルータやスイッチなどのスループットによって決定されます。DRBDのレプリケーションリンクは通常は専用の背面間ネットワーク接続であるため、これらはあまり関係がありません。したがって、ネットワークのスループットを向上させるには、高スループットのプロトコル(10ギガビットイーサネットや56GiBインフィニバンド)に切り換えるか、複数のネットワークリンクからなるリンクアグリゲーションを使用します。ネットワークドライバを使用して実現できます。次の制限を考慮してください。DRBDのスループットは下位I/Oサブシステムのスループットにより制限される。DRBDのスループットは使用可能なネットワーク帯域幅により制限される。これは3%未満だと考えられます。ギガビットイーサネットリンクで接続されているとします。この構成ではネットワーク接続がボトルネックになります。DRBDの最大スループットは110MB/s程度でしょう。I/Oサブシステムの持続した書き込みスループットが80MB/s程度の場合は、これがボトルネックとなり、DRDBの最大スループットはわずか77MB/sになります。チューニングの推奨事項DRBDには、システムのスループットに影響する可能性があるいくつかの構成オプションがあります。ここでは、スループットを向上させるための調整について、いくつかの推奨事項を取り上げます。スループットは主としてハードウェアに依存するため、ここで取り上げるオプションを調整しても、効果はシステムによって大きく異なります。パフォーマンスチューニングについて、必ず効く「特効薬」は存在しません。設定これらのオプションはセカンダリノードの書き込みパフォーマンスに影響します。2つの書き込みバリア間で許容される書き込み要求の最大数です。以上でなければなりません。デフォルト値は両方とも2048です。比較的高パフォーマンスのハードウェアRAIDコントローラの場合、この値を8000程度に設定すれば十分です。TCP送信バッファサイズの調整TCP送信バッファは送信TCPトラフィックのメモリバッファです。デフォルトサイズは128KiBです。(専用ギガビットイーサネット、負荷分散ボンディング接続など)で使用する場合は、このサイズを2MiBかそれ以上に設定すると効果があるでしょう。送信バッファサイズを16MiB以上にすることは一般にはお勧めできません。スループットが向上する可能性もありません。...}TCP送信バッファの自動調整もサポートされます。この機能を有効にすると、DRBDが適切なTCP送信バッファサイズを動的に選択します。TCP送信バッファの自動調整を有効にするには、次のようにバッファサイズをゼロに設定します。これらの設定を確認してください。(最小128kiB、デフォルト1MiB、最大16MiB)にするとよいかもしれません。異なるものですので、変更しないでください。間違った値を指定すると、容易にマシンがout-of-memoryになってしまいます。アクティビティログサイズの調整DRBDを使用するアプリケーションが、デバイス全体に分散した小さな書き込みを頻繁に発行する、書き込み集約型の場合は、十分に大きなアクティビティログを使用することをお勧めします。ない場合、頻繁なメタデータ更新により書き込みパフォーマンスが低下する可能性があります。バッテリでバックアップされた書き込みキャッシュを持つシステムには、停電時にデータを保護する機能が組み込まれています。その場合は、同じ目的を持つDRBD自体の保護機能の一部を無効にすることもできます。これはスループットの面で有効な場合があります。説明の通り、データのコピーを追加することで読み込み性能を上げることができます。有効にする意義があります。読み込みIOスループットが欲しい場合にはコピーを増やすとよいでしょう。DRBDレイテンシの最適化この章では、DRBDのレイテンシの最適化について説明します。レイテンシを最小にするためのハードウェアに関する検討事項と、チューニングを行う際の詳細な推奨事項について取り上げます。ハードウェアの検討事項DRBDのレイテンシは、配下のI/Oサブシステム(ディスク、コントローラおよび対応するキャッシュ)のレイテンシとレプリケーションネットワークのレイテンシの両方の影響を受けます。場合、I/Oサブシステムのレイテンシには、主としてディスクの回転速度が影響します。したがって、高速回転のディスクを使用すればI/Oサブシステムのレイテンシが短縮します。場合は、フラッシュストレージのコントローラが重要な要素です。次に重要なのは未使用容量です。DRBDのTrim/Discardのサポートを使用すると、コントローラーにどのブロックがリサイクル可能かについて必要な情報を渡すことができます。使用する事ができ、書き込めるスペースが空くまで待つ必要がありません。Cache)を使用すると、書き込み完了までの時間が短くなり、書き込みのレイテンシを短縮できます。手頃な価格のストレージサブシステムの多くは何らかのバッテリバックアップキャッシュを備えており、管理者がキャッシュのどの部分を読み書き操作に使用するか設定できます。ディスク読み取りキャッシュを完全に無効にし、すべてのキャッシュメモリをディスク書き込みキャッシュとして使用する方法をお勧めします。これ以外にもいくつかの要因がありますが、そのほとんどは、DRBDレプリケーションリンクとして推奨する、DRBD専用回線接続の場合は問題になりません。イーサネットリンクには常に一定のレイテンシが発生しますが、ギガビットイーサネットでは通常、100〜200マイクロ秒程度のパケット往復時間です。ネットワークレイテンシをこれより短くするには、レイテンシが短いネットワークプロトコルを利用する以外ありません。Express、10GBeの直結などを介してDRDBを実行します。これらの場合にはおよそ50マイクロ秒程になります。InfiniBandを利用するとさらにレイテンシが小さくなります。レイテンシオーバーヘッドの予測値スループットに関して、DRDBに関連するレイテンシオーバヘッドを見積もる際には、必ず次の制限を考慮してください。DRBDのレイテンシは下位I/Oサブシステムのレイテンシにより制限される。DRBDのレイテンシは使用可能なネットワークレイテンシにより制限される。