Oracle Fusion Middleware Oracle Process Manager and Notification Server管理者ガイド 11gリリース1(11.1.1.1.3) B60985-01 |
|
戻る |
次へ |
この章では、Oracle Fusion Middlewareのopmn.xml
ファイルの概要について説明します。次のトピックで構成されています。
ORACLE_INSTANCE
/config/OPMN/opmn/opmn.xml
ファイルは、OPMNの主要な構成ファイルです。opmn.xml
ファイルには、PMおよびシステム・コンポーネント固有の構成情報が格納されています。opmn.xml
ファイルは、システム上のどのシステム・コンポーネントがOPMNによって管理されているかを示します。
opmn.xml
ファイルは、log files、notification-serverおよびprocess-managerの3つの主要セクションに分けられています。
log files: デフォルトのlog files構成は、標準ログを完全に有効化しますが、デバッグ・ログを無効化します。
notification-server: notification-server構成には、OPMNリスナー・ポートおよびセキュアな接続定義が含まれています。オプションの<topology>
opmn.xml
ファイル要素は、OPMN検出のために手動で追加できます。
process-manager: process-manager構成には、各管理対象コンポーネントに必要なすべての情報が含まれます。
opmn.xml
ファイルには、コンポーネント固有の要素名は含まれません。コンポーネント固有の管理コードは、opmn.xml
ファイルのmodules
セクションで指定されたPMモジュールにあります。これらのPMモジュールはOPMNの起動時にロードされます。
各レベルには、一連の固有の構成があります。また、複数のレベルで有効な構成要素もあるため、ある構成をシステム・コンポーネント全体に適用することもコンポーネントの一部にのみ適用することも柔軟にできます。
<ias-component> <process-type> <process-set>
<ias-component>
: システム・コンポーネントを表します。このエントリにより、起動や停止などコンポーネントのプロセスを管理できます。
<process-type>
: <ias-component>
エントリのサブコンポーネントであり、特定のPMモジュールに関連して実行するプロセス・タイプを宣言します。
<process-set>
: <ias-component>
エントリのサブ・サブコンポーネントであり、システム・コンポーネントに対するオプションのランタイム引数やランタイム環境の様々なセットを宣言できます。<process-set>
はオプションの構成要素です。
opmn.xml
ファイルには、システム・コンポーネントのエントリが、例3-1に示すような階層構造で配置されます。
OPMNでは、コンポーネントの自動障害検出と再起動をユーザーが制御できます。つまり、OPMNがプロセスの障害を特定する際に使用するパラメータを設定したり、各コンポーネントの自動再起動を無効化したりできます。
OPMNは、次の方法で管理対象プロセスの動作を監視します。
オペレーティング・システム・レベルでのシステム・プロセス障害の検出
システム・プロセスへの定期的なpingリクエスト
システム・プロセスからの定期的なステータス通知(リバースping)
pingおよび通知機能は、システム・コンポーネントの機能に従って適切な場合にのみ実行されます。
OPMNは、予期せず中断したシステム・コンポーネントを自動的に再起動します。またOPMNは、通知およびping操作の結果に基づいて応答しないプロセスを再起動します。
OPMNが生成するログ・ファイルには、パフォーマンスや構成の問題の特定に役立つ重要な情報が保存されています。Fusion Middleware Controlコンソールでは、システム・コンポーネントのログ・ファイルを容易に検索および表示し、確認できるようになっています。
ONSクライアントおよびPM管理プロセスが使用するOPMNのローカル・リスナー・ポートでは、セキュリティにSecure Sockets Layer(SSL)暗号化を使用しませんが、別の2つのメカニズムを使用してOPMNサーバーへのアクセスを許可します。
OPMNは、ローカル・リスナー・ポートをローカル・ホストにバインドします。ローカル・システムのユーザーは、このポートに接続してOPMNプロセスの制御リクエストを発行します。情報のリクエストは、システムIPにバインドされたOPMNリクエスト・ポート上で許可されます。リクエスト・ポートはSSL暗号化をサポートしません。
OPMNサーバー・プロセスが初めて起動してローカル・ポートに正常にバインドすると、出力可能なASCII文字の文字列が作成され、これがローカル接続の鍵として使用されます。ローカル・ポートへのすべての接続には、この鍵が含まれている必要があります。含まれていないと、OPMNサーバーにより切断されます。このASCII文字列は、ORACLE_HOME
/opmn/.formfactor
ファイルに書き込まれます。.formfactor
ファイルにアクセスできないプロセスは、OPMNサーバーとのやり取りを許可されません。
セキュリティ上の理由から、OPMNサーバーは、無効なフォーム・ファクタ鍵(このOPMNプロセスによって.formfactor
ファイルに書き込まれた値と一致しない鍵)を使用したローカル・ポートへの接続をすべてログに記録します。次のようなことが発生する可能性があります。
ユーザーが、間違ったユーザーIDを使ってOPMNクライアントを手動で実行しようとする。アプリケーション・サーバーのユーザーのみ.formfactor
ファイルの値を読み取ることができるため、間違ったユーザーが実行するリクエストまたはプロセスでは、OPMNサーバーに正しい鍵を渡すことができません。
ユーザーが間違ったOracleインスタンスからOPMNクライアントを実行しようとする(1つのシステムに複数のOracleインスタンスを構成できます)。他のOracleインスタンスのOPMNが同じローカル・ポートを使用するように構成されていると、間違ったOracleインスタンスからのシステム・プロセス・リクエストが、間違った.formfactor
ファイルを読み取ります。
ユーザーが、opmn.xml
ファイルのローカル・ポート構成を手動で変更し、前のOPMNサーバーを停止せずに新しいOPMNサーバーを起動した。新しいOPMNサーバーを実行すると、このプロセスが新しいポートにバインドし、.formfactor
ファイルが上書きされます。ローカル・ポートから前のOPMNサーバーに接続できなくなり、リモートのOPMNリクエスト(SSLおよび認証が構成されている場合)を実行するか前のOPMNサーバーを手動で停止しないと、前のサーバーをシャットダウンできなくなります。
Oracle Fusion MiddlewareとOracle Databaseの両方がONSを使用している。これらの2つの製品が同じホストにインストールされていると、ONS用のポート値がOracle DatabaseとOracle Fusion Middlewareコンポーネントの両方で同一である場合には、ONSポートの競合が発生することがあります。
Oracle Databaseでは、ONSは特別な構成に対してのみ使用されるため、通常は起動されていません。しかし、データベース・リスナーがDatabase ONSサーバーに接続を試みると、Oracle Fusion MiddlewareとともにインストールされたONSサーバーに接続してしまうことになります。ONS(OPMNの構成要素としての)は、Oracle Fusion Middlewareを起動すると常に起動されます。
Oracle DatabaseはOracle Fusion Middlewareとは異なる場所にインストールされるため、Oracle Fusion MiddlewareとともにOPMNが起動されたときに作成された.formfactor
ファイルにDatabase ONSはアクセスできません。結果として、データベース・リスナーはOPMNへの接続を試み、DBリスナーはそれをフォーム・ファクタ文字列のない自分用のスタンドアロンONSとして解釈します。OPMNは、ons.log
ファイルに次のようなエラーを記録します。
04/11/15 18:43:32 [4] Local connection 0,127.0.0.1,6100 invalid form factor
これはOPMNの予定された動作で、正しいフォーム・ファクタ文字列を所持しないかぎり、ONSサーバーへのクライアント・アクセスが禁止されます。
Oracle DatabaseリスナーがシステムOPMNサーバーに接続するのを回避するには、Oracle DatabaseとともにインストールしたONSサーバーに対するデフォルトのローカルおよびリモート・ポート値を変更します。
ONSは、ネットワーク・インタフェースIPv4とIPv6を同時にサポートできます。
IPv4は、インターネット・プロトコル(IP)のバージョン4です。これは、広く普及したIPの最初のバージョンであり、現在のほとんどのインターネットの基盤となっています(2004年時点)。
IPv4のアドレスは32ビットであるため、一意のアドレス数は4,294,967,296までに制限されます。これらのアドレスのほとんどは、ローカル・ネットワーク、マルチキャスト・アドレスなどの特別な用途に確保されるため、公に割り当てられるインターネット・アドレス数は少なくなります。
IPv6の導入により、デバイス(特に携帯電話やモバイル機器)の接続性に対する今後の需要拡大に対応可能なIPアドレスの不足問題を解決することが期待されています。IPv6は、340澗(3.4 × 1038)アドレスをサポートします。
図3-1に示すように、デバッグやログの記録などの出力のための各IPv4識別子は、アドレス用に8ビットのフィールドが4つ(それぞれ3桁の10進数表記)とポート用に16ビットのフィールドが1つ(5桁の10進数表記)表示されます。
各IPv6識別子は、アドレス用に16ビットのフィールドが8つ(それぞれ4桁の16進数表記)とポート用に16ビットのフィールドが1つ(5桁の10進数表記)表示されます。