第 7 章 WebSphere Product Center サービスの管理


サービスのタイプ

WebSphere Product Center システム全体は、並行して稼働する以下のサービスから構成されます。

admin  管理サーバーは、リモート・マシン上のモジュールを開始したり停止したりします。
appsvr  アプリケーション・サーバーは、Java Server Pages を供給します。
eventprocessor  イベント処理プログラムは、すべてのモジュール間のイベントをディスパッチします。
queuemanager  キュー・マネージャーは、WebSphere Product Center の外部に文書を送信します。
scheduler  スケジューラーは、バックグラウンド・ジョブを実行します。
workflow ワークフロー・エンジン

admin_properties.xml およびクラスター化

サービスは、ワークステーションのクラスター内で実行できます。 クラスター内のさまざまなマシンが、admin_properties.xml ファイル内で定義されます。

$TOP/etc/default/admin_properties.xml

: admin_properties.xml には、 追加情報があります。各サービスは、admin_properties.xml ファイルにリストされたどのマシンでも実行できます。

標準的な WebSphere Product Center クラスターの場合、 アプリケーション・サーバーとサポート RMI レジストリー・ユーティリティーを WebSphere Product Center サーバーに、 残りの WebSphere Product Center コンポーネントを 2 次サーバーに含めることができます。

1 次サーバーがフェイルオーバーした場合、 2 次サーバー上でこれまで稼働していなかったサービスを最低限の労力でオンラインに回復することができるので、ダウン時間を最小にできます。

 

 図 4 - 標準的な WebSphere Product Center クラスター

サービス名 - 長い名前と短い名前

それぞれのサービスは、サービス名によって一意的に識別されます。 サービス名は固有でなければなりません (クラスター内のマシン上で、同じ名前を持つ別のサービスが稼働している場合、サービスは開始しません)。

各サービスは、サービス名が異なる限り、複数のマシン上で稼働できます。

「admin」および「appsvr」サービスの名前は、システムによって固定されています。

admin の場合は admin_<machine name> (例: 「admin_server1」)

appsvr の場合は appsvr_<machine name> (例: 「appsvr_server1」)

他のサービスの場合は、任意の名前を選んでください。選んだ名前は、実際にはサービスの短い名前になります。

長い名前は、この短い名前を使用して内部的に作成されます。

rmi://<machine name>:<rmi port>/<db user name>/<service type>/<service short name>

:

「scheduler」サービスをマシン「server1」上で実行しており、 使用する rmi ポートが 17507、接続先のデータベース・ユーザーが「pauadm」の場合、 サービスの名前が「sch1」とすると、長い名前は次のようになります。

rmi://server1:17507/pauadm/scheduler/sch1

同じユーザーおよびポートに対して別のスケジューラー (sch2) がサーバー 2 で稼働する場合、長い名前は次のようになります。

rmi://server2:17507/pauadm/scheduler/sch2

サービス・タイプのメモリー・フラグの設定

WebSphere Product Center サービスのメモリー・フラグは、 WebSphere Product Center インストール・ディレクトリーにある、WebSphere Product Center 初期設定スクリプト内で設定されます。

<install location>/setup/init_ccd_vars.sh

WebSphere Product Center サービスのために、以下のメモリー・フラグ設定を使用することをお勧めします。

export ADMIN_MEMORY_FLAG='-Xmx64m -Xms48m'

export APPSVR_MEMORY_FLAG='-Xmx512m -Xms64m'

export EVENTPROCESSOR_MEMORY_FLAG='-Xmx64m -Xms48m'

export QUEUEMANAGER_MEMORY_FLAG='-Xmx64m -Xms48m'

export SCHEDULER_MEMORY_FLAG='-Xmx1024m -Xms48m'

export WORKFLOWENGINE_MEMORY_FLAG='-Xmx64m -Xms48m'

RMI – リモート・メソッド呼び出し

サービス登録は RMI (Java リモート・メソッド呼び出し) を介して実行されます。 何らかのサービスを稼働する前に、マシン上で RMI が開始されていることを確認してください。

RMI 状況

クラスター内の稼働サービスすべてのリストを取得するには、次のスクリプトを実行します。

$TOP/bin/go/rmi_status.sh

このスクリプトは、クラスター内のすべてのマシン上の RMI デーモンと連絡を取り、各マシン上のローカル・サービスのリストを取得します。 これは、長い名前のリストを戻します。

ログ・ファイル

各サービスは、ランタイム・ログ・ファイルを生成します。

$TOP/logs/<service>/<service name>/svc.out

例:

「sch1」という名のスケジューラーは、$TOP/logs/scheduler/sch1 内にランタイム・ログ・ファイル svc.out を生成します。

サービスが開始したらログ・ファイルを確認して、すべてが問題なく開始したことを確認するようお勧めします。

サービスの開始

以下のセクションでは、ローカル・スクリプトを使用してサービスを制御する方法を説明します。 サービスを使用する前に、そのサービスを使用するマシン上で、RMI レジストリーを開始する必要があります。

RMI を開始するには、次のスクリプトを実行します。

$TOP/bin/go/start/start_rmiregistry.sh

ローカル・マシン上でのサービスの開始

ローカル・マシン上でサービスを開始する一番簡単な方法は、ディレクトリー $TOP/bin/go/start/ 内にあるスクリプトを使用することです。

スクリプト 説明

start_admin.sh

 admin サービスを開始します。

start_appsvr.sh

 アプリケーション・サーバーを開始します。

start_eventprocessor.sh

 イベント処理プログラムを開始します。

start_queuemanager.sh

 キュー・マネージャーを開始します。

start_rmiregistry.sh

 RMI レジストリーを開始します。

start_scheduler.sh

 スケジューラーを開始します。

start_workflowengine.sh

 ワークフロー・エンジンを開始します。

これらのスクリプトのそれぞれは、サービス名をオプションの引き数として使用できます (start_admin.sh、start_appsvr.sh、および start_rmiregistry.sh を除く)。

-svc_name=<service name>

admin および appsvr サービスは、デフォルトの名前を使用します (admin_<machine name> および appsvr_<machine name>)。 別の名前を指定しても、効果はありません。

サービス名を指定しない場合は、デフォルトの名前が使用されます。

「scheduler」(スケジューラー)

「eventprocessor」(イベント処理プログラム)

「queuemanager」(キュー・マネージャー)

「workflow」(ワークフロー・エンジン)

注: 稼働中のローカル・サービスと同じ名前のローカル・サービスを開始すると、 稼動中のローカル・サービスがアボートされますので注意してください。したがって、 スクリプトを使用してサービスを「再始動」することもできます (まず最初にアボートして、その後再始動する)。

:

「sch1」という名前のスケジューラーを開始する場合

$TOP/bin/go/start/start_scheduler.sh -svc_name=sch1

デフォルト名のスケジューラーを開始する場合

$TOP/bin/go/start/start_scheduler.sh

サービスのアボート

サービスをアボートすると、そのサービスがシャットダウンして、利用不可になります。

たとえば、スケジューラーがジョブを実行中の場合に、ジョブは処理の途中でアボートされます。

ローカル・マシン上でのサービスのアボート

ここに示す構造は、開始時の構造を反映しています。

ディレクトリー $TOP/bin/go/abort/ 内のスクリプトを使用します。

スクリプト 説明

abort_admin.sh

 admin サービスをアボートします。

abort_appsvr.sh

 アプリケーション・サーバーをアボートします。

abort_eventprocessor.sh

 イベント処理プログラムをアボートします。

abort_queuemanager.sh

 キュー・マネージャーをアボートします。

abort_rmiregistry.sh

 RMI レジストリーをアボートします。

abort_scheduler.sh

 スケジューラーをアボートします。

abort_workflowengine.sh

 ワークフロー・エンジンをアボートします。

各スクリプトは、サービス名をオプションの引き数として使用できます (abort_admin.sh、abort_appsvr.sh、および abort_rmiregistry.sh を除きます)。

-svc_name=<service name>

: RMI をアボートすると、 リモート・マシン上のサービスと連絡を取れなくなります。

サービスの停止

サービスを停止すると、サービスを円滑にシャットダウンするよう要求が出されます。 サービスが「ブロックされて」いる場合には、シャットダウン・プロシージャーが全く実行されないことがあります。 スケジューラーは、現在実行中のジョブをすべて完了するまでは、停止しません。

ローカル・マシン上でのサービスの停止

ここに示す構造は、開始時の構造を反映しています。

ディレクトリー $TOP/bin/go/stop/ 内のスクリプトを使用します。

スクリプト 説明

stop_admin.sh

 admin サービスを停止します。

stop_appsvr.sh

 アプリケーション・サーバーを停止します。

stop_eventprocessor.sh

 イベント処理プログラムを停止します。

stop_queuemanager.sh

 キュー・マネージャーを停止します。

stop_scheduler.sh

 スケジューラーを停止します。

stop_workflowengine.sh

 ワークフロー・エンジンを停止します。

各スクリプトは、サービス名をオプションの引き数として使用できます (stop_admin.sh、stop_appsvr.sh、および stop_rmiregistry.sh を除きます)。

-svc_name=<service name>

アボートと停止に関する重要な注記

停止とアボートのどちらを使用するか

アボート サービスのシャットダウンは保証されますが、現在実行中のタスクが中断しないという保証はありません。
停止 「もしも」サービスが停止するのであれば、現在実行中のタスクが最初に停止してから、サービスが円滑に停止することが保証されます。

すべての WebSphere Product Center モジュールの開始

ローカル・マシン上での WebSphere Product Center の開始

スクリプト $TOP/bin/go/start/start_local.sh を実行します。

これにより、RMI レジストリーと、以下のサービスが開始します。

: このスクリプトは、何かを開始する前に、まずローカル・マシン上の既存のシステムを強制終了しようとします。

ローカル・マシン上での WebSphere Product Center のアボート

スクリプト $TOP/bin/go/abort/abort_local.sh を実行します。

ローカル・マシン上で開始されているすべてのサービスがアボートされます。 RMI レジストリーがアボートされます。

ローカル・マシン上での WebSphere Product Center の停止

スクリプト $TOP/bin/go/stop/stop_local.sh を実行します。

ローカル・マシン上で開始されているすべてのサービスが停止します。 デフォルトで、RMI レジストリーが他のサービスとともに停止します。 RMI レジストリーを稼働したままにするには、以下のオプションを渡します。

--kill_rmi=no

: "kill_rmi=no" の前に、ダッシュを 2 つ付けます。

サービス状況

簡略形式のサービスの状況の取得

サービスの簡略状況を入手するには、以下のパラメーターを渡します。

-cmd=check -svc=<service name>

:

スケジューラーの状況を入手するには以下のようにします。

    rootadmin.sh -cmd=check -svc=scheduler

簡略状況には次のものがあります。

実行中 

 サービスが実行中であり、ハートビート機能に応答しています。 

見つかりません  

 サービスが見つかりません。サービスが開始されていなかったか、または破損していることなどが考えられます。

見つかりましたが、応答していません  

 サービスが RMI レジストリーに登録されたものとして見つかりましたが、ハートビート機能に応答しません。サービスを再始動する必要があるかもしれません。

サービスの詳細な状況の取得

サービスの詳細な状況を取得するには、以下のパラメーターを渡します。

-cmd=status -svc=<service name>

これにより、任意のブラウザーを使用して表示可能な html ファイルが作成されます。端末で、lynx を使用して出力をフォーマットすることもできます。

:

スケジューラーの状況を入手するには以下のようにします。

rootadmin.sh -cmd=status -svc=scheduler > /tmp/sch_status.html; lynx /tmp/sch_status.html

    または

rootadmin.sh -cmd=status -svc=scheduler > /tmp/sch_status.html; lynx -dump /tmp/sch_status.html

: 上記の例で使用している「>」は、 状況の詳細情報を出力ファイルに書き出します。

状況は、サービスの中で実行しているさまざまなスレッドの概要、および現在そのサービスが使用しているデータベース接続の状況を示します。