10gリリース3（10.1.3.1.0）
B31837-01
 目次 |
 索引 |
| Oracle Process Manager and Notification Server 管理者ガイド 10gリリース3（10.1.3.1.0） B31837-01 |
|
この章では、Oracle Application Serverのopmn.xmlファイルの概要について説明します。この章の項目は次のとおりです。
ORACLE_HOME/opmn/conf/opmn.xmlファイルは、OPMNの主要な構成ファイルです。opmn.xmlファイルには、PMおよびOracle Application Serverコンポーネント固有の構成情報が含まれています。opmn.xmlファイルでは、システム上でどのOracle Application ServerコンポーネントがOPMNによって管理されているかがわかります。
opmn.xmlファイルには、コンポーネント固有の要素名は含まれません。コンポーネント固有の管理コードは、opmn.xmlファイルのmodulesセクションのPM Modulesで指定されています。これはOPMNの起動時にロードされます。
各レベルには、一連の固有の構成があります。また、複数のレベルで有効な構成要素もあるため、構成はOracle Application Serverコンポーネント全体に適用することもコンポーネントの一部にのみ適用することもできます。
<ias-component> <process-type> <process-set>
<ias-component>: Oracle Application Serverコンポーネントを表します。このエントリにより、起動や停止などのプロセスを実行するコンポーネントを管理します。
<process-type>: <ias-component>エントリのサブコンポーネントで、特定のPM Modulesに関連して実行するプロセス・タイプを宣言します。
<process-set>: <ias-component>エントリのサブ・サブコンポーネントで、Oracle Application Serverコンポーネント用のオプションのランタイム引数やランタイム環境の異なるセットを宣言できます。
opmn.xmlファイルには、Oracle Application Serverコンポーネントのエントリが、例3-1に示すような階層構造で配置されます。
<ias-component id="OC4J"> <process-type id="home"> <process-set id="default_group">....
ONSはopmn.xmlファイルで構成できます。例3-2は、opmn.xmlファイルのons.conf要素の例です。
<notification-server> <topology> <nodes list="node-list"/> <discover list="discover-list"/> <gateway list="gateway-list"/> </topology>
Oracle Application Server 10gリリース3（10.1.3.1.0）では、OC4Jインスタンスをグループ化できます。opmn.xmlファイルの<ias-component>要素は、グループ化メカニズムとして使用可能です。
OC4Jグループでは、複数のOC4Jインスタンスに対して共通の管理タスクを自動的に実行できます。グループは、同じクラスタ・トポロジに属する、名前の類似したOC4Jインスタンスを緩やかに同期化したものです。
たとえば、COLORSというOC4Jグループを、次のように構成できます。
<ias-component id="COLORS"> <process-type id="home" module-id="OC4J"> <port id="ajp" range="3301-3400" /> <port id="rmi" range="3101-3200" /> <port id="jms" range="3201-3300" /> </process-type> <process-type id="oc4J_soa" module-id="OC4J"> <port id="ajp" range="3301-3400" /> <port id="rmi" range="3101-3200" /> <port id="jms" range="3201-3300" /> </process-type> </ias-component>
例3-3の例では、COLORSグループは、OC4Jインスタンスの同期化された集まりを示しています。OC4Jグループでは、複数のOC4Jインスタンスに対して共通の管理タスクを自動的に実行できます。この機能を使用すると、グループ内のすべてのOC4Jインスタンスを同時に構成できます。
具体的には、グループを使用すると、複数のOC4Jインスタンスに次の各タスクを1回の手順で実行できます。
グループ・メンバーシップは、OC4Jインスタンスに割り当てた名前によって自動的に定義されます。同じ名前を持つOC4Jインスタンスは、同じグループに属していると見なされます。
Application Server Controlコンソールを使用してOC4Jインスタンスのグループを管理するには、グループ内のすべてのOC4Jインスタンスに、管理OC4Jインスタンスと同じoc4jadminパスワードを構成する必要があります。
OPMNは、クラスタ環境内の他のONSサーバーと通信するために動的検出を使用します。opmn.xmlファイルには、マルチキャスト・アドレス、またはOPMNが使用する検出サーバーの一覧が含まれています。ONSでは、この検出メカニズムによって新しいサーバーがクラスタに通知され、ONSトポロジに動的に組み込まれます。
ONSネットワーク・トポロジには、同じ検出情報が構成されたOracle Application Serverインスタンスがすべて組み込まれています。
この情報は、opmn.xmlファイルのnotification-server要素の下に構成されています。例3-4は、opmn.xmlファイル内のnotification-server要素を示しています。
<notification-server interface="type"> <ipaddr remote="ip" request="ip"/> <port local="port" remote="port" request="port"/> <ssl enabled="boolean" wallet-file="path" wallet-password="password" openssl-certfile="path" openssl-keyfile="path" openssl-password="password" openssl-lib="path"/> <tune io-timeout="timeout" io-idle="interval" timeout="timeout"/> <topology> <nodes list="nodes"/> <discover list="nodes"/> <gateway list="nodes"/> </topology> </notification-server>
次の項では、動的検出の3つの構成タイプについて説明します。
マルチキャスト構成の動的検出の場合、opmn.xmlファイルですべてのONSサーバーのマルチキャスト・アドレスを構成します。ONSはこのアドレスを使用して、クラスタ内の他のすべてのOracle Application Serverインスタンスを検出します。
図3-1「マルチキャスト構成」では、マルチキャスト構成の仕組みを動的に示しています。
クラスタに新しいOracle Application Serverインスタンスが追加されると、構成されたマルチキャスト・アドレスを使用して通知されます。接続トポロジは、インスタンスが追加または削除されるとONSが自動的に管理します。
複数のマルチキャスト・アドレスが構成されている場合もありますが、通常これはサブネットやサブネットを接続するゲートウェイを区別するために使用されます。
マルチキャスト構成の実装方法の詳細は、第6章「opmn.xmlの一般的な構成」を参照してください。
検出サーバー構成の動的検出の場合、1つのOracle Application Serverインスタンスがすべてのインスタンスの検出サーバーとして機能します。ONSはこの検出サーバーを使用して、クラスタ内の他のすべてのOracle Application Serverインスタンスを検出します。
図3-2「検出サーバーの構成」では、検出サーバー構成の仕組みを動的に示しています。
クラスタに新しいOracle Application Serverインスタンスが追加されると、構成済の検出サーバーと通信し自身を通知します。接続トポロジは、インスタンスが追加または削除されるとONSが自動的に管理します。検出サーバーは、複数構成することもできます。
検出サーバー構成の詳細は、第6章「opmn.xmlの一般的な構成」を参照してください。
ゲートウェイ構成の動的検出の場合、検出された複数のトポロジ・リングを相互接続するためにゲートウェイが使用されます。
図3-3「ゲートウェイ構成」では、ゲートウェイ・サーバー構成の仕組みを動的に示しています。
ゲートウェイを使用すると、検出された複数のトポロジ・リングを相互接続できます。
ゲートウェイ構成は、ネットワーク・トポロジ内のノードが同一のサブネット内にない場合や、物理的に同じ場所にない場合に使用します。
ゲートウェイ構成の詳細は、第6章「opmn.xmlの一般的な構成」を参照してください。
Dynamic Resource Management（DRM）は、必要な動作が記述され、必要な結果を得るためにアクションを実行するOPMNの機能です。DRMの機能を使用すれば、構成を変更するだけでプロセスの管理方法をカスタマイズできます。DRMでは、ユーザーが構成する一連のディレクティブに従って、システムの状態に基づくプロセス管理コマンドを発行できます。
DRMは、単一のOracle Application Serverインスタンスで稼動するように設計されています。クラスタ環境では、DRM機能をローカル・インスタンスごとに使用できます。
OPMNによって認識されるDynamic Monitoring Service（DMS）メトリックも、システムの状態として考慮に入れることができます。ユーザーは、DMSが実行時に収集したパフォーマンス情報（DMSメトリック）を使用して、システムのパフォーマンスを分析したり、システムのステータスを監視することができます。DMSメトリックには、事前設定された常駐のメトリックと、ユーザーが定義し実装するメトリックがあります。DMSの詳細は、『Oracle Application Serverパフォーマンス・ガイド』を参照してください。
DRMを使用すると、プロセス管理コマンドをトリガーする条件を指定して、自動的に発行することができます。これは、Resource Management Directive（RMD）を使用して実行できます。RMDは、次のような情報を指定する一連の条件です。
RMDを使用すると、システム状態を定期的に監視し、その状態がRMDで指定した有効範囲を超えた場合にアクションを実行できるようにOPMNを構成することができます。
たとえば、図3-4のDRMの図では、RMDを次のように構成できます。
RMDの詳細は、第3.4.1項「Resource Management Directive」を参照してください。
RMDとは、評価する一連の情報、この情報のうちのアクションのトリガー対象となる値、および実行するアクションです。RMDは、次の7つの項目で構成されています。
たとえば、次のとおりです。
この設定では、システムのパフォーマンスが不安定になったり、メトリック値のポーリング回数が不要に増えない程度に、状況の変化に迅速に対応できるよう、RMDの評価の頻度を増やすことができます。
たとえば、次のとおりです。
これは、条件に満たないときは、不要なアクションを実行しない場合に使用します。一時的な状況だけでリソースの割当てを増やすのではなく、75%超のCPU使用率が2分間以上続いた場合にのみ、管理者がアクションを実行したいと考える場合などです。
このアクションは、コンポーネントの起動、停止、または再起動などです。また、新たにプロセスを起動するなどの別のリソースの要求や、別のノードでのアプリケーションの起動要求も含みます。
例外では、代替のアクションを実行したり、Oracle Enterprise Manager 10gなどのモニターにメッセージを送信したりすることができます。
ias-componentに構成された各process-setが評価される間隔の指定
DRMは、RMDで指定されたアクションを評価し、実行します。
図3-5では、2つのホスト上でのDRMの管理を示しています。いずれのホストにもApp1とApp2の2つのアプリケーションが配置されています。2つのホストはアプリケーションのロードを負担しています。それぞれのホストは最大5プロセスを実行できる容量があります。図3-5では、App1の要求の方がApp2よりも多いため、ロードの処理にApp1の方が多くのプロセスが起動されています。
図3-6では、App2への要求が増大しApp1への要求が減少するに従って、App1のプロセスが自動的にシャットダウンし、App2のプロセスが自動的に増え起動される様子を示しています。リソースがどの程度必要かは各コンピュータで判断され、コンピュータ間では調整しません。需要の変化はコンピュータごとに検知され、それぞれで類似のアクションを実行してそれを吸収しようとするため、システム全体としては需要に対応します。
両コンピュータの各アプリケーションの総需要は、2〜8プロセスです。今までは、アプリケーションごとのシステム・リソースのピーク需要の処理が可能な、ハードウェア構成をする必要がありました。そのため、プロセスを16実行できるシステム・ハードウェアを用意する必要がありました。
3台のコンピュータでそれぞれプロセスを5つ実行できるとしても、アプリケーションの需要に対しシステム・リソースは不十分です。しかし、DRMを使用してApp1とApp2間でリソースを動的に調整すると、各アプリケーションのピーク時のロードは2台のコンピュータのみで処理できます。
例3-5に、RMDの構文を示します。
<rmd name="rmd name"> <conditional> <!CDATA[conditional]> </conditional> <action value="action 1"/> <action value="action 2"/> ... <action value="action N"/> <exception value="exception 1"/> <exception value="exception 2"/> ... <exception value="exception N"/> </rmd>
例3-6では、RMDが、プロセスの平均リクエスト・レスポンス時間が最大しきい値の1分を上回っているかどうかを評価し、上回っている場合は、構成上可能であれば別のプロセスを起動します。
|
注意
例3-6と例3-7で使用されているメトリック値は例であり、実際のメトリック値ではありません。RMD定義に使用できる、OPMNで利用可能なメトリックは、 |
<rmd name="rampUp"> <conditional> <![CDATA[([process-set].responseTime > 5000) {duration(60)} & ([process-set].numProcs <[process-set].maxProcs)]]> </conditional> <action value="exec $ORACLE_HOME/scripts/logevent {ias-component} {process} slow response"/> <action value="start {process-set}"/> <exception value="exec $ORACLE_HOME/scripts/mailadmin {ias-component} {process-type} {process-set} could not start"/> </rmd>
図3-7、図3-8、図3-9、および図3-10は、構成されたパラメータを上回った場合のRMDのアクションを示しています。
図3-7では、平均リクエスト・レスポンス時間が上限のしきい値を上回っており、process-setのOC4Jプロセス数が、構成された最大数を下回っています。
図3-8では、RMDがアクションを実行し、それによってShopCart process-setに対してもう1つOC4Jプロセスが起動されています。
図3-8のディレクティブには、平均リクエスト・レスポンス時間が5分間以上、下限のしきい値を下回った場合に余分なOC4Jプロセスを停止する、補完的なRMD（例3-7）があります。
<rmd name="rampDown"> <conditional> <![(CDATA[([process-set].responseTime < 2000) {duration(500)} & ([process-set].numProcs > [process-set].minProcs)]]> </conditional> <action value="exec $ORACLE_HOME/scripts/logevent {ias-component} {process} fast response"/> <action value="stop {process-set}"/> <exception value="exec $ORACLE_HOME/scripts/mailadmin {ias-component} {process-type} {process-set} could not stop"/> </rmd>
図3-9では、平均リクエスト・レスポンス時間が、最低5分間は下限のしきい値を下回っており、ShopCart process-setのOC4Jプロセス数が、構成された最小数を上回っています。
図3-10では、RMDがアクションを実行し、それによってShopCart process-setに対しOC4Jプロセスが停止されています。
RMDには2種類の構成方法があります。その方法は、次のとおりです。
階層内の特定の場所に関連付けられたRMDには、その階層内の場所と相対的にRMDに関連付けられたメトリックおよびアクションしか指定できません。各RMDには評価レベルがあり、評価レベルには、ディレクティブによって参照される最も低いOPMNコンポーネント・レベルを指定します。上位に定義するRMD（ias-componentなど）は、そのRMDから参照される下位のすべてのコンポーネント（process-setなど）によって継承されます。たとえば、process-setを参照するias-componentレベルで定義されたRMDは、そのias-componentのすべてのprocess-setsによって継承されます。
グローバルRMDは、opmn.xmlファイルの別のセクションに構成します。グローバルRMDは、DMSツリー内のすべてのメトリックを使用でき、OPMNによって管理されているすべてのコンポーネントにアクションを実行できます。DMSの詳細は、『Oracle Application Serverパフォーマンス・ガイド』を参照してください。
RMDの条件には、アクションをトリガーするシステムの状態を記述します。条件は、2つの値の比較を論理的に組み合せたものです。OPMNのあらゆる機能と同様に、条件文では大文字と小文字が区別されます。使用できる値には次のものがあります。
DMSの詳細は、『Oracle Application Serverパフォーマンス・ガイド』を参照してください。
DMSメトリックは、OPMN DMSツリー内の位置に基づいて記述します。次のような記述方法があります。
目的のメトリックへの完全修飾パスは、先頭にスラッシュ（/）を付け、OPMNインスタンスからのフルパス（/pm/host_statistics/freePhysicalMem）を記述します。OPMNインスタンスの接頭辞は、自動的にこれらのパスに追加されます。
完全修飾されたパス名を持つメトリックは、階層RMD条件とグローバルRMD条件の両方から参照できます。
RMDが階層の場合、メトリックは、[process-set].numProcsのように相対パスの形式で記述できます。これは、そのRMDが属す階層内のprocess-setのnumProcsメトリックであることを示します。
階層RMD条件で指定できるコンポーネントは次のとおりです。
[ias-component]: opmn.xmlファイルの階層内のias-component要素を示します。
[process-type]: opmn.xmlファイルの階層内のprocess-typeを示します。
[process-set]: opmn.xmlファイルの階層内のprocess-setを示します。
[process]: ランタイム階層内のプロセスを示します。
[application]: ランタイム階層内のアプリケーションを示します。他のすべての階層の記述仕様とは異なり、具体的なアプリケーション名を指定できます。
RMDがグローバルの場合、メトリックは、絶対的な開始ポイントを記述した後、相対パスを記述できます。たとえば、次のとおりです。
[ias-component=WebCache][process-set=WebCache].numProcs
これは、ias-component WebCacheに属する、process-set WebcacheのメトリックnumProcsを示します。
グローバルRMD条件で指定できるコンポーネントは次のとおりです。
[ias-component=<comp>]: opmn.xmlファイルのias-component <comp>を示します。
[process-type=<ptype>]: opmn.xmlファイルのprocess-type <ptype>を示します。
[process-set=<pset>]: opmn.xmlファイルのprocess-set <pset>を示します。
[process]: プロセスを示します。
[application]: アプリケーションを示します。
[application=<app>]: プロセスで実行されているアプリケーション<app>を示します。
OPMNプロセス・リクエストと同様に、ディレクティブで指定されていないコンポーネントはワイルドカードと見なされます。そのため、[process-set=home]を参照するグローバルRMDは、opmn.xmlファイルのid homeが付いたすべてのprocess-setで評価されます。
1つの条件で、複数のOPMNコンポーネントを参照することはできません。たとえば、1つの条件で、[ias-component=Webcache]と[ias-component=HTTP_Server]は参照できません。同様に、1つの条件で、下位の構成コンポーネントを参照する場合、そのコンポーネントは参照元である上位のコンポーネントに属している必要があります。
プロセスを除き、大カッコで囲まれたセクションは、OPMN DMSツリーのダンプに示されるように、DMSツリーのタイプと一致する必要があります。
階層RMDとグローバルRMDのいずれでも、カッコ付セクションを複数指定できますが、後続のセクションでは、ツリーの範囲を限定していく必要があります。順序としては、ツリーの頂点から枝葉に向かうようにする必要があります。プロセスは、ias-componentの前に記述することはできません。
定数値は、小数点を含む平易な数値である必要があります。定数値をDMSメトリックと比較する場合は、比較対象であるDMSメトリックと同じ単位にする必要があります。DRMでは、演算子の右側にある数値を左側で同じタイプ（小数点または整数）に変換しますが、それ以外の単位は変換されません。
時間の値は、24時間形式（hh:mm）で指定しますが、オプションで曜日のインジケータと組み合せることができます。使用できる曜日の略語は、mon、tue、wed、thu、fri、sat、sunです。曜日インジケータには、単一の値、カンマ区切りリスト、またはダッシュを使用したリストが使用できます。たとえば、次のとおりです。
現在の時間は、キーワード{time}で表します。演算子の左側に指定した曜日に、右側で指定した曜日が含まれない場合、時間の比較はfalseと評価されます。つまり、デフォルトでは、曜日が同じであるかどうかのみが評価され、その評価がtrueの場合のみ、時間の値が指定された演算子で評価されます。曜日の後ろに@文字を追加することにより、単一の曜日に対する比較を強制できます。この場合、日曜（sun）は値0、土曜（sat）は値6として扱われます。
値の比較には次の演算子を使用できます。より小さい（<）、以下（<=）、より大きい（>）、以上（>=）、等しい（=）、等しくない（!=）。
また、一重引用符文字（'）を使用して引用符内に文字列値を指定することもできます。ただし、演算子として使用できるのは、等しい（=）と等しくない（!=）のみです。
比較は、演算子を使用して論理的に組み合せることができます。たとえば、AND（&）、OR（|）、NOT（!）、GROUPING（( )）などの演算子を使用できます。論理NOT単項演算子（!）を比較する論理グループの前に付けると、その結果を論理的に反転できます。
キーワード{duration(interval)}を使用すると、指定された時間隔（秒単位）に条件がtrueと評価された場合にのみ、条件がトリガーされるように指定することもできます。この場合、条件は、ある期間に限ってしか評価されないことに注意してください。期間の値を指定した場合、その期間すべての評価が条件に一致した場合にのみ、条件はトリガーされます。これは、指定された時間隔全体でこの条件がtrueであることを保証する近似処理です。この近似処理の精度は、durationの値と評価期間の割合に依存します。条件がtrueと評価されると、その評価のすべてのdurationがリセットされます。条件がfalseと評価された場合は、評価の間に出現しなかったdurationはリセットされます。
次の例では、RMD条件で特定の状態を検出します。
[process-set=home][process].heapSize > 500000
{time} = [MonFri].1700
process-setに対して実行されているプロセスが4より少ない場合（OC4J）:([process].avgReqTime > 500 {duration(60)})&([process-set].numProcs <4)
/pm/host_statistics.freePhysicalMemory < 50000 {duration(180)}
RMDのアクションのセクションにはアクション要素のリストがあります。これらはプロセス管理コマンドで、RMDの条件に一致した場合に実行されるアクションです。これらのコマンドの構文は、opmnctlの構文と類似していますが、有効範囲はありません。
RMDに指定できるアクションには、次のものがあります。
start: 指定した引数リストとともに起動リクエストを実行します。
restart: 指定した引数リストとともに再起動リクエストを実行します。
stop: 指定した引数リストとともに停止リクエストを実行します。
exec: 指定したプログラムまたはスクリプトを引数リストとともに実行します。
start、restart、およびstopリクエストのターゲットは、RMD条件で参照されるOPMNコンポーネントと相対的であると見なされます。リクエストの範囲を限定するために、それらのコンポーネントを示すキーワードを使用する必要があります。
次のキーワードを使用できます。
{ias-component} ias-component=<comp>
{process-type} process-type=<ptype>
{process-set} process-set=<pset>
{process} uniqueid=<uid>
{application} application=<app>
start、restart、およびstopアクションでは、キーワード{process}は他のキーワードとともに使用しないでください。
また、execアクションには、{pid}キーワードを使用できます。これは、条件がprocess-setまたはプロセスを参照する場合、pid=<pid>と同じであると見なされます。
ただし、アクションは、条件で参照される最下位のOPMNコンポーネントよりも下位のOPMNコンポーネントのキーワードは参照できません（たとえば、条件がias-componentのみを参照する場合、アクションに使用できるのは{ias-component}キーワードのみです）。このルールの例外は、条件がprocess-setを参照する場合に、アクションが{process}を参照できることです。ただし、その場合、RMDはprocess-setレベルではなく、プロセス・レベルで評価されます。
start、restart、およびstopリクエストが成功ではない状態を返す場合（200が成功）、またはexecが0以外のコードで終了する場合、残りのアクションは省略され、RMDに構成された例外処理が実行されます。
タイムアウト値はアクションごとに構成できます。start、restart、およびstopアクションのデフォルトのタイムアウト値は、OPMNリクエストに構成された（またはデフォルトの）タイムアウト値です。execアクションのデフォルトのタイムアウト値は30秒です。
RMDリクエストの結果は、OPMNプロセス・マネージャ・ログに記録されます（リクエストの開始と完了が記録されます。完了ステータスはレベル4、完全な結果はレベル5）。execプログラムまたはスクリプトのstdoutおよびstderrは、$ORACLE_HOME/opmn/logs/rmd.outに送られます。ただし、rmd.outファイルではローテーションは行われません。そのため、プログラムとスクリプトではそれぞれ固有のログ・ファイルを保持し、使用する必要があります。プログラムおよびスクリプトでは、ファイル・ディスクリプタstdoutおよびstderrには出力しないでください。
次にRMDアクションの例を示します。
process-setは、minprocs/maxprocsで構成する必要があります）。start {ias-component}{process-type}{process-set} numprocs=1
restart {process}
ias-componentを停止します。stop {ias-component}
exec $ORACLE_HOME/mybin/report.sh "RMD triggered" {process} {pid}
RMDの例外セクションは、RMDのアクション・セクション内のいずれかのプロセス管理コマンドが正常に実行できなかった場合に実行するプロセス管理コマンドのリストです。例外セクションの形式は、アクション・セクションの形式と同じです。
opmn.xmlファイルのRMD構成RMDは、opmn.xmlファイルのrmd-defintionsというセクションに構成されます。各RMDの条件、アクション、例外の部分は、.xml定義の属性です。例3-8に、RMDがopmn.xmlファイルの階層RMDとして定義される例を、例3-9に、RMDがグローバルRMDとして定義される例を示します。
<process-type id="home" moduleid="OC4J" status="enabled"> . . . <rmd-defintions> <rmd name="requesttime" description="Start another OC4J (if possible) when the response time of any exiting OC4J in home exceeds 500msecs for a minute" interval="30"> <conditional> <![CDATA[([process].avgReqTime > 500 {duration(60)})&([process-set].numProcs < 4)]]> </conditional> <action value="start {ias-component}{process-type}{process-set} numprocs=1"/> <exception value="exec $ORACLE_HOME/mybin/mailer.sh {ias-component} {process-type}{ process-set} failed to start on RMD request"/> </rmd> </rmd-defintions> </process-type>例3-9 グローバルRMDの例
<process-manager> . . . <rmd-defintions> <rmd name="requesttime" description="Start another OC4J (if possible) when the response time of any exiting OC4J in home exceeds 500msecs for a minute" interval="30"> <conditional> <![CDATA[([process].avgReqTime > 500 {duration(60)})&([ias-component=OC4J] [process-set=home].numProcs < 4)]]> </conditional> <action value="start {ias-component}{process-type} {process-set}.numprocs=1"/> <exception value="exec $ORACLE_HOME/mybin/mailer.sh {ias-component} {process-type}{process-set}failed to start on RMD request"/> </rmd> </rmd-defintions> </process-manager>
RMDは、構成された間隔、またはデフォルト値の30秒で定期的に評価されます。ただし、RMDを評価するために消費されるCPUサイクルと、RMDを実行する更新検出との間にはトレード・オフがあります。{duration()}キーワードによって定義される評価期間と時間値は、適切な割合である必要があります。
RMDは、RMDが構成されている場所と、条件によって参照される対象に基づいて評価されます。グローバルRMDの場合は、メトリックまたは内部の時間値へのフルパスのみが参照され、構成された時間間隔ごとに1つの評価のみが実行されます。ias-componentの下で定義され、process-setを参照する階層RMDの場合は、ias-componentに構成された各process-setが時間間隔ごとに1度評価されます。条件、アクション、または例外のいずれかのプロセスを参照するRMDの場合は、RMDによって参照されるコンポーネントの下位の各プロセスが時間間隔ごとに1度評価されます。ただし、プロセスを参照するRMDは、プロセスが存在し、Alive状態である場合にのみ評価されます。
DMSメトリックは、評価時に取得されます。参照されたDMSメトリックが見つからない場合は、その部分の条件はfalseとして評価されます。
メトリックの無効なタイプの比較は、評価時に検出されます。無効なタイプの比較が出現した場合、現在の評価が中止され、RMDは無効になり、そのRMDに基づく他のすべての評価は中止されます。エラーは、OPMNプロセス管理ログに記録されます。
サービスのフェイルオーバーは、処理を行っているサーバー上のサービスが停止したときに、実行する必要があるその重要なプロセスをOracle Application Serverクラスタ内の他の場所に指定するメカニズムです。これにより、優先して実行を継続させる必要があるプロセスを選択できます。
process-type opmn.xmlファイル内のすべての要素は、サービスのフェイルオーバー対象として構成できるため、一度起動すれば、構成された数のそのサービスのプロセスは必ずクラスタ内のいずれかのOracle Application Serverインスタンスで実行され続けることが保証されます。
サービス・フェイルオーバーを実行するOracle Application Serverインスタンスは、インスタンスごとに構成します。利用可能なインスタンスでどのプロセスを優先的に実行するかは、インスタンスごとに構成できます。
サービスのフェイルオーバー対象として構成されたprocess-typeには、1つしかprocess-setを定義できません。1つのサービス・フェイルオーバー・インスタンスで実行できるプロセスは1つのみです。
図3-11は、すべてのインスタンスがサービスのフェイルオーバー対象として構成されているクラスタで、サービスのフェイルオーバー・プロセスが起動されたところを示しています。
図3-12に示すように、サービスのフェイルオーバー・プロセスが実行されているインスタンスが、メンテナンス、予期せぬ停電、またはネットワーク障害などにより停止した場合、OPMNは、サービスのフェイルオーバー対象のOracle Application Serverインスタンスの中からそのプロセスを引き継ぐ別のインスタンスを選択します。図3-12に示したすべてのインスタンスは、サービス・フェイルオーバー対象です。
OPMNでは、コンポーネントの自動障害検出および再起動の制御、OPMNがプロセスの障害を特定する際に使用するパラメータの設定、各コンポーネントの自動再起動の無効化を実行できます。
OPMNは、次の方法で管理対象プロセスの動作を監視します。
pingおよび通知機能は、Oracle Application Serverコンポーネントの機能に従って適切な場合にのみ実行されます。
OPMNは、予期せず中断したOracle Application Serverコンポーネントを自動的に再起動します。またOPMNは、通知およびping操作の結果に基づいて応答しないプロセスを再起動します。
特定のコンポーネントが起動、停止またはクラッシュしたとき独自のカスタム・イベント・スクリプトを実行するようにOPMNを構成できます。次のいずれかのイベントを選択できます。
Oracle Application Serverのコンポーネントやサービスによっては、起動前に他のコンポーネントやサービスを実行させておく必要があります。OPMNでは、インストール時にデフォルトの起動順序の依存関係が構成されるため、1つのコマンドで、インスタンス内のすべてのコンポーネントを正しい順序で起動できます。Oracle Application Serverの依存関係の詳細は、『Oracle Application Server管理者ガイド』を参照してください。
OPMNには一連の依存関係が構成されますが、環境に応じて追加の依存関係を構成できます。
OPMNが生成するログ・ファイルには、パフォーマンスや構成の問題の特定に役立つ重要な情報が保存されています。Application Server Controlコンソールでは、Oracle Application Serverコンポーネントのログ・ファイルを容易に検索および表示し、確認できるようになっています。
ONSクライアントおよびPM管理プロセスが使用するOPMNのローカル・リスナー・ポートでは、セキュリティにSecure Socket Layer（SSL）暗号化を使用しませんが、別の2つのメカニズムを使用してOPMNサーバーへのアクセスを許可します。
ORACLE_HOME/opmn/conf/.formfactorファイルに記述されます。.formfactorファイルにアクセスできないプロセスは、OPMNサーバーとの相互作用を許可されません。
セキュリティ上の理由から、OPMNサーバーは、無効なフォーム・ファクタ鍵（このOPMNプロセスが.formfactorファイルに記述した値と一致しない鍵）を使用したローカル・ポートへの接続をすべて記録します。
セキュリティ違反の他に、接続が失敗する原因となる4つの一般的なユーザー・エラーがあります。
.formfactorファイルの値を読み取ることができるため、間違ったユーザーが実行するリクエストまたはプロセスでは、OPMNサーバーに正しい鍵を指定できません。
ORACLE_HOMEからOPMNクライアントを実行しようとする。1つのシステムに複数のORACLE_HOMEインスタンスを構成できます。他のORACLE_HOMEインスタンスのOPMNが同じローカル・ポートを使用するように構成されていると、間違ったORACLE_HOMEのOracle Application Serverプロセス・リクエストが、間違った.formfactorファイルを読み取ります。
opmn.xmlファイルのローカル・ポート構成を手動で変更し、前のOPMNサーバーを停止せずに新しいOPMNサーバーを起動した。新しいOPMNサーバーを実行すると、このプロセスが新しいポートにバインドし、.formfactorファイルが上書きされます。ローカル・ポートから前のOPMNサーバーに接続できなくなり、リモートのOPMNリクエスト（SSLおよび認証が構成されている場合）を実行するか前のOPMNサーバーを手動で停止しないと、前のサーバーをシャットダウンできなくなります。
Oracle Databaseでは、ONSは特別な構成に対してのみ使用されるため、通常は起動されていません。この場合、データベース・リスナーがDatabase ONSサーバーに接続を試みると、Oracle Application ServerとともにインストールされたONSサーバーに接続してしまうことになります。ONS（OPMNの構成要素としての）は、Oracle Application Serverの起動時は常に起動されています。
Oracle DatabaseはOracle Application Serverとは異なるORACLE_HOMEにインストールされるため、Oracle Application ServerとともにOPMNが起動されたときに作成された.formfactorファイルにDatabase ONSはアクセスできません。結果として、データベース・リスナーはOPMNへの接続を試み、DBリスナーはそれをフォーム・ファクタ文字列のない自分用のスタンドアロンONSとして解釈します。Oracle Application Server 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リスナーがOracle Application Server OPMNサーバーに接続するのを回避するには、Oracle DatabaseとともにインストールしたONSサーバーに対するデフォルトのローカルおよびリモート・ポート値を変更します。別の方法としては、OTNから入手可能な最新のOracle Databaseパッチセットを適用できます。
http://www.oracle.com/technology/products/
OPMNは、同じクラスタ内の他のOPMNサーバーへのリモート・リクエストをサポートしますが、セキュリティ上の理由から、すべてのプロセス制御リクエスト（起動、再起動および停止）は、opmn.xmlファイル内でSSLが有効であり、Walletファイルが構成されている場合にのみ許可されます。SSLおよびWalletファイルのいずれも構成されていない場合、OPMNはリモートのすべてのプロセス制御リクエストをHTTPコード403で拒否します。
リモート管理に使用するリモート・ポートでは、SSLを有効にする必要があります。このリモート・ポートは、複数のOPMNサーバー間の通信にのみ使用してください。Oracle Application ServerコンポーネントおよびApplication Server Controlコンソールは、リモート管理でアクセスできないローカル・ポートを使用して送信を行います。すべてのアクセス制御および認証は、Application Server Controlコンソールを通して制御されます。
Oracle Application Serverのインストール時、OPMNはデフォルトの証明書が含まれたWalletを使用するように構成されます。安全性のため、この証明書をセキュアな一意の証明書と交換する必要があります。Oracle Wallet内で証明書を構成する方法の詳細は、『Oracle Application Server管理者ガイド』を参照してください。
『Oracle Application Server管理者ガイド』に記載されているorapkiスクリプトを使用すると、OPMNで適切なレベルのセキュリティが保証される、ランダムな自己署名の証明書を作成できます。
クラスタでOPMNを使用するには、クラスタ内の他のすべてのメンバーに信頼される証明書を構成する必要があります。これには、クラスタ内のすべてのOPMNインスタンスに同じWalletを使用するか、同じ認証局で作成された証明書を使用します。
10.1.3では、ONSは、ネットワーク・インタフェースIPv4とIPv6を同時にサポートします。
IPv4は、インターネット・プロトコル（IP）のバージョン4です。これは、広く普及したIPの最初のバージョンであり、現在のほとんどのインターネット（2004年時点）の基盤となっています。
IPv4のアドレスは、32ビットであるため、一意のアドレス数は4,294,967,296までに制限されます。これらのアドレスのほとんどは、ローカル・ネットワーク、マルチキャスト・アドレスなどの特別な用途に確保されるため、公に割り当てられるインターネット・アドレス数は少なくなります。
IPv6の導入により、デバイス（特に携帯電話やモバイル機器）の接続性に対する今後の需要拡大に対応可能なIPアドレスの不足問題を解決することが期待されています。IPv6は、340澗（3.4 × 1038）アドレスをサポートします。
図3-13に示すように、デバッグやログの記録などの出力のための各IPv4識別子には、アドレス用に8ビットのフィールドが4つ（それぞれ3桁の10進数形式）とポート用に16ビットのフィールドが1つ（5桁の10進数形式）表示されます。
各IPv6識別子は、アドレス用に16ビットのフィールドが8つ（それぞれ4桁の16進数値）とポート用に16ビットのフィールドが1つ（5桁の10進数値）表示されます。
|
 Copyright © 2006, Oracle. All Rights Reserved. |
|