websphere extended deployment v6.1...

WebSphere Extended Deployment V6.1 構成ガイド

140/382

第４章既存Non-XD環境の統合

1 この章の目的この章では、XD が提供する non-WebSphere サポート機能を活用する方法についてご紹介します。こ

れは既存環境を仮想化・可視化したい場合に、既に ND で構成されている環境を XD 環境に切り替え

るのではなく、追加で WebSphere XD の Operation Optimization 機能の一部を導入する事で、既存

WAS サーバーに変更を加えることなく XD 機能を享受するものです。既存の WAS サーバーを

Non-WebSphere サーバーとして XD 環境に統合することで、インフラの標準化、運用・監視の統合化、

簡素化を実現することが出来ます。なお、本章は、前提として前の第 2 章、第 3 章までの構成が完了していることが前提となります。 2 MA による既存 Non-XD 環境のサポートについて 2-1 ミドルウェア･エージェントについて WebSphere XD V6.1 より、WebLogic や Tomcat などの他ベンダーの Web アプリケーション･サーバ

ー（Non-WebSphere プラットフォーム）のサポートが強化されています。3 章で見た様に、XD の

Operations Optimization 環境ではオンデマンド・ルーターが割り振りを行いますが、割り振り先の

バックエンド･サーバーは WAS XD V6.1 だけに限定せずに XD 機能を適用できます。このNon-WebSphereサポートの仕組みを実現する重要なコンポーネントがミドルウェア･エージェン

ト（MA）です。WAS 環境では各ノードの管理を行う NodeAgent がありますが、Non-WebSphere 環

境での NodeAgent にあたるものが、ミドルウェア･エージェントということになります。このミドル

ウェア･エージェントによって、Non-WebSphere ミドルウェアの管理とモニターが可能となっていま

す。ミドルウェア･エージェントは、Non-WebSphere ノード上にも配置できますし、WAS サーバーの入っ

たノードにも配置可能です。ミドルウェア･エージェントは、基本的には Non-WebSphere ミドルウェ

ア・サーバーを管理の対象としていますが、WAS V5.1 や V6.0 といった古いバージョンの WAS サー

バーについても管理の対象とすることが可能です。この場合、ミドルウェア･エージェントは WASサーバーをWASではなく、ホスト名とポートのみを認識したカスタムHTTPサーバーとみなします。

DMgr

NodeAgent

MiddlewareAgent

Non-WASmiddlewareWASサーバー

ノード

サーバー

セル

Non-WebSphereWebSphere


141/382

2-2 本環境で実現される機能通常の WAS ND 環境で提供される機能に加えて、本構成で可能になる追加機能には、以下のようなも

のがあります。

リソースモニタリング保守モードのサポート管理コンソールからの Non-WebSphere サーバーの起動･停止オンデマンド・ルーターによる動的ワークロード管理（流量制御）監視モードプロビジョニング（JVM 数調整）ヘルス･モニタリング

本ガイドでは、これらのうち、以下の項目を構成するための手順を紹介します。

リソース･モニタリングヘルス･モニタリング

3 この章で取り扱う環境構成と構成手順の概略まず、本章のはじめのベースの構成として、以下のように、既存 ND 環境が XD セルとはまったく独

立した別セルとして構成されています。


142/382

そこへ、以下の構成手順を実施して、下図のような構成を構築します。

1. ベース構成へ CIM にて MA 導入

2. カスタム HTTP サーバーの定義

3. 動的クラスターの作成

4. 既存 ND アプリケーション定義の作成

その後に、以下の機能の稼動確認を行います。

オンデマンド・ルーター経由での割り振り確認

リソース･モニタリングの確認

ヘルス･モニタリングの確認


143/382

4 既存 Non-XD 環境の統合の手順 4-1 事前準備 (1) 管理コンソールへのアクセス FireFoxもしくは Internet ExplorerなどのWebブラウザーを使用して以下のURLへアクセスしてく

ださい。 http://ise036:9060/ibm/console

(2) セキュリティーの警告の表示管理セキュリティーが有効であるため、https（9043 ポート）でリダイレクトされ、以下のようにセ

キュリティー警告が表示されますが、問題ありませんので「はい」を選択して継続してください。


144/382

(3) 管理コンソールへログインログイン画面が表示されますので、以下のユーザーID/パスワードにてログインしてください。

ユーザーID： wasadmin

パスワード： wasadmin


145/382

4-2 ベース構成へ CIM にて MA 導入 (1) インストール･ターゲットの登録まずは、XD の DM から、管理対象となる既存のサーバーへ、ミドルウェア･エージェントを導入しま

す。導入に先立ち、導入先のサーバーの情報を、「インストール･ターゲット」として登録しておく必

要があります。ここでは、この「インストール･ターゲット」の登録方法について記述しています。管理コンソールのメニューから、「システム管理」⇒「集中インストール･マネージャー」⇒「インス

トール･ターゲット」を選択します。


146/382

「インストール･ターゲットの追加」をクリックします。以下のような画面が表示されますので、必要事項を入力･選択します。ここでは、ターゲット･ホストを「ise039」として以下の情報を入力しています。ホスト名：ise039 ユーザー名：root パスワード：＜OS の root ユーザー･パスワード＞プラットフォーム･タイプ：Linux

その後、「適用」をクリックし、「保管」します。正常に追加されると、インストール･ターゲットの一覧で以下のように表示されるようになります。


147/382

(2) ミドルウェア･エージェントのインストールインストール･ターゲットの登録が終了したら、次のステップはミドルウェア･エージェントの導入に

なります。管理コンソールのメニューから、「システム管理」⇒「集中インストール･マネージャー」⇒「使用可

能なインストール」を選択します。


148/382

次の様な画面が表示されますので、それぞれの項目で以下を選択し、「インストール･ターゲットの表

示」をクリックします。

パッケージ･タイプの選択：製品インストール

インストール･パッケージの選択：WebSphere Extended Deploymet ミドルウェア･エージ

ェント for non WebSphere servers – 6.1


149/382

「インストール･ターゲット」欄に、先ほどインストール･ターゲットとして追加した「ise039」が表

示されるようになっています。これをチェックして、「インストール」をクリックします。


150/382

インストールが開始され、ウィザードに切り替わります。ステップ 1 では、「ソフトウェアのご使用条件」への同意確認を行います。「使用条件の条項に同意します。」にチェックし、「次へ」をクリックします。

ステップ 2 では、「インストール･ターゲット」の認証の方式を指定します。基本的に全てインストール･ターゲットとの通信は ssh を使用して行われますが、ユーザー名/パスワ

ードで認証を行うのか、それともあらかじめ DM に登録しておいたキーを使用して認証するのかを指

定します。ここでは、ユーザー名/パスワードを使用して認証することにします。「ユーザー名とパスワードを使用します。」にチェックし、「次へ」をクリックします。


151/382

ステップ 3 では、ユーザー名/パスワードを指定する際に、全サーバー共通で使用するユーザー名/パス

ワードを指定するのか、それぞれのインストール･ターゲットに固有のユーザー名/パスワードを使用

するのか、を指定します。ここでは、「ise039」サーバーに固有のユーザー名/パスワードを使用するこ

ととして、「各インストール･ターゲットごとに固有のユーザー名とパスワードを指定します。」にチェ

ックし、「ユーザー名」に「root」、「パスワード」に root のパスワードを入力し、「次へ」をクリック

します。

ステップ 4 では、ミドルウェア･エージェントのインストール先パスと、インストール・イメージをテ

ンポラリで展開するパスを指定します。ここでは、デフォルトをそのまま受け入れることとし、「次へ」

をクリックします。


152/382

ステップ 5 では、現行で使用している DM の管理者特権を保持しているユーザー/パスワードを指定し

ます。CIM を使用したミドルウェア･エージェントの導入は、インストール･ファイルの転送、インス

トール、エージェントの DM への登録、の 3 つのステップで行われますが、ここで指定した値は、エ

ージェントを DM に登録する際に使用されます。ユーザー名/パスワードを入力し、「次へ」をクリックします。

ステップ 6 では、ミドルウェア･エージェントの導入に必要な OS の前提条件をチェックするか、否か

を指定します。基本的には OS は前提条件を満たしている必要がありますので、チェックせずに「次

へ」をクリックします。

注) 本章執筆時点では、RedHad Linux の前提確認処理に不備があり、前提条件以上の

レベルの場合でもチェックに失敗してしまうという現象が発生しています。例えば、

RedHatLinux の前提は、V4 の Update2 以上となっていますが、上位の Update 4 を指

定した場合にチェックに失敗してしまいます。この場合は、Fix が提供されるまでの間

チェックボックスをチェックし、前提条件チェックを無効にしてください。


153/382

ステップ 7 では、ウィザードで指定した各パラメーターの確認を行います。確認後、「終了」をクリッ

クします。


154/382

終了をクリックすると、以下の様なメッセージが表示され、インストール･ターゲット一覧の「ise039」が（使用中）としてマークされ、グレーアウトされます。これで、インストール処理のサブミットが

終了したことになります。


155/382

ここからは、登録したインストール処理がどのように進行しているか確認してみましょう。メニュー

から、「システム管理」⇒「集中インストール･マネージャー」⇒「進行中のインストール」と選択し

ます。

以下のような画面が表示されます。インストールの進行と共に、「状況」欄が更新されます。状況の右

隣にあるリフレッシュボタンを押しながら、進行状況を確認します。正常にインストールが進んだ場合、下図にあるように、「ファイル転送中」⇒「進行中のインストール」

⇒「ポストインストール･コマンド実行中」とステータスが更新されます。


156/382

成功であれ、失敗であれ、インストールが終了すると、「進行中のインストール」画面からエントリが

無くなります。

CIM による MA インストールの結果確認は、以下の方法で行います。管理コンソールのメニューから「システム管理」⇒「集中インストール･マネージャー」⇒「インスト

ール･ヒストリー」を選択します。

以下の様な画面が表示されます。ヒストリーの一覧の完了状況に、結果が表示されています。


157/382

4-3 既存 WAS サーバーをカスタム HTTP サーバーとして定義 4-2 で既存 WAS ND 環境（ise039 サーバー）へのミドルウェア･エージェントの導入が完了しました

ので、次のステップとして、ise039 サーバー上にすでに存在するアプリケーション･サーバー（server1）を XD のセルに登録する作業を行います。ここでは、定義情報を追加するのみであるので、実際のサ

ーバー作成は行われません。 (1) サーバーの追加メニューから、「サーバー」⇒「サーバーの追加」を選択します。

ウィザードが開きます。ステップ 1 では、追加するサーバーのタイプを指定します。新しくサーバーを作成するのか、既存の

サーバーを追加するのかを選択します。今回は、「既存のサーバーの追加」を選択し、追加するサーバ

ーのタイプとして、「カスタム HTTP サーバー」を選択します。その後、「次へ」をクリックします。


158/382

ステップ 2 では、追加するサーバー定義の情報を指定します。ノードに「ise039」を、サーバー名に「server1」を指定して「次へ」をクリックします。

ステップ 3 では、追加するサーバーのテンプレートを選択します。今回は「customHTTP」しかあり

ませんので、そのまま「次へ」をクリックします。

ステップ 4 では、指定したパラメーターの確認を行います。確認後、「終了」をクリックします。


159/382

新しくサーバー定義が作成され、下図の様にリストに項目が追加されます。

(2) コネクター･ポートの指定次に、作成したサーバーの設定を行います。まずは、このサーバーが受け付けるポートの指定を行い

ます。(1)で作成した「server1」のエントリをクリックします。下図のような画面が表示されますので、

このサーバーがサービスを提供するポートを HTTP、SSL のそれぞれで指定します。ここでは、HTTPコネクターポートとして、9080 を、HTTPS コネクターポートとして 9443 を指定し、それぞれのポ

ートに対し「このコネクターは有効」をチェックします。

「適用」をクリックすると下図のようなメッセージが表示されますので、「保管」します。


160/382

(3) サーバー操作の定義次に、定義を追加したサーバーの起動･停止を行う際に必要な情報の定義を行います。この設定を行う

ことで、XD セルの中で Non-WebSphere サーバー（今回は便宜的に ND のサーバー）の操作を行う

ことが出来るようになります。 (2)で設定した server1 のプロパティー画面で、「サーバー操作」をクリックします。

① 起動の設定以下の様な画面が表示されます。まずは起動の設定を行います。「start」をクリックします。


161/382

以下のような画面が表示されます。以下の様に各パラメーターを指定します。実行可能ファイル：startServer.sh 実行可能の引数：${WAS_SERVER_NAME} 作業ディレクトリー：/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/bin サポートされる OS ：UNIX PID ファイル名を保管する環境変数の名前：PID_FILE

指定後、「適用」をクリックし、「保管」します。

/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/bin


162/382

② 停止の設定

次に、停止の設定を行います。「stop」をクリックします。

次ページの様な画面が表示されます。以下の様に各パラメーターを指定します。実行可能ファイル：stopServer.sh 実行可能の引数：${WAS_SERVER_NAME}

-username ${username} -password ${password}

実行可能の引数にあるユーザー名を参照する変数の名前：username 起動時にユーザー名変数を置換するユーザー名：wasadmin 実行可能の変数にあるパスワードを参照する変数の名前：password 起動時にパスワード変数を置換するパスワード：wasadmin 作業ディレクトリー：/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/bin サポートされる OS ：UNIX PID ファイル名を保管する環境変数の名前：PID_FILE

指定後、「適用」をクリックし、「保管」します。

それぞれのパラメータを

改行で区切って指定しま

す。


163/382

/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/bin


164/382

③ PID ファイル変数の設定

①、②で指定した、「PID ファイル名を保管する環境変数の名前」に相当する環境変数を設定します。ミドルウェア･エージェントは、ここで指定したプロセス ID ファイルの有無（プロセスが起動してい

ると作成され、プロセスが停止すると削除されます）をチェックして、稼動しているか否かのステー

タスチェックを行っています。 server1 の設定画面から、「変数」をクリックします。下図の様な画面が表示されますので、「新規作成」をクリックします。

新規作成画面が表示されますので、以下の様に「名前」に「PID_FILE」、「値」に

「/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/server1.pid」を指定します。「適用」をクリックし、「保管」します。

/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/server1.pid

これで、サーバーの定義は終了です。


165/382

4-4 動的クラスターの作成サーバーの定義が終了したら、動的クラスターの作成を行います。管理コンソールのメニューから、「サーバー」⇒「動的クラスター」をクリックします。

ウィザード画面が開きます。ステップ 1 では、動的クラスターに定義するサーバーのタイプと動的クラスター名を指定します。ここでは、「サーバー･タイプ」に「カスタム HTTP サーバー」を選択し、動的クラスター名に

「DC_nonWAS」を指定する事とします。


166/382

ステップ 2 の操作はスキップされ、ステップ 3 の設定画面が表示されます。ここでは、クラスターに追加するメンバーの定義を行います。リストに表示されているサーバーを選

択し（本構成では、XDCell01/ise039(6.1.0.0)/server1 のみ）、「メンバーの追加」をクリックします。

メンバー一覧に指定したサーバーが追加されます。「次へ」をクリックします。


167/382

ステップ 4 の操作もスキップされ、ステップ 5 の操作に移ります。ステップ 5 では、動的クラスターのプロパティーを指定します。ここでは、デフォルトのままとし、「次へ」をクリックします。

ステップ 6 では、指定したパラメーターの確認を行います。確認後、「終了」をクリックします。


168/382

「保管」します。

これで、動的クラスターの設定は終了です。動的クラスターの一覧に、以下の様にエントリーが追加されます。


169/382

4-5 既存 ND アプリケーション定義の作成次のステップは、4-4 で作成した動的クラスターで稼動するアプリケーションの定義を行います。定義に先立って、動的クラスターに含まれる ise039 上の server1 プロセスで稼動しているアプリケー

ションの稼動確認を行っておきます。ここでは、シンプルに snoop サーブレットを対象のアプリケーションとする事とします。server1 で

の定義に従い、http://ise039/DefaultApps/snoop にアクセスして、正常に画面が表示される事を確認

します。

サーバーでの稼動の確認が出来たら、オンデマンド・ルーターからアクセスするための定義に移りま

す。管理コンソールのメニューから、「アプリケーション」⇒「すべてのアプリケーション」をクリッ

クします。


170/382

以下のような画面が表示されますので「追加」をクリックします。

次の画面では、アプリケーション･タイプを指定します。ここでは、「非管理対象 web アプリケーション」を選択し、「次へ」をクリックします。

ウィザード画面が表示されます。ステップ 1 では、一般的なプロパティーについて指定を行います。ここでは、「アプリケーション名」に「snoop」、「アプリケーション･エディション」はデフォルトのま

ま「1.0.0」を指定して「次へ」をクリックします。


171/382

ステップ 2 では、デプロイメントに関する設定を行います。「モジュール名」に「snoop」を、「コンテキスト･ルート」に「/DefaultApps」を指定します。コンテ

キスト･ルートは、定義対象の既存のアプリケーションとそろえる必要があり、「/」のみを指定するこ

とは出来ませんので、注意が必要です。アプリケーションの配置のターゲットとしては、4-4 で定義した「DC_nonWAS」動的クラスターを対

象とします。下図の様に「DC_nonWAS」をハイライトし、「追加」をクリックします。

ターゲットのリストの右側のフィールドにエントリが移動しますので、「適用」をクリックします。


172/382

画面下の一覧にエントリーが追加されます。この状態で「次へ」をクリックします。

ステップ 3 は設定の確認です。確認後、「終了」をクリックします。


173/382

アプリケーション定義が一覧に追加されたことを確認し、「保管」をクリックします。


174/382

5 稼動確認前節で基本的な構成が完了しました。本節では、構成した定義での動作確認と、追加の機能構成と検

証の実施を記述します。 5-1 各プロセスの起動本構成の稼動に当たっては、以下のコンポーネントの起動が前提となりますので、稼動確認に入る前

に起動いたします。

･ise036XDDmgr01 ：DM

･ise036XDNode01 ：NodeAgent

･ise036XDNode01 ：odr

･ise039 ：ミドルウェア･エージェント

･ise039 ：server1

･ise039 ：NodeAgent

ここでは、DM は起動しているものとして、管理コンソールからそれぞれのコンポーネントを起動す

る手順について記述します。 (1) ノード･エージェントの起動管理コンソールのメニューから、「システム管理」⇒「ミドルウェア･ノード」を選択します。


175/382

以下の様な画面が表示されます。「ise036XDNode01」を選択し、「操作可能なアクションの選択」か

ら「エージェントの始動」を選択し、右隣の「実行」をクリックします。

ユーザー名/パスワードの入力画面が表示されます。ここでは、ise036 にアクセスし、ノード･エージェントを起動するための OS のユーザー名/パスワー

ドを入力します。入力後、「OK」をクリックします。


176/382

正常に起動が開始されると、次のメッセージが表示されます。

起動開始後は、ミドルウェア・ノードの一覧画面、もしくは、ノード･エージェントの一覧画面から、

ノード･エージェントの起動を確認できます。暫くしたら「状況」欄にあるリフレッシュボタンをクリ

ックし、状況を確認しながら、起動されるのを待ちます。


177/382

(2) オンデマンド・ルーターの起動次は、オンデマンド・ルーターを起動します。管理コンソールのメニューから、「サーバー」⇒「オンデマンド・ルーター」をクリックします。

次のような画面が表示されます。「odr」のエントリを選択し、「始動」をクリックします。


178/382

暫くすると、以下のような画面に切り替わり、odr の起動が確認できます。


179/382

(3) ミドルウェア･エージェントの起動次に、ミドルウェア･エージェントの起動を行います。管理コンソールのメニューから、「システム管理」⇒「ミドルウェア･ノード」を選択します。

以下のような画面が表示されます。ミドルウェア･エージェントが導入されている「ise039」をチェッ

クし、「エージェントの始動」を選択して「実行」をクリックします。


180/382

この動作は別ノード上のプロセス起動になるため、認証情報を入力する必要があります。以下のような画面が表示されますので、ise039 上でミドルウェア･エージェントを起動する OS のユー

ザーの ID とパスワードを入力し、「OK」をクリックします。

以下のようなメッセージが表示されます。

再度ミドルウェア･ノード一覧画面を表示し、状況をリフレッシュしながら稼動状態になることを確認

します。起動されると以下の様になります。


181/382

(4) アプリケーション・サーバーの起動後に、アプリケーション・サーバー・プロセスを起動します。

管理コンソールのメニューから、「サーバー」⇒「その他のミドルウェア･サーバー」⇒「カスタム HTTPサーバー」を選択します。

以下の画面が表示されます。 server1 を選択して、「始動」をクリックします。

注) WAS ND のアプリケーション･サーバーのプロセスは、ノード･エージェントの稼動

を前提としています。よって、ノード･エージェントを事前に起動しておく必要がありま

す。5-1(1)の手順を参照してオンデマンド･ルーター用にノード･エージェントを起動し

た手順を使用してもいいですし、以下のコマンドで起動しても構いません。 /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/bin/startNode.sh


182/382

以下の様なメッセージが表示され、「server1」の状況が開始済みになります。

これで、検証に必要なコンポーネントの用意が完了した事になります。


183/382

5-2 オンデマンド・ルーター経由での割り振り確認まずは、既存 ND 環境の AS へオンデマンド･ルーター経由での割り振りが正常に行われるかを確認し

てみましょう。構成の中で定義したアプリケーションへオンデマンド･ルーターのポート 80 でアクセ

スし、正常に snoop 画面が表示されれば成功ということになります。インターネット・エクスプローラー、Firefox などの Web ブラウザーにて、以下の URL へアクセスし

てください。 http://ise036/DefaultApps/snoop

以下の様な画面が表示されれば成功です。


184/382

5-3 リソースモニタリング機能ここでは、既存 ND 環境では出来なかった、各種サーバーのリソース確認を行います。ミドルウェア･

エージェントを導入することで、これらの情報収集が可能になり、管理コンソールにてビジュアルに

確認することが出来るようになります。管理コンソールのメニューから「サーバー」⇒「動的クラスター」をクリックします。

動的クラスターの一覧にて、「DC_nonWAS」をクリックします。


185/382

以下の様な画面が表示されます。「報告書」タブをクリックします。

以下のような画面が表示されます。デフォルトでは表示するデータエントリ構成がされていない状態ですので、「データの追加」をクリッ

クします。


186/382

以下のような画面が表示されます。ここでは、一例として、ise039 ノードに対する同時要求数、空き

メモリー容量、CPU 使用率を定義することとします。「データ･セット･タイプ」に「ノード」を指定し、「データ･セット」に「ise039」を指定します。次に、「使用可能なメトリック」欄で、Ctrl キーを押しながら、「同時要求数」、「空きメモリー（MB）」、

「CPU 使用率」を選択します。（Ctrl キーを押しながら項目をクリックすることで、複数項目の同時

選択が可能になります。）全て選択したら、「OK」をクリックします。

Ctrlを押しながらクリックで複数選択可能


187/382

以下の様に、選択したデータがグラフ表示されるようになります。


188/382

後に、ここで定義したデータ･セットを毎回定義し直さなくていいように保存しておきます。

画面下部の「図表タブの現行グループ構成を図表グループとして保管」フィールドに任意の定義名を

入力します。ここでは、「ise039_CPU_Mem_#req」と指定して、「保管」をクリックします。


189/382

5-4 ヘルス･ポリシーによるサーバーの稼動状況監視次は、ヘルス･ポリシーを設定し、サーバーの稼動がある一定条件を満たしたときにアクションをとる、

という機能を検証します。この機能は、例えばリクエストに対するレスポンスがタイムアウトした場

合など、サーバーが不健全である兆候を示した際に、プロセスを再始動するといった使い方をします。アクションはプロセスの再始動など予め定義されているものの他に、スクリプトを呼び出すなどカス

タムで独自のアクションを作成･定義することも可能です。ここでは、1000 リクエストを処理したら、プロセスの再始動を行うというポリシーを定義することと

します。管理コンソールのメニューから、「動作ポリシー」⇒「ヘルス･ポリシー」を選択します。

以下のような画面が表示されます。「新規作成」をクリックします。


190/382

ウィザード画面が表示されます。ステップ 1 では、一般的なプロパティーについて設定します。「名前」に「1000_stop」、アクションに

「ワークロード条件」を指定し、「次へ」をクリックします。

ステップ 2 では、1 で設定したヘルス条件のプロパティーについて設定します。「要求合計」に「1000」を指定し「次へ」をクリックします。アクションについては、デフォルトで

すでにサーバー再始動アクションが定義されていますので、そのままとします。


191/382

ステップ 3 では、モニターの対象となるメンバーを設定します。本構成では、対象を動的クラスター

としますので、「メンバー･タイプ」に「動的クラスター」を指定します。

次に、左側のフィールドに示される使用可能なメンバーの一覧から、「DC_nonWAS」を選択して、「追

加」をクリックします。


192/382

「1000_stop」ポリシーのメンバーとして、「DC_nonWAS」が定義されました。「次へ」をクリックし

ます。

ステップ 4 は、設定情報の確認です。確認後、「終了」をクリックし、「保管」します。

これで、ヘルス･ポリシーの設定は完了です。


193/382

5-5 ランタイム･タスクによるサーバー運用ここでは、5-4 で定義したポリシーに抵触した場合に、アクションが実行されることを確認します。管理コンソールのメニューから、「サーバー」⇒「カスタム HTTP サーバー」を選択します。

以下のような画面が表示されます。「server1」をクリックします。


194/382

次のような画面が表示されます。「オペレーション」タブをクリックします。

次の画面で、「活動中のタスク」タブをクリックします。


195/382

この状態では、まだヘルス・ポリシーに抵触する事象は起こっていないため、タスクは空の状態にな

っています。

この状態で、5-2 でアクセスしたページに 1000 回以上アクセスします。「状態」列の右側にあるリフレッシュボタンをクリックしながら状況を確認します。暫くすると、以

下の様にタスクが表示されます。


196/382

「タスク ID」列に示される ID をクリックして内容を確認してみます。以下のような内容が表示されます。

ここでは、モードを監視に設定していますので、自動ではタスクが実行されません。内容確認後、手

動でこのタスクを実行します。このタスクを選択し、「サブミット」ボタンをクリックします。


197/382

サブミット後、管理コンソールのメニューから、「サーバー」⇒「カスタム HTTP サーバー」を選択

して状態を確認してみましょう。タスクのサブミットの結果、サーバーが停止されている事が確認で

きます。（このタスクは「server1」を再起動するタスクですので、タイミングによっては、停止状態

になっていない場合がありますが、タスク実行直後からこの状態を観察すると、起動状態⇒停止状態

⇒起動状態と遷移するのが確認できます。）

暫くして状況をリフレッシュすると、再起動されて起動状態になっていることが確認できます。

以上で、ヘルス･ポリシー設定とランタイムタスクの実行が確認できました。

websphere extended deployment v6.1...

Documents