1. Oracle WebLogic ServerおよびCoherenceのための高可用性とディザスタ・リカバリ・ガイド
  2. 高可用性およびディザスタ・リカバリのための設計に関する一般的な考慮事項

2 高可用性およびディザスタ・リカバリのための設計に関する一般的な考慮事項

Oracle WebLogic ServerおよびCoherenceでサポートされる最大可用性アーキテクチャ(MAA)ソリューションについて、推奨される設計上の考慮事項およびベスト・プラクティスが提供されています。 MAAアーキテクチャでは、地理的に分散した場所にデータ・センターが展開されます。MAAの目的は、コストおよび複雑さを最小限に抑えてOracleのお客様にとって最適な高可用性アーキテクチャを実現することです。

この章の内容は次のとおりです:

この章の推奨事項は、WebLogic ServerおよびCoherenceでサポートされているすべてのMAAアーキテクチャに適用されます。特定のアーキテクチャに固有の推奨事項については、次に示す後続の章で説明します:

  • グローバル・ロード・バランサ
    グローバル・ロード・バランサを本番サイトとスタンバイ・サイトの前面にデプロイすると、両方のサイトについて、障害検出サービスとパフォーマンスベースのルーティング・リダイレクションが提供されます。
  • Web層
    サポートされるWebLogic Server MAAアーキテクチャでは、Web層の構成はオプションです。Oracle HTTP Server (OHS)およびOracle WebLogic Serverプロキシ・プラグインなどのWeb層製品は、WebLogic Serverアプリケーションを効率的にフロントエンドにするように設計されています。OHSおよびWebLogic Serverプロキシ・プラグインは、WebLogic Serverの他の高可用性機能とともに使用できます。
  • WebLogic Server
    クラスタリング、シングルトン・サービス、セッション・レプリケーションなどのWebLogic Server機能をCoherenceおよびOracle Databaseの機能と組み合せて使用することで、最高レベルの可用性を達成できます。
  • Coherence
    フェデレーテッド・キャッシュ、永続性、GoldenGate Hot CacheなどのCoherence機能を、WebLogic ServerおよびOracle Databaseの機能と組み合せて使用することで、最高レベルの可用性を実現できます。
  • データベース
    Oracle Databaseでは、MAAアーキテクチャでデータベースの高可用性を提供するために統合できるOracle Data Guard、Oracle Real Application Clusters (Oracle RAC)、その他の機能をいくつか提供しています。

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

グローバル・ロード・バランサを本番サイトとスタンバイ・サイトの前面にデプロイすると、両方のサイトについて、障害検出サービスとパフォーマンスベースのルーティング・リダイレクションが提供されます。 さらに、このロード・バランサは、信頼できるDNSネーム・サーバーと同等の機能を提供できます。

プライマリサイト障害の場合に、スタンバイ・サイトが本番ロールをとった後、グローバル・ロード・バランサがユーザー・リクエストをスタンバイ・サイトへ再ルーテイングするために使用されます。F5 –BigIP Global Traffic Manager (GTM)およびCisco –Global Site Selector (GSS)などのグローバル・ロード・バランサは、(解決プロセスを従来型のDNSサーバーからオフロードすることで)DNSサーバー解決も処理します。

通常の操作時には、本番サイトのロード・バランサの名前とIPのマッピングを使用してグローバル・ロード・バランサを構成できます。DNSスイッチオーバーが必要な場合は、グローバル・ロード・バランサのこのマッピングを変更して、スタンバイ・サイトのロード・バランサのIPにマップします。これにより、本番ロールを引き継いだスタンバイ・サイトにリクエストが送信されるようになります。

DNSスイッチオーバーを使用するこの方法は、サイトのスイッチオーバー(計画済)およびフェイルオーバー(計画外)として機能します。グローバル・ロード・バランサを使用する利点の1つは、名前とIPの新しいマッピングがほとんど即時に有効になる点です。マイナス面は、グローバル・ロード・バランサに対する追加投資が必要な点です。DNSスイッチオーバーの実行手順は、ディザスタ・リカバリ・ガイドのDNS名の手動変更を参照してください。

親トピック: 高可用性およびディザスタ・リカバリのための設計に関する一般的な考慮事項

Web層

サポートされるWebLogic Server MAAアーキテクチャでは、Web層の構成はオプションです。Oracle HTTP Server (OHS)およびOracle WebLogic Serverプロキシ・プラグインなどのWeb層製品は、WebLogic Serverアプリケーションを効率的にフロントエンドにするように設計されています。OHSおよびWebLogic Serverプロキシ・プラグインは、WebLogic Serverの他の高可用性機能とともに使用できます。

Oracle HTTP Serverは、2通りの方法で構成できます。既存のOracle WebLogic Serverドメインの一部として構成する方法と、独自のスタンドアロン・ドメイン内に構成する方法です。WebLogic ServerおよびCoherenceでサポートされているMAAアーキテクチャでは、Oracle HTTPサーバー・インスタンスは個別のスタンドアロン・ドメインとして構成され、Oracle HTTP Serverインスタンスの構成と管理は、アプリケーション層ドメインとは別に、WLSTオフライン・コマンドを使用して行えます。

mod_wl_ohsモジュールは、管理対象サーバーへのリンクを処理します。mod_wl_ohsは、特定のタイプ(JSPなど)のリクエスト、またはURL宛てのリクエストを特定の管理対象サーバーにルーティングすることで構成します。

Oracle HTTP Server (OHS)では、プロセス障害とノード障害の2つのタイプの障害が発生します。プロセス障害は、個々のオペレーティング・システムで発生する可能性があります。一方、ノード障害は、OHSを実行しているホスト・コンピュータ全体の障害に及ぶ可能性があります。

  • プロセス障害では、ノード・マネージャによってOHSプロセスが保護および管理されます。OHSプロセスに障害が発生すると、ノード・マネージャによって自動的にプロセスが再起動されます。

  • ノード障害では、最初のOHSが応答しない場合、またはURL pingが障害の発生を示している場合、OHSの前面にあるロード・バランサが別のOHSインスタンスにリクエストを送信します。

  • クラスタ内の管理対象サーバーに障害が発生すると、mod_wl_ohsモジュールによってアクティブなクラスタ・メンバーの1つにリクエストが自動的にリダイレクトされます。アプリケーションに状態が格納されている場合、状態のレプリケーションがクラスタ内で使用可能になり、これにより、リダイレクトされたリクエストが、同じ状態情報にアクセスできます。

Oracle HTTP ServerおよびWebLogic Serverプロキシ・プラグインの詳細は次を参照してください。

親トピック: 高可用性およびディザスタ・リカバリのための設計に関する一般的な考慮事項

WebLogic Server

クラスタリング、シングルトン・サービス、セッション・レプリケーションなどのWebLogic Server機能をCoherenceおよびOracle Databaseの機能と組み合せて使用することで、最高レベルの可用性を達成できます。

サポートされているWebLogic Server MAAアーキテクチャにおけるこれらのWebLogic Server機能の設計に関する考慮事項については、次の各項を参照してください:

親トピック: 高可用性およびディザスタ・リカバリのための設計に関する一般的な考慮事項

クラスタリング

WebLogic Serverクラスタは、同時に動作し、連携して高度なスケーラビリティ、信頼性および高可用性を実現する複数のWebLogic Serverサーバー・インスタンスで構成されます。クラスタはクライアントからは単一のWebLogic Serverインスタンスのように見えます。クラスタを構成する複数のサーバー・インスタンスは同じマシン上で実行することも、複数のマシンに配置することもできます。クラスタの能力は、既存のマシン上のクラスタにサーバー・インスタンスを追加することによって強化できます。また、新たにサーバー・インスタンスを配置するためのマシンをクラスタに追加することもできます。クラスタ内の各サーバー・インスタンスでは、同一バージョンのWebLogic Serverを実行する必要があります。

WebLogic Serverでは、次の2種類のクラスタがサポートされます。

  • 動的クラスタ - 動的クラスタは、アプリケーションのリソース・ニーズを満たすように動的にスケール・アップできるサーバー・インスタンスで構成されます。動的クラスタを作成すると、動的サーバーが事前構成され、自動的に生成されます。これにより、追加のサーバー容量が必要な場合に動的クラスタ内のサーバー・インスタンスの数を簡単にスケール・アップできます。動的クラスタにより、ルールおよびポリシーを定義および構成して動的クラスタをスケール・アップまたは縮小できます。

    動的クラスタでは、管理対象サーバーの構成は単一の共有テンプレートに基づいています。クラスタ化された管理対象サーバーの構成が非常に簡素化され、マシン・リソースへのサーバーの動的割当ておよび最小構成を使用したリソース使用率の増加が可能になります。

    動的クラスタの拡張度により、ユーザーが識別した条件に基づいてクラスタをスケール・アップまたはダウンできます。クラスタのスケーリングは、要求時に(管理者により対話的に)特定の日時に、または様々なサーバー・メトリックで見られるパフォーマンスに基づいて実行できます。

    動的クラスタを縮小する場合、管理対象サーバーは段階的に停止され、作業/トランザクションを完了できます。必要に応じて、シングルトン・サービスが自動的にクラスタ内の別のインスタンスに移行されます。

  • 静的クラスタ - 静的クラスタでは、エンドユーザーが新規サーバーを構成してクラスタに追加し、手動で起動および停止する必要があります。クラスタの拡張および縮小は自動ではないため、管理者が実行する必要があります。

多くの場合、動的クラスタを使用して拡張度をWebLogicデプロイメントに提供することをお薦めします。動的クラスタの利点は、最小構成、クラスタの拡張度およびクラスタ縮小時のJMSとJTAシングルトン・サービスの適切な移行です。

ただし、一部のインスタンスでは静的クラスタを使用する必要があります。このようなインスタンスは、手動でシングルトン・サービスを移行する必要がある場合です。動的クラスタはシングルトン・サービスの手動の移行をサポートしていません。

親トピック: WebLogic Server

シングルトン・サービス

シングルトン・サービスとは、管理対象サーバーで実行されるサービスであり、1度にクラスタ内の1つのメンバー上でのみ使用可能になります。WebLogic Serverでは、シングルトン・サービスを自動的に監視したり、あるサーバー・インスタンスから別のサーバー・インスタンスに移行したりできます。

JMS関連サービスおよびユーザー定義シングルトン・サービスなどの固定サービスは、WebLogicクラスタ内の個々のサーバー・インスタンスにホストされています。シングルトンJMSまたはJTAサービスが原因で、クラスタ内の依存するアプリケーションに対するシングル・ポイント障害が発生しないようにするため、シングルトン・サービスをクラスタ内の任意のサーバー・インスタンスに自動または手動で移行できるようにWebLogic Serverを構成できます。

アプリケーション内に、クラスタの複数のメンバーで同時に実行したくないタスクを実行するためのシングルトン・サービスを定義できます。シングルトン・サービスの自動移行では、ユーザー定義シングルトン・サービスのヘルス・モニタリングと移行を自動化できます。

シングルトン・サービスについては、次の項で説明します。内容は次のとおりです。

親トピック: WebLogic Server

サーバーおよびサービスの移行

Oracle WebLogic Serverでは、次の2種類の自動移行メカニズムをサポートしています。

  • サーバー全体の移行では、移行可能なサーバー・インスタンスとそのすべてのサービスが、障害発生時に物理的に別のマシンに移行されます。サーバー移行が構成されているクラスタに属するサーバーで問題が発生すると、そのサーバーは、クラスタのメンバーをホストする他のマシンで再起動されます。Oracle WebLogic Serverクラスタの管理のサーバー全体の移行を参照してください。

  • サービスの移行では、失敗したサービスが1つのサービス・インスタンスからクラスタ内で使用可能な別のサーバー・インスタンスに移行されます。状況によっては、サービスの移行のほうがサーバー全体の移行よりはるかに良好に機能します。これは、サーバー全体とは対照的にシングルトン・サービスの移行のみを実行しているためです。Oracle WebLogic Serverクラスタの管理のサービスの移行を参照してください。

サーバーの移行ではなく、サービスの移行機能を使用することをお薦めします。サービスの移行では、より少ないリソースで同じ高可用性保護が提供されます。たとえば、サーバーの移行に必要な浮動IPは、サービスの移行では不要であり、WebLogic Server全体を移行するのではなく、重要なサービスのみが移行されるため、使用されるメモリーまたはCPUリソースが少なくて済みます。

サーバー全体の移行およびサービスの移行は、どちらもデータベースのリース表を構成する必要があります。「リース」を参照してください。

MAA環境でサーバーおよびサービスの移行を使用するためのWebLogicサーバーの構成の詳細は、Oracle SOA Suiteエンタープライズ・デプロイメント・ガイドのエンタープライズ・デプロイメントでのサーバー全体の移行とサービスの移行の使用を参照してください。

データ・ストア

Oracle WebLogic Serverのトランザクション・ログおよびOracle WebLogic ServerのJMSには、データベース・ベースおよびファイル・ベースの2種類の永続データ・ストアがあります。

永続ストアをデータベースに保持することにより、基礎となるデータベース・システムに固有のレプリケーションおよび高可用性の利点が提供されます。JMS、TLogおよびアプリケーションが同じデータベースおよびOracle Data Guardで処理されたレプリケーション内にある場合、クロスサイトの同期が簡素化され、NASやSANなどの共有ストレージ・サブシステムの必要性は中間層で軽減されます。「データベース」を参照してください。

ただし、TLogおよびJMSストアをデータベースに格納すると、システム・パフォーマンスに対するペナルティがあります。このペナルティは、サイトの1つが他のサイトのデータベースと相互通信する必要がある場合に増加します。理想的には、パフォーマンスの観点から見て、各サイトに対してローカルな共有ストレージを両方の種類のストアに使用し、パフォーマンスの低下なしでゼロ・データ損失を保証するためにストレージ・レベルでの適切なレプリケーション戦略とバックアップ戦略をプロビジョニングする必要があります。データベース・ストアを使用したほうがシステム用の共有ストレージより適しているかどうかは、JMSおよびトランザクション・データの重要度によります。これは、共有ストレージが提供する保護のレベルがデータベースが保証するよりはるかに低いためです。

(Oracle Databaseパーティショニングが使用できる場合)索引にグローバル・ハッシュ・パーティションなどのテクニックを使用することで、データベース・ストアのパフォーマンスの影響を、特に並行性が大きい場合に最小限にとどめることができます。パフォーマンスへの影響を最小限にすることに関する推奨事項については、『Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』のエンタープライズ・デプロイメントでのTLOGおよびJMSに対する永続ストアの使用に関する項を参照してください。

アクティブ/アクティブ・トポロジおよびアクティブ/パッシブ・トポロジでは、データベースにデータ・ストアを維持することが必須です。JMSおよびJTAストアなどのWebLogic Serverストアを、Oracle RACなどの高可用性のデータベースに維持し、最大のパフォーマンスおよび可用性を得るためにActive GridLinkデータソースを使用してデータベースに接続することをお薦めします。

アクティブ/アクティブ・ストレッチ・クラスタの場合、データ・ストアをNASやSANなどの共有ストレージ・サブシステムに維持するか、データベースに維持するかを選択できます。ただし、高可用性レプリケーションおよびクロスサイト・レプリケーションは、基礎となるOracle RACデータベースおよびData Guardによって自動的に提供されるため、データベース・ベースのストアをストレッチ・クラスタでも使用することをお薦めします。

JMSおよびJTAストアなどのWebLogic Serverストアおよびリース表を、Oracle RACなどの高可用性のデータベースに維持し、Active GridLinkデータソースを使用してデータベースに接続することをお薦めします。データベース内でストアおよびリース表を格納する方法には、次のメリットがあります。

  • 基礎となるデータベース・システムに固有のレプリケーションおよびその他の高可用性の側面を利用します。

  • 障害時リカバリ・シナリオの処理を強化します。JMS、TLogおよびアプリケーションが同じデータベース内にありレプリケーションがData Guardにより処理される場合、クロスサイトの同期について心配する必要はありません。

  • NASまたはSANなどの共有ストレージ・サブシステムの必要性を軽減します。データベースの使用により全体的なシステムの複雑さも減ります。これは多くの場合、データベースが標準のランタイム/アプリケーション作業用にすでに存在しているためです。

リース

リースは、クラスタの複数のメンバーで同時に実行することができないサービスを管理するために使用するプロセスです。リースによって、クラスタ全体エンティティの排他的な所有権を確保できます。リースのオーナーは、クラスタ内に1つしか存在しません。また、サーバーやクラスタの障害時にはリースをフェイルオーバーさせることができ、シングル・ポイント障害を回避するために役立ちます。Oracle WebLogic Serverクラスタの管理のリースを参照してください。

WebLogic Serverには、非データベースのコンセンサス・リースと高可用性データベース・リースという、2つのタイプのリース機能があります。高可用性またはディザスタ・リカバリのシナリオにおいては、データベース・リースの使用をお薦めします。

データベース・リースの場合、次をお薦めします。

  • Oracle RACおよびActive GridLink (AGL)などの高可用性データベース。

  • スタンバイ・データベース、および2つのデータベース間のレプリケーションを提供するOracle Data Guard。

WebLogic Serverには、WebLogicクラスタ・データベース・リース表を自動作成するオプションがあります。このオプションを使用すると、リース表が存在しないことが自動的に検出され、データベース・タイプが検出されます。続いて、適切なデフォルトDDLファイルが検索されて実行され、表が作成されます。『Oracle WebLogic Serverクラスタの管理』の高可用性データベース・リースに関する項を参照してください。

データベース・リースを使用する際、データベースが(スイッチオーバーまたはフェイルオーバー中に)サーバー移行の分離時間よりも長い期間使用不可を続けている場合、Oracle WebLogic Serversが停止する場合があります。サーバー移行の分離時間は、『Oracle WebLogic Serverクラスタの管理』の次のトピックに説明されているように調整できます。

セッション・レプリケーション

WebLogic Serverでは、クラスタ内の複数のサーバー間でHTTPセッション状態をレプリケートするために次の3つの方法が用意されています。

  • メモリー内レプリケーション - WebLogic Serverはメモリー内レプリケーションを使用して、1つのサーバー・インスタンスから別のインスタンスにセッション状態をコピーします。プライマリ・サーバーはクライアントが最初に接続するサーバー上にプライマリ・セッション状態を作成し、クラスタ内の別のWebLogic Serverインスタンス上に予備のレプリカを作成します。サーブレットのホストとなっているサーバーで障害が起きた場合に使用できるように、レプリカは最新の状態に保たれます。

  • JDBCベースの永続性 - JDBCベースの永続性では、WebLogic Serverはファイル・ベースまたはJDBCベースの永続性メカニズムを使用して、サーブレットまたはJSPのHTTPセッション状態を保持します。それぞれの永続性メカニズムの詳細は、Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発のセッションの永続性の構成を参照してください。

  • Coherence*Web - Coherence*Webは、WebLogic ServerのインメモリーHTTP状態レプリケーション・サービスの代替ではありません。ただし、アプリケーションに大量くのHTTPセッション状態オブジェクトがある場合、HTTPセッション状態オブジェクト・データの格納によってメモリー制約が発生する場合、または既存のCoherenceクラスタを再利用する場合は、Coherence*Webを使用することをお薦めします。Oracle Coherence*WebでのHTTPセッション・マネージメントの管理のWebLogic ServerでのCoherence*Webの使用方法を参照してください。

遅延モデル、セッション損失に対する許容度およびパフォーマンスに応じて、もっとも要件に適した方法を選択する必要があります。

  • 遅延が小さい場合、たとえばMANネットワーク(ストレッチ・クラスタ・トポロジ)などでは、WebLogic Serverインメモリー・セッション・レプリケーションをお薦めします。ただし、サイトで障害が発生した場合はセッション損失の可能性があります。

  • 遅延が大きく(WANネットワーク)、アクティブ/アクティブまたはアクティブ/パッシブ・トポロジの場合、およびお使いのアプリケーションがセッション損失を許容できない場合、データベース・セッション・レプリケーションをお薦めします。

多くの場合、インメモリー・セッション・レプリケーションのほうがデータベース・セッション・レプリケーションよりはるかに良好に機能します。Oracle WebLogic Serverクラスタの管理のクラスタのフェイルオーバーとレプリケーションを参照してください。

親トピック: WebLogic Server

データソース

WebLogic Active GridLinkデータ・ソースは、Oracle RACデータベースおよびOracle Data Guardと統合されて最高のパフォーマンス、高いスケーラビリティおよび最高の可用性を提供します。Oracle RACとの統合により、Active GridLinkは高速接続フェイルオーバー(FCF)、ランタイム接続ロード・バランシング(RCLB)およびアフィニティの各機能を実行できます。Active GridLinkは、データベース内の計画済メンテナンスを、エンドユーザーに対する中断なしで処理する一方ですべての作業が完了するようにできます。

お使いのActive GridLink URLを構成してフェイルオーバー時間をデータベース間で最小化できます。Oracle WebLogic Server JDBCデータ・ソースの管理のサポートされるAGLデータソースURL形式を参照してください。

親トピック: WebLogic Server

セキュリティ

WebLogic ServerとJava EEアプリケーションを本番環境にデプロイする前に、セキュリティ・ニーズを決定し、適切なセキュリティ対策を講じることが重要です。Oracle WebLogic Server本番環境の保護の本番環境のセキュリティの確保を参照してください。

親トピック: WebLogic Server

ストレージ

通常、特定の環境内のOracle Fusion Middlewareコンポーネントは相互に依存するため、トポロジ内のコンポーネントが同期されていることが重要です。MAA環境で考慮が必要な一部のストレージ・アーティファクトは静的および動的として分類されています。

  • 静的アーティファクトは、頻繁には変更されないファイルやディレクトリです。これには次のものがあります。

    • ホーム: Oracleホームは通常、OracleホームとOracle WebLogic Serverホームで構成されます。

    • Oracleインベントリ: これには、/etcディレクトリにある、oraInst.locおよびoratabファイルが含まれます。

  • 動的またはランタイム・アーティファクトは、頻繁に変更されるファイルです。ランタイム・アーティファクトには、次のものが含まれています。

    • ドメイン・ホーム: 管理サーバーおよび管理対象サーバーのドメイン・ディレクトリ。

    • Oracleインスタンス: Oracleインスタンスのホーム・ディレクトリ。

    • .earファイルや.warファイルなどのアプリケーション・アーティファクト。

    • MDSリポジトリなどのデータベース・アーティファクト。

    • Oracle Fusion Middlewareで使用されるデータベース・メタデータ・リポジトリ。

    • JMSプロバイダやトランザクション・ログなどの永続ストア。可用性および障害時リカバリのベスト・プラクティスとして、これらをデータベース永続ストアに格納することをお薦めします。「データ・ストア」を参照してください。

    • デプロイメント・プラン: ファイル・アダプタやJMSアダプタなどのテクノロジ・アダプタの更新に使用されます。これらは、アーティファクトがデプロイされるクラスタ内のすべてのノードにアクセスできる場所に保存する必要があります。

可用性が最大になるように、バイナリの冗長インストールを使用することをお薦めします。各ノードは独自のOracleホームを持ち、ゼロ・ダウンタイム・パッチの適用時に1つのノード内のサーバーのみが一度に停止されるようにする必要があります。

ホーム・ディレクトリや構成ファイルなどアーティファクトの共有ストレージに関する推奨ガイドラインについては、『高可用性ガイド』の「共有記憶域の使用」を参照してください。

親トピック: WebLogic Server

ゼロ・ダウンタイム・パッチ適用

ゼロ・ダウンタイム・パッチ適用(ZDTパッチ適用)では、アップグレードのロールアウト処理中に継続的なアプリケーション可用性が提供されます。これはロールアウト処理中の障害の可能性が常に存在しても変わりません。MAA環境では、一度に1つのサイトに対してパッチを適用し、その他のサイトに対する更新の時間をずらしてサイトの同期が残るようにすることをお薦めします。サイト障害シナリオの場合、失敗したサイトがZDTパッチ適用を再開する前に再開できるようにします。

ZDTパッチ適用を使用する場合、次を考慮してください。

  • ロールアウトは一度に1つのノードを停止するため、クラスタ内のノードが増えるほどクラスタのトラフィック処理能力への影響が少なくなります。

  • クラスタのノードが2つのみで一方のノードがパッチ適用のために停止している場合、高可用性は保証されません。クラスタ内には2個を超えるノードを持つことをお薦めします。

  • 管理対象サーバーを管理サーバーと同じノードに含めた場合、両方のサーバーをともに停止してOracleホームを更新する必要があります。

  • 2つのクラスタでOracleホームを共有する同じノード上にサーバーを持つことができますが、両方のクラスタを停止して同時にパッチを適用する必要があります。

  • Oracleホームが2つ含まれている構成の場合、適用するパッチをテストできるように、本番マシン以外に2つ目のOracleホームを作成してパッチを適用することをお薦めしますが、必須ではありません。そのノードのOracleホームは、本番ドメインで使用しているOracleホームと同じである必要があります。

ゼロ・ダウンタイム・パッチ適用ワークフローの管理のゼロ・ダウンタイム・パッチ適用の概要を参照してください。

親トピック: WebLogic Server

Coherence

フェデレーテッド・キャッシュ、永続性、GoldenGate Hot CacheなどのCoherence機能を、WebLogic ServerおよびOracle Databaseの機能と組み合せて使用することで、最高レベルの可用性を実現できます。

サポートされているMAAアーキテクチャにおけるCoherenceの設計に関する考慮事項については、次の各項を参照してください。

親トピック: 高可用性およびディザスタ・リカバリのための設計に関する一般的な考慮事項

Coherence永続キャッシュ

致命的障害や、計画的メンテナンスによるクラスタ再起動の後に迅速なリカバリができるように、キャッシュされたデータは保持されます。マルチ・データ・センター環境では、Coherence永続性とフェデレーテッド・キャッシュの両方を使用して、障害時または計画メンテナンス・イベント中に最高レベルの保護を確保することをお薦めします。

永続性は、分散キャッシュに対してのみ使用可能で、集中パーティション割当て戦略を使用する必要があります。次の2つの永続性モードがあります。

  • アクティブ永続性 – キャッシュの内容はすべてのミューテーションで自動的に永続化され、クラスタ/サービスの起動時に自動的にリカバリされます。

  • オンデマンド永続性 – キャッシュ・サービスは手動で永続化され、リクエスト時に永続性コーディネータを使用してリカバリされます。

Oracle Coherenceの管理の永続キャッシュを参照してください。

親トピック: Coherence

Coherenceフェデレーテッド・キャッシュ

(ストレッチ・クラスタでない)アクティブ/アクティブおよびアクティブ/パッシブ・トポロジでは、Coherenceフェデレーテッド・キャッシュを使用できます。事前に、次の問題を考慮してください:

  • Coherenceデータが、ネットワークの分断またはリモート・クラスタの機能停止の後も他のサイトのなんらかのポイントに順序付け方式で到達しています(Coherenceでは順序付けはCoherenceパーティションごとです)。

  • リモート・サイトはローカル・サイトが更新された後の一定期間に失効データを読み取る場合があります。

  • 更新競合の可能性があり、これらを識別してアプリケーション固有の競合解消機能を呼び出します。

Coherenceフェデレーテッド・キャッシュは、次の理由でサイト間に最終競合モデルを実装しています。

  • データ・センターはどこにでも配置でき、場所は遅延または使用可能な帯域幅に制約されません。

  • リモートのデータ・センターまたはクラスタの使用不可状態が許容されることは、きわめて望ましいことです。通信が停止していることとリモート・クラスタが停止していることの違いを述べることは非常に困難であり、区別する必要はありません。

  • アクティブ/アクティブ構成における完全整合性にはなんらかの種類の分散センターの並行制御および同期書込みが必要です。これは、パフォーマンスに大きな影響を与えることがあり、望ましいことではありません。かわりに、整合性が重要なところでは、同期レプリケーションを伴うストレッチ・クラスタを使用できます。この場合、データ・センター間に保証帯域幅とともに最大遅延をアサートすることが妥当です。

Oracle Coherenceの管理のクラスタ間のキャッシュのフェデレートを参照してください。

親トピック: Coherence

Coherence GoldenGate Hot Cache

データの混合を伴う単一Coherenceクラスタ内では、データの一部がデータベースにより所有され、一部がCoherenceにより所有され、Coherence Read-ThroughキャッシュとCoherence GoldenGate Hot Cacheの両方を使用できます。

HotCacheおよびRead-Throughキャッシュ間の選択は、(1) データベースがCoherenceのバックで更新された場合にRead-Throughが失効読取りにつながる場合があるか、(2) HotCacheのリアルタイム性が他の理由で優先されるかということになります。HotCacheおよびRead-Throughの両方を併用して、たとえばHotCache経由でリアルタイム更新をプッシュするが、その後は削除または期限切れのためにデータが削除されたケースを処理するという状況もありえます。

Oracle Coherenceの統合のOracle Coherence GoldenGate HotCacheとの統合を参照してください。

親トピック: Coherence

データベース

Oracle Databaseでは、MAAアーキテクチャでデータベースの高可用性を提供するために統合できるOracle Data Guard、Oracle Real Application Clusters (Oracle RAC)、その他の機能をいくつか提供しています。 「Oracle Databaseの高可用性およびディザスタ・リカバリ」を参照してください。トポロジに関係なく、目標はデータベースのスイッチオーバーおよびフェイルオーバーにかかる時間を最小化することです。

計画済および計画外の両方の停止に備えてお使いのデータベースの高可用性を達成するには、次の機能を組み合せたアクティブ/パッシブ構成を使用することをお薦めします:

  • 可用性の高いデータベースとしてのOracle RAC。Oracle Real Application Clusters管理およびデプロイメント・ガイドのOracle RACの概要を参照してください。

  • ミッション・クリティカルなOracle Databaseに対する単一点障害を排除するOracle Data Guard。これは、リモートの場所に同期化された本番データベースの物理レプリカを維持することによって、データ損失および停止時間を防止します。本番データベースがどのような理由で使用不可になっている場合でも、クライアント接続が短時間で、また一部の構成では透過的に、同期されたレプリカにフェイルオーバーされてサービスを回復します。アプリケーションは、わずかな変更または変更なしでOracle Data Guardを利用できます。Oracle Data Guard概要および管理のOracle Data Guardの概要を参照してください。

    サポートされているWebLogic Server MAAアーキテクチャでは、Oracle Data Guardの最大可用性保護モードを使用することをお薦めします。この保護モードは、プライマリ・データベースの可用性を低下させない範囲で可能な最高レベルのデータ保護を提供します。特定の二重障害の場合(スタンバイ・データベースの障害が発生した後にプライマリ・データベースの障害が発生した場合など)を除いて、データ消失がないことを保証します。『Oracle Data Guard概要および管理』のOracle Data Guardの保護モードに関する項を参照してください。

    ノート:

    Oracle Data Guardはアクティブ/パッシブ構成でのみ使用できますが、ゼロデータ損失が保証されます。

  • Oracle Active Data Guardは、Oracle Data Guardのインフラストラクチャの組込みオプションで、プライマリ・データベースから変更が適用されている間も、フィジカル・スタンバイ・データベースを読取り専用で開くことができます。これにより、読取り専用アプリケーションは、プライマリ・データベースで非常に大きいトランザクション・ボリュームの処理中であっても、スタンバイ・データベースとプライマリ・データベース上のデータ間での遅延を最小限に抑えながら、フィジカル・スタンバイを使用できます。これはリアルタイム問合せと呼ばれることもあります。『Oracle Data Guard概要および管理』のフィジカル・スタンバイ・データベースのオープンに関する項を参照してください。

    Oracle Active Data Guardスタンバイ・データベースは、アプリケーションに透過的に、プライマリ・データベースにより検出されたデータ破損の自動修復に使用されます。プライマリ・データベースでの計画外停止の場合も、スタンバイ・データベースへの迅速なフェイルオーバーにより高可用性が保たれます。Active Data Guardスタンバイ・データベースは、プライマリ・データベースのブロック対ブロックのフィジカル・レプリカであるため、特定のプライマリ・データベースから高速増分バックアップをオフロードすることもできます。

    Oracle Active Data Guardには、ゼロ・データ損失構成でパフォーマンスを向上する遠隔同期機能があります。 Oracle Data Guard遠隔同期インスタンスは、プライマリ・データベースからREDOを受け取り、それをOracle Data Guard構成の他のメンバーに送信する、リモートのOracle Data Guardの宛先です。スタンバイ・データベースとは異なり、遠隔同期インスタンスにはデータ・ファイルがなく、オープンすることもできず、受け取ったREDOを適用することもできません。これらの制限のために、ディスクと処理リソースの使用量が少なくなる利点があります。より重要なこととして、遠隔同期インスタンスは、同期転送モードを使用してREDOデータを受け取り、構成保護モードが最大可用性に設定されている場合、データ損失なしでターミナル・データベースにフェイルオーバーすることができます。『Oracle Data Guard概要および管理』の遠隔同期インスタンスに関する項を参照してください。

  • Oracle Data Guardブローカは、Data Guard構成の作成、メンテナンス、監視を自動化および集中化する分散管理フレームワークです。Data Guard Brokerが実行できる操作の一部として、Data Guard構成の作成、管理、監視、構成内のすべてのデータベースにわたる複雑なロール変更を開始および制御するためのスイッチオーバーまたはフェイルオーバーの起動、およびフェイルオーバーを自動発生させるための構成があります。Data Guard BrokerのOracle Data Guard Brokerの概要を参照してください。

    プライマリ・データベースが使用できなくなった場合に、Oracle Data Guardのファスト・スタート・フェイルオーバーを有効化して、すぐにフェイルオーバーを自動的に行うことができます。ファスト・スタート・フェイルオーバーが有効化されている場合、Oracle Data Guardブローカによってフェイルオーバーの必要性が判断され、指定されたターゲット・スタンバイ・データベースへのフェイルオーバーが自動的に開始されます。データベース管理者による操作は不要です。『Oracle Data Guard Broker』のファスト・スタート・フェイルオーバーの管理に関する項を参照してください。

  • WebLogic ServerのActive GridLinkデータソースは、データベース・サーバーのスケジュール済メンテナンス・プロセスをアプリケーションに対して透過的にします。データベース・サーバーでメンテナンスのためにインスタンスを停止する場合、セッション排出によって、そのノードでインスタンスを使用しているすべての作業が完了し、アイドル・セッションが削除されることが保証されます。セッションは、処理中の作業に影響を与えることなく排出されます。

  • Application Continuityは、計画済および計画外の停止中にユーザーを保護します。計画外の停止イベント中に最大の可用性を得るにはApplication ContinuityおよびActive GridLinkを使用します。『Real Application Clusters管理およびデプロイメント・ガイド』のアプリケーション・コンティニュイティの確保に関する項を参照してください。

  • サイトにまたがって排出する高速アプリケーション通知(FAN)を伴うGlobal Data Services (GDS)またはData Guardブローカ。Active Data Guardを使用する場合、セカンダリ・データベースにスイッチオーバーされる前に作業が完了する可能性があります。

お使いの構成でアクティブ/アクティブ・データベース構成が必要な場合、次をお薦めします。

  • Oracle GoldenGate。データベースをアクティブ/アクティブ・モードにできます。読取りおよび書込みサービスの両方が両方のサイトのデータベースでアクティブ/アクティブであること。『Oracle GoldenGateの管理』のアクティブ/アクティブ型高可用性のためのOracle GoldenGateの構成に関する項を参照してください。

    Oracle Golden Gateを使用する際、Application ContinuityおよびActive GridLinkをサイト内(イントラサイト)で使用して計画済および計画外の停止のデータベース・イベントを処理できます。Application Continuityは、サイト間(インターサイト)のフェイルオーバーまたはスイッチオーバー操作中に使用してトランザクションをリプレイすることはできません。Application Continuityは、Oracle Logical StandbyおよびOracle Golden Gateを含めた論理的に異なるデータベースに対するフェイルオーバーをサポートしていません。リプレイには、トランザクション・ロスがないことが検証済のデータベースに適用される厳密な要件があります。

    ノート:

    Oracle GoldenGateの非同期レプリケート特性のため、アプリケーションはネットワークの遅れが原因のデータ損失を許容する必要があります。

  • Oracle GoldenGateを使用するすべてのアプリケーション/スキーマに対して完全なアクティブ/アクティブを備えた競合解決を実装すること。

  • 失効データ(対話中のサイトに限定)の表示を避けるためにWebアフィニティを必要とする環境を設計すること。Global Data Services (GDS)は、サイトにローカルなデータベースに対するアフィニティを提供してグローバル・サービスを管理できます。『Oracle Database Global Data Services概要および管理ガイド』のGlobal Data Servicesの概要に関する項を参照してください。

環境でアクティブ/アクティブ・データベースが必要な場合、これらのテクノロジの組合せを使用して計画済メンテナンス・イベントで可用性を最大限、データ損失を最小限にできます。

親トピック: 高可用性およびディザスタ・リカバリのための設計に関する一般的な考慮事項