ミラーリングのアーキテクチャおよび計画
ミラーとは、物理的に独立した複数の InterSystems IRIS インスタンスの論理グループで、プロダクション・データベースの同一コピーを同時に保持します。これによって、データベースへのアクセスを提供しているインスタンスが使用不可になった場合でも、別のインスタンスが引き継ぐことができます。ミラーでは、データベース (またはそのホスト・システム) へのアクセスを提供している InterSystems IRIS インスタンスに障害が発生した場合、別のインスタンスが自動的にかつ迅速に引き継ぐ処理である自動フェイルオーバーを通じた高可用性を実現できます。
この章では、ミラーリングのコンポーネントおよびメカニズムについて説明し、ネットワーク要件、フェイルオーバー後のアプリケーション接続のリダイレクト、仮想環境でのミラーリングなど、ミラー計画におけるさまざまな問題についても説明します。
ミラー・コンポーネント
ミラーの一部として構成されている InterSystems IRIS インスタンスをホストするシステムをミラー・メンバと呼びます (InterSystems IRIS インスタンス自体をミラー・メンバと呼ぶ場合もあります)。 ミラー・メンバには、次の 2 つのタイプがあります。
ほかに次の 2 つのコンポーネントが、1つのフェイルオーバー・メンバから別のフェイルオーバー・メンバへの自動フェイルオーバーをサポートします。
フェイルオーバー・ミラー・メンバ
自動フェイルオーバーを有効にするには、2 つのフェイルオーバー・メンバ (物理的に独立したシステムで、それぞれが InterSystems IRIS インスタンスをホストしています) がミラーに含まれている必要があります。 いつでも、一方のフェイルオーバー・インスタンスがプライマリとして動作して、ミラー内のデータベースへのアクセスをアプリケーションに提供し、他のインスタンスがバックアップとして動作して、これらのデータベースの同期コピーを保持し、プライマリとして引き継ぐことができるように準備しておきます。 プライマリの InterSystems IRIS インスタンスが使用不可になった場合、バックアップが引き継いで、データ損失のリスクなしにデータベースへのアクセスを中断なく提供します。 自動フェイルオーバー・プロセスに関する詳細は、"自動フェイルオーバーのメカニズム" を参照してください。
フェイルオーバー・メンバは、複数のミラー・メンバ・ネットワーク・アドレスを使用して、複数の通信チャンネル経由でお互いに通信します。外部クライアントは通常、現在のプライマリ上のインタフェースに常にバインドされる仮想 IP アドレス (VIP) 経由でミラーに接続します。ミラーリングされた分散キャッシュ・クラスタ内のアプリケーション・サーバ接続は、フェイルオーバー後に自動的に新しいプライマリにリダイレクトされます。したがって、この場合 VIP は不要です。
ミラーのフェイルオーバー・メンバ
ミラーのフェイルオーバー・メンバの構成に関する詳細は、"ミラーの作成" を参照してください。
Important:
ミラー内の 2 つのフェイルオーバー・メンバは同等と見なされ、いずれもプライマリとして優先されることはありません。このため、プライマリとバックアップは単なる一時的な指定であると考える必要があります。プライマリで問題が検出されてバックアップが引き継ぎ可能な場合、その引き継ぎはきわめて迅速に行われます。これは、プライマリ上の問題が、プライマリに十分な時間があれば自然に解決すると思われる場合であっても当てはまります。
フェイルオーバー･メンバ間のネットワーク遅延は、アプリケーションのパフォーマンスにおいて重要な要素であるため、接続における遅延が最小限に抑えられるように、フェイルオーバー・メンバの相対的な物理位置およびそれらのメンバ間のネットワーク接続を選択する必要があります。詳細は、"ネットワーク遅延に関する考慮事項" を参照してください。
非同期ミラー・メンバ
非同期メンバでは、ミラーリングされるデータベースの非同期コピーが保持されます。 非同期メンバとしては、災害復旧とレポートの 2 つのタイプがあります。単一のミラーに、最大 16 のメンバを含めることができます。そのため、1 つのミラーに、1 つのフェイルオーバー・ペアと、上記の 2 つのタイプを任意に組み合わせた最大 14 の非同期メンバを構成できます。自動フェイルオーバーなしで非同期メンバを利用するように、ミラーを単一のフェイルオーバー・メンバで構成することもできます。
Important:
非同期メンバのデータは、接続先のミラーで発生する変更に応じて継続的に非同期で更新されるため、非同期メンバ上での更新の同期およびクエリの結果の同期は保証されません。変化するデータに対するクエリの結果の整合性が保証されるかどうかは、非同期メンバに対して実行されるアプリケーション次第です。
ミラーへの非同期メンバの追加に関する詳細は、この章の "非同期ミラー・メンバを構成する" を参照してください。
災害復旧非同期
ミラーは、災害復旧 (DR) 非同期メンバを通して災害復旧機能を提供できます。DR 非同期メンバを手動でフェイルオーバー・メンバに昇格することができ、両方のフェイルオーバー・メンバが災害のために使用できない場合は DR 非同期メンバをプライマリに設定することさえできます。昇格した DR は、計画的メンテナンスの実施やフェイルオーバー・メンバの一時的置き換えにおいても有用です。1 つの DR 非同期メンバは 1 つのミラーにしか属することができませんが、ミラー・メンバの制限数である 16 までなら、必要な数だけ 1 つのミラー内にメンバを構成することができます。
一般に、DR 非同期ミラー・メンバは geoレプリケーションの形式となります。
単一のミラーに接続された複数の DR 非同期メンバ
Note:
DR 非同期メンバは絶対に自動フェイルオーバーの候補とはなりません。自動フェイルオーバーは 1 つのフェイルオーバー・ミラー・メンバから別のフェイルオーバー・ミラー・メンバに対してのみ行われます。
レポート非同期
レポート非同期ミラー・メンバでは、データ・マイニングやビジネス・インテリジェンスなどを目的として、選択されたデータベースの読み取り専用または読み取り/書込みのコピーが保持されます。レポート非同期メンバをフェイルオーバー・メンバに昇格することはできません。1 つのレポート非同期は最大 10 個のミラーに所属でき、別々の場所から一連の関連データベースをまとめる包括的エンタープライズ・データ・ウェアハウスとして機能できます。
複数のミラーに接続された単一レポート非同期メンバ
シングル・フェイルオーバー・ミラーの構成
1 つのミラーを、単一のフェイルオーバー・メンバと 1 つ以上の非同期メンバで構成することができます。この構成では高可用性は実現されませんが、他のニーズに対処できます。例えば、単一のフェイルオーバー・メンバ、1 つ以上の DR 非同期メンバ、および複数のレポート非同期メンバで構成されるミラーでは、データの収集と保存をサポートする一方で、データ・セキュリティおよび災害復旧を実現できます。高可用性を実現するには、フェイルオーバー・メンバを OS レベルのフェイルオーバー・クラスタまたはその他の高可用性構成に配置できます (このドキュメントの “高可用性を実現するためのフェイルオーバー方法” の章を参照してください)。
単一のフェイルオーバー・メンバと複数の非同期メンバ
ISCAgent
ISCAgent と呼ばれるプロセスは各ミラー・メンバのホスト・システム上で実行され、ミラー・メンバ間の通信に追加の手段を提供します。最も重要なのは、ISCAgent では、一方のフェイルオーバー・メンバが、もう一方のメンバに関する情報を、これら 2 つのメンバ間の通常の通信が中断された場合でも取得できるようにする方法が提供されていることです。ISCAgent は、ダウンしていたり切断しているミラー・メンバにデータを送信できます。このエージェントは、フェイルオーバーの決定にも関係しています。例えば、プライマリのインスタンスともアービターとも通信が途絶えたバックアップは、プライマリのインスタンスが本当にダウンしていることを引き継ぎの前に確認するために、プライマリの ISCAgent と通信できます (プライマリのホスト・システムがまだ動作していることが前提)。
ISCAgent がまだインストールされていない場合には、InterSystems IRIS と共に自動的にインストールされます。1 つ以上のミラーに属する複数の InterSystems IRIS インスタンスが、1 つのシステムでホストされている場合、それらのインスタンスは、1 つの ISCAgent を共有します。
ISCAgent のロールおよび構成の詳細は、この章の "自動フェイルオーバーのメカニズム" および "ISCAgent の構成" を参照してください。
アービター
アービターは、ミラーのフェイルオーバー・メンバとの継続的な通信が維持される ISCAgent をホストする独立システムで、直接通信できない場合にフェイルオーバーの決定を安全に下すために必要なコンテキストで提供します。1 つのアービターで複数のミラーに対処できますが、1 つのミラーでは一度に 1 つのアービターしか使用できません。アービターの使用は必須ではありませんが、自動フェイルオーバーが可能となる障害シナリオの範囲が大幅に広がるため、使用することを強くお勧めします。
ミラーのフェイルオーバー・メンバとアービター
Note:
バックアップがアクティブでない場合、フェイルオーバー・メカニズムでアービターが果たす役割は何もありません。
システムをアービターとして構成する場合は、最小限のソフトウェアのインストールで済み、InterSystems IRIS をインストールする必要はありません。アービターは、最小限のシステム・リソースを使用するため、他のサービスをホストしているシステムに配置でき、ワークステーションにさえ配置できます。 アービターに関する第一の要件は、アービターと単一のフェイルオーバー・メンバに同時に計画外の障害が発生するリスクを最小限に抑えるようにアービターを配置して、構成する必要があるということです。詳細は、"ミラーの可用性を最適化するためのアービターの配置" を参照してください。
ミラー同期
"データ整合性ガイド" の “ジャーナリング” の章で述べているように、ジャーナル・ファイルには、最後のバックアップ以後、InterSystems IRIS インスタンスのデータベースで行われた変更の記録が時間順に含まれています。ミラー内では、プライマリ上のデータベースに加えられた変更を記録するジャーナル・データが、バックアップおよび非同期上のデータベースのコピーに同じ変更を加える際の基礎となります。このため、ミラーリングされたデータベースは常にプライマリ上でジャーナリングされる一方で、バックアップおよび DR 非同期上では、他のソースから更新されないように常に読み取り専用となります。通常、レポート非同期上でも読み取り専用です。
ミラーリングされたデータベースでグローバル更新処理 (主に Set 処理と Kill 処理) を記録するデータがプライマリでジャーナルに書き込まれると、ジャーナル・レコードは他のミラー・メンバに送信されます。バックアップまたは非同期メンバでジャーナル・レコードが受信されると、それらのレコードに記録されている処理がそのメンバ上のデータベースで実行されます。このプロセスはデジャーナリングと呼ばれます(非同期メンバでのデジャーナリングの管理に関する重要な情報は、"データベース・デジャーナリングの管理" を参照してください)。
プライマリからバックアップへのジャーナル・レコードの転送は同期的に実行され、プライマリはバックアップからの応答を重要なポイントで待機します。これによって、"バックアップ・ステータスと自動フェイルオーバー" で詳細に説明されているように、フェイルオーバー・メンバは緊密に同期され、バックアップはアクティブである状態が保持されます。一方、非同期はプライマリから非同期的にジャーナル・データを受信します。このため、非同期ミラー・メンバはプライマリよりジャーナル・レコードが数個分遅れている場合があります。
Note:
InterSystems IRIS インスタンスがミラーのメンバとなった場合、以下のミラーリング・サポート用のジャーナル変更が発生します。
-
InterSystems IRIS インスタンスがミラーでプライマリ・フェイルオーバー・メンバとなった場合、以下の変更が生じます。
-
MIRROR-mirror_name が先頭に付く新規ジャーナル・ファイル (MIRROR-MIR21-20180921.001 など) に対してのジャーナル切り替えが発動します。その時点より、すべてのジャーナル・ファイルはミラー・ジャーナル・ファイルとして書き込まれ、mirrorjrn-mirror_name.log (mirrorjrn-MIR21.log や journal.log など) にログが記録されます。
-
[エラー発生時に凍結する] ジャーナリング構成は、ジャーナル入出力エラーが発生したときに自動的にオーバーライドされ、現在の設定に関係なく、ジャーナルされているグローバルの更新をすべて凍結します。現在の設定が [いいえ] の場合、インスタンスがプライマリ・フェイルオーバー・メンバでなくなったときに動作がこの設定に戻ります。この影響を把握するには、"データ整合性ガイド" の “ジャーナリング” の章の "ジャーナル設定の構成" および "ジャーナル入出力エラー" を参照してください。
-
インスタンスがバックアップまたは非同期のミラー・メンバになるとき、プライマリから受信したミラー・ジャーナル・ファイルは、ローカル・インスタンスの標準ジャーナル・ファイルと共に、構成済みのジャーナル・ディレクトリに書き込まれ、プライマリのミラー・ジャーナル・ログ (mirrorjrn-mirror_name.log) のコピーが install-dir\Mgr に作成され、継続的に更新されます。
ジャーナリング一般についての詳細は、"データ整合性ガイド" の “ジャーナリング” の章を参照してください。
自動フェイルオーバーのメカニズム
プライマリに障害が発生したり使用できなくなった場合にバックアップへの安全な自動フェイルオーバーを提供するようにミラーリングは設計されています。このセクションでは、この処理を可能にするメカニズムについて説明します。内容は以下のとおりです。
安全な自動フェイルオーバーの要件
バックアップの InterSystems IRIS インスタンスは、次の 2 つの条件が満たされることを確認できた場合にのみ、プライマリから自動的に引き継ぐことができます。
-
バックアップのインスタンスがプライマリから最新のジャーナル・データを受信した。
この要件によって、停止前にプライマリ上のミラーリング・データベースで行われた永続的な更新はすべて、バックアップ上の同じデータベースに対しても行われているか、またはこれから行われることが保証され、データが損失されることはなくなります。
-
プライマリのインスタンスは、もはやプライマリとしては動作しておらず、手動操作なしではプライマリとして動作できない。
この要件によって、両方のフェイルオーバー・メンバが同時にプライマリとして動作する可能性が除去されます。そのような状況が発生すると、論理データベースの性能低下と整合性の損失をまねくおそれがあります。
自動フェイルオーバーのルール
このセクションでは、自動フェイルオーバー・プロセスを制御し、双方の自動フェイルオーバー要件が確実に満たされようにするルールについて説明します。
Note:
以下の条件が当てはまらない場合、いかなる状況でもバックアップはプライマリ化を試行しません。
[開始時にマウントが必要] の詳細は、"InterSystems IRIS システム管理ガイド" の “InterSystems IRIS の管理” の章の "ローカル・データベースのプロパティの編集" を参照してください。
バックアップ・ステータスと自動フェイルオーバー
通常のミラー処理中は、バックアップ・フェイルオーバー・メンバのジャーナル転送ステータスはアクティブになっており、プライマリからすべてのジャーナル・データを受信してプライマリと同期していることを意味します(フェイルオーバー・メンバのデータベースがジャーナル・データおよび関連する詳細を使用して同期される方法については、"ミラー同期" を参照してください。また、ミラー・メンバのステータスの監視については、"ミラーの監視" を参照してください)。アクティブなバックアップは、現在のジャーナル・データをプライマリで書き込まれたままの状態で受信し、アクティブなバックアップがジャーナル・データの受信を確認しそのデータを永続的と見なすのをプライマリは待機します。これによって、アクティブなバックアップは、フェイルオーバーの 1 つ目の条件を満たします。
アクティブなバックアップがサービス品質 (QoS) タイムアウト内にプライマリからの新しいデータの受信を確認しなかった場合、プライマリはバックアップのアクティブ・ステータスを取り消し、そのバックアップの接続を解除して、一時的に障害状態に入ります。障害状態の間、プライマリは新しいジャーナル・データをコミットしないので (おそらくアプリケーションでの一時停止を引き起こす)、2 つのメンバが非同期にはならずに通信をリストアする時間か適切で安全なフェイルオーバーの決定を下す時間を確保できます。
バックアップがプライマリに再接続すると、まずプライマリから最新のジャーナル・データをすべて取得することによってキャッチアップした後で、アクティブになります。バックアップが最新ジャーナル・データをプライマリから取得してその受信を確認することでキャッチアップすると、そのアクティブ・ステータスがリストアされます。
バックアップがアクティブな場合の自動フェイルオーバー
バックアップがアクティブな際、プライマリがプライマリとしては動作しておらずに操作員の操作なしでプライマリとして動作できないという 2 つ目のフェイルオーバー条件を確認できる場合、プライマリとして引き継ぐことができます。バックアップは次の 3 つの方法のいずれかで引き継ぎができます。
-
引き継ぎを要求するプライマリから通信を受信する方法。
これは、プライマリ・インスタンスの通常シャットダウン時またはハング状態をプライマリが検出した際に発生します。 プライマリがこのメッセージを送信すると、プライマリとして動作できなくなり、アクティブなバックアップが安全に引き継ぐことができます。前のプライマリがハングしている場合、新しいプライマリはそれを強制終了します。
-
プライマリとの通信を失ったという情報をアービターから受信する方法。
プライマリとバックアップの InterSystems IRIS インスタンスでは、アービターとの継続的な通信が維持されており、これによって、他方のフェイルオーバー・メンバとの通信が切断されたかリストアされた場合は必ず、それぞれが更新されます。 ネットワーク・イベントによってバックアップとアービターの両方から同時にプライマリが切り離された場合、無限に障害状態に入ります。このように、アクティブなバックアップがプライマリとの通信を失い、アービターもプライマリとの通信が途絶えていることをアービターから確認すると、バックアップは安全に引き継ぐことができます。プライマリは障害が発生しているか切り離されていて、障害状態に入っているため、プライマリとして動作できないことがわかるからです。接続が回復すると、前のプライマリがハングしている場合、新しいプライマリはそれを強制終了します。
-
プライマリ・システムの ISCAgent から、プライマリのインスタンスがダウンまたはハングしているという情報を受信する方法。
アービターが利用できない場合や、アービターが構成されていない場合、プライマリ・インスタンスとの通信が途絶えたアクティブなバックアップは、プライマリの ISCAgent への通信を試行します (これは、プライマリのホスト・システムが動作を維持している場合のみ可能です)。これにより、プライマリ・インスタンスがダウンしているかどうかを確認し、ハング状態であった場合は強制終了させます。プライマリがプライマリとしての役割を果たせなくなっていて、そのためにフェイルオーバーが安全であることをエージェントが確認すると、バックアップがプライマリの役割を引き継ぎます。
ネットワーク・イベントによってプライマリがアクティブなバックアップから切り離されているが、バックアップでこれら 3 つの方法のいずれでも安全なフェイルオーバー状態を確保できない場合、バックアップはアクティブではなくなり、次のセクションで説明しているフェイルオーバー・メカニズムに従います。
バックアップがアクティブでない場合の自動フェイルオーバー
アクティブでないバックアップは、プライマリの ISCAgent との通信を試行して、プライマリ・インスタンスがダウンしているかどうかを確認するか、ハング状態の場合は強制終了させて、エージェントからプライマリの直近のジャーナル・データを取得するよう試行できます。旧プライマリの終了を確認し、ジャーナルを取得したら、バックアップはプライマリとして安全に引き継ぐことができます。
アクティブでないバックアップがプライマリの ISCAgent と通信できない場合、そのバックアップは、プライマリがプライマリとしての役割を果たせなくなっていることを確認する手段も、プライマリから最新のジャーナル更新を入手する手段もないため、プライマリの役割を引き継ぐことはできません。
バックアップがアクティブでない場合、フェイルオーバー・メカニズムでアービターが果たす役割は何もありません。
さまざまな停止シナリオに対するミラーの対応
このセクションでは、フェイルオーバー・メンバとアービターがさまざまな組み合わせで停止した場合のミラーの対応の概要を示します。
プライマリ停止シナリオに対応した自動フェイルオーバー
状況も詳細も異なる中で、アクティブなバックアップ・フェイルオーバー・メンバによる自動引き継ぎが実行される主要なプライマリ停止シナリオがいくつかあり、それらを以下に示します。
-
例えばメンテナンスのためなど、プライマリの計画停止が、プライマリの InterSystems IRIS インスタンスをシャットダウンすることによって開始しました。
プライマリがアクティブなバックアップに引き継ぎを指示したために自動フェイルオーバーが発生します。
-
プライマリの InterSystems IRIS インスタンスが、予期しない状態によりハングしました。
プライマリがハングを検出し、アクティブなバックアップに引き継ぎを指示したため、自動フェイルオーバーが発生します。
-
予期しない状態により、プライマリの InterSystems IRIS インスタンスが強制的にダウン状態になり、完全に無応答になりました。
このシナリオでは、プライマリはバックアップに引き継ぎを指示できません。ただし、プライマリとの通信を失っていることをアービターから確認できた後か、プライマリの ISCAgent と通信してプライマリがダウンしていることを確認した場合、アクティブなバックアップが引き継ぎます。
-
プライマリのストレージ・サブシステムに障害が発生しました。
ストレージに障害が発生すると通常はその結果として、入出力エラーによりプライマリのインスタンスがハングします。この場合、プライマリはハングを検出して、アクティブなバックアップに引き継ぎを指示します (シナリオ 2 と同様)。ただし、場合によっては、シナリオ 3 またはシナリオ 5 で示した動作が当てはまることがあります。
-
プライマリのホスト・システムに障害が発生したか応答しなくなりました。
アクティブなバックアップがアービターから、プライマリとの通信が途絶えていることを確認できると、自動フェイルオーバーが発生します。
アービターが構成されていないか、またはプライマリのホストに障害が発生する前にアービターが使用不可になっていた場合、自動フェイルオーバーは発生しません。このような場合、1 つのオプションとして、バックアップを手動で強制的にプライマリにできます。
-
ネットワーク上の問題によってプライマリが切り離されました。
アービターが構成されていて、ネットワーク障害発生時に両方のフェイルオーバー・メンバがアービターに接続されていた場合、プライマリは無限に障害状態に入ります。
-
プライマリとの通信が途絶えていることをアクティブなバックアップがアービターから確認すると、自動フェイルオーバーが発生します。
-
バックアップがプライマリとの通信を失ったと同時にアービターとの通信も失った場合、自動フェイルオーバーはできません。両方のフェイルオーバー・メンバが稼働していれば、ネットワークのリストア時にバックアップはプライマリと通信します。これによってプライマリとして処理を再開します。または、プライマリを手動で指定できます。
アービターが構成されていないか、ネットワークに障害が発生する前にいずれかのフェイルオーバー・メンバが切断されていた場合、自動フェイルオーバーはできず、プライマリはプライマリとして動作し続けます。
アクティブではないバックアップ (起動中であるか、遅れを取ってしまっているため) は、前述のシナリオ 1 から 4 までの場合、プライマリの ISCAgent と通信して、最新ジャーナル・データを取得することで引き継ぐことができます。シナリオ 5 および 6 の場合、アクティブではないバックアップは、ISCAgent と通信できないため、引き継ぐことができません。このような場合、1 つのオプションとして、バックアップを手動で強制的にプライマリにできます。
アービター停止の影響
アービターの停止がミラーの機能に直接的な影響を及ぼすことはありません。ただし、アービターがリストアされる前に、"プライマリ停止シナリオに対応した自動フェイルオーバー" に示したプライマリ停止シナリオの 5 または 6 が発生すると、バックアップによる自動的な引き継ぎができなくなります。
バックアップ停止の影響
アプリケーションによっては、プライマリが処理を再開する前に、短い間 (サービス品質タイムアウト程度の時間) 一時停止するものがあります。アービターが構成されていないか、バックアップの停止前にアービターが使用不可になっていた場合、発生する一時停止の時間はわずかに長くなることがあります (サービス品質タイムアウトの 3 倍程度の時間)。バックアップがリストアされる前にプライマリの停止が発生すると、ミラー全体の停止になります。
プライマリの停止とアービターの停止が組み合わさった場合の影響
このシナリオの結果は、"プライマリ停止シナリオに対応した自動フェイルオーバー" で説明しています。簡単に言うと、バックアップがプライマリの ISCAgent と通信できる場合は引き継ぎ、通信できない場合はミラー全体の停止となりますが、適切なオプションとして、手動操作によりバックアップを強制的にプライマリにできます。
バックアップの停止とアービターの停止が組み合わさった場合の影響
バックアップとアービターが同時に (またはほとんど同時に) 使用不可になった場合、プライマリは無限に障害状態のままです。これは、切り離されているからバックアップがプライマリになることができると見なされるためです。この結果、ミラー全体の停止となります。バックアップが再度使用可能になると、プライマリと通信します。これによってプライマリとして処理を再開します。または、プライマリを手動操作で強制的に再開することもできます。バックアップとアービターに順に障害が発生した場合、"バックアップ停止の影響" で説明した短い一時停止の後、プライマリはプライマリとして動作を続けます。これは、バックアップはプライマリになることができないと認識されるためです。
プライマリの停止とバックアップの停止が組み合わさった場合の影響
この組み合わせでは常に、ミラー全体の停止となります。この場合に使用可能なオプションについては、"両方のフェイルオーバー・メンバの計画外停止" を参照してください。
ミラーの可用性を最適化するためのアービターの配置
フェイルオーバー・メンバとアービターは共同でミラーリング高可用性ソリューションを提供します (アービターは最小限の役割を果たします)。アービターはクォーラム・メカニズムではなく、フェイルオーバー・メンバ間の通信が途絶えた場合にそれぞれにコンテキストを提供することにより、自動フェイルオーバーの処理で各フェイルオーバー・メンバをサポートします。どのような種類のプライマリ停止であってもその直前に両方のフェイルオーバー・メンバがアービターと通信しており、バックアップもアービターと通信している限り、自動フェイルオーバーができます。アービターに障害が発生すると、場合によっては自動フェイルオーバーが発生する可能性がなくなりますが、置換が構成されている際にミラーの動作を妨げることも、多くのプライマリ停止シナリオ (例えば、"プライマリ停止シナリオに対応した自動フェイルオーバー" のシナリオ 1 から 4) でのミラーによる自動フェイルオーバーの実行を妨げることもありません。
これらの理由により、それぞれが独立して高い可用性を持つフェイルオーバー・メンバよりもすぐれた高可用性をアービターが持つ必要はなく、アービターと単一フェイルオーバー・メンバに計画外の停止が同時に発生するリスクが最小限に抑えられるようにアービターを配置および構成することのみが必要です。(両方のフェイルオーバー・メンバに障害が発生するとミラーも失敗し、アービターのステータスは関係ないため、3 つすべてが同時に停止するリスクを考慮する必要はありません。)
この要件に基づいて、一般的に、フェイルオーバー・メンバが互いに分離されているのと同じだけ、アービターをフェイルオーバー・メンバから分離することをお勧めします。具体的には以下の処理を行います。
-
フェイルオーバー・メンバが 1 つのデータ・センタ内に配置されている場合、アービターを同じデータ・センタ内に配置できます。データ・センタ内で、フェイルオーバー・メンバが互いに物理的に分離されているのと同じだけ、アービターをフェイルオーバー・メンバから物理的に分離する必要があります。例えば、フェイルオーバー・メンバを別々のサーバ・ラックに配置して、1 つのラックに電力またはネットワークの問題が発生した際に両方のメンバに影響が及ばないようにしている場合、アービターをそれら 2 つのラックとは別に配置する必要があります。
データ・センタでミラー内の通信に内部ネットワークが使用されている場合、アービターをネットワークのパブリック側に配置して、内部ネットワーク内の障害によって、フェイルオーバー・メンバが互いに切り離されることも、アービターから切り離されることもないようにする必要があります。
-
フェイルオーバー・メンバが別々のデータ・センタ内に配置されている場合、アービターを 3 つ目の場所に配置する必要があります。その場所としては、別のデータ・センタ、別の関係者によってホストされている場所、パブリックまたはプライベートのクラウド・サービスのほか、システム管理者の自宅 (信頼できるネットワーキングを管理者が使用していることが前提) も考えられます。ユーザ・コミュニティを代表する場所にアービターを配置すると、ネットワーク停止時の最適なミラー対応を支援できます。
1 つのシステムが複数のミラーそれぞれに適切な場所にあれば、そのシステムを複数のミラーのアービターとして構成できます。そのように構成するには、システムがアービターとして機能する対象の各ミラーを作成または編集するときに、"ミラーの作成" の説明にあるようにホストとポート番号を指定します。
新しく配置されたシステムまたは専用のシステムでアービターをホストする必要はありません。実際、信頼性が適切に確立されている既存ホストが望ましい場合があります。レポート非同期ミラー・メンバ ("レポート非同期" を参照) が適切なホストとして機能できます。ただし、DR 非同期でのホストは避ける必要があります。メンテナンスまたは障害発生のシナリオでの DR 非同期の昇格 ("DR 非同期メンバのフェイルオーバー・メンバへの昇格" を参照) によって、アービターがフェイルオーバー・ミラー・メンバ上でホストされる可能性があり、これは間違った構成です。
Note:
"アービターのインストール" で説明するように、ISCAgent を実行しているシステムは、そのシステムが 1 つ以上の InterSystems IRIS インスタンスをホストしている場合を含め、アービターとして構成できます。ただし、ミラーのフェイルオーバー・メンバまたは DR 非同期メンバを 1 つ以上ホストしているシステムは、そのミラーのアービターとして構成してはいけません。
自動フェイルオーバーのメカニズムの詳細
このセクションでは、フェイルオーバーのメカニズムに関して追加の詳細を提示します。
フェイルオーバー・メンバ間またはフェイルオーバー・メンバとアービター間の通信が途絶えた場合のミラーの対応は、次の 2 つの異なるミラー・フェイルオーバー・モードの使用によってサポートされます。
エージェント制御モード
ミラーの開始時に、フェイルオーバー・メンバはエージェント制御モードで動作を開始します。アービターが使用不可になっているか構成されていない場合、このモードのままです。エージェント制御モードでは、フェイルオーバー・メンバは、以下で説明しているように、お互いの間の通信の損失に対応します。
通信が途絶えた場合のプライマリの対応
プライマリからアクティブなバックアップへの接続が失われた場合、またはデータ受信の確認を待機している時間がサービス品質タイムアウトを超えた場合、プライマリはバックアップのアクティブ・ステータスを取り消して、障害状態に入り、アクティブでなくなったことがバックアップで確認するのを待機します。プライマリがバックアップからの確認を受信するか、障害タイムアウト (サービス品質タイムアウトの 2 倍) の時間が過ぎると、プライマリは障害状態から出て、プライマリとして動作を再開します。
プライマリからアクティブではないバックアップへの接続が失われた場合、プライマリとして動作を続け、障害状態には入りません。
通信が途絶えた場合のバックアップの対応
バックアップがプライマリとの接続を失った場合や、プライマリからのメッセージの待機時間がサービス品質タイムアウトを超えた場合、そのバックアップはプライマリの ISCAgent との通信を試行します。そのエージェントから、プライマリのインスタンスはプライマリとして引き続き動作していることが報告されると、バックアップは再接続します。プライマリがダウンしているか、プライマリが強制終了されていることをエージェントが確認すると、バックアップは以下のように動作します。
-
バックアップがアクティブで、プライマリが障害タイムアウトの範囲内でダウンしていることをエージェントが確認した場合、バックアップはプライマリの役割を引き継ぎます。
-
バックアップがアクティブでない場合や、障害タイムアウトを超過している場合、そのバックアップは、プライマリがダウンしていることをエージェントが確認して、エージェントから最新のジャーナル・データを取得できたときに、プライマリの役割を引き継ぎます。
バックアップは、アクティブであるかどうかにかかわらず、エージェント制御モードの状態で自動的にプライマリの役割を引き継ぐことはありません。ただし、プライマリ自体がプライマリのハング状態を確認した場合、またはプライマリのエージェントが (強制終了させた後で)プライマリのダウン状態を確認した場合を除きますが、どちらの状況も、プライマリのホストがダウンしている場合や、ネットワークから切り離されている場合は発生しません。
Note:
いずれかのフェイルオーバー・メンバが再起動すると、他方の ISCAgent との通信を試行し、その動作はアクティブではないバックアップで説明したものと同じになります。
アービター制御モード
フェイルオーバー・メンバが互いに接続していて、両方がアービターに接続しており、バックアップがアクティブな場合、アービター制御モードに入ります。このモードでは、フェイルオーバー・メンバは、お互いの間の通信が途絶えた場合に、アービターから提供される他方のフェイルオーバー・メンバに関する情報に基づいて対応します。それぞれのフェイルオーバー・メンバは、アービターとの接続の損失に対して、自身から他方のフェイルオーバー・メンバへの接続と、その逆の接続をテストすることによって対応するため、1 つのネットワーク・イベントから生じる複数の接続損失が、1 つのイベントとして処理されます。
アービター制御モードでは、いずれかのフェイルオーバー・メンバがアービターへの接続のみを失ったか、バックアップがアクティブ・ステータスを失った場合に、フェイルオーバー・メンバはエージェント制御モードへの切り替えを調整して、そのモードについて説明したように、さらなるイベントに対して対応します。
アービター制御モードで、プライマリとバックアップの間の接続が失われた場合、それぞれのフェイルオーバー・メンバは、以下に説明しているようにアービターとの接続状態に基づいて対応します。
プライマリがバックアップへの接続を失った場合
プライマリがアクティブなバックアップへの接続を失った場合や、データの受信確認を待機する時間がサービス品質タイムアウトを超過した場合に、アービターもバックアップへの接続を失っているか、バックアップからの応答を待機する時間がサービス品質タイムアウトを超過していることをアービターから通知された場合、プライマリはプライマリとしての動作を継続し、エージェント制御モードに切り替えます。
アービターがバックアップに接続されていることをプライマリで確認すると、障害状態に入り、アービターを通じてバックアップとエージェント制御モードへの切り替えの調節を試行します。調節した切り替えが実行されるか、またはバックアップがアービターにはもう接続されていないことをプライマリが確認すると、プライマリはプライマリとしての通常の動作に戻ります。
バックアップへの接続と同様にアービターへの接続もプライマリが失った場合、無限に障害状態のままになるため、バックアップは安全に引き継ぐことができます。フェイルオーバーが発生すると、接続のリストア時にプライマリはシャットダウンします。
Note:
障害タイムアウトは、アービター制御モードでは適用されません。
バックアップがプライマリへの接続を失った場合
バックアップがプライマリへの接続を失った場合や、プライマリからのメッセージを待機する時間がサービス品質タイムアウトを超過した場合に、アービターもプライマリへの接続を失っているか、プライマリからの応答を待機する時間がサービス品質タイムアウトを超過していることをアービターから通知された場合、バックアップはプライマリとして役割を引き継ぎ、エージェント制御モードに切り替えます。接続が回復すると、前のプライマリがまだダウンしていない場合は、新しいプライマリはそれを強制終了します。
アービターがプライマリに接続されていることをバックアップで確認すると、バックアップは自身がアクティブであるとは見なさなくなり、エージェント制御モードに切り替え、アービターを通じてエージェント制御モードへのプライマリの切り替えに合わせます。その後バックアップは、プライマリへの再接続を試行します。
プライマリへの接続と同様にアービターへの接続もバックアップが失った場合、エージェント制御モードに切り替えて、エージェント制御メカニズムを通じてプライマリの ISCAgent への通信を試みます。
失われた接続に対するミラーの対応
次の表は、アービター制御モードで起こりうる接続の損失のすべての組み合わせに対するミラーの対応を示しています。最初の 3 つの状況は、ネットワーク障害のみを表し、それ以外には、フェイルオーバー・メンバの視点から見て、システム障害とネットワーク障害のいずれか、またはそれらの組み合わせが関係している可能性があります。説明では、1 つ以上の接続が失われる直前には、フェイルオーバー・メンバおよびアービターはすべて互いに通信し合っていて、バックアップはアクティブであったことが前提となっています。
Note:
アービター制御モードでの接続の損失のほとんどの組み合わせに対して、ミラーは、エージェント制御モードに切り替えて対応します。このため、1 つの障害イベントが処理された後、すべての接続が再確立される前に生じる後続のイベントに対する対応は、このテーブルで説明している対応ではなく "エージェント制御モード" で説明している対応と同じです。
アービター・モードで失われた接続に対するミラーの対応
|
3 つのシステムすべてが接続されている ：
|
|
バックアップはアービターへの接続を失うが、まだプライマリには接続されている ：
-
ミラーはエージェント制御モードに切り替えます。
-
プライマリは引き続きプライマリとして動作します。
-
バックアップはアービターへの再接続を試みます。
|
|
プライマリはアービターへの接続を失うが、まだバックアップには接続されている ：
-
ミラーはエージェント制御モードに切り替えます。
-
プライマリは引き続きプライマリとして動作します。
-
プライマリはアービターへの再接続を試みます。
|
|
フェイルオーバー・メンバは互いへの接続を失うが、まだアービターには接続されている ：
-
ミラーはエージェント制御モードに切り替えます。
-
プライマリは引き続きプライマリとして動作します。
-
バックアップはプライマリへの再接続を試みます。
|
|
アービターは障害が発生しているか切り離されている — フェイルオーバー・メンバはアービターの接続を失うが、まだ互いに接続されている ：
|
|
バックアップは障害が発生しているか切り離されている — プライマリとアービターはバックアップへの接続を失うが、まだ互いに接続されている ：
|
|
プライマリは障害が発生しているか切り離されている — バックアップとアービターはプライマリへの接続を失うが、まだ互いに接続されている ：
|
|
3 つの接続すべてが失われている ：
Note:
1 つのイベント (または複数の同時イベント) が原因ですべての接続が失われることはめったにありません。ほとんどの場合、ミラーはすべての接続が失われる前にエージェント制御モードに切り替えます。その場合、次のようになります。
|
自動フェイルオーバーの阻止
何らかの状況で、ミラーで自動フェイルオーバーが発生しないようにする場合、最善の方法として、単一のフェイルオーバー・メンバを 1 つ以上の DR 非同期で構成します ("非同期ミラー・メンバ" を参照)。DR 非同期は自動的に引き継ぐことはありませんが、必要に応じてプライマリも含めたフェイルオーバー・メンバに簡単に昇格できます ("DR 非同期メンバのフェイルオーバー・メンバへの昇格" を参照)。
メンテナンス処理中にバックアップに対して自動フェイルオーバーを一時的に阻止するには、バックアップを DR 非同期に一時的に降格するか、nofailover オプションを使用します。両方とも "計画的停止の手順" で説明されています。ここにはミラー処理を中断することなくフェイルオーバー・メンバにメンテナンスを実行する手順が示されています。
自動フェイルオーバー・プロセスのさまざまなポイントでアプリケーションの操作が必要な場合は、"^ZMIRROR ルーチンの使用法" を参照してください。
ミラーリング通信
このセクションでは、ミラー・メンバ間の通信について詳細に説明します。内容は以下のとおりです。
ネットワーク構成に関する考慮事項
2 つのフェイルオーバー・メンバ間でネットワークを構成する場合は、以下の一般的なネットワーク構成項目を考慮する必要があります。
-
信頼性 — 信頼性を最大限に高めるために、2 つのフェイルオーバー・メンバ間のミラー通信に対して、分離された (プライベート) ネットワークを構成する必要があります ("ミラーリング・アーキテクチャとネットワーク構成のサンプル" を参照)。さらに、このネットワークは冗長性を持たせて (ポートをフェイルオーバーボンディングした複数の NIC、複数の冗長スイッチなど) 構成する必要があります。
-
帯域幅 — アプリケーションによって生成されるジャーナル・データ量を転送するのに十分な帯域幅を使用できる必要があります。
-
遅延 — フェイルオーバー・メンバ間のネットワーク遅延は、アプリケーションのパフォーマンスにおいて重要な要素の 1 つです。詳細は、"ネットワーク遅延に関する考慮事項" を参照してください。
ミラー同期は、プライマリ・フェイルオーバー・メンバでのジャーナル書き込みサイクルの一部として行われます。ジャーナル書き込みサイクルおよびミラー同期プロセスをできる限り早く完了できることが重要です。このプロセスにおける遅延はすべて、パフォーマンスの低下につながる可能性があります。
ネットワーク遅延に関する考慮事項
フェイルオーバー・メンバ間のネットワーク遅延に厳格な上限はありません。遅延が長くなることによる影響は、アプリケーションごとに異なります。フェイルオーバー・メンバ間を往復する時間がディスク書込みサービス時間と似通っている場合、予期される影響はありません。ただし、データが保存されるのをアプリケーションが待機する必要があるとき (ジャーナル同期と呼ばれることがあります)、往復する時間が問題となる場合があります。ミラーリングされていない環境では、データの保存の待機には、ジャーナル・データの同期ディスク書き込みも含まれます。アクティブなバックアップが含まれるミラーリング環境では、フェイルオーバー・メンバ間のネットワーク往復時間も含まれます。データが保存されるのを多くのアプリケーションは待機することはないですが、それら以外のアプリケーションは頻繁に待機します。
アプリケーションの待機メカニズムに、以下の動作が含まれる場合があります。
-
同期コミット・モード (既定以外) でのトランザクションのコミット。
-
%SYS.Journal.SystemOpens in a new tab の Sync() メソッド。
-
アプリケーション・サーバ上で実行されているアプリケーションからの一般的な要求に応答する前に、分散キャッシュ・クラスタ・データ・サーバが保存を待機する動作 (ロックや $increment などのアプリケーション同期化アクションの一部として待機)。
-
ビジネス・サービスの SyncCommit 機能 (既定)
往復時間が比較的長い場合でも、アプリケーションの応答時間またはスループットに悪影響を及ぼすかどうかは、アプリケーション内で前述の動作が発生する頻度、およびアプリケーションがそのような動作を順番に処理するのか、それとも並行して処理するのかによって異なります。
ミラー・メンバ間のネットワーク遅延が問題になる場合は、オペレーティング・システムの SO_SNDBUF と SO_RCVBUF の最大値を管理する TCP パラメータを微調整することで、遅延を短縮できる可能性があります。これにより、プライマリとバックアップ/非同期は、それぞれに適切なサイズの送信バッファと受信バッファを設置できるようになります (最大 16 MB)。必要になるバッファ・サイズは、往復時間に必要なピーク時の帯域幅 ("受信ジャーナルの転送速度" を参照) と、プロトコルのオーバーヘッドおよび将来の増加を乗算したものを約 2 倍した値になります。例えば、以下の条件が当てはまるとします。
-
プライマリ・ミラー・サイトと DR サイトとの間のトラフィックは、毎秒 60 MB のジャーナル・データ (ピーク時)。
-
帯域幅を減らすために使用する圧縮は、ジャーナル・レートの約 33% が求められている。
-
往復時間は、50 ミリ秒 (一般に、1000 マイルの距離にかかる時間)。
この場合、最小のバッファサイズは、60 MB * 0.05 * .33 * 2 = 2 MB になります。バッファ・サイズをできるだけ小さく抑える大きな理由はないため、この状況では、より大きな最小値を懸念なく試してみることができます。
ミラー・トラフィックの圧縮
ミラーの作成時または編集時 (それぞれ "ミラーを作成し、第 1 のフェイルオーバー・メンバを構成する" または "フェイルオーバー・メンバの編集または削除" を参照) には、以下に示すように、プライマリからバックアップに、およびプライマリから非同期メンバに転送されるミラー・トラフィックに対して圧縮モードを選択できます。
-
システム選択 — ほとんどの環境に最適な圧縮方法を使用します。バックアップ・メンバへの転送の場合は、高帯域幅で低遅延の接続を前提として、応答時間を最適化することを意味します。つまり、ジャーナル・データは転送前に圧縮されるということです (圧縮により、フェイルオーバー・メンバの同期に必要な時間が短縮される場合)。非同期メンバへの転送の場合は、ネットワーク使用率を最適化することを意味します。[システム選択] は、フェイルオーバー・メンバと非同期の両方に対する既定の設定です。
現時点では、バックアップへの転送については、ミラーが TLS を必要とする場合にのみ、この設定で LZ4 圧縮が使用されます ("TLS セキュリティを使用したミラー通信の保護" を参照)。非同期への転送については、Zstd 圧縮が常に使用されます。この動作は、ネットワーク環境の分析メカニズムの向上と、圧縮動作の最適化に応じて、そのうちに変更される可能性があります。
-
圧縮なし — ミラー・トラフィックを圧縮しません。
-
圧縮 — 常にミラー・トラフィックを圧縮します。この設定を選択する場合、3 つの圧縮タイプ zlib (既定)、Zstd、LZ4 のうちの 1 つを選択する必要があります。
[システム選択] モード、または [圧縮] モードでのユーザの選択のいずれかにより Zstd または LZ4 圧縮を使用している場合に、受信システムでそのタイプがサポートされていないと、zlib 圧縮が代わりに使用されます。
ほとんどの量のデータベース更新が圧縮済みまたは暗号化済みのデータで構成されている場合は、[圧縮なし] を選択することが望ましいです。この状況では、圧縮に期待できる全体的な効果はほとんどありません。この場合、圧縮にかける CPU 時間が無駄になる可能性があります。この例として、圧縮されたイメージ、圧縮されたメディア、またはデータベースに設定される前に (InterSystems IRIS のデータ要素暗号化などの暗号化手法を使用して) 暗号化されたデータなどが挙げられます。InterSystems IRIS データベース暗号化またはジャーナル暗号化の使用は、圧縮を選択する際の要因にはなりません。
圧縮と TLS 暗号化は、どちらもスループットと遅延に影響する計算上のオーバーヘッドの原因になります。どちらが原因になるオーバーヘッドも同様のものですが、TLS 暗号化が使用されている場合は、追加の圧縮で暗号化する必要のあるデータの量を削減することで、実際にはオーバーヘッドを減らして、パフォーマンスを向上できます。詳細は、オペレーティング・システム、CPU アーキテクチャ、およびアプリケーション・データの圧縮率により変化します。具体的には、以下のようになります。
-
圧縮や TLS 暗号化を使用すると、データの圧縮に必要な計算時間のために、転送速度が制限されることがあります。最大転送速度は、最大圧縮速度に制限されます。ほとんどの構成では、圧縮と TLS 暗号化によって決まる最大転送速度は、実際にミラーリングに必要とされる最大スループットよりも、はるかに高速になります。一例を挙げると、このドキュメントの執筆時点では、一般的なシステムにおける圧縮と暗号化に対する計算速度は、毎秒 100 MB 程度であり、大規模なエンタープライズ・アプリケーションに対するピーク時のジャーナル作成速度よりも数倍も高速です。
-
圧縮や TLS 暗号化の使用により、ネットワーク遅延に加算される “計算上の遅延” が発生します ("ネットワーク遅延に関する考慮事項" を参照)。ほとんどのアプリケーションで、これは無視できます。圧縮や TLS 暗号化を有効にすることで達成可能なスループットよりも、さらに高いスループットが要求される構成の場合は、圧縮や TLS 暗号化を無効にして (無効にしても、認証には SSL が使用できます)、圧縮なしのピーク時の転送に十分に対応できる帯域幅を用意する必要があります。
ミラー・メンバのネットワーク・アドレス
ミラー・メンバは、お互いに通信するために、いくつかのネットワーク・アドレスを使用します。これらについては、このセクションで説明しますが、"ミラーリング・アーキテクチャとネットワーク構成のサンプル" でも説明しています。ここで説明されているミラー・アドレスの一部またはすべてに、同一のネットワーク・アドレスが使用されている可能性があることに留意してください。
-
ミラー・プライベート・アドレス
1 つの InterSystems IRIS インスタンスがプライマリ・フェイルオーバー・メンバとして実行されている場合、その他のミラー・メンバはそれぞれミラー・プライベート・アドレスを使用して、自身のミラー・データ・チャンネルを確立します。これは、プライマリからのジャーナル・データの受信に使用するチャンネルであり、最も頻繁に使用されるミラー通信チャンネルです。バックアップになろうとする第 2 のフェイルオーバー・メンバは、このアドレスに接続する必要があります。これは、フェイルオーバー・メンバに昇格された DR 非同期にも当てはまります。昇格された DR が他方のフェイルオーバー・メンバのプライベート・アドレスにアクセスできなくても、他方のフェイルオーバー・メンバがダウンしたときにプライマリになることは可能ですが、バックアップになることはできません。
プライマリは、非同期メンバの監視のために、ミラー・プライベート・アドレスも使用することがあります。
非同期メンバは、プライマリのミラー・プライベート・アドレスに接続しようしますが、そのミラー・プライベート・アドレスでプライマリに到達できないと、プライマリのスーパーサーバ・アドレスにフォールバックします。これにより、また ISCAgent がジャーナル・データを他のミラー・メンバに送信できることにより、場合によっては、ジャーナル・データはミラー・プライベート・ネットワーク以外のネットワーク経由で転送されます。
Note:
管理ポータルを使用して非同期メンバをミラーに追加する際に ("非同期ミラー・メンバを構成する" を参照)、[非同期メンバのアドレス] を入力します。このプロンプトで指定するアドレスは、非同期メンバのミラー・プライベート・アドレスおよびスーパーサーバ・アドレスになります。これらを異なったものにする場合、ミラーに追加した後に、プライマリで非同期のアドレスを更新できます。
-
スーパーサーバ・アドレス/ポート
このアドレスを使用して、外部ミラー認識システムをプライマリに接続できます。現時点では、そのような外部システムのみが、ミラーリングされた分散キャッシュ・クラスタ内のアプリケーション・サーバになります ("フェイルオーバーまたは災害復旧後のアプリケーション接続のリダイレクト" を参照)。ただし、将来、これは別の接続にも拡張される可能性があります。その他のミラー・メンバも特定の制御目的および監視目的のためにメンバのスーパーサーバ・アドレスに接続することがあります。例えば、プライマリは、非同期メンバの監視に、このアドレスを使用することがあります。プライマリのミラー・プライベート・アドレスにアクセスできない場合、非同期メンバはこのアドレスを使用してプライマリへのデータ・チャンネルを確立しようとします。これは、ジャーナル・データがこのネットワーク経由で転送可能であることを意味します。
-
エージェント・アドレス/ポート
このメンバのエージェントに通信しようとする場合、他のメンバはまずこのアドレスを試用します。重要なエージェント関数 (フェイルオーバーの決定に使用する関数など) は、このアドレスにアクセスできないと、ミラー・プライベート・アドレスおよびスーパーサーバ・アドレス (異なる場合) を使用して再試行します。エージェントはジャーナル・データを他のメンバに送信することができるので、ジャーナル・データはこのネットワーク経由で転送できます。
-
仮想 IP (VIP) アドレス
"ミラー仮想 IP (VIP) の計画" で説明しているように仮想 IP (VIP) アドレスを使用する場合、プライマリ・フェイルオーバー・メンバを作成または編集するときに VIP アドレスを入力する必要があります。プライマリは、プライマリになる処理の一環として自身をこのアドレスに動的に登録します。2 つのフェイルオーバー・メンバは、フェイルオーバーの発生時にバックアップが VIP を取得できるように VIP に関連付けられているネットワークの同じサブネットに配置する必要があります。管理者は通常、VIP アドレスに DNS サーバの DNS 名を指定します。このアドレスをミラーリング構成の他の場所で使用してはいけません (アプリケーション・サーバの接続先のアドレスとしても使用してはいけません。ECP には、スーパーサーバ・アドレスを使用してプライマリを検索する独自のメカニズムがあります)。
-
アービター・アドレス/ポート (送信)
フェイルオーバー・メンバがアービターへの接続に使用するアドレスです。このアドレスは、プライマリ・フェイルオーバー・メンバを作成または編集するときに構成します。アービターのネットワーク上の場所に関する重要な情報は、"ミラーの可用性を最適化するためのアービターの配置" を参照してください。
ここで説明したアドレス間のミラー通信に対する TLS の構成は任意ですが、強くお勧めします。機密データがフェイルオーバー・メンバ間で受け渡しされるためです。TLS は、ISCAgent に対する認証を提供します。ISCAgent は、ジャーナル・ファイルへのリモート・アクセスを提供し、システムを強制的に停止したり、その仮想 IP アドレスを操作できます。インスタンスでジャーナルの暗号化が有効になっていて、そのインスタンスをミラーのプライマリ・フェイルオーバー・メンバに設定する場合、TLS を使用するようにミラーを構成する必要があります。詳細は、"TLS セキュリティを使用したミラー通信の保護" を参照してください。
ミラーリング・アーキテクチャとネットワーク構成のサンプル
このセクションでは、ミラーリング・アーキテクチャと構成のサンプルをいくつか示して説明します。
一部の図では、災害復旧 (DR) 非同期メンバおよびレポート非同期メンバがさまざまな位置に描かれています。いずれかまたは両方を省略することも、それぞれを複数許可することもでき、また概して、異なる図で描かれている位置を組み合わせることもできます。
図で示すことを目的として、組織の内部ネットワークのサンプル IPv4 アドレスが示されています。サブネットは 24 ビットで指定される (つまり、CIDR 表記 a.b.c.d/24 または ネットマスク 255.255.255.0) ことが前提となっているため、同じサブネットに対して記載されているアドレスは、4 番目のドット区切り部分のみが異なります。
ミラー構成の IP アドレスの代わりに、それに相当する DNS 名も指定されている場合があります。ただし、ミラー仮想 IP (VIP) アドレスの場合は IP アドレスである必要があるため、この限りではありません。
単一のデータ・センタ、コンピュータ・ルーム、またはキャンパス内のミラーリング構成
以下の図は、1 つのデータ・センタ、コンピュータ・ルーム、またはキャンパス内で一般的な、さまざまなミラーリング構成を示しています。それぞれの図は、該当するネットワーク・トポロジ、およびミラー構成に指定されているネットワーク・アドレスとのリレーションシップを示しています。バリエーションが示されており、特にミラー・メンバが同一キャンパス内の複数の場所に配置されている場合に適用できることがあります。
単純なフェイルオーバーのペア
これは、最も単純なミラー構成です。複数のフェイルオーバー・メンバはプライベート・ネットワーク経由で互いに通信し、それらへの外部接続はパブリック・ネットワークを通じて確立されます。オプションでミラー仮想 IP (VIP) が使用されます。アービターは外部ネットワーク上にありますが ("ミラーの可用性を最適化するためのアービターの配置" で推奨されているとおり)、アービターへの接続を開始するのは常にフェイルオーバー・メンバであることから、VIP はアービターへの接続には関連していません。
この構成では、以下の IP アドレスが使用されています。
メモ ：
-
VIP では、両方のフェイルオーバー・メンバが同一のサブネットに配置されている必要があります。
-
ミラーリングに必須というわけではありませんが、ネットワーク使用率を最適に制御できるように、ここに示しているミラー通信用の個別プライベート LAN をお勧めします。このような LAN を使用しない場合、緑の背景で示しているアドレスを使用するようにミラー構成でミラー・プライベート・アドレスを変更する必要があります。ここに示されているように、メンバがこのネットワークの同一サブネット上にあることをミラー・プライベート・アドレスは示唆していますが、これは必須ではありません。
DR およびレポートが非同期に均一に接続されたフェイルオーバーのペア
この構成では、DR 非同期で機能上の柔軟性が最大限にでき、災害復旧機能を実現できることに加えて、メンテナンスや修理のために停止しているフェイルオーバー・メンバに代わるために昇格できます。昇格された DR はバックアップまたはプライマリとして完全に機能することができ、VIP に追加されます。フェイルオーバー・メンバと DR は、VIP の同一パブリック接続サブネット上にあります。これらのプライベート・ネットワーク・アドレスが使用される場合、これらはお互いにアクセス可能です (同じサブネットではない場合は、ルーティングによって)。ネットワーク・トポロジおよびネットワーク遅延によって、DR と 2 つのフェイルオーバー・メンバとの間に可能な物理的な分離に、制約が加わる場合があります。
この構成では、以下の IP アドレスが使用されています。
メモ ：
-
VIP を保持または取得できるメンバはすべて同じサブネット上に配置する必要があります。
-
ここに示しているミラー通信用の個別プライベート LAN はミラーリングに必須ではありませんが、ネットワーク使用率の最適制御でお勧めします。このような LAN を使用しない場合、緑で示しているアドレスを使用するようにミラー構成でミラー・プライベート・アドレスを変更する必要があります。示されているミラー・プライベート・アドレスは、メンバがこのネットワークの同一サブネット上にあることを示唆していますが、これは必須ではありません。
-
レポート・メンバはプライマリになることはできないため、ミラー・プライベート・ネットワークでは送信接続のみを確立します。このため、そのアドレスを、ミラー構成で個別に指定する必要はありません。
DR およびレポートがキャンパス上の任意の場所にあるフェイルオーバーのペア
この構成では、非同期メンバの位置およびそれらに接続しているネットワークにおいて最大限の柔軟性を実現できます。この構成において DR が VIP サブネット上にあることは前提となっていないため、災害復旧時の DR へのユーザ接続のリダイレクトには、他の代替方法を使用する必要があります。例えば、VIP ではなく DR 非同期の IP をポイントするように DNS 名を手動で更新することや、"フェイルオーバーまたは災害復旧後のアプリケーション接続のリダイレクト" で説明したメカニズムのいずれかを構成できます。さらに、DR メンバがミラー・プライベート・ネットワーク (使用されている場合) に接続されていることは前提となっていないため、稼働中のフェイルオーバー・メンバがない場合に限り、プライマリにするためにのみ昇格できます。
この構成では、以下の IP アドレスが使用されています。
メモ ：
-
仮想 IP を取得するメンバはすべて、同じサブネット上に配置する必要があります。
-
ここでは、ミラー通信用の個別プライベート LAN が示されていますが、必須ではありません。このような LAN を使用しない場合、緑で示しているアドレスを使用するようにミラー構成でミラー・プライベート・アドレスを変更する必要があります。示されているミラー・プライベート・アドレスは、フェイルオーバー・メンバがこのネットワークの同一サブネット上にあることを示唆していますが、これは必須ではありません。
災害復旧およびレポート専用のミラーリング
この構成では、DR とレポートのいずれかまたは両方の機能のみを提供するミラーリングを使用します。このドキュメントの “高可用性を実現するためのフェイルオーバー方法” の章で説明されているように、OS フェイルオーバー・クラスタリング、仮想 HA、またはその他のインフラストラクチャレベルのオプションを使用すると、単一のフェイルオーバー・メンバの場合に高可用性が実現されます。この構成で自動フェイルオーバーにミラーリングは使用されないため、VIP は描かれていません。必要に応じて、障害復旧時に使用するために VIP を構成できますが、これには DR メンバをフェイルオーバー・メンバと同じサブネットに配置する必要があります。または、災害復旧時の DR へのユーザ接続のリダイレクトに、"フェイルオーバーまたは災害復旧後のアプリケーション接続のリダイレクト" で説明したような代替のテクノロジまたは手順を使用する必要があります。
この構成では、以下の IP アドレスが使用されています。
メモ ：
-
ここでは、ミラー通信用の個別プライベート LAN が示されていますが、必須ではありません。このような LAN を使用しない場合、緑で示しているアドレスを使用するようにミラー構成でミラー・プライベート・アドレスを変更する必要があります。示されているミラー・プライベート・アドレスは、フェイルオーバー・メンバがこのネットワークの同一サブネット上にあることを示唆していますが、これは必須ではありません。
-
レポート・メンバはプライマリになることはできないため、ミラー・プライベート・ネットワークでは送信接続のみを確立します。このため、そのアドレスを、ミラー構成で個別に指定する必要はありません。
分散キャッシュ・クラスタでのミラーリング
この図は、ミラーリング環境に追加されたアプリケーション・サーバを示しています。複雑性は高まりますが、アプリケーション・サーバ層によって水平スケーラビリティが可能となり、データベース・サーバのフェイルオーバーを通してユーザ・セッションが保持されます。分散キャッシュおよび分散キャッシュ・クラスタの詳細は、"スケーラビリティ・ガイド" の “分散キャッシュによるユーザ数に応じた水平方向の拡張” の章を参照してください。
この構成では、以下の IP アドレスが使用されています。
メモ ：
-
アプリケーション・サーバは VIP を使用せず、任意のフェイルオーバー・メンバまたは昇格されてプライマリになった DR メンバに接続するため、VIP はプライマリへのユーザの直接接続がある場合は、それのみに使用されます。VIP では、両方のフェイルオーバー・メンバが同一のサブネットに配置されている必要があります。DR メンバが昇格時に VIP を取得するには、同じサブネットに配置する必要もあります。同じサブネットに配置していない場合、"フェイルオーバーまたは災害復旧後のアプリケーション接続のリダイレクト" を参照してください。
-
ここに示されている ECP 通信とミラー通信のプライベート LAN は両方とも必須ではありませんが、ネットワーク使用率および ECP データのプライバシーを最適に制御するために使用することをお勧めします。いずれかのネットワークを別のネットワークに折りたたむことによって、ネットワーク数を少なくした構成が可能です。示されているプライベート・アドレスは、メンバがこれらのネットワークの同じサブネット上にあることを示唆していますが、唯一の要件は、これらのアドレスがお互いにルーティングできることです。
ネットワーク・レイアウトについて検討する場合は、すべての非同期メンバが、プライマリのミラー・プライベート・アドレスかスーパーサーバ・アドレスでプライマリに接続できる必要があることを忘れないでください。このように、示されている構成では、緑のユーザ・ネットワークにのみアクセスできる非同期メンバは機能しません。
-
レポート・メンバはプライマリになることはできないため、ミラー・プライベート・ネットワークでは送信接続のみを確立します。このため、そのアドレスを、ミラー構成で個別に指定する必要はありません。
2 つのデータ・センタと地理的に分離された災害復旧に対するミラーリング構成
以下の図は、データ・センタ、キャンパス、または地域に影響を与える災害から復旧するために地理的な分離を利用した HA および DR 構成を示しています。図を単純にするためにこれらの図からレポート・メンバは省略されていますが、単一キャンパス構成で示したとおりに、いずれかの場所に追加できます。
以下の構成にはすべて、他方の場所のメンバがプライマリになったときに、そのプライマリに接続をリダイレクトする方法が必要です。地理的に分離されている場所の場合、これら 2 つの場所にわたってサブネットを拡張することが必要であるため、VIP を構成することは難しいか、または不可能な場合があります。構成したとしても、以下の段落で説明しているように、十分ではない可能性があります。"フェイルオーバーまたは災害復旧後のアプリケーション接続のリダイレクト" で説明したような代替のテクノロジ、ハードウェア、または手順では、接続をリダイレクトする他の方法を使用できます。拡張されたサブネットを利用するかどうかにかかわらず、VIP は単一のデータ・センタ内の 2 つのメンバ間の自動フェイルオーバーにはきわめて有用であるため、以下の図では VIP の使用が描かれています。
VIP 用に拡張されたサブネットは通常、内部イントラネット・アプリケーションに役立ちます。これにより、緑で示されている LAN/WAN への接続 (つまり VPN アクセス) があるユーザおよびシステムは、VIP 経由でいずれかの場所にあるプライマリにアクセスできます。
一方、インターネットに接続するアプリケーションの場合、VIP 用に拡張されたサブネットが、災害時に接続のソリューションを提供することはありません。メイン・データ・センタの DMZ が、内部ミラー VIP のプロキシとして、アプリケーションのインターネット接続 IP アドレスと DNS 名のいずれかまたは両方を提供します。災害時には、これらを他方のデータ・センタに外部的に転送する必要がある場合があります。ソリューションには、高度な外部ルーティングまたは "フェイルオーバーまたは災害復旧後のアプリケーション接続のリダイレクト" で説明したいずれかの手法が使用されます。これらの手法のいずれでも、拡張されたサブネットの必要性は除去されます。
ローカル DR と地理的に分離された DR を使用したフェイルオーバーのペア
ローカル DR 非同期は、一方または両方のフェイルオーバー・メンバに影響を与えるイベントの不測の事態に備えます。ローカル DR を昇格して、メンテナンスや修理のために停止しているいずれかのフェイルオーバー・メンバの代わりとすることも、両方のフェイルオーバー・メンバに影響を及ぼす災害からの復旧に使用することもできます。地理的に分離されている DR は、メイン・データ・センタまたはキャンパス全体に影響を及ぼす災害からの復旧に使用されます。
この構成では、以下の IP アドレスが使用されています。
メモ ：
-
VIP の前述の説明を参照してください。
-
可能な場合、ミラー・プライベート・ネットワーク (使用されている場合) に、データ・センタ相互接続 (WAN) を使用して DR データ・センタからアクセスできるようにすると、メンバ J にさらに機能上の柔軟性がもたらされます。これには、サブネットの拡張は必要ではなく、対象のネットワーク上のトラフィックをデータ・センタ間でルーティングすることだけが必要です。この構成では、J を昇格した場合、メイン・データ・センタのプライマリにバックアップとして接続できます。DR にミラー・プライベート・ネットワークへのアクセス権がない場合、プライマリとして機能させるためだけに昇格でき、稼働中のフェイルオーバー・メンバがない場合にのみこれは可能です。ここで述べた柔軟性は主として、VIP が拡張されていて、アプリケーションがデータ・センタ間の遅延に実質上は影響を受けない構成において有用です。
地理的に分離されていて、完全に冗長な DR 環境を使用したフェイルオーバーのペア
データ・センタ 1 に影響を及ぼす災害の発生時には、データ・センタ 2 内の 2 つの DR メンバが昇格され、完全に冗長な代替 HA 環境が提供されます。この構成では、以下の IP アドレスが使用されています。
メモ ：
-
VIP の前述の説明を参照してください。この図では、拡張されたサブネットは前提となっていません。代わりに、データ・センタ 2 への移行時に、そのデータ・センタ内での後続の自動フェイルオーバーに別の VIP を使用するようミラーが再構成されます。外部のテクノロジ、ハードウェア、または手順は、"フェイルオーバーまたは災害復旧後のアプリケーション接続のリダイレクト" で説明したように、この新しい VIP アドレスへの接続のリダイレクトに使用されます。
-
可能な場合、両方のデータ・センタから、データ・センタ相互接続 (WAN) を使用してミラー・プライベート・ネットワーク (使用されている場合) にアクセスできるようにすると、機能上の柔軟性がもたらされます。これには、サブネットの拡張は必要ではなく、対象のネットワーク上のトラフィックをデータ・センタ間でルーティングすることだけが必要です。この構成では、一方のデータ・センタ内の昇格された DR メンバが、バックアップとして他方のデータ・センタ内のプライマリに接続できます。これは主として、VIP が拡張されていて、アプリケーションがデータ・センタ間の遅延に実質上は影響を受けない構成において有用です。(DR にミラー・プライベート・ネットワークへのアクセス権がない場合、プライマリとして機能させるためだけに昇格でき、稼働中のフェイルオーバー・メンバがない場合にのみこれは可能です。)
-
データ・センタ 1 が完全にオフラインになり、メンバ J および K がフェイルオーバー・メンバに昇格された場合、新しいアービターをデータ・センタ 2 で使用可能にすることができ、ミラー構成を新しいアービターの IP アドレスで更新することができます。示されている構成では、反対側のデータ・センタで 2 つのフェイルオーバー・メンバを使用して長時間動作することは意図されていません。このように動作する場合、別の 3 つ目の場所 (この描画ではインターネット) にアービターを配置することをお勧めします。詳細は、"ミラーの可用性を最適化するためのアービターの配置" を参照してください。
地理的に分離されたフェイルオーバーのペア
この構成では、別個の場所で 2 つのマシンを利用して、最小限のハードウェアで高可用性と災害復旧の両方のニーズを満たします。フェイルオーバー・メンバ間のネットワーク遅延は、重要な考慮事項の 1 つですが、その影響がある場合、それはアプリケーションによって異なります。詳細は、"ネットワーク遅延に関する考慮事項" を参照してください。
ミラーリングでは、1 つのフェイルオーバー・メンバがプライマリとして動作するためにもう 1 つのフェイルオーバー・メンバより優先されることはなく、フェイルオーバーはあらゆるタイプの停止の結果として生じ、これはプライマリ上の問題が一時的なものであったことがわかった場合でも当てはまります。このため、この構成は、特定のデータ・センタで実行されているプライマリに暗黙的な優先順位がない場合に最適です。
この構成では、前述の説明で示されている理由により、VIP の使用は可能かどうかはわかりません。2 つのデータ・センタ間のフェイルオーバーは自動的に発生するため、採用する代替方法では、ユーザを迅速に自動で新しいプライマリにリダイレクトする必要があります。手動操作が必要な方法は通常、十分ではありません。
この構成では、以下の IP アドレスが使用されています。
メモ ：
-
この構成では、アービターは、3 つ目の場所に配置することが最適です。詳細は、"ミラーの可用性を最適化するためのアービターの配置" を参照してください。
-
ここでは、データ・センタ相互接続 (WAN) 経由で実行されるミラー通信のプライベート・ネットワークが描かれていますが、これは必須ではありません。
フェイルオーバーまたは災害復旧後のアプリケーション接続のリダイレクト
バックアップ・フェイルオーバー・メンバが自動フェイルオーバーによってプライマリになるか、DR 非同期を手動で、災害復旧の一部としプライマリに昇格する場合、アプリケーション接続を新しいプライマリにリダイレクトするメカニズムが必要です。これを実現する方法は多数ありますが、この章ではそのいくつかを詳しく取り上げます。1 つのソリューションを自動フェイルオーバーと DR の昇格の両方に適用することも、複数のソリューションを組み合わせることもできます。例えば、自動フェイルオーバーにはミラー VIP を使用し、DR の昇格には DNS の更新を使用する方法です。
組み込みのメカニズム
"ミラーリング・アーキテクチャとネットワーク構成のサンプル" で示しているように、ミラー構成に以下のメカニズムを追加して、アプリケーションのリダイレクトに対処できます。
-
ミラー仮想 IP アドレス (VIP)
ミラー VIP が使用されていて ("ミラー仮想 IP (VIP) の計画" を参照)、メンバがプライマリになった場合、VIP が新しいプライマリ上のローカル・インタフェースに自動的にバインドされます。これにより、外部クライアントは同じ IP アドレスに引き続き接続できます。"ミラーリング・アーキテクチャとネットワーク構成のサンプル" で示しているように、VIP の使用では、メンバが同一のサブネット上でプライマリになることが可能である必要があります。
Note:
通常、VIP はクラウド環境では使用できません。クラウドでミラーリングする場合の代替手段やその他の考慮事項は、"クラウド環境でのミラーリング" を参照してください。
-
分散キャッシュ・クラスタ
ミラーリングされた分散キャッシュ・クラスタ ("ミラーへのアプリケーション・サーバ接続の構成" を参照) では、フェイルオーバー・メンバをデータ・サーバとして構成し、すべてのアプリケーション・サーバの接続を具体的にミラー接続として構成します。フェイルオーバーに続き、アプリケーション・サーバが新しいプライマリ・フェイルオーバー・メンバへのそれぞれの接続を再確立し、進行中の作業負荷を引き続き処理します。フェイルオーバー・プロセスの実行中は、アプリケーション・サーバに接続しているユーザが作業に復帰する前に、接続が一時的に中断することがあります。ECP リカバリの詳細は、"スケーラビリティ・ガイド” の “InterSystems 分散キャッシュによるユーザ数に応じたシステムの水平方向の拡張” の章の "ECP リカバリ" および "ECP リカバリ・プロセス、保証、および制限" を参照してください。
分散キャッシュの主な目的は水平方向の拡張であることに注意してください。クラスタを単に HA の計画のコンポーネントとして配置することは、メリットだけでなく、複雑さの増大や新たな障害点の発生などの追加的なコストも生じる可能性があります。
-
Web ゲートウェイ
Web ゲートウェイのサーバ・アクセス・エントリがミラー認識で構成されている場合、ゲートウェイは初期構成でフェイルオーバー・メンバのいずれかに接続され、そのメンバからミラー内のフェイルオーバーおよび DR 非同期メンバのリストを取得します。ゲートウェイはこのリストに基づいて現在のプライマリを識別して接続します。 ミラーがフェイルオーバーした場合、ゲートウェイは新しいプライマリに接続を変更します。フェイルオーバー・メンバの中でプライマリが見つからない場合、ゲートウェイはリスト内の DR 非同期の中からプライマリを見つけようと試みます。これにより、DR 非同期がプライマリに昇格するとゲートウェイは接続を再確立できます。ミラー認識構成のゲートウェイ接続では、スーパーサーバ・アドレスを使用してミラー・メンバと通信します ("ミラー・メンバのネットワーク・アドレス" を参照)。
一般に、アプリケーション接続をプライマリにリダイレクトする他の方法が有効になっている場合 (VIP など)、そのメカニズムへの標準の Web ゲートウェイ接続 (ミラー認識接続ではなく) を構成することが推奨されます。ミラー認識 Web ゲートウェイ接続は、アプリケーション接続をリダイレクトするための主な手段としてのみ使用する必要があります。
既定では、サーバ・アクセス・エントリはミラー認識ではありません。これは、InterSystems IRIS 管理ポータルをサポートしているゲートウェイ・サーバなど、多くのゲートウェイ・サーバ構成に適していないためです。ミラー認識 Web ゲートウェイ接続の詳細は、"Web ゲートウェイ・ガイド" の "サーバ・アクセスの構成" を参照してください。
外部テクノロジ
ミラーリングと併用して以下のメカニズムを実装し、アプリケーションのリダイレクトに対処できます。
-
ハードウェアによるロード・バランサおよびサイト選択機能
ハードウェアによるサイト選択機能などのメカニズムを使用して、ネットワーク・レベルでアプリケーション・トラフィックをリダイレクトする機能を実装できます。
-
DNS の更新
自動および手動のオプションを使用できます。一部のオプションは、自動フェイルオーバーで使用するには遅すぎる場合があります。
-
アプリケーションのプログラミング
ミラー・メンバの情報を保持して、現在のプライマリに接続するように、個々のアプリケーションを適合させることができます。
-
ユーザ・レベルの手順
複数のミラー・メンバに接続する手段をユーザに提供できます。例えば、災害復旧サイトに接続するための 2 つ目のアイコンなどです。
ミラー仮想 IP (VIP) の計画
"組み込みのメカニズム" で説明したように、ミラー VIP が使用されていてメンバがプライマリになると、VIP は新しいプライマリに再割り当てされます。これにより、どちらのフェイルオーバー・メンバが現行プライマリとして動作しているかに関係なく、すべての外部クライアントおよび接続が単一の静的 IP とやりとりできます。
フェイルオーバー・プロセス中に、接続しているネットワークが切断されたクライアントは、バックアップがプライマリになると再接続できます。VIP が構成されている場合、バックアップは VIP の正常割り当てが可能な場合のみフェイルオーバーを完了します。そうでない場合、フェイルオーバー・プロセスは中止され、ミラーには手動操作が必要になります。
ミラー VIP の設定準備においては、以下について検討します。
-
ミラー VIP を使用するには、両方のフェイルオーバー・メンバが同じサブネットに構成され、VIP が各システムで選択されているネットワーク・インタフェースと同じサブネットに属している必要があります。DR 非同期メンバは、災害復旧の一部としてプライマリに昇格した場合は、VIP を取得できるように同じサブネット上にネットワーク・インタフェースを有している必要があります。それ以外の場合は、災害復旧の手順に代替のリダイレクト・メカニズムを組み込む必要があります。
-
フェイルオーバー・メンバまたは DR 非同期メンバが別々のデータ・センタにある場合、VLAN サブネットをデータ・センタ間に拡張して、同じ VIP アドレスをサポートし続けることができます。これには、2 つのサイト間にレイヤ 2 接続が必要ですが、すべての状況で十分であるとは言えません。"2 つのデータ・センタと地理的に分離された災害復旧に対するミラーリング構成" の説明を参照してください。
-
クライアントの接続に使用するために、DNS サーバ上の VIP に DNS 名を割り当てる必要があります。
-
VIP が使用中であり、フェイルオーバー・メンバが VIP サブネットから削除される場合、そのメンバは DR 非同期に降格させる ("DR 非同期へのバックアップの降格" を参照) かまたはミラーから削除する必要があります。あるいは、VIP 構成を両方のフェイルオーバー・メンバから削除する必要があります。そのようにしないと、フェイルオーバー・メンバがプライマリとして引き継ぎを試行しても、VIP の獲得に失敗し、プライマリになることができません。
Important:
1 つ以上のミラー・メンバが、UNIX® または Linux システム上の非 root InterSystems IRIS インスタンスの場合、"インストール・ガイド" の “UNIX® および Linux への InterSystems IRIS のインストール” の章にある、"InterSystems IRIS 非 root インストール" で説明されているように、ミラー VIP は使用できません。
仮想環境でのミラーリング
ミラーを構成する InterSystems IRIS インスタンスが仮想ホストにインストールされている仮想化環境でミラーリングを使用すると、ミラーリングの利点と仮想化の利点を併せ持つハイブリッド高可用性ソリューションが実現します。ミラーは計画的または計画外の停止に自動フェイルオーバーで即座に対応し、仮想 HA ソフトウェアは計画外のマシン停止や OS 停止後に、ミラー・メンバをホストする仮想マシンを自動的に再起動します。これにより、障害が発生したメンバは、すぐにミラーに再参加できるようになり、バックアップとして動作します (必要であればプライマリを引き継ぎます)。
ミラーを仮想化環境で構成する場合は、次の推奨事項が適用されます。
-
フェイルオーバー・メンバの仮想ホストは、同じ物理ホスト上に配置するようには構成しないでください。
-
単一障害点を回避するには、フェイルオーバー・メンバ上の InterSystems IRIS インスタンスによって使用されるストレージは、個別のディスク・グループまたはストレージ・アレイ上の個別のデータストアに恒久的に分離しておいてください。
-
仮想プラットフォーム・レベルで実行される一部の操作 (バックアップや移行など) により、フェイルオーバー・メンバが長い時間応答しなくなって不要なフェイルオーバーや望ましくない頻度の警告が発生することがあります。この問題に対処するために、サービス品質タイムアウトの設定値を大きくしてください ("サービス品質タイムアウト" を参照)。
-
フェイルオーバー・メンバの接続中断をもたらすような、計画的なメンテナンスを実施する場合は、不要なフェイルオーバーと警告を避けるために、一時的にバックアップでのミラーリングを停止することができます。
-
スナップショット管理は、ミラー・メンバに対しては注意深く使用する必要があります。メンバを以前のスナップショットに戻すと、メンバの最新のステータス (例えば、スナップショットが取られて以降にプライマリからバックアップに変更が加えられている場合など) と、他のメンバにより継続して処理されているジャーナル・データの両方が消去されてしまうことになります。特に次の事柄には注意してください。
-
以前のスナップショットに戻されているフェイルオーバー・メンバは、必ず電源オフの状態から再開してください。電源オンの状態から再開すると、両方のフェイルオーバー・メンバが同時にプライマリとして動作する可能性が生じます。
-
以前のスナップショットに戻されたフェイルオーバー・メンバが、スナップショット以降に作成されたすべてのジャーナル・データを取得せずにプライマリになる場合 (例えば、強制的にプライマリにされる)、他のすべてのミラー・メンバを再構築する必要があります ("ミラー・メンバの再構築" で説明しています)。
クラウド環境でのミラーリング
InterSystems IRIS をパブリック・クラウド・プラットフォームに導入する場合は、ミラーリングによって高可用性と災害復旧性を備えた堅牢なソリューションを実現できます。使用しているアプリケーションの要件によって導入の詳細は異なりますが、一般的な考慮事項を以下に示します。
-
同じリージョンにある 2 つの可用性ゾーンにフェイルオーバー・メンバを分割配置することをお勧めします。この構成により、遅延と復元可能性の適切な組み合わせが得られます。
-
アプリケーションで更新のワークロードがきわめて大きい場合や同期コミット・トランザクションを使用している場合は、近接して配置したグループを導入することで、復元可能性はやや低下するものの、遅延をさらに低減できる余地が生まれます。このような配置のグループでは、単一の可用性ゾーンに仮想マシン・インスタンスを互いに物理的に近い位置に置き、遅延を最小限に抑えることができます。この構成は、復元可能性が低くなるので、アプリケーションできわめて少ない遅延を必要とする場合にのみ検討します。
-
最大限の復元可能性を得るには、フェイルオーバー・メンバとは別のリージョンに DR 非同期メンバを配置する必要があります。
-
通常、VIP はクラウド環境では使用できません。ただし、代替手段があります。物理的または仮想のロード・バランサなどのネットワーク・トラフィック管理アプライアンスを使用して、VIP と同程度の透過性を実現できます。これにより、クライアント・アプリケーションやデバイスに単一のアドレスを提示できます。プラットフォームによっては、専用の構成を使用して VIP を確立できることもあります。クラウド環境でフェイルオーバー後のアプリケーションのリダイレクトを構成するためのオプションの詳細は、InterSystems Developer Community で "Database Mirroring without a Virtual IP AddressOpens in a new tab" および "VIP in AWSOpens in a new tab" を参照してください。
-
通常、アービターの配置場所は、Web サーバと同じネットワーク層、またはクラウドベースの InterSystems IRIS 導入への入口となる場所とする必要があります。Web サーバもアプリケーション・サーバもない場合は、ミラー・メンバ自体と同じ層またはセキュリティ・グループにアービターを配置できます。
-
2 つの可用性ゾーンがある導入では、どちらのゾーンにアービターを配置してもかまいません。その他の目的で 3 番目のゾーンを既に導入している場合は、そのゾーンにもアービターを配置すると役立つ可能性があります。アービター専用に新たに 3 番目のゾーンを導入しても、通常はコストと管理のオーバーヘッドが増加するので、利点が相殺されます。詳細は、"ミラーの可用性を最適化するためのアービターの配置" を参照してください。
-
クラウドでミラーリングを実装する場合は暗号化を強くお勧めします。プライマリ・メンバだけでなく、すべてのミラー・メンバで暗号化を使用することが最良です。データベースの暗号化により、ストレージ・ボリューム上のデータは保護されますが、ミラー・メンバ間で転送するデータは保護されません。転送するデータを保護するには、ジャーナルの暗号化も構成する必要があります。パブリック・クラウド・プラットフォームもデータベース暗号化を提供しますが、ストレージ・ボリュームを構成するときに暗号化の指定が必要になることがあります。暗号化の一般的な情報は、"暗号化ガイド" を参照してください。
バックアップ・フェイルオーバー・メンバへのアクセスの制限
ミラーのバックアップ・フェイルオーバー・メンバをホストするシステムに未使用のリソースまたは容量がある場合、またはそのミラーリングされたデータベースに読み取り専用のクエリを実行する場合、そのホストをバックアップ・ミラー・メンバとしての役割に専念させることを最善の方法としてお勧めします。バックアップをミラー関連としてまたはミラー以外に使用すると、以下の影響が生じる可能性があります。
-
バックアップのパフォーマンス低下によって、プライマリからのジャーナル・データの受信確認が遅くなると、プライマリ上のミラーリングされたデータベースにアクセスするアプリケーションのユーザに対してパフォーマンスの低下が生じる場合があります。プライマリによる確認を待機する必要があるアプリケーション対話は、明示的なジャーナル同期化、同期コミット・トランザクション、ECP アクティビティなどが関連するものを含め、すべてこのように影響を受ける可能性があります。
-
バックアップからの確認が遅くて、サービス品質タイムアウトの時間内に行われない場合、プライマリはバックアップのアクティブ・ステータスを取り消すので、プライマリ停止のタイプによっては、自動フェイルオーバーがより困難になるか不可能になります。
-
自動フェイルオーバーが発生したときに、バックアップが自身の既存のリソース使用とプライマリのユーザ・アプリケーションのリソース使用の両方をサポートします。これが起こりうる場合、バックアップのホストには、これらの負荷を両方とも処理できる容量が必要です。
これらの理由により、ユーザの操作をプライマリからオフロードする必要がある場合、バックアップではなく、非同期メンバを使用する必要があります。
単一ホストへの複数のミラー・メンバのインストール
ミラーを構成する InterSystems IRIS インスタンスは通常、別個の物理ホストまたは仮想ホストにインストールされますが、それは要件ではありません。パフォーマンスを低下させることなく、関係するリソース負荷を処理するのに十分な容量がシステムにあるとすれば、複数のミラー・メンバ (複数のミラー全体を含め) を同一ホストにインストールできます。個々の状況で、これが実現可能かどうか、またいくつのミラーまたはミラー・メンバをコホストできるのかを判断します。
複数のフェイルオーバー・メンバをコホストする場合、フェイルオーバー・ミラーリングでは、メンバは同等と見なされることに留意してください。優先されるプライマリ・メンバはありません。このため、フェイルオーバー・メンバのインスタンスを個別のホストに配置する際の最善の方法は、容量においてそれらのホストを可能な限り同じ、つまりほぼ同等にすることです。フェイルオーバー・メンバのコホストでは、対象モデルの境界の外に出る可能性があります。例えば、5 つのミラーを 5 つの個別ホストに作成して、1 つのホスト上の 5 つの InterSystems IRIS インスタンスを第 2 のフェイルオーバー・メンバとしてミラーに追加した場合、ミラーは最初、個別ホスト上の各プライマリと単独システムでコホストされているすべてのバックアップとを使用して動作します。ところが、フェイルオーバーに至る 2 つの同時、またはほとんどの同時の停止があると、単独システムで 2 つのプライマリと 3 つのバックアップをホストすることになり、適切なパフォーマンスを確保しながら処理するには、システムにとって負荷が大きくなりすぎる可能性があります。
1 つ以上のミラーに属する複数の InterSystems IRIS インスタンスがコホストされている場合、それらのインスタンスは 1 つの ISCAgent を共有します。
複数のミラー・メンバをコホストする場合は、次のネットワーキングに関する考慮事項に留意してください。
-
各ミラーが各マシンで一意のポート・セットを使用し ("ミラー・メンバのネットワーク・アドレス" を参照)、コホストされていない他のミラー・メンバ (存在する場合) が同じポートを使用するよう設定する必要があります。例えば、2 つの個別ホスト上で実行されている 2 つのプライマリが両方ともポート 1972 を使用しているが、コホストされている DR 非同期メンバに両方が置き換えられる可能性がある場合、前述の説明で示したように、新しいプライマリ (以前の DR 非同期) ではポート割り当てが競合します。1 つのプライマリがポート 1972 を使用し、もう 1 つのプライマリが 1973 を使用し、これらと同じポートが非同期で構成されていると、非同期は同時昇格の準備ができているので、発生時にクライアントは停止前と同じポートを使用してミラーにアクセスできます。
-
各ミラーのフェイルオーバーおよび DR 非同期メンバは (他のミラーまたはそのメンバと、全部がコホストされているか、一部がコホストされているかにかかわらず)、独自のサブネットを持つ必要があり、各ミラーは独自の VIP (VIP が使用されている場合) を持つ必要があります。これは、使用している環境によっては多少複雑であり、ミラー・メンバをコホストするノードに、複数のサブネットをサポートする複数の NIC が必要になります。ミラー・ネットワーク構成および VIP に関する重要な情報について、この章の "ミラーリング通信"、"ミラーリング・アーキテクチャとネットワーク構成のサンプル"、"ミラー仮想 IP (VIP) の計画" および “ミラーリングの構成” の "ミラー仮想 IP (VIP) の構成" を参照してください。
-
ミラー・メンバのコホストは、各ミラーに対応するアービターのネットワークの位置に影響を与えません ("ミラーの可用性を最適化するためのアービターの配置" を参照)。関与するミラーは、アービターを共有することも、個別のアービターを使用することもできます。ただし、フェイルオーバー・メンバとアービターが適切に配置されている必要があります。
