1. Oracle WebLogic ServerおよびCoherenceのための高可用性とディザスタ・リカバリ・ガイド
  2. アクティブ/パッシブ・データベース層を使用するアクティブ/パッシブ・アプリケーション層

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

アクティブ/パッシブ・アプリケーション層トポロジでは、アクティブ・サイトは地理的に異なる場所にありスタンバイになっているパッシブ・サイトとペアになります。

内容は次のとおりです:

  • アクティブ/パッシブ・トポロジのアーキテクチャの説明
    このMAAアーキテクチャは、アクティブ/パッシブ・アプリケーション・インフラストラクチャ層とアクティブ/パッシブ・データベース層で構成され、両方の層が地理的に異なる2つのサイトにまたがっています。1つ目のサイトでは、アプリケーション・インフラストラクチャ層とデータベース層の両方がアクティブです。2つ目のサイトでは、セカンダリ・ドメインが停止され、セカンダリ・データベースがスタンバイ状態にあります。
  • アクティブ/パッシブ・トポロジの設計に関する考慮事項
    アクティブ/パッシブ・データベース層とともに動作するアクティブ/パッシブ・アプリケーション層トポロジでの継続的可用性のためには、Oracleのベスト・プラクティスの設計に関する推奨事項を考慮してください。

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

このMAAアーキテクチャは、アクティブ/パッシブ・アプリケーション・インフラストラクチャ層とアクティブ/パッシブ・データベース層で構成され、両方の層が地理的に異なる2つのサイトにまたがっています。1つ目のサイトでは、アプリケーション・インフラストラクチャ層とデータベース層の両方がアクティブです。2つ目のサイトでは、セカンダリ・ドメインが停止され、セカンダリ・データベースがスタンバイ状態にあります。

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

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

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

このトポロジの主な特徴は次のとおりです。

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

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

  • 2つの異なるデータ・センター(サイト1およびサイト2)で構成された2つの異なるWebLogic Serverドメイン。サイト1のドメインがアクティブであり、サイト2のセカンダリ・ドメインは停止しています。各アクティブ/パッシブ・ドメインの構成は同じである必要があります。「アクティブ/パッシブ・トポロジの設計に関する考慮事項」を参照してください。

    ドメインには次のものが含まれます:

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

      ゼロ・ダウンタイム・パッチ適用(ZDT)によって、ローリング方式による管理対象サーバーのパッチ適用の提示が可能です。このアーキテクチャでは、「WebLogic Serverゼロ・ダウンタイム・パッチ適用」で説明されているように、サイト1のアクティブ・ドメインでゼロ・ダウンタイム・パッチ適用機能を使用できます。サイト2のセカンダリ・ドメインではサーバーが実行されていないため、OPatchを使用してOracleホームにパッチを適用できます。サーバーがアクティブになると、パッチを適用したOracleホームが示されます。詳細は、Opatchによるパッチ適用のOPatchを使用した環境へのパッチ適用を参照してください

    • ドメイン内のWebLogic Server管理サーバーによって管理されている、Coherenceクラスタ(COH1、COH2およびCOH3)。Coherence永続キャッシュは、クラスタで障害が発生した場合に、キャッシュ済データのリカバリに使用されます。Read-ThroughキャッシングまたはCoherence GoldenGate Hot Cacheが、データベースからのキャッシュの更新に使用されます。

      このアーキテクチャではCoherence Hot Cacheを使用することにより、サイト1のアクティブ・データベースが更新されるとCoherenceキャッシュがリアルタイムで更新され、データベース更新がサイト2にレプリケートされます。データ・レプリケーションがサイト2で発生すると、HotCacheはリアルタイムでキャッシュを更新します。Coherence GoldenGate HotCacheを参照してください。

      Coherenceフェデレーテッド・キャッシュは、アクティブ・クラスタからパッシブ・クラスタにデータをレプリケートします。パッシブ・サイトは読取り専用操作とオフサイト・バックアップをサポートしています。Coherenceフェデレーテッド・キャッシュを参照してください。

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

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

  • セカンダリWebLogicドメイン構成は、プライマリ・ドメインのレプリカです。本番サイトのストレージからスタンバイ・サイトのストレージに、中間層のファイル・システムなどのデータをコピーするには、レプリケーション・テクノロジ(ストレージ・レベルのレプリケーション、rsync、DBFS)を使用します。

親トピック: アクティブ/パッシブ・データベース層を使用するアクティブ/パッシブ・アプリケーション層

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

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

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

  • すべてのアクティブ/パッシブ・ドメインのペアは対称的トポロジで構成する必要があります。これらは同等であり、同じドメイン構成(ディレクトリの名前およびパス、ポート番号、ユーザー・アカウント、ロード・バランサおよび仮想サーバー名など)とソフトウェア・バージョンを使用する必要があります。ホスト名(静的IPではない)は、管理対象サーバーのリスニング・アドレスの指定に使用する必要があります。サイト間でホスト名が同じ場合(IPは同一ではない)、そのホスト名により、同じように構成されたサーバーまたはドメインをリカバリ・サイトで開始する動的な機能が提供されます。

  • このトポロジで遅延に関する考慮事項はありません。唯一の要件は、JMSおよびJTA TLogなどのストアがデータベースに維持されることです。

  • パッシブ・モードでWebLogic Serverのサーバーは構成されますが、稼働していません。障害がある場合、パッシブ・サイトのWebLogic Serverのサーバーが起動され、JTAおよびJMSのトランザクション/メッセージがリカバリされます。作業はその後2番目のサイトで実行されます。

  • パッシブ・サイトはプライマリ・サイトのWebLogicドメイン構成の正確なコピーを含む必要があります。本番サイトのストレージからスタンバイ・サイトのストレージに、中間層のファイル・システムなどのデータをコピーするには、レプリケーション・テクノロジ(ストレージ・レベルのレプリケーション、rsync、DBFS)を使用します。

    ストレージ・レプリケーションが有効化されると、アプリケーションのデプロイメント、構成、メタデータ、データおよび製品バイナリ情報が、本番サイトからスタンバイ・サイトにレプリケートされます。

  • JMSはこのトポロジでサポートされています。高可用性レプリケーションおよびクロスサイト・レプリケーションは、基礎となるOracle RACデータベースおよびData Guardによって自動的に提供されるため、JMSのデータベース・ストアを使用することをお薦めします。

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

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

    非同期レプリケーションは喪失メッセージ(メッセージがプライマリ・データ・センターに書き込まれたがコピーされていない)または重複メッセージ(メッセージがプライマリ・データ・センターで消費/削除されたがレプリケートされたデータ・センターに残っている)になる可能性があるため、基礎となるData Guardレプリケーションを利用するためにデータベース・ベースのストアを使用することをお薦めします。

    『ディザスタ・リカバリ・ガイド』のOracle WebLogic Server Java Message Service (JMS)およびトランザクション・ログ(T-Log)の推奨事項に関する項を参照してください。

  • ゼロ・ダウンタイム・パッチ適用は、お使いのWebLogicホーム、Javaおよびアプリケーションをアクティブなサイトでローリング方式でアップグレードします。計画済メンテナンスおよびパッシブ・サイトへのスイッチオーバー中、およびサーバーの起動後に、ゼロ・ダウンタイム・パッチ適用を使用してWebLogic、Javaまたはアプリケーションをアップグレードします。両方のサイトのドメインを対称に維持するには、両方のサイトでアップグレード・バージョンを同期状態に維持してください。

  • アクティブ/パッシブ・トポロジでは、Coherenceはスタンバイ・モードにあり、WebLogic Serverのようなパッシブ・モードではありません。スタンバイ・サイトにはアクティブなサイトからのキャッシュ・データのバックアップがあります。Coherenceフェデレーテッド・キャッシュをアクティブ/パッシブ・モードで使用すると、このレプリケーションは非同期ですが絶えず発生します。

  • このトポロジでは、Oracle Site Guardを使用してすべてのサイト・コンポーネント(Oracle Traffic Director、WebTier、WebLogic Server、Coherenceおよびデータベース)のフェイルオーバー/スイッチオーバーを編成することをお薦めします。

親トピック: アクティブ/パッシブ・データベース層を使用するアクティブ/パッシブ・アプリケーション層