10g リリース3（10.1.3.2.0） for Microsoft Windows
E05051-01
 目次 |
 索引 |
| Oracle Application Serverインストレーション・ガイド 10g リリース3（10.1.3.2.0） for Microsoft Windows E05051-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.2項「アクティブ-アクティブ・トポロジの作成」を参照してください。
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.3項「アクティブ-パッシブ・トポロジの作成」を参照してください。
OracleAS Disaster Recovery構成には、次の特性があります。
詳細は、6.4項「OracleAS Disaster Recovery構成の作成」を参照してください。
表6-1に、高可用性構成間の相違の概要を示します。
この項では、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ディレクトリのマウント・ポイントは、アクティブ-アクティブ・トポロジ内のすべてのノードで同じである必要があります（たとえば、S:¥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.3項「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.2.5.1項「動的検出方法によるクラスタの設定」の手順に従って、インストール後にクラスタを定義できます。拡張インストールの実行中にこの方法を使用する場合は、インストーラの「クラスタ・トポロジ構成」画面でマルチキャスト・アドレスおよびポートを指定する必要があります。
この方法では、検出サーバーとして機能するようにクラスタ内の特定のノードが構成されます。これにより、クラスタのトポロジ・マップが保持され、他のノードはこのサーバーを経由して相互に接続されます。
この方法を使用する場合は、インストール後に6.2.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">
C:¥> ORACLE_HOME¥bin¥opmnctl stopall C:¥> 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 modules/ApacheModuleCertHeaders.dll
<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）にあります。
Windowsを実行している場合は、次の製品がクラスタに必要です。
これらの製品は、トポロジ内の両方のノード（アクティブとパッシブ）にインストールする必要があります。
共有記憶域には、Oracle Metadata Services（MDS）用のディレクトリも作成する必要があります。MDSディレクトリには、デプロイされたアプリケーションに関するデータが格納されます。
共有記憶域にMDSディレクトリを作成することによって、すべてのOracle Application Serverインスタンスが同じデータにアクセスするため、データをレプリケートする必要がなくなります。
MDSディレクトリのマウント・ポイントは、アクティブ-パッシブ・トポロジ内のすべてのノードで同じである必要があります（たとえば、S:¥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.3.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を使用する場合は、共有ディスクでファイル・システムを作成します。 |
|
|
7. |
Oracle Fail Safeで作成したグループに、リソースとしてOPMNを追加します。 |
Oracle Application ServerをOracleAS Cold Failover Clusterにインストールする前に、次の手順を実行します。
クラスタ内の両方のノード上で、Event Logサービスが実行されている必要があります。これは、「サービス」ダイアログ・ボックスで確認できます。「サービス」ダイアログ・ボックスを表示するには、次の手順を実行します。
クラスタに関連付ける仮想アドレスが必要です。仮想アドレスは、仮想ホスト名およびIPアドレスで構成されます。クライアントは、仮想ホスト名を使用してOracleAS Cold Failover Clusterにアクセスします。各ノードには、ノード自体のホスト名およびIPアドレスに加えて、仮想アドレスが必要です。図6-3は、クラスタ内の2つのノードの仮想アドレスを示しています。
仮想アドレスを取得するには、ネットワーク管理者に連絡してください。仮想ホスト名と仮想IPアドレスは、クラスタを含むサブネットのコンテキスト内で有効な任意のホスト名およびIPアドレスです。
MSCSがコンピュータにインストールされていることを確認するには、「スタート」メニューから「クラスタ アドミニストレータ」を起動できることを確認します。
Windows 2000の場合: 「スタート」→「プログラム」→「管理ツール」→「クラスタ アドミニストレータ」を選択します。
Windows 2003の場合: 「スタート」→「管理ツール」→「クラスタ アドミニストレータ」を選択します。
MSCSが使用するクラスタIPアドレスおよびクラスタ名は、前述の手順で作成した仮想IPおよび仮想ホスト名とは異なります。
クラスタ・アドミニストレータを使用すると、クラスタの名前を確認できます。
OracleMSCSServicesサービスを所有するドメイン・ユーザーが必要です。このサービスは、Oracle Fail Safeのインストール時にインストールされます。
このユーザーの要件は、次のとおりです。
Oracle Fail Safeのインストール時に、domainname¥username形式を使用して、ドメインおよびユーザーを指定します。Microsoft Windows 2000のドメインを実行している場合は、username@dnsDomainName形式を使用することもできます。
両方のノードのローカル記憶域にOracle Fail Safeをインストールする必要があります。たとえば、図6-3では、両方のノードにOracle Fail Safeがインストールされています。
Oracle Fail Safeは、Oracle Application Serverに付属しています。Oracle Fail Safeは、Oracle Fail SafeのCD-ROMからインストールできます。
各ノードにOracle Fail Safeをインストールする手順の概要は、次のとおりです。
この項では、Oracle Fail Safeのインストールに使用する画面について説明します。画面の詳細は、『Oracle Fail Safeインストレーション・ガイド』を参照してください。
setup.exeをダブルクリックして、インストーラを起動します。
名前: このOracleホームの名前を入力します。たとえば、ofsと入力します。
パス（「インストール先」セクション内）: Oracle Fail Safeのインストール先をフルパスで入力します。Oracle Fail Safeは、ローカル記憶域にインストールする必要があります。たとえば、C:¥oracle¥OFSと入力します。
「次へ」をクリックします。
次のコンポーネントがインストールされます。
「ドメイン¥ユーザー名」: OracleMSCSServicesサービスを実行するドメイン名およびユーザー名を入力します。
「パスワード」および「パスワードの確認」: ユーザーのパスワードを指定して、確認します。
「OK」をクリックします。
Oracle Fail Safeのインストール後、Oracle Fail Safe Managerを使用してクラスタを検証します。
「スタート」→「プログラム」→「Oracle - OracleHomeName」→「Oracle Fail Safe Manager」を選択します。
ここで、OracleHomeNameは、Oracle Fail SafeをインストールしたOracleホームの名前です。
「クラスタの検証」をクリックします。
Oracleソフトウェアに関連する警告が表示される場合があります。この警告は、クラスタにまだ製品がインストールされていないために表示されます。この警告は無視できます。ただし、システム警告が表示された場合は、調査する必要があります。
Oracle Fail Safeのグループとは、スタンバイ・ノードに一括してフェイルオーバーされるリソースの論理的な集合です。OracleAS Cold Failover ClusterにOracle Application Serverをインストールする前に、Oracle Fail Safe Managerを使用してグループを作成し、そのグループに次のリソースを追加する必要があります。
| グループに追加するリソース | 使用するツール |
|---|---|
|
仮想ホストのIP |
Oracle Fail Safe Manager |
|
仮想ホスト名 |
Oracle Fail Safe Manager |
|
共有ディスク |
クラスタ・アドミニストレータ |
グループを作成および設定するには、次の手順を実行します。この手順を実行すると、（フェイルオーバー・ポリシーやフェイルバック・ポリシー用の）デフォルト属性を持つグループが作成されます。これらの属性は、必要に応じて後で変更できます。詳細は、『Oracle Application Server高可用性ガイド』およびOracle Fail Safeのドキュメントを参照してください。
「スタート」→「プログラム」→「Oracle - OracleHomeName」→「Oracle Fail Safe Manager」を選択します。
ここで、OracleHomeNameは、Oracle Fail SafeをインストールしたOracleホーム・ディレクトリの名前です。
OracleAS」というグループを使用します。
「クライアントからアクセス可能なネットワークの表示」を選択します。
ネットワーク: ノードのプライマリ・ネットワーク・インタフェース・カードに関連付けられている名前を選択します。デフォルトでは、これは「ローカル・エリア接続」です。
ホスト名: 仮想ホスト名を入力します。たとえば、vhostを入力します。
IPアドレス: 仮想ホスト名のIPを入力します。たとえば、138.2.229.77を入力します。
「次へ」をクリックします。
Windows 2000の場合: 「スタート」→「プログラム」→「管理ツール」→「クラスタ アドミニストレータ」を選択します。
Windows 2003の場合: 「スタート」→「管理ツール」→「クラスタ アドミニストレータ」を選択します。
左側の「OracleAS」グループに注意してください。これは、Oracle Fail Safe Managerで作成したグループです。
中間層のインストール時に使用するstaticports.iniファイルを設定します。staticports.iniファイルの作成の詳細は、2.5.4項「カスタムのポート番号の使用（「静的ポート」機能）」を参照してください。
この項では、OracleAS Cold Failover Clusterをインストールする手順について説明します。
Oracle HTTP ServerとOC4Jを別々のOracleホームにインストールする場合は、両方のクラスタでそれぞれの手順を実行します。
6.3.3項「OracleAS Cold Failover Clusterのインストール前の手順」に記載されているインストール前の手順を実行します。
Oracle Content DB用のデータベースが必要です。高可用性トポロジでは、コールド・フェイルオーバー・クラスタ・データベース、Real Application Clustersデータベースなどの高可用性データベースを使用する必要があります。
Oracle Content DBのデータベース要件の詳細は、2.3項「Oracle Content Databaseの要件」を参照してください。
ハードウェア・クラスタの両方のノードで環境変数VIRTUAL_HOST_NAMEを仮想ホスト名に設定します。環境変数の設定方法の詳細は、2.7項「環境変数」を参照してください。
ハードウェア・クラスタの共有ディスクに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のインストール時に、次の操作を行います。
基本インストールでは、インストーラによりOPMN用のWindowsサービスは作成されません。インストール後にWindowsサービスを作成する必要があります。
OPMN用のWindowsサービスを作成するには、SCツール（sc.exe）を使用できます。これは、Microsoftにより提供されているサービス制御管理ツールです。SCツールは、Windows Resource Kitに含まれています。
次のコマンドを実行して、OPMN用のサービスを作成します。SCツールでは、各オプションの後に空白が必要であることに注意してください。
sc create Oracle-<instance_name>ProcessManager binPath= "<oracle_home>¥opmn¥bin¥opmn.exe -S"
ノード1でOracle Application Serverサービスを停止し、スタートアップの種類を手動に設定します。
Windows 2000の場合: 「スタート」→「プログラム」→「管理ツール」→「サービス」を選択します。
Windows 2003の場合: 「スタート」→「管理ツール」→「サービス」を選択します。
Oracle-<InstanceName>ProcessManager
サービスを停止するには、サービスを右クリックし、ポップアップ・メニューから「停止」を選択します。
サービスを右クリックして、「プロパティ」を選択します。
「スタートアップの種類」セクションで「手動」を選択して、「OK」をクリックします。
この手順は、手順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">
C:¥> ORACLE_HOME¥bin¥opmnctl stopall C:¥> ORACLE_HOME¥bin¥opmnctl startall
この手順は、SSLを使用している場合にのみ実行する必要があります。
各ノードでORACLE_HOME¥Apache¥Apache¥conf¥httpd.confファイルを次のように編集します。
httpd.confに次の行を追加してcertheaders_moduleをロードします。
LoadModule certheaders_module modules/ApacheModuleCertHeaders.dll
<VirtualHost *:7777> ServerName myworkplace.com Port 443 ServerAdmin you@youraddress.com RewriteEngine On RewriteOptions inherit SimulateHTTPS On </VirtualHost>
ファイルベースの永続性があるOracleAS JMSを使用する場合は、共有ディスクでOracleAS JMSキュー用のファイル・システムを作成します。クラスタ・アドミニストレータを使用して、この共有ディスクをOracle Fail Safeグループに追加します。これは、6.3.3.7項「Oracle Fail Safeのグループの作成」の手順6と7を実行して行うことができます。
Oracle Fail Safeで作成したグループにリソースとしてOPMNを追加します。詳細は、6.3.5項「インストール後の手順: OPMNの高可用性設定」を参照してください。
OPMNの高可用性設定を行うには、6.3.3.7項「Oracle Fail Safeのグループの作成」で作成したOracle Fail SafeグループにOPMNを追加します。OPMNは、Oracle-<InstanceName>ProcessManagerサービスに対応します。
「スタート」→「プログラム」→「Oracle - OracleHomeName」→「Oracle Fail Safe Manager」を選択します。
ここで、OracleHomeNameは、Oracle Fail SafeをインストールしたOracleホーム・ディレクトリの名前です。
「汎用サービス」を選択して、グループが正しいことを確認し、「次へ」をクリックします。
「表示名」で「Oracle-<InstanceName>ProcessManager」を選択し、「次へ」をクリックします。
OPMNの起動パラメータは存在しません。「次へ」をクリックします。
「選択済ディスク」には、何も表示されていない必要があります。「次へ」をクリックします。
ネットワーク名を「リソースの依存性」列に移動します。「次へ」をクリックします。
情報を確認して、「OK」をクリックします。特に、クラスタの両方のノードが、「可能所有者ノード」の下に表示されていることを確認します。
クラスタ内の両方のノードがProcess Managerサービスを実行できるように、Oracle Fail Safe ManagerによってProcess Managerサービスが構成されます。構成が完了すると、図6-26に類似した画面が表示されます。成功したことを示すダイアログ・ボックスで「OK」をクリックします。
この項では、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.4.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.4.4項「OracleホームへのOracleAS 10g （10.1.3.2.0）のOracleAS Guardスタンドアロン・インストール」を参照してください。
図6-28に、対称型の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.5.4項「カスタムのポート番号の使用（「静的ポート」機能）」を参照してください。
サイト間でデータを同期化するときにデータを編集してホスト名を修正する必要がないように、本番サイトおよびスタンバイ・サイトの対応するノードの名前は同じである必要があります。
インフラストラクチャを実行するノードの場合、仮想名を設定します。これを行うには、C:¥Windows¥system32¥drivers¥etc¥hostsファイルにノードの別名を指定します。
たとえば、本番サイトのインフラストラクチャ・ノードでは、hostsファイル内の次の行は別名をasinfraに設定します。
138.1.2.111 prodinfra asinfra
スタンバイ・サイトでは、次の行はノードの別名をasinfraに設定します。
213.2.2.110 standbyinfra asinfra
本番サイトおよびスタンバイ・サイトにOracleAS Infrastructureをインストールする場合は、「仮想ホストの指定」画面でこの別名（asinfra）を指定します。構成データには、インフラストラクチャ・ノード用のこの別名が含まれます。
中間層を実行するノードの場合、中間層のインストール時にインストーラによって「仮想ホストの指定」画面が表示されないため、インフラストラクチャ・ノードの場合のように別名を指定できません。中間層のインストールでは、インストーラによってgethostname()関数がコールされ、自動的にホスト名が確認されます。本番サイトの各中間層ノードに対して、スタンバイ・サイトの対応するノードが同じホスト名を戻すようにする必要があります。
これを行うには、ローカルまたは内部のホスト名を設定します。このホスト名はパブリックまたは外部のホスト名と同じである必要はありません。スタンバイ・サイトのノードの名前を本番サイトの対応するノードの名前にあわせて変更するか、本番サイトとスタンバイ・サイトの両方のノードの名前が同じになるように変更できます。どちらの方法を使用するかは、ノード上で実行されている他のアプリケーション、およびノード名の変更によってこれらのアプリケーションが影響を受けるかどうかによって決定します。
_CLUSTER_NETWORK_NAME_に、新しいローカルの完全修飾名（asmid1.oracle.comなど）を指定します。方法1: 両サイトの各ノードのC:¥Windows¥system32¥drivers¥etc¥hostsファイルを編集します。この方法にはDNSサーバーの構成は含まれませんが、OracleAS Disaster Recovery環境内の各ノードのhostsファイルをメンテナンスする必要があります。たとえば、IPアドレスが変更されたら、すべてのノード上のファイルを更新し、ノードを再起動する必要があります。
方法1の詳細
C:¥Windows¥system32¥drivers¥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
hostsファイルが最初に読み取られるようにします。hostsファイルに目的のホスト名のエントリが含まれていない場合、ノードはDNSを介してホスト名を解決します。これを行うには、hostsファイルにエントリを追加した後でnbtstat -Rコマンドを実行し、キャッシュされた情報の消去および名前表の再ロードを実行します。詳細は、システム管理者に問い合せてください。
方法2: 本番サイトとスタンバイ・サイトに異なる内部DNSサーバーを設定します。この構成によって、各サイト（本番またはスタンバイ）のノードがサイト内でホスト名を解決できるようになります。内部DNSサーバーの上には、企業、つまり外部のDNSサーバーがあります。内部DNSサーバーは、信頼できないリクエストは外部DNSサーバーへ転送します。外部DNSサーバーは、内部DNSサーバーの存在を知りません。詳細は、図6-29を参照してください。
方法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
インフラストラクチャ・ノードの場合、仮想名または別名を使用します。
中間層ノードの場合、ノード名（環境変数_CLUSTER_NETWORK_NAME_内の値）を使用します。
次の例では、新しいゾーンのドメイン名として「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
表6-5 内部DNSサーバーを指すようにDNSリゾルバを構成する方法
スタンバイ・サイトのノードに対しても同じ手順を実行します。ただし、スタンバイ・サイト用の内部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コマンドを実行します。これによって、内部ホスト名が戻されます。たとえば、prodmid1およびstandbymid1上でこのコマンドを実行すると、「asmid1」が戻されます。
C:¥> hostname asmid1
C:> ping prodinfra ping the production infrastructure node Pinging prodinfra [138.1.2.111] with 32 bytes of data: Reply from 138.1.2.111: bytes=32 time<1ms TTL=128 C:> ping asinfra ping the production infrastructure node Pinging prodinfra [138.1.2.111] with 32 bytes of data: Reply from 138.1.2.111: bytes=32 time<1ms TTL=128 C:> ping asmid2 ping the second production midtier node Pinging asmid2 [138.1.2.444] with 32 bytes of data: Reply from 138.1.2.444: bytes=32 time<1ms TTL=128 C:> ping prodmid2 ping the second production midtier node Pinging asmid2 [138.1.2.444] with 32 bytes of data: Reply from 138.1.2.444: bytes=32 time<1ms TTL=128 C:> ping standbymid1 ping the first standby midtier node Pinging asmid2 [213.2.2.330] with 32 bytes of data: Reply from 213.2.2.330: bytes=32 time<1ms TTL=128
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 Disaster Recovery環境でOracleAS Cold Failover Clusterを設定する場合は、OracleAS Metadata RepositoryをOracle Fail Safeグループに追加するときにパスワード・ファイルを作成する必要があります。つまり、Oracleデータベースのリソース・タイプを追加します。
Oracle Application Server 10g リリース2（10.1.2）のインストレーション・ガイドで、OracleAS Metadata Repositoryの高可用性設定に関する項を参照してください。
手順3cで、「はい、パスワード・ファイルを作成します(推奨)」を選択します。
「ユーザー名」で、SYSと入力します。
「パスワード」と確認のために「パスワードの確認」にも、SYSユーザーに設定するパスワードを入力します。
OracleASリリース10.1.3.2.0では、本番サイトとスタンバイ・サイトでの中間層インストールのみを行うことができます。
次のようにしてOracle Application Serverをインストールします。
|
注意: すべてのインストールに対して、staticports.iniを使用してコンポーネントのポート番号を指定します。詳細は、6.4.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スタンドアロン・インストール・キットを実行するには、次のディレクトリ・パスから実行します。
Windowsシステムの場合:
Disk2¥asg¥Disk1¥install¥setup.exe
実行するインストールの種類を選択します。一般のインストールには、「標準」を選択します。OracleAS Guardの旧リリースから現行リリースへアップグレードする場合は、「カスタムまたは再インストール」を選択します。
oc4jadminアカウントのパスワードを入力し、インストールを続行します。
OracleAS Guardリリース10.1.2.n.n（n.nは0.0以上を表します）を使用してすでにOracleAS Disaster Recovery環境が設定されている場合は、その環境内のOracleAS Guardをアップグレードして、新しい機能および6.4.1項「OracleAS Disaster Recovery: 概要」に記載されているトポロジのサポートを利用できます。OracleAS Disaster Recovery環境をアップグレードする基本的な手順は、次のとおりです。
Windowsシステムの場合:
<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環境で以前と同じ設定を使用できます。
Windowsシステムの場合:
<ORACLE_HOME>¥dsa¥dsa.conf
Windowsシステムの場合:
<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. |
|