2 Oracle Application Server 高可用性フレームワーク

Chapter 1では一般的な高可用性の概要について説明しましたが、この章では高可用性トポロジで重要なOracle Application Serverの機能について説明します。この章の項は次のとおりです。

• 第2.1項「OPMNでのプロセス管理」

• 第2.2項「状態情報のレプリケーション」

• 第2.3項「Oracle Application Serverでのロード・バランシング」

• 第2.4項「OracleAS Cluster」

• 第2.5項「外部ロード・バランサ」

• 第2.6項「バックアップとリカバリ」

• 第2.7項「障害時リカバリ」

• 第2.8項「高可用性トポロジ： 概要」

2.1 OPMNでのプロセス管理

Oracle Application Serverインスタンスは、クライアント・リクエストを処理する多数の様々な実行中のプロセスで構成されています。高可用性の確保とは、これらのプロセスがすべてスムーズに実行され、リクエストが処理されると同時に、予期しないハングや障害が発生しないことを意味します。

Oracle Application ServerのOracle Process Manager and Notification Server（OPMN）コンポーネントは、次のプロセス管理サービスを提供します。

• OPMNは、停止しているか、レスポンスがないか、切断されているOracle Application Serverプロセスを検出すると、そのプロセスを自動的に再起動します。OPMNは、pingまたは通知メソッドによってプロセスを監視します。

• OPMNでは適切な順番でプロセスが開始されます。他のプロセスに依存しているプロセスは、依存先のプロセスが起動するまで起動されません。

OPMNを使用して、プロセスの起動や停止、プロセスのステータスのチェックなどのタスクを実行することもできます。

OPMNは、次のOracle Application Serverプロセスを管理します。

• Oracle HTTP Server

• Oracle Containers for J2EE（OC4J）

• OracleASログ・ローダー

• OracleAS Guard（障害時リカバリ用）

• OracleAS Port Tunnel

さらに、OPMNによって、前述のコンポーネントに依存するどのアプリケーションも暗黙的に管理されます。たとえば、J2EEアプリケーションはOPMNによって管理されるOC4Jの下で実行されるため、OPMNによって管理されます。

OPMNを使用してOracle Application Serverインスタンスをクラスタリングし、Oracle HTTP Serverがリクエストをクラスタ内の任意のOC4Jインスタンスに送信できるようにすることもできます。このクラスタリングはアクティブ/アクティブ・トポロジで必要です。詳細は、第3章「アクティブ/アクティブ・トポロジ」を参照してください。

OracleAS Clusterでは、クラスタ内のすべてのOracle Application Serverインスタンスを管理することもできます。たとえば、OPMNコマンドを1台のマシンで発行し、クラスタ内のすべてのローカルおよびリモートのOracle Application Serverインスタンスですべてのプロセスまたは特定のプロセス・タイプを起動できます。

OPMNは拡張可能で、カスタム・プロセス、システムの負荷、カスタム停止プロシージャ、および障害の検出と再起動のメソッドに関する情報を追加する機能を提供します。

OPMNの詳細は、『Oracle Process Manager and Notification Server管理者ガイド』を参照してください。

2.2 状態情報のレプリケーション

アプリケーションを分散する1つの利点は、複数の冗長プロセスすべてがクライアントからのリクエストを処理できることです。これらのプロセスの1つが使用不可になった場合、別のプロセスでリクエストを処理できます。

アプリケーションによっては、Oracle Application Serverが、連続したリクエスト間のステートフル情報を保持することが必要な場合があります。これらのリクエストの透過的なフェイルオーバーを実現するには、複数のプロセス間でこのアプリケーション状態をレプリケートする必要があります。Oracle Application Serverでは、アプリケーションレベルのクラスタリングによって、J2EEアプリケーションでの状態のレプリケーションが可能です。アプリケーション・クラスタでは、いくつかのプロセスが連動して、同じJ2EEアプリケーションを実行し、それによって作成された状態がレプリケートされます。これによって、クラスタ内のインスタンス間でのリクエストの透過的なフェイルオーバーが可能になります。

J2EEアプリケーションは、次の2つのタイプの状態情報を保持できます。

• HTTPセッション状態（サーブレットとJSPによって更新）

• ステートフル・セッションEJB状態（ステートフル・セッションEJBインスタンスによって更新）

OracleAS Cluster（OC4J）内では、アプリケーションレベルのクラスタリングによって、両方のタイプの状態情報のレプリケーションが実現されます。状態情報のレプリケート方法、状態情報がOC4Jインスタンス間でレプリケートされる頻度およびレプリケートする状態情報は制御が可能です。表2-1を参照してください。

表2-1    状態情報のレプリケート手順 

作業内容	参照先
状態情報のレプリケート方法の設定	状態情報は、マルチキャスト、peer-to-peerまたはデータベースを使用してレプリケートできます。 第3.2.2.1項「マルチキャスト・レプリケーションの設定」 第3.2.2.2項「peer-to-peerレプリケーションの設定」 第3.2.2.3項「データベースへのレプリケーションの設定」
状態情報をレプリケートする頻度の指定またはレプリケートする情報の指定	第3.2.2.4項「レプリケーション・ポリシーの設定」を参照してください。

詳細は、『Oracle Containers for J2EE構成および管理ガイド』の「OC4Jでのアプリケーションのクラスタリング」も参照してください。

2.3 Oracle Application Serverでのロード・バランシング

ロード・バランシングでは、複数のプロセスにリクエストを分散します。ソフトウェアまたはハードウェアのロード・バランサの機能は次のとおりです。

• ロード・バランシング・アルゴリズム

  アルゴリズムは、リクエストを各プロセスに割り当てる方法を指定します。最も一般的なロード・バランシング・アルゴリズムとしては、他のインスタンスと比較した場合のレスポンス時間や許容量など、そのインスタンスの重み付けされたプロパティに基づいた単純なラウンドロビンまたは割当てがあります。

  通常、アルゴリズムにはローカルのインスタンスとリモートのインスタンスのプロセスが含まれています。これによって、あるコンポーネントからリモート・マシンで実行されている別のコンポーネントにリクエストを送信できます。

• 障害の検出

  ロード・バランサは、1つ以上のプロセスに対するリクエストに障害が発生すれば、そのリクエストを検出でき、それ以降はそれらのプロセスにリクエストが転送されないように、該当プロセスを非アクティブとしてマークできることが必要です。

Oracle Application Serverでは、一部のコンポーネント間のリクエストのルーティングでロード・バランシング・メカニズムが使用されます。表2-2に、例を示します。

表2-2    コンポーネント間のリクエストのルーティング 

ルーティング元	ルーテイング先	説明
OracleAS Web Cache（リリース2（10.1.2））	Oracle HTTP Server	OracleAS Web Cacheでは、Oracle HTTP Serverを含む任意のOracle Application Serverインスタンスにリクエストをルーティングできます。 OracleAS Web Cacheは、Oracle HTTP Serverから返されたレスポンスで障害を検出した場合、使用可能なOracle HTTP Serverに新しいリクエストをルーティングします。 ルーティング・アルゴリズムはOracleAS Web Cacheコンポーネントで構成します。詳細は、リリース2（10.1.2）の『Oracle Application Server Web Cache管理者ガイド』を参照してください。
Oracle HTTP Server	OC4J	Oracle HTTP Serverは、J2EEアプリケーションに対するリクエストをOC4Jプロセスにルーティングします。ルーティングはOracle HTTP Serverのmod_oc4jモジュールによって実行されます。 mod_oc4jでは、OracleAS Clusterの任意のOC4Jプロセスにリクエストをルーティングできます。 Oracle HTTP Serverは、使用可能なOC4Jプロセスのルーティング・テーブルを維持し、実行中のOC4Jプロセスにのみ新しいリクエストをルーティングします。 ルーティング・アルゴリズムはOracle HTTP Server構成ファイルのディレクティブを使用して構成します。詳細は、第3.2.8項「mod_oc4jのロード・バランシング・オプションの設定」を参照してください。
Oracle HTTP Server	データベース	Oracle HTTP Serverは、PL/SQLアプリケーションに対するリクエストをデータベースにルーティングします。ルーテイングを実行するのはOracle HTTP Serverのmod_plsqlモジュールです。mod_plsqlは、データベースの障害を検出でき、使用可能なデータベース・ノードにのみリクエストをルーティングします。
OC4J	OC4J	OC4J内では、OC4Jがプレゼンテーション・レイヤー・コンポーネント（サーブレットおよびJSP）からビジネス・レイヤー・コンポーネント（EJB）にリクエストをルーティングします。 OC4JがEJB層に対するRMI呼出しで障害を検出した場合は、使用可能なEJBノードに通信をフェイルオーバーします。
OC4J	データベース	OC4Jドライバは、データベース・ノードの障害を検出し、使用可能なノードにリクエストを再ルーティングできます。

2.4 OracleAS Cluster

Oracle Application Serverは、様々なタイプのクラスタリングをサポートしています。この項では、OracleAS Clusterについて説明します。アプリケーションレベルのクラスタリングの詳細は、第2.2項「状態情報のレプリケーション」を参照してください。

OracleAS Cluster内のOracle Application Serverインスタンスはグループ化できます。OracleAS Clusterには次のような利点があります。

• アクティブ/アクティブ・トポロジでは、1つのクラスタ内のOracle Application Serverインスタンスをグループ化し、1つのトポロジのOracle HTTP Serverインスタンスが、同じトポロジ内にある他のOC4Jインスタンスを認識できるようにする必要があります。これらのインスタンスは、Oracle HTTP Serverがアプリケーション・リクエストの転送先として選択できるOC4Jインスタンスです。

  Oracle HTTP Serverがmod_oc4jモジュールに指定されているロード・バランシング・アルゴリズムを適用するとき、アルゴリズムはクラスタ内のOC4Jインスタンスに適用されます。mod_oc4jロード・バランシング・アルゴリズムを設定するには、第3.2.8項「mod_oc4jのロード・バランシング・オプションの設定」を参照してください。

• Oracle Application Serverインスタンスは、opmnctlコマンドの@clusterパラメータを使用して一括管理できます。たとえば、1つのクラスタに属しているすべてのインスタンスのOracle HTTP Serverを停止するには、次のコマンドを使用します。

  > opmnctl @cluster stopproc ias-component=HTTP_Server
  
  

  @clusterパラメータを受け入れるopmnctlコマンドの一覧は、『Oracle Process Manager and Notification Server管理者ガイド』を参照してください。

• 動的なpeer-to-peerレプリケーションでアプリケーションレベルのクラスタリングを使用する場合は、OracleAS Clusterによってクラスタのメンバーが判断されるため、OracleAS Clusterを設定する必要があります。

  peer-to-peerレプリケーションの詳細は、第3.2.2.2項「peer-to-peerレプリケーションの設定」を参照してください。

2.5 外部ロード・バランサ

アクティブ/アクティブ・トポロジの多数のOracle Application Serverインスタンス間でリクエストをロード・バランシングするには、外部ロード・バランサを使用する必要があります。

複数のOracle Application Serverインスタンスがクラスタ化されており、それらの前にロード・バランサが配置されている場合、ロード・バランサはシステムのエントリ・ポイントとなることで、複数のインスタンス構成を隠します。リクエストはクラスタ内のどのインスタンスでも処理できるので、外部ロード・バランサは、クラスタ内の任意のOracle Application Serverインスタンスにリクエストを送信できます。システムの能力は、追加のOracle Application Serverインスタンスを導入することにより、高めることができます。これらのインスタンスを別々のノードにインストールすれば、ノードの障害に備えて冗長性を確保できます。

Oracle Application Serverとともに使用可能な外部ロード・バランサには様々なタイプがあります。表2-3に、これらのタイプの要約を示します。

表2-3    外部ロード・バランサのタイプ 

ロード・バランサのタイプ	説明
ハードウェア・ロード・バランサ	ハードウェア・ロード・バランシングでは、Oracle Application ServerインスタンスのグループまたはOracleAS Web Cache（リリース2（10.1.2））の前にハードウェア・ロード・バランサを配置します。ハードウェア・ロード・バランサは、クライアントには透過的な方法で、Oracle HTTP ServerまたはOracleAS Web Cacheのインスタンスにリクエストをルーティングします。
ソフトウェア・ロード・バランサ	ソフトウェア・ロード・バランサでは、1つのアプリケーション・サーバーに対する複数のコールをインターセプトして、これらのリクエストを冗長なコンポーネントにルーティングするプロセスが使用されます。
Linux用LVSネットワーク・ロード・バランサ	一部のLinuxオペレーティング・システムでは、オペレーティング・システムを使用してネットワーク・ロード・バランシングを実行できます。
Windowsネットワーク・ロード・バランサ（Oracle Application ServerのWindowsバージョンに適用）	一部のWindowsオペレーティング・システムでは、オペレーティング・システムを使用してネットワーク・ロード・バランシングを実行できます。たとえば、Microsoft Advanced Serverでは、NLB機能を使用して、同じ仮想IPアドレスまたはMACアドレスを共有している異なるマシンにリクエストを送信できます。これらのサーバー自体をオペレーティング・システム・レベルでクラスタリングする必要はありません。

外部ロード・バランサの要件

オラクル社は、外部ロード・バランサを提供していません。他社の外部ロード・バランサを使用できます。

ご使用の外部ロード・バランサがOracle Application Serverと連動することを確認するには、外部ロード・バランサが表2-4に示されている要件を満たすことをチェックしてください。

この表に示されている要件の一部を満たす必要がない場合があります。外部ロード・バランサの要件は、考慮されるトポロジと、ロード・バランシングが実行されるOracle Application Serverコンポーネントによって異なります。

表2-4    外部ロード・バランサの要件 

外部ロード・バランサの要件	説明
仮想サーバーおよびポートの構成	外部ロード・バランサで仮想サーバー名とポートを構成できる必要があります。また、仮想サーバー名とポートは次の要件を満たす必要があります。 ロード・バランサで複数の仮想サーバーの構成を許可する必要があります。各仮想サーバーについて、ロード・バランサでは複数のポート上のトラフィック管理を構成できることが必要です。たとえば、OracleAS Clusterでは、ロード・バランサはHTTPおよびHTTPSのトラフィックに対する仮想サーバーとポートを使用して構成する必要があります。 仮想サーバー名はIPアドレスに関連付けられていて、DNSの一部である必要があります。クライアントは仮想サーバー名を使用して外部ロード・バランサにアクセスできることが必要です。
リソースの監視、ポートの監視およびプロセス障害の検出	通知などの方法を使用してサービスおよびノードの障害を検出するように、またOracle Net以外のトラフィックを障害の発生したノードに送ることを停止するように、外部ロード・バランサを設定する必要があります。ご使用の外部ロード・バランサに、障害の自動検出機能がある場合は、それを使用してください。
フォルト・トレラント・モード	ロード・バランサをフォルト・トレラント・モードになるように構成することを強くお薦めします。
その他	トラフィックの転送先のバックエンド・サービスが使用できない場合はコール元のクライアントにただちに戻すようロード・バランサの仮想サーバーを構成することを強くお薦めします。この構成は、クライアント・マシンのTCP/IP設定に基づいてタイムアウトの後にクライアントが切断される場合に適しています。

図2-1は、Oracle Application Serverでのハードウェア・ロード・バランシング・ルーターの配置例を示しています。

図2-1    Oracle Application Serverでのロード・バランシング・ルーターの配置例

画像の説明

ロード・バランシングでは、アクセス・ポイントの提供によってスケーラビリティが向上します。このアクセス・ポイントを通じて、使用可能な多数のインスタンスのいずれかにリクエストがルーティングされます。外部ロード・バランサが機能しているグループにインスタンスを追加すれば、ユーザーの追加に対応できます。

ロード・バランシングでは、最も使用可能度が高いインスタンスにリクエストをルーティングすることにより、可用性が向上します。あるインスタンスが停止した場合、または著しくビジーである場合、外部ロード・バランサは別のアクティブなインスタンスにリクエストを送信できます。

2.6 バックアップとリカバリ

システム・コンポーネントのデータ損失からの保護は、高可用性環境の保持に不可欠です。環境内のすべてのOracle Application Serverインスタンスを定期的にバックアップしてください。

Oracle Application Server環境の完全なバックアップには、次のものが含まれます。

• 中間層のOracleホームにあるすべてのファイルの全体バックアップ（Oracleソフトウェア・ファイルおよび構成ファイルを含む）

• 環境内の各ホストにあるOracleシステム・ファイルの全体バックアップ

• 以前のリリースのOracle Identity Managementを使用している場合は、次の全体バックアップも実行する必要があります。
  • Oracle Identity ManagementのOracleホームのすべてのファイル（Oracleソフトウェア・ファイルと構成ファイルを含む）

  • Oracle Identity Managementによって使用されるOracleAS Metadata Repository

2.6.1 Oracle Application Server Backup and Recovery Tool

Oracleインストールで最も頻繁に変更される重要なファイルは、構成ファイルとデータ・ファイルです。Oracle Application Serverには、これらのファイルをバックアップするためのOracleAS Backup and Recovery Toolが用意されています。

OracleAS Backup and Recovery Toolを使用すると、次のインストール・タイプをバックアップおよびリカバリできます。

• J2EEサーバー

• Oracle HTTP Server

• 統合サーバー（J2EEサーバーとOracle HTTP Server）

OracleAS Backup and Recovery Toolは、Oracle Application Serverをインストールしたときにデフォルトでインストールされます。これは、ORACLE_HOME/backup_restoreディレクトリにインストールされます。

OracleAS Backup and Recovery Toolの詳細は、『Oracle Application Server管理者ガイド』を参照してください。

2.7 障害時リカバリ

障害時リカバリとは、自然災害またはそれ以外の災害によるサイトの壊滅的な障害からシステムをどのように回復できるのかを指します。さらに、システムの計画停止の管理方法も障害時リカバリに含まれます。障害時リカバリを必要とするほとんどの状況において、障害の解決には個々のハードウェアやサブコンポーネントのレプリケーションだけでなく、サイト全体を対象としたレプリケーションを行う必要があります。これは、OracleAS Disaster Recoveryソリューションについても同様です。

最も一般的な構成では、本番サイトをミラー化するスタンバイ・サイトを作成します。通常の運用では、本番サイトがクライアント・リクエストを積極的に処理します。スタンバイ・サイトは、本番サイトがホスティングするアプリケーションおよびコンテンツをミラー化するために維持されています。

2.7.1 Oracle Application Server Guard

OracleAS Guardによって、対応するスタンバイ・サイトで本番サイトのリストアが自動的に行われます。完全なOracle Application Server環境を災害から保護するために、OracleAS Guardによって次の操作が実行されます。

• スタンバイ・サイトのインスタンス化: プライマリ・ファームをミラー化するOracle Application Serverスタンバイ・ファームをインスタンス化します。

• 構成の検証: ファームが、対応するプライマリ・ファームのスタンバイ・ファームとして使用されるための要件を満たしていることを検証します。

• サイトの同期化: 本番サイトとスタンバイ・サイトを同期化します。

  関連項目 第5.4項「OracleAS Guardとasgctlの概要」

2.8 高可用性トポロジ： 概要

Oracle Application Serverは、同じワークロードに対して複数のインスタンスをサポートすることによって冗長性を実現します。これらの冗長トポロジでは、分散ワークロードまたはフェイルオーバー設定、あるいはその両方によって高可用性を実現します。

Oracle Application Serverでは、Oracle Application Serverシステムのエントリ・ポイント（コンテンツ・キャッシュ）からバック・エンド・レイヤー（データソース）までの、リクエストが通過するすべての層を冗長に構成できます。トポロジは、OracleAS Clusterを使用したアクティブ/アクティブ・トポロジにすることも、OracleAS Cold Failover Clusterを使用したアクティブ/パッシブ・トポロジにすることもできます。

次の項では、これらのトポロジの基礎について説明します。

• 第2.8.1項「アクティブ/アクティブ・トポロジ」

• 第2.8.2項「アクティブ/パッシブ・トポロジ: OracleAS Cold Failover Cluster」

• 第2.8.3項「トポロジの要約」

2.8.1 アクティブ/アクティブ・トポロジ

Oracle Application Serverは、そのすべてのコンポーネントに対してアクティブ/アクティブ冗長モデルを提供します。アクティブ/アクティブ・トポロジでは、複数のOracle Application Serverインスタンスが同じワークロードを処理するように構成されます。これらのインスタンスは、同一マシンまたは異なるマシンで実行できます。

これらのインスタンスの前には外部ロード・バランサが配置され、それによって任意のアクティブなインスタンスにリクエストが送信されます。外部ロード・バランサのかわりにソフトウェア・ロード・バランサを実行して、リクエストを分散することもできます。ただし、本番環境ではハードウェア・ロード・バランサの使用をお薦めします。

アクティブ/アクティブ・トポロジの一般的なプロパティは次のとおりです。

• 類似のインスタンス構成

  複数のインスタンスで、同じワークロードまたはアプリケーションを処理する必要があります。一部の構成プロパティにはインスタンス間で類似の値を指定して、これらのインスタンスが同じリクエストに対して同一のレスポンスを返すことができるようにする必要があります。他の構成プロパティには、ローカル・ホスト名情報などのようにインスタンス固有のものもあります。

  1つのインスタンスの構成を変更する場合は、アクティブ/アクティブ・トポロジ内の他のインスタンスにも同一の変更を行ってください。『Oracle Containers for J2EE構成および管理ガイド』の「クラスタおよびOC4Jグループの構成と管理」では、レプリケートするプロパティを含むファイルの一覧を示しています。

• 独立操作

  アクティブ/アクティブ・トポロジ内の1つのOracle Application Serverインスタンスに障害が発生した場合は、クラスタ内の他のインスタンスが引き続きリクエストを処理します。ロード・バランサは、動作中のインスタンスのみにリクエストを送信します。

アクティブ/アクティブ・トポロジの利点は次のとおりです。

• 可用性の向上

  アクティブ/アクティブ・トポロジは、冗長構成です。他のインスタンスが同じリクエストの処理を続行できるので、1つのインスタンスの停止に対する耐性があります。

• スケーラビリティとパフォーマンスの向上

  複数の同一に構成されたインスタンスによって、異なるマシン間およびプロセス間でワークロードを共有できます。トポロジは、リクエスト数が増加するにつれて新しいインスタンスを追加することで、拡大できます。

2.8.2 アクティブ/パッシブ・トポロジ: OracleAS Cold Failover Cluster

Oracle Application Serverは、OracleAS Cold Failover Clusterのすべてのコンポーネントに対してアクティブ/パッシブ・モデルを提供します。OracleAS Cold Failover Clusterトポロジでは、2つのOracle Application Serverインスタンスが同じアプリケーション・ワークロードを処理しますが、アクティブなインスタンスは常に1つになるように構成されます。パッシブなインスタンスはアクティブなインスタンスに障害が発生した場合にのみ実行されます（アクティブになります）。これらのインスタンスはハードウェア・クラスタ内のノードで実行されます。

OracleAS Cold Failover Clusterトポロジの一般的なプロパティは次のとおりです。

• ハードウェア・クラスタ

  OracleAS Cold Failover Clusterトポロジでは、ハードウェア・クラスタ内の、ベンダー・クラスタウェアが実行されているマシンでOracle Application Serverを実行します。

• 共有記憶域

  Oracle Application Serverインスタンス用のOracleホームは、ハードウェア・クラスタ内のマシンが共有する記憶域にインストールします。

  OracleAS Cold Failover Clusterトポロジのアクティブ・ノードは、Oracleホームにアクセスできるように共有記憶域をマウントします。このノードに障害が発生した場合は、パッシブなインスタンスが共有記憶域をマウントし、同じOracleホームにアクセスします。

• 仮想ホスト名

  仮想ホスト名は、Oracle Application Server中間層のシングル・システム・ビューをクライアントに提供します。クライアントは、仮想ホスト名を使用してOracle Application Server中間層にアクセスします。

  仮想ホスト名は、仮想IPに関連付けられています。この名前とIPのエントリは、サイトが使用するDNSに追加する必要があります。たとえば、ハードウェア・クラスタの2つの物理ホスト名がnode1.mycompany.comとnode2.mycompany.comであるとき、このクラスタのシングル・ビューをapps.mycompany.comという仮想ホスト名で示すことができます。DNSでは、appsはハードウェア・クラスタを経由してnode1とnode2間で浮動する仮想IPアドレスにマップします。クライアントはapps.mycompany.comを使用してOracle Application Serverにアクセスします。どの物理ノードがアクティブになっていて、特定のリクエストを実際に処理しているかはクライアントにはわかりません。

  インストール時には仮想ホスト名を指定できます。Oracle Application Serverのインストレーション・ガイドを参照してください。

• フェイルオーバー・プロシージャ

  アクティブ/パッシブ構成には、アクティブ・インスタンスの障害を検出し、停止時間を最小限に抑えてパッシブ・インスタンスにフェイルオーバーするための一連のスクリプトとプロシージャも含まれています。

OracleAS Cold Failover Clusterトポロジの利点は次のとおりです。

• 可用性の向上

  アクティブ・インスタンスになんらかの理由で障害が発生したか、オフラインにする必要がある場合はいつでも、同一に構成されたパッシブ・インスタンスが引き継ぐことができます。

• 運用コストの削減

  アクティブ/パッシブ・トポロジでは、起動していてリクエストを処理しているのは1つのセットのプロセスのみです。通常、1つのアクティブ・インスタンスの管理には、一連のアクティブ・インスタンスの管理ほど手間がかかりません。

• アプリケーションの独立性

  アクティブ/アクティブ・トポロジに適していないアプリケーションもあります。アプリケーションの状態や、ローカルに保存されている情報に対する依存度が高いアプリケーションなどです。アクティブ/パッシブ・トポロジでは、リクエストを処理しているインスタンスは常に1つのみです。

2.8.3 トポロジの要約

表2-5に、Oracle HTTP Server、WebCenter FrameworkおよびOracle Content DBコンポーネントの高可用性トポロジの要約を示します。この後の章では、トポロジが詳しく説明されています。

表2-5    高可用性トポロジの要約 

	アクティブ/アクティブ・トポロジ	アクティブ/パッシブ・トポロジ
同じOracleホームのOracle HTTP Server、WebCenter FrameworkおよびOracle Content DB	Oracle HTTP Server、WebCenter FrameworkおよびOracle Content DB: 2つ以上のノードを配置し、各ノードでOracle HTTP Server、WebCenter FrameworkおよびOracle Content DBを実行します。これらのコンポーネントは、各ノード上の同じOracleホームにインストールします。 ロード・バランサをこれらのノードの前に配置して、ノード間のトラフィックを分散させます。 WebCenter FrameworkおよびOracle Content DBのOC4Jインスタンスは、OracleAS Clusterでクラスタリングします。 Oracle Content DBのデータベース: Real Application Clustersデータベース。データベースは、個別にインストールします。 このトポロジの詳細は、第3.1.4項「同じ場所に配置したトポロジ: コンポーネントを同じOracleホームに配置」を参照してください。	Oracle HTTP Server、WebCenter FrameworkおよびOracle Content DB: ハードウェア・クラスタ内に2つのノードを配置し、それら2つのノード用に共有記憶域を1つ配置します。ノードの一方はアクティブで、他方はパッシブです。ハードウェア・クラスタは、仮想ホスト名と仮想IPアドレスに関連付けられています。 共有記憶域には、Oracle HTTP Server、WebCenter FrameworkおよびOracle Content DBのOracleホームがあります。 Oracle Content DBのデータベース:コールド・フェイルオーバー・クラスタ・データベースまたはReal Application Clustersデータベース。データベースは、個別にインストールします。 このトポロジの詳細は、第4.1.6項「同じ場所に配置したトポロジ: コンポーネントを同じOracleホームに配置」を参照してください。
異なるOracleホームのOracle HTTP Server、WebCenter FrameworkおよびOracle Content DB	Oracle HTTP Server: Oracle HTTP Serverは、Web層のノードにインストールされます。Oracle HTTP Serverは、アクティブ/アクティブまたはアクティブ/パッシブのいずれかのモードで実行できます。 ロード・バランサをこれらのノードの前に配置して、ノード間のトラフィックを分散させます。 WebCenter FrameworkおよびOracle Content DB: WebCenter FrameworkとOracle Content DBは、アプリケーション層のノードにインストールされます。 WebCenter FrameworkおよびOracle Content DBのOC4Jインスタンスは、Oracle HTTP ServerインスタンスとともにOracleAS Clusterでクラスタリングします。 各層には、2つ以上のノードを配置します。 Oracle Content DBのデータベース: Real Application Clustersデータベース。データベースは、個別にインストールします。 このトポロジの詳細は、第3.1.5項「分散トポロジ: Oracle HTTP Server、WebCenter FrameworkおよびOracle Content DBを個別のOracleホームに配置」を参照してください。	Oracle HTTP Server: Oracle HTTP Serverは、Web層のノードにインストールされます。Oracle HTTP Serverは、アクティブ/アクティブまたはアクティブ/パッシブのいずれかのモードで実行できます。 WebCenter FrameworkおよびOracle Content DB: WebCenter FrameworkとOracle Content DBは、アプリケーション層のノードにインストールされます。 ハードウェア・クラスタ内に2つのノードを配置し、それら2つのノード用に共有記憶域を1つ配置します。ノードの一方はアクティブで、他方はパッシブです。ハードウェア・クラスタは、仮想ホスト名と仮想IPアドレスに関連付けられています。 共有記憶域には、WebCenter FrameworkとOracle Content DBのOracleホームがあります。 Oracle Content DBのデータベース:コールド・フェイルオーバー・クラスタ・データベースまたはReal Application Clustersデータベース。データベースは、個別にインストールします。 このトポロジの詳細は、第4.1.7項「分散トポロジ: Oracle HTTP Server、WebCenter FrameworkおよびOracle Content DBを個別のOracleホームに配置」を参照してください。