10g リリース3（10.1.3.1.0） for Microsoft Windows
B31910-02
 目次 |
 索引 |
| Oracle Application Serverインストレーション・ガイド 10g リリース3（10.1.3.1.0） for Microsoft Windows B31910-02 |
|
この章では、Oracle Application Serverでサポートされている高可用性構成の概要とインストール手順について説明します。
この章の内容は次のとおりです。
この章では、Oracle Application Serverでの高可用性構成の概要のみを説明します。構成の詳細は、『Oracle Application Server高可用性ガイド』を参照してください。
Oracle Application Serverがインストール時にサポートする高可用性構成のタイプは次のとおりです。それぞれのタイプには複数のバリエーションがあることに注意してください。
高可用性構成の比較一覧は、6.1.4項「相違の概要」を参照してください。
Oracle Application Serverは、OracleAS Clusterを使用したそのすべてのコンポーネントに対してアクティブ-アクティブな冗長モデルを用意しています。OracleAS Cluster構成では、2つ以上のOracle Application Serverインスタンスが同じワークロードを処理するように構成されます。これらのインスタンスは、同じマシン上で実行することも、別のマシン上で実行することもできます。
これらのインスタンスのフロントエンドには外部のロード・バランサが配置され、このロード・バランサによって、任意のアクティブなインスタンスにリクエストが送信されます。外部のロード・バランサではなく、ソフトウェア・ロード・バランサを実行してリクエストを分散することもできます。ただし、本番環境ではハードウェア・ロード・バランサの使用をお薦めします。
OracleAS Cluster構成の一般的なプロパティは次のとおりです。
各インスタンスは、同じワークロードまたはアプリケーションを処理する必要があります。一部の構成プロパティでは、各インスタンスが同じリクエストに対して同じリプライを配信できるように、インスタンス全体で類似した値が使用されます。その他の構成プロパティでは、ローカル・ホスト名情報のようにインスタンス固有の値が使用されます。
1つのインスタンスの構成を変更する場合は、そのアクティブ-アクティブ・トポロジ内の他のインスタンスにも同じ変更を加える必要があります。『Oracle Containers for J2EE構成および管理ガイド』の「クラスタの構成と管理」に、レプリケートされるプロパティを含むファイルが記載されています。
アクティブ-アクティブ・トポロジ内の1つのOracle Application Serverインスタンスで障害が発生しても、クラスタ内の他のインスタンスがリクエストの処理を続行します。ロード・バランサは、動作中のインスタンスにのみリクエストを送信します。
OracleAS Cluster構成の利点は次のとおりです。
アクティブ-アクティブ・トポロジは、冗長構成です。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にアクセスします。クライアントは、どちらの物理ノードがアクティブになっていて、特定のリクエストを実際に処理しているかを認識しません。
インストール時に仮想ホスト名を指定できます。詳細は、6.3項「アクティブ-パッシブ・トポロジの作成」を参照してください。
アクティブ-パッシブ構成には、アクティブなインスタンスの障害を検出し、パッシブなインスタンスにフェイルオーバーしてダウンタイムを最小にするための一連のスクリプトと手順も含まれています。
OracleAS Cold Failover Clusterトポロジの利点は次のとおりです。
アクティブなインスタンスになんらかの理由で障害が発生するか、オフラインにしなければならない場合、同一の構成を持つパッシブのインスタンスがアクティブなインスタンスを引き継ぐために常に待機しています。
アクティブ-パッシブ・トポロジでは、1つのセットのプロセスのみが稼働してリクエストを処理します。通常、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インスタンスでは単一ホストのリソースが利用されるのに対し、中間層インスタンスのクラスタでは複数のホストのリソースが使用され、より多くのCPUにアプリケーションの実行が分散されます。単一のOracle Application Serverインスタンスは、そのホストとオペレーティング・システムの障害に対して脆弱ですが、アクティブ-アクティブ・トポロジは、オペレーティング・システムやホストで障害が発生しても継続して機能し、その障害をクライアントから見えなくします。
アクティブ-アクティブ・トポロジでは、すべてのインスタンスが同時にアクティブになります。これが、常に1つのインスタンスのみがアクティブなアクティブ-パッシブ・トポロジとの相違点です。
アクティブ-アクティブ・トポロジのノードは、ハードウェア・クラスタに属しません。
アクティブ-アクティブ・トポロジでは、ロード・バランサによってトポロジ内のOracle Application Serverインスタンスの1つにリクエストが送信されます。つまり、ロード・バランサがOracle Application Serverインスタンスの前に配置されています。
ロード・バランサの構成時に、HTTPおよびHTTPSトラフィック用の仮想サーバー名を指定します。クライアントは、この仮想サーバー名を使用してリクエストを送信します。ロード・バランサは、利用可能なOracle Application Serverインスタンスにリクエストを送信します。
ロード・バランサで利用できる機能のリストは、『Oracle Application Server高可用性ガイド』を参照してください。
次の図は、2つのアクティブ-アクティブ・トポロジを示しています。この2つのトポロジは、Oracle HTTP ServerとOC4Jを同じOracleホームにインストールするか、または別々のOracleホームにインストールするかで異なります。
図6-1は、Oracle HTTP ServerとOC4Jを同じOracleホームにインストールしたアクティブ-アクティブ・トポロジを示しています。図6-2は、Oracle HTTP ServerとOC4Jを別のOracleホームにインストールしたアクティブ-アクティブ・トポロジを示しています。
アクティブ-アクティブ・トポロジのOracle Application Serverインスタンスはすべて同じクラスタに属します。Oracle HTTP Serverは、同じクラスタに属するOC4Jインスタンスにのみアプリケーションのリクエストを転送します。
次のいずれか方法により、OPMNを使用してインスタンスをクラスタ化できます。
OPMNによるクラスタ化では、一部のopmnctlコマンドで@clusterパラメータを使用することもできます。@clusterパラメータを使用するコマンドは、クラスタ内のすべてのインスタンスに適用されます。たとえば、@clusterパラメータを使用して、クラスタ内の全インスタンスのすべてのコンポーネントを起動できます。
クラスタのOC4Jインスタンスには、次の機能があります。
詳細は、『Oracle Containers for J2EE構成および管理ガイド』の「クラスタの構成と管理」を参照してください。
ロード・バランサはトポロジ内の任意のOracle Application Serverインスタンスにリクエストを送信できるため、リクエストを処理するインスタンスに関係なくクライアントが同じレスポンスを受信できるように、同じ方法でインスタンスを構成する必要があります。この方法の例を次に示します。
図6-1または図6-2に示すトポロジを作成するには、次の手順を実行します。
手順2: Oracle HTTP ServerおよびOC4JのインストールとOPMNを使用したインスタンスのクラスタ化
手順3: OC4Jコンポーネントのクラスタ化によるアプリケーション・クラスタの作成
次の各項で、手順について詳しく説明します。
構成手順については、ロード・バランサのドキュメントを参照してください。ロード・バランサで、HTTPトラフィック用に仮想サーバー名とポートを構成し、さらにHTTPSトラフィック用に別の仮想サーバー名とポートを構成する必要があります。仮想サーバー名のポート番号は、Oracle HTTP Serverがリスニングしているポート番号と一致している必要があります。クライアントは、この仮想サーバー名とポートを使用してOracle Application Serverインスタンスにアクセスします。
Oracle HTTP ServerとOC4Jは、同じ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項「検出サーバー方法によるクラスタの設定」の手順に従って、各インスタンスのopmn.xmlファイルでOracle Application Serverインスタンスの名前を明示的に指定することにより、OPMNのクラスタを定義できます。
この構成は、指定されたゲートウェイ・ノードを使用して、ファイアウォールで切り離されているトポロジや異なるサブネット上にあるトポロジを接続するために使用されます。
この方法を使用する場合は、構成の詳細について『Oracle Containers for J2EE構成および管理ガイド』のトポロジ間のゲートウェイ構成に関する項を参照してください。
統合インストールまたは分散インストールを実行できます。
アクティブ-アクティブ・トポロジの各ノードのローカル記憶域にOracle Application Serverをインストールします。
5.2.3項「J2EEサーバーおよびWebサーバーのインストール」の手順に従って拡張インストールを実行します。これにより、Oracle HTTP ServerとOC4Jが同じOracleホームから実行されます。
インストール時、表示されるメッセージに従って、次の手順を実行します。
「クラスタ・トポロジ構成」画面で、「このインスタンスをOracle Application Serverクラスタ・トポロジの一部として構成」を選択します。クラスタ内のすべてのノードで共有されるマルチキャスト・アドレスの「IPアドレス」および「ポート」を指定します。
マルチキャスト・アドレスは224.0.0.1〜239.255.255.255の間で指定する必要があります。クラスタ内の最初のノードにインストールする場合は、任意のIPアドレスとポートをマルチキャスト・アドレスの範囲内で選択できます。
次の点に注意してください。
アクティブ-アクティブ・トポロジの各ノードのローカル記憶域にOracle Application Serverをインストールします。
Oracle HTTP Serverを実行するノードでは、5.2.5項「Webサーバーのインストール」の手順を実行します。OC4Jを実行するノードでは、5.2.4項「J2EEサーバーのインストール」の手順を実行します。
インストール時に、次のオプションを選択します。
マルチキャスト・アドレスは224.0.0.1〜239.255.255.255の間で指定する必要があります。クラスタ内の最初のノードにインストールする場合は、任意のIPアドレスとポートをマルチキャスト・アドレスの範囲内で選択できます。
次の点に注意してください。
Oracle Application Serverインスタンス内のOC4Jコンポーネントをクラスタ化することもできます。このタイプのクラスタをアプリケーション・クラスタと呼びます。
アプリケーション・クラスタは次の機能を備えています。
グローバル・レベルまたはアプリケーション・レベルで定義されたアプリケーション・クラスタ
アプリケーション・クラスタのプロパティをグローバル・レベルまたはアプリケーション・レベルで定義できます。グローバル・レベルで定義したプロパティはすべてのアプリケーションに適用されますが、アプリケーション・レベルで定義した特定のプロパティを優先させることもできます。
グローバル・レベルでプロパティを定義するには、グローバルなdefaultアプリケーションの構成ファイルであるORACLE_HOME/j2ee/home/config/application.xmlファイルでプロパティを定義します。
アプリケーション・レベルでプロパティを定義するには、そのアプリケーションのorion-application.xmlファイルでプロパティを定義します。アプリケーションをデプロイすると、このファイルはORACLE_HOME/j2ee/home/application-deployments/<app-name>/ディレクトリに格納されます。
手順
グローバル・レベルまたはアプリケーション・レベルでアプリケーション・クラスタを作成するには、次の手順を実行します。
web.xmlファイルに、空の<distributable/>タグを追加します。
表6-2 アプリケーション・クラスタのレプリケーションのメカニズム
| レプリケーションのメカニズム | 説明 |
|---|---|
|
マルチキャスト |
OC4Jインスタンスは、マルチキャスト・アドレスおよびポートを使用して各インスタンス間の情報をレプリケートします。 詳細は、6.2.5.2項「マルチキャスト・レプリケーションの設定」を参照してください。 |
|
peer-to-peer |
Oracle Application Serverは、動的および静的の2種類のpeer-to-peerレプリケーションをサポートしています。
詳細は、6.2.5.3項「peer-to-peerレプリケーションの設定」を参照してください。 |
|
データベースへのレプリケーション |
状態およびセッションの情報は指定したデータベースに保存されます。このデータベースは 詳細は、6.2.5.4項「データベースへのレプリケーションの設定」を参照してください。 |
詳細は、『Oracle Containers for J2EE構成および管理ガイド』の「OC4Jでのアプリケーションのクラスタ化」を参照してください。
この項では、アクティブ-アクティブ・トポロジの保持に必要な一般的な手順について説明します。
マルチキャスト方法を使用しない場合は、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
マルチキャスト・レプリケーションはデフォルトのレプリケーション・タイプです。マルチキャスト・レプリケーションを使用するようにアプリケーションを設定するには、空の<cluster/>タグをそのアプリケーションのorion-application.xmlファイルまたはグローバルなORACLE_HOME¥j2ee¥home¥config¥application.xmlファイルに追加します。たとえば、次のようになります。
<orion-application ... > ... <cluster/> </orion-application>
<cluster/>タグは、アプリケーションをデプロイするすべてのノードで追加する必要があります。
マルチキャスト・レプリケーションでは、マルチキャスト・アドレス230.230.0.1とポート45566がデフォルトで使用されます。これらの値を変更する場合は、multicast要素のipおよびport属性に適切な値を指定します。たとえば、次のコードは、カスタマイズされた値に設定されているipおよびport属性を示しています。
<orion-application ... > ... <cluster allow-colocation="false"> <replication-policy trigger="onShutdown" scope="allAttributes"/> <protocol> <multicast ip="225.130.0.0" port="45577" bind-addr="226.83.24.10"/> </protocol> </cluster> </orion-application>
マルチキャスト・アドレスは224.0.1.0〜239.255.255.255の間で指定する必要があります。
前述のコード例で使用されているその他のタグおよび属性の説明:
allow-colocation: 同じホストで実行されている他のOracle Application Serverインスタンスにアプリケーションの状態をレプリケートするかどうかを指定します。デフォルト値はtrueです。
triggerおよびscope: 6.2.5.5項「レプリケーション・ポリシーの設定」を参照してください。
bind-addr: バインドするネットワーク・インタフェース・カード（NIC）のIPを指定します。ホスト・マシンで複数のNICが使用され、各NICでIPアドレスが個別に指定されている場合、この属性は有用です。
Oracle Application Serverは、動的および静的の2種類のpeer-to-peerレプリケーションをサポートしています。
動的なpeer-to-peerレプリケーションを設定するには、空の<opmn-discovery/>タグをそのアプリケーションのorion-application.xmlファイルまたはグローバルなORACLE_HOME¥j2ee¥home¥config¥application.xmlファイルに挿入します。
<orion-application ... > ... <cluster allow-colocation="false"> <replication-policy trigger="onShutdown" scope="allAttributes"/> <protocol> <peer> <opmn-discovery/> </peer> </protocol> </cluster> </orion-application>
クラスタ内のインスタンスをOPMNで検出する方法については、手順2 「Oracle HTTP ServerおよびOC4JのインストールとOPMNを使用したインスタンスのクラスタ化」で定義しています。
静的なpeer-to-peerレプリケーションを指定するには、そのアプリケーションのorion-application.xmlファイルまたはグローバルなORACLE_HOME¥j2ee¥home¥config¥application.xmlファイルの<node>要素でホスト名を記述します。ノードごとに、アクティブ-アクティブ・トポロジの別のノードを指定して、トポロジ内のすべてのノードが連鎖するようにします。たとえば、トポロジ内に3つのOracle Application Serverインスタンスがある場合、ノード1ではノード2を指定し、ノード2ではノード3を指定し、ノード3ではノード1を指定できます。
例:
ノード1では、<node>タグでノード2を指定します。
<orion-application ... > ... <cluster allow-colocation="false"> <replication-policy trigger="onShutdown" scope="allAttributes"/> <protocol> <peer start-port="7900" range="10" timeout="6000"> <node host="node2.mycompany.com" port="7900"/> </peer> </protocol> </cluster> </orion-application>
ノード2では、<node>タグでノード3を指定します。
<orion-application ... > ... <cluster allow-colocation="false"> <replication-policy trigger="onShutdown" scope="allAttributes"/> <protocol> <peer start-port="7900" range="10" timeout="6000"> <node host="node3.mycompany.com" port="7900"/> </peer> </protocol> </cluster> </orion-application>
ノード3では、<node>タグでノード1を指定します。
<orion-application ... > ... <cluster allow-colocation="false"> <replication-policy trigger="onShutdown" scope="allAttributes"/> <protocol> <peer start-port="7900" range="10" timeout="6000"> <node host="node1.mycompany.com" port="7900"/> </peer> </protocol> </cluster> </orion-application>
すべてのノードで同じノードを指定することにより、この操作を行うこともできます。3つのノードを使用した例の場合、ノード1および2でノード3を指定し、ノード3でノード1またはノード2を指定することもできます。
前述のコード例で使用されているタグおよび属性の説明:
start-port: ピア通信のためにOracle Application Serverがバインドしようとするローカル・ノードの最初のポートを指定します。このポートがすでに使用されている場合、Oracle Application Serverは、利用可能なポートが見つかるまでポート番号を増加します。デフォルト値は7800です。
timeout: 指定したピア・ノードからのレスポンス待機時間（ミリ秒）を指定します。デフォルト値は3000ミリ秒です。
host: ピア・ノードの名前を指定します。
port: ピア通信のために（host属性で）指定されているホストで使用するポートを指定します。デフォルト値は7800です。
range: （start-portではなく）port属性で指定されているポートを増加する回数を指定します。デフォルト値は5です。
次の点に注意してください。
orion-application.xmlファイルがインスタンスごとに異なります。アプリケーションをデプロイする際は、orion-application.xmlを適宜更新する必要があります。
このレプリケーション・メカニズムでは、レプリケートされたデータがデータベースに保存されます。アプリケーションのorion-application.xmlファイルまたはグローバルなORACLE_HOME¥j2ee¥home¥config¥application.xmlファイルの<database>タグでデータベースを指定します。たとえば、次のようになります。
<orion-application ... > ... <cluster allow-colocation="false"> <replication-policy trigger="onShutdown" scope="allAttributes"/> <protocol> <database data-source="jdbc/MyOracleDS"/> </protocol> </cluster> </orion-application>
data-source属性の値は、data-sources.xmlファイルで指定されているデータソースのjndi-nameと一致している必要があります。データソースの作成および使用方法の詳細は、『Oracle Containers for J2EEサービス・ガイド』を参照してください。
<replication-policy>タグの属性を使用すると、レプリケートするデータとその頻度を指定できます。
trigger属性は、レプリケーションをいつ実行するかを指定します。表6-3は、この属性でサポートされている値の説明です。
scope属性は、レプリケートするデータを指定します。表6-4は、この属性でサポートされている値の説明です。
レプリケート先のノードの数を指定するには、<cluster>タグのwrite-quota属性を使用します。たとえば、次のコードは、レプリケートされたデータが他の2つのノードにレプリケートされるように指定します。
<orion-application ... > ... <cluster allow-colocation="false" write-quota="2"> <replication-policy trigger="onShutdown" scope="allAttributes"/> <protocol> <peer> <opmn-discovery/> </peer> </protocol> </cluster> </orion-application>
デフォルト値は1です。
推奨事項: 2つのノードで構成されるアクティブ-アクティブ・トポロジでは、write-quotaを1に設定します。これにより、データが他のノードにレプリケートされます。
3つ以上のノードで構成されるトポロジでは、他の2つ以上のノードにデータがレプリケートされるようにwrite-quotaを2以上に設定します。
トポロジ内のすべてのノードにデータをレプリケートするには、トポロジのノードの合計数にwrite-quotaを設定します。別のインスタンスが実行されているノードがある場合は、その同じノードに書き戻すことができます。
write-quota属性は、データベースへのレプリケーションには使用されません。
この項では、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を実行している場合は、次の製品がクラスタに必要です。
これらの製品は、トポロジ内の両方のノード（アクティブとパッシブ）にインストールする必要があります。
図6-3は、Oracle Application ServerのOracleホームを共有記憶域にインストールしたアクティブ-パッシブ・トポロジの図を示しています。このOracleホームには、Oracle HTTP ServerとOC4Jの両方が格納されています。図6-4は、分散型のアクティブ-パッシブ・トポロジを示しています。ここでは、Oracle HTTP ServerとOC4Jが別々のOracleホームにインストールされています。
表6-5の手順に従ってOracleAS Cold Failover Cluster構成を作成します。Oracle HTTP ServerとOC4Jを同じOracleホームにインストールする場合は（図6-3）、ハードウェア・クラスタでこの手順を実行します。Oracle HTTP ServerとOC4Jを別々のOracleホームにインストールする場合は（図6-4）、両方のハードウェア・クラスタでそれぞれの手順を実行します。
| 手順 | 説明 | |
|---|---|---|
|
1. |
インストール前の作業の詳細は、6.3.3項を参照してください。内容は次のとおりです。 |
|
|
2. |
VIRTUAL_HOST_NAME変数を仮想ホスト名に設定します。 |
|
|
3. |
この手順では、インストーラを実行して共有ディスクにOracle HTTP ServerとOPMNをインストールします。 |
|
|
4. |
Oracle Application ServerインスタンスでSSLを使用する場合は、Oracle Application ServerインストールでSSLを有効にします。 |
|
|
5. |
OracleAS JMSを使用する場合は、共有ディスクでファイル・システムを作成します。 |
|
|
6. |
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.4.4項「カスタムのポート番号の使用（「静的ポート」機能）」を参照してください。
この項では、OracleAS Cold Failover Clusterをインストールする手順について説明します。
Oracle HTTP ServerとOC4Jを別々のOracleホームにインストールする場合は、両方のクラスタでそれぞれの手順を実行します。
6.3.3項「OracleAS Cold Failover Clusterのインストール前の手順」に記載されているインストール前の手順を実行します。
ハードウェア・クラスタの両方のノードで環境変数VIRTUAL_HOST_NAMEを仮想ホスト名に設定します。環境変数の設定方法の詳細は、2.8項「環境変数」を参照してください。
ハードウェア・クラスタの共有ディスクにOracle Application Serverをインストールするには、次の手順を実行します。
5.2.3項「J2EEサーバーおよびWebサーバーのインストール」の手順に従います。インストール時に、次の操作を行います。
Oracle HTTP Serverを実行するハードウェア・クラスタにインストールする場合は、5.2.5項「Webサーバーのインストール」の手順を実行します。インストール時に、次の操作を行います。
OC4Jを実行するハードウェア・クラスタにインストールする場合は、5.2.4項「J2EEサーバーのインストール」の手順を実行します。インストール時に、次の操作を行います。
Windows 2000の場合: 「スタート」→「プログラム」→「管理ツール」→「サービス」を選択します。
Windows 2003の場合: 「スタート」→「管理ツール」→「サービス」を選択します。
Oracle-<InstanceName>ProcessManager
サービスを停止するには、サービスを右クリックし、ポップアップ・メニューから「停止」を選択します。
サービスを右クリックして、「プロパティ」を選択します。
「スタートアップの種類」セクションで「手動」を選択して、「OK」をクリックします。
Oracle Application ServerインスタンスでSSLを使用する場合は、『Oracle Application Server管理者ガイド』の手順に従います。
ファイルベースの永続性がある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.1.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.1.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.4.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: 本番サイトとスタンバイ・サイトに異なる内部DNSサーバーを設定します。この構成によって、各サイト（本番またはスタンバイ）のノードがサイト内でホスト名を解決できるようになります。内部DNSサーバーの上には、企業、つまり外部のDNSサーバーがあります。内部DNSサーバーは、信頼できないリクエストは外部DNSサーバーへ転送します。外部DNSサーバーは、内部DNSサーバーの存在を知りません。詳細は、図6-29を参照してください。
方法1の詳細
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-7 内部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
方法2: 両サイトの各ノードのC:¥Windows¥system32¥drivers¥etc¥hostsファイルを編集します。この方法にはDNSサーバーの構成は含まれませんが、OracleAS Disaster Recovery環境内の各ノードのhostsファイルをメンテナンスする必要があります。たとえば、IPアドレスが変更されたら、すべてのノード上のファイルを更新し、ノードを再起動する必要があります。
方法2の詳細
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コマンドを実行し、キャッシュされた情報の消去および名前表の再ロードを実行します。詳細は、システム管理者に問い合せてください。
変更を行い、ノードを再起動した後で、次のコマンドを実行して、ノードがホスト名を適切に解決することを確認します。
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 this is a virtual IP address 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 physical IP address remote_infra.asha IN A 138.1.2.120 virtual IP address
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.1.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.1.0中間層またはOracleAS 10.1.2n.n中間層をインストールできます。n.nは0.0以上を表します。
OracleASリリース10.1.3.1.0では、任意の中間層タイプをインストールできます。
J2EEサーバーのインストールについては、5.2.4項「J2EEサーバーのインストール」を参照してください。
Webサーバーのインストールについては、5.2.5項「Webサーバーのインストール」を参照してください。
J2EEサーバーおよびWebサーバーのインストールについては、5.2.3項「J2EEサーバーおよびWebサーバーのインストール」を参照してください。
J2EEサーバー、WebサーバーおよびSOAスイートのインストールについては、5.2.2項「J2EEサーバー、WebサーバーおよびSOAスイートのインストール」を参照してください。
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.1.0）のOracleAS Guardスタンドアロン・インストールは、Companion CDのDisk 2に収録されています。このOracleAS Guardスタンドアロン・インストールは、次の環境にインストールできます。
OracleAS Guardがアップグレード・インストールされた場合は、dsa.conf構成ファイルのコピーを作成して、現在のOracleAS Guard環境の設定を保存します。OracleAS 10g（10.1.3.1.0）のOracleAS Guardスタンドアロン・インストール・キットを実行後、保存しておいたdsa.conf構成ファイルをリストアして、アップグレードされたOracleAS Guard環境で以前と同じ設定を使用できます。
OracleAS 10g（10.1.3.1.0）のOracleAS Guardスタンドアロン・インストール・キットを実行するには、次のディレクトリ・パスから実行します。
Windowsシステムの場合:
¥Disk2¥asg¥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.1.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=DSA
Oracle Data Guardの設定やOracleAS Metadata Repositoryデータベースの構成などのOracleAS Disaster Recovery環境の管理方法については、『Oracle Application Server高可用性ガイド』を参照してください。
|
 Copyright © 2007 Oracle Corporation. All Rights Reserved. |
|