その後、クラスタマネージャはノードBをプライマリに昇格させ、代わりにそこでサービスを実行し続けることができます。場合、データの相違を避ける必要があります。このシナリオを考えます。プライマリとセカンダリ間の接続が失われ、プライマリのディスクレスノードへの接続が突然失われた場合でも、アプリケーションはプライマリ上で実行を継続しています。この場合は、どのノードもプライマリに昇格できず、クラスタは動作を継続できません。データの分離を避けることは、サービスの可用性を確保することよりも常に優先されます。他のシナリオを見てみます。ここでは、アプリケーションはプライマリで実行されていますが、セカンダリは利用できません。その後、タイブレーカーはプライマリへの接続を失い、次にセカンダリに再接続します。ここで重要なのは、クォーラムを失ったノードは、ディスクレスノードに接続してもクォーラムを取り戻すことはできないことです。したがって、この場合、どのノードもクォーラムを持たず、クラスタは停止します。ラストマン・スタンディングクラスタから正常に離脱するノードは、障害が発生したノードとは異なるものとしてカウントされることに注意する必要があります。してマークされ、残りのノードにデータが無効状態であることを伝えることができます。つのノードを除くすべてのノードがクラスターから離脱した場合、そのすべてのノードが正常に離脱している限り、クォーラムを維持できます。データにアクセスすると仮定します。他のパーティションが(潜在的に)自分のパーティションよりも大きい場合、クォーラムを失います。Proxyプロセスは、DRBDが設定されているマシン上に直接配置するか、個別の専用サーバに配置することができます。Proxyインスタンスは、複数のノードの複数のDRBDデバイスのプロキシとして機能することができます。ProxyはDRBDに対して完全に透過的です。Proxyを含む転送経路に溜まるため、アクティビティログがかなり大きくなります。設定を有効にすることをお勧めします。Proxyによる遠距離レプリケーションをご参照ください。3ではLiunxカーネル2.6.26以降からのカーネルの機能を使用しています。そのため、RHEL5などの古いシステムでは使用できません。Proxy1のパッケージは提供しています。Proxyを入手するには、(日本では)サイオステクノロジー株式会社またはその販売代理店に連絡してください。Proxyを使用してください。Proxyのバージョンとアーキテクチャは、ターゲットのアーキテクチャに合わせてください)。Proxyのバージョンとアーキテクチャは、ターゲットのアーキテクチャに合わせてください)。Proxyの設定にはdrbdadmが必要なので、これもインストールします。通常に入る起動スクリプトもインストールします。Proxyの動作も設定します。Proxyの実行には、ライセンスファイルが必要です。ユーザー/グループに所有されている必要があります。Proxyもまたリソースファイルを編集して構成します。セクションで行います。Proxyの設定例を次に示します。IPアドレスはプロキシ間の通信に使用します。後者はファイヤーウォール設定で許可する必要があります。Proxyプロセスとの接続を設定したり削除したりできます。アクションによって使用されます。いう下位レベル構成ツールがあります。このツールをオプションを指定せずに呼び出した場合は、対話型モードで動作します。パラメータをコマンドに続けて使用します。使用可能なコマンドを表示するには次のようにします。"help"コマンドの周りのダブルクォートは読み飛ばされる点に注意ください。以下にコマンドを列挙します。コマンド経由で使用されます)。それ以降のものは様々なステータスや情報を表示します。arguments通信経路を作成します。コマンド経由で使用されるものなので、長い構文は省略しています。<name>通信経路を削除します。<memlimit-in-bytes>コネクションにメモリ制限を設けます。これは新規に設定したときのみ有効で、稼働中に変更することはできません。show現在設定されている通信経路を表示します。memusage各コネクションでのメモリ使用量を表示します。memusage"'メモリ使用を監視します。上記に挙げているように、クォートが必要である点にご注意ください。[h]subconnections現在接続中の各コネクションを種々の情報と共に表示します。つけると、人間が可読のバイト単位のフォーマットで出力します。[h]connections現在接続中のコネクションをステータスと共に表示します。つけると、人間が可読のバイト単位のフォーマットで出力します。行では以下のうちいずれかのステータスを表示します。Proxyプロセスとの通信経路がない。Proxyプロセスとの接続はおそらく確立しているものの、ProxyとDRBD間の経路がまだ確立していない。最初の数パケットをコネクションを通じて送信してはいるものの、まだスプリットブレインなどの状態にある。DRBDのコネクションが完全に確立された状態。プログラムをシャットダウンする。Proxyを使ったすべてのDRBDコネクションが終了します。quitdrbd-proxy-ctlプログラムを終了します(プログラムとの接続を閉じます)。Proxy自体は動作したままです。statistics現在アクティブなコネクションの読みやすいフォーマットでの詳細な統計情報を表示します。この機能をご使用の監視方法に統合して利用するのもよいでしょう。アクセス権があれば)。権限を設定している箇所をご確認ください。proxy3以降のプロキシではWANコネクション用のプラグインを使用できます。(ハードウェア圧縮サポート。詳細はhttp://www.aha.com/data-compression/参照)です。(Zstandard)は、高圧縮率を提供するリアルタイム圧縮アルゴリズムです。非常に高速なデコーダーのもとで、圧縮/速度の幅広いトレードオフ値を提供します。プロキシに必要なメモリが増加します。非常に高速な圧縮アルゴリズムです。通常データを1/2から1/4に圧縮でき、使用するネットワーク帯域も1/2から3/2程度になります。プラグインはGZIPアルゴリズムを圧縮に使用します。多少CPUを消費しますが、1/3から1/5になります。ライブラリを使用します。数百MiBの辞書を使って、小さな変更であっても非常に効率的な繰り返しデータの差分符号化を行います。高い圧縮率になります。DRBD上にVMを置いた実際の環境でテストしたところ、1/10から1/40になりました。プラグインはライセンスで有効化する必要があります。(20GBit/sec)などのハードウェア圧縮カードを使用します。現在のハードウェアではこれがもっとも高速な圧縮です。ahaプラグインはライセンスで有効化する必要があります。ご利用の環境に最適な設定についてはLINBIT(またはサイオステクノロジー)へご相談ください。性能はCPU(速度、スレッド数)、メモリ、帯域幅の入出力、CPUスパイクなどに依存します。データがあれば、設定を決定するのに役立ちます。現在使用していません。近いうちに廃止する予定です。壊れていますので、使わないでください。DRBDを使うアプリケーションがIOでブロックするかもしれません。これは将来削除されます。代わって、Linuxカーネルのトラフィック制御フレームワークを使ってください。以下の例で、インターフェース名、ソースのポート、IPアドレスを変更して使ってください。1:10この帯域幅制限は以下のコマンドで削除できます。ファシリティに記録されます。Proxyでデバッグモードを有効にするには次のようにします。いうようなメッセージがログに記録されます。その場合は、DRBDが(スタンドアローンモードでなく)両方のノードで動作していて、両方ノードでプロキシが動作していることを確認してください。両方のノードで設定値を確認してください。トラブルシューティングとエラーからの回復この章では、ハードウェアやシステムに障害が発生した場合に必要な手順について説明します。ハードドライブの障害の場合ハードドライブの障害への対処方法は、DRBDがディスクI/Oエラーを処理する方法(ディスクエラー処理ストラテジー参照)、また設定されているメタデータの種類(DRBDメタデータ参照)によって異なります。ほとんどの場合、ここで取り上げる手順はDRBDを直接物理ハードドライブ上で実行している場合にのみ適用されます。次に示す層の上でDRBDを実行している場合には通常は適用されません。手動でDRBDをハードドライブから切り離すDRBDがI/Oエラーを伝えるように設定(非推奨)している場合、まずDRBDリソースを切り離すとよいでしょう。下位デバイスからの切り離しです。[10]コマンドを実行することで、現在の状態を確認することができます。<resource>Diskless/UpToDateディスク障害がプライマリノードで発生した場合、スイッチオーバーと、この手順を組み合わせることもできます。手動での操作なしで、DRBDはすでにリソースを下位ストレージから自動的に切り離しているはずです。コマンドを使用して、リソースが実際にディスクレスモードで実行されているか確認します。障害が発生したディスクの交換(内部メタデータを使用している場合)内部メタデータを使用している場合、新しいハードディスクでDRBDデバイスを再構成するだけで十分です。交換したハードディスクのデバイス名が交換前と異なる場合は、DRBD設定ファイルを適切に変更してください。新しいメタデータを作成してから、リソースを再接続します。<resource>新しいハードディスクの完全同期がただちに自動的に始まります。監視することができます。障害の発生したディスクの交換(外部メタデータを使用している場合)外部メタデータを使用している場合でも、手順は基本的に同じです。DRBDだけではハードドライブが交換されたことを認識できないため、追加の手順が必要です。破棄するデータのある側のノードでを実行してください。このコマンドはローカルのデータを対向ノードからのデータで上書きさせます。このコマンドを実行すると破棄する側のノードのデータが失われます。コマンドが同期をトリガーします。変更し、対向ノードが再び現れるのを待ちます。切断モードでは、リソースおよびリソースに関連付けられたブロックデバイスが完全に利用可能で、必要に応じて昇格したり降格したりします。ブロックの変更は対向ノードにレプリケートされません。切断中に変更されたブロックについての内部情報は対向ノードごとにDRBDが格納します。一時的なセカンダリノードの障害に対処するセカンダリロールでリソースを持っているノードに一時的に障害が生じた場合(たとえばメモリ交換で直るようなメモリの問題)には、障害が発生したノードを修復してオンラインに戻すだけで十分です。修正したノードを起動すると、ノード間の接続が再確立され、停止中にプライマリノードに加えられた変更内容すべてがセカンダリノードに同期されます。この時点で、DRBDの再同期アルゴリズムの性質により、セカンダリノードのリソースの一貫性が一時的に失われます。この短時間の再同期の間は、対向ホストが使用できない場合でも、セカンダリノードをプライマリロールに切り替えることができません。したがって、セカンダリノードの実際のダウンタイムとその後の再同期の間は、クラスタが冗長性を持たない期間になります。DRBD9では各リソースに3ノード以上が接続することができます。そのため、例えば4ノードでは一度フェイルオーバーしてもまだ2回フェイルオーバーすることができます。一時的なプライマリノードの障害に対処するDRBDからみると、プライマリノードの障害とセカンダリノードの障害はほぼ同じです。生き残ったノードが対向ノードの障害を検出し、切断モードに切り替わります。これはクラスタ管理システムが管理します。障害が発生したノードが修復されてクラスタに戻る際に、セカンダリロールになります。述べたように、それ以上の手動による介入は必要ありません。このときもDRBDはリソースのロールを元に戻しません。変更を行うように設定されている場合は、クラス管理システムがこの変更を行います。プライマリノードに障害が発生すると、DRBDはアクティビティログというメカニズムによってブロックデバイスの整合性を確保します。詳細はアクティビティログを参照ください。永続的なノード障害に対処するノードに回復不能な問題が発生した場合やノードが永久的に破損した場合は、次の手順を行う必要があります。ディスク容量を持つハードウェアと交換します。障害が発生したノードを、それよりパフォーマンスが低いものと置き換えることも可能ですが、お勧めはできません。障害が発生したノードを、それよりディスク容量が小さいものと置き換えることはできません。このような場合には、DRBDを置き換えたノードへの接続は拒否されます。[11]OSとアプリケーションをインストールします。デバイスの初期同期の前まで実行します。この時点で、デバイスの完全同期を手動で開始する必要はありません。生き残ったプライマリノードへの接続時に、同期が自動的に開始します。スプリットブレインからの手動回復ノード間の接続が可能になると、ノード間で初期ハンドシェイクのプロトコルが交換されます。この時点でDRBDはスプリットブレインが発生したかどうかを判断できます。両方のノードがプライマリロールであるか、もしくは切断中に両方がプライマリロールになったことを検出すると、DRBDは即座にレプリケーション接続を切断します。その場合、システムログにたとえば次のようなメッセージが記録されます。状態でリソースを保持します。状態になります(一方のノードがスプリットブレインを検出する前に対向ノードが切断をした場合)。この介入は次のコマンドで行います。構成の変更が行われる予定です。場合には、次のコマンド実行します。状態の場合は自動的に再接続するので、この手順は省略できます。変化し、他のノードによって変更内容が上書きされます。スプリットブレインの犠牲ノードは、デバイスのフル同期の対象にはなりません。代わりに、ローカル側での変更がロールバックされ、スプリットブレインの生存ノードに対して加えられた変更が犠牲ノードに伝播されます。再同期が完了すると、スプリットブレインが解決したとみなされ、2つのノードが再び完全に一致した冗長レプリケーションストレージシステムとして機能します。DRBDとPacemakerクラスタPacemakerクラスタスタックとDRBDの組み合わせは、もっとも多いDRBDの使いみちです。Pacemakerはさまざまな使用シナリオでDRBDを非常に強力なものにするアプリケーションの1つです。DRBDはPacemakerクラスタで2つの使用法があります。DRBDをPacemakerで完全に制御するそれぞれの長所と短所は後で考察します。フェンシング設定を行うことを推奨します。発生する事になります。Pacemakerの基礎PacemakerはLinuxプラットフォーム向けの高度で機能豊富なクラスタリソースマネージャで、さまざまな用途で使われています。マニュアルも豊富に用意されています。この章を理解するために、以下のドキュメントを読むことを強くお勧めします。DRBDをPacemakerクラスタで管理する自律的なDRBDストレージはローカルストレージのように扱えます。Pacemakerクラスタへの組み込みは、DRBDのマウントポイントを指定することで行えます。セクションで設定しておくとよいでしょう。}}後はファイルシステム経由で使ってストレージにアクセスするだけです。Pacemaker管理下ではクラスタ内で1インスタンスのみがマウント出来ます。DRBDを下位デバイスにするマスターとスレーブのあるサービスのクラスタ設定このセクションではPacemakerクラスタでDRBDを下位デバイスにするサービスを使用する方法を説明します。DRBDの自動起動は無効にしてください。マスター/スレーブ管理が可能であり、Pacemakerから複数ノードでのDRBDリソースの起動やモニター、必要な場合には降格を行うことができます。リソースエージェントはPacemakerのシャットダウン時、またはノードをスタンバイモードにする時には、管理する全DRBDリソースを切断してデタッチを行う事を理解しておく必要があります。インストールされます。インストールされます。レガシーなOCFリソースエージェントは非推奨なので使用しないでください。先行してDRBDリソースが昇格したノードでだけサービスが起動するようにPacemakerの制約を設定しなければなりません。シェルで設定することができます。exitbyeこれで設定が有効になります。PacemakerがDRBDリソースを昇格するノードを選び、そのノードでDRBDを下位デバイスにするリソースを起動します。マスター/スレーブリソースを昇格させないようにするために必要な手順の概要を説明します。これにより、Pacemakerが古いデータでサービスを開始し、プロセスでの不要な「タイムワープ」の原因になることが回避できます。DRBD用のリソースレベルのフェンシングを有効にするには、リソース設定で次の行を追加する必要があります。セクションも変更しなければなりません。リソースレベルフェンシングで説明している設定を使用できます。Base)を使ったリソースレベルフェンシングで説明されている機能を使うことができます。最低でも2つの独立したクラスタ通信チャネルを設定しなければ、この機能は正しく動作しません。設定ファイルに最低2つのクラスタ通信のリンクを定義する必要があります。記載しなければなりません。呼ばれるリソースレベルのフェンシング機能を使用できます。ファイルに追加します。パスを調整する必要があります。