4 アクティブ/アクティブ・データベース層を使用するアクティブ/アクティブ・アプリケーション層

アクティブ/アクティブ・アプリケーション層トポロジでは、地理的に分散した場所にある2つ以上のアクティブなサーバー・インスタンスが同時にリクエストを処理するようにデプロイされているため、スケーラビリティが向上し、可用性が高まります。

内容は次のとおりです:

アクティブ/アクティブ・ペア・トポロジのアーキテクチャの説明

サポートされているこのMAAアーキテクチャは、WebLogicドメイン・ペアを持つアクティブ/アクティブ・アプリケーション・インフラストラクチャ層と、Oracle RACクラスタ・ペアを持つアクティブ/パッシブ・データベース層で構成され、両方の層が2つのサイトにまたがっています。 アプリケーション・インフラストラクチャ層では、各サイト上にアクティブおよびパッシブの同一WebLogicドメインからなるドメイン・ペアが含まれ、データベース層では、各サイト上にアクティブおよびパッシブの同一データベース・クラスタからなるデータベース・クラスタ・ペアが含まれています。

図4-1は、アクティブ/アクティブ・アプリケーション・ペア・インフラストラクチャ層をアクティブ/アクティブ・データベース層とともに使用した、推奨されるソリューションを示しています。

図4-1 アクティブ/アクティブ・アプリケーション・ペア層とアクティブ/アクティブ・データベース・ペア層からなるアーキテクチャ図

図4-1の説明が続きます
「図4-1 アクティブ/アクティブ・アプリケーション・ペア層とアクティブ/アクティブ・データベース・ペア層からなるアーキテクチャ図」の説明

このサンプル・トポロジの主な特徴は次のとおりです。

  • グローバル・ロード・バランサ。

  • 各サイトにあるOracle HTTP Server (OHS)の2つのアクティブ・インスタンス。OHSは、WebLogic Serverクラスタに対するリクエストを均衡化できます。

  • 2つの異なるデータ・センター(サイト1およびサイト2)に構成された2つの同一ドメイン・ペア。ドメインAとドメインBは独立したドメインであり、対称トポロジで構成する必要はありませんが、各サイトのドメイン・ペアは対称である必要があります。各サイトには、1つのアクティブ・ドメインと1つのパッシブ・ドメインからなるドメイン・ペアが含まれます。「アクティブ/アクティブ・ペア・トポロジの設計に関する考慮事項」を参照してください。ドメインには次のものが含まれます:

    • ドメイン内のWebLogic Server管理サーバーによって管理されている、WebLogic Serverクラスタ内の管理対象サーバー(MS1、MS2およびMS3)の集合。この例では、同じサイトに配置されたプライマリ・データベースに管理対象サーバーを接続するためにActive Gridlink (AGL)が使用されています。(汎用データ・ソースやマルチ・データ・ソースを使用できますが、高可用性とパフォーマンス向上を実現できるため、Active Gridlinkをお薦めします。)

      ゼロ・ダウンタイム・パッチ適用(ZDT)の矢印は、ローリング方式で管理対象サーバーにパッチが適用されることを表しています。両方のドメインがアクティブであるため、各サイトで別々に更新のロールアウトを編成できます。WebLogic Serverゼロ・ダウンタイム・パッチ適用を参照してください。

    • ドメイン内のWebLogic Server管理サーバーによって管理されている、Coherenceクラスタ(COH1、COH2およびCOH3)。Coherence永続キャッシュは、クラスタで障害が発生した場合に、キャッシュ済データのリカバリに使用されます。「Coherence永続性およびクラスタ」を参照してください。

      Read-ThroughキャッシングまたはCoherence GoldenGate Hot Cacheが、データベースからのキャッシュの更新に使用されます。Coherence Hot Cacheは、アクティブ・データベースに行われる更新に対してCoherenceキャッシュをリアルタイムで更新します。「Coherence GoldenGate Hot Cache」を参照してください

      Coherenceフェデレーテッド・キャッシュは、アクティブ・クラスタ間でデータをレプリケートします。このアクティブ/アクティブ・アーキテクチャでは、「Coherenceフェデレーテッド・キャッシュ」で説明されているように、この機能の全要素を使用できます。一方のアクティブ・クラスタに置かれるデータは、もう一方のアクティブ・クラスタでレプリケートされます。異なるサイトのアプリケーションはローカル・クラスタ・インスタンスへのアクセスを保有します。

  • 構成データ、ローカル・バイナリ、ログなどのファイル・ストレージ。

  • 2つの異なるデータ・センター(サイト1およびサイト2)内にある2つの別個のOracle RACデータベース・クラスタ・ペア。両方のサイトに、プライマリのアクティブOracle RACデータベース・クラスタとスタンバイの(パッシブ)Oracle RACデータベース・クラスタが含まれています。サイト1では、クラスタAがアクティブなプライマリ・クラスタであり、クラスタBはスタンバイ・モードになっています。サイト2では、クラスタBがプライマリのアクティブOracle RACクラスタであり、クラスタAはスタンバイ・モードになっています。クラスタにはトランザクション・ログ、JMSストアおよびアプリケーション・データが含まれる場合があります。データはOracle Active Data Guardを使用してレプリケートされます。(最高レベルの高可用性が提供されることからOracle RACデータベース・クラスタの使用が推奨されていますが、これは必須ではありません。単一データベースまたはマルチテナント・データベースも使用できます。)

アクティブ/アクティブ・ペア・トポロジの設計に関する考慮事項

アクティブ/パッシブ・データベース・ペア層を含むアクティブ/アクティブ・アプリケーション・ペア層トポロジにおける、設計に関するOracleのベスト・プラクティスの推奨事項を考慮してください。

ここで説明する設計上の考慮事項に加えて、サポートされるすべてのWebLogic ServerおよびCoherence MAAアーキテクチャについて推奨されるベスト・プラクティスにも従う必要があります。「高可用性およびディザスタ・リカバリのための設計に関する一般的な考慮事項」を参照してください。

アクティブ/アクティブ・トポロジで高可用性機能を最大限に利用するには、次のことを考慮してください:

  • ドメインAとドメインBは独立したドメインであり、対称トポロジで構成する必要はありませんが、各サイトのドメイン・ペアは対称である必要があります。つまり、ドメイン・ペアでは、同じドメイン構成(ドメインおよびサーバーの名前、リソース名、ポート番号、ユーザー・アカウント、ロード・バランサ、仮想サーバー名など)および同じソフトウェア・バージョンを使用する必要があります。ホスト名(静的IPではない)は、管理対象サーバーのリスニング・アドレスの指定に使用する必要があります。ペアの同期状態を維持するために現在使用している既存のレプリケーション・テクノロジまたは方法はすべて使用できます。

  • このトポロジ・ネットワークの遅延は、通常大です(WANネットワーク)。アプリケーションでサイト間のセッションのレプリケーションが必要な場合、データベース・セッション・レプリケーションまたはCoherence*Webのいずれかを選択する必要があります。「セッション・レプリケーション」を参照してください。

  • サーバーおよびサービスの移行は、アクティブ/アクティブ・トポロジのクラスタ・イントラサイト(サイト内)の管理対象サーバーにのみ適用されます。サーバーおよびサービスの移行を参照してください。

  • JMSはこのトポロジのイントラサイトでのみサポートされています。フェイルオーバーまたは計画済メンテナンス中のJMSリカバリはサイト間ではサポートされていません。

  • ゼロ・ダウンタイム・パッチ適用は、アクティブ/アクティブ・トポロジのイントラサイト(サイト内)でのみ適用されます。各サイトのWebLogicホーム、Javaおよびアプリケーションは別々にアップグレードできます。アップグレード・バージョンを同期状態に維持し、両方のサイトのドメインを対称に維持してください。

  • 異なる高可用性機能を組み合せることにより、障害時のデータ損失を最小限にするようにアプリケーションを設計できます。たとえば、Coherenceフェデレーテッド・キャッシュ、Coherence HotCacheまたはCoherence Read-Throughキャッシュを組み合せて使用できます。

    Coherenceデータがデータベースにバックアップされており、ネットワーク・パーティション障害が発生した場合、フェデレーテッド・キャッシュはレプリケーションを実行できず、Coherenceクラスタが独自に作業を継続できるため、両方のサイトのデータの整合性が失われます。サイト間の通信が再開すると、バックアップされたデータがデータベースからCoherenceにCoherence HotCacheまたはCoherence Read-Throughキャッシュ経由で送られ、最終的にはCoherenceキャッシュのデータが同期されます。「Coherence」を参照してください。