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 レジストリーと、以下のサービスが開始します。
- 「admin_<machine name>」という名前の admin
- 「appsvr_<machine name>」という名前のアプリケーション・サーバー
- 「eventprocessor」という名前のイベント処理プログラム
- 「queuemanager」という名前のキュー・マネージャー
- 「scheduler」という名前のスケジューラー
- 「workflow」という名前のワークフロー
注: このスクリプトは、何かを開始する前に、まずローカル・マシン上の既存のシステムを強制終了しようとします。
ローカル・マシン上での 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
注: 上記の例で使用している「>」は、 状況の詳細情報を出力ファイルに書き出します。
状況は、サービスの中で実行しているさまざまなスレッドの概要、および現在そのサービスが使用しているデータベース接続の状況を示します。