|
|
この節では、WLOC を使用してアプリケーションをデプロイおよび管理するためのポリシーを作成する方法について説明します。この節は、以下のトピックで構成されています。
各 WLOC ポリシーは、制約とアクションまたはアクション パイプラインで構成されています。制約では、サービスの一部のデプロイメントまたは実行時の要件を定義します。一方、アクションまたはアクション パイプラインでは、サービスの runtime-value が constraint-value の範囲外になった場合に実行する 1 つまたは複数のアクションを定義します。
たとえば、少なくとも 2 つの実行プロセスの実行時の要件を定義する制約、および実行するプロセスが 1 つだけ見つかった場合にプロセスを開始するアクションでポリシーを構成することができます。
図 6-1 は、制約とアクションの基本的な関係を示しています。
ポリシーに対する制約とアクションの割り当ては、「制約とアクションのバインディング」と呼ばれます。
コード リスト 6-1 は、metadata-config.xml ファイルにおけるサービス定義の一部としての制約とアクションのバインディングを示しています。この例における「キー」の名前は、ファイル内の他の場所にある制約とアクションの定義全体への参照です。
<ns2:service>
<ns2:name>MyService</ns2:name>
<ns2:description>MyService</ns2:description>
<ns2:state>deployed</ns2:state>
<ns2:priority>0</ns2:priority>
<ns2:constraint-bindings>
<ns2:constraint-binding>
<ns2:constraint-key>MyServicedeploy-key</ns2:constraint-key>
<ns2:action-key>MyServicestartserviceaction</ns2:action-key>
</ns2:constraint-binding>
</ns2:constraint-bindings>
</ns2:service>
ポリシーのスコープに適した制約とアクションのバインディングを行うことが非常に重要です。たとえば、一部のサービス デプロイメントの状態を指定する制約は、サービスをステージング、デプロイ、またはアンデプロイできるアクションにバインドする必要があります。
推奨されるポリシーの定義方法は WLOC Administration Console を使用する方法ですが、メタデータ コンフィグレーション ファイル (metadata-config.xml) を直接編集することもできます。ファイルを直接編集する場合は、3 つの定義 (サービスまたはプロセスの種類に基づく制約のバインディング、制約、およびアクション) を指定する必要があります。
コード リスト 6-2 は、制約のバインディングの XML コードを示しています。コード リスト 6-1 に示すように、制約のバインディングはサービス定義内に含まれます。制約のバインディングには、ファイル内の他の場所にある実際の制約とアクションの定義への「キー」が含まれます。
<ns2:constraint-binding>
<ns2:constraint-key>MyServicedeploy-key</ns2:constraint-key>
<ns2:action-key>MyServicestartserviceaction</ns2:action-key>
</ns2:constraint-binding>
</ns2:constraint-bindings>
コード リスト 6-3 は、上記の制約のバインディングで参照される制約の定義の XML コードを示しています。
<ns2:deployment-state-constraint>
<ns2:name>MyService-service-deploy</ns2:name>
<ns2:key>MyServicedeploy-key</ns2:key>
<ns2:priority>0</ns2:priority>
<ns2:state>starting</ns2:state>
<ns2:evaluation-period>0</ns2:evaluation-period>
</ns2:deployment-state-constraint>
コード リスト 6-4 は、コード リスト 6-2 に示す制約とアクションのバインディングで参照されるアクションの定義の XML コードを示しています。
<ns2:actions>
<ns2:action>
<ns2:name>MyServicestartserviceaction</ns2:name>
<ns2:key>MyServicestartserviceaction</ns2:key>
<ns2:impl-class>com.bea.adaptive.actions.internal.StartServiceAction</ns2:impl-class>
<ns2:adjudicate>false</ns2:adjudicate>
<ns2:properties/>
</ns2:action>
</ns2:actions>
メタデータ コンフィグレーション ファイルの編集方法を理解するには、スキーマ ファイル (BEA_HOME\wloc_10.3\schemas\loc-metadata.xsd) を使用し、サービス メタデータ コンフィグレーション スキーマ リファレンスも参照してください。
必要に応じて管理対象アプリケーションをデプロイして実行するために必要なポリシーの識別を開始する場合は、目的別または機能別にポリシーを分類すると役立つことがあります。この点から、ポリシーはデプロイメント、実行時、または管理のカテゴリに分類することができます。
デプロイメント ポリシーでは、管理対象アプリケーションの必要なデプロイメントの状態 (デプロイ済み、ステージング済み、アンデプロイ済み) およびアプリケーションが必要な状態になっていない場合に実行するアクションを定義します。たとえば、デプロイメント ポリシーでは、サービス デプロイメントの状態が「デプロイ済み」であることが必要な場合があります。現在のサービスの状態が「デプロイ済み」でない場合、WLOC はサービスをデプロイします。
表 6-1 は、デプロイメント ポリシーの定義に使用できる制約とアクションの種類を示しています。
| 注意 : | [Resource Agreement] 制約はアクションにバインドされません。 |
実行時ポリシーは、管理対象アプリケーションの継続的なパフォーマンスを調整し、必要に応じて順応的な実行時調整を行うために使用されます。このポリシーの使い方の例を次に示します。
表 6-2 は、実行時ポリシーの定義に使用できる制約とアクションを示しています。
管理ポリシーでは、制約違反があった場合に実行する管理アクションを定義します。たとえば、何らかの制約違反があった場合に、管理アクションによって電子メール通知または Administration Console イベント メッセージを生成できます。
表 6-3 は、管理ポリシーの定義に使用できる制約とアクションの種類を示しています。
WLOC には、状態とパフォーマンスの一般的かつ重要な一連の測定値を使用して要件を定義するための制約の種類があらかじめ用意されています。表 6-4 は、あらかじめ用意されている制約の種類を示しています。
| 注意 : | これらの制約の種類の詳細については、『WLOC Administration Console オンライン ヘルプ』の「制約の定義」を参照してください。 |
|
|
|
MBean 属性に基づく [Runtime] 制約は、管理対象 JVM から収集される実行時 JMX 属性に対して評価されます。これらの属性は、直接観察される属性のメトリック値、または 1 つの JVM インスタンス (または JVM インスタンスの集合) のそれらの値に関数を適用して取得されるカスタム メトリックのどちらをベースにすることもできます。
WLOC Administration Console には、名前の付いた一連の制約 (Smart Pack 制約) が用意されています。これらは、名前の付いた MBean 属性に基づいています。これらの制約のいずれか 1 つを選択すると、コンソールによって MBean インスタンス名、種類、および属性名が自動的に指定されます。表 6-5 は、Smart Pack 制約を示しています。
コード リスト 6-5 は、名前の付いた属性の制約を含む XML コードを示しています。metadata-config.xml を直接編集する場合の参考にしてください。
<ns2:instance-name>com.bea:Name=myserver,Type=ServerRuntime</ns2:instance-name>
<ns2:instance-type>weblogic.management.runtime.ServerRuntimeMBean</ns2:instance-type>
<ns2:attribute-name>RestartsTotalCount</ns2:attribute-name>
<ns2:constraint-type>max</ns2:constraint-type>
<ns2:value>10</ns2:value>
制約は、単純な数値比較関数または MBean 属性に適用されるさらに複雑な関数をベースにすることができます。制約関数には、次の構文を使用してメトリックのパラメータを含めることができます。
[<種類>|<インスタンス名>|<属性名>]
Sum([weblogic.management.runtime.ServerRuntimeMBean|.*|RestartsTotalCount],[weblogic.management.runtime.ServerRuntimeMBean|.*|Port])
インスタンス名の指定では正規表現の構文を使用できるため、コンテキスト固有の名前を使用する必要はありません。以降の例では、「.*」がインスタンス名として使用されますが、任意の正規表現を使用することもできます。
Sum — 関数weblogic.management.runtime.ServerRuntimeMBean — インスタンスの種類.* — インスタンス名RestartsTotalCount — 属性名Port — 2 つ目の属性名
メトリックのパラメータにはその他の関数を含めることもできます。次に例を示します。
Sum(Sum([weblogic.management.runtime.ServerRuntimeMBean|.*|RestartsTotalCount],[weblogic.management.runtime.ServerRuntimeMBean|.*|RestartsTotalCount]),[weblogic.management.runtime.ServerRuntimeMBean|.*|RestartsTotalCount])
関数定義のスカラーは定数値です。スカラーを関数で置き換えることはできません。たとえば、次のように指定します。
SumWithScalar([weblogic.management.runtime.ServerRuntimeMBean|.*|RestartsTotalCount],37)
WLOC 提供の関数の詳細なリストについては、『WLOC Administration Console オンライン ヘルプ』の「カスタム メトリックの定義」を参照してください。
コード リスト 6-6 は、MeanofCollection 関数を使用する制約を定義する XML コードを示しています。関数は double を返すので、double-constraint 要素にカプセル化されます。これらの制約の instance-type 要素は常に FUNCTION であり、関数定義自体は attribute-name 要素で指定されます。
instance-name 要素の値は、実際の関数名と一致する必要はありません。
<ns2:double-constraint>
<ns2:name>MyConstraint</ns2:name>
<ns2:key>MyConstraintKey</ns2:key>
<ns2:priority>0</ns2:priority>
<ns2:state>deployed</ns2:state>
<ns2:instance-name>MeanOfCollection</ns2:instance-name>
<ns2:instance-type>FUNCTION</ns2:instance-type>
<ns2:attribute-name>MeanOfCollection([weblogic.management.runtime.
ServerRuntimeMBean|.*|ServerStartupTime])</ns2:attribute-name>
<ns2:constraint-type>max</ns2:constraint-type> <ns2:value>10000</ns2:value>
</ns2:double-constraint>
表 6-6 は、WLOC にあらかじめ用意されているアクションを示しています。これらのアクションを WLOC Administration Console で作成する場合は、必須のパラメータ値の入力を求められます。
| 注意 : | これらのアクションの種類の詳細については、『WLOC Administration Console オンライン ヘルプ』の「アクションの定義」を参照してください。 |
| 注意 : | ほとんどのアクションは、制約にバインドしたりポリシーに追加したりせずに、Administration Console から直接実行することもできます。 |
アクションを組み合わせてアクション パイプラインを作成することができます。これにより、制約違反があった場合に一連のアクションが実行されます。
| 注意 : | パイプラインのいずれかのポイントでアクションが失敗すると、そのパイプラインは終了し、パイプライン内の後続のアクションは実行されません。 |
WebLogic Server 管理サーバ インスタンスの起動、管理対象サーバ インスタンスのクラスタの起動、および電子メール通知の送信に必要なアクションを定義するには、次の手順に従います。
  
|