ヘッダーをスキップ

Oracle Containers for J2EE 構成および管理ガイド
10g（10.1.3.4.0）
B50866-01
目次
目次		 索引
索引

戻る 次へ

8 クラスタおよびOC4Jグループの構成と管理

この章では、Oracle Application Server環境のクラスタ・トポロジと、Oracle Application Serverクラスタ内のOC4Jインスタンスのグループを構成および管理する方法について説明します。次の項目が含まれます。

アプリケーションのクラスタリング（セッションまたは状態のレプリケーションを目的としてOracle Application Serverノードにデプロイされたアプリケーションのクラスタリング）は、第9章「OC4Jでのアプリケーションのクラスタリング」で説明します。

クラスタリングの概要

この項では、Oracle Application Server 10gリリース3（10.1.3.4.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ファイルに指定されているのと同じように構成されている必要があります。

サポートされるクラスタリング・モデル

次のクラスタリング・モデルがサポートされます。

クラスタリングにおける変更点

次に、Oracle Application Server 10gリリース3（10.1.3）のクラスタ構成における旧リリースからの変更点を示します。

Oracle Application Serverクラスタ内のOC4Jグループの作成および管理

OPMN管理環境のすべてのOC4Jインスタンスは、グループに属している必要があります。グループは、同じクラスタ・トポロジに属する一連のOC4Jインスタンスです。グループでは、グループ内のすべてのOC4Jインスタンスに対して、共通の構成、管理およびデプロイ・タスクを同時に実行できます。

注意:

Oracle Application Serverクラスタのグループ内に存在するすべてのOC4Jインスタンスは、10.1.3.4.0など、同じリリースであることが必要です。 

Application Server Controlを使用して、追加のグループを作成し、「グループ」ページからOC4Jインスタンスのグループに対して次のタスクを実行できます。

「グループ」ページを表示するには、「クラスタ・トポロジ」ページの「グループ」セクションでグループ名をクリックします。

図8-1    「クラスタ・トポロジ」ページの「グループ」セクション


画像の説明

アプリケーション・サーバー・インスタンスをインストールすると、デフォルトのOC4Jグループ（default_group）が自動的に作成されます。Oracle Application Server 10g（10.1.3.4.0）のインストール時に、デフォルト・グループに存在するデフォルトのOC4Jインスタンスがインストーラにより作成されます。その後、OC4Jインスタンスを追加してグループに編成できます。

たとえば、Oracle Application Serverクラスタ全体のグループのすべてのOC4Jインスタンスに特定のアプリケーションをデプロイするための新規グループを作成できます。その後、Application Server Controlの「グループ」ページを使用して、クラスタ全体でOC4Jグループ内のアプリケーションの全インスタンスに対してアプリケーション固有の構成の変更を実行できます。

次の各項では、1つ以上のOracle Application Serverクラスタ全体でレプリケートされたアプリケーションで、グループ操作を行うためにOC4Jインスタンスのグループを作成および管理する方法を説明します。

OC4Jインスタンスのグループの作成

グループを使用すると、複数のOC4Jインスタンスに対して次の各タスクを一度で実行できます。

Application Server Controlを使用したグループの管理:
  1. 「クラスタ・トポロジ」ページの「グループ」で、グループを選択します。

  2. 「管理」タブを選択します。

  3. 「管理」ページには、グループ全体の管理機能が表示されています。これらの機能には、セキュリティ・プロバイダの管理は含まれません。

Application Server Controlを使用した新規OC4Jグループの作成:
  1. 「クラスタ・トポロジ」ページの「グループ」で、「作成」を選択します。

  2. 「グループの作成」ページで次のようにします。

    1. グループ名を指定します。

      グループ名に使用できるのは英数字およびアンダースコアのみで、カッコ、ピリオド、ドル記号（$）、アスタリスク（*）またはカンマなどの特殊文字は使用できません。名前は、文字またはアンダースコアで開始する必要があります。

      表8-1に、OC4Jインスタンスとグループの有効な名前および無効な名前の例を示します。

      表8-1    OC4Jインスタンスおよびグループの名前 
      インスタンスまたはグループの有効な名前  インスタンスまたはグループの無効な名前 

      OC4J1 

      $OC4J_2 

      _production_apps 

      32_PROD_test 

      test_environment_42 

      !deployGroup2 

      Deployment_Group3 

      deployment_(group3) 
    2. グループに移動するOC4Jインスタンスを選択します。

      OC4Jインスタンスを新しいグループに移動すると、インスタンスは前のグループから削除されます。インスタンスを移動する前に停止しておく必要があります。

    3. 「作成」を選択します。

グループを作成すると、「クラスタ・トポロジ」ページのグループのリストに表示されます。「グループ内のOC4Jインスタンスの管理」で説明されているように、後からグループにOC4Jインスタンスを追加することや、グループからインスタンスを削除することが可能です。

次の操作中にグループを作成することも可能です。

次に、複数のOC4Jインスタンスおよびグループを使用して、Oracle Application Server環境を管理する例を示します。

グループ内のOC4Jインスタンスの管理

OC4Jには、グループへの追加のOC4Jインスタンスの作成や、Oracle Application Serverクラスタ内のグループからのインスタンスの削除を実行するためのツールがあります。新規作成されたOC4Jインスタンスは、Application Server Controlを使用してアクセスおよび管理できます。

この項の内容は次のとおりです。

OC4Jインスタンスの追加作成

グループにOC4Jインスタンスを追加するには、次の方法があります。

Application Server Controlを使用したOC4Jインスタンスの作成

Application Server Controlを使用してOC4Jインスタンスを作成するには、次のようにします。

  1. 「クラスタ・トポロジ」ページで、Oracle Application Serverインスタンスの名前をクリックし、「アプリケーション・サーバー: instance_name」ページへ移動します。

  2. 「OC4Jインスタンスの作成」をクリックします。

  3. 「OC4Jインスタンスの作成」ページで、次の情報を入力します。

  4. 「作成」をクリックします。

インスタンスが作成されると確認画面が表示されます。このOC4Jインスタンスのパスワードは、インストール用にoc4jadminユーザーに使用されるパスワードと同じです。

createinstanceユーティリティを使用したOC4Jインスタンスの作成

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ユーザーに同じパスワードを指定する必要があります。

注意:

  • createinstanceユーティリティは、Oracle Application Serverインスタンスの状態が実行中か停止中かに関係なく使用できます。

  • ORMI over SSL（ORMIS）リクエストの受入れに新規OC4Jインスタンスが必要な場合、『Oracle Containers for J2EEセキュリティ・ガイド』で説明しているように、インスタンス固有のrmi.xmlファイルでORMISを構成し、opmn.xmlをORMISポート情報で更新する必要があります。

 

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インスタンスを削除できます。OC4Jインスタンスを削除するには、次の方法があります。

どちらの方法でも、j2eeディレクトリ構造からインスタンスに作成されたディレクトリが削除され、opmn.xmlからインスタンスの構成データが削除されます。OC4Jインスタンスの削除には次のガイドラインが適用されます。

Application Server Controlを使用したOC4Jインスタンスの削除

Application Server Controlを使用してOC4Jインスタンスを削除するには、次のようにします。

  1. 「クラスタ・トポロジ」ページで、OC4Jインスタンスが稼働しているOracle Application Serverインスタンスの名前をクリックし、「アプリケーション・サーバー: instance_name」ページへ移動します。

  2. 削除するインスタンスの「削除」アイコンをクリックします。

  3. 「確認」ページで、「はい」をクリックします。

インスタンスが削除されると確認画面が表示されます。

removeinstanceユーティリティを使用したOC4Jインスタンスの削除

OC4Jインスタンスは、removeinstanceユーティリティを使用して削除できます。このユーティリティは、ORACLE_HOME/j2eeディレクトリ構造からインスタンス用に作成されたディレクトリを削除し、opmn.xmlからインスタンスの構成データを削除します。

removeinstanceユーティリティは、ORACLE_HOME/binディレクトリにインストールされています。構文は次のとおりです。

removeinstance -instanceName instanceName

ユーティリティを使用してインスタンスを削除するには、次のようにします。

  1. インスタンスを停止します。

    ORACLE_HOME/opmn/bin/opmnctl stopproc process-type=oc4J_instanceName
  2. インスタンスを削除します。

    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での場所  レプリケートまたは管理対象データ 

application.xml 

/j2ee/instance
/config 
  • すべてのデプロイ済アプリケーションにデフォルトで適用される構成データに加えられた変更。

  • データソースまたは他の共有リソースへの参照。

  • <imported-shared-libraries>要素内の共有ライブラリ定義。

    カスタム共有ライブラリのコード・ソースは、OC4Jホストにインストールする必要があり、ライブラリはOC4Jインスタンスのserver.xmlファイルで参照する必要があります。

 

data-sources.xml 

/j2ee/instance
/config 
  • デプロイ済アプリケーションで使用できるようにする必要があるカスタム・データソースの構成データ。

 

default-web-site.xml 

/j2ee/instance
/config 
  • 該当する場合は、セキュアなWebサイト（HTTPS）構成。

 

*-web-site.xml 

/j2ee/instance
/config 
  • OC4Jインスタンスで使用される追加Webサイトの構成ファイルを指定された場所にコピーします。

    Webサイト構成ファイルへの参照は、「OC4JでのWebサイトの新規作成」で説明しているように、opmn.xmlまたはserver.xmlに追加する必要があります。

 

global-web-application.xml 

/j2ee/instance
/config 
  • 新しいサーブレット定義またはサーブレット構成の変更（<init-param>の変更など）。

  • 変更されたJSPコンテナのプロパティ。詳細は、『Oracle Containers for J2EE JavaServer Pages開発者ガイド』を参照してください。

 

j2ee-logging.xml 

/j2ee/instance
/config 
  • ロギング構成の変更。

 

javacache.xml 

/j2ee/instance
/config 
  • Javaキャッシュ構成の変更。

 

jazn.xml 

/j2ee/instance
/config 
  • XMLベースまたはLDAPベースのセキュリティ・プロバイダの構成。jazn.xmlファイルの詳細は、『Oracle Containers for J2EEセキュリティ・ガイド』を参照してください。

 

jazn-data.xml 

/j2ee/instance
/application-deployments/appName 
  • XMLベースのプロバイダ構成を、このプロバイダを使用するすべてのアプリケーションに対して、指定された場所にレプリケートします。LDAPベースのプロバイダを使用するアプリケーションには不要です。jazn-data.xmlファイルの詳細は、『Oracle Containers for J2EEセキュリティ・ガイド』を参照してください。

 

jms.xml 

/j2ee/instance
/config 
  • 接続先またはコネクション・ファクトリへの追加。

 

rmi.xml 

/j2ee/instance
/config 
  • RMI構成の変更（ロギング構成など）。

 

クラスタの構成

この項では、次のクラスタリング・モデルを構成する手順について説明します。

マルチキャストを使用した動的ノード検出の構成

動的ノード検出は、最も単純なクラスタリング構成です。このモデルでは、各ONSノードは、その存在を通知する単純なマルチキャスト・メッセージをブロードキャストし、クラスタ内のノードが相互に動的に検出できるようにします。

次のツールは、マルチキャスト検出を使用してOC4Jインスタンスをクラスタに追加するために使用できます。

各ONSは、クラスタ・トポロジのマップを独自に保持します。新しいONSがクラスタに追加されると、既存のONSは、新しいノードとその接続情報をそれぞれのマップに追加します。同時に、新しいONSはすべての既存のノードをそのマップに追加します。また、ONSがクラスタから削除されると、残りのノードのマップにこの変更が反映されます。

図8-2    動的検出モデル


画像の説明

マルチキャスト・メッセージは異なるネットワーク構成によって制限されるため、動的ノード検出は、同じサブネット上にあるONSノードに対してのみのオプションとなる場合があります。ただし、動的ノード検出を使用する複数のサブネットは、ゲートウェイ・サーバーを使用して接続できます。詳細は、「トポロジ間ゲートウェイの構成」を参照してください。

注意:

  • トポロジ内のすべてのノードは、同じマルチキャスト・アドレスおよびポートを使用するように構成する必要があります。

  • マルチキャスト・アドレスは、有効なアドレス範囲（224.0.1.0〜239.255.255.255）内にある必要があります。

    マルチキャスト・アドレスおよびポートの割当ては、他のアプリケーションとの競合を回避するために、システム管理スタッフが管理することをお薦めします。

 

動的検出の構成は、トポロジ内の各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およびデプロイ済アプリケーションなど）には影響を与えません。 

opmnctlによるマルチキャスト検出の構成

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の「ランタイム・ポート」ページを使用して構成できます。opmnctl config port updateコマンドは、opmn.xmlに定義されたデフォルトWebサイト構成の変更にも使用できます。詳細は、「opmnctlによるWebサイトの構成」を参照してください。 

検出データの挿入または更新

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によるマルチキャスト検出の構成

opmnassociateユーティリティは、マルチキャスト検出を使用してデフォルトのhome OC4Jインスタンスをクラスタに追加します。このユーティリティは、次の手順を実行します。

  1. opmn.xmlの<discover>要素に、指定されたマルチキャスト・アドレスおよびポートを挿入または更新します。

  2. opmn.xmlの対応する<port>要素を変更して、Apache JServ Protocol（AJP）を使用してOracle HTTP Serverからのリクエストを受信し応答するようにデフォルトWebサイトを構成します。

  3. 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による静的検出サーバー接続の構成」を参照してください。

図8-3    静的検出サーバー・モデル


画像の説明

クラスタ内の各静的ハブ・ノードにあるopmn.xmlファイルの<discover>要素内に、検出サーバーのTCP/IP接続情報を設定します。次に例を示します。

<opmn>
 <notification-server>
  <port ...  />
  <ssl ... />
  <topology>
   <discover list="node1.company.com:6200"/>
  </topology>
 </notification-server>
 ...
</opmn>

必須情報は次のとおりです。

opmnctlによる静的検出サーバー接続の構成

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通知を異なるトポロジ間で送信できるようにすることができます。

図8-4    ゲートウェイ・サーバーを使用したトポロジの接続


画像の説明

このモデルでは、それぞれの分離されたトポロジ内のONSノードはゲートウェイ・サーバーとして構成され、クラスタへのエントリ・ポイントとなります。ゲートウェイ構成は、<topology>要素の<gateway>サブ要素内に指定されます。

ソース・ゲートウェイ・ノードとその接続先の各ターゲット・ノードのホストおよびポートは、list属性の値として設定します。ノードがリストされる順序は重要ではありません。

次の例に、ゲートウェイ・ノード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 10gリリース1（10.1.2）および9iリリース1（9.0.4）で使用されたものと同じ方式です。このモデルは、主にこれらの旧リリースとの下位互換性を提供するためにサポートされています。

図8-5    静的ノードツーノード・モデル


画像の説明

この構成では、クラスタ内の各ノードのホスト・アドレスおよび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コンポーネントの現行のステータスを表示できます。

opmnctlによるクラスタのステータスの表示

クラスタ内の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

Application Server Controlでのクラスタのステータスの表示

Application Server Controlのホームページの左上隅にある「クラスタ・トポロジ」リンクをクリックします。

結果ページには、クラスタ内のアクティブな各Oracle Application Serverインスタンスとともに、各インスタンス上のアクティブなアプリケーションが表示されます。このページから、クラスタ内のインスタンスまたはデプロイ済アプリケーションにアクセスできます。

Oracle HTTP Serverを使用したルーティングおよびロード・バランシングの構成

ロード・バランシングという用語は、クラスタ内のサーバー・インスタンスに受信サービス・リクエストを分散するプロセスを指します。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をさらに構成する必要はありません。

クラスタ内の様々なOracle HTTP ServerおよびOC4JインスタンスのONSサーバーが、この章で説明しているクラスタリング構成方式のいずれかを使用して接続されることが唯一の要件です。詳細は、「クラスタの構成」を参照してください。

WebサーバーのルーティングIDを使用したOC4Jリクエスト・ルーティングの制御

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の変更

Application Server Controlを使用して、クラスタの各アプリケーションおよびコンポーネントに割り当てられたルーティングIDを変更または表示するには、次のようにします。

  1. 「クラスタ・トポロジ」ページに移動します。

  2. ページの「管理」セクションまでスクロールし、「ルーティング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を割り当ててください。

opmn.xmlファイルのルーティング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>

mod_oc4jロード・バランシング・オプションの設定

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ディレクティブを設定します。

  1. 各Oracle Application Serverインスタンスのmod_oc4j.confファイルにある<IfModule mod_oc4j.c>セクションで、Oc4jSelectMethodディレクティブに表8-3に示す値のいずれかを設定します。

    Oc4jSelectMethodディレクティブをroundrobin:weightedまたはrandom:weightedに設定した場合は、Oc4jRoutingWeightディレクティブに重み付けを指定する必要もあります（次の手順を参照）。

    ルーティング・アルゴリズムの選択の詳細は、「mod_oc4jのロード・バランシング・オプションの選択」を参照してください。

    表8-3    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と似ていますが、ローカルOC4Jプロセスが優先されます。使用可能なローカルOC4Jプロセスがない場合には、リモートOC4Jプロセスが選択されます。 

    random:weighted 

    トポロジの各インスタンスに構成されている重み付けに基づいて、mod_oc4jによりOC4Jプロセスが選択されます。

    重み付けは、Oc4jRoutingWeightディレクティブを使用して構成します。 

    metric 

    プロセスがどの程度ビジーであるかを示すランタイム・メトリックに基づいて、mod_oc4jによりリクエストがルーティングされます。 

    metric:local 

    metricと似ていますが、ローカルOC4Jプロセスが優先されます。使用可能なローカルOC4Jプロセスがない場合には、リモートOC4Jプロセスにルーティングされます。 

    例:

    Oc4jSelectMethod random:local

    メトリックベースのロード・バランシングの設定方法の詳細は、『Oracle HTTP Server管理者ガイド』を参照してください。

  2. 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を設定しなくてもかまいません。

  3. 変更内容が反映されるよう、トポロジのすべてのインスタンス上のOracle HTTP Serverを再起動します。

    > opmnctl @cluster restartproc ias-component=HTTP_Server
mod_oc4jのロード・バランシング・オプションの選択

mod_oc4jの使用するロード・バランシング・オプションを決定する際には、次のガイドラインに従います。

アプリケーション・マウント・ポイントの構成

受信リクエストをルーティングするために、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インスタンスにデプロイされると、マウント・ポイント情報が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の値 
値  説明 

Dynamic 

動的に構成されたマウント・ポイントのみが使用されます。静的マウント・ポイントは無視されます。 

Static 

mod_oc4j.confに定義される、手動で構成された静的マウント・ポイントのみが使用されます。動的マウント・ポイントは新しいアプリケーションに対して作成されません。 

DynamicOverride 

動的マウント・ポイントと静的マウント・ポイントの両方が使用されます。競合する場合は、動的に構成されたマウント・ポイントが使用されます。 

StaticOverride 

動的マウント・ポイントと静的マウント・ポイントの両方が使用されますが、競合する場合は、手動で構成されたマウント・ポイントが使用されます。

デフォルトでmod_oc4j.confに定義されていなくても、この値がデフォルト・モードです。 

次に示す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

複数のJVMでのOC4Jインスタンスの稼働

OC4Jは、標準Java Development Kit（JDK）のJava仮想マシン（JVM）で稼働します。各OC4Jインスタンスはデフォルトで1つのJVMを使用しますが、図8-6に示すように、複数のJVMで稼働するように構成できます。OC4Jインスタンスを複数のJVMで稼働するように構成すると、インスタンスは基本的に複数のプロセスで稼働します。これにより、パフォーマンスが向上し、デプロイ済のアプリケーションに一定レベルのフォルト・トレランスが提供されます。

図8-6    複数のJVMで稼働するOC4Jインスタンス


画像の説明

この図には、クラスタ内のOracle Application Serverインスタンスの1つであるOC4J_homeという名前のOC4Jインスタンスから実行するよう構成されている4つのプロセスを示します。

注意:

通常、homeという名前のOC4Jインスタンスは、複数プロセス・モデルでの実行には適さないApplication Server Controlアプリケーションascontrolのホストであるため、複数のプロセスで実行するように構成することはできません。

複数のプロセスで実行されるOC4Jインスタンスで、EJBタイマーを使用するアプリケーションは実行できません。EJBタイマーがサポートされているのは、（opmn.xml構成ファイルの<process-set>要素がnumprocs=1の）単一のJVMで実行されるOC4Jインスタンスのみです。 

ただし、複数のJVMが効率的に稼働するには、追加のハードウェア・リソースが必要です。また、複数のプロセスが同じホストで稼働していて、そのホストが停止した場合には、すべてのJVMプロセスが停止します。

複数のアプリケーション・サーバー・インスタンスをインストールおよび管理する場合には、それらのアプリケーション・サーバー・インスタンスを複数のホストにインストールできます。アプリケーション・サーバーをクラスタ化し、「クラスタ・トポロジ」ページ（またはコマンドラインやAPI）からOC4Jグループを作成することで、アプリケーションのクラスタリングおよびロード・バランシングを利用することもできます。第9章「OC4Jでのアプリケーションのクラスタリング」で説明されているように、アプリケーションのクラスタリングにより、各JVMで稼働しているアプリケーションの異なるインスタンスに状態情報がレプリケートされます。

また、Oracle Application ServerクラスタおよびOC4Jグループにより、ハードウェアまたはネットワークの停止からさらに強固に保護されます。1つのホストが停止しても、別のホストにデプロイされているアプリケーションは使用可能です。

注意:

（ascontrolアプリケーションとして表される）Application Server Controlは、複数のJVMで稼働しているOC4Jインスタンスでは稼働できません。アクティブなApplication Server ControlインスタンスのホストであるOC4Jインスタンスには、複数のJVMを構成しないでください。 

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インスタンスに追加のJVMを作成する方法

Application Server Controlの「サーバー・プロパティ」ページで、OC4Jインスタンスに1つ以上のJVMを追加できます。

Application Server Controlを使用してOC4Jインスタンスに追加のJVMを作成する手順:
  1. OC4Jホームページに移動して「管理」をクリックし、OC4Jの「管理」ページを表示します。このページには、OC4Jインスタンスに対して実行可能な様々な管理タスクがリストされた表が表示されています。

  2. 「管理」ページで、「サーバー・プロパティ」を選択し、OC4Jの「サーバー・プロパティ」ページを表示します。

  3. 「VMのプロセス数」フィールドに、OC4Jインスタンスに構成するJVMの数を入力します。

  4. 「適用」をクリックします。

  5. 「クラスタ・トポロジ」ページまたはOC4JホームページからOC4Jインスタンスを再起動します。

opmn.xmlファイルのOC4Jインスタンスに追加のJVMを作成する方法

デフォルトで、各OC4Jインスタンスは1つのJVMを使用します。ただし、複数のJVMで稼働するようにOC4Jインスタンスを構成できます。opmn.xmlファイルのOC4Jインスタンスに関する構成で<process-set>要素のnumprocs属性を設定することで、1つ以上のJVMを追加できます。

opmn.xmlファイルのOC4Jインスタンスに追加のJVMを作成する手順:
  1. opmn.xmlファイルを編集します。

  2. 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>
  3. opmn.xmlファイルを保存します。

  4. OC4Jインスタンスを再起動します。

複数のJVMの監視

複数の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システム・プロパティを設定して監視を有効にする必要があります。

ダイナミック・モニタリング・サービスJVMメトリックの監視

Oracle Application Server環境でOC4Jを実行している場合は、各JVMの一連のダイナミック・モニタリング・サービス（DMS）メトリックを監視できます。これらのメトリックは、スタンドアロンOC4J環境では使用できません。

Application Server Controlを使用してOracle Application Server環境のDMS JVMメトリックを表示するには、次のようにします。

  1. OC4Jホームページに移動します。

  2. OC4Jホームページの「一般」セクションで、「仮想マシン」フィールドを探します。

  3. OC4JインスタンスにJVMがいくつ構成されているかを示す数をクリックします。

    「JVMメトリック」ページには、選択したOC4Jインスタンスに構成されているすべてのJVMの主要なメトリックのサマリーが表示されます。この表を使用して、複数のJVMのパフォーマンスを比較できます。

  4. 詳細は、JVMの名前をクリックしてください。

    OC4Jの「JVM」ページには、JVMの状態を詳細に示す一連のグラフおよび数値メトリックが表示されます。「データの表示」リストからリフレッシュ間隔を選択します。その後、パフォーマンス・グラフで一定期間の変化を参照できます。

J2SE JVM 5.0メトリックを監視するためのjmxremoteシステム・プロパティの設定

J2SE JVM 5.0メトリックを監視するために、Application Server Control、OC4J起動オプション、また、OPMN管理環境の場合はopmn.xmlファイルを使用して、jmxremoteシステム・プロパティを設定できます。

Application Server Controlコンソールを使用したjmxremoteシステム・プロパティの設定

Application Server Controlを使用して、各OC4JインスタンスのJVM J2SE 5.0メトリックの監視を有効化するには、次のようにします。

  1. OC4Jホームページに移動して「管理」をクリックし、OC4Jの「管理」ページを表示します。このページには、OC4Jインスタンスに対して実行可能な様々な管理タスクがリストされた表が表示されています。

  2. OC4Jの「管理」ページで、「サーバー・プロパティ」を選択し、OC4Jの「サーバー・プロパティ」ページを表示します。

  3. ページの「コマンドライン・オプション」セクションまでスクロールして、「J2SE 5.0プラットフォームMBeanの有効化」を選択します。

  4. 「適用」をクリックして、変更内容を適用します。

  5. 「クラスタ・トポロジ」ページに移動して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ファイルに手動でプロパティを設定する必要はありません。

Oracle Application Server環境のJ2SE 5.0 JVMメトリックの監視

Application Server Controlを使用してOracle Application Server環境のJ2SE 5.0 JVMメトリックを表示するには、次のようにします。

  1. OC4Jホームページの「一般」セクションで、「仮想マシン」フィールドを探します。

  2. OC4JインスタンスにJVMがいくつ構成されているかを示す数をクリックします。

    「JVMメトリック」ページが表示されます。

  3. JVMの名前をクリックします。

    OC4Jの「JVM」ページが表示されます。

  4. ページの「関連リンク」セクションまでスクロールし、「J2SE 5.0メトリック」をクリックします。

スタンドアロンOC4J環境のJ2SE 5.0 JVMメトリックの監視

Application Server Controlを使用してスタンドアロンOC4J環境のJ2SE 5.0 JVMメトリックを表示するには、次のようにします。

  1. OC4Jホームページで、「パフォーマンス」をクリックして「OC4Jのパフォーマンス」ページを表示します。

  2. ページの「関連リンク」セクションまでスクロールし、「J2SE 5.0メトリック」をクリックします。

戻る 次へ
Oracle
Copyright © 2006, 2008 Oracle Corporation.
All Rights Reserved.
目次
目次		 索引
索引