5 アクティブ/パッシブ・アプリケーション層トポロジの設計に関する考慮事項

アクティブ/パッシブ・アプリケーション層トポロジでは、アクティブ・サイトは地理的に異なる場所にありスタンバイになっているパッシブ・サイトとペアになります。アクティブ/パッシブ・ソリューションの設計する場合には、Oracleのベスト・プラクティスを考慮してください。

「継続的可用性の一般設計に関する考慮事項」に説明されているようにすべての継続的可用性MAAアーキテクチャに対してお薦めする一般的なベスト・プラクティスに加えて、次の項では、「アクティブ/パッシブ・データベース層を使用するアクティブ/パッシブ・アプリケーション層」に示されたMAAアーキテクチャに適用される設計に関する考慮事項および障害シナリオについて説明します。

アクティブ/パッシブ・データベース層を使用するアクティブ/パッシブ・アプリケーション層の設計に関する考慮事項

アクティブ/パッシブ・データベース層とともに動作するアクティブ/パッシブ・アプリケーション層トポロジでの継続的可用性のためには、Oracleのベスト・プラクティスの設計に関する推奨事項を考慮してください。

アクティブ/パッシブ・トポロジで継続的可用性の機能を最大限に利用するには、次を考慮してください。

すべてのアクティブ/パッシブ・ドメインのペアは対称的トポロジで構成する必要があります。これらは同等であり、同じドメイン構成(ディレクトリの名前およびパス、ポート番号、ユーザー・アカウント、ロード・バランサおよび仮想サーバー名など)とソフトウェア・バージョンを使用する必要があります。ホスト名(静的IPではない)は、管理対象サーバーのリスニング・アドレスの指定に使用する必要があります。サイト間でホスト名が同じ場合(IPは同一ではない)、そのホスト名により、同じように構成されたサーバーまたはドメインをリカバリ・サイトで開始する動的な機能が提供されます。
このトポロジで遅延に関する考慮事項はありません。唯一の要件は、JMSおよびJTA TLogなどのストアがデータベースに維持されることです。
パッシブ・モードでWebLogic Serverのサーバーは構成されますが、稼働していません。障害がある場合、パッシブ・サイトのWebLogic Serverのサーバーが起動され、JTAおよびJMSのトランザクション/メッセージがリカバリされます。作業はその後2番目のサイトで実行されます。
JMSはこのトポロジでサポートされています。パッシブ・サイトには、JMSサーバー、ストアおよび宛先の構成が同一になるようにプライマリ・サイトのドメインの完全なコピーが含まれている必要があります。

フェイルオーバーまたはスイッチオーバーの場合、ストアまたはJMSサーバー(あるいはその両方)がクラスタをターゲットとしている場合は同数のサーバーをクラスタで起動する必要があります。このプロセスは、JMSサーバー+ストア+宛先のそれぞれが、実行していたサーバーに固有のものであるためです。MyServer1とMyServer2がプライマリ・ドメインにある場合、これらの各サーバーにJMS Server + ストアがあります。これらのサーバーのキューにメッセージが含まれている可能性があります。1つのサーバーのみを再起動すると、リカバリされるのはその1つのサーバーに対するメッセージのみです。

スタンバイ・ドメインは、レプリケーション・フェーズ中は実行できず、最初のデータ・センターの停止が確認された後にのみ起動できます。このプロセスは、データの破損を防いでリカバリを強制するために必要です。2つのJMSサーバー/ストアがまったく同じデータを書込み/更新している場合、予期できない結果が発生します。また、メッセージ・リカバリはJMSの起動時にのみ発生します。その際、JMSサーバーはストアの完全な内容を読み取って宛先状態を再作成します。

非同期レプリケーションは喪失メッセージ(メッセージがプライマリ・データ・センターに書き込まれたがコピーされていない)または重複メッセージ(メッセージがプライマリ・データ・センターで消費/削除されたがレプリケートされたデータ・センターに残っている)になる可能性があります。

ディザスタ・リカバリ・ガイドのOracle WebLogic Server Java Message Service (JMS)およびトランザクション・ログ(TLog)の推奨事項を参照してください。
ゼロ・ダウンタイム・パッチ適用は、お使いのWebLogicホーム、Javaおよびアプリケーションをアクティブなサイトでローリング方式でアップグレードします。計画済メンテナンスおよびパッシブ・サイトへのスイッチオーバー中、およびサーバーの起動後に、ゼロ・ダウンタイム・パッチ適用を使用してWebLogic、Javaまたはアプリケーションをアップグレードします。両方のサイトのドメインを対称に維持するには、両方のサイトでアップグレード・バージョンを同期状態に維持してください。
アクティブ/パッシブ・トポロジでは、Coherenceはスタンバイ・モードにあり、WebLogic Serverのようなパッシブ・モードではありません。スタンバイ・サイトにはアクティブなサイトからのキャッシュ・データのバックアップがあります。Coherenceフェデレーテッド・キャッシュをアクティブ/パッシブ・モードで使用すると、このレプリケーションは非同期ですが絶えず発生します。
このトポロジでは、Oracle Site Guardを使用してすべてのサイト・コンポーネント(Oracle Traffic Director、WebTier、WebLogic Server、Coherenceおよびデータベース)のフェイルオーバー/スイッチオーバーを編成することをお薦めします。

アクティブ/パッシブ・データベース層を使用するアクティブ/パッシブ・アプリケーション層の障害シナリオ

アクティブ/パッシブ・アプリケーション層トポロジに対する異なる障害シナリオのそれぞれで継続的可用性の機能がどのように使用されているかについて学習します。

表5-1では、様々な障害シナリオを説明し、継続可用性機能がどのように適用されるかを説明します。様々な障害シナリオの説明については、「潜在的な障害シナリオ」を参照してください。

表5-1 アクティブ/パッシブ・アプリケーション層およびアクティブ/パッシブ・データベース層の障害シナリオ

継続的可用性の機能	完全サイト障害	部分サイト/中間層障害(WebLogic Server/Coherence/OTD)	メンテナンス機能停止	ネットワークの分断障害
サイト間のトランザクション・リカバリ	Oracle Site GuardがOracle Data Guardブローカと統合されてデータベースのフェイルオーバー/スイッチオーバーを実行します。Site GuardがOracle Data Guardブローカを呼び出してフェイルオーバーを実行し、Site Guardがロールをプライマリからセカンダリに切り替えます。 JDBC TLogが、Oracle Data GuardまたはOracle Active Data Guardなどのレプリケーション・テクノロジを使用してサイト2のデータベースにレプリケートされます。トランザクションはサーバーが再起動されたときにリカバリされます。	Oracle Site GuardがOracle Data Guardと統合されてデータベースおよびアプリケーション・インフラストラクチャのスイッチオーバーを編成します。トランザクションはサーバーが起動するときにリカバリされます。	Oracle Site Guardは、Oracle Data Guardとともにデータベースおよびアプリケーション・インフラストラクチャのスイッチオーバーを編成します。 JDBC TLogが、Oracle Data GuardまたはOracle Active Data Guardなどのレプリケーション・テクノロジを使用してサイト2のデータベースにレプリケートされます。トランザクションはサーバーが起動されたときにリカバリされます。	何もしません。
Oracle Traffic Director	スタンバイ・サイトのOracle Traffic Directorインスタンスが、(Oracle Site Guardによって、何がどのような順序で発生するかを指定するスクリプトを使用して)アクティブ化されます。(スクリプトはフェイルオーバーの前または後に実行できます。)	スタンバイ・サイトのOracle Traffic Directorインスタンスが、(Oracle Site Guardによって、何がどのような順序で発生するかを指定するスクリプトを使用して)アクティブ化されます。(スクリプトはフェイルオーバーの前または後に実行できます。) Oracle Traffic Directorが、サイト2のサーバーへのトラフィックのルーティングを開始します。	スタンバイ・サイトのOracle Traffic Directorインスタンスが、(Oracle Site Guardによって、何がどのような順序で発生するかを指定するスクリプトを使用して)アクティブ化されます。(スクリプトはフェイルオーバーの前または後に実行できます。)	何もしません。
Oracle Site Guard	Oracle Site GuardがOracle Data Guardブローカと統合されてデータベースのフェイルオーバー/スイッチオーバーを実行します。Site GuardがOracle Data Guardブローカを呼び出してフェイルオーバーを実行し、Site Guardがロールをプライマリからセカンダリに切り替えます。	Oracle Site Guardは中間層でのみフェイルオーバーします。	顧客はOracle Site Guardを使用してサイト1の停止を開始します。 Oracle Site GuardがOracle Data Guardブローカと統合されてデータベースのフェイルオーバーを実行します。Site GuardがOracle Data Guardブローカを呼び出してフェイルオーバーを実行し、Site Guardがデータベース内のロールをプライマリからセカンダリに切り替えます。	何もしません。
Coherenceフェデレーテッド・キャッシュ	サイト2のCoherenceクラスタがアクティブになります。キャッシュ・データは最終的にCoherence Hot CacheまたはRead-Through Cacheのいずれかを介して整合します。	サイト2のCoherenceクラスタがアクティブになります。キャッシュ・データは最終的にCoherence Hot CacheまたはRead-Through Cacheのいずれかを介して、あるいはリモート・サイトが稼働状態に戻ったときに整合します。	サイト2のCoherenceクラスタがアクティブになります。キャッシュ・データは最終的にCoherence Hot CacheまたはRead-Through Cacheのいずれかを介して、あるいはリモート・サイトが稼働状態に戻ったときに整合します。	キャッシュ・データは最終的にCoherence Hot CacheまたはRead-Through Cacheのいずれかを介して、あるいはネットワーク接続が2つのサイト間で再確立されたときに整合します。