Oracle Application Server 高可用性フレームワーク
3.2 アクティブ アクティブ アクティブ アクティブ / アクティブ・トポロジの管理 アクティブ・トポロジの管理 アクティブ・トポロジの管理 アクティブ・トポロジの管理
3.2.11 アクティブ アクティブ アクティブ アクティブ / アクティブ・トポロジからのインスタンスの削除 アクティブ・トポロジからのインスタンスの削除 アクティブ・トポロジからのインスタンスの削除 アクティブ・トポロジからのインスタンスの削除
インスタンスをトポロジから削除する手順は次のとおりです。
■ ロード・バランサを再構成し、削除したインスタンスにリクエストが送信されないように します。
■ インスタンスに追加したタグを削除して、インスタンスをOracleAS Clusterから削除しま す。これらのタグは、クラスタの設定時に追加したものです。詳細は、第3.2.1項
「OracleAS Clusterの設定」を参照してください。
■ 次のタグを削除して、アプリケーションレベルのクラスタリングからインスタンスを削除 します。
– クラスタリングが構成されているアプリケーションの一部であるすべてのWebモ ジュール用のweb.xmlファイルの、<distributable/>タグ。
– アプリケーションのorion-application.xmlファイルまたはグローバルの ORACLE_HOME/j2ee/home/config/application.xmlファイルに追加した
<cluster>タグ。
3.2.12 mod_oc4j のロード・バランシング・オプションの設定 のロード・バランシング・オプションの設定 のロード・バランシング・オプションの設定 のロード・バランシング・オプションの設定
Oracle HTTP Server内のmod_oc4jモジュールは、リクエストをOC4Jプロセスに委任します。
Oracle HTTP ServerがOC4Jに対するURLのリクエストを受信すると、Oracle HTTP Serverで
はそのリクエストをmod_oc4jモジュールにルーティングします。mod_oc4jモジュールでは、
このリクエストをOC4Jプロセスにルーティングします。OC4Jプロセスで障害が発生すると、
OPMNはその障害を検出し、mod_oc4jは、障害の発生したOC4Jプロセスが再起動されるま でそのOC4Jプロセスにリクエストを送信しません。
mod_oc4jは、OC4Jプロセスに対するリクエストをロード・バランシングするように構成でき
ます。Oracle HTTP Serverでは、mod_oc4jを経由して、各種のロード・バランシング・ポリ
シーをサポートしています。ロード・バランシング・ポリシーは、ネットワーク・トポロジや ホスト・マシンの性能に応じて、パフォーマンス上のメリットだけでなく、フェイルオーバー や高可用性も実現します。
mod_oc4jには、必要なルーティングのタイプと複雑さに応じて、異なるロード・バランシン
グ・ルーティング・アルゴリズムを指定できます。ステートレス・リクエストは、mod_
oc4j.confで指定されたアルゴリズムに基づいて使用可能な宛先にルーティングされます。ス
テートフルHTTPリクエストは、セッションIDを使用して前回のリクエストを処理したOC4J プロセスに転送されます。ただし、mod_oc4jがOPMNとの通信によってそのプロセスが使用 不可であると判断した場合を除きます。その場合、mod_oc4jは、指定されたロード・バランシ ング・プロトコルに従って使用可能なOC4Jプロセスにそのリクエストを転送します。
デフォルトでは、すべてのOC4Jインスタンスに同じ重みが付けられており(すべてのインス タンスに1の重みが付けられている)、mod_oc4jではラウンド・ロビン方法を使用して、リク エストの転送先のOC4Jインスタンスを選択します。OC4Jインスタンスの重みは、トポロジ内 の他の使用可能なOC4Jインスタンスの重みに対する比率として扱われ、インスタンスが処理 するリクエストの数が定義されます。リクエストが確立済のセッションに属する場合、mod_
oc4jでは、そのセッションを開始したのと同じOC4Jインスタンスおよび同じOC4Jプロセスに そのリクエストを転送します。
mod_oc4jのロード・バランシング・オプションでは、リクエストの送信先OC4Jインスタンス
を判断するとき、OC4Jインスタンス上で実行されているOC4Jプロセスの数を考慮しません。
OC4Jインスタンスの選択は、インスタンスに対して構成済の重みと、その可用性に基づいて行 われます。
mod_oc4jロード・バランシング・ポリシーを変更するには、ORACLE_
HOME/Apache/Apache/conf/mod_oc4j.confファイル内のOc4jSelectMethodディレク ティブとOc4jRoutingWeightディレクティブを設定します。
1. 各Oracle Application Serverインスタンスのmod_oc4j.confファイルの<IfModule mod_oc4j.c>セクションで、Oc4jSelectMethodディレクティブを表3-4に示す値のい ずれかに設定します。
Oc4jSelectMethodディレクティブをroundrobin:weightedまたは
random:weightedに設定した場合は、Oc4jRoutingWeightディレクティブも設定し て重みを指定します(次の手順を参照)。
ルーティング・アルゴリズムを選択する際のヒントについては、3-23ページの「mod_oc4j のロード・バランシング・アルゴリズムの選択」を参照してください。
表表
表表3-4 Oc4jSelectMethodの値の値の値の値 値
値 値
値 説明説明説明説明
roundrobin(デフォルト) mod_oc4jでは、トポロジ内のすべてのOC4Jプロセスをリストに配
置し、リスト内の順序に従ってプロセスを選択します。
roundrobin:local roundrobinと似ていますが、リストにはローカルのOC4Jプロセ
スのみが含まれています。利用可能なローカルOC4Jプロセスがな い場合は、リモートOC4Jプロセスを選択します。
roundrobin:weighted mod_oc4jでは、各インスタンスに構成されているルーティングの
重みに基づいて、各OC4Jインスタンスへのリクエストの合計ロー ドを分散します。次に、ラウンド・ロビン方式でローカルのインス タンスからOC4Jプロセスを選択します。
この重みは、Oc4jRoutingWeightディレクティブを使用して構 成します。
random mod_oc4jでは、トポロジ内のすべてのOC4Jプロセスのリストから
OC4Jプロセスをランダムに選択します。
random:local randomと似ていますが、mod_oc4jではローカルのOC4Jプロセス
が優先されます。利用可能なローカルOC4Jプロセスがない場合は、
リモートOC4Jプロセスを選択します。
random:weighted mod_oc4jでは、トポロジ内の各インスタンスに構成されている重
みに基づいて、OC4Jプロセスを選択します。
この重みは、Oc4jRoutingWeightディレクティブを使用して構 成します。
metric mod_oc4jでは、プロセスのビジー状況を示す実行時メトリックに
基づいて、リクエストをルーティングします。
metric:local metricと似ていますが、mod_oc4jではローカルのOC4Jプロセス
が優先されます。使用可能なローカルのOC4Jプロセスがない場合 は、リモートのOC4Jプロセスにルーティングされます。
例:
Oc4jSelectMethod random:local
メトリックベースのロード・バランシングの設定方法の詳細は、『Oracle HTTP Server管理 者ガイド』の付録「mod_oc4jを使用したロード・バランシング」を参照してください。
2. Oc4jSelectMethodディレクティブを重みベースの方法(つまり
roundrobin:weightedまたはrandom:weighted)に設定した場合は、
Oc4jRoutingWeightディレクティブも設定して重みを指定します。
Oc4jRoutingWeightの構文は次のとおりです。
Oc4jRoutingWeighthostnameweight
Oc4jRoutingWeightディレクティブを設定しない場合は、デフォルトの重みの1が使用 されます。
例: 3つのインスタンス(A、BおよびC)で構成されるトポロジがあり、BとCがAの2 倍のリクエストを受信するように設定するには、すべてのインスタンスに対して次のディ レクティブを設定します。
Oc4jSelectMethod roundrobin:weighted Oc4jRoutingWeight hostB 2
Oc4jRoutingWeight hostC 2
hostAのOc4jRoutingWeightの設定はオプションです。指定しない場合はデフォルト値
の1が使用されるためです。
3. トポロジ内のすべてのインスタンスに対してOracle HTTP Serverを再起動し、変更を反映 させます。
> opmnctl @cluster restartproc ias-component=HTTP_Server
mod_oc4jのロード・バランシング・アルゴリズムの選択のロード・バランシング・アルゴリズムの選択のロード・バランシング・アルゴリズムの選択のロード・バランシング・アルゴリズムの選択
mod_oc4jで使用するロード・バランシング・オプションを決定する際は、次のガイドラインが
役に立ちます。
■ Oracle HTTP ServerおよびOC4Jを同一のOracleホームで実行している、まったく同じマ
シンで構成されるトポロジでは、ローカル・アフィニティ・アルゴリズムによるラウン ド・ロビンが適しています。この場合、同じマシン上のOC4Jプロセスがすべて使用でき ないような極端なケースを除けば、mod_oc4jを使用して他のマシンにリクエストをルー ティングすることから得られるOracle HTTP Serverのメリットはほとんどありません。
■ あるマシンのセットではOracle HTTP Serverを実行し、別のセットではリクエストを処理 するOC4Jインスタンスを実行しているような、分散されたデプロイでは、単純なラウン ド・ロビンおよびメトリックベースのアルゴリズムが適しています。特定の設定で2つの アルゴリズムのどちらがより適しているかを決定するには、それぞれを試してみて結果を 比較することが必要な場合もあります。結果はシステムの動作および受信リクエストの分 散によって異なるため、こうした試行が必要になります。
■ 異なる特性を持つ複数のノードで、異なるOracle Application Serverインスタンスを実行 している異機種間の配置では、重み付けされたラウンド・ロビンのアルゴリズムが適して います。各インスタンスの重みを設定するだけでなく、各Oracle Application Serverイン スタンスで実行されるOC4Jプロセスの数も調整して、最大限の効果をあげるようにして ください。たとえば、重みが4のマシンは重みが1のマシンの4倍のリクエストを処理し ますが、重みが4のシステムは4倍の数のOC4Jプロセスを実行する必要があります。
■ メトリックベースのロード・バランシングは、たとえばCPU、データベース接続の数な ど、アプリケーションのパフォーマンスを決定するメトリックが数個しかない場合に便利 です。