プロビジョン可能なクラスターでの Liberty Elasticity の構成
Liberty Elasticity をサポートするように集合を構成することができます。 Liberty Elasticity により、スケーリング・コントローラーが Liberty ソフトウェアを登録ホストにインストールして、新しいサーバーを作成することができます。 また、Liberty Elasticity のサポートには、JVM Elasticity のサポートが含まれるため、 リソースの使用量やオプションのスケーリング・ポリシーに基づいて、スケーリング・コントローラーが Liberty サーバーを始動したり停止したりすることが可能です。 使用可能なサーバーの数が、アプリケーションの需要が高いと増大し、低いと減少します。
始める前に
Liberty ソフトウェアをインストールするターゲット・ホストと、インストールする Liberty ソフトウェアを決定します。最小限、 スケーリング・コントローラーによってターゲット・ホストに以下のインストール可能ファイルおよびパッケージ・ファイルがインストールされるようにします。
- 1 つのアプリケーションのある 1 つのスタンドアロン Liberty サーバーを提供するパッケージ。ステップ 5c に、このパッケージの作成方法が説明されています。
- wlp ディレクトリーを含むが usr ディレクトリーを含まない 1 つの Liberty サーバーを提供するインストール可能ファイル。ステップ 5a に、この Liberty ランタイム・アーカイブ・インストール可能ファイルの作成方法が説明されています。
各ターゲット・ホストには、RXA または SSH と、Liberty サーバーの最小要件を満たす Java Runtime Environment (JRE) がインストールされている必要があります。『Liberty 集合操作用 RXA のセットアップ』および『Liberty 集合メンバーおよび集合コントローラー用の JAVA_HOME 変数の設定』を参照してください。
ターゲット・ホストで、ホストの JAVA_HOME 変数とシステムの PATH 変数で JRE へのパスが指定されて JRE がインストールされているという状態になっていない場合、スケーリング・コントローラーがターゲット・ホストに JRE をインストールできます。Step 5b に、インストール可能ファイルである JRE アーカイブの作成方法が説明されています。
ご覧ください: 「Configuring an auto-scalable cluster for Liberty elasticity」ビデオには、プロビジョン可能なクラスターの構成方法が示されています。[トランスクリプト]
手順
- Java 仮想マシン (JVM) Elasticity をサポートするように集合を構成します。この集合には少なくとも 1 つの動的クラスター・メンバーが含まれるようにしてください。
スケーリング・コントローラーでの動的クラスター・メンバーの構成の詳細については、 JVM 弾力性のための自動スケーリング可能クラスターの構成を参照してください。
- 既存の動的クラスター・メンバーのそれぞれが、StackGroupName.PackageName 命名規則に従って名付けられたクラスターに属していることを確認します。
スケーリング・コントローラーがプロビジョンする対象となる既存の動的クラスター・メンバーおよびサーバーは、このクラスターのメンバーです。StackGroupName は、スケーリング・コントローラーがスケーリング・ポリシーに基づいてターゲット・ホストにプロビジョンするインストール可能ファイルおよびパッケージを保持する共有ディレクトリーの名前です。PackageName は、スケーリング・コントローラーがターゲット・ホストにプロビジョンするサーバー・パッケージの名前です。
myStackGroup.cluster1 という名前のクラスターの場合、既存の各動的クラスター・メンバーの server.xml ファイルに次のステートメントを入れます。
<clusterMember name="myStackGroup.cluster1"/>
このトピックのステップ 5c とステップ 7 でこのクラスター名を使用します。ステップ 5c では、 サーバー・パッケージ名に cluster1.zip を使用します。ステップ 7 では、 デプロイされるインストール可能ファイルおよびパッケージ用に myStackGroup ディレクトリーを作成します。
- オプション: スケーリング・コントローラーにスケーリング・ポリシーを追加します。 スケーリング・ポリシーの定義を参照してください。
- 各ターゲット・ホストをスケーリング・コントローラーに登録します。
ホストを登録すると、スケーリング・コントローラーはファイルをそのホストに転送できるほか、 そのホスト上のファイル、コマンド、その他のリソースにアクセスできるようになります。 registerHost コマンドを使用して、ターゲット・ホストを登録します。 スケーリング・コントローラーの server.xml ファイルで、 --host、--port、--user、--password の各パラメーターの値を見つけます。 Linux または Windows オペレーティング・システム上のターゲット・ホストの場合などに、SSH 秘密鍵ファイルを使用しない場合は、 --rpcUser と --rpcUserPassword のパラメーターを設定して、オペレーティング・システム・ログイン・ユーザーとパスワードを含めます。 --rpcUser で指定するユーザーには、ターゲット・デプロイメント・ロケーションへのオペレーティング・システムの権限が必要です。
wlp/bin/collective registerHost targetHost --host=controllerHost --port=controllerHTTPSPort --user=controllerAdmin --password=controllerAdminPassword --rpcUser=osUser --rpcUserPassword=osUserPassword
ターゲット・ホストにファイルを転送する場合、 コマンドに --hostWritePath パラメーターを含める必要はありません。 スタック・プロビジョニング・コードによって書き込みパスが設定されます。 ホストが既に登録されている場合は、updateHost コマンドを使用して登録情報をリセットすることができます。 詳しくは、ホスト・コンピューターの Liberty 集合への登録を参照してください。
ターゲット・ホストがコントローラー・ホストと同じコンピューターにある場合、コントローラー・ホストに対しても updateHost コマンドを実行する必要があります。
- スケーリング・コントローラーが登録ホストにデプロイできるインストール可能ファイルおよびパッケージを作成して構成します。
インストール可能ファイル は、登録ホストにインストールしたいアプリケーションが実行を必要とする、Liberty ランタイムや JRE などのバイナリー・ファイルです。パッケージ は、そのアプリケーションが圧縮ファイルにパッケージされたものです。
- wlp ディレクトリーを含むが、usr ディレクトリーは含まない Liberty ランタイム・アーカイブを作成します。 このインストール可能ファイルの命名規則は、type.name.zip です。例えば、wlp.855.zip などです。
Liberty ランタイム・アーカイブを作成する場合、以下のオプションがあります。
- Liberty サーバーの
package コマンド に --include=wlp オプションを指定して実行します。例えば、以下のようにします。
wlp/bin/server package --include=wlp
ファイル名とターゲット・ロケーションを指定するには、 --archive=archive_path_name オプションを追加します。例えば、次のようにします。
wlp/bin/server package --include=wlp --archive=c:¥temp¥wlp.855.zip
--archive オプションで有効なファイル名またはターゲット・ロケーションを指定しないと、 コマンドは、ランタイム・アーカイブ wlp.zip を ロケーション $WLP_OUTPUT_DIR (デフォルトでは ${wlp.install.dir}/usr/servers ディレクトリー) に作成します。 ターゲット・ロケーションは、コマンドを実行する前に存在している必要があります。 したがって、ターゲット・ロケーションが c:¥temp であれば、C:¥temp ディレクトリーの存在と、C:¥temp ディレクトリーにアーカイブをコマンドで書き込むための書き込み権限が必要です。
- package コマンドに --include=all オプションを指定して実行してから、
usr ディレクトリーを削除します。
package コマンドは、次のようなものになります。
wlp/bin/server package myServer --include=all --archive=myArchive.zip
- wlp ディレクトリーを含み、usr ディレクトリーを含まない圧縮 (.zip) ファイルを作成します。
Liberty ランタイム・アーカイブを作成したら、 アーカイブ名が命名規則 wlp.name.zip に従っていることを確認します。
- Liberty サーバーの
package コマンド に --include=wlp オプションを指定して実行します。例えば、以下のようにします。
- Java Development Kit (JDK) とその他の必要なインストール可能ファイルのアーカイブを作成または入手します。 インストール可能ファイルの命名規則は、type.name.zip です。
例えば、jre.17.zip などです。
インストール可能ファイルの有効なタイプ値は、以下のとおりです。
- wlp: Liberty ランタイムの場合。
- jre: Java ランタイム環境の場合。
- other: 別のファイル・タイプの場合。これはデフォルトです。
例えば、JRE のアーカイブを作成するには、IBM JRE インストール済み環境の java ディレクトリーの内容を含む圧縮 (.zip) ファイルを作成します。java ディレクトリーは含めずに、java ディレクトリー内のすべてのフォルダーおよびファイルを含めます。jre.name.zip 命名規則に従ってアーカイブに名前を付けます。
- Liberty サーバーとアプリケーションをデプロイするには、その Liberty サーバーとアプリケーションを含むサーバー・パッケージ ZIP ファイルを作成します。 サーバー・パッケージの命名規則は package_name.zip です。
例えば、cluster1.zip などです。サーバー・パッケージを作成するオプションには、以下があります。
- package コマンドを以下のように実行します。
このコマンドは、例えば、C:¥wlp¥usr¥servers¥cluster1¥cluster1.zip という名前のサーバー・パッケージを作成します。wlp/bin/server package cluster1 --include=usr
- package コマンドに --include=all オプションを指定して実行してから、
wlp ディレクトリーを削除します。
package コマンドは、次のようなものになります。
wlp/bin/server package cluster1 --include=all --archive=cluster1.zip
- usr ディレクトリーを含み、wlp ディレクトリーを含まない圧縮 (.zip) ファイルを作成します。
例えば、1 つのアプリケーションがある 1 つのスタンドアロン Liberty サーバーからなる、cluster1.zip という名前のサーバー・パッケージを作成するには、 次のようにします。
- サーバーを作成します。
wlp/bin/server create cluster1
- cluster1 サーバーの dropins ディレクトリーにアプリケーションをコピーします。
- サーバーをパッケージします。
wlp/bin/server package cluster1 --include=usr
重要: パッケージ内の server.env ファイル中の環境設定がターゲット・ホストで有効な設定であることを確認してください。JAVA_HOME が設定されている場合、デプロイが失敗するのを防ぐために、ターゲット・ホスト上に存在するロケーションに設定されている必要があります。注: Windows ターゲット・ホストの場合、JAVA_HOME をターゲット・ホスト上の JRE ロケーションに設定する server.env ファイルを作成します。package コマンドを実行した後、 サーバー・パッケージ ZIP 内で server.xml ファイルと同じディレクトリーに server.env を置きます。server.env の内容の例を以下に示します。
JAVA_HOME=C:¥wlp.jre¥jre.17.zip¥jre
- package コマンドを以下のように実行します。
- wlp ディレクトリーを含むが、usr ディレクトリーは含まない Liberty ランタイム・アーカイブを作成します。 このインストール可能ファイルの命名規則は、type.name.zip です。例えば、wlp.855.zip などです。
Liberty ランタイム・アーカイブを作成する場合、以下のオプションがあります。
- スケーリング・コントローラー
の server.xml ファイル内に、集合コントローラーまたはスタック・マネージャー用のユーザー名とパスワードを設定します。
または<collectiveController user="adminUser" password="adminPassword" />
<stackManager controllerUser="adminUser" controllerUserPassword="adminPassword" />
- WLP_STACK_GROUPS_DIR のロケーション (デフォルトでは $WLP_USER_DIR/shared/stackGroups) にインストール可能ファイルとパッケージを置きます。
スケーリング・コントローラーは、ファイル・システム内のインストール可能ファイルとパッケージのデフォルト・ロケーションをモニターし、 更新に動的に対応します。 インストール可能ファイルとパッケージをデフォルト・ロケーションに置いた場合、デフォルト属性を変更する必要はありません。
デフォルトのスタック・グループ defaultStackGroup を使用できます。 あるいは、stackGroups の独自のサブディレクトリー (myStackGroup など) を作成して、それに installables と packages のサブディレクトリーを追加します。
wlp/usr /servers /shared ... /stackGroups /defaultStackGroup /installables /packages /myStackGroup /installables /packages
スケーリング・コントローラーは、インストール可能ファイルとパッケージを登録ホストにデプロイし、新しいサーバーを作成します。
ヒント: 新しいサーバーが作成されるのは、スケーリング・ポリシーが使用可能になっていて、新規サーバーを必要とする場合のみです。新規サーバーを作成するようスケーリング・コントローラーを強制するには、 スケーリング・コントローラーのスケーリング・ポリシーの min 値を調整し、場合によっては max 値も調整します。例えば、 スケーリング・コントローラーにスケーリング・ポリシーがなく、3 つのスケーリング・メンバーからなる集合がある場合、スケーリング・コントローラーの server.xml ファイルに、少なくとも 4 つの実行中メンバーが存在するようにスケーリング・コントローラーを強制するポリシーを追加します。<scalingDefinitions> <defaultScalingPolicy enabled="true" min="4" max="6"/> </scalingDefinitions>
Liberty Elasticity のクラスター命名規則は、StackGroupName.PackageName です。 スタックのデプロイ時に、デプロイされたサーバーの server.xml ファイルに <clusterMember name="StackGroupname.PackageName" が自動的に設定されます。 対応する <scalingPolicy> エレメントには、 <bind clusters="StackGroupName.Packagename"/> ステートメントが含まれます。
表 1. インストール可能ファイルとパッケージのデフォルト・ロケーション. Liberty 環境変数により、デフォルト・インストール・ディレクトリーが設定されます。デフォルト・ロケーションをオーバーライドするには、Liberty 環境のカスタマイズを参照してください。 ファイル デフォルト・インストール・ディレクトリー インストール可能ファイルのタイプ wlp /wlp インストール可能ファイルのタイプ jre /wlp/jre インストール可能ファイルのタイプ other /wlp/other パッケージ /wlp/usr - スタック・グループとインストール可能ファイルの構成属性を調べ、
Liberty プロビジョン実行の時期と場所を定義するために、必要に応じて、スタック・グループとインストール可能ファイルの構成を変更します。
デフォルト構成のオーバーライドが必要な場合があります。
デフォルト構成をオーバーライドするには、スケーリング・コントローラーの server.xml ファイルの stackGroup エレメントと installable エレメントに新しい値を設定します。stackGroup エレメントと installable エレメントについて詳しくは、『スケーリング・コントローラー』を参照してください。
一部のエレメントのデフォルト値のオーバーライドについてのヒント:
- installable エレメントでは、スタック・グループのインストール可能ファイルを定義します。
installable エレメントは、stackGroup エレメントの子エレメントか、
stackGroup エレメントの installableRef 子エレメントで参照される兄弟である可能性があります。
以下の例は、スケーリング・コントローラーの server.xml ファイル内の設定を変更して、スタック・グループの installable 属性のデフォルト値をオーバーライドする方法を示しています。
または<stackGroup name="myStackGroup"> <installable name="wlp.v8555.zip" sourceDir="c:¥myStackGroup¥installables"/> </stackGroup>
<stackGroup name="myStackGroup" installDir="/myInstallDir" installableRef="myInstallable1, myInstallable2"/> <installable name="wlp.v8555.zip" id="myInstallable1" sourceDir="c:¥myStackGroup¥installablesOne" /> <installable name="jre.v1.6.zip" id="myInstallable2" sourceDir="c:¥myStackGroup¥installablesTwo"/>
- 子エレメント deployVariable は、デプロイされたスタックに注入される置換変数を指定します。スタックがデプロイされるたびに置換変数が自動的にインクリメントするように指定できます。
例えば、deployVariable 属性を使用して、初期ポート番号値を指定し、デプロイメントのたびに値をインクリメントします。
この状況における deployVariable の目的は、ターゲット・ホストでのポート競合の回避です。
deployVariable エレメントは、デプロイされたサーバーの
server.xml ファイルに示された計算方法を使用してランタイム・ポート番号を導出します。
例えば、開始ポート番号値とインクリメント量を定義するには、次のようにします。
- パッケージされたサーバーの server.xml ファイルの httpEndpoint エレメントに httpPort="${http.port}" を設定します。
<httpEndpoint ... httpPort="${http.port}" />
- 開始ポート値とインクリメント値を設定する deployVariable 定義を、スケーリング・コントローラーの server.xml ファイルに追加します。
<stackGroup name="DefaultStackGroup" installDir=""> <deployVariable name="http.port" value="9080" increment="1"/> </stackGroup>
以降、スタックがホストにデプロイされるたびに、 httpPort 値は、1 ずつインクリメントします。 このため、スタックが host1 に最初にデプロイされたとき、HTTP エンドポイント・エレメントは以下のようになります。
<httpEndpoint ... httpPort="9080" />
その後、スタックが host1 に次にデプロイされたとき、エレメントは次のようになります。
<httpEndpoint ... httpPort="9081" />
deployVariable 属性に関して、 value のデフォルト値は null です。 increment のデフォルト値は 0 (ゼロ) です。
deployVariable がスケーリング・コントローラーの server.xml ファイルで指定された場合、デプロイされるサーバーのランタイム・ポート番号は、初期ポートの value ストリングに increment の整数を加えたものになります。
- パッケージされたサーバーの server.xml ファイルの httpEndpoint エレメントに httpPort="${http.port}" を設定します。
- スケーリング・コントローラーの server.xml でスタック・グループが以下のように定義されている場合、サーバー・パッケージの作成に使用するサーバー・ディレクトリーの bootstrap.properties ファイル内で httpPort を再定義しないでください。それを行うと、
deployVariable 構成エレメントによって生成される値ではなく、bootstrap.properties 内に定義された httpPort 値が使用されます。
<stackGroup name="DefaultStackGroup" installDir=""> <deployVariable name="http.port" value="9080" increment="1"/> </stackGroup>
- installable エレメントでは、スタック・グループのインストール可能ファイルを定義します。
installable エレメントは、stackGroup エレメントの子エレメントか、
stackGroup エレメントの installableRef 子エレメントで参照される兄弟である可能性があります。
- オプション: スケーリング・コントローラーがファイル・システムでスタック・グループの追加、更新、削除をチェックする間隔を変更します。
スケーリング・コントローラーは stackGroups ディレクトリーおよびそのサブディレクトリーの内容をスキャンして変更がないか確認します。内容に変更があると、前に使用可能なパッケージを保有していなかったクラスターをコントローラーがプロビジョンすることになる場合があります。パッケージの更新は、コントローラーが既存のクラスターを再度プロビジョンする原因にはなりません。
デフォルトでは、コントローラーは、5000 ミリ秒ごと (5 秒ごと) に WLP_STACK_GROUPS_DIR のロケーションをスキャンします。 スキャン間隔を変更する場合、またはスキャンを無効にする場合は、 スケーリング・コントローラーの server.xml ファイルでスタック・マネージャーの scanningInterval 属性と scanningEnable 属性に新しい値を設定します。 例えば、スキャン間隔を 6 秒に設定し、スキャンを有効にする場合は、 以下のようなステートメントをスケーリング・コントローラーの server.xml ファイルに追加します。
<stackManager groupsDir="${wlp.install.dir}/usr/shared/stackGroups/" controllerUser="adminUser" controllerUserPassword="adminPassword" scanningInterval="6000" scanningEnable="true"> </stackManager>
スキャンを無効にするには、scanningEnable を false に設定します。
- オプション: ファイル・システムで新しいスタック・グループの追加、更新、削除があるかスキャンするように、スケーリング・コントローラーに指示します。
スケーリング・コントローラーに WLP_STACK_GROUPS_DIR のロケーションでスタック・グループの追加、更新、削除をチェックさせる StackManager MBean 操作を実行します。 スケーリング・コントローラーの server.xml ファイルに scanningEnable="false" が指定されていても、 StackManager MBean 操作を実行して、追加、更新、削除のスキャンを実行させることができます。
StackManager MBean については、提供されている MBean のリストを参照してください。
- オプション: サーバーへのルーティングを有効にするため IHS を始動します。
IBM HTTP Server (IHS) が動的にプロビジョンされたクラスターにある Web アプリケーションをディスカバーしてルーティングを行えるようにするには、 スケーリング・コントローラーが置かれるホストで動的ルーティングを有効にします。IHS は、 プロビジョンされたサーバーのルーティング情報を動的ルーティング・サービスから取得します。サーバー状況が使用可能にされている場合、 ルーティング情報を表示することができます。
IHS がインストールされていない場合、『Liberty 集合に対する動的ルーティングのセットアップ』を参照してください。また、以下のビデオに、IBM Installation Manager を使用して動的ルーティングのサポートをインストールする方法が示されています。
ご覧ください: 「Enabling IHS for Liberty Dynamic Routing」のビデオには、IHS をインストールし、WebSphere Application Server の Web サーバー・プラグインをインストールし、動的ルーティングのインテリム・フィックスを適用する方法が示されています。[トランスクリプト]

ファイル名: twlp_autoscale_configlibertyelast.html