• 検索結果がありません。

アクティブ アクティブ アクティブ アクティブ / アクティブ・トポロジからのインスタンスの削除 アクティブ・トポロジからのインスタンスの削除 アクティブ・トポロジからのインスタンスの削除 アクティブ・トポロジからのインスタンスの削除

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、データベース接続の数な ど、アプリケーションのパフォーマンスを決定するメトリックが数個しかない場合に便利 です。

Outline

関連したドキュメント