| Oracle Containers for J2EE構成および管理ガイド 10g（10.1.3.5.0） B56030-01 |
|
 戻る |
 次へ |
この章では、Oracle Application Server環境のクラスタ・トポロジと、Oracle Application Serverクラスタ内のOC4Jインスタンスのグループを構成および管理する方法について説明します。次の項目が含まれます。
アプリケーションのクラスタリング（セッションまたは状態のレプリケーションを目的としてOracle Application Serverノードにデプロイされたアプリケーションのクラスタリング）は、第9章「OC4Jでのアプリケーションのクラスタリング」で説明します。
この項では、Oracle Application Server 10gリリース3（10.1.3.5.0）でサポートされるクラスタリング方式の概要と、10.1.3リリースと旧リリースの機能の重要な変更点について説明します。次の項目が含まれます。
現行リリースでは、クラスタ・トポロジは、2つ以上の緩やかに接続されたOracle Application Serverノードとして定義されます。
クラスタ内での接続は、Oracle Application Serverコンポーネント（OC4JやOracle HTTP Serverなど）間の通信を管理するOracle Notification Server（ONS）の機能により提供されます。ONSサーバーは、Oracle Process Manager and Notification Server（OPMN）のコンポーネントで、すべてのOracle Application Serverホストにデフォルトでインストールされます。クラスタ・トポロジの構成時、実際には各Oracle Application Serverノードで稼働しているONSサーバーに接続しています。
Oracle Application Serverの旧リリースでは、完全に接続されたサーバー・ノードの集合のクラスタリングのみをサポートしていました。つまり、各ノードはONS構成ファイル（ons.conf）に明示的に指定する必要がありました。クラスタに対してノードが追加または削除されると、各サーバー・ノードで構成を更新し、サーバーを再起動する必要がありました。
現行リリースでは、新しい動的検出方式をサポートし、基本的にクラスタが自己管理できるようになりました。このフレームワークでは、各ONSは最新のクラスタ・トポロジのマップを保持します。新しいONSがクラスタに追加されると、既存のONSは、新しいノードとその接続情報をそれぞれのマップに追加します。同時に、新しいONSはすべての既存のノードをそのマップに追加します。また、ONSがクラスタから削除されると、残りのノードのマップにこの変更が反映されます。
Oracle Application Serverリリース3（10.1.3.0.0）では、ONS構成ファイル（ons.conf）は使用されません。かわりに、ONS構成データは、OPMN構成ファイルopmn.xmlの<notification-server>要素に設定されています。このファイルは、各ノードのORACLE_HOME/opmn/confディレクトリにあります。同様に、クラスタリング構成は、<topology>サブ要素内に設定されています。<notification-server>要素で使用できる<topology>サブ要素は1つのみです。
次の例に、opmn.xmlのクラスタ・トポロジ構成を示します。
<notification-server>
<topology>
<discover list="*225.0.0.20:8001"/>
</topology>
...
</notification-server>
<topology>要素に指定されたクラスタリング構成は、ノードにインストールされたOracle Application Serverコンポーネント（Oracle HTTP ServerやOC4Jなど）のすべてのインスタンスに適用されます。クラスタ・トポロジ内のすべてのノードは、opmn.xmlファイルに指定されているのと同じように構成されている必要があります。
次のクラスタリング・モデルがサポートされます。
動的ノード検出
この構成では、同じサブネット内の各ONSノードはマルチキャスト・メッセージでその存在を通知します。各ノードのクラスタ・トポロジのマップはノードが追加または削除されると自動的に更新され、クラスタは自己管理できるようになります。
構成手順は、「マルチキャストを使用した動的ノード検出の構成」を参照してください。
検出サーバーとしての静的ハブ
クラスタ内の特定のノードを、クラスタのトポロジ・マップを保持する検出サーバーとして機能するように構成します。他のノードは検出サーバーを介して相互に接続します。トポロジの検出サーバー・ハブは、別のトポロジのハブに接続できます。
「静的検出サーバーの構成」を参照してください。
分離されたトポロジのゲートウェイを介した接続
この構成は、指定されたゲートウェイ・ノードを使用して、ファイアウォールによって分離されたトポロジまたは別のサブネット上にあるトポロジを接続する場合に使用します。
詳細は、「トポロジ間ゲートウェイの構成」を参照してください。
手動によるノード構成
この構成では、クラスタ内の各ノードのホスト・アドレスおよびポートを手動で構成に指定します。これは、Oracle Application Server 10gリリース2（10.1.2）でサポートされていたものと同じクラスタリング方式で、主に下位互換性を提供するためにサポートされています。
手順は、「静的ノードツーノード通信の構成」を参照してください。
次に、Oracle Application Server 10gリリース3（10.1.3）のクラスタ構成における旧リリースからの変更点を示します。
Oracle Application Server 10g（10.1.3.1.0）では、OC4Jインスタンスはクラスタ・トポロジ内のグループに属しています。これにより、Oracle Application Serverクラスタ全体でグループに対してデプロイ、構成および管理操作を実行できます。
Oracle Application Server 10g（10.1.3.5.0）では、グループは管理者が任意の名前を使用して明示的に作成します。グループを作成したら、グループには、クラスタ・トポロジに属する任意のOC4Jインスタンスを移入できます。
|
注意: グループの作成および管理の手順は、Oracle Application Server 10g（10.1.3.0.0）から変更されました。10.1.3.0.0リリースを使用していた場合は、「Oracle Application Serverクラスタ内のOC4Jグループの作成および管理」で説明されている、10.1.3.5.0リリースにおけるグループの作成および管理の新しい手順を確認してください。 |
Distributed Configuration Management（DCM）フレームワークは、クラスタで共通の構成情報をレプリケートするために旧リリースのOracle Application Serverで使用されていましたが、現行リリースには含まれていません。つまり、次のことを意味します。
dcmctlコマンドライン・ユーティリティまたはApplication Server Controlを使用した構成はサポートされなくなりました。
現在、クラスタ構成は、クラスタ内の各ノードにインストールされているopmn.xmlファイルに手動でレプリケートする必要があります。
ONS構成ファイル（ons.conf）は使用されなくなりました。現在、ONS接続データは、OPMN構成ファイルopmn.xmlの<notification-server>要素に設定されています。このファイルは、OC4JまたはOracle HTTP Serverインスタンスを含む各ノードのORACLE_HOME/opmn/confディレクトリにあります。
クラスタ内のその他すべてのノードと接続するように、各ノードを手動で構成する必要はなくなりました。
OPMN管理環境のすべてのOC4Jインスタンスは、グループに属している必要があります。グループは、同じクラスタ・トポロジに属する一連のOC4Jインスタンスです。グループでは、グループ内のすべてのOC4Jインスタンスに対して、共通の構成、管理およびデプロイ・タスクを同時に実行できます。
|
注意: Oracle Application Serverクラスタのグループ内に存在するすべてのOC4Jインスタンスは、10.1.3.5.0など、同じリリースであることが必要です。 |
Application Server Controlを使用して、追加のグループを作成し、「グループ」ページからOC4Jインスタンスのグループに対して次のタスクを実行できます。
起動、停止および再起動などのプロセス管理操作
デプロイ、アンデプロイおよび再デプロイなどのデプロイ操作
JDBCデータソースやコネクション・プールの作成、変更または削除などのJDBC管理操作
JMS宛先の作成および削除、JMSコネクション・ファクトリの作成、変更または削除などのJMSプロバイダ操作
「グループ」ページを表示するには、「クラスタ・トポロジ」ページの「グループ」セクションでグループ名をクリックします。
アプリケーション・サーバー・インスタンスをインストールすると、デフォルトのOC4Jグループ（default_group）が自動的に作成されます。Oracle Application Server 10g（10.1.3.5.0）のインストール時に、デフォルト・グループに存在するデフォルトのOC4Jインスタンスがインストーラにより作成されます。その後、OC4Jインスタンスを追加してグループに編成できます。
たとえば、Oracle Application Serverクラスタ全体のグループのすべてのOC4Jインスタンスに特定のアプリケーションをデプロイするための新規グループを作成できます。その後、Application Server Controlの「グループ」ページを使用して、クラスタ全体でOC4Jグループ内のアプリケーションの全インスタンスに対してアプリケーション固有の構成の変更を実行できます。
次の各項では、1つ以上のOracle Application Serverクラスタ全体でレプリケートされたアプリケーションで、グループ操作を行うためにOC4Jインスタンスのグループを作成および管理する方法を説明します。
グループを使用すると、複数のOC4Jインスタンスに対して次の各タスクを一度で実行できます。
グループ内のすべてのOC4JインスタンスのOC4Jサーバー・プロパティの変更
グループ内のすべてのOC4Jインスタンスの起動または停止
グループ内の全OC4Jインスタンス上のアプリケーションのデプロイ、アンデプロイまたは再デプロイ
JDBCデータソースやコネクション・プールの作成、変更または削除などのJDBC管理操作の実行
JMS宛先の作成または削除、JMSコネクション・ファクトリの作成、変更または削除などのJMSプロバイダ操作の実行
Application Server Controlを使用したグループの管理手順:
「クラスタ・トポロジ」ページの「グループ」で、グループを選択します。
「管理」タブを選択します。
「管理」ページには、グループ全体の管理機能が表示されています。これらの機能には、セキュリティ・プロバイダの管理は含まれません。
Application Server Controlを使用した新規OC4Jグループの作成手順:
「クラスタ・トポロジ」ページの「グループ」で、「作成」を選択します。
「グループの作成」ページで次のようにします。
グループ名を指定します。
グループ名に使用できるのは英数字およびアンダースコアのみで、カッコ、ピリオド、ドル記号（$）、アスタリスク（*）またはカンマなどの特殊文字は使用できません。名前は、文字またはアンダースコアで開始する必要があります。
表8-1に、OC4Jインスタンスとグループの有効な名前および無効な名前の例を示します。
グループに移動するOC4Jインスタンスを選択します。
OC4Jインスタンスを新しいグループに移動すると、インスタンスは前のグループから削除されます。インスタンスを移動する前に停止しておく必要があります。
「作成」を選択します。
|
注意: 次のようにして、グループの作成後にOC4Jインスタンスをグループに移動することも可能です。
|
グループを作成すると、「クラスタ・トポロジ」ページのグループのリストに表示されます。「グループ内のOC4Jインスタンスの管理」で説明されているように、後からグループにOC4Jインスタンスを追加することや、グループからインスタンスを削除することが可能です。
次の操作中にグループを作成することも可能です。
新規OC4Jインスタンスの作成中
新規OC4Jインスタンスの作成時に、新規グループの作成、またはインスタンスの既存のグループの特定を実行できます。グループを指定しない場合、新規インスタンスはdefault_groupに割り当てられます。
グループからのOC4Jインスタンスの削除中
グループからのOC4Jインスタンスの削除時に、新規グループの作成、またはインスタンスの既存のグループの特定を実行できます。
|
注意: グループ間でのOC4Jインスタンスの移動には、次の制限が適用されます。
|
次に、複数のOC4Jインスタンスおよびグループを使用して、Oracle Application Server環境を管理する例を示します。
特定の目的のためにOC4Jインスタンスを作成します。たとえば、デフォルトのOC4Jインスタンスを管理OC4Jとし、Application Server Controlのデプロイにのみ使用します。本番アプリケーションのデプロイ用には別のOC4Jインスタンスを作成します。
パフォーマンスを向上させるために追加のOC4Jインスタンスを作成し、本番アプリケーションのロード・バランシングを実現します。
同じアプリケーションのデプロイ先であるOC4Jインスタンスをグループ化し、個々のOC4Jインスタンスではなく、そのグループに対してアプリケーション固有の変更を行えるようにします。また、個々のOC4Jインスタンスに何度もデプロイするのではなく、そのグループにアプリケーションを一度にデプロイできます。
OC4Jには、グループへの追加のOC4Jインスタンスの作成や、Oracle Application Serverクラスタ内のグループからのインスタンスの削除を実行するためのツールがあります。新規作成されたOC4Jインスタンスは、Application Server Controlを使用してアクセスおよび管理できます。
この項の内容は次のとおりです。
グループにOC4Jインスタンスを追加するには、次の方法があります。
Application Server Controlの「アプリケーション・サーバー」ページを使用
ORACLE_HOME/binディレクトリにインストールされているcreateinstanceユーティリティを使用
Application Server Controlを使用してOC4Jインスタンスを作成するには、次のようにします。
「クラスタ・トポロジ」ページで、Oracle Application Serverインスタンスの名前をクリックし、「アプリケーション・サーバー: instance_name」ページへ移動します。
「OC4Jインスタンスの作成」をクリックします。
「OC4Jインスタンスの作成」ページで、次の情報を入力します。
OC4Jインスタンス名: インスタンス名を入力します。
|
注意: homeはデフォルトのOC4Jインスタンスの名前用に予約されているため、homeをインスタンス名として入力することはできません。 |
次の項目のいずれかを選択します。
名前を指定して既存のグループに追加: 「既存のグループ名」からグループを選択します。
名前を指定して新規グループに追加: 「新規グループ名」フィールドで、新規グループの名前を入力します。
「作成後にこのインスタンスを起動します。」を選択します。
「作成」をクリックします。
インスタンスが作成されると確認画面が表示されます。このOC4Jインスタンスのパスワードは、インストール用にoc4jadminユーザーに使用されるパスワードと同じです。
createinstanceユーティリティを使用すると、次の構文でグループに追加のOC4Jインスタンスを作成できます。
createinstance -instanceName instanceName [-port httpPort] [-groupName group]
|
注意: homeはデフォルトのOC4Jインスタンスの名前用に予約されているため、instanceNameにhomeを指定することはできません。 |
スタンドアロンのOPMN管理OC4Jインスタンス（「J2EE Serverおよびプロセス管理」インストール・タイプ）にインスタンスを新規作成するときは、HTTPリスナー・ポートをhttpPortの値として指定する必要があります。このHTTPリスナー・ポートは、インスタンス用に作成されたWebサイト構成ファイルdefault-web-site.xmlに設定されます。
すべての新規OC4Jインスタンスがグループに割り当てられます。指定したグループが存在しない場合は、作成されます。-groupNameパラメータが指定されていない場合、インスタンスはdefault_groupグループに割り当てられます。
作成プロセスの一環として、パスワードの入力を要求されます。このパスワードは、このインスタンスのoc4jadminユーザーと関連付けられます。OPMNでの問題を回避するために、oc4jadminユーザーが管理インスタンスのApplication Server Controlへのアクセスに使用するのと同じパスワードを入力することをお薦めします。
作成操作の一部として、新規インスタンスは既存のopmn.xmlファイルに追加されます。OPMNが新規インスタンスを認識していることを確認するために、作成操作の最後にOPMNのリロードが実行されます。このリロードでは、createinstanceユーティリティがOPMNの構成に使用されたMBeanServerに接続している必要があります。新規OC4Jインスタンスのパスワードは、認証に使用されます。新規インスタンスのパスワードがMBeanServerが稼働しているインスタンスのパスワードと異なる場合は、エラーが戻されます。このためにインスタンスが作成されないことはありませんが、OPMNまたはその他のコンポーネントが新規インスタンスに接続する必要がある場合に問題の原因になります。そのため、すべてのOC4JインスタンスをターゲットのOracle Application Serverクラスタに同じパスワードで作成することをお薦めします。
また、ユーザーがグループ操作を実行できるように、Oracle Application Serverクラスタ内に存在するグループの各OC4Jインスタンスのoc4jadminユーザーに同じパスワードを指定する必要があります。
|
注意:
|
HTTPポートを-portの値に指定できます。この機能は、Oracle Application ServerインスタンスにOracle HTTP Serverが含まれない場合に必要です。HTTPポートを設定すると、OC4Jインスタンスのホームページに直接アクセスできるようになります。
新規インスタンスは、デフォルトのhome OC4Jインスタンスと同じ場所の、新しいORACLE_HOME/j2ee/instanceディレクトリ内に作成されます。インスタンス構成が指定される新しい<process-type>要素もopmn.xml構成ファイルに追加されます。
homeインスタンスの<process-type>要素は、homeインスタンスと同じ設定で作成される新規OC4Jインスタンスのテンプレートとして機能します。opmn.xmlファイルに存在するインスタンスの<process-type>要素のheapsize、numprocsおよびtimeout属性値などの設定を変更することで、新規インスタンスの構成を変更できます。OC4Jインスタンスの構成を変更した場合は、変更内容が反映されるようにそのインスタンスを再起動する必要があります。
次のディレクトリおよびファイルは、新しいORACLE_HOME/j2ee/instanceディレクトリ構造で生成されます。
applib/ applications/ config/ contains default versions of all server-level configuration files config/database-schemas/ contains all database schema XML files packaged with OC4J connectors/ contains RAR files packaged with OC4J log/ persistence/
新規インスタンスには、OC4Jバイナリ・ライブラリが含まれません。かわりに、homeインスタンスにインストールされたライブラリを利用します。この新規インスタンスには、defaultアプリケーションはデプロイされますが、他のデプロイ済アプリケーション（Application Server Controlなど）のバイナリおよび構成ファイルはコピーされません。
OPMNによって起動された新規インスタンスは、Application Server Controlの「クラスタ・トポロジ」ページからアクセスできます。
oc4jadminユーザーとしてログインし、createinstanceユーティリティを使用してインスタンスを作成したときに設定したパスワードを指定します。
ログインすると、アプリケーションのデプロイなどのあらゆる管理者タスクをインスタンスで実行できます。
「OC4Jインスタンスのグループの作成」で説明されているように、別のグループに移動するか削除することで、グループからOC4Jインスタンスを削除できます。OC4Jインスタンスを削除するには、次の方法があります。
Application Server ControlでOC4JインスタンスがインストールされているOracle Application Serverの「アプリケーション・サーバー」ページを使用
ORACLE_HOME/binディレクトリにインストールされているremoveinstanceユーティリティを使用
どちらの方法でも、j2eeディレクトリ構造からインスタンスに作成されたディレクトリが削除され、opmn.xmlからインスタンスの構成データが削除されます。OC4Jインスタンスの削除には次のガイドラインが適用されます。
インストール中にOracle Application Serverによって作成されたOC4J homeインスタンスは削除できません。
インストール後にユーザーによって作成されたOC4Jインスタンスは削除できます。
削除するOC4Jインスタンスは停止状態である必要があります（Application Server Controlによって実行されます）。
removeinstanceツールの使用時にOPMNが稼働している場合は、opmnctl reloadを起動して更新済のopmn.xmlをランタイムにリロードする必要があります。
Application Server Controlを使用してOC4Jインスタンスを削除するには、次のようにします。
「クラスタ・トポロジ」ページで、OC4Jインスタンスが稼働しているOracle Application Serverインスタンスの名前をクリックし、「アプリケーション・サーバー: instance_name」ページへ移動します。
削除するインスタンスの「削除」アイコンをクリックします。
「確認」ページで、「はい」をクリックします。
インスタンスが削除されると確認画面が表示されます。
OC4Jインスタンスは、removeinstanceユーティリティを使用して削除できます。このユーティリティは、ORACLE_HOME/j2eeディレクトリ構造からインスタンス用に作成されたディレクトリを削除し、opmn.xmlからインスタンスの構成データを削除します。
removeinstanceユーティリティは、ORACLE_HOME/binディレクトリにインストールされています。構文は次のとおりです。
removeinstance -instanceName instanceName
ユーティリティを使用してインスタンスを削除するには、次のようにします。
インスタンスを停止します。
ORACLE_HOME/opmn/bin/opmnctl stopproc process-type=oc4J_instanceName
インスタンスを削除します。
ORACLE_HOME/bin/removeinstance -instanceName oc4J_instanceName
Oracle Application Serverリリース3（10.1.3）にはDistributed Configuration Management（DCM）フレームワークが用意されていないため、Oracle Application Server 10.1.3ではクラスタ内での構成ファイルの同期が変更されました。表8-2に、レプリケートが必要なファイルをまとめます。
リリース10.1.3.1.0で導入されたOC4Jのグループ化機能（「OC4Jインスタンスのグループの作成」を参照）を使用すると、Application Server Control、admin_client.jarコマンドライン・ユーティリティまたはOC4J Antタスクを使用して、OC4Jインスタンスのグループ全体に一貫してEAR、WAR、RARおよび共有ライブラリをデプロイできます。これにより、OC4Jインスタンスのグループ内のモジュール・レベルで一貫性のある構成を実現できます。これらのツールを使用したOC4Jインスタンスのグループへのデプロイの詳細は、第6章「admin_client.jarユーティリティの使用方法」および『Oracle Containers for J2EEデプロイメント・ガイド』を参照してください。
特定の構成ファイルでは、管理者はグループ化機能を使用して、Application Server Control、admin_client.jarコマンドライン・ユーティリティおよびOC4J Antタスクから、OC4Jインスタンスのグループ全体のデータソース、コネクション・プールおよびJMSリソースを構成することもできます。特に、この機能がサポートされている構成ファイルは、data-sources.xmlおよびjms.xmlです。
複数のOC4Jプロセス全体で一貫性のある構成にするには、Oracle Application Serverの複数のJVM機能を使用します。この機能を使用すると、単一のOC4J構成が同時に実行されるJVMインスタンスの数（n）を設定できます。その結果、一貫性のある単一の構成セットから、同じOC4Jインスタンスを実行しているn個のOC4Jプロセスが起動されます。単一の構成セットの任意のファイルを変更すると、JVMセットの番号に対応して、起動されたすべてのOC4Jプロセスが更新されます。OC4JインスタンスごとにJVMの番号を構成する方法は、「複数のJVMでのOC4Jインスタンスの稼働」で説明されています。
アプリケーションの構成を変更するためにクラスタ全体を手動で構成する必要がある場合に備え、表8-2に、これらの特定の機能だけでなく、すべての構成ファイルとその使用方法を説明します。
表8-2 クラスタでレプリケートする構成ファイル
| ファイル | ORACLE_HOMEでの場所 |
レプリケートまたは管理対象データ |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
この項では、次のクラスタリング・モデルを構成する手順について説明します。
動的ノード検出は、最も単純なクラスタリング構成です。このモデルでは、各ONSノードは、その存在を通知する単純なマルチキャスト・メッセージをブロードキャストし、クラスタ内のノードが相互に動的に検出できるようにします。
次のツールは、マルチキャスト検出を使用してOC4Jインスタンスをクラスタに追加するために使用できます。
opmnctl
このユーティリティには、マルチキャストのport:addressでopmn.xmlを更新するためのコマンドと、インスタンスをクラスタに追加するために必要なWebサイト構成データが含まれます。詳細は、「opmnctlによるマルチキャスト検出の構成」を参照してください。
opmnassociate
このユーティリティは、OC4Jインスタンスをクラスタに追加するためのワンステップ・ソリューションを提供します。詳細は、「opmnassociateによるマルチキャスト検出の構成」を参照してください。
|
注意: Oracle Application Serverインスタンスは、インストール時にクラスタに追加できます。 |
各ONSは、クラスタ・トポロジのマップを独自に保持します。新しいONSがクラスタに追加されると、既存のONSは、新しいノードとその接続情報をそれぞれのマップに追加します。同時に、新しいONSはすべての既存のノードをそのマップに追加します。また、ONSがクラスタから削除されると、残りのノードのマップにこの変更が反映されます。
マルチキャスト・メッセージは異なるネットワーク構成によって制限されるため、動的ノード検出は、同じサブネット上にあるONSノードに対してのみのオプションとなる場合があります。ただし、動的ノード検出を使用する複数のサブネットは、ゲートウェイ・サーバーを使用して接続できます。詳細は、「トポロジ間ゲートウェイの構成」を参照してください。
|
注意:
|
動的検出の構成は、トポロジ内の各Oracle Application Serverインスタンスにあるopmn.xmlファイルの<topology>要素の<discover>サブ要素内に設定されます。新しいノードをクラスタに追加するには、この要素をopmn.xmlファイルに追加するだけです。クラスタからノードを削除するには、この要素を削除します。
マルチキャストIPアドレスおよびポートは、list属性の値として設定します。IPアドレスの前のアスタリスク（*）は、指定された値がマルチキャスト・アドレスであることをOPMNに伝えるため、重要です。複数の値は、それぞれをカンマで区切って指定できます。
<opmn>
<notification-server>
<port ... />
<ssl ... />
<topology>
<discover list="*225.0.0.20:8001"/>
</topology>
</notification-server>
...
</opmn>
|
注意: opmn.xmlファイルの変更を有効にするには、リロードする必要があります。対象となるノードで次のコマンドを実行し、opmn.xmlをリロードします。
opmnctl reload このコマンドは、OPMN管理コンポーネント（Oracle HTTP Server、OC4Jおよびデプロイ済アプリケーションなど）には影響を与えません。 |
OPMNコマンドライン・ツールopmnctlでは、新しいconfig topologyコマンドをサポートします。このコマンドを使用すると、opmn.xml内でマルチキャストの<discovery>エントリを指定、更新または削除できます。
opmnctlツールは、各ノードのORACLE_HOME/opmn/binディレクトリにインストールされています。このツールは各ノードで個別に実行する必要があり、そのノードのopmn.xmlファイルのみが更新されます。
|
OPMN管理スタンドアロンOC4Jインスタンスの追加に関する注意: OPMN管理のOC4Jインスタンスには、Oracle HTTP Server（「J2EE Serverおよびプロセス管理」インストール・タイプ）は含まれません。デフォルトWebサイトは、デフォルトでHTTPリクエストをリスニングするように構成されます。 インスタンスをクラスタに追加する際に、Apache JServ Protocol（AJP）を使用するようにWebサイトを構成する必要があります。この変更は、OC4JインスタンスがOracle HTTP Serverからのリクエストを受信し応答できるようにするために必要です。 デフォルトのWebサイトで使用されるプロトコルおよびポートは、Application Server Controlの「ランタイム・ポート」ページを使用して構成できます。 |
検出データの挿入または更新
updateコマンドは、<discover>要素を指定された値で挿入または更新します。構文は次のとおりです。
opmnctl config topology update discover="*multicastAddress:multicastPort"
次に例を示します。
opmnctl config topology update discover="*225.0.0.20:8001" opmnctl reload
検出データの削除
deleteコマンドは、<discover>要素をopmn.xmlから削除し、事実上ノードをクラスタから削除します。<topology>要素に他のサブ要素がない場合は、同様に削除されます。
opmnctl config topology delete discover opmnctl reload
opmnassociateユーティリティは、マルチキャスト検出を使用してデフォルトのhome OC4Jインスタンスをクラスタに追加します。このユーティリティは、次の手順を実行します。
opmn.xmlの<discover>要素に、指定されたマルチキャスト・アドレスおよびポートを挿入または更新します。
opmn.xmlの対応する<port>要素を変更して、Apache JServ Protocol（AJP）を使用してOracle HTTP Serverからのリクエストを受信し応答するようにデフォルトWebサイトを構成します。
OPMNを再起動し、新しい構成をランタイム環境にロードします。
opmnassociateツールは、各OC4JインスタンスのORACLE_HOME/binディレクトリにインストールされています。このツールは各インスタンスで個別に実行する必要があり、そのインスタンスのopmn.xmlファイルのみが更新されます。
LinuxまたはUNIX環境での構文は次のとおりです。
opmnassociate.sh "*multicastAddress:multicastPort" [-restart]
次に例を示します。
opmnassociate.sh "*225.0.0.20:8001" -restart
Windows環境での構文は次のとおりです。
opmnassociate "*multicastAddress:multicastPort" [-restart]
次に例を示します。
opmnassociate "*225.0.0.20:8001" -restart
IPアドレスの前にアスタリスク（*）を付ける必要があります。
|
注意: opmnassociateユーティリティは、デフォルトのhome OC4Jインスタンスをクラスタに追加する場合にのみ使用できます。home2などの別のOC4Jインスタンスを追加する場合は、「opmnctlによるマルチキャスト検出の構成」に説明されているように、opmnctlユーティリティを使用します。一般的に、opmnassociateは、マルチキャスト検出を構成するために設定されている、より完全なopmnctlコマンドを簡略化したものです。マルチキャスト検出の構成には、opmnctlを使用することをお薦めします。 |
この構成はpeer-to-peerクラスタリング・モデルに似ており、同じクラスタ内に、静的ハブまたは検出サーバーとして機能するように構成された1つ以上のONSノードがあります。
クラスタ内の各ONSノードは、クラスタ・トポロジのマップを保持する検出サーバーと接続を確立します。検出サーバーは、接続ノードに最新のトポロジ・マップを提供し、接続ノードがクラスタ内の他のONSノードと通信できるようにします。
opmnctlを使用すると、静的検出サーバーへの接続を構成できます。詳細は、「opmnctlによる静的検出サーバー接続の構成」を参照してください。
クラスタ内の各静的ハブ・ノードにあるopmn.xmlファイルの<discover>要素内に、検出サーバーのTCP/IP接続情報を設定します。次に例を示します。
<opmn> <notification-server> <port ... /> <ssl ... /> <topology> <discover list="node1.company.com:6200"/> </topology> </notification-server> ... </opmn>
必須情報は次のとおりです。
静的検出サーバーのホスト名またはIPアドレス
OPMNのremoteポート。次に示すように、静的サーバーにインストールされているopmn.xmlファイル内の<port>要素に定義されています。
<port local="6100" remote="6200" request="6003"/>
|
注意: opmn.xmlファイルは、OPMNランタイムで変更を有効にするためにリロードする必要があります。対象となるノードで次のコマンドを実行し、opmn.xmlをリロードします。
opmnctl reload このコマンドは、OPMN管理コンポーネント（Oracle HTTP Server、OC4Jおよびデプロイ済アプリケーションなど）には影響を与えません。 |
OPMNコマンドライン・ツールopmnctlでは、新しいconfig topologyコマンドをサポートします。このコマンドを使用すると、opmn.xml内で<discover>エントリを指定、更新または削除できます。
opmnctlツールは、各ノードのORACLE_HOME/opmn/binディレクトリにインストールされています。このツールは各ノードで個別に実行する必要があり、そのノードのopmn.xmlファイルのみが更新されます。
検出データの挿入または更新
updateコマンドは、<discover>要素を指定された値で挿入または更新します。構文は次のとおりです。
opmnctl config topology update discover="serverHost:opmnRemotePort"
次に例を示します。
opmnctl config topology update discover="node.company.com:6200" opmnctl reload
検出データの削除
deleteコマンドは、<discover>要素をopmn.xmlから削除し、事実上ノードをクラスタから削除します。<topology>要素に他のサブ要素がない場合は、同様に削除されます。
opmnctl config topology delete discover opmnctl reload
クラスタ・トポロジが異なるサブネット上にある、またはファイアウォールや物理的な場所によって分離されている状況では、特定のONSノードをゲートウェイとして構成し、ONS通知を異なるトポロジ間で送信できるようにすることができます。
このモデルでは、それぞれの分離されたトポロジ内のONSノードはゲートウェイ・サーバーとして構成され、クラスタへのエントリ・ポイントとなります。ゲートウェイ構成は、<topology>要素の<gateway>サブ要素内に指定されます。
ソース・ゲートウェイ・ノードとその接続先の各ターゲット・ノードのホストおよびポートは、list属性の値として設定します。ノードがリストされる順序は重要ではありません。
ノードごとに、サーバーのホスト名またはIPアドレスと、OPMNのremoteポートを指定します。このポートは、次に示すように、静的サーバーにインストールされたopmn.xmlファイルの<port>要素に定義されています。
<port local="6100" remote="6200" request="6003"/>
各ノードのデータをアンパサンド（&）で区切ります。
ノードのリストの最後に/を1つ指定します。
次の例に、ゲートウェイ・ノードnode2およびnode3と接続するnode1に対するopmn.xmlの構成を示します。同じ構成をこれらのゲートウェイ・ノードのそれぞれに設定できます。リストの最後の/に注意してください。
<opmn>
<notification-server>
<port ... />
<ssl ... />
<topology>
<discover list="*224.0.0.37:8205"/>
<gateway list="node1.com:6201&node2.com:6202&node3.com:6203/"/>
</topology>
</notification-server>
...
</opmn>
<gateway>要素の他に、<topology>要素に<discover>要素があることに注意してください。この要素には、ノード独自のクラスタ内で動的検出に使用されるマルチキャスト・アドレスおよびポートが指定されています。
あるいは、前述の例の<topology>要素全体を、クラスタ・トポロジ内のすべてのノードにあるopmn.xmlファイルにコピーできます。node1のみが<gateway>構成を利用します。つまり、他のノードによって無視されます。
構成を単純化するには、すべてのゲートウェイ・ノード（ソースおよびターゲット）の接続データを<gateway>サブ要素に設定した後、この要素を各ゲートウェイ・ノードにあるopmn.xmlファイルにコピーします。ここでも、ノードの順序は重要ではありません。各ノードはリストの自身のエントリを無視するだけです。
|
注意: opmn.xmlファイルは、OPMNランタイムで変更を有効にするためにリロードする必要があります。対象となるノードで次のコマンドを実行し、opmn.xmlをリロードします。
opmnctl reload このコマンドは、OPMN管理コンポーネント（Oracle HTTP Server、OC4Jおよびデプロイ済アプリケーションなど）には影響を与えません。 |
localhostを使用する単一のマシンで作業している場合は、<notification-server>要素の<ipaddr>サブ要素にIPアドレスを追加し、クラスタの<port>要素に定義されているようにlocalhostのOPMNリモート・ポートを参照するよう、<discover>要素に検出リストを明示的に設定します。次にこの構成の例を示します。
<notification-server>
<ipaddr remote="127.0.0.1" request="127.0.0.1"/>
<port local="6101" remote="6201" request="6004"/>
<ssl enabled="true"
wallet-file="$ORACLE_HOME\opmn\conf\ssl.wlt\default"/> <topology>
<discover list="localhost:6201"/>
</topology>
</notification-server>
localhost IPアドレス127.0.0.1を指定すると、マシンはネットワークに接続していても接続していなくても動作します。
この静的構成モデルは、基本的にはOracle Application Server 10.1.2および9.0.4で使用されたものと同じ方式です。このモデルは、主にこれらの旧リリースとの下位互換性を提供するためにサポートされています。
この構成では、クラスタ内の各ノードのホスト・アドレスおよびONSリモート・リスナー・ポートを含むノード・リストを指定します。Oracle Application Serverリリース3（10.1.3.0.0）より前のリリースでは、ONS構成データがopmn.xmlに統合される場合、この構成はons.conf構成ファイルに設定されていました。
クラスタ内の各ノードのホスト・アドレスおよびONSリモート・リスナー・ポート（<notification-server>の<port>サブ要素内に指定）を<nodes>サブ要素内に定義します。各ノードはカンマで区切ります。
次に例を示します。
<opmn> <notification-server> <port local="6101" remote="6202" request="6004"/> <ssl ... /> <topology> <nodes list="node1-sun:6201,node2-sun:6202"/> </topology> </notification-server> ... </opmn>
クラスタ内の各ノードに同じリストを指定します。各ONSインスタンスは、リストで自身を識別し、そのエントリを無視します。
|
注意: opmn.xmlファイルは、OPMNランタイムで変更を有効にするためにリロードする必要があります。対象となるノードで次のコマンドを実行し、opmn.xmlをリロードします。
opmnctl reload このコマンドは、OPMN管理コンポーネント（Oracle HTTP Server、OC4Jおよびデプロイ済アプリケーションなど）には影響を与えません。 |
opmnctlまたはApplication Server Controlを使用して、クラスタ内のOracle Application Serverコンポーネントの現行のステータスを表示できます。
クラスタ内のOracle Application Serverノードでopmnctlを使用して、クラスタのステータスをチェックできます。
opmnctl @cluster status
出力には、クラスタ内のアクティブな各Oracle Application Serverインスタンスにインストールされたコンポーネントのステータスが示されます。
Processes in Instance: AppSrv1.comp1.yourcompany.com -------------------+--------------------+---------+--------- ias-component | process-type | pid | status -------------------+--------------------+---------+--------- OC4JGroup:COLORS | OC4J:home | 26880 | Alive OC4JGroup:COLORS | OC4J:oc4j_soa | 26256 | Alive HTTP_Server | HTTP_Server | 26879 | Alive Processes in Instance: AppSrv2.comp2.yourcompany.com-------------------+--------------------+---------+--------- ias-component | process-type | pid | status -------------------+--------------------+---------+--------- OC4JGroup:COLORS | OC4J:home | 26094 | Alive OC4JGroup:COLORS | OC4J:oc4j_soa | N/A | Down HTTP_Server | HTTP_Server | 26093 | Alive
ロード・バランシングという用語は、クラスタ内のサーバー・インスタンスに受信サービス・リクエストを分散するプロセスを指します。Oracle Application Serverクラスタでのロード・バランシングは、Oracle HTTP Serverのmod_oc4jモジュールによって管理されます。この構成では、Oracle HTTP Serverインスタンスは受信HTTPおよびHTTPSリクエストに対するフロントエンド・リスナーとして機能します。mod_oc4jはリクエストされたアプリケーションを提供するOC4Jインスタンスに各リクエストをルーティングします。
Oracle Application Serverリリース3（10.1.3）では、ロード・バランシングは、同じクラスタに属するOracle Application Serverインスタンスに対しては完全に動的です。Oracle HTTP Serverまたはmod_oc4jをさらに構成する必要はありません。
動的OC4Jインスタンス検出
Oracle HTTP Serverインスタンスではクラスタ内の各OC4Jインスタンスとそこにデプロイされたアプリケーションに関する情報が動的に更新され、Oracle HTTP Serverが適切なインスタンスにリクエストをルーティングできるようになります。
詳細は、「アプリケーション・マウント・ポイントの動的構成の有効化」を参照してください。
動的ルーティング
新しいリリースでは、ルーティングID方式をサポートしています。この方式を使用すると、Oracle HTTP Serverインスタンスがリクエストを転送するOC4Jインスタンスを必要に応じて制御できます。基本的には、特定のOracle HTTP Serverインスタンスからのリクエストを処理する一連のOC4Jインスタンスを制御できるようになります。すべてのOracle HTTP ServerおよびOC4Jインスタンスは、インストール時にデフォルトのルーティングIDを使用するように構成されるため、構成は不要です。
詳細は、「WebサーバーのルーティングIDを使用したOC4Jリクエスト・ルーティングの制御」を参照してください。
クラスタ内の様々なOracle HTTP ServerおよびOC4JインスタンスのONSサーバーが、この章で説明しているクラスタリング構成方式のいずれかを使用して接続されることが唯一の要件です。詳細は、「クラスタの構成」を参照してください。
OPMN管理のインストールでは、すべてのOracle HTTP ServerおよびOC4JインスタンスにルーティングIDが割り当てられます。このIDは、opmn.xmlに定義されています。Oracle HTTP Serverインスタンスは、ルーティングIDを共有するOC4Jインスタンスにのみ受信Webリクエストをルーティングします。つまり、特定のOracle HTTP Serverインスタンスがリクエストをルーティングする一連のOC4Jインスタンスを事実上定義できます。
デフォルトのルーティングIDがすべてのコンポーネント・インスタンスに割り当てられるため、インストールと同時に、クラスタ内のすべてのOracle HTTP Serverインスタンスはリクエストをクラスタ内のOC4Jインスタンスにルーティングできます。
一般的なOracle Application Serverクラスタでは、ユーザーからのリクエストは1つ以上のOracle HTTP Serverインスタンスによって受信され、それらのリクエストはクラスタ内にデプロイされたアプリケーションにルーティングされます。各アプリケーション・サーバー、OC4Jインスタンス、グループおよびデプロイ済アプリケーションのルーティングIDにより、Oracle HTTP Serverがそれぞれのリクエストをルーティングする宛先が決定されます。
|
注意: アプリケーション・サーバー、コンポーネントまたは個々のアプリケーションのルーティングIDを変更すると、HTTPリクエストがデプロイ済アプリケーションに送信されなくなる場合があります。クラスタ内でそのアプリケーションの別のインスタンスが使用可能で、ルーティングIDが同一である場合以外は、この変更によってユーザーがアプリケーションを使用できなくなる可能性があります。 |
これ以降では、次の各項でルーティングIDの変更方法を説明します。
AJPリクエストをリスニングするWebサイトの構成方法の詳細は、「Webサイト接続データの構成」を参照してください。
Application Server Controlを使用して、クラスタの各アプリケーションおよびコンポーネントに割り当てられたルーティングIDを変更または表示するには、次のようにします。
「クラスタ・トポロジ」ページに移動します。
ページの「管理」セクションまでスクロールし、「ルーティングID構成」をクリックします。
「ルーティングID構成」ページには、クラスタ・トポロジ内のコンポーネントおよびアプリケーションの階層が表示されます。たとえば、アプリケーション・サーバーの「拡張」アイコンをクリックすると、そのアプリケーション・サーバー・インスタンス内のグループが表示されます。各グループ内には、グループを構成するOC4Jインスタンスが表示されます。また、特定のOC4Jインスタンスを開くと、そのOC4Jインスタンスにデプロイされているアプリケーションが表示されます。
デフォルトで、アプリケーション・サーバー・インスタンスにルーティングIDが割り当てられ、グループ、OC4Jインスタンスおよびアプリケーションは、アプリケーション・サーバーのルーティングIDを継承します。特定のグループ、OC4Jインスタンスまたはアプリケーションに別のルーティングIDを入力すると、アプリケーション・サーバーから継承されたルーティングIDは新しいルーティングIDで上書きされます。
クラスタ内で複数のアプリケーション・サーバー・インスタンスを管理している場合、あるOC4Jインスタンスをメンバーとして含むグループがアプリケーション・サーバーごとに1つずつ表示されるため、同じグループが階層に複数表示されます。これは、「ルーティングID構成」ページの階層が、各アプリケーション・サーバーのOracleホーム・ディレクトリに格納されているOracle Process Management and Notification（OPMN）ソフトウェアの構成ファイル（opmn.xml）に基づいているためです。そのため、グループのルーティングIDを変更する際には注意してください。特定のOracle HTTP Serverリクエストをグループ内の一部のOC4Jインスタンスにのみルーティングする必要がある場合を除き、「ルーティングID構成」ページでは、グループのすべてのインスタンスに同じルーティングIDを割り当ててください。
ルーティングIDは、opmn.xmlの、id属性がrouting-idである<data>要素に定義されます。<data>要素エントリは、起動時にインスタンスに渡されるパラメータを指定する<category id="start-parameters">のサブ要素です。インスタンスごとに設定されるデフォルトのrouting-id値は、g_rt_idです。
<category id="start-parameters">
<data id="routing-id" value="g_rt_id"/>
</category>
デフォルトのルーティングIDが指定されている<data>要素は、Oracle Application ServerインスタンスのOPMN構成データが指定されている<ias-instance>要素内に設定されます。ルーティングIDはこのレベルに設定されるため、この<data>要素に設定されるrouting-id値は、Oracle Application Serverインスタンス内にインストールされるOracle HTTP ServerおよびOC4Jコンポーネントのすべてのインスタンスに適用されます。
<opmn> <process-manager> ... <ias-instance id="instance1" name="instance1"> ... <environment> ... </environment> <module-data> <category id="start-parameters"> <data id="routing-id" value="g_rt_id"/> </category> </module-data> </environment> <ias-component id="HTTP_Server"> ... </ias-component> <ias-component id="default_group"> ... </ias-component> </ias-instance> </process-manager> </opmn>
しかし、ルーティングIDは、コンポーネントの<category id="start-parameters">要素内に<data>要素を追加して、個々のOracle HTTP ServerまたはOC4Jインスタンス・レベルに設定できます。この値は、Oracle Application Serverインスタンス・レベルに割り当てられたルーティングIDに優先します。
routing-id属性の値には任意の文字列を指定できます。この識別子には特定の書式はありません。opmn.xmlの次のエントリは、Oracle HTTP ServerインスタンスのルーティングIDを設定します。
<opmn>
<process-manager>
...
<ias-instance id="instance1" name="instance1">
...
<ias-component id="HTTP_Server">
<environment>
...
</environment>
<process-type id="HTTP_Server" module-id="OHS">
<module-data>
<category id="start-parameters">
<data id="start-mode" value="ssl-enabled"/>
<data id="routing-id" value="group_b_id"/>
</category>
</module-data>
<process-set id="HTTP_Server" numprocs="1"/>
</process-type>
</ias-component>
</ias-instance>
</process-manager>
</opmn>
opmn.xmlの次のエントリは、OC4JのhomeインスタンスのルーティングIDを設定します。
<opmn>
<process-manager>
...
<ias-instance id="instance1" name="instance1">
...
<ias-component id="default_group">
<environment>
</environment>
<process-type id="home" module-id="OC4J" status="enabled">
<module-data>
<category id="start-parameters">
<data id="java-options" ... />
<data id="routing-id" value="group_b_id"/>
</category>
</module-data>
<process-set id="HTTP_Server" numprocs="1"/>
<port id="default-web-site" range="12501-12600" protocol="ajp" />
<port id="rmi" range="12401-12500"/>
<port id="jms" range="12601-12700"/
<port id="rmis" range="12701-12800"/
<process-set id="default_group" numprocs="1"/>
</process-type>
</ias-component>
</ias-instance>
</process-manager>
</opmn>
Oracle HTTP Server内のmod_oc4jモジュールにより、OC4Jプロセスにリクエストが委任されます。Oracle HTTP ServerがOC4Jを対象としたURLのリクエストを受信すると、Oracle HTTP Serverによりmod_oc4jモジュールにリクエストがルーティングされます。その後、このモジュールによりそのリクエストはOC4Jプロセスにルーティングされます。OC4Jプロセスが失敗すると、OPMNにより障害が検出され、mod_oc4jはOC4Jプロセスが再起動されるまで失敗したOC4Jプロセスにリクエストを送信しません。
mod_oc4jを構成して、OC4Jプロセスへのリクエストをロード・バランシングできます。Oracle HTTP Serverでは、mod_oc4jを介して、様々なロード・バランシング・ポリシーをサポートしています。ロード・バランシング・ポリシーには、フェイルオーバーおよび高可用性に加え、ネットワーク・トポロジおよびホスト・マシンの性能に応じてパフォーマンス上の利点もあります。
必要とするルーティングのタイプや複雑さに応じて、mod_oc4jに異なるロード・バランシング・ルーティング・アルゴリズムを指定できます。ステートレス・リクエストは、mod_oc4j.confに指定されているアルゴリズムに基づいて使用可能な任意の宛先にルーティングされます。ステートフルHTTPリクエストは、セッション識別子を使用して前のリクエストを処理した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ディレクティブを設定します。
各Oracle Application Serverインスタンスのmod_oc4j.confファイルにある<IfModule mod_oc4j.c>セクションで、Oc4jSelectMethodディレクティブに表8-3に示す値のいずれかを設定します。
Oc4jSelectMethodディレクティブをroundrobin:weightedまたはrandom:weightedに設定した場合は、Oc4jRoutingWeightディレクティブに重み付けを指定する必要もあります（次の手順を参照）。
ルーティング・アルゴリズムの選択の詳細は、「mod_oc4jのロード・バランシング・オプションの選択」を参照してください。
表8-3 Oc4jSelectMethodの値
| 値 | 説明 |
|---|---|
|
|
mod_oc4jによりリストにトポロジのすべてのOC4Jプロセスが表示され、プロセスがリストから順番に選択されます。 |
|
|
|
|
|
各インスタンスに構成されているルーティングの重み付けに基づいて、mod_oc4jにより合計のリクエスト負荷が各OC4Jインスタンスに分散されます。その後、ラウンド・ロビン方式でローカル・インスタンスからOC4Jプロセスが選択されます。 重み付けは、 |
|
|
mod_oc4jによりトポロジのすべてのOC4Jプロセスのリストから、OC4Jプロセスがランダムに選択されます。 |
|
|
|
|
|
トポロジの各インスタンスに構成されている重み付けに基づいて、mod_oc4jによりOC4Jプロセスが選択されます。 重み付けは、 |
|
|
プロセスがどの程度ビジーであるかを示すランタイム・メトリックに基づいて、mod_oc4jによりリクエストがルーティングされます。 |
|
|
metricと似ていますが、ローカルOC4Jプロセスが優先されます。使用可能なローカルOC4Jプロセスがない場合には、リモートOC4Jプロセスにルーティングされます。 |
例:
Oc4jSelectMethod random:local
メトリックベースのロード・バランシングの設定方法の詳細は、『Oracle HTTP Server管理者ガイド』を参照してください。
Oc4jSelectMethodディレクティブに重み付けベースのメソッド（roundrobin:weightedまたはrandom:weighted）を設定した場合は、Oc4jRoutingWeightディレクティブに重み付けを指定する必要もあります。
Oc4jRoutingWeightの構文は次のとおりです。
Oc4jRoutingWeight hostname weight
Oc4jRoutingWeightディレクティブを設定しない場合は、デフォルトの重み付けである1が使用されます。
例: 3つのインスタンス（A、BおよびC）で構成されるトポロジがあり、BとCではAの2倍のリクエストを取得する必要がある場合には、BおよびCに次のディレクティブを設定します。
Oc4jSelectMethod roundrobin:weighted Oc4jRoutingMethod hostB 2 Oc4jRoutingMethod hostC 2
デフォルト値は1であるため、hostAにはOc4jRoutingMethodを設定しなくてもかまいません。
変更内容が反映されるよう、トポロジのすべてのインスタンス上のOracle HTTP Serverを再起動します。
> opmnctl @cluster restartproc ias-component=HTTP_Server
mod_oc4jの使用するロード・バランシング・オプションを決定する際には、次のガイドラインに従います。
同じOracleホームでOracle HTTP ServerおよびOC4Jが稼働している同一のマシンのあるトポロジには、ローカル・アフィニティ・アルゴリズムを使用するラウンド・ロビンが適しています。この場合、同じマシン上のすべての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またはデータベース接続の数など、アプリケーションのパフォーマンスを占有するメトリックがほとんどない場合に便利です。
受信リクエストをルーティングするために、Oracle HTTP Serverでは、リクエストに指定されたURLとリクエストを処理するOC4Jインスタンスをマップする、アプリケーション固有のマウント・ポイントのリストを使用します。この項では、マウント・ポイント作成に関する次の項目について説明します。
マウント・ポイントの構成の詳細は、『Oracle HTTP Server管理者ガイド』を参照してください。
旧リリースのOracle Application Serverでは、アプリケーション・マウント・ポイントのリストはmod_oc4j構成ファイルのmod_oc4j.confで手動で管理する必要がありました。
現行リリースでは、新しいノードおよびアプリケーションがクラスタに対して追加または削除されると、マウント・ポイントのリストは動的に更新されます。ONS通知を使用して、クラスタ内のすべてのOC4Jインスタンスは、それぞれのデプロイ済アプリケーションのマウント・ポイント・データをmod_oc4jに送信し、mod_oc4jによってこの情報は内部ルーティング表に追加されます。
この動的検出方式は、クラスタ化されたOracle Application Serverインスタンスではデフォルトで有効になっているため、追加構成は不要です。
各OC4JインスタンスによってOracle HTTP Serverに送信されるマウント・ポイント情報には次のものがあります。
OC4Jホスト・アドレス
OC4Jポート情報（Apache JServ Protocol（AJP）リスナー・ポートなど）
この値は、ノードにあるopmn.xmlファイルでAJPに割り当てられる最も低い値の使用可能なポートです。
Webモジュール名
この値は、バインド先の*-web-site.xml構成ファイルでモジュールに定義される<web-app>要素のname属性の値として定義されます。
アプリケーションに定義されているWebコンテキストまたはルート・コンテキスト
この値は、*-web-site.xml構成ファイルでモジュールに定義される<web-app>要素のroot属性に設定されます。
|
注意: 動的に構成されるマウント・ポイントは、mod_oc4j構成ファイル（mod_oc4j.conf）には書き込まれません。 |
新しいアプリケーションがOC4Jインスタンスにデプロイされると、マウント・ポイント情報がOracle HTTP Serverに送信され、mod_oc4jは動的にアプリケーションを検出し、リクエストをルーティングできるようになります。
反対に、アプリケーションがOC4Jインスタンスから停止または削除されると、mod_oc4jルーティング表はアプリケーションが存在しないことを反映するように更新され、mod_oc4jはアプリケーション・インスタンスへのリクエストのルーティングを停止します。
「マウント・ポイント構成アルゴリズムの変更点」で説明されているように、アプリケーションのマウント・ポイントは手動で構成することも可能です。マウント・ポイント・リストの表示の詳細は、「マウント・ポイントの構成データの表示」を参照してください。マウント・ポイントの構成の詳細は、『Oracle HTTP Server管理者ガイド』を参照してください。
動的マウント・ポイントの作成はデフォルトで有効になっていますが、手動で構成されたマウント・ポイントを引き続き使用することもできます。これは、旧リリースのOracle Application Serverでサポートされたデフォルトの方式です。
静的マウント・ポイントは、mod_oc4j構成ファイルのmod_oc4j.confに定義されます。このファイルは、ORACLE_HOME/Apache/Apache/confディレクトリにインストールされています。デフォルトでは、Oracle HTTP Serverはアプリケーションのデプロイ時に動的マウント・ポイントを作成しますが、mod_oc4j.confに定義される静的マウント・ポイントも有効とみなされます。
使用するマウント・ポイントの構成方式は、mod_oc4j.confのOc4jRoutingModeパラメータに指定されます。表8-4に、この変数の値を示します。マウント・ポイントの構成およびmod_oc4j.conf.の使用方法は、『Oracle HTTP Server管理者ガイド』を参照してください。
|
注意: mod_oc4j構成ファイルのOc4jRoutingModeをStaticに変更する場合には、Application Server Controlへのアクセス権を失わないように、mod_oc4j.confに次の構成を追加する必要もあります。
Oc4jMount /em/* home Oc4jMount /em home |
表8-4 Oc4jRoutingModeの値
| 値 | 説明 |
|---|---|
|
|
動的に構成されたマウント・ポイントのみが使用されます。静的マウント・ポイントは無視されます。 |
|
|
|
|
|
動的マウント・ポイントと静的マウント・ポイントの両方が使用されます。競合する場合は、動的に構成されたマウント・ポイントが使用されます。 |
|
|
動的マウント・ポイントと静的マウント・ポイントの両方が使用されますが、競合する場合は、手動で構成されたマウント・ポイントが使用されます。 デフォルトで |
次に示すmod_oc4j.confの例では、DynamicOverrideモードを有効にしています。競合が発生した場合、このモードでは、指定された動的マウント・ポイントが静的マウント・ポイントに優先します。
#########################################################
# Oracle iAS mod_oc4j configuration file: mod_oc4j.conf #
#########################################################
LoadModule oc4j_module libexec/mod_oc4j.so
Oc4jRoutingMode DynamicOverride
<IfModule mod_oc4j.c>
<Location /oc4j-service>
SetHandler oc4j-service-handler
</Location>
Oc4jMount /j2ee/*
Oc4jMount /webapp home
Oc4jMount /webapp/* home
Oc4jMount /cabo home
Oc4jMount /cabo/* home
Oc4jMount /stressH home
Oc4jMount /stressH/* home
</IfModule>
マウント・ポイントの構成データをOracle HTTP Serverホストで生成されるWebページに出力するように、Oracle HTTP Serverを構成できます。
次のエントリを、Oracle HTTP Serverホスト・マシンにあるOracle HTTP Server構成ファイルhttpd.confに追加します。このファイルは、ORACLE_HOME/Apache/Apache/confにインストールされています。
<IfModule mod_oc4j.c> Oc4jSet StatusUri /oc4j-status </IfModule>
ここで、/oc4j-statusコンテキストURIをOracle HTTP ServerサーバーのURLの最後に追加すると、マウント・ポイント・データを表示できます。
http://ohsHost:ajpPort/oc4j-status
次に例を示します。
http://node1.company.com:7777/oc4j-status
次に、結果のWebページにコメントとともに表示されるサンプルの出力を示します。
hostname : node1.company.com
local instance : node1.company.com
select method : Round-Robin
select affinity : None
# OHS routing configuration
routing mode : Static-Dynamic
routing ID : g_rt_id
OC4J Dynamic routing
# Applications using dynamic routing
# 'ascontrol' application
application : ascontrol
context : /em
process (Jgroup): 0
# 'demos' application
application : demos
context : /ojspdemos/jstl, /ojspdemos
process (Jgroup): 0 (demos)
OC4J Process List
process,ias instance,host,port,status
0 : home.node1.company.com, node1.company.com, 12502, ALIVE
1 : home.node1.company.com, node1.company.com, 12501, ALIVE
2 : home.node1.company.com, node1.company.com, 12503, ALIVE
OC4Jは、標準Java Development Kit（JDK）のJava仮想マシン（JVM）で稼働します。各OC4Jインスタンスはデフォルトで1つのJVMを使用しますが、図8-6に示すように、複数のJVMで稼働するように構成できます。OC4Jインスタンスを複数のJVMで稼働するように構成すると、インスタンスは基本的に複数のプロセスで稼働します。これにより、パフォーマンスが向上し、デプロイ済のアプリケーションに一定レベルのフォルト・トレランスが提供されます。
この図には、クラスタ内のOracle Application Serverインスタンスの1つであるOC4J_homeという名前のOC4Jインスタンスから実行するよう構成されている4つのプロセスを示します。
|
注意: 通常、homeという名前のOC4Jインスタンスは、複数プロセス・モデルでの実行には適さないApplication Server Controlアプリケーションascontrolのホストであるため、複数のプロセスで実行するように構成することはできません。
複数のプロセスで実行されるOC4Jインスタンスで、EJBタイマーを使用するアプリケーションは実行できません。EJBタイマーがサポートされているのは、（ |
ただし、複数のJVMが効率的に稼働するには、追加のハードウェア・リソースが必要です。また、複数のプロセスが同じホストで稼働していて、そのホストが停止した場合には、すべてのJVMプロセスが停止します。
複数のアプリケーション・サーバー・インスタンスをインストールおよび管理する場合には、それらのアプリケーション・サーバー・インスタンスを複数のホストにインストールできます。アプリケーション・サーバーをクラスタ化し、「クラスタ・トポロジ」ページ（またはコマンドラインやAPI）からOC4Jグループを作成することで、アプリケーションのクラスタリングおよびロード・バランシングを利用することもできます。第9章「OC4Jでのアプリケーションのクラスタリング」で説明されているように、アプリケーションのクラスタリングにより、各JVMで稼働しているアプリケーションの異なるインスタンスに状態情報がレプリケートされます。
また、Oracle Application ServerクラスタおよびOC4Jグループにより、ハードウェアまたはネットワークの停止からさらに強固に保護されます。1つのホストが停止しても、別のホストにデプロイされているアプリケーションは使用可能です。
|
注意: （ascontrolアプリケーションとして表される）Application Server Controlは、複数のJVMで稼働しているOC4Jインスタンスでは稼働できません。アクティブなApplication Server ControlインスタンスのホストであるOC4Jインスタンスには、複数のJVMを構成しないでください。 |
デフォルトで、各OC4Jインスタンスは1つのJVMを使用します。ただし、各JVMにインスタンスのコピーが存在する状態で、OC4Jインスタンスが複数のJVMで稼働するように構成できます。Application Server Controlの「サーバー・プロパティ」ページを使用するか、opmn.xmlファイルでOC4Jインスタンスのnumprocs属性を直接設定することにより、OC4Jインスタンスに追加のJVMを作成できます。
|
注意: opmn.xmlファイルでOC4Jインスタンスのnumprocs属性が1より大きい場合（n）、その属性をApplication Server Controlを使用して設定するかファイルを編集して設定するかにかかわらず、Oracle Application Serverはn個の別々の物理JVMプロセスを開始します。各プロセスは関連するOC4Jインスタンス（すべてのデプロイ済アプリケーションを含む）のコピーの実行専用です。この値を設定する際には、物理ハードウェア・リソースも考慮に入れてください。 |
Application Server Controlの「サーバー・プロパティ」ページで、OC4Jインスタンスに1つ以上のJVMを追加できます。
Application Server Controlを使用してOC4Jインスタンスに追加のJVMを作成する手順:
OC4Jホームページに移動して「管理」をクリックし、OC4Jの「管理」ページを表示します。このページには、OC4Jインスタンスに対して実行可能な様々な管理タスクがリストされた表が表示されています。
「管理」ページで、「サーバー・プロパティ」を選択し、OC4Jの「サーバー・プロパティ」ページを表示します。
「VMのプロセス数」フィールドに、OC4Jインスタンスに構成するJVMの数を入力します。
「適用」をクリックします。
「クラスタ・トポロジ」ページまたはOC4JホームページからOC4Jインスタンスを再起動します。
デフォルトで、各OC4Jインスタンスは1つのJVMを使用します。ただし、複数のJVMで稼働するようにOC4Jインスタンスを構成できます。opmn.xmlファイルのOC4Jインスタンスに関する構成で<process-set>要素のnumprocs属性を設定することで、1つ以上のJVMを追加できます。
opmn.xmlファイルのOC4Jインスタンスに追加のJVMを作成する手順:
opmn.xmlファイルを編集します。
OC4J構成の<process-set>要素で、numprocs属性の値をOC4Jを実行するJVMの数に設定します。
例8-1に、opmn.xmlのnumprocs設定を示します。
例8-1 opmn.xmlのOC4Jのnumprocs属性
<opmn>
. . .
<ias-component id="default_group"> <process-type id="home" module-id="OC4J" status="enabled">
<module-data>
<category id="start-parameters">
<data id="java-options" value=" -Djava.awt.headless=true"/>
<data id="java-bin" value="/jdk/bin"/>
<data id="oc4j-options" value="-validateXML -verbosity 10"/>
</category>
<category id="stop-parameters">
<data id="java-options" value="-Djava.awt.headless=true"/>
</category>
</module-data>
<start timeout="600" retry="2"/>
<stop timeout="120"/>
<restart timeout="720" retry="2"/>
<port id="default-web-site" protocol="ajp" range="12501-12600"/>
<port id="rmi" range="12401-12500"/>
<port id="jms" range="12601-12700"/>
<port id="rmis" range="12701-12800"/>
<process-set id="default_group" numprocs="2"/>
</process-type>
</ias-component>
</opmn>
opmn.xmlファイルを保存します。
OC4Jインスタンスを再起動します。
複数のJVMを使用する場合には、現在のハードウェア・リソースで構成に対応できることを確認するためにJVMのパフォーマンスを監視することが重要です。Application Server Controlから、OC4Jインスタンスに関連付けられているJVMのパフォーマンスを監視および比較できます。
次の各項では、Application Server Controlを使用してJVMメトリックを監視する方法を説明します。
Application Server ControlからJ2SE 5.0のJVMメトリックを監視するには、JDK 5.0（1.5）でOC4Jを実行し、各OC4Jインスタンスにjmxremoteシステム・プロパティを設定して監視を有効にする必要があります。
Oracle Application Server環境でOC4Jを実行している場合は、各JVMの一連のダイナミック・モニタリング・サービス（DMS）メトリックを監視できます。これらのメトリックは、スタンドアロンOC4J環境では使用できません。
Application Server Controlを使用してOracle Application Server環境のDMS JVMメトリックを表示するには、次のようにします。
OC4Jホームページに移動します。
OC4Jホームページの「一般」セクションで、「仮想マシン」フィールドを探します。
OC4JインスタンスにJVMがいくつ構成されているかを示す数をクリックします。
「JVMメトリック」ページには、選択したOC4Jインスタンスに構成されているすべてのJVMの主要なメトリックのサマリーが表示されます。この表を使用して、複数のJVMのパフォーマンスを比較できます。
詳細は、JVMの名前をクリックしてください。
OC4Jの「JVM」ページには、JVMの状態を詳細に示す一連のグラフおよび数値メトリックが表示されます。「データの表示」リストからリフレッシュ間隔を選択します。その後、パフォーマンス・グラフで一定期間の変化を参照できます。
J2SE JVM 5.0メトリックを監視するために、Application Server Control、OC4J起動オプション、また、OPMN管理環境の場合はopmn.xmlファイルを使用して、jmxremoteシステム・プロパティを設定できます。
Application Server Controlコンソールを使用したjmxremoteシステム・プロパティの設定
Application Server Controlを使用して、各OC4JインスタンスのJVM J2SE 5.0メトリックの監視を有効化するには、次のようにします。
OC4Jホームページに移動して「管理」をクリックし、OC4Jの「管理」ページを表示します。このページには、OC4Jインスタンスに対して実行可能な様々な管理タスクがリストされた表が表示されています。
OC4Jの「管理」ページで、「サーバー・プロパティ」を選択し、OC4Jの「サーバー・プロパティ」ページを表示します。
ページの「コマンドライン・オプション」セクションまでスクロールして、「J2SE 5.0プラットフォームMBeanの有効化」を選択します。
「適用」をクリックして、変更内容を適用します。
「クラスタ・トポロジ」ページに移動してOC4Jインスタンスを選択し、「再起動」をクリックします。
OC4J起動オプションでのjmxremoteシステム・プロパティの設定
OC4Jのランタイム起動オプションとして次の文字列を指定することにより、JVM J2SE 5.0メトリックの監視を有効化することもできます。
com.sun.management.jmxremote
OC4Jのランタイム起動オプションの指定方法の詳細は、「起動時のOC4Jランタイム・オプションの設定」を参照してください。
スタンドアロン環境でOC4Jを稼働している場合は、OC4J javaコマンドに次の引数を指定します。
java -Dcom.sun.management.jmxremote -jar oc4j.jar
opmn.xmlファイルへのjmxremoteシステム・プロパティの設定
OPMN管理のOracle Application Server環境でOC4Jを実行している場合には、次に示すように、opmn.xmlファイルに-Dcom.sun.management.jmxremoteを指定します。
<ias-component id="default_group">
<process-type id="home" module-id="OC4J" status="enabled">
<module-data>
<category id="start-parameters">
<data id="java-options" value="-Dcom.sun.management.jmxremote"/>
...
</category>
...
</module-data>
...
</process-type>
...
</ias-component>
Application Server Controlを使用してJ2SE 5.0プラットフォームMBeansを有効化すると、opmn.xmlファイルにjmxremoteシステム・プロパティが設定されます。この方法を使用した場合、opmn.xmlファイルに手動でプロパティを設定する必要はありません。
Application Server Controlを使用してOracle Application Server環境のJ2SE 5.0 JVMメトリックを表示するには、次のようにします。
OC4Jホームページの「一般」セクションで、「仮想マシン」フィールドを探します。
OC4JインスタンスにJVMがいくつ構成されているかを示す数をクリックします。
「JVMメトリック」ページが表示されます。
JVMの名前をクリックします。
OC4Jの「JVM」ページが表示されます。
ページの「関連リンク」セクションまでスクロールし、「J2SE 5.0メトリック」をクリックします。
