コンフィグレーション ガイド

     前  次    新しいウィンドウで目次を開く     
ここから内容の開始

サービスとプロセス グループのコンフィグレーション

この節では、WLOC サービスに関するコンフィグレーション タスクについて説明します。この節は、以下の内容で構成されています。

 

概要

WLOC サービスは、WLOC が 1 つの単位として管理する 1 つまたは複数のプロセスの集まりです。サービス内の各プロセスは、Java 仮想マシン (JVM) から起動し、JVM で実行するクラスが含まれているソフトウェア スタックです。同じ機能を実行し、同じ実行時特性を備えたプロセス (JVM プロセス) は、サービス内の「プロセス グループ」にまとめることができます。たとえば、クラスタ内のすべての管理対象サーバは 1 つのプロセス グループにまとめることができます。

サービスのコンフィグレーション情報には、以下の種類の情報が含まれます。

たとえば、以下の項目を指定するサービスを作成できます。

サービス プロセス管理

WLOC が管理する一部の種類のプロセスには、独自の管理ツールが用意されています。たとえば、WebLogic Server には、サーバを作成およびコンフィグレーションし、アプリケーションをデプロイする Administration Console があります。このような外部管理ツールを使用して、WLOC サービスとして実行されるプロセスをコンフィグレーションする場合は、以下の制限事項に注意してください。

たとえば、クラスタ内の 3 つの WebLogic 管理対象サーバで構成されるプロセス グループを持つ WLOC サービスを作成できます。この管理対象サーバのクラスタは、Web サービスの集合をホストします。WebLogic Server ユーティリティを使用して新しい管理対象サーバ (MS4) をクラスタに追加する場合、MS4 はクラスタ メンバーとして機能できますが、サービス コンフィグレーションに MS4 を追加するまで、WLOC では MS4 を管理できません。同様に、WebLogic Server ユーティリティを使用して新しい Web サービスをクラスタにデプロイする場合、ユーザはその Web サービスにアクセス可能であり、Web サービスが追加されたことによるメモリおよびその他のコンピューティング リソースの追加の使用量を WLOC で測定できますが、WLOC サービス コンフィグレーションに 1 つまたは複数のサービス ポリシーを追加するまで、WLOC では新しい Web サービス内の特定のアクティビティをモニタできません。

 

サービスのコンフィグレーション

サービス定義のための主要なツールは WLOC ＵAdministration Console です。このコンソールを使用して定義または変更するサービスはリアルタイムで実行されます。Administration Console を使用してサービスを作成する詳細な手順については、『WLOC Administration Console オンライン ヘルプ』を参照してください。Administration Console の右上隅にある [Help] リンクをクリックすると、このヘルプを表示できます。

コンソールでサービス プロセスを定義する場合は、必要な情報を手動で入力するか、またはコンソールから提供されるいくつかのヘルパー関数を使用して情報をインポートできます。可能な処理は以下のとおりです。

また、メタデータ コンフィグレーション ファイルを直接編集してサービスを定義または変更することもできます。このファイルの場所と名前は次のとおりです。

BEA_HOME\user_projects\controller\config\metadata-config.xml

ファイルに対して直接行った変更は、コントローラが再起動されるまで有効になりません。また、ファイルを手動で変更した場合、コントローラの次回の起動時にそれらの変更がロードされるまで、検証やエラー チェックは行われません。

metadata-config.xml ファイルに関する情報の取得に役立つリソースがあります。このようなリソースは以下のとおりです。

 

プロセス グループのコンフィグレーション

注意 : プロセス グループは、サービスの metadata-config.XML ファイルではプロセス タイプと呼ばれます。

プロセス グループのコンフィグレーション時には、WLOC がそのプロセス グループをインスタンス化するために必要な、以下の項目を含む情報を指定する必要があります。

プロセス グループを定義する場合は、そのプロセスに関する情報の入力をコンソールから求められます。表 5-1 は、プロセス グループの定義に必要な情報を詳しく示しています。

表 5-1 プロセス グループのコンフィグレーション
プロセス グループの属性
説明
[Process Group]
プロセス グループの文字列識別子。
[Number of Processes]
プロセス グループを最初に作成するときに、そのプロセス グループ用にコンフィグレーションされるプロセスの数。
[Name]
初期 JVM インスタンスの名前。インスタンスが追加されるたびに、数値のサフィックスが名前に追加されます。
[Description]
JVM の説明。
[Main Class] または [Main JAR]
このプロセスをインスタンス化するクラスまたは JAR ファイル。
[Host]
JVM があるホストの完全修飾名。
このホストとポート番号は、エージェントが JMX メトリック情報をエンドポイントから収集するために使用するアドレスの決定に使用されます。
[Starting Port #]
JVM があるマシンの開始ポート番号。最初のプロセス インスタンスではこのポート番号を使用します。インスタンスが追加されるたびに、ポートのアドレスが 1 ずつ追加されます。
このホストとポート番号は、エージェントが JMX メトリック情報をエンドポイントから収集するために使用するアドレスの決定に使用されます。詳細については、「テンプレートを使用した複数の Java プロセスの作成」を参照してください。
[JMX Service URL]
WLS ホストとポートを指定する代わりに使用する JMX サービス URL。この URL は、WLS 以外のエンドポイント (MBean サーバなど) への接続に使用されます。
[Classpath]
このプロセスをインスタンス化するクラスまたは JAR ファイルの CLASSPATH。CLASSPATH 情報の取得の詳細については、「クラスパスの指定」を参照してください。
[JVM Arguments]
プロセスをインスタンス化するコマンドで使用する JVM 引数。これらの引数は Java オプションとして渡されます。各 Java 引数を区切るには、スペースを使用します。
詳細については、「プロセスの JVM 引数」を参照してください。
[Java Arguments]
この JVM でアプリケーションを実行するために必要なコマンド ライン引数。これらは Java メイン クラスに引数として渡されます。
[Username and password]
JVM への JMX 接続に必要なセキュリティ資格。これらは、以降に作成されるすべてのプロセスのデフォルト値になります。
[Instance Directory]
プロセス インスタンスが起動される作業ディレクトリ。
[Native Lib Directory]
JVM ネイティブ ライブラリが保存されているディレクトリ。この値は JVM 引数に -Djava.library.path として渡されます。
[Use Native JMX]
JMX 接続のネイティブ JMX MBean サーバを使用するかどうかを指定するフラグ。
[SSH Enabled]
インスタンスに対して SSH を有効にするかどうかを指定するフラグ。
[Protocol]
JMX 接続に使用されるプロトコル (iiop、iiops、http、および https)。
[Ready metric]
WLOC が JVM インスタンスから取得し、プロセスが使用可能かどうかを判断するために使用するメトリックの情報。
詳細については、「プロセスの準備完了メトリック」を参照してください。
[Process Requirements]
必要なプロセスの最小数と最大数。
[Resource Requirements]
必要な CPU とメモリの最小容量と最大容量。詳細については、「リソース要件」を参照してください。
[Software Requirements]
プロセスで必要なソフトウェアの名前とディレクトリの場所。
[Manual Placement Addresses]
プロセスの配置のために推奨される IP アドレス。この値は、WLOC の内部配置アルゴリズムを補足するものです。このアルゴリズムにより、メモリ、CPU 能力、ソフトウェアの可用性、および IP アドレスの制約がある場合に使用する配置場所のセットが検索されます。

 

リソース要件

コンソールを使用してサービスのプロセスを定義する場合、コンソールはサービスのリソース要件に関する情報を要求します。この情報は、サービスの古いデプロイメント ポリシーを構成し、制約およびアクションの形式で保存されます。

リソース要件では、プロセス グループ内の各インスタンスに必要な物理コンピューティング リソースの容量を指定します。たとえば、WebLogic Server ドメインを含むプロセス グループを作成するには、すべての WebLogic Server インスタンスを実行するためのリソース要件を指定します。少なくとも 400 MHz の CPU サイクルと 400 MB の RAM が WebLogic クラスタに必要であり、最大 800 MHz の CPU と 800 MB の RAM に WebLogic クラスタを拡張できるように指定できます。

注意 : CPU 測定の場合、WLOC では正規化されたメガヘルツ (MHz) を複数の CPU アーキテクチャで使用するため、i386 プロセッサにおける処理のメガヘルツは他の種類のプロセッサにおけるメガヘルツと同等です。

これらの要件には、プロセス グループ外のソフトウェアの実行に必要であるが、依存関係として宣言されるリソースは含まれません。たとえば、プロセス グループで RDBMS システムが必要であることを指定する場合、リソース要件には RDBMS のコンピューティング リソースは含まれません。

最小要件と最大要件

リソース要件については、最小要件と最大要件が指定されます。最小要件では、プロセス グループが排他的に使用するために予約する必要のあるリソースの最小容量を指定します。プロセス グループによって使用されるリソースがこの最小要件に達すると、WLOC ポリシーでは、最大要件を上限とした追加のリソースを要求できます。

利用可能なすべてのリソースが他の WLOC リソース プールまたは WLOC 以外のアプリケーションによって使用されている場合、WLOC では実際に追加のリソースを取得することはできません。たとえば、図 5-1 は、2 つの WLOC リソース プールを含むハイパーバイザ リソース プールを示しています。このプールには 600 MB のメモリが用意されていますが、WLOC リソース プールには 2 つのサービスがあり、それぞれの最小容量が 200 MB、最大容量が 400 MB とコンフィグレーションされています。2 つのサービスは必要な最小のメモリ (200 MB) を同時に使用できますが、最大のメモリを同時に使用することはできません。図 5-1 では、サービス 1 が 400 MB を使用しているため、使用済みのメモリの総量は 600 MB です。サービス 1 がメモリの使用量を減らすまで、サービス 2 は追加のメモリを使用できません。

図 5-1 リソースの最小容量と最大容量

リソースの最小容量と最大容量

 

プロセスの準備完了メトリック

WLOC では、プロセスが正常に開始されたタイミングと、プロセスを実行する準備が整ったタイミングを把握しておく必要があります。そのためには、プロセス グループの準備完了メトリックを指定します。インスタンスを起動するアクションを定義する場合、準備完了メトリックを満たすまで、そのアクションは完了したと見なされません。コンフィグレーション可能な期間内に準備完了メトリックを満たさない場合、インスタンスは失敗したと見なされて停止されます。

表 5-2 は、準備完了メトリックの情報を示しています。

表 5-2 準備完了メトリック
準備完了メトリックの属性
説明
[Instance Name]
テストする属性を持つ MBean の名前。例 : com.bea:Name=AdminServer,Type=ServerRuntime
[Attribute]
テストする MBean 属性の名前。例 : state
MBean 属性の指定に使用する形式の詳細については、『WebLogic Server MBean リファレンス』を参照してください。
[Value]
MBean 属性のテストに使用する定数値。このフィールドは、[Operator] が Value Equals に設定されている場合にのみ有効です。例 : RUNNING
[Operator]
演算子 (Value Equals または Value Exists)。
[Value Type]
値の型 (Integer、Long、Float、Double、Boolean、Date、String)。デフォルトは Integer です。
[Wait]
(省略可能) プロセスが準備完了であると見なされる前に準備完了メトリック制約を満たしてから待機するミリ秒数。

表 5-3 では、JVM インスタンスが RUNNING 状態であることを報告する準備完了メトリックを指定します。

表 5-3 WebLogic Server インスタンスの準備完了メトリック コンフィグレーション
準備完了メトリックの属性
値
[Ready metric instance]
Name=com.bea:AdminServer,Type=ServerRuntime
[Attribute]
State
[Value]
RUNNING
[Operator]
ValueEquals
[Value Type]
String
[Wait]
30000

コード リスト 5-1 は、metadata-config.xml におけるこの準備完了メトリックを示しています。

コード リスト 5-1 WebLogic Server インスタンスの準備完了メトリック コンフィグレーション 
<ns2:ready-information>
  <ns2:check-type>ValueEquals</ns2:check-type>
  <ns2:max-wait-period>300000</ns2:max-wait-period>
  <ns2:instance>com.bea:Name=AdminServer,Type=ServerRuntime</ns2:instance>
  <ns2:attribute>State</ns2:attribute>
  <ns2:value>RUNNING</ns2:value>
  <ns2:value-type>java.lang.String</ns2:value-type>
</ns2:ready-information>

 

プロセスの JVM 引数

処理やチューニングを適切に行うために、通常、管理対象アプリケーションは特定の JVM 引数で起動する必要があります。プロセスの開始時に使用する JVM 引数は、プロセス グループごとに指定できます。WLOC Administration Console では、インスタンスの定義時に、[Process Properties] ページで JVM 引数を指定します。

注意 : JVM 引数は、JVM インスタンスがステージングされる場合に設定されます。JVM インスタンスがステージングされた後に JVM 引数を更新する場合は、JVM が破棄されて再度ステージングされない限り、設定がコンフィグレーションから更新されることはありません。新しい設定を使用するには、サービスをステージング解除して再起動する必要があります。

JVM インスタンスをコンフィグレーションする場合は、実行中のインスタンスから管理情報を取得する方法をエージェントに通知するための接続情報を指定する必要があります。詳細については、「JMX ポートの設定」を参照してください。また、エージェントが接続する必要のあるポートを開くように JVM インスタンス自体をコンフィグレーションする必要があります。

通常、JVM インスタンスのネイティブ コンフィグレーションでは、そのインスタンスが管理情報を公開する方法を指定します。ただし、インスタンスのコマンド ライン引数の指定が必要な場合もあります。たとえば、WebLogic Server では、リスン ポートを WebLogic ドメインの config.xml に定義するか、またはコマンド ラインでリスン ポートをオーバーライドすることができます。WebLogic 以外のエンドポイントの場合は、コマンド ライン引数を設定することにより、JDK プラットフォーム MBeanServer へのリモート アクセスを有効にすることができます。

注意 : WLOC Plain Agent では、JDK プラットフォーム MBean を使用して、サービスの現在の CPU とメモリの使用量を取得します。Plain Agent の場合は、公開されているポートからプラットフォーム MBean を使用できるようにする必要があります。

通信プロトコルの設定

管理対象エンドポイントのすべての管理情報は JMX MBean を通じて取得されますが、その情報を渡すときに使用する通信プロトコルは、VM で実行するアプリケーションによって異なります。いくつかの例を以下に示します。

WebLogic

エンドポイントが WLS の場合、WebLogic Server は一般的なリスン ポート (デフォルトの 7001) で JMX を公開します。WLS MBean だけでなく、WLS MBeanServer も JDK プラットフォーム MBean を公開します。

Coherence

エンドポイントが Coherence の場合は、-Dtangosol.coherence で始まるコマンド ライン プロパティを設定することにより、Coherence MBean をエクスポーズするためのポートがコンフィグレーションされます。Coherence のベスト プラクティスは、JMX データを公開するクラスタ内に少数のインスタンスを設定することです。これらのインスタンスは、すべてのクラスタ メンバーに関する情報を集約します。上述したように、Plain Agent では、JDK プラットフォーム MBean を使用して、CPU とメモリの統計を取得します。そのため、この設定によって、各インスタンスのデフォルトの CPU とメモリの統計を WLOC Administration Console の特定のチャートで取得することはできません。Coherence からの MBean のエクスポーズの詳細については、Coherence のドキュメントを参照してください。

汎用的なアプリケーション

アプリケーションが WebLogic または Coherence でない場合は、JVM 自体によって開かれるポート経由で、プラットフォーム MBeanServer から管理情報を公開できます。このコンフィグレーションのためには、-Dcom.sun.management で始まるコマンド ライン プロパティを設定します。

上記の 3 つのすべての例では JMX データを提供していますが、基底のプロトコルはすべて異なります。また、JMX クライアント (この場合はエージェント) では、データを読み込む方法を把握しておく必要があります。JMX は、回線上での JMX 情報の転送およびシリアル化における柔軟性を大幅に向上します。WLS では、http、https、t3、t3s などのさまざまなプロトコルを使用できます。

プロトコル、ホスト、およびポートだけを設定すると、WLOC エージェントは WebLogic エンドポイントと対話すると見なされ、WebLogic RMI を使用して指定のプロトコル経由でデータを転送します。

エンドポイントが WLS でない場合は、metadata-config.xml ファイルで、native-jmx を true に設定する必要があります。WLOC Administration Console では、インスタンスの定義時に、[Process Properties] ページの [Use Native JMX] チェック ボックスを選択します。このように設定すると、WLOC エージェントは標準の JMX プロトコルを使用します。

Coherence では、2 つのポートを使用して JMX を公開します。1 つは JMX トラフィック自体のためのポートで、もう 1 つは JMX のルックアップに必要な JNDI 情報用のポートです。このエンドポイントに接続する場合、プロトコル、ホスト、およびポートの基本設定では不十分であるため、Coherence MBeanServer と対話するときは、metadata-config.xml ファイルで jmx-service-url を指定する必要があります。WLOC Administration Console では、インスタンスの定義時に、[Process Properties] ページでこの値を指定します。jmx-service-url が指定されている場合、プロトコル、ホスト、およびポートの設定は無視されます。

コード リスト 5-2 は、WLS 管理サーバの起動に使用される JVM 引数を示しています。

コード リスト 5-2 JVM 引数の例 
-Xmanagement -Dcom.sun.management.jmxremote.port=7091
-Xmx128m
-Xms64m
-Dweblogic.Name=examplesServer
-Dweblogic.management.username=weblogic
-Dweblogic.management.password={Salted-3DES}L9NHXoCmDmOXAobBz2ennw==</
-Djava.security.policy=C:/files/bea/weblogic92/server/lib/weblogic.policy
-Dwls.home=C:/files/bea/weblogic92/server
-Dweblogic.RootDirectory=C:\files\bea\weblogic92\samples\domains\wl_server

コード リスト 5-3 は、metadata-config.xml における JVM 引数の例を示しています。

コード リスト 5-3 WLS インスタンスの metadata-config.xml における JVM 引数 
<ns2:jvm-args>
	<ns2:arg>-Xmx128m</ns2:arg>
	<ns2:arg>-Xms64m</ns2:arg>
	<ns2:arg>-da</ns2:arg>
	<ns2:arg>-cp</ns2:arg>	
	<ns2:arg>CLASSPATH=C:\bea\patch_weblogic921\profiles\default\
	sys_manifest_classpath\weblogic_patch.jar;C:\bea\WEBLOG~1\server\
	lib\weblogic_sp.jar;C:\bea\WEBLOG~1\server\lib\weblogic.jar;C:\bea\
	WEBLOG~1\server\lib\webservices.jar;</ns2:arg>
	<ns2:arg>-Dwls.home=C:\bea\weblogic92\server</ns2:arg>
	<ns2:arg>-Dweblogic.management.discover=true</ns2:arg>
	<ns2:arg>-Dweblogic.Name=AdminServer</ns2:arg>
	<ns2:arg>-Dweblogic.management.username=weblogic</ns2:arg>
	<ns2:arg>-Dweblogic.management.password=weblogic</ns2:arg>
	<ns2:arg>-Djava.security.policy=C:\bea\weblogic92\server\lib\
	weblogic.policy</ns2:arg>
	<ns2:arg>-Dweblogic.RootDirectory=C:\bea\user_projects\domains\
	WLOCdomain</ns2:arg>
</ns2:jvm-args>

WebLogic Server インスタンスの起動時に使用する JVM 引数の詳細については、『weblogic.Server コマンドライン リファレンス』を参照してください。

JMX ポートの設定

Administration Console の [Starting Port #] フィールドまたは metadata-config.xml ファイルの <jvm-instance> 定義の <port> フィールドを使用して、管理対象エンドポイントの JMX ポートを設定します。このホストとポート番号は、エージェントが JMX メトリック情報をエンドポイントから収集するために使用するアドレスの決定に使用されます。

JMX ポート設定には以下のルールが適用されます。

クラスパスの指定

必須の JVM 引数の 1 つとして、JVM インスタンスの起動に必要なクラスパスがあります。この節では、さまざまな環境でクラスパスを取得する方法について説明します。

Plain Agent 上の JVM

LiquidVM

クラスパス要素の提供元としては、LiquidVM ファイル システムの任意の場所を指定できます。この要素が ISO イメージ内にある場合、ISO は /appliance にマウントされるため、パスの先頭を /appliance にする必要があります。この要素が NFS 共有内にある場合は、パスの先頭を NFS マウント ポイントにする必要があります。この要素がローカル ディスク内にある場合は、パスの先頭を / (スラッシュ) にする必要があります。

WLS-VE 9.2v1.1 の場合、commonStartVE スクリプトによって設定される標準のクラスパスは次のとおりです。 

/bea/patch_weblogic922/profiles/default/sys_manifest_classpath/weblogic_patch.jar:
/appliance/java/lib/tools.jar:/appliance/bea/weblogic92/server/lib/weblogic.jar:
/appliance/bea/weblogic92/server/lib/webservices.jar:

 

テンプレートを使用した複数の Java プロセスの作成

サービス内の Java プロセスの複数のコピーを作成するタスクを簡略化するために、WLOC には、プロセスの共通の特性をテンプレートで定義し、変数を使用して共通のパラメータを置き換える機能が用意されています。このテンプレートを使用すると、メタデータ コンフィグレーションで物理的に重複をコンフィグレーションする必要なくプロセスの複数のコピーを生成できます。テンプレートを作成する場合は、以下の定義を行います。

注意 : 変数に指定する値の数は、作成されるコピーの数と同じである必要があります。

共通の JVM パラメータの定義

Java プロセス テンプレートの共通のパラメータは、個々のプロセス インスタンスを定義する場合と同じ方法で定義します。定義する変数の名前がわかっている場合は、テンプレートのコンフィグレーション時に、引数の一部として変数を指定できます。それ以外の場合は、変数が作成された後でテンプレート定義を更新する必要があります。詳細については、以下のトピックを参照してください。

プロセス数の指定

変数の定義だけでなく、次のように max-copies 要素を使用して、作成するインスタンスのコピー数を指定することもできます。 

<ns2:max-copies>5</ns2:max-copies>

デフォルトは 1 です。

注意 : Administration Console では、[Process Group Template Properties] ページの [Max Copies] フィールドを使用してコピー数を指定します。

たとえば、max-copies 要素の値として 5 を指定すると、WLOC は 5 つの JavaInstanceMetaData インスタンスに定義を展開します。

max-copies が 1 より大きい場合、各 Java インスタンスの名前にはダッシュとコピー数 (0、1、2 など) が追加されます。たとえば、managed-0、managed-1 のようになります。

変数の定義

変数の定義を利用する場合は、jvm-instance 定義の特定の属性に変数の参照を挿入できます。変数を指定できる属性は以下のとおりです。

準備完了メトリック定義のインスタンスと値の属性に変数を定義することもできます。

サポートされている変数はスカラーと配列です。スカラー変数を使用する場合は、その値によって属性内の参照が置き換えられます。配列変数を使用する場合は、属性内の参照の置き換えに使用する一連の値を指定できます。

たとえば、次に示すように、インスタンスごとに異なるポート値を定義するために使用できる ManagedPort という変数を作成できます。

<ns2:port>${ManagedPort}</ns2:port>

スカラー変数を使用するには、参照の代わりとして使用する値を指定するだけで済みます。たとえば、メタデータ ファイル内のスカラー変数は次のようになります。 

<ns2:variable>
   <ns2:name>ManagedPort</ns2:name>
   <ns2:value>7010</ns2:value>
</ns2:variable>

配列変数は以下のように指定できます。

値のリストまたは範囲を使用する配列は、メタデータ ファイル内では次のようになります。 

<ns2:variable>
   <ns2:name>ManagedPort</ns2:name>
   <ns2:values>
      <ns2:value>7010</ns2:value>
      <ns2:value>7011</ns2:value>
      <ns2:value>7012</ns2:value>
      <ns2:value>7013</ns2:value>
   </ns2:values>
</ns2:variable>

この例では、最初のコピーにポート番号 7010、2 つ目のコピーに 7011 (以下も同様) が割り当てられます。

宣言内のいずれかの場所に配列インデックスを挿入するために使用できる暗黙的な変数 ${index} があります。次に例を示します。

<ns2:arg>-Dweblogic.Name=managed-${index}</ns2:arg>

Administration Console で変数を作成する手順については、『WLOC Administration Console オンライン ヘルプ』の「複数の Java プロセスの変数の定義」を参照してください。

変数を使用するサンプル テンプレート

コード リスト 5-4 は、変数を使用するサンプル JVM テンプレートを示しています。このテンプレートでは、インスタンスの 5 つのコピーを作成する必要があることを指定し、名前、ホスト、およびポートの各フィールドに変数を使用します。変数と変数の参照は太字で示します。

コード リスト 5-4 変数を使用するサンプル JVM テンプレート 
<ns2:jvm-instance>
	<ns2:name>MyServerInstance</ns2:name>
	<ns2:description>This JVM instance defines a template to stamp out five instances of MyServer</ns2:description>
	<ns2:max-copies>5</ns2:max-copies>
	<ns2:variables>
		<ns2:variable>
			<ns2:name>serverName</ns2:name>
			<ns2:values>
				<ns2:value>server-A</ns2:value>
				<ns2:value>server-B</ns2:value>
				<ns2:value>server-C</ns2:value>
				<ns2:value>server-D</ns2:value>
				<ns2:value>server-E</ns2:value>
			</ns2:values>
		</ns2:variable>
		<ns2:variable>
			<ns2:name>host</ns2:name>
			<ns2:values>
				<ns2:value>123.12.123.100</ns2:value>
				<ns2:value>123.12.123.107</ns2:value>
				<ns2:value>123.12.123.104</ns2:value>
				<ns2:value>123.12.123.109</ns2:value>
				<ns2:value>123.12.123.111</ns2:value>
			</ns2:values>
		</ns2:variable>
		<ns2:variable>
			<ns2:name>port</ns2:name>
			<ns2:value>@range{8000,8005}</ns2:value>
		</ns2:variable>
	</ns2:variables>
	<ns2:main-class>com.mycompany.MyServer</ns2:main-class>
	<ns2:jvm-args>
		<ns2:arg>-Xms64m</ns2:arg>
		<ns2:arg>-Xmx128m</ns2:arg>
		<ns2:arg>-cp</ns2:arg>
		<ns2:arg></ns2:arg>
		<ns2:arg>-Dcom.mycompany.servername=${serverName}</ns2:arg>
		<ns2:arg>-Dcom.mycompany.maxthreads=8</ns2:arg>
		<ns2:arg>-Dcom.mycompany.minthreads=3</ns2:arg>
	</ns2:jvm-args>
	<ns2:java-args/>
	<ns2:native-lib-dir></ns2:native-lib-dir>
	<ns2:instance-dir></ns2:instance-dir>
	<ns2:native-jmx>false</ns2:native-jmx>
	<ns2:protocol>http</ns2:protocol>
	<ns2:host>${host}</ns2:host>
	<ns2:port>${port}</ns2:port>
	<ns2:username></ns2:username>
	<ns2:ssh-enabled>false</ns2:ssh-enabled>
	<ns2:wait-for-ssh>false</ns2:wait-for-ssh>
	<ns2:priority>0</ns2:priority>
	<ns2:copies-at-create/>
	<ns2:copies-at-shutdown/>
</ns2:jvm-instance>

 

サービス デプロイメント プロセス

WLOC サービスを開始するには、WLOC Administration Console を使用してサービスをデプロイします。サービスを開始する前に、そのサービスの状態はアンデプロイされます。これは、実行中のインスタンスが存在しないことを示します。サービスを開始すると、コントローラは以下の手順を実行します。

  1. サービス内の各プロセス グループのプロセス要件を評価します。
  2. サービス内の各プロセス グループで使用可能なリソース プールを、リソース アグリーメントに照らして比較し、サービスをホストできないリソース プールを削除します。たとえば、次の処理を行います。
    • サービスに高可用性が必要な場合、高可用性をサポートしないリソース プールは候補から削除されます。
    • サービスに特定の IP アドレスが必要な場合、その IP アドレスを含まないリソース プールは候補から削除されます。
    • サービスでソフトウェア要件 (iso-constraint および software-constraint) を指定する場合、必要なすべてのソフトウェアへのアクセスを提供しないリソース プールは候補から削除されます。
    • サービスが 1 つのプロセスで構成される場合、提供するコンピューティング リソースがサービスの最小リソース要件よりも少ないリソース プールは削除されます。

      • たとえば、あるリソース プールが 150MHz の CPU サイクルを提供し、サービスには 1 つのプロセスが含まれていて、必要な CPU サイクルが少なくとも 200MHz (および最大 400MHz) である場合、このリソース プールは候補から削除されます。ただし、200MHz の CPU サイクルを提供するリソース プールの場合は、デプロイメントのための候補と見なされます。

    • サービスが複数のプロセスで構成される場合、WLOC は複数のリソース プールをサービスの実行用として選択できます。
  3. 削除のプロセスが完了すると、コントローラでは、サービスの定義時に指定された以下の配置アルゴリズムを使用して、サービスの配置先のリソース プールを決定します。
    • [Prefer resource pools with the most resources] : WLOC は、最大容量のコンピューティング リソースを提供するリソース プールの組み合わせを選択します。
    • [Prefer resource pools with fewer resources] : WLOC は、サービスの最小リソース要件に最も近いリソース プールを選択します。このアルゴリズムによって、データ センタで最も効率的にリソースが使用されます。
      • 注意 : Plain インスタンスには適用されない iso-constraint を除き、Plain インスタンスと ESX インスタンスの配置条件は同じです。
  4. 各インスタンスを個別にステージングします。
  5. 各インスタンスを個別に起動します。各グループの最小数のプロセスが開始されると、サービスがデプロイされます。
  6. 実行時ポリシーを評価し、制約違反があった場合は、指定されたアクションを開始します。
  7. 管理対象アプリケーションから取得する情報を使用して、実行時ポリシーを継続的に評価します。

  ページの先頭       前  次