機能していることを確認できます。これ以降は、古いリソースをプライマリロールに切り替えようとしても失敗します。なります(ネットワーク遮断中に、プライマリノードで変化が起こった場合)。2つのオプション設定をする必要があります。スクリプトがクラスタ管理システムに連絡し、このDRBDリソースに関連付けられたPacemakerのマスター/スレーブリソースが決定され、現在アクティブなノード以外のすべてのノードでマスター/スレーブリソースが昇格されることがないようにします。逆に、接続が再確立してDRBDが同期プロセスが完了すると、この制約は解除され、クラスタ管理システムは再び任意のノードのリソースを自由に昇格させることができます。PacemakerクラスタでスタックDRBDリソースを使用するDRBD9.xでは1つの階層で複数ノードを使用できるのでスタッキングは非推奨です。ネットワークコネクションの定義をご参照ください。スタックリソースを用いるとマルチノードクラスタの多重冗長性やオフサイトのディザスタリカバリ機能を実現するためにDRBDを利用できます。本セクションではそのような構成におけるDRBDおよびPacemakerの設定方法について説明します。オフサイトディザスタリカバリ機能をPacemakerクラスタに追加するこの構成シナリオでは、1つのサイトの2ノードの高可用性クラスタと、多くは別のサイトに設置する独立した1つのノードについて説明します。第3のノードは、ディザスタリカバリノードとして機能するスタンドアロンサーバです。次の図で概念を説明します。Pacemakerで管理されないオフサイトのノードです。このような構成を作成するには、スタック3ノード構成の作成の説明に従って、まずDRBDリソースを設定と初期化を行います。次のCRM構成でPacemakerを設定します。いう一時ファイルに保存し、次のコマンドで現在のクラスタにインポートします。クラスタで行われます。Primary)ロールに昇格させます。PacemakerはIPアドレス192.168.42.1の、第3ノードへのレプリケーションに使用するスタックリソースを開始します。DRBDリソースのマスターロールに昇格したノードで行われます。DRBDリソースを開始します。リソースもプライマリロールに昇格させるため、ディザスタリカバリノードとのレプリケーションが始まります。このように、このPacemaker構成では、クラスタノード間だけではなく第3のオフサイトノードでも完全なデータ冗長性が確保されます。Proxyと合わせて使用するのが一般的です。スタックリソースを使って、Pacemakerクラスタの4ノード冗長化を実現するこの構成では、全部で3つのDRBDリソース(2つの非スタック、1つのスタック)を使って、4ノードのストレージ冗長化を実現します。4ノードクラスタの目的と意義は、3ノードまで障害が発生しても、可用なサービスを提供し続けることが可能であることです。次の例で概念を説明します。2セットの2ノードPacemakerクラスタを構成しています。いう名前のクラスタを構成し、互いにDRBDリソースを使ってデータをレプリケートします。いう名前の別のDRBDリソースでレプリケートします。3番目に、DRBDリソースをスタックし、2つのクラスタを接続します。Pacemakerバージョン1.0.5のPacemakerクラスタの制限により、CIBバリデーションを有効にしたままで4ノードクラスタをつくることはできません。CIBバリデーションは汎用的に使うのには向かない特殊な高度な処理です。これは、今後のPacemakerのリリースで解決されることが予想されます。このような構成を作成するには、スタック3ノード構成の作成の説明に従って、まずDRBDリソースを設定して初期化します(ただし、ローカルがクラスタになるだけでなく、リモート側にもクラスタになる点が異なります)。クラスタを開始します。いう一時ファイルに保存し、次のコマンドで現在のクラスタにインポートします。/tmp/crm.txtCIBに上記の設定を投入すると、Pacemakerは以下のアクションを実行します。起動し、いずれかのノードをマスターに昇格します。マスターロールを担っている方)を起動します。target-role="Master"が指定されているため、スタックリソースがプライマリになります。ms_drbd_stacked:startCIBに上記の設定を投入すると、Pacemakerは以下のアクションを実行します。起動し、これらのノードのいずれかをマスターにします。マスターロールを担っている方)を起動します)。指定されているため、スタックリソースはセカンダリのままになります。2セットのSANベースPacemakerクラスタ間をDRBDでレプリケートこれは、拠点が離れた構成に用いるやや高度な設定です。2つのクラスタが関与しますが、それぞれのクラスタは別々のSANストレージにアクセスします。サイト間のIPネットワークを使って2つのSANストレージのデータを同期させるためにDRBDを使います。次の図で概念を説明します。SANベースのクラスタ間のレプリケートにDRBDを用いるこのような構成の場合、DRBDの通信にかかわるホストをあらかじめ明示的に指定しておくことは不可能です。動的接続構成の場合、DRBDは特定の物理マシンではなく仮想IPアドレスで通信先を決めます。Proxyや、またはトラック輸送のレプリケーションと組み合わせます。このタイプの設定は共有ストレージを扱うので、STONITHを構築してテストすることが、正常動作の確認のためには必要不可欠です。STONITHは本書の範囲を超えるので、以下の設定例は省略しています。セクションの代わりに指定します。このモードでは、DRBDはホスト名ではなく、IPアドレスやTCPポートで相互接続を認識します。動的接続を適切に運用するには、物理IPアドレスではなく仮想IPアドレスを指定してください(これはとても重要です)。上の例のように、離れた地点ではそれぞれ別々のIPネットワークに属するのが一般的です。したがって、動的接続を正しく運用するにはDRBDの設定だけではなく、ルータやファイアウォールの適切な設定も重要です。Pacemakerリソース構成DRBD動的接続の設定には、少なくともPacemaker設定が必要です(2つの各Pacemakerクラスタに係わる)。コマンドでPacemakerを設定します。commitbyeCIBに上記の設定を投入すると、Pacemakerは以下のアクションを実行します。いずれか)IPアドレスの設定にもとづいてDRBDリソースを起動します。DRBDリソースをプライマリにします。次に、もう一方のクラスタで、これとマッチングする設定を作成します。Pacemakerのインスタンスを次のコマンドで設定します。commitbyeCIBに上記の設定を投入すると、Pacemakerは以下のアクションを実行します。IPアドレスの設定にもとづいてDRBDリソースを起動します。指定されているため、DRBDリソースは、セカンダリのままになります。サイトのフェイルオーバ拠点が離れた構成では、サービス自体をある拠点から他の拠点に切り替える必要が生じるかもしれません。これは、計画された移行か、または悲惨な出来事の結果でしょう。計画にもとづく移行の場合、一般的な手順は次のようになります。DRBDがプライマリであることに依存したリソースは自動的に停止し、その後DRBDはセカンダリに降格します。DRBDリソースは昇格し、DRBDリソースのプライマリ側に依存した他のPacemakerリソースを起動します。リモート拠点への同期が更新されます。フェイルバックをするには、手順を逆にするだけです。アクティブな拠点で壊滅的な災害が起きると、その拠点はオフラインになり、以降その拠点からバックアップ側にレプリケートできなくなる可能性があります。DRBDリソースは昇格し、DRBDリソースがプライマリになることに依存する他のPacemakerリソースも起動します。元の拠点が回復または再構成されると、DRBDリソースに再度接続できるようになります。その後、逆の手順でフェイルバックします。Cluster高可用性クラスタのためのレプリケーションストレージとして使用する方法を説明します。Clusterは本来は共有ストレージクラスタを主な対象として設計されたもので、ノードフェンシングによって共有リソースへの危険な同時アクセスを回避します。シェルスクリプトとして実装されるフェンシングエージェントに依存しています。DRBDベースのクラスタは共有ストレージリソースを利用しないため、DRBDとしては厳密にはフェンシングは必要ありません。SuiteはDRBDベースの構成の場合でもフェンシングを必要とします。)はPacemakerと似ています。これは、クラスタ管理スイートと管理対象アプリケーションとの間の主要なインタフェースとして機能します。NFSエクスポートがマウントされているファイルシステムに依存するように、リソースは互いに依存しています。入れ子の内部のリソースが、入れ子の外部のリソースからパラメータを継承する場合もあります。Pacemakerにはリソースツリーの概念はありません。