10g リリース3（10.1.3.2.0） for Linux x86
E05049-01
 目次 |
 索引 |
| Oracle Application Serverインストレーション・ガイド 10g リリース3（10.1.3.2.0） for Linux x86 E05049-01 |
|
この章では、Oracle Application Serverでサポートされている高可用性構成の概要とインストール手順について説明します。
この章の内容は次のとおりです。
この章では、Oracle Application Serverでの高可用性構成の概要のみを説明します。構成の詳細は、『Oracle Application Server高可用性ガイド』を参照してください。
Oracle Application Serverがインストール時にサポートする高可用性構成のタイプは次のとおりです。それぞれのタイプには複数のバリエーションがあることに注意してください。
高可用性構成の比較一覧は、6.1.4項「相違の概要」を参照してください。
Oracle Application Serverでは、そのすべてのコンポーネントに対してアクティブ-アクティブな冗長モデルが提供されます。アクティブ-アクティブ・トポロジでは、2つ以上のOracle Application Serverインスタンスが同じワークロードを処理するように構成されます。これらのインスタンスは、同じマシン上で実行することも、別のマシン上で実行することもできます。
これらのインスタンスのフロントエンドには外部のロード・バランサが配置され、このロード・バランサによって、任意のアクティブなインスタンスにリクエストが送信されます。外部のロード・バランサではなく、ソフトウェア・ロード・バランサを実行してリクエストを分散することもできます。ただし、本番環境ではハードウェア・ロード・バランサの使用をお薦めします。
アクティブ-アクティブ・トポロジの一般的なプロパティは次のとおりです。
各インスタンスは、同じワークロードまたはアプリケーションを処理する必要があります。一部の構成プロパティでは、各インスタンスが同じリクエストに対して同じリプライを配信できるように、インスタンス全体で類似した値が使用されます。その他の構成プロパティでは、ローカル・ホスト名情報のようにインスタンス固有の値が使用されます。
1つのインスタンスの構成を変更する場合は、そのアクティブ-アクティブ・トポロジ内の他のインスタンスにも同じ変更を加える必要があります。『Oracle Containers for J2EE構成および管理ガイド』の「クラスタの構成と管理」に、レプリケートされるプロパティを含むファイルが記載されています。
アクティブ-アクティブ・トポロジ内の1つのOracle Application Serverインスタンスで障害が発生しても、クラスタ内の他のインスタンスがリクエストの処理を続行します。ロード・バランサは、動作中のインスタンスにのみリクエストを送信します。
アクティブ-アクティブ・トポロジの利点は次のとおりです。
アクティブ-アクティブ・トポロジは、冗長構成です。1つのインスタンスを失っても、他のインスタンスが同じリクエストを継続して処理できます。
同一の構成を持つ複数のインスタンスは、異なるマシンおよびプロセス間でワークロードを共有する機能を備えています。リクエスト数の増加に応じてインスタンスを新規に追加することにより、トポロジの規模を変更できます。
OracleAS Cluster構成の作成方法については、6.3項「アクティブ-アクティブ・トポロジの作成」を参照してください。
Oracle Application Serverでは、OracleAS Cold Failover Cluster環境のすべてのコンポーネントでアクティブ-パッシブ・モデルを利用できます。OracleAS Cold Failover Clusterトポロジでは、2つのOracle Application Serverインスタンスが同じアプリケーションのワークロードを処理するように構成されますが、常に一方のインスタンスのみがアクティブになります。パッシブなインスタンスは、アクティブなインスタンスに障害が発生した場合にのみ実行されます（つまり、アクティブになります）。これらのインスタンスは、ハードウェア・クラスタ内のノードで実行されます。
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つのインスタンスのみがリクエストを処理します。
OracleAS Cold Failover Cluster構成の作成方法については、6.4項「アクティブ-パッシブ・トポロジの作成」を参照してください。
OracleAS Disaster Recovery構成には、次の特性があります。
詳細は、6.5項「OracleAS Disaster Recovery構成の作成」を参照してください。
表6-1に、高可用性構成間の相違の概要を示します。
この項では、すべての高可用性構成に共通の要件を説明します。これらの共通の要件に加えて、各構成には固有の要件があります。詳細は、それぞれの章を参照してください。
共通の要件は次のとおりです。
高可用性構成には、2つ以上のノードが必要です。なんらかの理由でノードに障害が発生した場合、2番目のノードが引き継ぎます。
クラスタ内のすべてのノードの/etc/groupファイルに、使用するオペレーティング・システム・グループが含まれていることを確認します。oraInventoryディレクトリ用に1つのグループ、データベース管理用に1つまたは2つのグループが必要です。グループ名およびグループIDは、すべてのノードで同じである必要があります。
詳細は、2.8項「オペレーティング・システム・グループ」を参照してください。
Oracle Application Serverをインストールするためのログインに使用するoracleオペレーティング・システム・ユーザーに次のプロパティがあることを確認します。
oinstallグループおよびosdbaグループに属している。oinstallグループはoraInventoryディレクトリ用で、osdbaグループはデータベース管理グループです。詳細は、2.8項「オペレーティング・システム・グループ」を参照してください。
高可用性構成でインストールするすべてのノードに、既存のoraInventoryディレクトリがないことを確認します。
すべてのOracleソフトウェアのインストールの詳細は、Oracle Installer Inventoryディレクトリに記録されます。通常、このディレクトリはノードに対して一意であり、oraInventoryという名前が付けられています。Oracle Installer Inventoryディレクトリのディレクトリ・パスは、oraInst.locファイルに格納されています。
このファイルがノードに存在することにより、ノードになんらかのOracleソフトウェアのインストールが含まれることが確認できます。高可用性構成では、他のノードではアクセスできない可能性のあるファイル・システムのOracle Installer Inventoryディレクトリを含む複数のノードへのインストールが必要であるため、この章以降のインストール手順では、この高可用性構成で使用されるすべてのノードに、Oracleソフトウェアの以前のインストールはまったくなかったものとします。oraInst.locファイルとOracle Installer Inventoryディレクトリは、高可用性環境をインストールする前にこれらのノードに存在していてはいけません。
インストーラによって検出される可能性があるoraInventoryディレクトリがノードにあるかどうかを確認するには、次の手順を実行します。
oraInst.locファイルが存在するかどうかを確認します。このファイルは/etcディレクトリにあります。ノードにこのファイルがない場合、インストーラによって使用されるoraInventoryディレクトリはありません。次のノードを確認できます。
oraInst.locファイルが存在する場合は、このファイルおよびoraInventoryディレクトリの名前を変更します。その結果、インストーラによって新しいoraInventoryディレクトリの場所を入力するように要求されます。たとえば、rootとして次のコマンドを入力します。
# cat /etc/oraInst.loc inventory_loc=/localfs/app/oracle/oraInventory inst_group=dba # mv /etc/oraInst.loc /etc/oraInst.loc.orig # mv /localfs/app/oracle/oraInventory /localfs/app/oracle/oraInventory.orig
oraInst.locファイルとOracle Installer InventoryディレクトリはOracleソフトウェアのインストール時にのみ必要であり、実行時には必要ないため、後でこれらの名前の変更やリストアを実行しても、ノードにインストールされたOracleソフトウェアの動作には影響はありません。Oracle Universal Installerを開始する前に、適切なoraInst.locファイルとOracle Installer Inventoryディレクトリが正しく配置されていることを確認してください。
この項では、OracleAS Clusterを使用したアクティブ-アクティブ・トポロジにOracle Application Serverをインストールする方法について説明します。OracleAS Clusterは、Oracle Application Serverがサポートする高可用性環境の1つです。
この項の内容は次のとおりです。
アクティブ-アクティブ・トポロジは、単一インスタンスよりもスケーラビリティと可用性が強化された冗長なOracle Application Serverインスタンスで構成されています。アクティブ-アクティブ・トポロジでは、単一インスタンスで発生するシングル・ポイント障害が排除されます。単一のOracle Application Serverインスタンスでは単一ホストのリソースが利用されるのに対し、Oracle Application Serverインスタンスのクラスタでは複数のホストのリソースが使用され、より多くのCPUにアプリケーションの実行が分散されます。単一のOracle Application Serverインスタンスは、そのホストとオペレーティング・システムの障害に対して脆弱ですが、アクティブ-アクティブ・トポロジは、オペレーティング・システムやホストで障害が発生しても継続して機能し、その障害をクライアントから見えなくします。
アクティブ-アクティブ・トポロジでは、すべてのインスタンスが同時にアクティブになります。これが、常に1つのインスタンスのみがアクティブなアクティブ-パッシブ・トポロジとの相違点です。
アクティブ-アクティブ・トポロジのノードは、ハードウェア・クラスタに属しません。
アクティブ-アクティブ・トポロジでは、ロード・バランサによってトポロジ内のOracle Application Serverインスタンスの1つにリクエストが送信されます。つまり、ロード・バランサがOracle Application Serverインスタンスの前に配置されています。
ロード・バランサの構成時に、HTTPおよびHTTPSトラフィック用の仮想サーバー名を指定します。クライアントは、この仮想サーバー名を使用してリクエストを送信します。ロード・バランサは、利用可能なOracle Application Serverインスタンスにリクエストを送信します。
ロード・バランサで利用できる機能のリストは、『Oracle Application Server高可用性ガイド』を参照してください。
各ノード上のローカル・ドライブの他に、アクティブ-アクティブ・トポロジ内のすべてのノードからアクセス可能な共有記憶域が必要です。共有記憶域には、Oracle Metadata Services（MDS）用のディレクトリを作成する必要があります。MDSディレクトリには、デプロイされたアプリケーションに関するデータが格納されます。
共有記憶域にMDSディレクトリを作成することによって、すべてのOracle Application Serverインスタンスが同じデータにアクセスするため、データをレプリケートする必要がなくなります。
MDSディレクトリのマウント・ポイントは、アクティブ-アクティブ・トポロジ内のすべてのノードで同じである必要があります（たとえば、/oracle/mdsなどです）。
共有記憶域は、インストール時には必要ありませんが、アプリケーションのデプロイ時に必要となります。アプリケーションのデプロイ時に、MDSディレクトリへのパスを指定します。
次の図は、2つのアクティブ-アクティブ・トポロジを示しています。この2つのトポロジは、Oracle HTTP Server、Oracle WebCenter FrameworkおよびOracle Content DBを同じOracleホームにインストールするか、別々のOracleホームにインストールするかという点が異なります。
図6-1は、Oracle HTTP Server、Oracle WebCenter FrameworkおよびOracle Content DBを同じOracleホームにインストールしたアクティブ-アクティブ・トポロジを示しています。図6-2は、Oracle HTTP Server、Oracle WebCenter FrameworkおよびOracle Content DBを別々のOracleホームにインストールしたアクティブ-アクティブ・トポロジを示しています。
アクティブ-アクティブ・トポロジ内のOracle Application Serverインスタンスはすべて同じクラスタに属します。Oracle HTTP Serverは、同じクラスタ内のすべてのOC4Jインスタンスにアプリケーションのリクエストを転送できます。Oracle WebCenter FrameworkおよびOracle Content DBコンポーネントはOC4Jコンテナで実行されるため、この機能が役に立ちます。
| コンポーネント | 実行場所となるOC4Jインスタンス |
|---|---|
|
Oracle WebCenter Framework |
OC4J_WebCenter |
|
Oracle Content DB |
OC4J_WebCenter |
次のいずれかの方法を使用して、クラスタ内のインスタンスをグループ化できます。
opmn.xml構成ファイルで指定する。
OracleAS Clusterでは、一部のopmnctlコマンドで@clusterパラメータを使用することもできます。@clusterパラメータを使用するコマンドは、クラスタ内のすべてのインスタンスに適用されます。たとえば、@clusterパラメータを使用して、クラスタ内の全インスタンスのすべてのコンポーネントを起動できます。
クラスタのOC4Jインスタンスには、次の機能があります。
詳細は、『Oracle Containers for J2EE構成および管理ガイド』の「クラスタの構成と管理」を参照してください。
ロード・バランサはトポロジ内の任意のOracle Application Serverインスタンスにリクエストを送信できるため、リクエストを処理するインスタンスに関係なくクライアントが同じレスポンスを受信できるように、同じ方法でインスタンスを構成する必要があります。この方法の例を次に示します。
図6-1または図6-2に示すトポロジを作成するには、次の手順を実行します。
手順2: Oracle HTTP Server、Oracle WebCenter FrameworkおよびOracle Content DBのインストールとOPMNを使用したインスタンスのクラスタ化
手順3: Oracle Content DBが含まれているノード上のOracle HTTP Serverの無効化（分散インストールのみ）
手順6: Oracle Content DBのドメイン・プロパティの更新
次の各項で、手順について詳しく説明します。
Oracle Content DB用のデータベースが必要です。高可用性トポロジでは、コールド・フェイルオーバー・クラスタ・データベース、Real Application Clustersデータベースなどの高可用性データベースを使用する必要があります。
Oracle Content DBのデータベース要件の詳細は、2.5項「Oracle Content Databaseの要件」を参照してください。
Oracle HTTP Server、Oracle WebCenter FrameworkおよびOracle Content DBは、同じOracleホームにインストールすること（図6-1を参照）も、別のOracleホームにインストールすること（図6-2を参照）もできます。
同一のアクティブ-アクティブ・トポロジにグループ化するOracle Application Serverインスタンスは、同じクラスタにデプロイする必要があります。これにより、Oracle HTTP ServerとOC4Jインスタンス間の通信が可能になり、Oracle Application Serverインスタンスの管理が簡素化されます。OracleAS Clusterでは、@clusterパラメータをopmnctlコマンドで使用して、クラスタ内のすべてのインスタンスを管理できます。
次のいずれかの方法でクラスタを作成できます。
この方法では、同一サブネット内の各ONSノードは、マルチキャスト・メッセージによってその存在を通知します。各ノードのクラスタ・トポロジ・マップは、ノードが追加または削除されると自動的に更新され、クラスタの自己管理を可能にします。
基本インストールの実行中にこの方法を使用する場合は、6.3.5.1項「動的検出方法によるクラスタの設定」の手順に従って、インストール後にクラスタを定義できます。拡張インストールの実行中にこの方法を使用する場合は、インストーラの「クラスタ・トポロジ構成」画面でマルチキャスト・アドレスおよびポートを指定する必要があります。
この方法では、検出サーバーとして機能するようにクラスタ内の特定のノードが構成されます。これにより、クラスタのトポロジ・マップが保持され、他のノードはこのサーバーを経由して相互に接続されます。
この方法を使用する場合は、インストール後に6.3.5.2項「検出サーバー方法によるクラスタの設定」の手順に従って、各インスタンスのopmn.xmlファイルでOracle Application Serverインスタンスの名前を明示的に指定することにより、OPMNのクラスタを定義できます。
この構成は、指定されたゲートウェイ・ノードを使用して、ファイアウォールで切り離されているトポロジや異なるサブネット上にあるトポロジを接続するために使用されます。
この方法を使用する場合は、構成の詳細について『Oracle Containers for J2EE構成および管理ガイド』のトポロジ間のゲートウェイ構成に関する項を参照してください。
統合インストールまたは分散インストールを実行できます。
アクティブ-アクティブ・トポロジの各ノードのローカル記憶域にOracle Application Serverをインストールします。
第4章「基本インストール」の手順に従って基本インストールを実行します。これによって、Oracle HTTP Server、Oracle WebCenter FrameworkおよびOracle Content DBが同じOracleホームから実行されます。
次の点に注意してください。
oc4jadminパスワードを同じにする必要があります。
アクティブ-アクティブ・トポロジの各ノードのローカル記憶域にOracle Application Serverをインストールします。
Oracle HTTP Serverを実行するノードでは、5.2.5項「Oracle HTTP Serverのインストール」の手順を実行します。
Oracle WebCenter FrameworkおよびOracle Content DBを実行するノードでは、次の2つのタイプのインストールを各ノードで実行する必要があります。
インストール時に、次のオプションを選択します。
マルチキャスト・アドレスは224.0.1.0〜239.255.255.255の間で指定する必要があります。クラスタ内の最初のノードにインストールする場合は、任意のIPアドレスとポートをマルチキャスト・アドレスの範囲内で選択できます。
次の点に注意してください。
oc4jadminパスワードを同じにする必要があります。
この手順は、手順2で分散インストールを実行した場合にのみ実行する必要があります。
Oracle Content DBをインストールしたOracleホーム上のOracle HTTP Serverを無効にします。
ORACLE_HOME/opmn/conf/opmn.xmlファイルでOracle HTTP Serverのステータスをdisabledに設定します。
<ias-component id="HTTP_Server" status="disabled">
> ORACLE_HOME/bin/opmnctl stopall > ORACLE_HOME/bin/opmnctl startall
構成手順については、ロード・バランサのドキュメントを参照してください。ロード・バランサで、HTTPトラフィック用に仮想サーバー名とポートを構成し、さらにHTTPSトラフィック用に別の仮想サーバー名とポートを構成する必要があります。仮想サーバー名のポート番号は、Oracle HTTP Serverがリスニングしているポート番号と一致している必要があります。クライアントは、この仮想サーバー名とポートを使用してOracle Application Serverインスタンスにアクセスします。
この手順は、SSLを使用している場合にのみ実行する必要があります。
各ノードでORACLE_HOME/Apache/Apache/conf/httpd.confファイルを次のように編集します。
httpd.confに次の行を追加してcertheaders_moduleをロードします。
LoadModule certheaders_module libexec/mod_certheaders.so
<VirtualHost *:7777> ServerName myworkplace.com Port 443 ServerAdmin you@youraddress.com RewriteEngine On RewriteOptions inherit SimulateHTTPS On </VirtualHost>
各ノードでApplication Server Controlを使用して次のドメイン・プロパティを更新します。
IFS.DOMAIN.APPLICATION.ApplicationHost: ロード・バランサに構成されている仮想ホスト名に設定します。
IFS.DOMAIN.APPLICATION.ApplicationPort: ロード・バランサに構成されているポート番号に設定します。
Application Server Controlを使用してこれらのプロパティを編集するには、次の手順を実行します。
IFS.DOMAIN.APPLICATION.ApplicationHost」プロパティをクリックし、その値をロード・バランサに構成されている仮想ホスト名に設定します。「OK」をクリックします。
IFS.DOMAIN.APPLICATION.ApplicationPort」プロパティをクリックし、その値をロード・バランサに構成されているポート番号に設定します。「OK」をクリックします。
各ノードでOPMNをリロードします。
> ORACLE_HOME/opmn/bin/opmnctl reload
この項では、アクティブ-アクティブ・トポロジの保持に必要な一般的な手順について説明します。
この方法では、クラスタ内の各Oracle Application Serverインスタンスに同じマルチキャスト・アドレスおよびポートを定義します。この方法には、クラスタ内の各Oracle Application Serverインスタンスの名前を指定する必要がなくなるという利点があります。マルチキャスト・アドレスおよびポートを編集することによって、クラスタに対してインスタンスの追加または削除を行うことができます。
opmnctl config topology update discover="*<multicastAddress>:<multicastPort>"
multicastAddressには、このクラスタで使用するマルチキャスト・アドレスを指定します。マルチキャスト・アドレスは、224.0.1.0〜239.255.255.255の有効なアドレス範囲内である必要があります。前述のコマンドのマルチキャスト・アドレスの前に*文字が付けられていることに注意してください。
multicastPortには、未使用の任意のポート番号を指定できます。
例:
> ORACLE_HOME/opmn/bin/opmnctl config topology update discover="*225.0.0.20:8001"
分散インストール（Oracle HTTP ServerおよびOC4Jを別々のOracleホームにインストール）では、すべてのOracle Application Serverインスタンスを同じクラスタにクラスタ化する必要があります。すべてのインスタンスで同じマルチキャストIPおよびポートを使用する必要があります。
opmnctl config topology updateコマンドを実行したそれぞれのOracle Application Serverインスタンスに対してopmnctl reloadコマンドを実行し、更新されたopmn.xmlファイルをOPMNに読み込みます。
> ORACLE_HOME/opmn/bin/opmnctl reload
マルチキャスト方法を使用しない場合は、Oracle Application Serverインスタンスを実行するノードの名前を各インスタンスのopmn.xmlファイルで指定することにより、クラスタを定義できます。
たとえば、4つのインスタンス（inst1.node1.mycompany.com、inst2.node2.mycompany.com、inst3.node3.mycompany.com、inst4.node4.mycompany.com）をクラスタ化する場合は、次の手順を実行します。
この例では、inst1.node1.mycompany.comとinst2.node2.mycompany.comがクラスタの検出サーバーであると想定します。
分散インストール（Oracle HTTP ServerとOC4Jを別々のOracleホームにインストール）では、Oracle HTTP ServerまたはOC4Jを実行しているすべてのインスタンスが検出サーバーとして機能できます。
opmn.xmlファイルで、検出サーバー（この例ではnode1.mycompany.comとnode2.mycompany.com）を実行するノードを指定します。この例では、opmn.xmlファイルが変更されて次の各行が挿入されます。
<notification-server> <topology> <discover list="node1.mycompany.com:6201,node2.mycompany.com:6201"/> </topology> ... </notification-server>
6201は通知サーバーがリスニングを行うポート番号を表します。この値は、そのインスタンスのopmn.xmlファイルに格納されています。
複数の検出サーバーを使用する場合は、各サーバーをカンマで区切ります。
opmnctl reloadを実行し、OPMNに更新済のopmn.xmlファイルを読み取らせます。
> ORACLE_HOME/opmn/bin/opmnctl reload
この項では、OracleAS Cold Failover Clusterを使用したアクティブ-パッシブ・トポロジにOracle Application Serverをインストールする方法について説明します。OracleAS Cold Failover Clusterは、Oracle Application Serverがサポートする高可用性環境の1つです。
この項の内容は次のとおりです。
アクティブ-パッシブ・トポロジは、次のコンポーネントで構成されます。
Oracleホームは共有記憶域にインストールします。アクティブ-パッシブ・トポロジの実行時には、1つのノードのみがアクティブになります。もう1つのノードはパッシブになります。アクティブ・ノードは共有記憶域をマウントすることにより、ファイルにアクセスしてすべてのプロセスを実行し、すべてのリクエストを処理します。クライアントは、仮想ホスト名を介してアクティブ・ノードにアクセスします。クライアントは、トポロジ内のノードの物理的なホスト名を認識する必要はありません。
なんらかの理由によりアクティブ・ノードに障害が起きると、フェイルオーバー・イベントが発生し、パッシブ・ノードが引き継いでアクティブ・ノードとなります。このノードは共有記憶域をマウントしてすべてのプロセスを実行し、すべてのリクエストを処理します。仮想ホスト名とIPは、このパッシブ・ノードを指すようになります。クライアントは仮想ホスト名を使用してノードにアクセスするため、そのリクエストを処理しているのがパッシブ・ノードであることを認識しません。
フェイルオーバーを可能にするには、ノードがハードウェア・クラスタに属している必要があります。
アクティブ-パッシブ・トポロジの2つのノードはハードウェア・クラスタに属します。通常、このハードウェア・クラスタにはベンダー・クラスタウェアが含まれています。動作が保証されているクラスタウェアのリストは、OTN（Oracle Technology Network）のWebサイト（http://www.oracle.com/technology）にあります。
これらの製品は、トポロジ内の両方のノード（アクティブとパッシブ）にインストールする必要があります。
共有記憶域には、Oracle Metadata Services（MDS）用のディレクトリも作成する必要があります。MDSディレクトリには、デプロイされたアプリケーションに関するデータが格納されます。
共有記憶域にMDSディレクトリを作成することによって、すべてのOracle Application Serverインスタンスが同じデータにアクセスするため、データをレプリケートする必要がなくなります。
MDSディレクトリのマウント・ポイントは、アクティブ-パッシブ・トポロジ内のすべてのノードで同じである必要があります（たとえば、/oracle/mdsなどです）。
共有記憶域は、インストール時には必要ありませんが、アプリケーションのデプロイ時に必要となります。アプリケーションのデプロイ時に、MDSディレクトリへのパスを指定します。
図6-3は、Oracle Application ServerのOracleホームを共有記憶域にインストールしたアクティブ-パッシブ・トポロジの図を示しています。このOracleホームには、Oracle HTTP ServerおよびWebCenter Suiteの両方が格納されています。図6-4は、分散型のアクティブ-パッシブ・トポロジを示しています。ここでは、Oracle HTTP Server、Oracle WebCenter FrameworkおよびOracle Content DBが別々のOracleホームにインストールされています。このトポロジは、ノードがWeb層とアプリケーション層に分けられ、それらの層内のノードがファイアウォールで分離されている場合に使用できます。
MDSディレクトリは、共有記憶域に構成する必要があります。
表6-3の手順に従ってOracleAS Cold Failover Cluster構成を作成します。Oracle HTTP ServerとOC4Jを同じOracleホームにインストールする場合は（図6-3）、ハードウェア・クラスタでこの手順を実行します。Oracle HTTP ServerとOC4Jを別々のOracleホームにインストールする場合は（図6-4）、両方のハードウェア・クラスタでそれぞれの手順を実行します。
| 手順 | 説明 | |
|---|---|---|
|
1. |
インストール前の作業の詳細は、6.4.3項を参照してください。内容は次のとおりです。 |
|
|
2. |
Oracle Content DB用の高可用性データベースをインストールします。 |
|
|
3. |
VIRTUAL_HOST_NAME変数を仮想ホスト名に設定します。 |
|
|
4. |
この手順では、ハードウェア・クラスタのいずれかのノードからインストーラを実行して共有ディスクにOracle Content DB、Oracle WebCenter FrameworkおよびOracle HTTP Serverをインストールします。 |
|
|
5. |
Oracle Application ServerインスタンスでSSLを使用する場合は、Oracle Application ServerインストールでSSLを有効にします。 |
|
|
6. |
OracleAS JMSを使用する場合は、共有ディスクでファイル・システムを作成します。 |
Oracle Application ServerをOracleAS Cold Failover Clusterにインストールする前に、次の手順を実行します。
OracleAS Cold Failover Cluster構成内の各ノードは、独自の物理IPアドレスに関連付けられます。また、クラスタ内のアクティブ・ノードは、仮想ホスト名と仮想IPアドレスに関連付けられています。これによって、クライアントは仮想ホスト名を使用してOracleAS Cold Failover Clusterにアクセスできます。
仮想ホスト名と仮想IPアドレスは、ハードウェア・クラスタを含むサブネットのコンテキスト内で有効な任意のホスト名およびIPアドレスです。
次の例では、vhost.mydomain.comという仮想ホスト名を138.1.12.191の仮想IPを使用して構成します。
たとえば、vhost.mydomain.com/138.1.12.191の組合せをDNSに登録します。
通常、Ethernetカプセル化のプライマリ・パブリック・ネットワーク・インタフェースはeth0です。次のコマンドを使用して、そのノードで物理IPアドレスのinet addrの値を持つネットワーク・インタフェースを検索します。
/sbin/ifconfig
たとえば、/sbin/ifconfigコマンドの出力が次のようになり、手順2でeth0がプライマリ・パブリック・インタフェースだと確認された場合、追加のIPアドレスにはeth0:1が使用できます。
eth0 Link encap:Ethernet HWaddr 00:B0:D0:68:B4:3D inet addr:130.35.137.46 Bcast:130.35.139.255 Mask:255.255.252.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:608598569 errors:8 dropped:0 overruns:0 frame:8 TX packets:578257570 errors:111 dropped:0 overruns:0 carrier:111 collisions:0 txqueuelen:100 RX bytes:2407934851 (2296.3 Mb) TX bytes:3386476912 (3229.5 Mb) Interrupt:26 Base address:0xe0c0 Memory:fbefc000-fbefc038 eth1 Link encap:Ethernet HWaddr 00:02:B3:28:80:8C inet addr:10.0.0.1 Bcast:10.255.255.255 Mask:255.0.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:781415 errors:0 dropped:0 overruns:0 frame:0 TX packets:725511 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:280473135 (267.4 Mb) TX bytes:254651952 (242.8 Mb) Interrupt:23 Base address:0xccc0 Memory:fabff000-fabff038 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:114185902 errors:0 dropped:0 overruns:0 frame:0 TX packets:114185902 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:2307872746 (2200.9 Mb) TX bytes:2307872746 (2200.9 Mb)
/sbin/ifconfig <primary_public_interface>:<available_index> <virtual_ip_address> netmask <netmask_value> up
たとえば、eth0:1が使用可能な場合は次のコマンドを入力します。
/sbin/ifconfig eth0:1 138.1.12.191 up
アクティブ・ノードに障害が発生すると、パッシブ・ノードが引き継ぎます。障害が発生したノードからパッシブ・ノードへ仮想IPをマップするクラスタウェア・エージェントがない場合は、手動で行う必要があります。次の手順を実行して、障害が発生したノードから仮想IPマッピングを削除し、パッシブ・ノードにマップする必要があります。
/sbin/ifconfig configured_interface down
たとえば、eth0:1に仮想IPアドレスが構成されている場合は次のコマンドを入力します。
/sbin/ifconfig eth0:1 down
ハードウェア・クラスタには共有記憶域がありますが、OracleAS Cold Failover Clusterの両方のノードがこのファイル・システムをマウントできるようにこの共有記憶域にファイル・システムを作成する必要があります。次のディレクトリでは、このファイル・システムを使用します。
ディスク領域の要件については、2.2項「システム要件」を参照してください。
クラスタ上でボリューム・マネージャを実行して共有記憶域を管理する場合のボリュームを作成する手順については、ボリューム・マネージャのドキュメントを参照してください。ボリュームを作成すると、そのボリューム上にファイル・システムを作成できます。
ボリューム・マネージャがない場合は、共有ディスク上に直接ファイル・システムを作成できます。ハードウェアのベンダーがこの機能をサポートしていること、OracleAS Cold Failover Clusterのいずれかのノードからファイル・システムがマウントできること、およびノードに障害が発生した場合にいずれかのノードからファイル・システムが修復できることを確認します。
ファイル・システムをいずれかのノードからマウントできることを確認するには、次の手順を行います。
この項では、OracleAS Cold Failover Clusterをインストールする手順について説明します。
Oracle HTTP ServerとOC4Jを別々のOracleホームにインストールする場合は、両方のクラスタでそれぞれの手順を実行します。
6.4.3項「OracleAS Cold Failover Clusterのインストール前の手順」に記載されているインストール前の手順を実行します。
Oracle Content DB用のデータベースが必要です。高可用性トポロジでは、コールド・フェイルオーバー・クラスタ・データベース、Real Application Clustersデータベースなどの高可用性データベースを使用する必要があります。
Oracle Content DBのデータベース要件の詳細は、2.5項「Oracle Content Databaseの要件」を参照してください。
ハードウェア・クラスタのいずれかのノードで環境変数VIRTUAL_HOST_NAMEを仮想ホスト名に設定します。次の手順で、このノードから共有ディスクにインストールを実行します。環境変数の設定方法の詳細は、2.10項「環境変数」を参照してください。
環境変数VIRTUAL_HOST_NAMEを設定したノードからハードウェア・クラスタの共有ディスクにOracle Application Serverをインストールします。
第4章「基本インストール」で説明しているとおりに、基本インストールを実行します。
Oracle HTTP Serverを実行するハードウェア・クラスタにインストールする場合は、5.2.5項「Oracle HTTP Serverのインストール」の手順を実行します。インストール時に、次の操作を行います。
Oracle WebCenter FrameworkおよびOracle Content DBを実行するハードウェア・クラスタへのインストールを実行する場合は、次の2つのタイプのインストールを実行する必要があります。
Oracle WebCenter Frameworkのインストール時に、次の操作を行います。
Oracle Content DBのインストール時に、次の操作を行います。
この手順は、手順4で分散インストールを実行した場合にのみ実行する必要があります。
Oracle Content DBをインストールしたOracleホーム上のOracle HTTP Serverを無効にします。
ORACLE_HOME/opmn/conf/opmn.xmlファイルでOracle HTTP Serverのステータスをdisabledに設定します。
<ias-component id="HTTP_Server" status="disabled">
> ORACLE_HOME/bin/opmnctl stopall > ORACLE_HOME/bin/opmnctl startall
この手順は、SSLを使用している場合にのみ実行する必要があります。
各ノードでORACLE_HOME/Apache/Apache/conf/httpd.confファイルを次のように編集します。
httpd.confに次の行を追加してcertheaders_moduleをロードします。
LoadModule certheaders_module libexec/mod_certheaders.so
<VirtualHost *:7777> ServerName myworkplace.com Port 443 ServerAdmin you@youraddress.com RewriteEngine On RewriteOptions inherit SimulateHTTPS On </VirtualHost>
ファイルベースの永続性があるOracleAS JMSを使用する場合は、共有ディスクでOracleAS JMSキュー用のファイル・システムを作成し、このファイル・システムをノード1からマウントします。
この項では、OracleAS Disaster Recovery構成にOracle Application Serverをインストールする方法について説明します。OracleAS Disaster Recoveryは、Oracle Application Serverがサポートする高可用性環境の1つです。
この項の内容は次のとおりです。
使用している環境に2つの物理的に分離したサイトが必要な場合は、OracleAS Disaster Recovery環境を使用します。1つは本番サイトであり、もう1つはスタンバイ・サイトです。本番サイトがアクティブの間、スタンバイ・サイトはパッシブです。本番サイトが停止すると、スタンバイ・サイトがアクティブになります。
OracleAS Disaster Recoveryでは、本番サイトおよびスタンバイ・サイトでInfrastructureおよび中間層の構成に使用できる、多数の基本トポロジをサポートしています。OracleAS Disaster Recoveryがサポートする基本トポロジは次のとおりです。
対称トポロジでは、スタンバイ・サイトの各ノードは本番サイトのノードに対応しています。この中には、OracleAS Infrastructureおよび中間層の両方を実行しているノードも含まれます。非対称トポロジのスタンバイ・サイトに必要なインスタンスの数は、本番サイトよりも少なく、スイッチオーバーまたはフェイルオーバー操作時のサイトの運用に最低限必要な数です。サポートされる最後の2つのトポロジは、OracleASリリース10.1.3.2.0で特に重要です。これらのトポロジの詳細は、『Oracle Application Server高可用性ガイド』を参照してください。
OracleAS Cold Failover Cluster環境の本番サイトにOracleAS Infrastructureを設定し、この環境を少し変更できます。詳細は、6.5.2.4項「本番サイトでOracleAS Cold Failover Clusterを使用する場合（OracleAS 10.1.2.n.nのみ）」を参照してください。
これらのサポートされているトポロジでは、OracleAS Disaster Recoveryソリューションとして構成された本番およびスタンバイ・トポロジ内のすべてのシステムのOracleホームに、OracleAS Guardがインストールされます。
OracleAS GuardはOracleAS Companion CD #2に収録されており、スタンドアロン・インストール・キットとしてインストールできます。このスタンドアロン・キットをインストールするタイミングの詳細は、6.5.4項「OracleホームへのOracleAS 10g （10.1.3.2.0）のOracleAS Guardスタンドアロン・インストール」を参照してください。
図6-5に、対称型のOracleAS Disaster Recovery環境の例を示します。各サイトには、中間層を実行するノードが2つとOracleAS Infrastructureを実行するノードが1つあります。
OracleAS Disaster Recoveryを機能させるには、フェイルオーバーが即座に実行されるように本番サイトとスタンバイ・サイトのデータを同期化する必要があります。本番サイトで行った構成の変更は、スタンバイ・サイトにも反映させる必要があります。
2つのタイプのデータを同期化する必要があります。同期化の方法は、データのタイプによって異なります。
Oracle Data Guard、およびバックアップおよびリカバリ・スクリプトの使用方法の詳細は、『Oracle Application Server高可用性ガイド』を参照してください。
OracleAS Disaster Recovery環境内にOracle Application Serverをインストールする前に、次の手順を実行する必要があります。
次の条件についてノードが同じであることを確認します。
同じコンポーネントでは、本番サイトでもスタンバイ・サイトでも同じポート番号を使用する必要があります。たとえば、Oracle HTTP Serverが本番サイトでポート80を使用している場合は、スタンバイ・サイトでもポート80を使用する必要があります。これを確実にするためには、インストール時に使用するstaticports.iniファイルを作成します。このファイルで各コンポーネントのポート番号を指定できます。詳細は、2.7.3項「カスタムのポート番号の使用（「静的ポート」機能）」を参照してください。
サイト間でデータを同期化するときにデータを編集してホスト名を修正する必要がないように、本番サイトおよびスタンバイ・サイトの対応するノードの名前は同じである必要があります。
インフラストラクチャを実行するノードの場合、仮想名を設定します。これを行うには、/etc/hostsファイルにノードの別名を指定します。
たとえば、本番サイトのインフラストラクチャ・ノードでは、hostsファイル内の次の行は別名をasinfraに設定します。
138.1.2.111 prodinfra asinfra
スタンバイ・サイトでは、次の行はノードの別名をasinfraに設定します。
213.2.2.110 standbyinfra asinfra
本番サイトおよびスタンバイ・サイトにOracleAS Infrastructureをインストールする場合は、「仮想ホストの指定」画面でこの別名（asinfra）を指定します。構成データには、インフラストラクチャ・ノード用のこの別名が含まれます。
中間層を実行するノードの場合、中間層のインストール時にインストーラによって「仮想ホストの指定」画面が表示されないため、インフラストラクチャ・ノードの場合のように別名を指定できません。中間層のインストールでは、インストーラによってgethostname()関数がコールされ、自動的にホスト名が確認されます。本番サイトの各中間層ノードに対して、スタンバイ・サイトの対応するノードが同じホスト名を戻すようにする必要があります。
これを行うには、ローカルまたは内部のホスト名を設定します。このホスト名はパブリックまたは外部のホスト名と同じである必要はありません。スタンバイ・サイトのノードの名前を本番サイトの対応するノードの名前にあわせて変更するか、本番サイトとスタンバイ・サイトの両方のノードの名前が同じになるように変更できます。どちらの方法を使用するかは、ノード上で実行されている他のアプリケーション、およびノード名の変更によってこれらのアプリケーションが影響を受けるかどうかによって決定します。
hostnameコマンドが新しいローカル・ホスト名を戻すようにノードを再構成します。方法1: 両サイトの各ノードの/etc/hostsファイルを編集します。この方法にはDNSサーバーの構成は含まれませんが、OracleAS Disaster Recovery環境内の各ノードのhostsファイルをメンテナンスする必要があります。たとえば、IPアドレスが変更されたら、すべてのノード上のファイルを更新し、ノードを再起動する必要があります。
方法1の詳細
/etc/hostsファイルに次の行を含めます。IPアドレスは、本番サイトのノードで解決します。127.0.0.1 localhost 138.1.2.333 asmid1.oracle.com asmid1 138.1.2.444 asmid2.oracle.com asmid2 138.1.2.111 asinfra.oracle.com asinfra
hostsファイルに次の行を含めます。IPアドレスは、スタンバイ・サイトのノードで解決します。127.0.0.1 localhost 213.2.2.330 asmid1.oracle.com asmid1 213.2.2.331 asmid2.oracle.com asmid2 213.2.2.110 asinfra.oracle.com asinfra
/etc/nsswitch.confファイルの「hosts:」行の最初の項目が、「files」になるようにします。
hosts: files nis dns
このエントリでは、名前解決の順序を指定します。別の方法が最初に表示されている場合は、ノードは他の方法を使用してホスト名を解決します。
方法2: 本番サイトとスタンバイ・サイトに異なる内部DNSサーバーを設定します。この構成によって、各サイト（本番またはスタンバイ）のノードがサイト内でホスト名を解決できるようになります。内部DNSサーバーの上には、企業、つまり外部のDNSサーバーがあります。内部DNSサーバーは、信頼できないリクエストは外部DNSサーバーへ転送します。外部DNSサーバーは、内部DNSサーバーの存在を知りません。詳細は、図6-6を参照してください。
方法2の詳細
例:
prodmid1.us.oracle.com IN A 138.1.2.333 prodmid2.us.oracle.com IN A 138.1.2.444 prodinf.us.oracle.com IN A 138.1.2.111 standbymid1.us.oracle.com IN A 213.2.2.330 standbymid2.us.oracle.com IN A 213.2.2.331 standbyinf.us.oracle.com IN A 213.2.2.110
インフラストラクチャ・ノードの場合、仮想名または別名を使用します。
中間層ノードの場合、ノード名（/etc/nodename内の値）を使用します。
次の例では、新しいゾーンのドメイン名として「asha」を使用します。
asmid1.asha IN A 138.1.2.333 asmid2.asha IN A 138.1.2.444 asinfra.asha IN A 138.1.2.111
スタンバイ・サイトに対しても同じことを行います。本番サイトに使用したドメイン名を使用します。
asmid1.asha IN A 213.2.2.330 asmid1.asha IN A 213.2.2.331 asinfra.asha IN A 213.2.2.110
本番サイトの各ノードの/etc/resolv.confファイル内で、既存のネーム・サーバーのIPアドレスを、本番サイトの内部DNSサーバーのIPアドレスに変更します。
スタンバイ・サイトのノードに対しても同じ手順を実行します。ただし、スタンバイ・サイト用の内部DNSサーバーのIPアドレスを使用します。
次の例では、「remote_infra」エントリはスタンバイ・サイトのインフラストラクチャ・ノードを示します。この名前は、スイッチオーバーが発生した場合にTNSエントリを変更しなくてもよいように、本番サイトとスタンバイ・サイトの両方のTNSエントリで使用されます。
本番サイトでは、DNSエントリは次のようになります。
asmid1.asha IN A 138.1.2.333 asmid2.asha IN A 138.1.2.444 asinfra.asha IN A 138.1.2.111 remote_infra.asha IN A 213.2.2.110
スタンバイ・サイトでは、DNSエントリは次のようになります。
asmid1.asha IN A 213.2.2.330 asmid2.asha IN A 213.2.2.331 asinfra.asha IN A 213.2.2.110 remote_infra.asha IN A 138.1.2.111
変更を行い、ノードを再起動した後で、次のコマンドを実行して、ノードがホスト名を適切に解決することを確認します。
> hostname asmid1
hostnameコマンドを実行します。これによって、内部ホスト名が戻されます。たとえば、prodmid1およびstandbymid1上でこのコマンドを実行すると、「asmid1」が戻されます。
prompt> hostname asmid1
prompt> ping prodinfra ping the production infrastructure node PING prodinfra: 56 data byes 64 bytes from prodinfra.oracle.com (138.1.2.111): icmp_seq=0. time=0. ms ^C prompt> ping iasinfra ping the production infrastructure node PING iasinfra: 56 data byes 64 bytes from iasinfra.oracle.com (138.1.2.111): icmp_seq=0. time=0. ms ^C prompt> ping iasmid2 ping the second production midtier node PING iasmid2: 56 data byes 64 bytes from iasmid2.oracle.com (138.1.2.444): icmp_seq=0. time=0. ms ^C prompt> ping prodmid2 ping the second production midtier node PING prodmid2: 56 data byes 64 bytes from prodmid2.oracle.com (138.1.2.444): icmp_seq=0. time=0. ms ^C prompt> ping standbymid1 ping the first standby midtier node PING standbymid1: 56 data byes 64 bytes from standbymid1.oracle.com (213.2.2.330): icmp_seq=0. time=0. ms ^C
OracleAS Disaster Recoveryシステムの本番サイトでOracleAS Infrastructureを設定し、OracleAS Cold Failover Cluster構成で実行できます。この場合、1つのハードウェア・クラスタに2つのノードがあり、OracleAS Infrastructureを共有ディスクにインストールします。詳細は、10g リリース2（10.1.2）のOracle Application Serverのインストレーション・ガイドで、第11章「高可用性環境へのインストール: OracleAS Cold Failover Cluster」を参照してください。
この環境でOracleAS Cold Failover Clusterを設定するには、本番サイト上のasinfra.ashaに対して（物理IPアドレスのかわりに）仮想IPアドレスを使用します。次の例では、138.1.2.120が仮想IPアドレスであると仮定します。
asmid1.asha IN A 138.1.2.333 asmid2.asha IN A 138.1.2.444 asinfra.asha IN A 138.1.2.120 仮想IPアドレス remote_infra.asha IN A 213.2.2.110
スタンバイ・サイトでは、asinfra.ashaには引き続き物理IPアドレスを使用しますが、remote_infra.ashaには仮想IPアドレスを使用します。
asmid1.asha IN A 213.2.2.330 asmid2.asha IN A 213.2.2.331 asinfra.asha IN A 213.2.2.110 物理IPアドレス remote_infra.asha IN A 138.1.2.120 仮想IPアドレス
OracleASリリース10.1.3.2.0では、本番サイトとスタンバイ・サイトでの中間層インストールのみを行うことができます。
次のようにしてOracle Application Serverをインストールします。
|
注意: すべてのインストールに対して、staticports.iniを使用してコンポーネントのポート番号を指定します。詳細は、6.5.2.2項「staticports.iniファイルの設定」を参照してください。 |
OracleASリリース10.1.2.0.0環境では、OracleAS InfrastructureのOracle Identity ManagementおよびOracleAS Metadata Repositoryコンポーネントを同じノードにインストールする必要があります。コンポーネントを複数のノードに分散することはできません。OracleASリリース10.1.2.0.2環境では、コンポーネントを複数のノードに分散できます。
インストール手順は、OracleAS Cold Failover Clusterの場合の手順と同様です。表示される一連の画面については、10g リリース2（10.1.2）のOracle Application Serverのインストレーション・ガイドの「OracleAS Cold Failover Cluster（Infrastructure）構成のインストール」を参照してください。
次の点に注意してください。
構成に応じて、OracleAS 10.1.3.2.0中間層またはOracleAS 10.1.2n.n中間層をインストールできます。n.nは0.0以上を表します。
OracleASリリース10.1.3.2.0では、任意の中間層タイプをインストールできます。
Oracle WebCenter FrameworkおよびOracle HTTP Serverのインストールについては、5.2.2項「Oracle WebCenter FrameworkおよびOracle HTTP Serverのインストール」を参照してください。
Oracle WebCenter Frameworkのインストールについては、5.2.4項「Oracle WebCenter Frameworkのインストール」を参照してください。
Oracle HTTP Serverのインストールについては、5.2.5項「Oracle HTTP Serverのインストール」を参照してください。
OracleASリリース10.1.2.n.nでは、任意の中間層タイプをインストールできます。
J2EE and Web Cacheのインストールについては、10g リリース2（10.1.2）のOracle Application Serverのインストレーション・ガイドで「Database-Based Farm RepositoryへのJ2EE and Web Cacheのインストール（Oracle Identity Management Accessを使用する場合）」を参照してください。
Portal and WirelessまたはBusiness Intelligence and Formsのインストールについては、Portal and WirelessまたはBusiness Intelligence and Formsのインストールに関する項を参照してください。
OracleAS 10.1.2.n.nでは、次の点に注意してください。
OracleAS 10g （10.1.3.2.0）のOracleAS Guardスタンドアロン・インストールは、Companion CDのDisk 2に収録されています。このOracleAS Guardスタンドアロン・インストールは、次の環境にインストールできます。
OracleAS Guardがアップグレード・インストールされた場合は、dsa.conf構成ファイルのコピーを作成して、現在のOracleAS Guard環境の設定を保存します。OracleAS 10g （10.1.3.2.0）のOracleAS Guardスタンドアロン・インストール・キットを実行後、保存しておいたdsa.conf構成ファイルをリストアして、アップグレードされたOracleAS Guard環境で以前と同じ設定を使用できます。
OracleAS 10g （10.1.3.2.0）のOracleAS Guardスタンドアロン・インストール・キットを実行するには、次のディレクトリ・パスから実行します。
UNIXシステムの場合:
/Disk2/asg/install/runInstaller
実行するインストールの種類を選択します。一般のインストールには、「標準」を選択します。OracleAS Guardの旧リリースから現行リリースへアップグレードする場合は、「カスタムまたは再インストール」を選択します。
oc4jadminアカウントのパスワードを入力し、インストールを続行します。
OracleAS Guardリリース10.1.2.n.n（n.nは0.0以上を表します）を使用してすでにOracleAS Disaster Recovery環境が設定されている場合は、その環境内のOracleAS Guardをアップグレードして、新しい機能および6.5.1項「OracleAS Disaster Recovery: 概要」に記載されているトポロジのサポートを利用できます。OracleAS Disaster Recovery環境をアップグレードする基本的な手順は、次のとおりです。
UNIXシステムの場合:
<ORACLE_HOME>/opmn/bin/opmnctl stopall
同じシステムに複数のOracleホームが存在する場合は、構成ファイルでOracleAS Guardサーバーごとに異なるポートが構成されていることを確認します。
ここではOracleAS Guardをアップグレード・インストールするので、dsa.conf構成ファイルのコピーを作成して、現在のOracleAS Guard環境の設定を保存します。OracleAS 10g （10.1.3.2.0）のOracleAS Guardスタンドアロン・インストール・キットを実行後、保存しておいたdsa.conf構成ファイルをリストアして、アップグレードされたOracleAS Guard環境で以前と同じ設定を使用できます。
UNIXシステムの場合:
<ORACLE_HOME>/dsa/dsa.conf
UNIXシステムの場合:
<ORACLE_HOME>/opmn/bin/opmnctl startall <ORACLE_HOME>/opmn/bin/opmnctl startproc ias-component=ASG
Oracle Data Guardの設定やOracleAS Metadata Repositoryデータベースの構成などの、OracleAS Disaster Recovery環境の管理方法については、『Oracle Application Server高可用性ガイド』を参照してください。
|
 Copyright © 2007 Oracle Corporation. All Rights Reserved. |
|