| Oracle® Fusion Middleware Oracle WebLogic Serverのための継続的可用性 12c (12.2.1.3.0) E90354-01 |
|
 前 |
 次 |
アクティブ/アクティブ・アプリケーション層トポロジでは、地理的に分散した場所にある2つ以上のアクティブなサーバー・インスタンスが同時にリクエストを処理するようにデプロイされているため、スケーラビリティが向上し、可用性が高まります。アクティブ/アクティブ・ソリューションを設計する場合には、Oracleのベスト・プラクティスを考慮してください。
「継続的可用性の一般設計に関する考慮事項」に説明されているようにすべての継続的可用性MAAアーキテクチャに対してお薦めする一般的なベスト・プラクティスに加えて、次の項では、「アクティブ/パッシブ・データベース層を使用するアクティブ/アクティブ・アプリケーション層」に示されたMAAアーキテクチャに適用される設計に関する考慮事項および障害シナリオについて説明します。
アクティブ/パッシブ・データベース層とともに動作するアクティブ/アクティブ・アプリケーション層トポロジでの継続的可用性のためには、Oracleのベスト・プラクティスの設計に関する推奨事項を考慮してください。
アクティブ/アクティブ・トポロジで継続的可用性の機能を最大限に利用するには、次を考慮してください。
アクティブ/アクティブ・ドメインは対称的トポロジで構成する必要があります。これらは類似しており、同じドメイン構成(ドメインおよびサーバーの名前、ポート番号、ユーザー・アカウント、ロード・バランサおよび仮想サーバー名など)と同じソフトウェア・バージョンを使用する必要があります。ホスト名(静的IPではない)は、管理対象サーバーのリスニング・アドレスの指定に使用する必要があります。このトポロジでクロスサイト・トランザクション・リカバリを構成すると、構成可能なMBeanプロパティ、SiteName、RecoverySiteNameはサイト固有です。サイトを同期状態に維持するために現在使用している既存のレプリケーション・テクノロジまたは方法はすべて使用できます。
注意:
クロスサイトXAトランザクション・リカバリを利用する際、いくつかの構成パラメータ(表3-1を参照)が、サイトに固有の「サイト名」および「リカバリ・サイト名」とともに存在します。構成をレプリケートするときにこれらのパラメータおよび名前を上書きしないでください。
このトポロジ・ネットワークの遅延は、通常大です(WANネットワーク)。アプリケーションでサイト間のセッションのレプリケーションが必要な場合、データベース・セッション・レプリケーションまたはCoherence*Webのいずれかを選択する必要があります。セッション・レプリケーションを参照してください。
サーバーおよびサービスの移行は、アクティブ/アクティブ・トポロジのイントラサイト(サイト内)でのみ適用されます。サーバーおよびサービスの移行を参照してください。
JMSはこのトポロジのイントラサイトでのみサポートされています。フェイルオーバーまたは計画済メンテナンス中のJMSリカバリはサイト間ではサポートされていません。
ゼロ・ダウンタイム・パッチ適用は、アクティブ/アクティブ・トポロジのイントラサイト(サイト内)でのみ適用されます。各サイトのWebLogicホーム、Javaおよびアプリケーションは別々にアップグレードできます。アップグレード・バージョンを同期状態に維持し、両方のサイトのドメインを対称に維持してください。
異なるContinuous Availability機能を組み合せることにより、障害時のデータ損失を最小限にするようにアプリケーションを設計できます。たとえば、クロスサイトXAトランザクション・リカバリ、Coherenceフェデレーテッド・キャッシュ、Coherence HotCacheまたはCoherence Read-Throughキャッシュを組み合せて使用できます。
Coherenceデータがデータベースにバックアップされており、ネットワーク・パーティション障害が発生した場合、フェデレーテッド・キャッシュはレプリケーションを実行できず、Coherenceクラスタが独自に作業を継続できるため、両方のサイトのデータの整合性が失われます。サイト間の通信が再開すると、バックアップされたデータがデータベースからCoherenceにCoherence HotCacheまたはCoherence Read-Throughキャッシュ経由で送られ、最終的にはCoherenceキャッシュのデータが同期されます。「Coherence」を参照してください。
アクティブ/アクティブ・トポロジでは、Oracle Site Guardはデータベースのスイッチオーバーまたはフェイルオーバーのみを実行できます。アクティブ/パッシブ・データベース層を使用するアクティブ/アクティブ・アプリケーション層の障害シナリオを参照してください。
図4-1および図4-2は、クロスサイト・トランザクション・リカバリのデフォルト・パラメータ設定を使用したベンチマーク・テスト中に見つかった結果を表しています。この図は、中間層が失敗したときのサイト間でのトランザクションのリカバリで生じた遅延を示しています。図4-1は、サイト間の遅延が1秒の場合に平均リカバリ時間が170から180ミリ秒の範囲であったことを表しています。図4-2は、サイト間の遅延が77ミリ秒の場合に平均トランザクション・リカバリ時間が90から100ミリ秒の範囲であったことを表しています。
遅延が増加するに伴って、クロスサイト・トランザクション・リカバリ・パラメータのCrossSiteRecoveryLeaseExpiration、CrossSiteRecoveryRetryIntervalおよびCrossSiteRecoveryLeaseUpdateを増やして遅延にあわせる必要があります。クロスサイト・トランザクション・リカバリのリース表が維持されているデータベースがサイトの1つに対してリモートである場合、これらの値のチューニングが特に重要です。「クロスサイトXAトランザクション・リカバリ」を参照してください。
アクティブ/アクティブ・アプリケーション層トポロジに対する異なる潜在的な障害シナリオのそれぞれで継続的可用性の機能がどのように使用されているかについて学習します。
表4-1では、様々な障害シナリオを説明し、継続可用性機能がどのように適用されるかを説明します。様々な障害シナリオの説明については、「潜在的な障害シナリオ」を参照してください。
表4-1 アクティブ/アクティブ・アプリケーション層およびアクティブ/パッシブ・データベース層の障害シナリオ
| 継続的可用性の機能 | 完全サイト障害 | 部分サイト/中間層障害(WebLogic Server/Coherence/OTD) | メンテナンス機能停止 | ネットワークの分断障害 |
|---|---|---|---|---|
サイト間のトランザクション・リカバリ |
|
プライマリ・サイトのリース表が期限切れになった場合、サイト2のサーバーが自動的にTLog表の所有権をとり、トランザクション・リカバリを開始します。 |
|
|
Oracle Traffic Director |
サイト2のOracle Traffic Directorは、そのサイトで稼働しているサーバーへのトラフィックのルーティングを続行します。 |
サイト2のOracle Traffic Directorは、そのサイトで稼働しているサーバーへのトラフィックのルーティングを続行します。 |
|
サイト1のOracle Traffic Directorおよびサイト2のOracle Traffic Directorは、そのサイトで稼働しているサーバーへのトラフィックのルーティングを続行します。 |
Oracle Site Guard |
Oracle Site GuardがOracle Data Guardブローカと統合されてデータベースのフェイルオーバー/スイッチオーバーを実行します。Site GuardがOracle Data Guardブローカを呼び出してフェイルオーバーを実行し、Site Guardがデータベース内のロールをプライマリからセカンダリに切り替えます。 |
何もしません。 |
|
何もしません。 |
Coherenceフェデレーテッド・キャッシュ |
サイト2のCoherenceクラスタがアクティブになります。 |
レプリケーションは非同期のため、キャッシュ・データは最終的にCoherence Hot CacheまたはRead-Through Cacheのいずれかを介して、あるいはもう一方のサイトが稼働状態に戻ったときに整合します。 |
レプリケーションは非同期のため、キャッシュ・データは最終的にCoherence Hot CacheまたはRead-Through Cacheのいずれかを介して、あるいはもう一方のサイトが稼働状態に戻ったときに整合します。 |
レプリケーションは非同期のため、キャッシュ・データは最終的にCoherence Hot CacheまたはRead-Through Cacheのいずれかを介して、あるいはネットワーク接続が2つのサイト間で再確立されたときに整合します。 |
