7. WebOTXの内部サービス

7.1. TPシステム

TPシステムに関する運用操作法について説明します。 WebOTX V6.3以降の統合運用管理ツールでは、WebOTX V5の運用管理ツールと比べてショートカットキーが一部以下のように変更されています。

表7.1-1
メニュー V6.3以降 V5
起動 CTRL+S F7
停止 CTRL+T Shift+F7
強制停止 CTRL+F -
削除 DEL Del
モジュールの活性化 CTRL+E -
モジュールの閉塞 CTRL+D -
新規作成 CTRL+N Ctrl+N

7.1.1. 操作・状態確認(TPシステム)

7.1.1.1. 設定の変更

統合運用管理ツールから設定
  1. 統合運用管理ツールよりドメインと接続します。
  2. ツリービューよりWebOTXシステム[TPシステム]を選択します。
  3. リストビューより変更したい項目を選択し、変更します。

PropertyChange
図7.1.1.1-1

コマンドから設定
  1. otxadminコマンドを起動し、ドメインにログインします。
    otxadmin> login --user admin --password adminadmin --port 6212
    
  2. 現在設定している値を確認します。
    otxadmin> get tpsystem.*
    
  3. 変更したい属性を変更します。
    otxadmin> set tpsystem.serverName=host1
    
注意事項

システムパラメータ、イベントジャーナル、ジャーナルに関する設定はTPシステムが停止している必要があります。

7.1.1.2. 設定値の説明

表7.1.1.2-1
タブ表記 項目 説明 既定値
システムパラメータ システムモデル
システムパラメータのモデルをシステム規模に合わせて、小モデル、大モデル、最大モデルから選択します。 Standard の場合は最大モデルを選択することは出来ません。 またモデルを選択すると、個別のシステムパラメータの値はすべて初期化されます。 設定の変更はTPシステム稼働中に行うとエラーになります。

Standard:小、Enterprise:大
システムパラメータ history.actの世代数
history.actの世代数を設定します。 指定ライン数到達時かTPモニタ起動時に設定値まで世代切り替えを行います。 設定の変更はTPシステム稼働中に行うとエラーになります。

10
システムパラメータ sysmsg.trcの世代数
sysmsg.trcの世代数を設定します。 指定ライン数到達時かTPモニタ起動時に設定値まで世代切り替えを行います。 設定の変更はTPシステム稼働中に行うとエラーになります。

10
システムパラメータ トレースファイルの保存期間
プロセスグループのトレースファイルの保存期間を設定します。 指定した保存期間を超過時に、トレースファイルの削除が行われます。 トレースファイルを削除しない場合は、-1を指定してください。

30日
システムパラメータ ログファイル名の固定化
ログファイル名を固定化するかを設定します。 固定化しない場合はPID、固定化する場合は固定IDをログに付与します。 固定IDは1〜プロセス多重度×2の範囲で昇順に付与します。どの固定IDがどのプロセスIDを利用しているかは アプリケーションのログファイル{PGNAME}_sys.{固定ID}.logを参照する事で確認出来ます。
注意事項)
ログファイル名の固定化を有効にしている場合、動的設定変更、動的多重度変更の実行は推奨しません。動的設定変更、動的多重度変更を行った場合、プロセス異常終了を含むプロセス再起動後に設定される固定IDは不定です。

固定化しない
システムパラメータ/静的情報 最大アプリケーショングループ数
最大アプリケーショングループ数の設定をします。 Standardでは100を超過して設定できません。 すでに作成してあるアプリケーショングループよりも少ない値にする事はできません。 またシステムモデルを変更すると、値はそのモデルの値に自動的に変更されます。 設定の変更はTPシステム稼働中に行うとエラーになります。

Standard:20、Enterprise:100
システムパラメータ/静的情報 最大プロセスグループ数
最大プロセスグループ数の設定をします。 Standardでは100を超過して設定できません。 すでに作成してあるプロセスグループよりも少ない値にする事はできません。 またシステムモデルを変更すると、値はそのモデルの値に自動的に変更されます。 設定の変更はTPシステム稼働中に行うとエラーになります。

Standard:20、Enterprise:100
システムパラメータ/静的情報 最大オペレーション数
最大オペレーション数の設定をします。 すでに登録してあるオペレーションよりも少ない値にする事はできません。 またシステムモデルを変更すると、値はそのモデルの値に自動的に変更されます。 この数値はファクトリオペレーションとWebOTX内部オペレーション(1システムで5+プロセスグループ×7) も含んだ数にする必要があります。設定の変更はTPシステム稼働中に行うとエラーになります。

Standard:200、Enterprise:1000
システムパラメータ/静的情報 最大コンポーネント数 最大コンポーネント数を設定します。 システムで登録できる最大コンポーネント数を1から3844の間で設定します。 またシステムモデルを変更すると、値はそのモデルの値に自動的に変更されます。 設定の変更はTPシステム稼働中に行うとエラーになります。 Standard:200、Enterprise:1000
システムパラメータ/静的情報 最大インターフェース数 最大インターフェース数を設定します。TPシステムで登録できる最大インタフェース数を1から10000の間で設定します。またシステムモデルを変更すると、値はそのモデルの値に自動的に変更されます。設定の変更はTPシステム稼働中に行うとエラーになります。 Standard:200、Enterprise:1000
システムパラメータ/動的情報 最大プロセス数
最大プロセス数の設定をします。 Standardでは100を超過して設定できません。 すでに設定してあるプロセス数よりも少ない値にする事はできません。 またシステムモデルを変更すると、値はそのモデルの値に自動的に変更されます。 設定の変更はTPシステム稼働中に行うとエラーになります。

Standard:20、Enterprise:100
システムパラメータ/動的情報 最大スレッド数
TPシステムで作成できる最大スレッド数を1から9850までの整数で指定します。 すでに設定してあるスレッド数よりも少ない値にする事はできません。 プロセスグループのプロセスは、指定したスレッド数の他に、WebOTX内部で使用するスレッド3つが動作します。 そのため、プロセスグループで動作する全スレッドは、プロセス数*(スレッド数+予備スレッド数+3)となります。 TPシステム内の全プロセスグループの合計スレッド数が、この値を超えない必要があります。 設定の変更はTPシステム稼働中に行うとエラーになります。

200
システムパラメータ/動的情報 メモリプールサイズ
メモリプールサイズの設定をします。 メモリプールサイズは、クライアントからのリクエスト処理を行うために利用する、共有メモリのサイズです。 同時に実行できるリクエスト数および、電文のサイズに依存します。 メモリプールサイズが不足した場合は全てのリクエスト処理がエラーとなります。 設定の変更はTPシステム稼働中に行うとエラーになります。

Windows(x86):32MB、それ以外:128MB
上限設定 プロセス障害時の再起動回数
例外などでプロセスが異常終了したとき、自動的にプロセスを再起動させる回数を1〜55000の整数で指定します。 1を設定の場合、再起動は行わずすぐにプロセスグループが停止します。 全てのプロセスグループに対してこの設定は有効となります。

5回
上限設定 プロセスを正常と仮定する間隔
プロセス正常と仮定しプロセス再起動回数をクリアするための間隔を秒単位で指定します。 この時間内にプロセスの異常終了が起こらなかった場合、そのプロセスは正常とみなされ、再起動回数はクリアされます。 -1を指定した場合は、間隔は無制限とします。 上記再起動回数だけ再起動を終えるとプロセス再起動は行いません。 全てのプロセスグループに対してこの設定は有効となります。

3600秒
上限設定 キューの最大数
キューの最大数を設定します。 TPシステムはここで指定した値以上クライアントからの要求をキューイングせずにオペレーションコールをエラーリターンさせます。 これにより高負荷時の待ち要求の数を制限し、必要以上に負荷をあげ、応答しない状況を回避できます。 -1あるいは1以上で設定します。-1を指定した場合制限はありません。 全てのプロセスグループに対してこの設定は有効となります。 ただし、アプリケーショングループ、プロセスグループごとに設定する事もできます。 その場合、アプリケーショングループ、プロセスグループの設定が有効になります。 設定の変更はTPシステム稼働中に行うとエラーになります。

-1
上限設定 オペレーション再試行回数
オペレーション再試行回数の設定をします。 データベースのデッドロックの発生など、再試行が可能な障害が発生した場合に、 APIを通してプロセスグループから再試行の指示があると、この回数オペレーションの実行をやり直します。 この回数を超えて再試行した場合は、オペレーションの実行は失敗します。 -1あるいは1〜99で指定します。-1を指定すると無限に再試行します。

-1
上限設定 プロセスのストール監視間隔
プロセスのストール監視時間を設定します。 プロセスの初期化または強制停止にかかる時間のタイムアウト値を設定します。 この時間にスレッド初期化時間は含まれません。 指定値がTPシステムの属性「プロセスを正常と仮定する間隔」より長い場合、 TPシステムの属性で指定した「プロセス障害時の再起動回数」に関係なく無限ループします。 また、オペレーションが通常でも長時間の場合(DBアクセス等)は、APループの値を極端に短くすると、 意図せずオペレーションが中断します。 システムにあわせた設定をお願いします。 設定の変更はTPシステム稼働中に行うとエラーになります。

600秒
上限設定 メモリプールサイズの閾値
メモリプールサイズの閾値を設定します。 メモリプールサイズ使用量が設定した閾値を超えた場合、イベントログ・シスログにWARNINGレベルで警告メッセージを出力します。 設定の変更はTPシステム稼働中に行うとエラーになります。0を指定した場合は、メッセージを出力しません。

90%
上限設定 メモリプールサイズの閾値を超えてから次の警告を出すまでの時間 メモリプールの使用量に関する警告メッセージ(TPS15-01323)を出力してから、次回出力するまでの時間を設定します。設定の変更はTPシステム稼働中に行うとエラーになります。 3600秒
クライアント制御 クライアント情報表示時にホスト名の逆引き処理を行う
クライアントセッションの接続クライアント情報を表示する時に、 接続しているクライアントのホスト名を逆引き処理によって取得するかどうかを指定します。 Trueにするとクライアントホスト名が表示されます。 ただし、IPアドレスからホスト名を逆引きできない環境ではこれを指定すると、 クライアント情報を表示させようとしたときにレスポンスが悪くなることがありますので設定には注意が必要です。

行わない
クライアント制御 TCPレベルでのアライブチェックを行う
TCPレベルのkeepaliveを行うかどうかを選択します。 クライアント(もしくはWebサーバ)のアボートにより無効となってしまったセッションをクリアする場合に利用します。 特に連続運用をする場合は設定が必要です。 この機能はOSに依存した機能でありkeepaliveの間隔はOSで設定した値が適用されます。

行う
システム情報 接続サーバ名
クライアント(Webサーバ)がWebOTXに接続するときに利用するサーバ名を127文字以内で指定します。 サーバ名にはホスト名、IPアドレス、ドメイン付きホスト名のどれかを指定してください。 クライアント側で実際にこの名前を用いてセッションの接続を行います。Javaアプリケーションでは、プロセスグループ起動時のJavaシステムプロパティ ExternalHostNameのホスト名としても利用します。 よってクライアント側で認識できる名前を指定してください。

自ホスト名
システム情報 システム名
TPシステムの名前です。 ドメイン作成時に設定した名前は変更することはできません。

-
システム情報 システムID
システムを一意に識別するIDを0から255までの値で指定してください。 共有メモリの識別子やラウンドロビンのIDに使用されます。 ドメイン間で使用するシステムIDの中で一意に設定してください。 設定の変更はTPシステム稼働中に行うとエラーになります。

-
システム情報 名前サーバホスト名
リファレンスを登録する名前サーバホスト名を127文字以内で指定します。 ホスト名、IPアドレス、ドメイン付きホスト名のどれかを指定してください。 別マシンに名前サーバを構築する場合に指定します。指定した名前の名前サーバにオブジェクトを登録します。

自ホスト名
システム情報 名前サーバポート番号
リファレンスを登録する名前サーバポート番号を設定します。 0を指定した場合は、そのドメインで定義している名前サーバポート番号になります。 ドメイン外の名前サーバにアクセスする場合に設定してください。

0
システム情報 CORBAエラーの詳細化
ライセンス違反等オペレーション実行中にWebOTXサーバでエラーを検出したときのクライアントに返却するCORBAエラーを詳細化します。

行う
システム情報 IPv6優先
IPv6を優先的に使用します。 この設定を変更すると、プロセスグループ起動時の動作も連動して変わります。 この設定は、ドメインのIPv6の設定(IPv6優先:ipv6-enable)と連動します。 変更した場合、TPシステムの再起動が必要になります。

IPv4優先
システム情報 10MB以上の電文を利用する
10MB以上の電文を利用するかを設定します。 設定の変更はTPシステム稼働中に行うとエラーになります。

利用する
システム情報 オペレーション実行中の停止をエラーとする
オペレーション実行中に停止を伴う操作(モジュール停止、配備解除)が行われた場合、その操作をエラーとするかを指定する。

エラーとしない
オペレーション制御 重み付けオペレーション優先度制御 重み付けラウンドロビン方式でオペレーションの優先度制御を行います。 0
オペレーション制御 オペレーションの統計情報を採取しない
オペレーションの統計情報を採取しないようにします。 オペレーションの統計情報を採取しないことによりメモリリソースを節約できます。 統計情報を採取しない場合は、コマンドもしくはツールで運用アシスタントを利用しないようにTPシステムのプロパティを変更して下さい。 これにより運用アシスタントの機能を利用できなくなります。変更はドメイン再起動後に有効になります。

採取しない
オペレーション制御 実行時間上限
実行時間上限を設定します。 オペレーションの応答時間が指定時間(秒)を過ぎてもレスポンスが返却されない場合オペレーション処理を中断します。 また−1を設定すると、上限を設定しません。 この設定を変更した場合、運用アシスタントの「実行時間上限を自動設定する」設定は、「自動設定しない」に変更されます。 運用アシスタントに実行時間上限を自動設定させたい場合は、「自動設定する」に変更し直してください。 実行時間上限はドメインに配備した全アプリケーションのオペレーションに対して設定されます。 オペレーションのプロパティで個別に実行時間上限を設定した場合はその値が優先されます。 ただし、再度この値を更新すると個別に設定した値も上書きされます。

600秒
オペレーション制御 プロセスを強制停止する
実行時間上限超過時にプロセスを強制停止するかどうかを設定します。 オペレーションの実行時間上限は、運用アシスタントにより推奨値が自動設定されている場合があります。 プロセスを強制停止する場合は、実行時間上限の設定値が問題ないかを検討して下さい。 プロセスを強制停止する設定に変更した場合、予期しない時間で強制停止されることを防ぐために、 運用アシスタントの「実行時間上限を自動設定する」設定は、「自動設定しない」に変更されます。 運用アシスタントに実行時間上限を自動設定させたい場合は、「自動設定する」に変更し直してください。 「プロセスを強制停止する」設定はドメインに配備した全アプリケーションのオペレーションに対して反映されます。 オペレーション単位で個別にプロセスを再起動するかどうかを設定した場合はその値が優先されます。 ただし、再度この設定を更新すると個別に設定した値も上書きされます。

強制停止しない
名前サーバへの登録 名前サーバへの登録
名前サーバへの登録ポリシについて設定します。 永続的に扱う場合、名前サーバへのIOR登録をプロセス起動停止に関係なく行えます。 このため、プロセス起動時の名前サーバアクセス負荷を軽減することができます。 一時的に扱う場合、プロセス起動時に名前サーバへの登録を行います。 このとき、ラウンドロビン機能の設定もできます。

永続的に扱う
名前サーバへの登録 ラウンドロビン機能を使用する
名前サーバのラウンドロビン機能を使用するかどうかの設定をします。 同一のサーバアプリケーションが登録されたシステム間で負荷分散を行う時に設定します。 ラウンドロビン機能を使用するときは、ObjectBrokerにて名前サーバのラウンドロビン機能を設定する必要があります。

する
名前サーバへの登録 CORBA自動名前登録
CORBAアプリケーションを配備時に自動で名前サーバにリファレンスを登録します。 設定は次回の配備時に反映されます。

名前登録を行わない
起動/停止 起動タイムアウト
システム起動タイムアウトの設定を秒単位で指定します。 指定した時間以内に起動要求が完了しない場合、起動要求はタイムアウトします。 ただし起動処理はタイムアウトした後も行いますのでタイムアウトした後に起動が完了する場合があります。 タイムアウトした場合は状態を確認してください。

120秒
起動/停止 停止タイムアウト
システム停止タイムアウトの設定を秒単位で指定します。 指定した時間以内に停止要求が完了しない場合、停止要求はタイムアウトします。 ただし停止処理はタイムアウトした後も行いますのでタイムアウトした後に停止が完了する場合があります。 タイムアウトした場合は状態を確認してください。

120秒
起動/停止 プロセスを即時停止する
プロセスを即時停止します。 プロセスを即時停止する場合、アプリケーショングループ、プロセスグループ、 アプリケーション停止時の後処理をおこなわないためアプリケーショングループ、プロセスグループの停止時間が短縮されます。 プロセスグループの後処理ではログ採取も行っているため、即時停止をした場合障害解析が困難になる可能性がありますのでご注意下さい。 TPシステム稼働中に変更するとエラーになります。

即時停止しない
起動/停止 アプリケーショングループの起動間隔
アプリケーショングループの起動間隔を指定します。 複数アプリケーションが同時に起動することにより、一時的なリソース不足になる場合は、本指定で起動間隔の調整を行ってください。自動起動時は<アプリケーショングループ数>*<設定された間隔>で起動されます。合計値が「起動タイムアウト」に設定されている値より上回る値を設定しないでください。

0秒
イベントジャーナル イベントジャーナルを採取する
イベントジャーナルを採取するかどうか設定します。 オペレーションの実行の過程で起きる障害については、イベントジャーナルを追っていくことで、 どこで障害が発生しているか調べることができます。 また、イベントジャーナルではクライアントからの受信開始から応答の送信終了までを確認できるため、 障害箇所がサーバ側なのかそうではないのか(ネットワークやクライアント側なのか)を切り分けることができます。 設定の変更はTPシステム稼働中に行うとエラーになります。

する
イベントジャーナル ファイルサイズ
イベントジャーナルファイルサイズの設定をします。 イベントジャーナルはこのファイルサイズでサイクリックに採取されます。 イベントジャーナルを多く採取したい場合はこのサイズを増やします。 設定の変更はTPシステム稼働中に行うとエラーになります。

10MB
イベントジャーナル 出力ファイルの最大行数
イベントジャーナルを編集する際の、ひとつの出力ファイルの最大行数を設定をします。 イベントジャーナルは[採取したイベントジャーナルの編集(editEventJournal)] オペレーションによってこの行数で複数のファイルに分割されて出力されます。 ファイル名は(システム名)_woejout(数字).logとなります。

30000行
ジャーナルの設定 ジャーナルを採取する
ジャーナルを採取するかどうか設定します。 ジャーナルはWebOTXの稼働状況を評価するための性能及び統計情報を各種レポートとして提供します。 設定の変更はTPシステム稼働中に行うとエラーになります。

する
ジャーナルの設定 ファイルサイズ
ジャーナルファイルサイズの設定をします。 ジャーナルはこのファイルサイズでサイクリックに採取されます。 採取する設定のときはシステム起動中であっても変更できますが、反映するためにはシステムを再起動する必要があります。

10MB
例外ハンドル 例外ハンドルを行う
例外発生時(OSからのシグナル受信時)に、WebOTXで例外処理をするかどうかを設定します。 Trueの場合はWebOTXが例外処理を行いますが、falseの場合は例外処理を行いません。 OSのデバック情報(Windows環境でのワトソンログやUNIX環境でのcoreファイル)を出力させる場合はfalseにします。 設定は、言語がJava以外のプロセスグループのみ有効です。

する
WatchServer WatchServerを使用する
WatchServerを使用するかどうかの設定を行います。 WatchServerを使用する場合、 「名前サーバホスト名」で設定したサーバのWatchServerに対してオブジェクトリファレンスの登録・削除処理を行います。

しない
WatchServer 登録するオブジェクトの多重度
WatchServerを使用する場合、名前サーバに登録するオブジェクトの多重度を1〜10の間で設定します。 多重度に合わせてそのシステムの負荷が分散されます。 アプリケーショングループ、プロセスグループごとに設定する事もできます。 その場合、アプリケーショングループ、プロセスグループの設定が有効になります。

1
状態 アライブチェックモニタの自動登録を行う アライブチェックモニタの自動登録を行います。 行う
状態 監視間隔
アライブチェックモニタの監視間隔を指定します。

30000ミリ秒
状態 イベントを連続発生させる間隔
監視対象リソースがアライブ中でない状態が続く場合にイベントを発生させる間隔です(ミリ秒単位)。 0の場合このイベントは発生しません。

0ミリ秒
状態 状態
システムの状態を表示します。

-
状態 現在のコンポーネント数 システムに登録されているコンポーネント数を表示します。 -
状態 現在のインターフェース数 システムに登録されているインターフェース数を表示します。 -
状態 現在のオペレーション数
システムに登録されているオペレーション数を表示します。 この数値はファクトリオペレーションとWebOTX内部オペレーション (1システムで5+プロセスグループ×6(プロセスグループの種類がJ2EE、CORBA Java(バージョン6以上)の場合7))を含みます。

-
状態 現在のプロセス数 システム内に生成された全プロセス数を表示します。 -
状態 現在のスレッド数
システム内に生成された全スレッド数を表示します。 プロセスグループ内のプロセスごとにWebOTX内部で使用するスレッドが3つあるため、 各プロセスグループで使用するスレッド数は設定したスレッド数+予備スレッド数+3*プロセス数となります。

-
運用アシスタント 運用アシスタント機能を使用する
運用アシスタント機能を使用するか否かを設定します。 Falseにした場合、運用アシスタント機能だけでなく、オペレーションジャーナル情報も使用できなくなります。

使用する
運用アシスタント 最終情報採取時刻
運用アシスタント機能が最後にTPシステムの稼動情報を採取した時間を表示します。

-
運用アシスタント 学習期間
学習期間(分)を設定します。学習期間内は実行時間上限や多重度の自動設定・一括設定を行いません。 学習期間には各業務のデータが十分に採取できる時間を設定してください。 たとえば、週末は負荷が高い業務であれば、学習期間には1週間以上を設定してください。

1440分
運用アシスタント 情報採取間隔
TPシステムの稼動情報採取間隔(分)を設定します。 情報採取間隔を経過するたびにTPシステムの情報を採取し、多重度や実行時間上限の推奨値算出および設定を行います。 また、ここで設定された値はオペレーションジャーナルの最小編集単位となります。

5分
運用アシスタント 実行時間上限推奨値を提示する 実行時間上限推奨値を提示するかどうか設定します推奨値を提示しない場合は実行時間上限自動設定機能も働きません。 する
運用アシスタント 実行時間上限推奨値を更新する
実行時間上限推奨値を更新するかどうか設定します。 「更新する」を設定すると情報採取間隔(「TPシステム」-「情報採取間隔」)ごとに推奨値が更新されます。 推奨値の妥当性を検証したい場合など、推奨値の更新を止めることもできます。

する
運用アシスタント 実行時間上限値 推奨基準
実行時間上限値の推奨基準を設定します。 早期復旧優先を設定した場合は短めの値が、オペレーション継続優先を設定した場合は長めの値が実行時間上限値として推奨されます。

ノーマル
運用アシスタント 実行時間上限推奨値の最小値 実行時間上限推奨値の最小値(秒)を設定しますこれより小さな値が推奨されても、自動設定・一括設定されません。 60秒
運用アシスタント 実行時間上限を自動設定する
実行時間上限を自動設定するかどうか設定します「自動設定する」 をtrueにすると情報採取間隔(「TPシステム」-「情報採取間隔」)ごとに実行時間上限が自動的に更新されます。

する
運用アシスタント スローダウン障害を検出する
スローダウン障害を検出するかどうか設定します。 Trueにすると情報採取間隔(「TPシステム」-「情報採取間隔」)が経過するごとにスローダウン障害が発生していないか調べます。 スローダウン障害の検出は、情報採取間隔内に実行された全てのオペレーションの統計から総合的に判断されます。 スローダウン障害の疑いがあっても、正常動作の可能性が多く残る場合は、スローダウン障害として検出しません。 スローダウン障害を検出すると、イベントログ出力と統合運用管理ツールへの通知が行われます。 スローダウンを検出してすぐに、ログの待避・ジャーナルの待避・イベントジャーナルの編集を行うと障害解析に役立ちます。

する
運用アシスタント スローダウン障害検出基準
スローダウン障害の検出基準を設定します。 スローダウン障害を早期に検出したい場合は「早期検出優先」を設定してください。 正常動作とみなせるオペレーションまでスローダウン障害として検出されてしまう場合は「長め」を設定してください。

ノーマル
運用アシスタント スローダウン継続監視時間
スローダウンを検出してからの経過時間を分単位で監視します。 この時間を過ぎてもスローダウン状態が解消されない場合は「長期にわたるスローダウン」として警告メッセージを出力します。 スローダウンを検出してからの経過時間は、情報採取間隔ごとにチェックされます。 -1を設定した場合は、スローダウンを検出してからの経過時間を監視しません。

20分
運用アシスタント スローダウン時に自動スタックトレースを採取する スローダウン検出時に、自動でスタックトレースを採取するかを設定します。 採取する
運用アシスタント 多重度最適化支援
多重度最適化支援機能の設定を行います。 「推奨通知」を選択した場合、情報採取間隔(「TPシステム」-「情報採取間隔」)が経過するごとに多重度の適正をチェックし、 多重度設定が不適切だと判断すると、その旨をイベントログ出力し、統合運用管理ツールに通知します。 実際の多重度変更はオペレータ判断になります。 「自動変更」を選択した場合、情報採取間隔(「TPシステム」-「情報採取間隔」)が経過するごとに多重度の適正をチェックし、 必要に応じてプロセス数を動的に変更します。 「多重度の適正をチェックしない」を選択すると、多重度の適正をチェックしません。

推奨通知
運用アシスタント 多重度最適化支援:目標応答時間(秒)
多重度最適化支援機能の目標応答時間設定を行います。 現在キューの最後尾で待機しているリクエストが目標応答時間を越える可能性があると予測される場合、 運用アシスタント機能は多重度が不足していると判断します。 リクエストの応答時間の予測は、オペレーションの優先度が同一である場合が想定されています。 目標応答時間は秒単位で設定してください。旧表記は「多重度最適化支援:応答期限(秒)」です。

600秒
運用アシスタント 最大マルチプロセス数
最大マルチプロセス数の設定をします。 運用アシスタントが利用する、プロセス数動的変更時の最大数を1から1000の整数で指定します。 運用アシスタントは、この値を超えて、プロセスグループのプロセス多重度を設定することはありません。

5
運用アシスタント 多重度最適化支援:アイドルCPU使用率(%)
確保すべきアイドルCPU使用率を設定します。 多重度が不足と判断されても、多重度を増加させた場合にアイドルCPU使用率がこの基準を下回ることが予測されるならば、 多重度変更の推奨/自動設定を行いません。 アイドルCPU使用率は%単位で設定してください。

30%
運用アシスタント 多重度最適化支援:多重度を過剰と見なす間隔(分)
多重度最適化支援機能の多重度を過剰と見なす間隔の設定を行います。 プロセス数を減らしてもオペレーション実行に影響を与えない期間がこの時間を超えた場合、 多重度が過剰だと判断されます。旧表記は「多重度最適化支援:多重度過剰期限(分)」です。

1440分
運用アシスタント 多重度最適化支援:予備プロセス数
多重度最適化支援機能の予備プロセス数設定を行います。 ここで設定された予備プロセス数分はプロセス数が過剰であっても、多重度過剰とは判断されません。 障害回避の観点でプロセス数を多めに用意している場合は、こちらを設定してください。

1

7.1.1.3. 起動・停止

統合運用管理ツールから起動・停止
  1. 統合運用管理ツールよりドメインと接続します。
  2. ツリービューよりWebOTXシステム[TPシステム]を選択します。
  3. 右クリックメニューより「システムの起動」あるいは「システムの停止」を実行します。

SystemStart
図7.1.1.3-1

コマンドから起動・停止
  1. otxadminコマンドを起動し、ドメインにログインします。
    otxadmin> login --user admin --password adminadmin --port 6212
    
  2. 起動・停止を実行します。

    起動
    otxadmin> start-system
    
    停止
    otxadmin> stop-system
    

7.1.1.4. 状態

WebOTXシステム(TPシステム)の状態について説明します。

表7.1.1.4-1
状態 アイコンの色 説明
起動処理中 黄色
起動処理中状態です。 起動処理中状態から状態が遷移しない場合は停止を行なってください。 それでも状態が変更しない場合はサービスの再起動を行なってください。

起動中 緑色
起動中状態です。 システムを停止させるときは停止処理により停止することができます。

停止処理中 橙色
停止処理中状態です。 停止処理中状態から遷移しない場合は、もう一度停止を行なってください。 それでも状態が変更しない場合はサービスの再起動を行なってください。

停止 赤色
停止状態です。 システムを起動させるときは起動処理により起動することができます。

起動停止処理失敗 赤色に×印 起動・停止処理に失敗しました。 復旧させるにはサービスの再起動を行なってください。
注意事項

ドメイン起動中(TPモニタ・マネージャライフサイクル起動処理中)にTPシステムの状態チェックコマンドを実行すると、TPモニタ・マネージャライフサイクルの起動に失敗することがあります。 ドメインが起動状態になってから状態チェックを行ってください。

IIOPリスナの状態は、個別に起動停止することはできません。 TPシステムの起動停止に合わせて動作します。 状態に関しては、TPシステムの状態と同じです。 アライブチェックを行うために、TPモニタ・マネージャからIIOPリスナに対してセッションを1本張ります。 このアライブチェックに失敗した場合、起動停止処理失敗となります。

7.1.2. 操作・状態確認(アプリケーショングループ)

7.1.2.1. 作成・削除

統合運用管理ツールから新規作成
  1. 統合運用管理ツールよりドメインと接続します。
  2. ツリービューよりTPシステム配下のアプリケーショングループを選択します。
  3. 右クリックメニューより「アプリケーショングループの新規作成」を実行します。
  4. 新規作成するアプリケーショングループ名を入力し、作成します。

APGSakusei
図7.1.2.1-1

統合運用管理ツールから削除
  1. 統合運用管理ツールよりドメインと接続します。
  2. ツリービューよりTPシステム配下のアプリケーショングループを選択します。
  3. 右クリックメニューより「アプリケーショングループの削除」を実行します。
  4. 削除するアプリケーショングループ名を選択し、削除します。

なお、直接該当アプリケーショングループ名のノードを選択して右クリックメニューより「アプリケーショングループの削除」を実行することもできます。

コマンドから新規作成・削除
  1. otxadminコマンドを起動し、ドメインにログインします。
    otxadmin> login --user admin --password adminadmin --port 6212
    
  2. アプリケーショングループ名を指定して新規作成・削除を実行します。

    新規作成
    otxadmin> create-apg apg
    
    削除
    otxadmin> delete-apg apg
    
注意事項

アプリケーショングループ作成後にドメインのパスを変更することはできません。

7.1.2.2. 設定の変更

統合運用管理ツールから設定
  1. 統合運用管理ツールよりドメインと接続します。
  2. ツリービューより設定を変更するアプリケーショングループを選択します。
  3. リストビューより変更したい項目を選択し、変更します。

APGPropertyChange
図7.1.2.2-1

コマンドから設定
  1. otxadminコマンドを起動し、ドメインにログインします。
    otxadmin> login --user admin --password adminadmin --port 6212
    
  2. 現在設定している値を確認します。
    otxadmin> get tpsystem.applicationGroups.apg.*
    
  3. 変更したい属性を変更します。
    otxadmin> set tpsystem.applicationGroups.apg.applicationGroupAutoStart=true
    
注意事項

アプリケーショングループの各プロパティについては、アプリケーショングループ起動中でも設定は可能ですが、設定内容を反映させるにはアプリケーショングループの再起動が必要です。

7.1.2.3. 設定値の説明

表7.1.2.3-1
タブ表記 項目 説明 既定値
自動起動 システム起動時、アプリケーショングループを自動起動する TPシステムを起動する時、自動的にアプリケーショングループを起動します。 する
WatchServer システムと同様の多重度とする WatchServerを使用する設定をシステム単位ではなく、アプリケーショングループ単位で設定する場合falseにします。 アプリケーショングループ単位で設定せず、システムと同様の設定とする
WatchServer 登録するオブジェクトの多重度
WatchServerを使用する場合、名前サーバに登録するオブジェクトの多重度を設定します。 多重度に合わせてそのシステムの負荷が分散されます。 アプリケーショングループ単位でWatchServerの多重度を設定する場合に設定します。 通常はシステムでの設定値が表示されます。システムの設定より優先されます。

1
キューの最大数 システムと同様の最大数とする キューの最大数設定をアプリケーショングループ単位で設定する場合falseにします。 アプリケーション単位で設定せず、システムと同様の設定とする
キューの最大数 キューの最大数
キューの最大数を設定します。 アプリケーショングループ単位でキューの最大数を設定する場合に設定します。 通常はシステムでの設定値が表示されます。 TPシステムはここで指定した値以上キュー要求をため込まずにオペレーションコールをエラーリターンさせます。 これにより高負荷時の待ち要求の数を制限し、必要以上に負荷をあげ、応答しない状況を回避できます。 -1を指定した場合制限はありません。ここで設定すると、システムの設定よりも優先されます。

-1
初期プロセス アプリケーション初期プロセスを使用する
初期プロセスを利用してアプリケーショングループ開始前に業務トランザクションを使用する場合trueにします。 初期プロセスを使用する場合は以下の項目を設定する必要があります。
・利用言語
・WebOTX AS バージョン
・ライブラリファイル名
・クラス名(Java言語(J2SE)のみ指定)
初期プロセスを含め、アプリケーショングループ全体の起動に時間がかかる場合、アプリケーショングループの起動に失敗します。 既定値では、100秒以上かかってタイムアウトした場合に失敗となります。 この監視時間を変更するためにはシステムTPPの設定を変更する必要があります。

設定しない
初期プロセス 利用言語
初期プロセスを実行するための言語を選択してください。 初期プロセスを使用する場合必ず設定してください。Javaは、全OSで選択可能です。

Java
初期プロセス WebOTX AS バージョン
設定するライブラリファイルのWebOTX AS バージョンを指定してください。 初期プロセスを使用する場合必ず設定してください。 OSがWindows (x86)の場合はバージョン5以上選択可能です。 ただし、利用言語により選択可能バージョンが変わります。 利用言語のヘルプを参照してください。 OSがHP-UX (IPF)、Linux (x86)、Windows (x64)の場合はバージョン6以上が選択可能です。 OSがLinux (x64)の場合はバージョン7以上が選択可能です。

8
初期プロセス ライブラリファイル名
初期プロセス起動時に使用するライブラリファイル名を選択してください。 初期プロセスを使用する場合必ず設定してください。 ライブラリファイルは共有コンポーネントとしてあらかじめ登録されている必要があります。 利用言語の選択を変更すると選択時に表示されるライブラリファイル名リストが変更されます。 選択せずに直接ファイルパスを記述することもできます。

-
初期プロセス クラス名
利用言語がJavaの場合はライブラリファイルのクラス名も指定してください。 その他の言語の場合は指定する必要はありません。

-
初期プロセス アプリケーション引数
初期プロセス起動時の引数を511文字以内で指定してください。 初期プロセスを使用する場合で必要な場合は設定してください。

-
起動/停止 起動タイムアウト
起動タイムアウト値(秒)を設定します。 指定した時間以内に起動要求が完了しない場合、起動要求はタイムアウトします。 ただし起動処理はタイムアウトした後も行いますのでタイムアウトした後に起動が完了する場合があります。 タイムアウトした場合は状態を確認してください。

120秒
起動/停止 停止タイムアウト
停止タイムアウト値(秒)を設定します。 指定した時間以内に停止要求が完了しない場合、停止要求はタイムアウトします。 ただし停止処理はタイムアウトした後も行いますのでタイムアウトした後に停止が完了する場合があります。 タイムアウトした場合は状態を確認してください。

120秒
状態 状態
状態を表示します。

-

7.1.2.4. 起動・停止

統合運用管理ツールから起動・停止
  1. 統合運用管理ツールよりドメインと接続します。
  2. ツリービューより起動・停止するアプリケーショングループを選択します。
  3. 右クリックメニューより「アプリケーショングループの起動」あるいは「アプリケーショングループの停止」を実行します。 強制停止を行う場合は「アプリケーショングループの強制停止」を実行します。

APGKidou
図7.1.2.4-1

コマンドから起動・停止
  1. otxadminコマンドを起動し、ドメインにログインします。
    otxadmin> login --user admin --password adminadmin --port 6212
    
  2. 起動・停止を実行します。

    起動
    otxadmin> start-apg apg
    
    停止
    otxadmin> stop-apg apg
    
    強制停止
    otxadmin> stop-apg --force=true apg
    
強制停止について

停止しようとしているプロセスグループがクライアントからのオペレーション実行中の場合、通常停止処理が失敗(タイムアウト)する場合があります。 通常停止を行なっても停止できない場合は強制停止を行なって停止させてください。 なお、強制停止を行なった場合実行中の処理は強制的に終了させますので、処理の保証は行なえません。 したがって強制停止は通常停止が行なえない場合に限り利用ください。

7.1.2.5. 状態

アプリケーショングループの状態について説明します。

表7.1.2.5-1
状態 アイコンの色 説明
起動処理中 黄色
起動処理中状態です。 起動処理中状態から状態が遷移しない場合は停止を行なってください。 それでも状態が変更しない場合は強制停止を行なってください。

起動中 緑色
起動中状態です。 アプリケーショングループを停止させるときは停止処理により停止することができます。 起動中状態であるアプリケーショングループについては、強制停止をできるだけ行なわないでください。 強制停止を行ないますと正常に終了処理が行なわれない場合があります。

停止処理中 橙色
停止処理中状態です。 停止処理中状態から遷移しない場合は、もう一度停止を行なってください。 それでも状態が変更しない場合は強制停止を行なってください。

停止 赤色
停止状態です。 アプリケーショングループを起動させるときは起動処理により起動することができます。

起動停止処理失敗 赤色に×印 起動・停止処理に失敗しました。 復旧させるには強制停止を行なってください。
クライアント接続中 水色
起動中状態であり、クライアントがそのアプリケーショングループに接続しています。 アプリケーショングループを停止させるときは停止処理により停止することができます。 停止した場合、接続しているクライアントにはエラーが返却されます。 起動中状態であるアプリケーショングループについては、強制停止をできるだけ行なわないでください。 強制停止を行ないますと正常に終了処理が行なわれない場合があります。

7.1.3. 操作・状態確認(プロセスグループ)

7.1.3.1. 作成・削除

統合運用管理ツールから新規作成
  1. 統合運用管理ツールよりドメインと接続します。
  2. ツリービューよりアプリケーショングループ配下のプロセスグループを選択します。
  3. 右クリックメニューより「プロセスグループの新規作成」を実行します。
  4. 新規作成するプロセスグループ名を入力し、WebOTXバージョンとモジュールの種類を選択して作成します。

PGSakusei
図7.1.3.1-1

モジュールの種類は以下の通りです。 コマンド指定時文字列は、運用管理コマンドからプロセスグループを作成するときに指定します。

表7.1.3.1-1
モジュールの種類 コマンド指定時文字列 説明
Java EE javaee
Java EEアプリケーションを配備する場合に作成します。 バージョンは8となります。

CORBA Java corbajava
CORBA Javaアプリケーションを配備する場合に作成します。
  • OSがHP-UX (IPF64)、Windows (x64)の場合
    バージョン6以上選択時のみ作成可能です。
  • OSがLinux (x64)、Solarisの場合
    バージョン7以上選択時のみ作成可能です。
  • OSがLinux (x86)の場合
    バージョン8以上選択時のみ作成可能です。
  • それ以外のOS
    全バージョンで作成可能です。
CORBA C++ cpp
CORBA C++アプリケーションを配備する場合に作成します。
  • OSがHP-UX (IPF64), Windows (x64)の場合
    バージョン6以上選択時のみ作成可能です。
  • OSがLinux (x64)、Solarisの場合
    バージョン7以上選択時のみ作成可能です。
  • OSがLinux (x86)の場合
    バージョン8以上選択時のみ作成可能です。
Windows (x86)の場合は、バージョン5のみ作成可能です。 Microsoft Visual C++ 6.0を用いて作成した CORBA C++アプリケーションを配備する場合はこちらを指定してください。
Windows (x64)の場合は、バージョン6〜8.2のみ作成可能です。 Platform SDK for Windows Server 2003 R2を用いて作成したCORBA C++アプリケーションを配備する場合はこちらを指定してください。

CORBA VC++ 2010 vc2010
Microsoft Visual C++ 2010を用いて作成した CORBA C++アプリケーションを配備する場合に作成します。 バージョン8選択時、OSがWindowsのみ作成可能です。

CORBA VC++ 2008 vc2008
Windows SDK for Windows Server 2008、Microsoft Visual C++ 2008を用いて作成した CORBA C++アプリケーションを配備する場合に作成します。 バージョン8選択時、OSがWindowsのみ作成可能です。

CORBA VC++ 2005 vc2005
Microsoft Visual C++ 2005を用いて作成した CORBA C++アプリケーションを配備する場合に作成します。 バージョン6以上選択時、OSがWindowsのみ作成可能です。

CORBA VC++ .NET 2003 vc2003
Microsoft Visual C++ .NET 2003 を用いて作成した CORBA C++アプリケーションを配備する場合に作成します。 バージョン5以上選択時、OSがWindows(x86)のみ作成可能です。

CORBA VC++ .NET 2002 vcdotnet
Microsoft Visual C++ .NET 2002 を用いて作成したCORBA C++アプリケーションを配備する場合に作成します。 バージョン5選択時、OSがWindows (x86)のみ作成可能です。

統合運用管理ツールから削除
  1. 統合運用管理ツールよりドメインと接続します。
  2. ツリービューよりアプリケーショングループ配下のプロセスグループを選択します。
  3. 右クリックメニューより「プロセスグループの削除」を実行します。
  4. 削除するプロセスグループ名を選択し、削除します。

なお、直接該当プロセスグループ名のノードを選択して右クリックメニューより「プロセスグループの削除」を実行することもできます。

コマンドから新規作成・削除
  1. otxadminコマンドを起動し、ドメインにログインします。
    otxadmin> login --user admin --password adminadmin --port 6212
    
  2. プロセスグループ名を指定して新規作成・削除を実行します。 新規作成時はWebOTXバージョンとモジュールの種類も設定します。 モジュールの種類は前述の通りです。

    新規作成
    otxadmin> create-pg --version 8 --kind javaee --apgroup apg pg
    
    削除
    otxadmin> delete-pg --apgroup apg pg
    
注意事項

プロセスグループの作成、削除は、アプリケーショングループ起動中の場合は実行できません。 アプリケーショングループを停止して実行してください。

7.1.3.2. 設定の変更

統合運用管理ツールから設定
  1. 統合運用管理ツールよりドメインと接続します。
  2. ツリービューより設定を変更するプロセスグループを選択します。
  3. リストビューより変更したい項目を選択し、変更します。

PGPropertyChange
図7.1.3.2-1

コマンドから設定
  1. otxadminコマンドを起動し、ドメインにログインします。
    otxadmin> login --user admin --password adminadmin --port 6212
    
  2. 現在設定している値を確認します。
    otxadmin> get tpsystem.applicationGroups.apg.processGroups.pg.*
    
  3. 変更したい属性を変更します。
    otxadmin> set tpsystem.applicationGroups.apg.processGroups.pg.processCount=1
    
  4. リストのように配列指定する場合は、{{変数1,値1},{変数2,値2},...}として指定します。
    otxadmin> set tpsystem.applicationGroups.apg.processGroups.pg.javaSystemPropertyList={{var1,value1},{var2,value2}}
    
注意事項

プロセスグループの各プロパティについては、アプリケーショングループ起動中でも設定は可能ですが、設定内容を反映させるにはアプリケーショングループの再起動が必要です。

7.1.3.3. 設定値の説明

表7.1.3.3-1
タブ表記 項目 説明 既定値
基本設定 モジュールの種類
モジュールの種類を表示します。 プロセスグループ作成時に登録するアプリケーションの種別を指定します。作成後変更は出来ません。

-
基本設定 WebOTX AS バージョン
モジュールのWebOTX AS バージョンを表示します。 プロセスグループ作成時に登録するアプリケーションをビルドしたWebOTX AS バージョンを指定します。 作成後変更は出来ません。

-
基本設定 アプリケーショングループ起動時、プロセスグループを起動する。
プロセスグループの自動起動設定をします。

する
Java非同期メッセージ 非MDBのJava非同期メッセージを使用します。 非MDBのJava非同期メッセージを使用します。 使用しない
トレース設定 トレースレベル
プロセスグループ上で動作するサーバアプリケーションログのトレースレベルを指定します。 -1を指定した場合は採取しません。以下にトレースレベルの説明をします。
0 パニック状態
1 データベースが壊れているなど即時に訂正すべきである状態
2 ハードウェア、デバイスエラーのような危急の状態
3 一般的なエラー
4 警告メッセージ
5 通知メッセージ
6 情報メッセージ
7 デバッグ時のメッセージ

5
トレース設定 トレースファイル最大サイズ
プロセスグループ上で動作するサーバアプリケーションログのトレースファイルの最大サイズをKB単位で指定します。 最大サイズを超えると、既存の情報はバックアップ(トレースファイル名).bakに待避し、新規にトレースファイルを作成します。

1024KB
トレース設定 システムトレースファイル最大サイズ
プロセスグループ上で動作するサーバアプリケーションログのシステムトレースファイルの最大サイズをKB単位で指定します。 最大サイズを超えると、既存の情報はバックアップ(システムトレースファイル名).bakに待避し、新規にシステムトレースファイルを作成します。

1024KB
トレース設定 標準出力の出力先
サーバアプリケーションの標準出力をトレースファイルに追加するかどうか設定します。 トレースに統合される場合、(プロセスグループ名).(プロセスID).logに出力されます。

する
トレース設定 標準エラー出力の出力先
サーバアプリケーションの標準エラー出力をトレースファイルに追加するかどうか設定します。 トレースに統合される場合、(プロセスグループ名).(プロセスID).logに出力されます。

する
プロセス制御 プロセス数
マルチプロセスで動作させる場合のプロセス数を設定します。 マルチプロセスで動作させない場合は、プロセス数は1です。 マルチスレッドで動作しない場合は、プロセス数が同時に処理できるコマンド数になります。 プロセスを分割することにより、 プロセス障害が発生したときの障害の影響範囲をそのプロセスが使用しているクライアントだけに限定することができます。 TPシステム内の全プロセス数が【システムパラメータ】の最大プロセス数の上限を超えない範囲で設定可能です。 動的多重度変更時のプロセス上限値でもあります。

1
プロセス制御 プロセスの優先度
プロセスを優先順位制御(固定優先度制御、Linuxのみ変動優先度制御)の対象とするときに指定します。 未指定、LOW、BELOW、MIDDLE、ABOVE、HIGHで指定します。 LOW、BELOW、MIDDLE、ABOVE、HIGHの順に優先度が高くなります。 未指定を指定した場合は、プロセス優先度制御を使用しません。 Solaris、HP-UX、Linuxは、OSの制限によりスーパーユーザでないとプロセスの優先度を変更できません。 本機能の利用には、スーパーユーザによるWebOTXの起動が必要となります。 Windowsでは、障害発生時にタスクマネージャからプロセスが強制終了できなくなることを防ぐため、優先度をHIGHに設定できません。 各プラットフォームのプロセス優先度値のマッピングは以下の通りです。
Windows:ABOVE 10、MIDDLE 8、BELOW 6、LOW 4
Solaris:HIGH 60、ABOVE 45、MIDDLE 30、BELOW 15、LOW 0
HP-UX:HIGH 178、ABOVE 198、MIDDLE 217、BELOW 236、LOW 255
Linux:HIGH -20、ABOVE -10、MIDDLE 0、BELOW 10、LOW 19

未指定
プロセス制御 動的設定変更時初期化待ち時間 動的設定変更時の初期化待ち時間を設定します。 600秒
プロセス制御 動的設定変更時終了待ち時間 動的設定変更時の終了待ち時間を設定します。 600秒
プロセス制御 リカバリプロセスを起動する リカバリプロセスはプロセスが異常終了した場合、正常停止時に行う名前サーバからのオブジェクトリファレンス削除が行われません。 このオブジェクトリファレンスを削除する為に起動するプロセスです。 配備したアプリケーションと「名前サーバへの登録」の設定内容を確認して適切な設定を行ってください。 Webアプリケーションの場合、またはEJB / CORBAアプリケーションの「名前サーバへの登録」を"永続的に扱う"としている場合、「起動しない」に設定することを推奨します。 EJB / CORBAアプリケーションの「名前サーバへの登録」を"一時的に扱う"としている場合、必ず「起動する」に設定してください。 起動する
スレッド制御 スレッド数
サーバプロセスのスレッド数を指定します。 この値と予備スレッド数を足した値が動的多重度変更時のスレッド上限値になります。 指定したスレッド数の他に、WebOTX内部で使用するスレッド3つが動作します。 そのため、プロセスグループで動作する全スレッドは、プロセス数*(スレッド数+予備スレッド数+3)となります。 TPシステム内の全プロセスグループの合計スレッド数(WebOTX内部で使用するスレッド含む)が、 TPシステムの属性【システムパラメータ】の最大スレッド数を超えない範囲で設定可能です。

1
スレッド制御 スレッドスタックサイズ
スレッド1つあたりのスタックサイズ(KB)を指定します。 スタックサイズの不足が原因でプロセスが異常終了する場合には、スタックサイズを増やしてください。

1000KB
スレッド制御 スレッド初期化時間
スレッド初期化処理の応答時間を秒単位で1以上を指定します。 この時間以内にアプリケーションの初期化処理が終了しない場合は、プロセス起動に失敗します。

600秒
スレッド制御 オペレーション異常終了時にオペレーションを閉塞させる
オペレーション実行中にアボートが発生した場合、自動的にそのオペレーションを閉塞状態にするかどうかを指定します。 閉塞状態にすることにより、WebOTXシステム全体を停止することなく、障害の影響が拡大することを防ぐことができます。

しない
スレッド制御 予備スレッド数
予備スレッド数を指定します。この値とスレッド数を足した値が動的多重度変更時のスレッド上限値になります。 予備スレッドを使用する場合は、動的多重度変更を行って下さい。

0
非同期オペレーション呼び出し 非同期オペレーション呼び出しを行う
CORBAアプリケーションを配備した場合、 このプロセスグループから他のプロセスグループへ非同期オペレーション呼び出し (トランザクション型VDを用いた非同期オペレーション呼び出し)を行いたい場合はtrueにしてください。 当プロセスグループ内から他のオペレーションをVD経由で非同期に呼び出すことができます。 詳細は [ 7.1.7.6. 非同期トランザクション ] を参照してください。

行わない
キューの最大数 アプリケーショングループと同様の最大数とする キューの最大数設定をプロセスグループ単位で設定する場合falseにします。 プロセス単位で設定せず、システムと同様の設定とする
キューの最大数 キューの最大数
キューの最大数を設定します。 プロセスグループ単位でキューの最大数を設定する場合に設定します。 通常はアプリケーショングループでの設定値が表示されます。 TPシステムはここで指定した値以上キュー要求をため込まずにオペレーションコールをエラーリターンさせます。 これにより高負荷時の待ち要求の数を制限し、必要以上に負荷をあげ、応答しない状況を回避できます。 ここで設定すると、システム、アプリケーショングループの設定よりも優先されます。

-
Transaction Service Transaction Service連携を行う
Transaction Service連携を行う場合、trueにしてください。 EJBコンポーネントでは最初から「連携を行う」になっています。 EJBコンポーネントの場合はTransaction Service連携が必須となっています。 Transaction Serviceとの連携を行う場合、Transaction Service RecoveryServerとのコネクションが常に張られた状態になります。 また、この時ライセンスを1つ消費します。手動で切断しないようにしてください。 詳細は [ 7.1.7.7. Transactionサービス連携 ] を参照してください。

行わない
Transaction Service トランザクションの制御
Transaction Service連携を行う場合のトランザクション制御方式を設定します。
Recovery Coordination Server:Recovery Coordination Server を使用してアプリケーションと同一のプロセス空間でトランザクション処理を実行します。
RecoveryServer:RecoveryServerを使用してトランザクション処理を実行します。

Recovery Coordination Server
Transaction Service RCSID
Transaction Service連携を行う場合、RCSIDを指定します。 Recovery Coordination Server を使用する時はRCSIDの選択もしてください。 RCSIDはあらかじめTransaction Serviceに設定されている必要があります。 EJBのときはRCSIDを選択しないことも可能です。

-
Transaction Service OTSポリシ
Transaction Service連携を行うときのOTSポリシの選択をします。 ADAPTS オブジェクトはトランザクション内でもトランザクション外でも動作できます。 REQUIRES オブジェクトは必ずトランザクション内で動作する必要があります。 FORBIDS オブジェクトは必ずトランザクション外で動作する必要があります。

ADAPTS
ESB ESB JBIコンテナの起動
Java EEアプリケーションを配備した場合、JBIコンテナを起動するかどうかを設定します。 trueにした場合、プロセスグループ起動時にJBIコンテナも起動します。 falseにした場合、プロセスグループ起動時にJBIコンテナを起動しません。 この設定は、インストール時にWebコンテナの動作モードをアドバンスドモードにしたときに有効になります。 スタンダードモード(旧互換モード)にした場合、設定は有効になりません。

行わない
起動/停止 起動タイムアウト
起動タイムアウト値(秒)を設定します。 指定した時間以内に起動要求が完了しない場合、起動要求はタイムアウトします。 ただし起動処理はタイムアウトした後も行いますのでタイムアウトした後に起動が完了する場合があります。 タイムアウトした場合は状態を確認してください。

120秒
起動/停止 停止タイムアウト
停止タイムアウト値(秒)を設定します。 指定した時間以内に停止要求が完了しない場合、停止要求はタイムアウトします。 ただし停止処理はタイムアウトした後も行いますのでタイムアウトした後に停止が完了する場合があります。 タイムアウトした場合は状態を確認してください。

120秒
WatchServer アプリケーショングループと同様の多重度とする WatchServerを使用する設定をシステム単位ではなく、アプリケーショングループ単位で設定する場合falseにします。 プロセスグループ単位で設定せず、アプリケーショングループと同様の設定とする
WatchServer 登録するオブジェクトの多重度
WatchServerを使用する場合、名前サーバに登録するオブジェクトの多重度を1〜10の間で設定します。 プロセスグループ単位でWatchServerの多重度を設定する場合に設定します。 通常はアプリケーショングループでの設定値が表示されます。 多重度に合わせてそのシステムの負荷が分散されます。システム、アプリケーショングループの設定より優先されます。

1
コマンドライン引数 コマンドライン引数
プロセスに渡すためのコマンドライン引数を指定します。 先頭に'#',';'は使用できません。 例えば、データベースにプロセスグループから直接コネクションをはる場合に、SID、ユーザ名、パスワードなどを指定して、 プロセスグループで使用する事ができます。

<アプリケーショングループ名>-<プロセスグループ名>
JavaVMオプション 最大ヒープサイズ
最大ヒープサイズを指定します。 -1はJavaVMの既定値になります。 指定する値は、2メガバイトより大きくしてください。 また、バイトで指定するときは 1024 の倍数にしなければなりません。 初期ヒープサイズ(初期ヒープサイズをfalseにしているときは、JavaVMの既定初期ヒープサイズ)以上の値を指定してください。 旧表記は「ヒープの最大サイズ」です。

-1
JavaVMオプション 最大ヒープサイズの単位
最大ヒープサイズの単位を指定します。 単位は、キロバイトなら‘k’、メガバイトなら‘m’、バイトなら‘-’で指定してください。

m
JavaVMオプション 初期ヒープサイズ
初期ヒープサイズを指定します。 -1はJavaVMの既定値になります。 指定する値は、1メガバイトより大きくしてください。 また、バイトで指定するときは 1024 の倍数にしなければなりません。 最大ヒープサイズ(最大ヒープサイズをfalseにしているときは、JavaVMの既定最大ヒープサイズ)以下の値を指定してください。 旧表記は「ヒープの初期サイズ」です。

32
JavaVMオプション 初期ヒープサイズの単位
初期ヒープサイズの単位を指定します。 単位は、キロバイトなら‘k’、メガバイトなら‘m’、バイトなら‘-’で指定してください。

m
JavaVMオプション スタックトレース採取時にJavaヒープの情報を採取する
アプリケーションプロセスでOutOfMemoryErrorが発生した時に、スタックトレースとJavaヒープの情報を採取します。 Javaヒープの情報には、クラス名やオブジェクトサイズ合計、オブジェクト数などが含まれます。 また、Ctrl+Break, SIGQUIT受信時にもヒープに生存している全オブジェクトのJavaヒープの情報を採取します。 採取した情報はクラスごとのオブジェクトサイズの合計の降順でソートを行い、 標準出力に出力します(トレース設定の既定値では、標準出力はプロセスグループのトレースにマージされて出力されます)。

採取する
JavaVMオプション Javaヒープの情報採取時に何位の情報まで出力するか
アプリケーションプロセスでJavaヒープの情報を採取する設定になっている場合、 Javaヒープの情報を表示する時に、第何位の情報まで出力するかを設定します。 既定値では、クラスごとのオブジェクトサイズの合計の降順でソートしたものの上位20位までを出力します。

20
JavaVMオプション OutOfMemoryErrorの監視を行う OutOfMemoryError発生抑止の監視を行うかを選択します。 監視する
JavaVMオプション メモリ使用量閾値 (Old領域)
JavaヒープメモリのOld領域に対する割合を設定します。 0を設定した場合、監視を行いません。 閾値を超過するとAPトレースにメモリ情報が出力され (ログレベルは「6.情報メッセージ」以上)、「メモリ使用量閾値の超過時GCを行う」の設定に従い、GC要求が行われます。 GCの実行はJavaVMに依存します。

0%
JavaVMオプション メモリ使用量閾値 (Permanent領域)
JavaヒープメモリのPermanent領域に対する割合を設定します。 0を設定した場合、監視を行いません。 閾値を超過するとAPトレースにメモリ情報が出力され (ログレベルは「6.情報メッセージ」以上)、「メモリ使用量閾値の超過時GCを行う」の設定に従い、GC要求が行われます。 GCの実行はJavaVMに依存します。

0%
JavaVMオプション メモリ使用量閾値の超過時GCを行う Old領域及びPermanent領域のメモリ使用量が閾値を超えた際、GC要求を行います。 GCを行う
JavaVMオプション GC後メモリ使用量閾値
JavaヒープメモリのOld領域に対する割合を設定します。 0を設定した場合、監視を行いません。 「GC後メモリ使用量閾値の超過時プロセス停止を行う」場合、 プロセス停止時にトレースレベル「6.情報メッセージ」以上でAPトレースとシステムトレースにメモリ情報が出力されます。 「GC後メモリ使用量閾値の超過時プロセス停止を行わない」場合、 GC後のメモリ使用量閾値超過時にトレースレベル「6.情報メッセージ」以上で、 APトレースにメモリ情報、システムトレースにFullthreaddumpが出力されます。

97%
JavaVMオプション GC後メモリ使用量閾値の超過時プロセス停止を行う GC後のOld領域に対してのメモリ使用量が閾値を超えた際、プロセス停止を行います。 プロセス停止を行う
JavaVMオプション その他の引数
引数を2550文字以内で設定します。引数を空白で区切って設定してください。
例: -Xrs -Xcheck:jni
-XbootclasspathはWebOTXで内部的に使用しているので設定できません。 また、-Xdebugはサポートしていません。 ダブルクォーテーションで括られた文字列は一つの文字列とみなします。 引数中に区切り以外で空白を用いる場合(パス名など)はダブルクォーテーションで括ってください。 また、\\に続くダブルクォーテーションや\\はそのまま文字として表現されます。

-
JavaVMオプション プロセス固有指定を行う
プロセス毎にJavaVMオプションを指定する場合に指定します。 本設定が有効となっている場合のみプロセス毎に固有の設定が行えます。

固有指定しない
JavaVMオプション プロセス固有の引数
プロセス毎に指定された引数を設定する場合に指定します。 引数を1023文字以内で設定します。引数を空白で区切って設定してください。1プロセスにつき1行が割り当てられます。プロセス多重度×2の範囲でオプションを設定可能です。
例: -Xrs -Xcheck:jni
-XbootclasspathはWebOTXで内部的に使用しているので設定できません。 また、-Xdebugはサポートしていません。 ダブルクォーテーションで括られた文字列は一つの文字列とみなします。 引数中に区切り以外で空白を用いる場合(パス名など)はダブルクォーテーションで括ってください。 また、\\に続くダブルクォーテーションや\\はそのまま文字として表現されます。
注意事項)
プロセス多重度に対してプロセス固有の引数が不足する場合、不足したプロセスにプロセス固有の引数は設定しません。 プロセス多重度に対してプロセス固有の引数が余剰している場合、定義した順番に利用します。 プロセス異常終了、動的設定変更、動的多重度変更によるプロセス再起動の場合、どのプロセスに対してどのプロセス固有の引数が設定されるか不定です。 この場合アプリケーションのログファイル${PGNAME}_sys.${PID}.logを参照することでプロセス固有の引数を確認することができます。

-
リソース 使用するデータソースリスト
Java EEアプリケーションを配備した場合、プロセスグループの起動時にロードするデータソースのリストを表示します。 そのプロセスグループ上で動作するEJBが使用するデータソースのJNDI名を選択してください。

-
リソース 使用するコネクタリソースリスト
Java EEアプリケーションを配備した場合、プロセスグループの起動時にロードするコネクタリソースのリストを表示します。 そのプロセスグループ上で動作するEJBが使用するコネクタリソースのJNDI名を選択してください。

-
リソース 使用するリソースアダプタリスト
Java EEアプリケーションを配備した場合、プロセスグループの起動時にロードするリソースアダプタのリストを表示します。 そのプロセスグループ上で動作するEJBが使用するリソースアダプタの名前を選択してください。

-
データソース 使用するデータソースリスト
CORBA Javaアプリケーションを配備した場合、 現在そのシステムに設定されているデータソースのプロパティファイルリストを表示します。 そのプロセスグループで使用するデータソースのプロパティファイル名を選択してください。

-
データベースプロセス定義 データベース(ORACLE)を使用する
CORBA C++アプリケーションを配備した場合、WebOTXのデータベース連携機能を利用するかの設定を行います。 WebOTXで自動制御のサポートをするのはORACLEをPro*Cで利用する場合のみです。 アプリケーション内で例外発生した場合はOnTPSAbort()を呼ぶ前にロールバックを行います。 Linux x64では設定できません。

利用しない
データベースプロセス定義 SID
CORBA C++アプリケーションを配備してWebOTXのデータベース連携機能を利用する場合、ORACLEのSIDの設定をします。 WebOTXは指定されたSID名のORACLEと自動接続します。

-
データベースプロセス定義 ユーザ名
CORBA C++アプリケーションを配備してWebOTXのデータベース連携機能を利用する場合、 接続するときに使用するORACLEのユーザ名の設定をします。

-
データベースプロセス定義 パスワード
CORBA C++アプリケーションを配備してWebOTXのデータベース連携機能を利用する場合、 接続するときに使用するORACLEのパスワードの設定をします。

-
データベースプロセス定義 SQL Netを使用する
CORBA C++アプリケーションを配備してWebOTXのデータベース連携機能を利用する場合、 SQL Net経由でデータベースを使用するかどうかを設定します。

しない
データベースコネクションプーリング コネクションプーリングを行う
ODBCドライバVersion 3.0以上を使用してデータベースをアクセスするときに、 コネクションプーリングの機能を使用するかどうか指定します。 TrueにするとWebOTXは自動的にコネクションプーリング機能を使用します。

利用しない
常駐オブジェクト 常駐オブジェクトを使用する
CORBAアプリケーションを配備した場合、常駐オブジェクトを利用するかどうかの設定を行います。 詳細は [ 7.1.7.2. 常駐オブジェクト ] を参照してください。

しない
Javaシステムプロパティ Javaシステムプロパティ
Javaシステムプロパティを設定します。 プロパティに空白は使用できません。 java.class.path, org.omg.CORBA.ORBClass, org.omg.CORBA.ORBSingletonClassはWebOTX内部で使用しているため設定できません。 既定値として設定されているプロパティは、統合運用管理ツールの既定値ボタンを押したときは再設定されません。 手動で設定しなおす必要があります。

-
環境変数 環境変数
環境変数を設定します。変数に空白は使用できません。 TPM_ 、WOTX_ から始まる変数はWebOTX内部で使用しているため設定できません。 変数と値を足して1008バイトをこえないように設定して下さい。 環境変数を展開する場合、Windows Unix 共に「%変数名%」のように指定します。「$」は使用できません。 また展開したとき、文字の合計が4044を超えるとエラーとなります。 登録できる環境変数の種類は50個までです。

-
アプリケーションリスト 登録されているアプリケーション プロセスグループに登録されているアプリケーションリストです。 -
動作情報 スレッド情報
プロセスグループの現在のスレッドの情報を表示します。 WebOTX内部で利用するメインスレッド(MAIN)、受信スレッド(RECV)、送信スレッド(SEND)も表示します。
pid:プロセスID
tid:スレッドID
thno:論理スレッド番号
状態:スレッドの動作状態
モジュール:オペレーション実行中の場合、モジュール名を表示
インタフェース:オペレーション実行中の場合、インタフェース名を表示
オペレーション:オペレーション実行中の場合、オペレーション名を表示
経過時間:オペレーション実行中の場合、その経過時間を表示
クライアント:オペレーション実行中の場合、クライアントIPアドレスを表示
ユーザCPU時間:スレッドのユーザモードCPU時間を表示(ミリ秒)
システムCPU時間:スレッドのシステムモードCPU時間を表示(ミリ秒)
CPU使用率:現在のCPU使用率(%)
情報採取間隔:スレッド情報の採取間隔(ミリ秒)

-
動作情報 プロセス情報
プロセスグループのプロセス情報を表示します。
pid:プロセスID
CPU使用率:現在のCPU使用率(%)
CPU時間:現在までのトータルCPU時間(ミリ秒)
ユーザCPU時間:現在までのトータルユーザCPU時間(ミリ秒)
システムCPU時間:現在までのトータルシステムCPU時間(ミリ秒)
コンテナ状態:コンテナの状態
次の状態をとります
APINIT:プロセス起動処理中
CONFREAD:設定ファイル読み込み中
CREJVM:JavaVM起動処理中
LOAD:コンポーネント読み込み中
ORBINIT:ORB初期化中
OBJCRE:サーバオブジェクト作成中
APINIT_E:スレッド起動処理準備中
THINIT:スレッド起動処理中
RESICRE:常駐オブジェクト作成中
ACT:起動状態
THTERM:スレッド停止処理中
RESIDEL:常駐オブジェクト削除中
OBJDEL:サーバオブジェクト削除中
THTERM_E:スレッド停止処理中
APTERM:プロセス停止処理中
UNLOAD:コンポーネントアンロード中
DESJVM:JavaVM終了処理中
TERM:停止状態
仮想メモリ使用量:Windowsの場合はページングファイル使用サイズ、HP-UXの場合はプロセス全体の仮想メモリの合計、 Linuxの場合はVmSizeとなります(KB)。 Solarisは対応していません。 物理メモリ使用量:Windowsの場合はワーキングセットサイズ、HP-UXの場合は常駐メモリサイズ、Linuxの場合はVmRSSとなります(KB)。 Solarisは対応していません。

-
状態 状態
状態を表示します。

-
状態 プロセスグループアイドル時間
プロセスグループに登録されたアプリケーションのアイドル時間のうち最小のものを表示します(単位:秒)。 アプリケーションが登録されていない場合は0が表示されます。

-
状態 動的設定変更状態
動的設定変更状態を表示します。

-
運用アシスタント スローダウン継続時間
配下のオペレーションのスローダウン継続時間の最大値を表示します。 配下の全てのオペレーションがノーマル状態の場合は、-1が表示されます。表示は情報採取間隔ごとに更新されます。

-
運用アシスタント スローダウン継続監視時間
スローダウンを検出してからの経過時間を分単位で監視します。 この時間を過ぎてもスローダウン状態が解消されない場合は「長期にわたるスローダウン」として警告メッセージを出力します。 スローダウンを検出してからの経過時間は、情報採取間隔ごとにチェックされます。 -1を設定した場合は、スローダウンを検出してからの経過時間を監視しません。

20分
運用アシスタント アプリケーショングループと同様の監視時間とする
スローダウン継続監視時間の設定をプロセスグループ単位に行うかどうかを設定します。 ここで設定すると、システム、アプリケーショングループの設定よりも優先されます。

プロセスグループ単位で設定せず、アプリケーショングループと同様の設定とする
運用アシスタント 多重度過剰期間
現在の多重度過剰期間です。

-
運用モジュールログレベル JDBC Data Source
JDBC Data Sourceモジュールのログレベルを設定します。

-
運用モジュールログレベル JMS
JMSモジュールのログレベルを設定します。

-
運用モジュールログレベル JTA
JTAモジュールのログレベルを設定します。

-
運用モジュールログレベル EJB Container
EJB Containerモジュールのログレベルを設定します。

-
運用モジュールログレベル Web Container
Web Containerモジュールのログレベルを設定します。

-
運用モジュールログレベル Object Broker Java Library
Object Broker Java Libraryモジュールのログレベルを設定します。

-
運用モジュールログレベル Object Broker Java Message
Object Broker Java Messageモジュールのログレベルを設定します。

-
上限設定 同時受付オペレーション数
プロセスグループで同時に受け付けるオペレーション数を指定します。

-1

7.1.3.4. 起動・停止

統合運用管理ツールから起動・停止
  1. 統合運用管理ツールよりドメインと接続します。
  2. ツリービューより起動・停止するプロセスグループを選択します。
  3. 右クリックメニューより「起動」あるいは「停止」を実行します。 強制停止を行う場合は「プロセスグループの強制停止」を実行します。

PGKidou
図7.1.3.4-1

コマンドから起動・停止
  1. otxadminコマンドを起動し、ドメインにログインします。
    otxadmin> login --user admin --password adminadmin --port 6212
    
  2. 起動・停止を実行します。

    起動
    otxadmin> start-pg --apgroup apg pg
    
    停止
    otxadmin> stop-pg --apgroup apg pg
    
    強制停止
    otxadmin> stop-pg --apgroup apg --force=true pg
    
強制停止について

停止しようとしているプロセスグループがクライアントからのオペレーションが実行中の場合、通常停止処理が失敗(タイムアウト)する場合があります。 通常停止を行なっても停止できない場合は強制停止を行なって停止させてください。 なお、強制停止を行なった場合実行中の処理は強制的終了させますので、処理の保証は行なえません。 したがって強制停止は通常停止が行なえない場合に限り利用ください。

7.1.3.5. 状態

プロセスグループの状態について説明します。

表7.1.3.5-1
状態 アイコンの色 説明
起動処理中 黄色
起動処理中状態です。 起動処理中状態から状態が遷移しない場合は停止を行なってください。 それでも状態が変更しない場合は強制停止を行なってください。

起動中 緑色
起動中状態です。 プロセスグループを停止させるときは停止処理により停止することができます。 起動中状態であるアプリケーショングループについては、強制停止をできるだけ行なわないでください。 強制停止を行ないますと正常に終了処理が行なわれない場合があります。

停止処理中 橙色
停止処理中状態です。 停止処理中状態から遷移しない場合は、もう一度停止を行なってください。 それでも状態が変更しない場合は強制停止を行なってください。

停止 赤色
停止状態です。 プロセスグループを起動させるときは起動処理により起動することができます。

オペレーション実行中 水色
起動中状態であり、クライアントがそのプロセスグループのオペレーションを実行しています。 プロセスグループを停止させるときは停止処理により停止することができます。 停止した場合、接続しているクライアントにはエラーが返却されます。 起動中状態であるプロセスグループについては、強制停止をできるだけ行なわないでください。 強制停止を行ないますと正常に終了処理が行なわれない場合があります。

リカバリ処理中 橙色
プロセスが例外や実行時間上限オーバにより異常終了した場合、また強制停止を行い、プロセスが停止要求に応答しない場合にリソースを解放するために行なうリカバリ処理中状態です。 リカバリ処理中状態では60秒経過すると停止状態となります。

7.1.4. 操作・状態確認(モジュール)

7.1.4.1. 設定の変更

統合運用管理ツールから設定
  1. 統合運用管理ツールよりドメインと接続します。
  2. ツリービューより設定を変更するモジュールを選択します。
  3. リストビューより変更したい項目を選択し、変更します。

ModulePropertyChange
図7.1.4.1-1

コマンドから設定確認
  1. otxadminコマンドを起動し、ドメインにログインします。
    otxadmin> login --user admin --password adminadmin --port 6212
    
  2. 現在設定している値を確認します。
    otxadmin> get applications.j2ee-applications.ShopApp.ShopApp.ear.*
    
  3. 変更したい属性を変更します。
    otxadmin> set applications.j2ee-applications.ShopApp.ShopApp.ear.sharedComponentList=shareApp
    
注意事項

モジュールの各プロパティについては、プロセスグループ起動中でも設定は可能ですが、設定内容を反映させるにはプロセスグループの再起動が必要です。

7.1.4.2. 設定値の説明

表7.1.4.2-1
タブ表記 項目 説明 既定値
コンポーネント初期化関数 コンポーネント初期化関数
CORBAアプリケーション配備時、コンポーネント初期化関数(Javaの場合は初期化クラス)を1023文字以内で設定します。 WebOTX Developerに付属しているIDLコンパイラ(woi2j,woigenxx)を用いずCORBAコンポーネントを作成した場合に設定が必須となります。 IDLコンパイラ(woi2j,woigenxx)を用いてソースを自動生成した場合、設定の必要はありません。

-
基本設定 ifファイル
CORBAアプリケーション配備時、サーバアプリケーションのifファイル名です。 共有コンポーネントとして配備されているifファイルを指定して配備することもできます。

-
基本設定 更新日時 サーバアプリケーションの更新日時です。 -
基本設定 サイズ サーバアプリケーションのファイルサイズ(単位:Byte)です。 -
基本設定 自動起動設定 CORBAアプリケーション配備時、モジュールの自動起動設定をします。 する
基本設定 共有コンポーネントの使用
CORBAアプリケーション配備時、共有コンポーネントのifファイルを使用していることを示します。 共有コンポーネントとして配備されているifファイルを指定して配備した場合、trueになります。

-
基本設定 モジュールの種類 CORBAアプリケーション配備時、モジュールの種類を表示します。 -
共有コンポーネント 使用する共有コンポーネント コンポーネントが利用する共有コンポーネントのリストを設定します。そのドメインに配備されている共有コンポーネントの中から選びます。言語にあった共有コンポーネントを指定してください。 -
状態 モジュールアイドル時間 モジュール配下のオペレーションが最近の呼び出しから呼ばれていない時間を示します。(単位:秒) -
状態 モジュールアクティブオブジェクト数 CORBAアプリケーション配備時、モジュール内のアクティブオブジェクト数を表します。ステートフルの場合、この値が0となっている時は利用しているクライアントが無いことを意味します。 -

7.1.4.3. 活性化・閉塞

統合運用管理ツールから活性化・閉塞
  1. 統合運用管理ツールよりドメインと接続します。
  2. ツリービューより活性化・閉塞するモジュールを選択します。
  3. 右クリックメニューより「活性化」あるいは「閉塞」を実行します。

ModuleKassei
図7.1.4.3-1

コマンドから活性化・閉塞
  1. otxadminコマンドを起動し、ドメインにログインします。
    otxadmin> login --user admin --password adminadmin --port 6212
    
  2. 活性化・閉塞を実行します。

    活性化
    otxadmin> invoke applications.j2ee-applications.ShopApp.ShopApp.ear.enable
    
    閉塞
    otxadmin> invoke applications.j2ee-applications.ShopApp.ShopApp.ear.disable
    

7.1.4.4. 状態

モジュールの状態について説明します。

表7.1.4.4-1
状態 アイコンの色 説明
起動処理中 黄色
起動処理中状態です。 起動処理中状態から状態が遷移しない場合はアプリケーショングループもしくはプロセスグループの停止を行なってください。 それでも状態が変更しない場合はアプリケーショングループもしくはプロセスグループの強制停止を行なってください。

起動中 緑色
起動中状態です。モジュールを停止させるときは停止処理により停止することができます。

停止処理中 橙色
停止処理中状態です。 停止処理中状態から遷移しない場合は、アプリケーショングループもしくはプロセスグループの停止を行なってください。 それでも状態が変更しない場合はアプリケーショングループもしくはプロセスグループの強制停止を行なってください。

停止 赤色
停止状態です。 モジュールをも起動させるときは起動処理により起動することができます。

起動停止処理失敗 赤色に×印
起動・停止処理に失敗しました。 復旧させるにはアプリケーショングループもしくはプロセスグループの停止を行なってください。 それでも状態が変更しない場合はアプリケーショングループもしくはプロセスグループの強制停止を行なってください。

7.1.5. 操作・状態確認(インタフェース)

7.1.5.1. 設定の変更

統合運用管理ツールから設定
  1. 統合運用管理ツールよりドメインと接続します。
  2. ツリービューより設定を変更するオブジェクトを選択します。
  3. リストビューより変更したい項目選択し、変更します。

InterfacePropertyChange
図7.1.5.1-1

コマンドから設定確認
  1. otxadminコマンドを起動し、ドメインにログインします。
    otxadmin> login --user admin --password adminadmin --port 6212
    
  2. 現在設定している値を確認します。
    otxadmin> get applications.j2ee-applications.ShopApp.ShopApp.ear.ShopEJB.Shop.*
    
  3. 変更したい属性を変更します。
    otxadmin> set applications.j2ee-applications.ShopApp.ShopApp.ear.ShopEJB.Shop.maxGenerationObject=0
    

7.1.5.2. 設定値の説明

表7.1.5.2-1
タブ表記 項目 説明 既定値
事前生成オブジェクト オペレーションコールのモード CORBAアプリケーション配備時、オブジェクトに登録されているオペレーションをステートフルで動作させるかステートレスで動作させるかを指定します。 ステートレス
事前生成オブジェクト スレッディングモデル ステートレスの場合、オブジェクトのスレッディングモデルをApartment、Freeより指定します。ステートフルの場合、Freeとなります。
Apartment:オブジェクトをスレッド毎に生成します。
Free:オブジェクトをスレッドとは独立して生成します。
Apartment
事前生成オブジェクト オブジェクトの事前生成を行う ステートレスの場合、事前生成するかどうか指定します。ステートフルの場合、事前生成は選択できません。ファクトリオブジェクトからの生成要求時に生成されます。 行う
事前生成オブジェクト 事前生成オブジェクト数 事前生成するオブジェクトの数を指定します。ステートレス、アパートメントモデルの場合はプロセスグループのスレッド数となります。Freeスレッディングモデルの場合、1からスレッド数の間で指定します。最大生成オブジェクト数以下の値を指定してください。 -
事前生成オブジェクト 最大生成オブジェクト数
最大生成するオブジェクトの数を設定します。 ステートレス、アパートメントモデルの場合はプロセスグループのスレッド数となります。
ステートフルの場合:1つの業務で一定数以上のオブジェクトを生成させたくない場合に、生成可能なオブジェクトの上限を指定します。 この上限を越えてオブジェクトを生成しようとすると、オブジェクト生成が失敗します。 上限チェックを行わない場合は0を指定します。事前生成オブジェクト数以上の値を指定してください。
ステートレスの場合:Freeスレッディングモデルのときは事前生成オブジェクト数〜スレッド数の範囲で設定してください。 それ以外のスレッディングモデルでは、スレッド数分オブジェクトを生成します。 事前生成オブジェクト数以上の値を指定してください。

-
事前生成オブジェクト コネクション制御ポリシ
Object Brokerにおけるオペレーション呼び出し毎のコネクション制御ポリシを指定します。 ロードバランサ使用時には、このポリシを変えることにより、サーバ側のどの単位で負荷分散を行うかを指定できます。 プロセスグループのバージョンが6以上のステートレス、あるいはファクトリで設定可能です。 バージョン5の場合は設定変更できません。また、ステートフルでは設定できません。
ホスト単位 : 同一ホストに対するコネクションを再利用する。コネクションが切断されるまでは同一のホストへ送信する。
オブジェクト単位 : リファレンス単位にコネクションを再利用する。
コネクションを再利用しない : コネクションを再利用しない。オペレーション呼び出し毎にコネクションを接続する。

ホスト単位
名前サーバへの登録 名前サーバへの登録設定 名前サーバへの登録名を、任意に設定するかどうかを選択してください。
登録は行わない:該当オブジェクトを名前サーバにリファレンス登録しません。
任意に設定する:該当オブジェクトを名前サーバにリファレンス登録します。別途名前サーバへのIOR登録URL等の設定が可能になります。
任意に設定する
名前サーバへの登録 名前サーバ登録名のリスト
名前サーバへのIOR登録URLをcorbaname形式で指定します。 既定値はIDLファイルのモジュール名、インタフェース名から構築されたURLです。 「追加」ボタンを押して、名前サーバへの登録URLを1023文字以内で設定してください。 「編集」ボタンと「削除」ボタンは設定してあるURLを選択すると使用できます。 ボタンを押して名前サーバへの登録URLを編集・削除してください。 「既定値に戻す」ボタンは既定値が設定されます。 それまで設定されていたURLはすべて削除されます。 バージョン5以前でCORBAコンポーネントを登録した場合はファクトリの使用設定によって既定値が変わります。 ファクトリを使用する設定になっている場合、ファクトリオブジェクトの場合は既定値のURLが設定されており、 そうでない場合は設定されていません。 ファクトリを使用しない設定になっている時はどちらの場合も既定値のURLが設定されています。 また、名前サーバのルートに直接登録されるURLも既定値として存在します。

-
名前サーバへの登録 TPシステムの設定を参照する TPシステムの属性で設定した名前サーバへの登録情報を引き継ぐ時はtrueにしてください。Falseにすると以下の項目をインタフェース単位で設定できます。 参照する
名前サーバへの登録 名前サーバへの登録 名前サーバへの登録方法を設定します。永続的に扱う場合、名前サーバへのIOR登録をプロセス起動停止に関係なく行えます。このため、プロセス起動時の名前サーバアクセス負荷を軽減することができます。一時的に扱う場合、プロセス起動時に名前サーバへの登録を行います。このとき、ラウンドロビン機能の設定もできます。 永続的に扱う
名前サーバへの登録 登録するIORの生成方式 登録するIORの生成方式を指定します。マルチサーバを使用する場合は、trueにしてください。シングルサーバを選択すると名前サーバへの登録時、自TPシステムの情報を登録します。マルチサーバの詳細は [ 7.1.7.5. マルチサーバラウンドロビン負荷分散運用 ] を参照してください。 指定しない
名前サーバへの登録 複数サーバシステムグループ名 マルチサーバで設定されたシステムグループ名を選択してください。名前サーバへの登録時、システムグループに設定されている全TPシステムの情報を登録します。 -
名前サーバへの登録 ラウンドロビン機能を使用する 同一のサーバアプリケーションが登録されたTPシステム間で負荷分散を行う時にtrueにします。ラウンドロビン機能を使用するときは、ObjectBrokerにて名前サーバのラウンドロビン機能を設定する必要があります。 使用する

7.1.6. 操作・状態確認(オペレーション)

7.1.6.1. 設定の変更

統合運用管理ツールから設定
  1. 統合運用管理ツールよりドメインと接続します。
  2. ツリービューより設定を変更するオペレーションを選択します。
  3. リストビューより変更したい項目選択し、変更します。

OperationPropertyChange
図7.1.6.1-1

コマンドから設定確認
  1. otxadminコマンドを起動し、ドメインにログインします。
    otxadmin> login --user admin --password adminadmin --port 6212
    
  2. 現在設定している値を確認します。
    otxadmin> get applications.j2ee-applications.ShopApp.ShopApp.ear.ShopEJB.Shop.*
    
  3. 変更したい属性を変更します。
    otxadmin> set applications.j2ee-applications.ShopApp.ShopApp.ear.ShopEJB.Shop.addAccount(int).exetimeMax=-1
    

7.1.6.2. 設定値の説明

表7.1.6.2-1
タブ表記 項目 説明 既定値
オペレーション制御 アプリケーショングループ起動時、オペレーションを自動活性する アプリケーショングループ起動時に自動的にオペレーションを実行可能な状態にします。 自動活性する
オペレーション制御 オペレーションの優先度 オペレーションの優先度を設定します。数字の小さい方が優先度は高くなります。 2
オペレーション制御 実行時間上限
実行時間上限を設定します。 オペレーションの応答時間が指定時間(秒)を過ぎてもレスポンスが返却されない場合で、 「プロセスを強制停止する」属性がオンになっている場合はオペレーション処理を中断します。 また-1を設定すると、上限を設定しません。 この設定を変更した際に、 「インタフェースと同様の自動設定とする」属性(詳細レベルの属性)とTPシステムの「実行時間上限を自動設定する」 属性がともにオンになっている場合、運用アシスタントによって実行時間上限が自動設定されないように、以下の設定をオフに変更します。
・「実行時間上限を自動設定する」
・「インタフェースと同様の自動設定とする」(詳細レベルの属性)
運用アシスタントに実行時間上限を自動設定させたい場合は、「実行時間上限を自動設定する」をオンに変更しなおしてください。

600
オペレーション制御 プロセスを強制停止する
実行時間上限を超えた際に、プロセスを強制停止するかどうかを設定します。 オペレーションの実行時間上限は、「実行時間上限を自動設定する」の設定に応じて推奨値が自動設定される場合がありますので、 実行時間上限の現在の設定値に問題がないかを確認してください。 また、オペレーションの実行時間上限を意図的に指定した場合、次の設定は自動的にfalseに変更されます。 運用アシスタントに実行時間上限を自動設定させたい場合は、「実行時間上限を自動設定する」をオンに変更しなおしてください。
・「実行時間上限を自動設定する」
・「インタフェースと同様の自動設定とする」(詳細レベルの属性)
]
強制停止しない
オペレーション制御 実行時間上限推奨値 現在までの実行履歴の統計情報をもとに算出された実行時間上限の推奨値を表示します。推奨値が設定値の90%〜100%であるような微小な減少では値は一括設定/自動設定設定されません。推奨値が0以上9以下である場合も一括設定/自動設定されません。 -
データベースの設定 データベース入出力時のエラー処理 CORBAアプリケーション配備時、WebOTXのデータベース機能を利用する場合、データベース入出力時のエラー処理について設定します。 実行中のオペレーションをキャンセルし以後このオペレーションは閉塞
データベースの設定 オペレーション終了時にデータベースの自動コミット/ロールバックを行う CORBAアプリケーション配備時、WebOTXのデータベース機能を利用する場合、オペレーション終了時にオペレーションのステータスにより、データベースの自動コミット/ロールバックを行うかどうか設定します。 設定しない
状態 状態
オペレーションの状態を表示します。

-
運用アシスタント 実行時間上限を自動設定する 実行時間上限を自動設定するかどうか設定します。「自動設定する」をチェックすると情報採取間隔(「TPシステム」-「情報採取間隔」)ごとに実行時間上限が自動的に更新されます。 する
運用アシスタント スローダウン継続時間 スローダウンを検出してからの経過時間を分単位で表示します。ノーマル状態の場合は-1が表示されます。表示は情報採取間隔ごとに更新されます。 -
運用アシスタント スローダウン継続監視時間
スローダウンを検出してからの経過時間を分単位で監視します。 この時間を過ぎてもスローダウン状態が解消されない場合は「長期にわたるスローダウン」として警告メッセージを出力します。 スローダウンを検出してからの経過時間は、情報採取間隔ごとにチェックされます。 -1を設定した場合は、スローダウンを検出してからの経過時間を監視しません。

20分
運用アシスタント インタフェースと同様の監視時間とする スローダウン継続監視時間の設定をオペレーション単位に行うかどうかを設定します。ここで設定すると、TPシステム、アプリケーショングループ、プロセスグループ、モジュール、インタフェースの設定よりも優先されます。 オペレーション単位で設定せず、インタフェースと同様の設定とする

7.1.6.3. 起動・停止

統合運用管理ツールから起動・停止
  1. 統合運用管理ツールよりドメインと接続します。
  2. ツリービューより活性化するオペレーションを選択します。
  3. 右クリックメニューより「起動」あるいは「停止」を実行します。

OperationKidou
図7.1.6.3-1

コマンドから設定確認
  1. otxadminコマンドを起動し、ドメインにログインします。
    otxadmin> login --user admin --password adminadmin --port 6212
    
  2. 起動・停止を実行します。

    起動
    otxadmin> invoke applications.j2ee-applications.ShopApp.ShopApp.ear.ShopEJB.Shop.addAccount(int).start
    
    停止
    otxadmin> invoke applications.j2ee-applications.ShopApp.ShopApp.ear.ShopEJB.Shop.addAccount(int).stop
    

7.1.6.4. 状態

オペレーションの状態について説明します。

表7.1.6.4-1
状態 アイコンの色 説明
起動中 緑色 起動中状態です。 モジュールを停止させるときは停止処理により停止することができます。
停止 赤色
停止状態です。 オペレーションをも起動させるときは起動処理により起動することができます。

7.1.7. 設定詳細

7.1.7.1. クライアント制御

接続しているクライアント制御の設定について以下に示します。

クライアント情報の表示

統合運用管理ツールで[クライアントセッション]を選択することにより現在接続しているクライアントに関する情報を表示します。 ただし thinクライアントから利用している場合は、実際にTPシステムにアクセスを行っているのはWebコンテナであるため、Webコンテナの情報が表示され、実際のブラウザの情報は表示されません。

V6.5より、IIOPリスナのアライブチェックを行うため、TPモニタ・マネージャよりIIOPリスナに対してセッションを1本張っています。 このときのIPアドレスは127.0.0.1です(127.0.0.1であるセッションすべてがアライブチェック用のセッションとは限りません)。 このセッションは切断しないように注意してください。 切断した場合、IIOPリスナが起動停止失敗(failed)状態になります。 ただし、つぎのアライブチェック時にセッションを張りなおします。

クライアントの強制切断

接続しているクライアントを統合運用管理ツール上で切断することができます。

  1. 統合運用管理ツールで[クライアントセッション]を選択します。
  2. [操作]-[クライアント切断]メニューを実行します。
  3. 切断したいクライアントを設定し、切断を実行します。
クライアントにメッセージ送信

接続しているクライアントに統合運用管理ツールよりメッセージを送ることができます。 ただし、メッセージが送れるクライアントはクライアント管理ライブラリをリンクしているCORBAのクライアントアプリケーションのみです。

  1. 統合運用管理ツールで[クライアントセッション]を選択します。
  2. [操作]-[メッセージ送信]メニューを実行します。
  3. メッセージを送りたいクライアントを設定し、メッセージを入力して実行ボタンを押します。

クライアントに送信するメッセージは187バイト以内で指定します。 メッセージに半角セミコロン";"は使用できません。

クライアント無通信監視

接続しているクライアントより、一定時間が経過してもオペレーション呼び出しがない場合、強制的にクライアントからの接続を切断させることができます。

  1. 統合運用管理ツールで[IIOPリスナ]を選択します。
  2. [クライアント制御]を選択し、[クライアント無通信監視を行う]をチェックします。
  3. [クライアント無通信監視間隔]に監視時間を秒単位(60〜2147483)で指定します。
  4. 設定を反映させるためにTPシステムを再起動します。
クライアントアライブチェック

クライアント及び回線の有効性を確認するため、WebOTXの機能を使用して所定の間隔でアライブチェックを行うことができます。 アライブチェックで応答がないクライアントは強制的に切断されます。 ただし、アライブチェックが可能なクライアントはクライアント管理ライブラリを使って決められた手続きを行っているCORBAのクライアントアプリケーションのみです。 クライアント管理ライブラリを使っていないクライアントがいる環境でクライアントアライブチェックを使用しても害はありませんが機能しません。

  1. 統合運用管理ツールで[IIOPリスナ]を選択します。
  2. [クライアント制御]を選択し、[クライアントアライブチェックを行う]をチェックします。
  3. [クライアントアライブチェック間隔]に監視時間を秒単位(60〜2147483)で指定します。
  4. 設定を反映させるためにTPシステムを再起動します。
接続クライアント情報のホスト名表示

統合運用管理ツールの[クライアントセッション]では接続しているクライアントのホスト名の表示を行っています。 ただ、クライアントのIPアドレスからホスト名への変換ができない場合に、ホスト名変換ができずにWebOTX全体のレスポンスを悪化させてしまいます。 そのような環境の場合は接続クライアント情報のホスト名表示を行わない指定をする必要があります。

  1. 統合運用管理ツールで[TPシステム]を選択します。
  2. [クライアント制御]を選択し、[クライアント情報表示時にホスト名の逆引き処理を行う]からチェックを外します。
  3. 設定を反映させるためにTPシステムを再起動します。
TCPレベルでのアライブチェック

クライアント及び回線の有効性を確認するため、OSの機能を使用してアライブチェックを行うことができます。 アライブチェックで応答がないクライアントは強制的に切断されます。 WebOTXの機能を使ったCORBAのクライアントアプリケーションのアライブチェックと違って本機能は全てのクライアントに有効です。 但し、アライブチェック間隔はOS側の設定となります。 OS側の設定については [ 高度な管理と運用サイクルガイド > 2. チューニング > 2.9. 通信 > 2.9.1. TCP/IPに関する設定 ] を参照してください。

TPシステムに関しては以下の手順で設定してください。

  1. 統合運用管理ツールで[TPシステム]を選択します。
  2. [クライアント制御]を選択し、[TCPレベルでのアライブチェックを行う]をチェックします。
  3. 設定を反映させるためにTPシステムを再起動します。

7.1.7.2. 常駐オブジェクト

常駐オブジェクトの登録・置換

常駐オブジェクトは、あらかじめ共有コンポーネントとして登録されている必要があります。 統合運用管理ツール上で[アプリケーション]を選択し、[操作]-[コンポーネントの配備]コマンドを実行すると、コンポーネント(C++,VC++.NETの場合は.DLL(.SL,.SO),Javaの場合は.ZIPもしくは.JAR)を追加または置換することができます。

常駐オブジェクトとして登録する場合は.IFファイルを指定する必要はありません。 常駐オブジェクトとして使用する場合、プロセスグループのプロパティにおいて常駐オブジェクト名を指定する必要があります。

常駐オブジェクトの設定

統合運用管理ツールで、常駐オブジェクトを使用するプロセスグループの設定を行います。

統合運用管理ツールを起動し、ドメインと接続します。 プロセスグループを選択し[常駐オブジェクト]を選択して[常駐オブジェクトを使用する]にチェックを入れて更新します。 配下に[常駐オブジェクト]が表示されますのでそれを選択し[操作]-[複数常駐オブジェクトの設定]を実行して以下の項目について設定します。

表7.1.7.2-1
項目 説明 既定値
オブジェクト識別名
常駐オブジェクトを識別するための識別名を16文字以内の英数字で一意に設定します。 最初の文字は英字で指定してください。 ここでは大文字と小文字は区別されます。

-
コンポーネント名
常駐オブジェクトのアプリケーション名を選択します。 常駐オブジェクトは共有コンポーネントとしてあらかじめ登録されている必要があります。

-
オブジェクトクラス名
Javaの場合のみ常駐オブジェクトクラス名も255文字以内で指定します。 例えばpreObjというクラス名を指定するときは、次のように設定します。
Packageありの場合:jp.co.nec.preObj
Packageなしの場合:preObj

-
オペレーション開始時の呼び出しを行う オペレーション開始時に常駐オブジェクトへの呼び出しを行います。 呼び出す
オペレーション正常終了時の呼び出しを行う オペレーション正常終了時時に常駐オブジェクトへの呼び出しを行います。 呼び出す
オペレーション異常終了時の呼び出しを行う オペレーション異常終了時に常駐オブジェクトへの呼び出しを行います。 呼び出す
例外発生時の呼び出しを行う 例外発生時に常駐オブジェクトへの呼び出しを行います。 呼び出す

ここで登録した常駐オブジェクトはコールバック呼び出しの際にリストの登録順に呼び出されます。 また、Javaの場合はクラスパスにこの順番で追加されます。

順番を変えたいときは設定した常駐オブジェクトを選択し、[常駐オブジェクト]の[ロード順]を変更してください。

注意事項
表7.1.7.2-2
C++パターン 1 2
オブジェクト識別名 ×
結果 上書 追加
表7.1.7.2-3
Javaパターン 1 2 3 4 5 6 7 8
オブジェクト識別名 × × × ×
オブジェクトファイル名 × × × ×
オブジェクトクラス名 × × × ×
結果 上書 上書 上書 上書 追加 追加 不可 追加
○:一致する
×:一致しない
常駐オブジェクトの削除

削除したい場合は[常駐オブジェクト]を選択し、[複数常駐オブジェクトの削除]などの削除メニューを実行してください。 削除する項目を選択して削除を実行してください。

注意事項

常駐オブジェクトを削除する場合、そのオブジェクトをロードしているサーバアプリケーションを含むアプリケーショングループを停止する必要があります。

7.1.7.3. 共有コンポーネント

各プロセスが共通に使用するコンポーネントや共通の基底クラスをもつコンポーネントなどは共有コンポーネントとして追加します。 以下に共有コンポーネントの設定について示します。

共有コンポーネントの登録・置換

統合運用管理ツール上で[アプリケーション]を選択し、[操作]-[コンポーネントの配備]コマンドを実行して配備します。 コンポーネントタイプとして、共有コンポーネントを選択してください。

また、共有コンポーネントとして登録されているifファイルを指定してコンポーネントを登録することができます。 複数実装を実現する際、共通部分は共有コンポーネントとして作成してあらかじめ登録しておき、実装部分のみを個別に作成してコンポーネントとして登録することができます。 共有部分として作成したコンポーネントをここで登録してください。

ifファイルのみを登録することもできます。 コンポーネント登録時にこのifファイルを参照することができます。

共有コンポーネントとして使用する場合、モジュールのプロパティにおいて共有コンポーネント名を指定する必要があります。 使用しないものについては、モジュールのプロパティから共有コンポーネント名を削除する必要があります。 使用しない場合、共有コンポーネント情報は継承されません。

共有コンポーネントのプロパティにおいて、「全てのコンポーネントで使用する」チェックボックスをチェックしたときは、全てのモジュールのプロパティにおいて使用する設定になります(既定値:使用しない)。 ただし、チェックをはずした場合はモジュールのプロパティを変更しません。 モジュールのプロパティ設定はそのままになります。

また、チェックしてある場合、以降に配備したモジュールは自動的にその共有コンポーネントを使用する設定になります。 チェックしていない場合は、以降に配備したモジュールは自動的にその共有コンポーネントを使用しない設定になります。

継承情報の更新はプロセスグループを選択し、[操作]-[継承情報の更新]コマンドを実行してください。

共有コンポーネントの削除

統合運用管理ツール上で[アプリケーション]配下のアプリケーション名を選択し、[操作]-[配備解除]コマンドを実行して配備解除します。

注意事項

共有コンポーネントのifファイルを使用してコンポーネントの配備をしている場合、共有コンポーネントの削除によってそのコンポーネントが正常に動作しなくなります。 削除前にコンポーネントのほうから削除してください。

7.1.7.4. 名前サーバへの登録

名前サーバへの登録

名前サーバへのInteroperable Object Reference(IOR)登録URLをcorbaname形式で任意に指定することができます。 また、その登録を永続化するか一時的に扱うかを選択し、どのタイミングで名前サーバに登録するかを選択することができます。

EJBコンポーネントの場合URLはcorbaname://*となります。

  1. 統合運用管理ツールを起動し、ドメインと接続します。
  2. インタフェースの[名前サーバへの登録]を選択し[名前サーバへの登録名]を選択します。 [任意に設定する」を選択した場合、名前サーバへの登録URL等の設定が可能になります。 [登録は行わない]を選択した場合は、名前サーバへの登録は行いません。
  3. [任意に設定する]を選択した場合、[名前サーバのリスト]に登録用URLをcorbaname形式で任意に指定します。 既定値はV4.2までの登録URLです。 IDLファイルのモジュール名、インタフェース名から構築されます。
    旧バージョンでCORBAコンポーネントを登録した場合は名前サーバのルートに直接登録されるURLも既定値として存在します。
  4. [名前サーバへの登録]にて永続的に扱うか一時的に扱うかを選択してください。 永続的に扱う場合、任意のタイミングで登録できます。 また、プロセスが停止してもその情報は登録されたままになります。 プロセス起動時の名前サーバアクセス負荷を軽減することができます。
    一時的に扱う場合、プロセス起動時にWebOTX内部で登録を行います。 プロセス停止時に削除されます。 ユーザが明示的に名前サーバへの登録を行う必要はありません。
    [システムの設定を参照する]にチェックを入れている場合はTPシステムの[名前サーバへの登録]で設定されている値が引き継がれます。
  5. [登録するIORの生成方式]で、シングルサーバで扱う場合はチェックをはずしてください(既定値)。 複数サーバに関する設定を行う場合は、チェックを入れて[複数サーバシステムグループ名]を設定してください。 名前サーバへの登録時、システムグループに設定されている全TPシステムの情報を登録します。
    [複数サーバシステムグループ名]はツリービューから[マルチサーバ]を選択して設定することができます。
    詳細は [ 7.1.7.5. マルチサーバラウンドロビン負荷分散運用 ] をご覧ください。
  6. ラウンドロビン機能を利用する場合は、[ラウンドロビン機能を使用する]にチェックを入れてください。 同一のサーバアプリケーションが登録されたTPシステム間で負荷分散を行います。(既定値:行う)
Caution
ラウンドロビン設定において、運用途中でラウンドロビン機能の設定を変える(ラウンドロビン機能のチェックを変える、「一時的に扱うラウンドロビン機能使用」の設定から「永続的に扱う」設定に変えるなど)と名前サーバが動作不定になります。 システム構築時にIOR登録とラウンドロビン設定を決めたら変えないようにしてください。
名前サーバに登録したオブジェクトリファレンスの確認

サーバアプリケーションのオブジェクトは、WebOTXが名前サーバに登録するほかに、ユーザが任意に登録することができます。 その登録内容をWindows版のOrbManagerを使用して確認することができます。 以下にその確認方法について示します。

  1. WebOTXインストールディレクトリにObject Brokerがインストールされます。 そのbinディレクトリ配下にあるorbmanag.exeを起動します。
  2. 該当名前サーバに登録されているオブジェクト一覧が確認できます。 設定したcorbaname形式の“/”を区切りとしたツリーとして表示されます。

なお、orbmanag.exeは指定したホストで名前サーバが起動していないとエラーになります。 かならず名前サーバが起動しているホスト名を指定して下さい。

orbmanag.exe起動中にオブジェクトが登録された時、ツリービューが構築されない時はツリーを一度閉じてください。

CORBAアプリケーションの自動名前登録

CORBAアプリケーションの自動名前登録の設定を以下に示します。

運用管理ツールからの配備時に自動名前登録を行う場合は、[TPシステム]-[アプリケーション]を右クリックし、表示されたメニューより[コンポーネントの配備]を選択します。
[コンポーネントの配備]-[CORBA関連情報]の名前サーバの登録方式を"永続的に扱う"を選択し、配備を行います。

図7.1.7.4-1
図7.1.7.4-1

また、運用管理コマンドからの配備時に自動名前登録を行う場合は、以下のコマンドを使用し"--bindtype"オプションを使用します。
詳細は、deployコマンドを参照してください。

otxadmin> deploy --apgroup <アプリケーショングループ名> --pgroup <プロセスグループ名> --bindtype=<transient|persistent> <配備するファイル>

7.1.7.5. マルチサーバラウンドロビン負荷分散運用

マルチサーバラウンドロビン負荷分散はEJBのホームインタフェース、ステートレスセッションBeanのリモートインタフェース、CORBAアプリケーションのオブジェクトリファレンスに複数の接続先の情報を含める(IOR 多重化)ことにより、クライアントからのオペレーション呼び出し毎にラウンドロビン方式で接続先を決定することにより、複数ドメイン間の負荷分散運用を行うことができます。

オブジェクトのIORにマルチサーバの定義を行うためのサーバ、クライアントの設定について説明します。

7.1.7.5.1. サーバ実行環境の設定

サーバ実行環境においては、統合運用管理ツールを使って以下の設定を行います。 全てのサーバで同一の設定を行ってください。

  1. [名前サーバへの登録]の設定
    TPシステムのプロパティで[名前サーバへの登録]を[永続的に扱う]に設定します。
  2. 複数サーバの設定
    [マルチサーバ]を選択し、[操作]-[システムグループの設定]でシステムグループを作成します。 配下にシステムグループが作成されるので、[操作]-[サーバセットの設定]を実行して自システムを含め負荷分散を行うTPシステム全てを登録します。 いくつかの負荷分散パターンがある場合は複数のシステムグループを作成してください。
  3. インタフェースの設定
    インタフェースの属性で負荷分散を行う全てのインタフェースに、次の設定を行います。 [名前サーバへの登録]について[システムの設定を参照する]とし[永続的に扱う]にします。 [登録するIORの生成方式]にチェックを入れ、[複数サーバシステムグループ名]に[マルチサーバ]で作成したシステムグループ名を指定します。
  4. IORの登録
    インタフェースを選択して、[操作]-[名前サーバへ登録]を実行し、IORを名前サーバに登録します。 この作業は全てのシステムで実行してください。 登録を行うときに、各TPシステムに対してポート番号やSSLの設定などの情報取得を行いますので、全てのサーバのWebOTXシステムを起動させた状態で実行してください。
7.1.7.5.2. クライアント実行環境の設定

マルチサーバ負荷分散を行うためのクライアント実行環境の設定について説明します。

C++,VB

クライアントの実行環境においては、レジストリまたはAPIで以下の設定を行います。

  1. レジストリで設定する場合
    MultiConnection=true,ConnectionRoundRobin=true に設定されているかをご確認下さい。既定値はtrueです。
    設定に関する詳細は[ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.10. Object Broker > 1.10.1. Object Broker設定項目・設定方法 ]をご覧ください。
  2. APIで設定する場合
    Ob_use_multi_connection及び__use_connection_roundrobinの設定を行ってください。
    設定方法に関する詳細は[ リファレンス集 開発編(共通) > 4. CORBA > 4.4. WebOTX Object Broker C++ > 4.4.9. オブジェクト多重化を利用するためのインタフェース ] をご覧ください。
Java

クライアントの実行環境においては、システムプロパティまたはAPIで以下の設定を行います。

  1. システムプロパティで設定する場合
    UseMultiConnection=true,UseConnectionRoundRobin=true に設定されているかをご確認下さい。既定値はtrueです。
    設定方法に関する詳細は[ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.10. Object Broker > 1.10.2. Object Broker JavaにおけるORBのプロパティ定義 ]をご覧ください。
  2. APIで設定する場合
    setUseMultiConnection及びsetUseConnectionRoundRobinの設定を行ってください。
    設定に関する詳細はリファレンス集 開発編 (共通)の jp.co.nec.orb.Config をご覧ください。
注意事項

ステートレスセッションBeanやファクトリを使用したCORBAアプリケーションをステートレスで動作させる場合、クライアントでオペレーション呼び出し毎、もしくは頻繁にEJBホームインターフェースのcreate()、CORBA ファクトリオブジェクトのCreateServerObject()を呼び出しオブジェクトリファレンスを取得すると負荷が偏るのでご注意下さい。これはcreate()、CreateServerObject()で取得したリファレンスに対する呼び出しは複数の接続先の中から同じ順番で振り分けられるためです。

7.1.7.6. 非同期トランザクション

非同期トランザクションの設定方法について以下に示します。

AsyncTX
図7.1.7.6-1

  1. 非同期トランザクションを行うための1stステージ、2ndステージコンポーネントを作成します。
  2. 通常コンポーネント同様非同期トランザクションを行う1stステージ、2ndステージコンポーネントを登録します。
  3. 1stステージコンポーネントを登録したプロセスグループのプロパティにて[非同期オペレーション呼び出し]を選択し、[非同期オペレーション呼び出しを行う]にチェックします。
  4. トランザクション型VDを作成します。 [VDのプロパティ」では1stステージから呼び出される2ndステージのオペレーションとそれが属するアプリケーショングループ、プロセスグループ、モジュール名、インタフェース名を設定します。
  5. トランザクション型VDを起動します。
  6. 1stステージ、2ndステージのアプリケーショングループを起動します。

以下に、トランザクション型VDと間接型VDについて説明します。 端末型VDに関しては、[ 7.1.7.9. 帳票印刷(WebOTX Print Kit) ] を参照してください。

VDの作成 トランザクション型VD
  1. 統合運用管理ツールを起動し、ドメインに接続します。
  2. TPシステムを停止します。
  3. [VDインフォメーション]を選択し、VDを使用するをチェックして最大VD数を設定します。
  4. TPシステムを起動します。
  5. [VDインフォメーション]を選択し[操作]-[トランザクション型VDの新規作成]を実行します。
  6. VD名を英数字16文字以内で設定します。
    また、非同期オペレーションとして指定するオペレーション名と、そのオペレーションが属するアプリケーショングループ、プロセスグループ、モジュール、インタフェース名を指定します。 モジュール名は、アプリケーション名ではなくファイル名で指定してください。
VDの作成 間接型VD
  1. 統合運用管理ツールを起動し、ドメインに接続します。
  2. TPシステムを停止します。
  3. [VDインフォメーション]を選択し、VDを使用するをチェックして最大VD数を設定します。
  4. TPシステムを起動します。
  5. [VDインフォメーション]を選択し[操作]-[トランザクション型VDの新規作成]を実行してトランザクション型VDを作成します。
  6. [VDインフォメーション]を選択し[操作]-[間接型VDの新規作成]を実行します。
  7. VD名を英数字16文字以内で設定します。 また、VDの型をラウンドロビンか滞留数優先か選択し、使用するトランザクション型VDのリストを選択します。
VDの削除
  1. 統合運用管理ツールを起動し、ドメインに接続します。
  2. VDが実行中である場合は、[VDインフォメーション]配下の該当VDを選択し、[操作]-[停止]を実行します。
  3. [VDインフォメーション]を選択し[操作]- [削除]を実行して削除するVDを選択します。

なお、直接該当VD名のノードを選択して右クリックメニューより「削除」を実行することもできます。

VDの起動
  1. 統合運用管理ツールを起動し、ドメインに接続します。
  2. [VDインフォメーション]配下の該当VDを選択し、[操作]-[起動]を実行します。
VDの停止
  1. 統合運用管理ツールを起動し、ドメインに接続します。
  2. [VDインフォメーション]配下の該当VDを選択し、[操作]-[停止]を実行します。
VDの閉塞
  1. 統合運用管理ツールを起動し、ドメインに接続します。
  2. [VDインフォメーション]配下の該当VDを選択し、[操作]-[閉塞]を実行します。
VD滞留メッセージのクリア
VDに滞留した不要なメッセージを、オペレーション実行中のデータも含めて強制的に削除します。 オペレーション実行中に以下の操作は行わないでください。
  1. 統合運用管理ツールを起動し、ドメインに接続します。
  2. [VDインフォメーション]配下の該当VDを選択し、[操作]-[VD滞留メッセージのクリア]を実行します。
VDのプロパティ
  1. 統合運用管理ツールを起動し、ドメインに接続します。
  2. [VDインフォメーション]配下の該当VDを選択します。
  3. 設定したい項目を設定します。

VDのプロパティについて以下に示します。 なおプロパティを設定する場合はVDを停止してから行ってください。

表7.1.7.6-1
項目 説明 既定値
システム起動時にVDも起動する TPシステムを起動した時、VDを起動します。 -
実行優先順位 VD内で実行優先順位を2〜15の範囲で指定します。 -
VDマスタデータファイルに情報を置かずに個別で持つ 個別にデータファイルを持つかどうかを指定します。個別に持つ場合、データファイルサイズの設定もしてください。 VDマスタデータファイルに持つ
個別VDデータファイルサイズ VDのメッセージを格納するデータファイルのサイズをメガバイト単位で指定します。1〜2047の正数で指定します。 1MB
個別VDデータファイルのフラッシュを行う
VDで使用するデータファイルの更新時にディスクへのフラッシュを行うかどうかを指定します。 フラッシュを行う場合、オペレーティングシステムのダウン後もデータファイルを使用することができます。 なお、フラッシュを行う設定にした場合、マスタデータファイルのフラッシュも行います。 また、VDマスタデータファイルに持つ場合でもこちらの設定が有効になります。

行わない
個別VDデータファイルの初期化を行う VDサーバ起動時に保存メッセージを消去して初期化するかどうかを指定します。 また、VDマスタデータファイルに持つ場合でもこちらの設定が有効になります。 行う
個別VDデータファイル名
VDで使用するデータファイルの名前を31文字以内の英数字で指定します。 入力しなかった場合はVD名が個別VDデータファイル名となります。 個別VDデータファイルは以下の位置に作成されます。
${INSTANCE_ROOT}/config/tpsystem /vdf/<個別VDデータファイル名>

-
クライアント永久障害発生時の後処理 端末型VDのみ設定可能です。 -
取り出し後のメッセージ 端末型VDのみ設定可能です。 -
トランザクション型VDのプロパティ トランザクション型VDのとき、非同期オペレーションとそのオペレーションが属するアプリケーショングループ、プロセスグループ、モジュール名、インタフェース名が表示されます。 -
間接型VDのプロパティ 間接型VDのとき、間接型VDが使用するトランザクション型VDのリストを表示します。 -
注意事項

7.1.7.7. Transactionサービス連携

複数に分散されたデータベースの一括更新管理を行う場合、2フェーズコミットメント機能を提供する「Transactionサービス」を利用する必要があります。

Transactionサービスは、StandardまたはEnterpriseをインストールすると標準でインストールされます。 ただしリカバリサーバはインストール時に明示的にインストール指定を行う必要があります。 リカバリサーバを利用して分散トランザクション処理を実行する場合にはご注意ください。

次に、Transactionサービスと連携するための設定について示します。

TSRenkei
図7.1.7.7-1

  1. 統合運用管理ツールを起動し、ドメインと接続します。
  2. ツリーの部分で、プロセスグループをクリックします。
  3. 右側に表示される[Transaction Service]プロパティを選択し「Transaction Service連携を行う」をチェックします。 EJBの場合は、「Transaction Service連携を行う」が既定値です。
  4. 「トランザクションの制御」の設定を行ないます。 Recovery Coordination Server(RCS)を使用してアプリケーションと同一の空間でトランザクション処理を実行するか、リカバリサーバを使用してトランザクション処理を実行するかを選択してください。
  5. RCSを使用する場合で、WebOTX V5互換のアプリケーションを動作させる場合には「RCSID」の一覧が表示されますので、これも設定を行ってください。 WebOTX V6のアプリケーションでは設定の必要はありません。
  6. 「OTSポリシ」を選択してください。 トランザクションの動作を指定します。
  7. C++,VC++.NETアプリケーションの場合はオープンするデータベースを設定してください。 10個まで選択できます。 なお使用するデータベースは統合運用管理ツールのserver.transactionserviceの設定で追加できますので、予め設定しておいてください。 設定方法については [ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.9. Transactionサービス > 1.9.3. Transactionサービスに関する設定 ] をご参照ください。
    なお、リカバリサーバを利用する場合にはTransaction Service 運用管理ツールを使用して作成してください。 Java, EJBの場合は選択する必要はありません。

なお、連携時にはこれらのサービス(RCSもしくはリカバリサーバ)が起動している必要があります。

注意事項

リカバリサーバを利用してTransactionサービスとの連携を行う場合、リカバリサーバとのコネクションが常に張られた状態になります。 また、この時ライセンスを1つ消費します。

クライアント情報の画面に表示されますが手動で切断しないようにしてください。

7.1.7.8. ダウンローダ管理サービス

ダウンローダ管理ツールを使ってクライアント配布を行う場合や、syslog(unix)とイベントログ(Windows)に出力されるOTX190000xxメッセージを抑制する場合にはダウンローダ管理サービスの設定が必要です。 ダウンローダ管理サービスの設定について以下に示します。

ダウンローダ管理サービスの設定

ダウンローダ管理サービスの設定内容は次の通りです。 設定は統合運用管理ツールと運用コマンドから行うことができます。

表7.1.7.8-1
項目 属性名 説明 既定値
ポート番号 portNumber
利用するポート番号を1〜65535の整数で指定します。 システムで使用する全てのポート番号の中で一意に設定してください。 設定を反映させるにはドメインの再起動が必要です。

5202
受信タイムアウト値 recvtimeout 通信ソケットの受信時のタイムアウト値を秒単位で指定します。1〜2147483の整数で指定してください。 10秒
抑制メッセージ番号 ignoreMessage OTX190000xxメッセージの内、出力しないsyslog(unix)とイベントログ(Windows)のメッセージを指定します。1〜91の整数を追加してください。 指定なし
統合運用管理ツールから設定
  1. 統合運用管理ツールよりドメインと接続します。
  2. ツリービューよりTPシステム内のダウンローダ管理サービスを選択します。
  3. リストビューより変更したい項目選択し、変更します。
コマンドから設定
  1. otxadminコマンドを起動し、ドメインにログインします。
    otxadmin> login --user admin --password adminadmin --port 6212
    
  2. 現在設定している値を確認します。
    otxadmin> get tpsystem.downloaderManagerService.*
    
  3. 変更したい属性名を指定して変更します。
    otxadmin> set tpsystem.downloaderManagerService.portNumber=port番号
    
  4. 抑制メッセージ番号を複数指定する場合は、カンマ区切りで指定します。
    otxadmin> set tpsystem.downloaderManagerService.ignoreMessage=番号,番号,番号
    

7.1.7.9. 帳票印刷(WebOTX Print Kit)

WebOTX Print Kitなどを使って帳票印刷を行うためには端末型VDとOLFリスナの設定が必要です。 サーバ実行環境側の設定について以下に示します。

端末型VDの作成
  1. 統合運用管理ツールを起動し、ドメインに接続します。
  2. TPシステムを停止します。
  3. [VDインフォメーション]を選択し、VDを使用するをチェックして最大VD数を設定します。
  4. TPシステムを起動します。
  5. [VDインフォメーション]を選択し[操作]-[端末型VDの新規作成]を実行します。
  6. VD名を英数字16文字以内で設定します。
端末型VDの削除
  1. 統合運用管理ツールを起動し、ドメインに接続します。
  2. VDが実行中である場合は、[VDインフォメーション]配下の該当VDを選択し、[操作]-[停止]を実行します。
  3. [VDインフォメーション]を選択し[操作]- [削除]を実行して削除するVDを選択します。

なお、直接該当VD名のノードを選択して右クリックメニューより「削除」を実行することもできます。

端末型VDの起動
  1. 統合運用管理ツールを起動し、ドメインに接続します。
  2. [VDインフォメーション]配下の該当VDを選択し、[操作]-[起動]を実行します。
端末型VDの停止
  1. 統合運用管理ツールを起動し、ドメインに接続します。
  2. [VDインフォメーション]配下の該当VDを選択し、[操作]-[停止]を実行します。
端末型VDの閉塞
  1. 統合運用管理ツールを起動し、ドメインに接続します。
  2. [VDインフォメーション]配下の該当VDを選択し、[操作]-[閉塞]を実行します。
VD滞留メッセージのクリア
VDに滞留した不要なメッセージを、オペレーション実行中のデータも含めて強制的に削除します。 オペレーション実行中に以下の操作は行わないでください。
  1. 統合運用管理ツールを起動し、ドメインに接続します。
  2. [VDインフォメーション]配下の該当VDを選択し、[操作]-[VD滞留メッセージのクリア]を実行します。
端末型VDのプロパティ
  1. 統合運用管理ツールを起動し、ドメインに接続します。
  2. [VDインフォメーション]配下の該当VDを選択します。
  3. 設定したい項目を設定します。

VDのプロパティについて以下に示します。 なおプロパティを設定する場合はVDを停止してから行ってください。

表7.1.7.9-1
項目 説明 既定値
システム起動時にVDも起動する TPシステムを起動した時、VDを起動します。 -
実行優先順位 VD内で実行優先順位を2〜15の範囲で指定します。 -
VDマスタデータファイルに情報を置かずに個別で持つ 個別にデータファイルを持つかどうかを指定します。 個別に持つ場合、データファイルサイズの設定もしてください。 VDマスタデータファイルに持つ
個別VDデータファイルサイズ VDのメッセージを格納するデータファイルのサイズをメガバイト単位で指定します。1〜2047の正数で指定します。 1MB
個別VDデータファイルのフラッシュを行う VDで使用するデータファイルの更新時にディスクへのフラッシュを行うかどうかを指定します。 フラッシュを行う場合、オペレーティングシステムのダウン後もデータファイルを使用することができます。 なお、フラッシュを行う設定にした場合、マスタデータファイルのフラッシュも行います。 また、VDマスタデータファイルに持つ場合でもこちらの設定が有効になります。 行わない
個別VDデータファイルの初期化を行う VDサーバ起動時に保存メッセージを消去して初期化するかどうかを指定します。 また、VDマスタデータファイルに持つ場合でもこちらの設定が有効になります。 行う
個別VDデータファイル名
VDで使用するデータファイルの名前を31文字以内の英数字で指定します。 入力しなかった場合はVD名が個別VDデータファイル名となります。 個別VDデータファイルは以下の位置に作成されます。
${INSTANCE_ROOT}/config/tpsystem/vdf/<個別VDデータファイル名>
-
クライアント永久障害発生時の後処理 クライアント永久障害が発生したときの処理を指定します。 端末型VDのみ設定できます。
VDの切り離しを行なわず、送信リトライを行なう
取り出し後のメッセージ 取り出し後のメッセージを保留するかどうかを指定します。 端末型VDのみ設定できます。
取り出し後のメッセージを保存しない
注意事項
OLFTPリスナの設定

OLFTPリスナに関する設定は統合運用管理ツールを実行し、ドメインと接続を行い[OLFTPリスナ]を選択して設定します。

表7.1.7.9-2
項目 説明
平文ポート番号
OLFTPリスナポート番号を指定します。

OLFTPリスナを起動する
OLFTPリスナを使用する場合はチェックを入れます。

利用可能な同時接続クライアント数
印刷サーバ同時最大接続数を指定します。 ここで指定した値以上に同時に印刷サーバからの要求は受け付けません。

7.1.7.10. プロセスグループの設定の動的変更

動的変更の設定について以下に示します。

動的変更方法

図7.1.7.10-1
図7.1.7.10-1

以下の動作の場合は、再起動回数による起動リトライは行われず、旧設定のプロセスで動作継続します。

旧設定のプロセスの終了でタイムアウトが発生した場合、タイムアウトの旨をプロセスIDとともにsyslog(またはイベントログ)に出力しますが、 再起動処理自体は正常終了となり、業務は新プロセスで継続します。

動的設定変更に対応している項目は以下となります。

動的設定変更に関する設定及び状態

動的設定変更に関する以下の設定及び状態が追加になります。

上記設定は、運用管理ツールの以下の箇所で設定・参照することができます。

MOの属性名は以下となります。

ログ出力

動的設定変更で出力するTPSメッセージは、 [ メッセージ一覧 > 3. TPシステム > 3.2. メッセージ一覧 > 3.2.4. イベントログ出力されないメッセージ ] を参照してください。

Caution

7.1.7.11. 予備スレッドの事前生成と活性化

予備スレッドの事前生成と活性化の設定を以下に示します。
予備スレッドはプロセス起動時は閉塞状態となっており、オペレーションの実行を行うことができません。
予備スレッドの閉塞・閉塞解除は、[TPシステム]-[アプリケーショングループ名]-[プロセスグループ名]を右クリックし、表示されたメニューより[動的多重度変更]の"スレッドの多重度"を設定することにより閉塞解除できます。このとき、"プロセス多重度"の設定は必須です。
スレッドの多重度は "スレッド数"+"予備スレッド数"の範囲で設定してください。

図7.1.7.11-1
図7.1.7.11-1

図7.1.7.11-2
図7.1.7.11-2

予備スレッド数は運用管理ツールから設定する場合、

で設定することができます。
また、運用管理コマンドからは以下のMOの属性に設定します。

Memo
設定を反映するにはアプリケーショングループの再起動が必要です。

7.1.7.12. アプリケーショングループ停止処理時間の短縮

プロセスグループの強制停止処理に即時強制停止する設定を以下に示します。
運用管理ツール上の設定項目は以下の通りとなります。

上記に対応するMOの属性は、

となります。

Memo
TPシステム稼働中に設定を変更するとエラーになります。

Caution
プロセスを即時停止するを設定し、アプリケーショングループまたはプロセスグループを強制停止した場合、後処理を一切行わず即時停止します。
停止時にログ採取を行わないため、障害解析に支障が出る可能性があります。

7.1.7.13. IIOPリスナ

RMI-IIOPのリクエストを処理するリスナです。統合運用管理ツールで設定できる項目は次の通りです。

表7.1.7.13-1
タブ表記 項目 説明 既定値
リスナ 暗号化しない通信を行う IIOP通信において平文ポートを使用するかどうかを指定します。 する
リスナ 平文ポート番号 IIOP通信における平文ポート番号を指定します。初期値についてはドメイン作成時に設定した値となります。全TPシステムで使用する全てのリスナポート番号の中で一意に設定してください。 5151
リスナ 着呼時のIPアドレスの待ち受け指定 着呼時のIPアドレスの待ち受け指定をします。 IPv4とIPv6
上限設定 利用可能な同時接続クライアント数 利用可能な同時接続クライアント数を指定します。また、TPシステム稼働中に設定を変更するとエラーになります。 100
上限設定 AP応答監視タイマ AP応答監視タイマを秒単位で指定します。 2147483秒
上限設定 同時受付オペレーション数 IIOPリスナで同時に受け付けるオペレーション数を指定します。 -1
クライアント制御 クライアント無通信監視を行う クライアント無通信監視を行うかどうかを指定します。 しない
クライアント制御 クライアント無通信監視間隔 クライアント無通信監視間隔を秒単位で指定します。 600秒
クライアント制御 クライアントアライブチェックを行う クライアントアライブチェックを行うかどうかを指定します。 しない
クライアント制御 クライアントアライブチェック間隔 クライアントアライブチェック間隔を秒単位で指定します 600秒
クライアント制御 送信データ分割サイズ 送信データ分割サイズを指定します 4488Bytes
クライアント制御 接続要求最大保留数 接続要求最大保留数を指定します。 5
クライアント制御 1プロセス当たりの多重度 1プロセス当たりのリクエスト処理同時実行多重度を指定します。 128
SSL SSLを使用する IIOP通信においてSSLを使用するかどうかを指定します。また、TPシステム稼働中に設定を変更するとエラーになります。しない
SSL SSLライブラリ 使用するSSLライブラリを指定します。TPシステム稼働中に設定を変更するとエラーになります。 OpenSSL
SSL SSLポート番号クライアント認証なし IIOP通信においてSSLポート番号クライアント認証なしのポートを使用するかどうか指定します。 しない
SSL SSLポート番号クライアント認証なし IIOP通信におけるSSLポート番号もしくはクライアント認証なし時のポート番号を指定します。全TPシステムで使用する全てのリスナポート番号の中で一意に設定してください。 -
SSL SSLポート番号クライアント認証あり IIOP通信においてSSLポート番号クライアント認証ありのポートを使用するかどうか指定します。 しない
SSL SSLポート番号クライアント認証あり IIOP通信におけるSSLポート番号クライアント認証あり時のポート番号を指定します。全TPシステムで使用する全てのリスナポート番号の中で一意に設定してください。 -
SSL 認証情報が存在しない場合の接続可否 SSL通信においてクライアント認証情報が送られない場合に接続を許可するかしないかを設定します。 しない
OpenSSL 秘密鍵ファイル名 秘密鍵ファイル名を指定します。OpenSSLを利用する場合は以下の属性も必ず指定してください。 -
OpenSSL 証明書ファイル名 証明書ファイル名を指定します。 -
OpenSSL 信頼するCAの証明書ファイル名 信頼するCAの証明書ファイル名を指定します。 -
OpenSSL 証明書ファイルのパスワード サーバ認証で使用する証明書ファイルのパスワードを指定します。 -
SecureWare 鍵識別子 SecureWare/セキュリティパック の鍵識別子を指定します。SecureWare/セキュリティパック を利用する場合は必ず指定してください。 -
状態 状態 状態を表示します。 -
状態 アライブチェックモニタの自動登録を行う アライブチェックモニタの自動登録を行う する
状態 監視間隔 監視間隔(ミリ秒単位) 30000ms
状態 イベントを連続発生させる間隔 監視対象リソースがアライブ中でない状態が続く場合にイベントを発生させる間隔(ミリ秒単位)。0の場合このイベントは発生しない。 0

SSL通信を行うための設定手順は次の通りです。

  1. TPシステムを停止します。
  2. [SSL]-[SSLを使用する]にチェックを入れます。
  3. クライアント認証を行わない場合、[SSL]-[SSLポート番号クライアント認証なし]にチェックを入れ、ポート番号を指定します。クライアント認証を行う場合、[SSL]-[SSLポート番号クライアント認証あり]にチェックを入れ、ポート番号を指定します。必ずどちらかのポート番号を指定する必要があります。
  4. OpenSSLを使用する場合、[SSLOpenSSL]-[秘密鍵ファイル名], [証明書ファイル名], [信頼するCAの証明書ファイル名]を全て指定します。フルパス指定不可ですのでファイル名のみ指定してください。セキュリティパックを使用する場合、[SSLSecureWare]-[鍵識別子]を指定します。
  5. 設定完了後、更新ボタンを押します。
  6. ${INSTANCE_ROOT}\config\tpsystem 配下に秘密鍵ファイル、証明書ファイル、信頼するCAの証明書ファイルを置きます。
  7. 名前サーバへの登録が「永続的に扱う」設定である場合、名前サーバにIORを登録します。
  8. TPシステムを起動します。

7.1.8. 統計情報(統合運用管理ツールでの表示)

統合運用管理ツールから確認できるスレッド情報、CPU情報、キュー情報、接続クライアント情報に関して説明します。

7.1.8.1. スレッド情報

起動しているプロセスグループのスレッド情報を見ることができます。

* Linux版、Solaris版ではCPU時間取得機能を提供していません。
  1. 統合運用管理ツールよりドメインと接続します。
  2. ツリービューよりプロセスグループを選択します。
  3. リストビューより動作情報を選択します。
表7.1.8.1-1
説明
pid プロセスID
tid スレッドID
thno スレッド論理ID
  • MAIN:メインスレッド
  • RECV:内部受信スレッド
  • SEND:内部送信スレッド
  • 番号:ユーザスレッド
状態 スレッドステータス
  • APPROLOG:APプロログ呼び出し中
  • APEPILOG:APエピログ呼び出し中
  • THPROLOG:スレッドプロログ呼び出し中
  • THEPILOG:スレッドエピログ呼び出し中
  • TPPENTRY:TPPエントリ呼び出し中
  • ABORTEXIT:異常終了出口呼び出し中
  • RUNNING:制御スレッド実行中
  • WAIT:イベント待ち
  • STOPPED:スレッド停止
モジュール モジュール名
インタフェース インタフェース名
オペレーション オペレーション名
経過時間 実行時間(ミリ秒)
クライアント 接続クライアントIPアドレス
ユーザCPU時間 該当スレッドが現在までに消費したユーザモードCPU使用時間
ユーザCPU時間 該当スレッドが現在までに消費したユーザモードCPU使用時間
システムCPU時間 該当スレッドが現在までに消費したシステムモード(カーネルモード)CPU使用時間
CPU使用率 該当スレッドのCPU使用率(直近の情報採取間隔時間が対象)
情報採取間隔 前回の情報採取からの経過時間。最初の情報採取の場合は、プロセス起動時からの経過時間

7.1.8.2. プロセス情報

起動しているプロセスグループのプロセス情報を見ることができます。

* Linux版ではCPU時間取得機能を提供していません。
* Solaris版ではメモリ情報取得機能を提供していません。
  1. 統合運用管理ツールよりドメインと接続します。
  2. ツリービューよりプロセスグループを選択します。
  3. リストビューより動作情報を選択します。
表7.1.8.2-1
説明
pid プロセスID
CPU使用率 該当プロセスの現在のCPU使用率(%)
CPU時間 該当プロセスが現在までに消費したCPU時間(ミリ秒)
ユーザCPU時間 該当プロセスが現在までに消費したユーザCPU時間(ミリ秒)
システムCPU時間 該当プロセスが現在までに消費したシステムCPU時間(ミリ秒)
コンテナ状態 該当プロセスの起動/停止処理がどこまで進んでいるかの状態
仮想メモリ使用量 該当プロセスの仮想メモリ使用量
物理メモリ使用量 該当プロセスの物理メモリ使用量

7.1.8.3. キュー情報

起動しているTPシステム全体のキュー情報を見ることができます。

  1. 統合運用管理ツールよりドメインと接続します。
  2. ツリービューより[キュー]を選択します。
  3. リストビューよりキュー情報を選択します。
表7.1.8.3-1
説明
名前 キュー名
優先度 実行優先度
滞留数 現在のキュー滞留数

7.1.8.4. クライアントセッション情報

TPシステムと接続しているクライアント情報を見ることができます。

  1. 統合運用管理ツールよりドメインと接続します。
  2. ツリービューより[クライアントセッション]を選択します。
  3. リストビューよりクライアント情報を選択します。
表7.1.8.4-1
説明
クライアントID 論理端末ID
IPアドレス 接続クライアントIPアドレス
ホスト名 接続クライアントホスト名(逆引きをしない設定になっている場合は表示されません)
接続アプリケーショングループ名 接続アプリケーショングループ名
接続状態 接続状態
  • Not connected:未接続
  • Now accepting...:着呼処理中
  • Now connecting...:センタ発呼中
  • Connecting:接続中
  • Now disconnecting...:切断処理中
  • Trouble:トラブル
接続時間 接続経過時間(秒)

7.1.9. 統計情報(ジャーナル)

ジャーナルはWebOTXの稼働状況を評価するための性能及び統計情報を各種レポートとして提供します。 レポートの種類は以下の通りです。


ジャーナル採取の手順は以下のようになります。

  1. 準備
    下記で説明する各コマンドはWindowsでは${AS_INSTALL}\Trnsv\bin、UNIXでは${AS_INSTALL}/Trnsv/commandにあります。 UNIX版のWebOTXをご使用で、且つ、WebOTX運用ユーザを設定している場合は、WebOTX運用ユーザでコマンドを実行して下さい。

  2. ジャーナル採取の設定
    ジャーナルの採取は統合運用管理ツールで指定できます。 なお、ここで指定するファイルサイズは以下を目安として下さい。
    SIZE(MB) = 0.084nt + 0.028mt + 0.009gt
    

  3. ジャーナル採取
    WebOTXを再起動するとジャーナルの採取を始めます。 ジャーナル情報を格納したファイル(ジャーナルファイル)はカタログディレクトリ下のjnlディレクトリにjnl000x.logという名前で作られます(xは1〜3)。 ファイルはサイクリックに使用されます。 次のファイルに移る契機は指定された容量に達した時、もしくは、WebOTXを再起動した時です。

  4. ジャーナルの状態表示
    現在のジャーナルの採取状況はjnldispコマンドで確認できます。 コマンドの書式は以下の通りです。
    jnldisp [-C journaldir]
    

    出力例を以下に示します。
    ********** Control File Infomation **********
      Status      : Active
      Groupnum    : 1
      Filenum     : 3
      Filesize    : 10
    ****** Group 0 Journal File Infomation *****
    
     ***** Current Journal File *****
      number       : 2
      PathName     : C:\Program Files\NEC\WebOTX\domains\domain1\config\tpsystem\jnl\jnl0002.log
      record count : 1
      Save Flag    : 0 : (Not Save)
      FirstDate    : 2005.04.12    FirstTime    : 10:10:36
      LastDate     : 2005.04.12    LastTime     : 10:10:36
    
      number       : 1
      PathName     : C:\Program Files\NEC\WebOTX\domains\domain1\config\tpsystem\jnl\jnl0001.log
      record count : 67
      Save Flag    : 0 : (Not Save)
      FirstDate    : 2005.04.11    FirstTime    : 15:37:16
      LastDate     : 2005.04.11    LastTime     : 21:02:16
    
      number       : 3
      PathName     : C:\Program Files\NEC\WebOTX\domains\domain1\config\tpsystem\jnl\jnl0003.log
      record count : 99
      Save Flag    : 1 : (Saved)
      FirstDate    : 2005.04.11    FirstTime    : 15:22:16
      LastDate     : 2005.04.11    LastTime     : 15:34:51
    
    
    Filenum:ファイル数
    FileSize:ファイルサイズ(単位Mbyte)
    *** Current Journal File ***
    
    ジャーナルファイルが新しい順に表示されます。 最初に表示されるジャーナルファイルをカレントジャーナルファイルと言います(例ではjnl0002.logのファイル)。

  5. ジャーナルファイルの退避
    ジャーナルファイルはそのままではサイクリックに使用されてしまうため、定期的に退避する必要があります。 退避は単にコピーコマンドを使用するかもしくはjnlsaveコマンドを使用します。 コマンドはWindowsでは${AS_INSTALL}\Trnsv\bin、UNIXでは${AS_INSTALL}/Trnsv/commandにあります。 jnlsaveコマンドを使うと複数のジャーナルファイルを1つにまとめることができます。 また、使用中のカレントジャーナルファイル(ジャーナルが動作中の時のカレントジャーナルファイル)は、jnlsaveコマンドで一旦退避しないと編集できません。
    ジャーナル退避のコマンドの書式は以下の通りです。
    jnlsave -n SystemName [-C journaldir] [-d savefilename] [file_num]
    

  6. ジャーナルファイルの編集
    各種レポートを編集するために、ジャーナル編集コマンド(wojnledt)を実行します。 コマンドはWindowsでは${AS_INSTALL}\Trnsv\bin、UNIXでは${AS_INSTALL}/Trnsv/commandにあります。 ジャーナル編集コマンドの書式は以下の通りです。
    wojnledt [-I InputFile] [-a AppricationServer] [-p ProcessGroup] [-t OutputType] [-x SuppressionType] [-l TimeLength] [-r ResponseTime] [-L LinesPerPage] [-O Output] [-D TargetTime]
    

ジャーナルのファイル数またはファイルサイズの変更手順は次の通りです。

  1. TPシステムを停止します。
  2. ファイル数を変更する場合、${INSTANCE_ROOT}/config/tpsystem/jnlwrt.ped ファイルを開き、-F オプションの引数を書き換えます。既定値は3で、2 から 100 の範囲で指定可能です。
  3. ファイルサイズを変更する場合、統合運用管理ツールでTPシステムをクリックし、右ページの[ジャーナルの設定]タブの[ファイルサイズ]で設定します。
  4. ${INSTANCE_ROOT}/config/tpsystem/jnl/journal.ctl ファイルを削除します。削除すると、それまで採取していたジャーナル情報は削除されます。設定変更前のジャーナルが必要な場合、事前にジャーナルを採取してください。
  5. TPシステムを起動します。

7.1.10. 統計情報(オペレーションジャーナル)

オペレーションジャーナルは、システムの稼働状況・統計をオペレーション単位でレポート出力します。 オペレーションごとの実行時間情報(平均値・最大値・最小値)、オペレーションの実行回数、プロセスグループごとの稼動スレッド数(起動中のスレッドのうち実際にオペレーションを実行しているスレッド数)を知ることができます。 それぞれの情報について、全体の統計と単位時間ごとの推移がレポート出力されます。

V6.3からはこれに加えて、オペレーションのCPU使用時間(ユーザモード、カーネルモード)の平均・最大・最小、プロセスグループのCPU使用率・CPU使用時間(ユーザモード、カーネルモード)をレポート出力します。

* Linux版ではCPU情報出力機能を提供していません。
* HP-UX版ではCPU時間がOSの制限により秒単位で出力されます。

またオペレーション情報のサマリに「実行時間上限推奨値」が追加されました。 実行時間上限を設定する際の参考にしてください。

ジャーナルに蓄積された各オペレーションの実行時間データは、CVS形式のファイルで出力されます。 データはデータ種別(平均時間、最大時間、最小時間、呼び出し回数、最大同時稼動スレッド数、平均同時稼動スレッド数)ごとに編集可能です。 編集時刻、情報採取時間帯や、全体の情報がファイルの先頭に表示されます。 一度も実行されていないオペレーションについては表示されません。

コマンドはWindowsでは${AS_INSTALL}\Trnsv\bin、UNIXでは${AS_INSTALL}/Trnsv/commandにあります。 UNIX版のWebOTXで、且つWebOTX運用ユーザを設定している場合は、WebOTX運用ユーザでコマンドを実行して下さい。

7.1.10.1. オペレーションジャーナル編集コマンド

オペレーションジャーナル編集コマンドの使用方法は以下のとおりです。

> woopjnledt  [-I InputFile] [-O Output] [-type EditType] [-intvl TimeLength] [-time TargetTime] [-line LinesPerPage] [-ag ApplidationGroup][-pg ProcessGroup] [-cmp Component] [-rep RepositoryID] [-op Operation] [-txid TXID] [-txn TxIDNumber]  [-c CatalogDir]

使用例:

  1. まずジャーナルを待避します。
    jnlsave -n MySystem -C ${INSTANCE_ROOT}\config\tpsystem\jnl -d jnlsv.log
    
  2. 待避したジャーナルをオペレーションジャーナル編集コマンドにより編集します。
    woopjnledt -I jnlsv.log -c ${INSTANCE_ROOT}\config\tpsystem -O domain1jnl.csv
    

以下のオプションは必ず指定するようにしてください。

-c

カタログディレクトリ(${INSTANCE_ROOT}/config/tpsystem)を絶対パスで指定します。 省略時はプロセスグループ名、オペレーション名、起動時設定スレッド数、スレッド使用率などの一部情報が出力されなくなります。 スレッド数などの設定の変更を行っていない場合はカタログディレクトリを指定することを推奨します。

以下のオプションで編集間隔を指定することができます。

-intvl

時系列レポートの時間間隔(単位:分、1から999まで)を指定します。 省略時は30分となります。 「TPシステム」-「情報採取間隔」で設定された情報採取間隔より短い値を設定すると、編集結果が不正確になるのでご注意ください。

ファイル入出力に関するオプションには以下があります。

-I

入力ファイルのパス名を255文字以内で指定します。 省略時はカレントディレクトリのjnlsv.log(jnlsaveコマンドで生成)となります。 ジャーナルファイルとその退避ファイルを入力ファイルとして指定できますが、使用中のカレントジャーナルファイルは指定できません。

-O

レポートの出力先ファイル名を指定します。 省略時は標準出力に出力します。

以下のオプションはデータ量が多いときに使用してください。

情報のフィルタリングを行うオプションには以下があります。

-type

編集出力するレポートの種別を数値(01〜15)で指定します。 ","(カンマ)をデリミタとした複数指定できます。 省略時は全レポートを出力します。 レポートナンバー01がオペレーション情報サマリ、02がプロセス情報サマリ、03が平均値、04が最大値、05が最小値、06がオペレーション実行回数、07が平均同時稼動スレッド数、08が最大同時稼動スレッド数、20がCPU使用率、21がプロセスCPU使用時間(ユーザモード) 、22がプロセスCPU使用時間(カーネルモード)、30がオペレーションCPU使用時間平均(ユーザモード)、31がオペレーションCPU使用時間最大(ユーザモード)、32がオペレーションCPU使用時間最小(ユーザモード)、33がオペレーションCPU使用時間平均(カーネルモード)、34がオペレーションCPU使用時間最大(カーネルモード)、35がオペレーションCPU使用時間最小(カーネルモード)のそれぞれ集計です。
指定例:
01,02,03

-time

編集対象日時をdate1/time1_date2/time2で指定します。 date1(開始日)、date2(終了日)はyyyy.mm.ddの形式で指定します。 time1(開始時)、time2(終了時)はhh:mmの形式で指定します。 省略時は全レコードを編集します。

-ag

編集するアプリケーショングループを指定します。 指定されたアプリケーショングループに含まれるオペレーション、またはプロセスのみを編集します。 アプリケーショングループは複数指定できます。 その場合はカンマで区切ってください。 省略時は全てのオペレーション、またはプロセスについて編集します。 -pg,-txid,-rep,-cmp,-opオプションと共に使用された場合は、全ての条件に適合するオペレーションについて編集します。 本オプションを使用するには、-cオプションによりカタログディレクトリを指定する必要があります。

-pg

編集するプロセスグループを指定します。 指定されたプロセスグループに含まれるオペレーション、またはプロセスのみを編集します。 プロセスグループは複数指定できます。 その場合はカンマで区切ってください。 省略時は全てのオペレーション、またはプロセスについて編集します。 -ag,-txid,-rep,-cmp,-opオプションと共に使用された場合は、全ての条件に適合するオペレーションについて編集します。 -cによりカタログディレクトリが指定されていない場合、プロセスについては指定プロセスのみの編集となりますが、オペレーションについては全てのオペレーション情報を編集します。

-txid

編集するオペレーションをTxIDで指定します。 TxIDは複数指定することができます。 その場合はカンマで区切ってください。 省略時は全てのオペレーションを編集します。 -ag,-pg,-cmp,-rep,-opオプションと共に使用された場合は、全ての条件に適合するオペレーションについて編集します。

-rep

編集するオペレーションをリポジトリIDで指定します。 指定されたリポジトリIDを持つ全てのオペレーションを編集します。 リポジトリIDは複数指定することができます。 その場合は、カンマで区切ってください。 省略時は全てのオペレーションを編集します。 このオプションを利用するためには、-cオプションによりカタログディレクトリが指定されている必要があります。 -ag,-pg,-cmp,-op,-txidオプションと共に使用された場合は、全ての条件に適合するオペレーションについて編集します。

-cmp

編集するオペレーションをコンポーネント名で指定します。 指定されたコンポーネント名を持つ全てのオペレーションを編集します。 コンポーネント名は複数指定することができます。 その場合は、カンマで区切ってください。 省略時は全てのオペレーションを編集します。 このオプションを利用するためには、-cオプションによりカタログディレクトリが指定されている必要があります。 -ag,-pg,-rep,-op,-txidオプションと共に使用された場合は、全ての条件に適合するオペレーションについて編集します。

-op

編集するオペレーションをオペレーション名で指定します。 指定されたオペレーション名を持つ全てのオペレーションを編集します。 オペレーション名は複数指定することができます。 その場合は、カンマで区切ってください。 省略時は全てのオペレーションを編集します。 このオプションを利用するためには、-cオプションによりカタログディレクトリが指定されている必要があります。 -ag,-pg,-cmp,-rep,-txidオプションと共に使用された場合は、全ての条件に適合するオペレーションについて編集します。

テーブルの整形をするオプションです。

-line

レポートの1ページあたりの行数を指定します。 指定可能な範囲は30〜100000です。 省略された場合は、txt形式で60行、CSV形式で100000行となります。

-txn

1つの表に表示するオペレーションの数を指定します。 指定可能な範囲は1〜10000です。 指定された数を越えるオペレーションが存在する場合は、別の表に表示します。 省略された場合は、全てのオペレーションが1つの表に表示されます。

-txt

テキスト形式で編集します。 プロセスグループ名は先頭の14文字までしか表示されません。 省略した場合はCSV形式で出力します。

7.1.10.2. オペレーションジャーナルの読み方

オペレーションジャーナル編集コマンドでは、以下の17種類のテーブルを出力します。

テーブルの読み方は以下のようになります。 ここではオペレーション情報統計サマリとプロセスグループ情報統計サマリを例にしています。 以下に示すテーブルはCSV形式で編集されたものです。

オペレーション実行時間統計サマリのレポートは以下のように出力されます。

OperationJournal
図7.1.10.2-1

各値はそれぞれ秒単位です。

実行時間とCPU使用時間に差がある場合は、データベース処理やネットワーク関連など何らかの「待ち」が生じていると推測されます。 オペレーションジャーナルからCPUを多く使用しているオペレーションを特定することもできます。

プロセスグループ情報統計サマリのレポートは以下のように出力されます。

ProcessJournal
図7.1.10.2-2

どのプロセスグループでCPUを消費しているかがオペレーションジャーナルよりわかります。 障害解析や、システムの稼働状況把握に役立ててください。

ここでいうスレッド稼働率は、[稼動スレッド数/(稼動可能なプロセス数×稼動可能なスレッド数)]となります。 これは多重度設定が適切かどうかの指標になります。

7.1.10.3. オペレーションジャーナル採取間隔時間の設定

オペレーションジャーナルの情報採取間隔は1分から1440分(24時間)の間で指定可能です。 デフォルトは5分となっています。 この情報採取間隔がオペレーションジャーナルの最小編集単位となります。 情報採取間隔を変更したい場合は以下の設定を変更してください。

「TPシステム」-「運用アシスタント」タブ-「情報採取間隔」

この設定は運用アシスタント機能でも使用されます。

7.1.10.4. 補足事項

7.1.11. 通信情報(イベントジャーナル)

オペレーションの実行の過程で起きる障害については、イベントジャーナルを追っていくことで、どこで障害が発生しているか調べることができます。 また、イベントジャーナルではクライアントからの受信開始から応答の送信終了までを確認できるため、障害箇所がサーバ側なのかそうではないのか(ネットワークやクライアント側なのか)を切り分けることができます。

イベントジャーナルの編集は統合運用管理ツールから実行できます。 編集の対象となる期間は前回TPシステム起動時から編集実行時までを1世代分として、3世代分まで遡って編集することが出来ます。 TPシステムを終了した状態で編集を実行しても前回の運用中の情報が採取できます。 ログは次の箇所に出力されます。

[世代数を指定しない、現在稼動しているシステムを選択した場合]
${INSTANCE_ROOT}\logs\tpsystem\logcollect\{日付10桁}\{システム名}_woejout{数字}.log
[世代数を指定した場合]
${INSTANCE_ROOT}\logs\tpsystem\logcollect\{日付10桁}\{システム名}_woejout_{世代数}_{数字}.log

以下に主な採取ポイントを示します。 空欄は採取項目がないか、もしくは開発向けの内部情報です。 また、採取ポイントは他にもありますが、それらも開発向けの内部情報です。

表7.1.11-1
コンポーネント 種別 項1 項2 項3 項4 項5 項6 項7 項8 項9 項10 項11 項12
LSN 通信リスナ 01 キューアウト時 キューID

端末ID 受信長

TXシーケンス番号

SPA長
02 キューイン時 キューID 端末ID
TXシーケンス番号



TX名


03 受信完了時 端末ID 受信長
エラーコード







04 送信完了時 端末ID 送信長
エラーコード







05 端末接続時 端末ID IPアドレス









06 端末切断時 端末ID










07 内部情報











08 内部情報











09 内部情報











10 内部情報












表7.1.11-2
コンポーネント 種別 項1 項2 項3 項4 項5 項6 項7 項8 項9 項10 項11
TPLIB サーバAP (ベースライブラリ) 01 OBJMNG呼び出し時(※1) TX名

端末ID/VDID

TXシーケンス番号

リトライカウント
02 API発行時
6 TPSRestart()








7 TPSAbort() abort種別







03 内部情報










04 内部情報










05 Commit/Rollback実行情報(※2) TX名 CANCEL(1)orCOMMIT(0) DBのCOMMIT/ROLLBACKする(1)orしない(0) TX完了時(1)orTXリスタート時(0) TXシーケンス番号





06 キューイン時

TX名 キューID TXシーケンス番号 端末ID




07 キューアウト時

TX名 キューID TXシーケンス番号 端末ID




08 OBJMNG戻り時(※1) TX名

端末ID/VDID TXシーケンス番号 終了コード(※3)





表7.1.11-3
コンポーネント 種別 項1 項2
OBJMNG サーバAP(オブジェクトマネージャ) 01 C++ Factoryオブジェクト TX名 call in
オブジェクト呼び出し時
call out
戻り時
02 C++ ステートレスオブジェクト TX名 call in
オブジェクト呼び出し時
call out
戻り時
03 C++ ステートフルオブジェクト TX名 call in
オブジェクト呼び出し時
call out
戻り時
06 Java Factoryオブジェクト TX名 call in
オブジェクト呼び出し時
call out
戻り時
07 Java ステートレスオブジェクト TX名 call in
オブジェクト呼び出し時
call out
戻り時
08 Java ステートフルオブジェクト TX名 call in
オブジェクト呼び出し時
call out
戻り時

表7.1.11-4
コンポーネント 種別 項1
USER サーバAP(ユーザ実装部) 01〜15 ユーザ指定 ユーザ指定

TX処理における上記コンポーネント(通信リスナ、サーバAP)の位置づけを以下に示します。 図中の数字は上表での種別の数字に対応しています。

EventJournal
図7.1.11-1

次に編集形式を以下に示します。

Event Journal Ver6.2                          05/04/12
(イベントジャーナルのバージョン)              (編集日)

System name : MySystem
Last Output Time = 05/04/12:11:16:42 (情報の最終出力時刻)

DATE      TIME             PID    THREAD  RECNO  BLOCKNO  COMP   TYPE  ITEM1                ITEM2  ...
05/04/12  10:05:26.622000  02728  65535   13832  000      TPLIB  01    Lower(IDL:Loop:1.0)  sample
05/04/12  10:05:26.782000  02728  65535   13837  000      TPLIB  02    2                    1
(日付)    (時刻)           (プロセスID)   (レコード通番)  (コンポーネント名)                (項2)
                                  (スレッドID)   (ブロック#)     (種別)(項1)

コマンドによるイベントジャーナルの編集

イベントジャーナルの編集はコマンドでも実行可能です。 但しWebOTXが動作しているマシン上で直接コマンドを実行する必要があります。 コマンドはWindowsでは${AS_INSTALL}\Trnsv\bin、UNIXでは${AS_INSTALL}/Trnsv/commandにあります。 UNIXでWebOTXの運用ユーザを設定している場合は必ず運用ユーザでコマンドを実行する必要があります。 また、運用管理コマンドからの実行も可能です。

コマンドは下記の通りです。

[コマンドからの実行]

> woejedit catalogpath maxline outpath systemname

[運用管理コマンドからの実行]

otxadmin> invoke tpsystem.editEventJournal maxline

実行例

[コマンドからの実行]

> woejedit /opt/WebOTX/domains/domain1/config/tpsystem 30000 /opt/WebOTX/domains/domain1/logs/tpsystem/ejout.log MySystem

[運用管理コマンドからの実行]

otxadmin> invoke tpsystem.editEventJournal 30000

この場合、実際の出力ファイルはejout1.log, ejout2.log, ejout3.log … となります。

コマンドによる前世代のイベントジャーナルの編集

イベントジャーナルの編集は基本的に1世代分(前回TPシステム起動時からコマンド実行時まで)の情報を編集します。 統合運用管理ツールによる編集と同じく、コマンドによる編集でも3世代前までの情報を編集することが可能です。 また、運用管理コマンドからの実行も可能です。

コマンドは下記の通りです。

[コマンドからの実行]

> woejedit catalogpath maxline outpath systemname savedfile

[運用管理コマンドからの実行]

otxadmin> invoke tpsystem.editEventJournal maxline generation

実行例

[コマンドからの実行]

> woejedit /opt/WebOTX/domains/domain1/config/tpsystem 30000 /opt/WebOTX/domains/domain1/logs/tpsystem/ejout.log MySystem #0msj

[運用管理コマンドからの実行]

otxadmin> invoke tpsystem.editEventJournal 30000 1

この場合、1世代前のイベントジャーナルを編集します。

なお、3世代分のイベントジャーナルの編集前ファイルは

${INSTANCE_ROOT}/config/tpsystem/tmp/saveディレクトリ
に退避しています。
ファイルサイズ

イベントジャーナル採取データはTPモニタにより定期的に${INSTANCE_ROOT}/config/tpsystem/tmpディレクトリ下のファイルmsjに出力されます。

msjファイルのファイルサイズは設定変更可能(既定値10MB)であり、そのサイズまでアペンド出力します。 ファイルサイズ上限に達した場合はサイクリックに出力されます。 設定は統合運用管理ツールの[TPシステム]をクリックし、右ページの[イベントジャーナル]-[ファイルサイズ]で行ってください。

7.1.12. キュー滞留情報

クライアントからのリクエストは通信リスナが受付を行い、アプリケーション側のキューに一旦格納されます。 キューはプロセスグループ単位のキューとプロセス単位のキューが作成されますが、ステートレスの場合はプロセスグループ単位のキューが、ステートフルの場合はプロセス単位のキューが使用されます。 アプリケーション側では処理スレッドに空きがあればすぐにリクエストをキューから取りだして処理しますが、スレッドが塞がっている場合にはしばらくキューに滞留した状態が続くことになります。 以下では、このキュー滞留数を確認する方法を説明します。

otxadminコマンドによるキュー滞留数の確認

otxadminコマンドを用いてキューの状態を確認できます。

quewrtコマンドによるキュー滞留数の確認

このコマンドで確認できるのはプロセスグループ単位での滞留リクエスト数(ステートレスの場合)、プロセス単位での滞留リクエスト数(ステートフルの場合)です。

コマンドはWindowsでは${AS_INSTALL}\Trnsv\bin、UNIXでは${AS_INSTALL}/Trnsv/commandにあります。 UNIX版のWebOTX使用の場合は、WebOTX運用ユーザでコマンドを実行して下さい。

> quewrt -n システム名 -M 収集間隔 -C 収集回数 [-f ファイル名]

結果表示例:

MODE QUE-NAME                          MSG-NUM  POOL-NAME  CONECT DEQUE
  Q  STPCTLQUE28752                          0       ea60     ON    ON
  Q  QUE_TIMER                               0   746d6d70     ON    ON
  Q  TPproc029983                            0       ea60     ON    ON
  Q  java                                    0       ea60     ON    ON
  Q  _OTSLink                                0       ea60     ON    ON
  Q  JOURNALQUE0                             0      13880     ON    ON
  Q  SENDTPPQUE                              0       ea60     ON    ON
  Q  STPRCVQUE                               0       ea60     ON    ON
  Q  TPproc028754                            0       ea60     ON    ON
  Q  IIOPLISTENER                            0       ea60     ON    ON
  Q  TPproc028758                            0       ea60     ON    ON
contpsコマンドによるキュー滞留数の確認

このコマンドで確認できるのはオペレーション単位での滞留リクエスト数です。

このコマンドはWebOTX運用ユーザで実行してください。 コマンドはWindowsでは${AS_INSTALL}\Trnsv\bin、UNIXでは${AS_INSTALL}/Trnsv/commandにあります。

> contps -n システム名 DI N TR

結果表示例:

********** TPBASE TR STATUS ****************************************************
TxID    :処理状態:Tx滞留数  :総Tx数    :最小応答:最大応答:平均応答:応答合計
LOX000  :IDLE    :         0:         0:      -1:      -1:      -1:        -1
UKN000  :IDLE    :         0:         0:      -1:      -1:      -1:        -1
APR000  :IDLE    :         0:         0:      -1:      -1:      -1:        -1
ABAAAB  :START   :         0:   1022991:       3:     503:       4:   4727079
ABAAAA  :IDLE    :         0:         0:      -1:      -1:      -1:        -1
ABaa00  :IDLE    :         0:         0:      -1:      -1:      -1:        -1
ABaa01  :IDLE    :         0:         0:      -1:      -1:      -1:        -1
ABaa20  :IDLE    :         0:         0:      -1:      -1:      -1:        -1
ABaa21  :IDLE    :         0:         0:      -1:      -1:      -1:        -1
********** END OF TR STATUS ****************************************************

7.1.13. 運用アシスタント

V6.3 から、オペレータの運用を支援する自律運用機能「運用アシスタント」を実現しました。 運用アシスタントに関する各種設定について以下に説明します。

7.1.13.1. 運用アシスタント機能全体に関する設定

運用アシスタント機能全体に関する設定について説明します。

なお、本節では統合運用管理ツールからの操作をメインに説明します。

設定箇所について

統合運用管理ツールから設定する場合の設定箇所は、「TPシステム」ノードの「運用アシスタント」タブをクリックしてください。 通常はここで一括して設定します。

アプリケーショングループ、プロセスグループ、モジュール、オペレーション単位で細かく設定することも可能です。 個別に設定したい場合は、統合運用管理ツールの左上のメニュー「システム」−「システム設定」をクリックし、画面表示の「属性の表示レベル」と「操作の表示レベル」を「詳細レベルの情報を表示」に変更してください。 すると各ノードに「運用アシスタント」タブが表示されます。

以下の項目をまず確認してください。

以下の項目は必要であれば見直してください。

以下の操作により、内部的に蓄積された情報を一旦クリアすることができます。

以下の操作により、運用アシスタント機能の利用有無が設定できます。

7.1.13.2. 多重度の最適化支援

多重度最適化支援機能の設定について以下に説明します。

多重度最適化支援機能ではシステムの稼働状況を解析し、多重度の増減を推奨、または自動変更します。 多重度の増減が推奨される場合は、以下のメッセージが統合運用管理ツールに通知され、イベントログ/syslog, webotx_agent.log(webotx_tpmmgr.log)に出力されます。 同時にスタックトレースを3秒間隔5回でアプリケーションログに出力します。

"OTX20220100 プロセスグループxxxの多重度が不足しています。プロセス数/スレッド数の増加を検討してください。"
"OTX20220001 プロセスグループxxxは多重度を減らしても同じ処理能力を維持できます。プロセス数/スレッド数の削減を検討してください。もしくは予備プロセス数を変更してください。"
"OTX20220100 The multiplicity of process group xxx is insufficient. Please examine an increase in the the number of process or threads."
"OTX20220001 Even if the multiplicity is decreased, process group xxx can maintain the same processing performance. Please examine an decrease in the the number of process or threads, or modify backup process count."

[注] イベントIDがV6.3から変更になりました(OTX20220000 → OTX20220100)

多重度の自動変更機能を利用している場合は、以下のメッセージとなります。

"OTX20220010 プロセスグループxxxの多重度が不足しています。プロセス数をaに変更しました。"
"OTX20220011 プロセスグループxxxは多重度を減らしても同じ処理能力を維持できます。プロセス数をaに変更しました。"
"OTX20220010 The multiplicity of process group xxx is insufficient. So the count of process is changed to a."
"OTX20220011 Even if the multiplicity is decreased, process group xxx can maintain the same processing performance. So the count of process is changed to a."

多重度最適化支援機能の設定としては、以下の設定をまず確認してください。

必要に応じて以下の設定も見直してください。 多重度を増加させるべきかの判断基準を示す設定には、上記の応答期限に加えて以下のものがあります。

多重度を減少させるかの判断基準を示す設定には、以下のものがあります。

以下の設定を変更することにより、そのときのシステム稼働状況に応じて動的に多重度を変更することができます。

7.1.13.3. 実行時間上限の適正値算出

実行時間上限の適正値算出機能に関する設定について以下に説明します。 実行時間上限とは、実行時間上限を超えるオペレーションが検出し異常状態とみなされたプロセスを再起動させる、ストール障害自律復旧のための設定です。

運用アシスタントが算出した実行時間上限の推奨値は、以下に表示されます。

運用アシスタントが算出した実行時間上限の推奨値を実際に設定するには、以下の操作を実行します。

必要に応じて以下の設定も確認してください。

7.1.13.4. スローダウン障害の検出

スローダウン障害検出機能のための設定について以下に説明します。

ここでスローダウン障害とは、「従来に比べて総体として遅くなった」状態を指します。 何回かのオペレーション実行がたまたま長いだけではスローダウン障害とは見なしません。 上記に加え、V8.2からは1秒以下でのスローダウンは検出しません。

前回の情報取得までの統計情報と、最新の情報採取分(「情報採取間隔」分)のデータを比較します。 最新の情報取得で得た各オペレーションの実行回数が30回に満たない場合は、スローダウン検出を行わず、次回の情報取得分にマージさせます。 スローダウン障害の疑いがあっても、正常動作の可能性が多く残る場合は、スローダウン障害として検出しません。

スローダウン障害を検出すると以下のメッセージを統合運用管理ツールに通知し、イベントログ/syslog,webotx_agent.log(webotx_tpmmgr.log)に出力します。 このとき、スタックトレースを3秒間隔5回でアプリケーションログに出力し、イベントジャーナルとキュー情報を ${INSTANCE_ROOT}\logs\tpsystem\logcollect\{日付10桁}\配下に出力します。 これらの情報を確認することで障害解析に役立ちます。

"OTX20110100 オペレーションzzzのスローダウンを検出しました。current:平均実行時間=xxx秒。normal:平均実行時間=www秒。プロセスグループ=vvv。 ObjectName=yyy"
"OTX20110100 The Operation zzz get late. Average of current time is xxx s. Average of normal time is www s. The Process Group is vvv. The ObjectName is yyy"

[注] イベントIDがV6.3から変更になりました(OTX20110000 → OTX20110100)

スローダウン障害からの回復を検出すると以下のメッセージを統合運用管理ツールに通知し、イベントログ/syslog,webotx_agent.log(webotx_tpmmgr.log)に出力します。 遅くなったまま長期間状態が落ち着いた場合も以下のメッセージとなります。

"OTX20120100 オペレーションzzzがスローダウン状態からノーマル状態に遷移しました。current:平均実行時間=xxx秒。normal:平均実行時間=www秒。プロセスグループ=vvv, ObjectName=yyy"
"OTX20120100 The Operation zzz transit from slowdown to normal. Average of current time is xxx s. Average of normal time is www s. The Process Group is vvv. The ObjectName is yyy"

[注] イベントIDがV6.3から変更になりました(OTX20120000 → OTX20120100)

スローダウンが検出された場合は、システム運用上重要な問題となっていないか、オペレーションジャーナルや統合運用管理ツールを使用し稼動状態を調査してください。 スローダウン検出機能は、遅くなり始めた状態を検出するものであり、致命的な遅延となる前に自然復旧される場合もあります。 この場合は特に復旧処置は必要ありません。

スローダウン障害が、自然復旧される一時的なものか、オペレータによる対処が必要な恒久的なものかの判断を支援する機能として「長期スローダウン検出機能」があります。 オペレーションのスローダウンを検出してから「スローダウン継続監視時間」を超えてなお、スローダウン状態が継続していると以下のメッセージを統合運用管理ツールに通知し、イベントログ/syslog,webotx_agent.log(webotx_tpmmgr.log)に出力します。

"OTX20110200 オペレーションzzzの長期にわたるスローダウン状態を検出しました。current:平均実行時間=xxx秒。normal:平均実行時間=www秒。スローダウン継続時間=uuu分。プロセスグループ名=vvv, ObjectName=yyy"
"OTX20110200 The Operation zzz is slow for a long time. Average of current time is xxx s. Average of normal time is www s. Duration of slow is uuu m. The Process Group is vvv. The ObjectName is yyy"

「長期にわたるスローダウン状態」を検出すると、メッセージ出力とともに、該当プロセスグループのスタックトレースを採取します。 このAPログに出力されるスタックトレースを参照することで、スローダウンの原因を調査することができます。

「長期にわたるスローダウン状態」が通知される場合、スローダウンが長期化しており、一時的なスローダウンでなく恒久的なスローダウンに陥っている可能性があります。 オペレーションジャーナルやスタックトレース、イベントジャーナルによりスローダウンの原因を調査してください。 必要に応じてプロセスグループの再起動などの復旧に向けた対処を検討してください。 運用管理製品などによりスローダウン障害を監視する場合は、本メッセージを監視することをお奨めします。

スローダウン状態が継続しているか否かは、「情報採取間隔」ごとに監視されます。 「スローダウン継続監視時間」を超えてスローダウン状態が継続していても、次の情報採取までは「長期にわたるスローダウン状態」が検出されません。 前回スローダウン状態か否かを解析してからの該当オペレーションに対する呼び出し回数が30に満たない場合は、スローダウン状態か否かの判断ができないため、「長期にわたるスローダウン」は検出されません(復旧したとも見なされません)。 スローダウン継続時間は、最初にスローダウンを検出した時間を0としてカウントされます。 「長期にわたるスローダウン状態」は同一オペレーションに対して連続して通知されません。

スローダウン障害検出機能のための設定には以下があります。 必要に応じて見直してください。

スローダウン状態がどのくらい長く継続しているかは、以下で参照できます。

7.1.14. メモリ枯渇監視機能

メモリ枯渇監視機能の設定を以下に示します。

設定方法

メモリ枯渇監視機能の設定の初期値は表3.4.4.3-2のようになっています。機能を使用しない場合は、各閾値を0に設定します。

表7.1.14-1 メモリ枯渇監視機能の設定初期値
設定項目名 設定値 既定値
OutOfMemoryErrorの監視 ON/OFF ON
OutOfMemoryErrorの検出タイミング メモリ使用量閾値 old領域 0〜99(%) 0(監視を行わない)
Permanent領域 0〜99(%) 0(監視を行わない)
GC後のメモリ使用量閾値(Old領域) 0〜99(%) 97
検出時の動作 メモリ使用量超過時にGCを行う ON/OFF ON
GC後のメモリ使用量超過時にプロセスの停止を行う ON/OFF ON

運用管理ツールからの設定は以下の通りとなります。

図7.1.14-1
図7.1.14-1

運用管理コマンドを使用する場合は、以下のMOの属性を変更してください。

Memo
設定を有効にするには、プロセスグループの再起動もしくは動的設定変更を行ってください。
ログ出力
OutOfMemoryError検出時、トレースレベルが6:情報メッセージの場合、各監視毎に以下のログが出力されます。
表7.1.14-2
監視種別 出力条件 出力場所 Fullthreaddump出力
メモリ使用量監視 - APトレース なし
GC後のメモリ使用量監視 プロセスの停止 有 システムトレース
APトレース
なし
プロセスの停止 無 APトレース あり

出力されるログは"検出時のメモリ使用量"と"共通情報"、"Fullthreaddump"(GC後のメモリ使用量監視のプロセス停止しない場合のみ)が出力されます。
各監視の"検出時のメモリ使用量"のイメージは以下の通りとなります。
メモリ使用量監視の場合

2009/10/16 16:28:49.080|---: PS Old Gen Memory Threshold Exceeded threshold: used:289794864 max:477233152 init:29884416 committed:351862784

GC後のメモリ使用量監視の場合

2009/10/15 11:00:38.431|---: PS Old Gen Collection Memory Threshold Exceeded threshold: used:475432840 max:477233152 init:29884416 committed:477233152

共通情報は以下のイメージになります。

2009/10/15 11:00:38.431|---: JavaHeap used:496048936 max:517013504 init:33554431 committed:508624896
2009/10/15 11:00:38.431|---: Code Cache used:1098176 max:50331648 init:2359296 committed:2359296
2009/10/15 11:00:38.431|---: PS Eden Space used:20616096 max:58130432 init:3145728 committed:30801920
2009/10/15 11:00:38.431|---: PS Survivor Space used:0 max:589824 init:524288 committed:589824
2009/10/15 11:00:38.431|---: PS Old Gen used:475432840 max:477233152 init:29884416 committed:477233152
2009/10/15 11:00:38.431|---: PS Perm Gen used:9610576 max:67108864 init:16777216 committed:16777216
2009/10/15 11:00:38.431|---: GC Name:PS Scavenge Count:20 Time:247
2009/10/15 11:00:38.431|---: GC Name:PS MarkSweep Count:98 Time:8350

出力されるログは以下の意味となります。

Caution
各監視の閾値超過時のヒープ使用量と共通情報のヒープ出力は、前者は閾値超過した時点でのヒープ使用量で、後者は検出後に取得したヒープ使用量のため、メモリの情報にタイムラグを生じることがあります。

7.1.15. 同時受付オペレーション数

TPシステムの同時受付オペレーション数

TPシステムで同時に受け付けるオペレーション数を制限することができます。変更するには、同時受付オペレーション数を変更します。実行中のオペレーションとキューに滞留中のオペレーションの両方を含みます。WebOTX内部で生成され、IIOPリスナを経由して起動されるオペレーションも含まれます。非同期トランザクションは含まれません。

統合運用管理ツールからの設定は以下の通りとなります。

TPシステムで現在受け付けているオペレーション数は、統合運用管理ツールから参照できます。

TPシステムで現在受け付けているオペレーション数は、otxadminコマンドからでも参照できます。

otxadmin> get --monitor tpsystem.IIOPListener.simultaneousRequestsCount-Current
プロセスグループの同時受付オペレーション数

IIOPリスナは各プロセスグループにオペレーションを振り分けますが、その際にプロセスグループが同時に受け付けるオペレーション数を指定できます。実行中のオペレーションとキューに滞留中のオペレーションの両方を含みます。WebOTX内部で生成され、IIOPリスナを経由して起動されるオペレーションも含まれます。非同期トランザクションは含まれません。

統合運用管理ツールからの設定は以下の通りとなります。

プロセスグループで現在受け付けているオペレーション数は、統合運用管理ツールの統計情報から参照できます。

プロセスグループで現在受け付けているオペレーション数は、otxadminコマンドからでも参照できます。

otxadmin> get --monitor tpsystem.applicationGroups.apg_name.processGroups.pg_name.simultaneousRequestsCount-Current

7.2. Object Broker

7.2.1. Object Brokerの運用操作

Object Brokerに関する運用操作法について説明します。なお、各属性の説明については[ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.10. Object Broker > 1.10.1. Object Broker設定項目・設定方法 ]をご参照ください。

7.2.1.1. Object Brokerのオペレーション一覧

ここでは、Object BrokerコンフィグやObject Brokerサービスの各MOで実行可能なオペレーションについて説明します。

7.2.1.2. Object Brokerコンフィグの操作

Dottedname : server.objectbrokerconfig

Object Broker コンフィグ のオペレーションを以下に示します。[ ]内はコマンドで実行する場合のコマンド名です。

1. Object Broker Java プロパティ設定一覧取得 [get-ospi-java-properties]
Object Broker Java ライブラリのプロパティ設定の一覧を取得します。


[実行方法]

ツリー表示で、「Object Broker コンフィグ」 を右クリックして「Java プロパティ設定一覧取得」を実行してください。

「実行」をクリックしてください。



2. Object Broker Java プロパティ設定値取得 [get-ospi-java-property]
Object Broker Java ライブラリのプロパティ設定値を取得します。


[実行方法]

ツリー表示で、「Object Broker コンフィグ」 を右クリックして「Java プロパティ設定値取得」を実行してください。

プロパティ名* :参照したいプロパティの名前を記述してください。

上記の値を入力して「実行」をクリックしてください。

*は入力必須項目です。



3. Object Broker Java プロパティ設定 [set-ospi-java-property]
Object Broker Java ライブラリにプロパティを設定します。設定された属性は以下のファイルに格納されます。

${INSTANCE_ROOT}/config/ObjectBroker/objava.conf


[実行方法]

ツリー表示で、「Object Broker コンフィグ」 を右クリックして「Java プロパティ設定」を実行してください。

プロパティ名* :設定するプロパティの名前を記述してください。

プロパティ値 : 設定するプロパティの値を記述してください。

上記の二つの値を入力して「実行」をクリックしてください。

*は入力必須項目です。

この「Object Broker Javaプロパティ設定」オペレーションで設定可能なプロパティの一覧は、[ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.10. Object Broker > 1.10.2. Object Broker JavaにおけるORBのプロパティ定義 ]を参照してください。



4. Object Broker Java プロパティの削除 [delete-ospi-java-property]
Object Broker Java ライブラリのプロパティを削除します。

ただし、共通タブおよびJava タブで設定可能なプロパティについては、このオペレーションで削除することはできません。


[実行方法]

ツリー表示で、「Object Broker コンフィグ」 を右クリックして「Java プロパティの削除」を実行してください。

プロパティ名* :削除するプロパティの名前を記述してください。

上記の値を入力して「実行」をクリックしてください。

*は入力必須項目です。



5. Object Broker C++プロパティ設定一覧取得 [get-cpp-properties]
Object Broker C++ライブラリのプロパティ設定の一覧を取得します。

ただし、共通タブ、cpp タブおよびObjectBroker MO で設定可能なプロパティについては、このオペレーションで取得することはできません。


[実行方法]

ツリー表示で、「Object Broker コンフィグ」 を右クリックして「C++プロパティ設定一覧取得」を実行してください。

「実行」をクリックしてください。



6. Object Broker C++プロパティ設定値取得 [get-cpp-property]
Object Broker C++ライブラリのプロパティ設定値を取得します。


[実行方法]

ツリー表示で、「Object Broker コンフィグ」 を右クリックして「C++プロパティ設定値取得」を実行してください。

プロパティ名* :参照したいプロパティの名前を記述してください。

上記の値を入力して「実行」をクリックしてください。

*は入力必須項目です。



7. Object Broker C++プロパティ設定 [set-cpp-property]
Object Broker C++ライブラリにプロパティを設定します。設定された属性は以下のファイルに格納されます。

${INSTANCE_ROOT}/config/ObjectBroker/orbconf

ただし、共通タブ、cpp タブおよびObjectBroker MO で設定可能なプロパティについては、このオペレーションで設定することはできません。


[実行方法]

ツリー表示で、「Object Broker コンフィグ」 を右クリックして「C++プロパティ設定」を実行してください。

プロパティ名* : 設定するプロパティの名前を記述してください。

プロパティ値 : 設定するプロパティの値を記述してください。

上記の二つの値を入力して「実行」をクリックしてください。

*は入力必須項目です。

この「Object Broker C++プロパティ設定」オペレーションで設定可能なプロパティの一覧は、[ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.10. Object Broker > 1.10.3. Object Broker C++における環境設定 ]を参照してください。



8. Object Broker C++プロパティの削除 [delete-cpp-property]
Object Broker C++ライブラリのプロパティを削除します。

ただし、共通タブ、cpp タブ、およびObjectBroker MO で設定可能なプロパティについては、このオペレーションで削除することはできません。


[実行方法]

ツリー表示で、「Object Broker コンフィグ」 を右クリックして「C++プロパティの削除」を実行してください。

プロパティ名* : 削除するプロパティの名前を記述してください。

上記の値を入力して「実行」をクリックしてください。

*は入力必須項目です。



9. Object Broker 共通プロパティ設定一覧取得 [get-ospi-properties]
Object Broker ライブラリのプロパティ設定の一覧を取得します。


[実行方法]

ツリー表示で、「Object Broker コンフィグ」 を右クリックして「共通プロパティ設定一覧取得」を実行してください。

「実行」をクリックしてください。



10. Object Broker 共通プロパティ設定値取得 [get-ospi-property]
Object Broker ライブラリのプロパティ設定値を取得します。


[実行方法]

ツリー表示で、「Object Broker コンフィグ」 を右クリックして「共通プロパティ設定値取得」を実行してください。

プロパティ名* :参照したいプロパティの名前を記述してください。

上記の値を入力して「実行」をクリックしてください。

*は入力必須項目です。



11. Object Broker 共通プロパティ設定 [set-ospi-property]
Object Broker ライブラリにプロパティを設定します。設定された属性は以下のファイルに格納されます。

${INSTANCE_ROOT}/config/ObjectBroker/orbconf

${INSTANCE_ROOT}/config/ObjectBroker/objava.conf

ただし、共通タブ、cpp タブおよびObjectBroker MO で設定可能なプロパティについては、このオペレーションで設定することはできません。


[実行方法]

ツリー表示で、「Object Broker コンフィグ」 を右クリックして「共通プロパティ設定」を実行してください。

プロパティ名* : 設定するプロパティの名前を記述してください。

プロパティ値 : 設定するプロパティの値を記述してください。

上記の二つの値を入力して「実行」をクリックしてください。

*は入力必須項目です。

この「Object Broker共通プロパティ設定」オペレーションで設定可能なプロパティの一覧は、[ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.10. Object Broker > 1.10.2. Object Broker JavaにおけるORBのプロパティ定義 ]および[ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.10. Object Broker > 1.10.3. Object Broker C++における環境設定 ]を参照してください。


12. Object Broker 共通プロパティの削除 [delete-ospi-property]
Object Broker ライブラリのプロパティを削除します。

ただし、共通タブ、cpp タブ、およびObjectBroker MO で設定可能なプロパティについては、このオペレーションで削除することはできません。


[実行方法]

ツリー表示で、「Object Broker コンフィグ」 を右クリックして「共通プロパティの削除」を実行してください。

プロパティ名* : 削除するプロパティの名前を記述してください。

上記の値を入力して「実行」をクリックしてください。

*は入力必須項目です。



7.2.1.3. Object Brokerサービスの操作

Dottedname : server.objectbrokerservice

Object Broker サービス のオペレーションを以下に示します。[ ]内はコマンドで実行する場合のコマンド名です。

1. Object Broker サービスの起動 [start-ospi]
Object Broker サービスを起動します。


[実行方法]

ツリー表示で、「Object Broker サービス」 を右クリックして「Object Broker サービスの起動」を実行してください。

「実行」をクリックしてください。



2. Object Broker サービスの停止 [stop-ospi]
Object Broker サービスを停止します。


[実行方法]

ツリー表示で、「Object Broker サービス」 を右クリックして「Object Broker サービスの停止」を実行してください。

「実行」をクリックしてください。



Dottedname : server.objectbrokerservice.oad

oad のオペレーションを以下に示します。

1. Oad サービスの起動 [invoke server.objectbrokerservice.oad.start]
Oad サービスを起動します。


[実行方法]

ツリー表示で、oad を右クリックして「Oad 起動」を実行してください。

「実行」をクリックしてください。



2. Oad サービスの停止 [invoke server.objectbrokerservice.oad.stop]
Oad サービスを停止します。


[実行方法]

ツリー表示で、oad を右クリックして「Oad 停止」を実行してください。

「実行」をクリックしてください。



Dottedname : server.objectbrokerservice.namesv

namesv のオペレーションを以下に示します。

1. namesv サービスの起動 [invoke server.objectbrokerservice.namesv.start]
namesv サービスを起動します。


[実行方法]

ツリー表示で、namesv を右クリックして「名前サーバの起動」を実行してください。

「実行」をクリックしてください。



2. namesv サービスの停止 [invoke server.objectbrokerservice.namesv.stop]
namesv サービスを停止します。


[実行方法]

ツリー表示で、namesv を右クリックして「名前サーバの停止」を実行してください。

「実行」をクリックしてください。



Dottedname : server.objectbrokerservice.irsv

irsv のオペレーションを以下に示します。

1. irsv サービスの起動 [invoke server.objectbrokerservice.irsv.start]
irsv サービスを起動します。


[実行方法]

ツリー表示で、irsv を右クリックして「IR サーバの起動」を実行してください。

「実行」をクリックしてください。



2. irsv サービスの停止 [invoke server.objectbrokerservice.irsv.stop]
irsv サービスを停止します。


[実行方法]

ツリー表示で、irsv を右クリックして「IR サーバの停止」を実行してください。

「実行」をクリックしてください。



Dottedname : server.objectbrokerservice.corbaloc

corbaloc のオペレーションを以下に示します。

1. corbaloc サービスの起動 [invoke server.objectbrokerservice.corbaloc.start]
corbaloc サービスを起動します。


[実行方法]

ツリー表示で、corbaloc を右クリックして「Corbaloc サーバの起動」を実行してください。

「実行」をクリックしてください。



2. corbaloc サービスの停止 [invoke server.objectbrokerservice.corbaloc.stop]
corbaloc サービスを停止します。


[実行方法]

ツリー表示で、corbaloc を右クリックして「Corbaloc サーバの停止」を実行してください。

「実行」をクリックしてください。



Dottedname : server.objectbrokerservice.cnamesv

cnamesv のオペレーションを以下に示します。

1. cnamesv サービスの起動 [invoke server.objectbrokerservice.cnamesv.start]
cnamesv サービスを起動します。


[実行方法]

ツリー表示で、cnamesv を右クリックして「キャッシュ名前サーバの起動」を実行してください。

「実行」をクリックしてください。



2. cnamesv サービスの停止 [invoke server.objectbrokerservice.cnamesv.stop]
cnamesv サービスを停止します。


[実行方法]

ツリー表示で、cnamesv を右クリックして「キャッシュ名前サーバの停止」を実行してください。

「実行」をクリックしてください。



Dottedname : server.objectbrokerservice.oadj

oadj のオペレーションを以下に示します。[ ]内はコマンドで実行する場合のコマンド名です。

1. OadJ サービスの起動 [start-oadj]
OadJ サービスを起動します。


[実行方法]

ツリー表示で、oadj を右クリックして「OadJ サービスの起動」を実行してください。

「実行」をクリックしてください。



2. OadJ サービスの停止 [stop-oadj]
OadJ サービスを停止します。


[実行方法]

ツリー表示で、oadj を右クリックして「OadJ サービスの停止」を実行してください。

「実行」をクリックしてください。



3. インプリメンテーションの一覧 [listimpl]
サーバのインプリメンテーション一覧を表示します。


[実行方法]

ツリー表示で、oadj を右クリックして「インプリメンテーションの一覧」を実行してください。

「実行」をクリックしてください。



4. インプリメンテーションの登録 [instimpl]
サーバのインプリメンテーションを登録します。


[実行方法]

ツリー表示で、oadj を右クリックして「インプリメンテーションの登録」を実行してください。

インプリメンテーション名* : 登録するインプリメンテーション名を指定します。

コマンドライン* : サーバを起動するときのコマンドラインの文字列を指定します。

例)

java .classpath C:\test\sample.jar sampleServer

サーバの活性化方針* : サーバの活性化方針を以下の三つから選択してください。

上記の三つの値を入力して「実行」をクリックしてください。

*は入力必須項目です。



5. インプリメンテーションの削除 [rmimpl]
サーバのインプリメンテーションを削除します。


[実行方法]

ツリー表示で、oadj を右クリックして「インプリメンテーションの削除」を実行してください。

インプリメンテーション名* : 削除するインプリメンテーション名を指定します。

上記の値を入力して「実行」をクリックしてください。

*は入力必須項目です。



Dottedname : server.objectbrokerservice.ospprxy

ospprxy のオペレーションを以下に示します。[ ]内はコマンドで実行する場合のコマンド名です。

1. ospprxy サービスの起動 [start-ospprxy]
ospprxy サービスを起動します。


[実行方法]

ツリー表示で、ospprxy を右クリックして「ospprxy サービスの起動」を実行してください。

「実行」をクリックしてください。



2. ospprxy サービスの停止 [stop-ospprxy]
ospprxy サービスを停止します。


[実行方法]

ツリー表示で、ospprxy を右クリックして「ospprxy サービスの停止」を実行してください。

「実行」をクリックしてください。



7.2.2. 旧互換アプリケーションの運用操作

WebOTX バージョン5 以前に作成したCORBA アプリケーションをStandard, Enterpriseで運用操作する手順について説明します。Object Broker サービスのみを使用するWebOTX CORBA アプリケーションの場合とObjectBroker サービス以外のサービスを使用するWebOTX CORBA アプリケーションの場合で環境の構築方法および運用方法が異なります。

ドメイン内のObject Broker, ドメイン内のTransaction サービスとは、ドメインの起動および停止に連動することができ、${INSTANCE_ROOT}/config に設定ファイルを持ち、統合運用管理ツールや otxadmin コマンドで制御できるプロセスのことです。

ドメイン外のObject Broker, ドメイン外のTransaction サービスとは、WebOTX バージョン5 以前と同様の運用管理方式で、サービスから起動するプロセスのことです。

7.2.2.1. Object Broker サービスのみを使用する WebOTX CORBA アプリケーションの場合

ここでは、Object Broker サービスのみを使用するWebOTX CORBA アプリケーションの場合について説明します。 バージョン5 以前のWebOTX 旧互換ライブラリはドメイン固有の設定を参照することができません。このため、ドメインの設定 のほかに追加で旧互換の設定を行う必要があります。本節ではその手順について説明いたします。

環境構築

1.  ドメインを作成します。

ドメインを新規作成します。既存のドメインも使用できます。
ドメインの作成手順については[ 3. ドメイン > 3.2. ドメインの作成・削除 ]を参照してください。

2.  Object Brokerの設定を変更します。

ドメイン外のObject Brokerの設定をドメイン内で動作するObject Brokerを使用するように変更します。
ドメイン内で動作するObject Brokerの設定は次のように確認します。
otxadmin> get server.objectbrokerservice.oad.OadPort
otxadmin> get server.objectbrokerservice.namesv.NameServicePort
server.objectbrokerservice.oad.OadPortの値を設定名”OadPort”に設定します。
server.objectbrokerservice.namesv.NameServicePortの値を設定名”CorbalocDefaultPort”に設定します。

表7.2.2.1-1
設定名 意味
OadPort oad の使用するポート番号を指定します。ORB 通信するすべてのホストで同一のポート番号を使う必要があります。未指定時の既定値は9825 です。運用開始後にoad のポート番号を変更すると、それ以前に作ったオブジェクトを呼び出すことができなくなります。変更するときは、oad やnamesv およびすべてのORB アプリケーションをいったん終了してから変更してください。
CorbalocDefaultPort URL でポート番号を指定しなかったときの値を設定します。未設定時は2809 です。
NameServiceRoundRobin on を設定します。名前サーバのラウンドロビン拡張機能が有効になります。同一の名前でresolve を呼んだ場合、呼び出すたびに別のオブジェクトを返すためのWebOTX Object Broker 独自の機能です。

(注)ドメイン外で名前サーバを動作させて、ドメイン内のアプリケーションと連携させる場合、NameServiceRoundRobinの設定変更(on を設定する)が必要です。ドメイン内では、NameServiceRoundRobin=trueがデフォルトですが、ドメイン外ではNameServiceRoundRobinの指定なし(off)がデフォルトであるためです。
ドメイン外のObject Brokerの設定をドメイン内で動作するObject Brokerを使用するように変更します。
ドメイン内で動作するObject Brokerの設定は次のように確認します。

設定項目の詳細は[ WebOTX Object Broker JavaTM > 運用ガイド > 1. 環境設定について ]を参照してください。

3.  ドメイン外のObject Broker を起動します。

root ユーザで以下のコマンドを実行します。
# /etc/init.d/ObjectSpinner start (HP-UX の場合 /sbin/init.d/ObjectSpinner start)
名前サーバ、IRサーバを起動するか否かについては[ WebOTX Object Broker JavaTM > 運用ガイド > 3. Object Brokerの起動/終了について ]を参照してください。

4.  ドメインを起動します。

WebOTX運用ユーザで実行します。
otxadmin> start-domain domain_name

5.  アプリケーションの配備・設定をします。

プロセスグループ作成時にWebOTX のバージョンを旧バージョンに変更します。
詳細は [ 7.1. TPシステム > 7.1.3. 操作・状態確認(プロセスグループ) > 7.1.3.1. 作成・削除 ] を参照してください。

  運用上の注意点は次のとおりです。

ドメイン起動
ドメインを起動するためには、通常のドメインと同様にotxadmin コマンドを使用します。
WebOTX 運用ユーザで実行します。
otxadmin> start-domain domain_name
ドメイン停止
ドメインを停止するためには、通常のドメインと同様にotxadmin コマンドを使用します。
WebOTX 運用ユーザで実行します。
otxadmin> stop-domain domain_name

7.2.2.2. Object Broker サービス以外のサービスを使用する WebOTX CORBA アプリケーションの場合

以下では、バージョン5 以前に作成したWebOTX CORBA アプリケーションがTransaction サービスと連携する場合について説明します。 Transaction サービスとバージョン5 以前のWebOTX 旧互換ライブラリを動作させるためには、 両者でトランザクション情報などの情報を共有するためTransaction サービスをドメイン外で動作させる必要があります。 それに伴い、起動順序を維持するためObject Broker サービスをドメイン外で動作させる必要があります。 本節ではその手順について説明します。

環境構築

1.  ドメインを作成します。

ドメインを新規作成します。既存のドメインも使用できます。
ドメインの作成手順については[ 3. ドメイン > 3.2. ドメインの作成・削除 ]を参照してください。

2.  ドメインを起動します。

設定変更のため、一度ドメインを起動します。
WebOTX 運用ユーザで実行します。
otxadmin> start-domain domain_name

3.  Object Brokerの設定を変更します。

まず、ドメイン外で動作するObject Brokers を使用するようにポート番号を変更します。
ドメイン外のObject Broker の設定は次の場所になります。

設定名”OadPort”と”NameServicePort”の値を上記レジストリまたはファイルを参照し、以下のように設定します。
設定されていない場合は既定値を設定します。
otxadmin> set server.objectbrokerservice.oad.OadPort = <設定名OadPort の値(既定値9825)>
otxadmin> set server.objectbrokerservice.corbaloc.CorbalocDefaultPort = <設定名NameServicePort の値(既定値2809)>
次に、ドメイン外で動作するObject Broker で次の設定がされていない場合はレジストリまたはファイルに追加します。

さらに、ドメイン内のObject Broker がドメイン起動時に自動起動しないように設定します。
otxadmin> set server.internal-lifecycle-module.ObjectBrokerService.state-order=initialization(既定値ready)

4.  ドメイン内のTransaction サービスの設定を変更します。

ドメイン内のTransaction サービスがドメイン起動時に自動起動しないように設定します。
otxadmin> set server.internal-lifecycle-module.TransactionService.state-order=initialization(既定値ready)

5.  ドメインを停止します。

WebOTX 運用ユーザで実行します。
otxadmin> stop-domain domain_name

6.  ドメイン外のTransactionService(RCD)をサービス登録します。(Windows のみ)

コマンド実行してRCD をサービスに登録します。
> wotsrcd -a
サービスに"WebOTX Transaction Service"が登録されます。

7.  ドメイン外のTransactionサービスの設定をします。

設定方法は[ 11. 付録 > 11.2. Transactionサービス (バージョン5以前互換) ]にしたがってください。

設定にあたって次の点に注意をしてください。

なお、リカバリサーバを使用することもできます。
設定方法は[ 11. 付録 > 11.3. Transactionサービス (リカバリサーバ利用時) ]を参照してください。

8.  ドメイン外のObject Broker とTransaction サービスを起動します。

root ユーザで以下のコマンドを実行します。
# /etc/init.d/ObjectSpinner start (HP-UX の場合 /sbin/init.d/ObjectSpinner start)
# /etc/init.d/WebOTX_TS start (HP-UX の場合 /sbin/init.d/WebOTX_TS start) 
名前サーバ、IRサーバを起動するか否かについては[ WebOTX Object Broker JavaTM > 運用ガイド > 3. Object Brokerの起動/終了について ]を参照してください。

9.  ドメインを起動します。

WebOTX運用ユーザで実行します。
otxadmin> start-domain domain_name
※Java でデータベースを使用する場合はドメイン起動前にjdbc ドライバのjar を{domain_name}\lib\ext へコピーします。

10.  アプリケーションの配備・設定をします。

  運用上の注意点は次のとおりです。

ドメイン起動
ドメインを起動するためには、まずドメイン外で動作するObject Broker とTransaction サービスを起動します。
その後通常のドメインと同様に otxadmin コマンドを使用します。

ドメイン停止
ドメインを停止するためには、まず通常のドメインと同様に otxadmin コマンドを使用します。
その後ドメイン外で動作するObject Broker とTransaction サービスを停止します。

7.3. JMS

JMSに関する運用操作法について説明します。なお、各属性の詳細については[ 7.3.1. JMSサービスの操作 > 7.3.1.2. 属性参照・設定 ]、および[ リファレンス集 運用管理・設定編 > 2. MO定義リファレンス ]を参照してください。

7.3.1. JMSサービスの操作

JMSサービスで管理しているJMSサーバの起動と停止、および、項目の参照と設定の手順について説明します。

7.3.1.1. 起動・停止

統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「JMSサービス」を選択し、右クリックするか、あるいは、メニューバーの[操作] を選択します。
  2. 表示されるメニューから「JMSサーバの起動」を選択するとJMSサーバが起動します。また、「JMSサーバの停止」を選択することでJMSサーバが停止します。

    JMSサービスの起動・停止
    図7.3.1.1-1


運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. JMSサーバを起動するには、以下のコマンドを実行します。
    otxadmin> invoke server.jms-service.start
    あるいは
    otxadmin> start-jms

    start-jmsコマンドの詳細については運用管理コマンドリファレンスの「start-jms」を参照してください。


  2. JMSサーバを停止するには、以下のコマンドを実行します。
    otxadmin> invoke server.jms-service.stop
    あるいは
    otxadmin> stop-jms

    stop-jmsコマンドの詳細については、運用管理コマンドリファレンスの「stop-jms」を参照してください。

7.3.1.2. 属性参照・設定

JMSサービスの属性の詳細については、MO定義リファレンスの「jms-service」を参照してください。

統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「JMSサービス」を選択します(選択すると、リストビューから各属性を参照できます)。
  2. リストビューから変更したい属性を選択して変更します。
  3. 「更新」ボタンをクリックして変更を反映します。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. 属性に設定している値を参照するには、getコマンドを使用します。

    例) 1つの項目(ログレベル)を参照する場合
    otxadmin> get server.jms-service.loglevel

    例) すべての項目を参照する場合 (プロパティが設定されている場合は、プロパティも表示されます)
    otxadmin> get server.jms-service.*


  2. 属性の値を設定するには、setコマンドを使用します。

    例) ログレベルを設定する場合
    otxadmin> set server.jms-service.loglevel=ERROR

注意 :
以下の属性は、JMSサーバの起動中は変更が動的に反映されます。JMSサーバの停止中は、次回起動するときにその値が有効になります。

表7.3.1.2-1
統合運用管理ツールでの属性名 運用管理コマンドでの属性名(attribute-name)
システム内メッセージ最大数 systemMaxCount
システム内メッセージ最大合計サイズ systemMaxSize
最大メッセージサイズ messageMaxSize
ログレベル loglevel
ログロールオーバーサイズ logfileRolloverBytes
ログロールオーバー間隔 logfileRolloverSecs
自動トピック作成の許可 autocreateTopic
自動キュー作成の許可 autocreateQueue
自動生成キューに対するアクティブコンシューマの最大数 autocreateMaxNumActiveConsumers
自動生成キューに対するバックアップコンシューマの最大数 autocreateMaxNumBackupConsumers
JMSクライアントメモリ情報採取 enableClientMetrics
メッセージ一覧表示最大件数 displayMessageCount
パケット(メッセージ)情報採取 logPacketMessage
パケット(PING)情報採取 logPacketPing
パケット(運用管理)情報採取 logPacketAdmin
パケット(クラスタ)情報採取 logPacketCluster
パケットログロールオーバーサイズ logfileRolloverBytesPacket
パケットログロールオーバー間隔 logfileRolloverSecsPacket
運用管理操作履歴採取 logAdmin
運用管理操作履歴ファイルロールオーバーサイズ logfileRolloverBytesAdmin
運用管理操作履歴ファイルロールオーバー間隔 logfileRolloverSecsAdmin
メッセージライフサイクル情報採取 logMessage
メッセージログロールオーバーサイズ logfileRolloverBytesMessage
メッセージログロールオーバー間隔 logfileRolloverSecsMessage
エラー情報採取 logError
エラーログロールオーバーサイズ logfileRolloverBytesError
エラーログロールオーバー間隔 logfileRolloverSecsError


7.3.1.3. プロパティ参照・設定

統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「JMSサービス」を選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。
  2. プロパティを参照する場合は、メニューから「プロパティ一覧の取得」を選択し、表示されるダイアログで「実行」ボタンをクリックします。

    JMSサービスのプロパティ参照
    図7.3.1.3-1

  3. プロパティを設定する場合は、メニューから「プロパティの設定」を選択し、表示されるダイアログで設定値を入力して「実行」ボタンをクリックします。

    JMSサービスのプロパティ設定
    図7.3.1.3-2

    例) JMSサーバインスタンス識別子を設定する場合は次のように入力します。
    instance-name=jms1

運用管理コマンド(otxadmin)からの操作
属性の参照・設定と同様にgetコマンド、setコマンドを利用します。

7.3.1.4. JMSサーバの一覧の取得

JMSサーバクラスタを構成しているときに、クラスタ内の各JMSサーバの状態を確認する場合に利用します。表示する情報は次のとおりです。
この説明での「ローカルのJMSサーバ」とは、操作を実行したドメイン上のJMSサーバをさします。

表7.3.1.4-1
表示名 説明
Broker ID JMSサーバインスタンス識別子。ローカルのJMSサーバのもののみ表示します。
Address JMSサーバのアドレス。<ホスト名>:<ポート番号>の形式で表示します。
State JMSサーバの状態。
OPERATING : ローカルのJMSサーバの場合は、起動状態であることを示します。リモートのJMSサーバの場合は、通信が確立できていることを示します。
BROKER_DOWN : リモートのJMSサーバが停止しているか、通信が確立できていない状態を示します。


統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「JMSサービス」を選択し、右クリックするか、あるいは、メニューバーの[操作] を選択します。
  2. 表示されるメニューから「JMSサーバの一覧の取得」を選択すると、クラスタを構成するJMSサーバの状態を一覧表示します。

    JMSサーバの一覧の取得
    図7.3.1.4-1


運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. JMSサーバクラスタを構成しているときに、クラスタ内の各JMSサーバの状態を確認する場合には、以下のコマンドを実行します。
    otxadmin> list-jms-services

     
    結果表示例) 
    ---------------------------------------------
    Broker ID Address                 State
    ---------------------------------------------
    BROKER1   SVR1:9900               OPERATING
    BROKER2   SVR2:9700               OPERATING
    Command list-jms-services executed successfully.
    
list-jms-servicesコマンドの詳細については、運用管理コマンドリファレンスの「list-jms-services」を参照してください。

7.3.1.5. コネクション一覧の取得

JMSサーバに接続しているJMSクライアントのコネクションを確認する場合に利用します。表示する情報は次のとおりです。

表7.3.1.5-1
表示名 説明
Connection ID コネクションID
Client ID クライアントID
User ユーザ名
Service コネクションサービス名。コネクションサービスには次のものがあります。
jms:JMSのコネクションサービス
ssljms:JMSのSSLコネクションサービス
admin:管理用のコネクションサービス
ssladmin:管理用のSSLコネクションサービス
Producers プロデューサ数
Consumers コンシューマ数
Host ホスト名(IPアドレス)
Port ポート番号
Max Memory 最大メモリサイズ。「JMSクライアントメモリ情報採取(enableClientMetrics)」をtrueにしている場合、通常ユーザのコネクションに対する情報を表示します。
Current Memory 現在のメモリサイズ。「JMSクライアントメモリ情報採取(enableClientMetrics)」をtrueにしている場合、通常ユーザのコネクションに対する情報を表示します。
Peak Memory ピーク時のメモリサイズ。「JMSクライアントメモリ情報採取(enableClientMetrics)」をtrueにしている場合、通常ユーザのコネクションに対する情報を表示します。


統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「JMSサービス」を選択し、右クリックするか、あるいは、メニューバーの[操作] を選択します。
  2. 表示されるメニューから「コネクション一覧の取得」を選択し、表示されるダイアログで「表示対象タイプ」と、送信先で絞り込みたい場合は「送信先名」を指定して「実行」ボタンをクリックします。

    コネクション一覧の取得
    図7.3.1.5-1


運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. JMSサーバに接続しているコネクションの情報を表示するには、list-jms-connectionコマンドを使用します。
    otxadmin> list-jms-connections [--wojmsListType <表示対象タイプ>] [--wojmsDestinationName <送信先名>]

    例) 送信先 MyQueue に接続しているコンシューマが利用しているコネクションを表示する場合
    otxadmin> list-jms-connections --wojmsListType CONSUMERS --wojmsDestinationName MyQueue
     
    結果表示例) 
    ----------------------------------------------------------------------------------------------------------------------
    Connection ID       Client ID  User  Service Producers Consumers Host      Port Max Memory Current Memory Peak Memory
    ----------------------------------------------------------------------------------------------------------------------
    7738908095054457858 JMS_C00010 guest jms     0         1         127.0.0.1 2957 0          0              0
    7738908095054509825 JMS_C00020 guest jms     0         1         127.0.0.1 2977 0          0              0
    7738908095054473986 JMS_C00013 guest jms     0         1         127.0.0.1 2963 0          0              0
    コマンド list-jms-connections は正常に実行されました。
    

    list-jms-connectionsコマンドの詳細については、運用管理コマンドリファレンスの「list-jms-connections」を参照してください。

7.3.1.6. コネクションクローズ

JMSサーバから、JMSクライアントのコネクションを強制的にクローズする場合に利用します。

統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「JMSサービス」を選択し、右クリックするか、あるいは、メニューバーの[操作] を選択します。
  2. 表示されるメニューから「コネクションクローズ」を選択し、表示されるダイアログで「クローズ対象タイプ」と、必要な場合は「クローズ対象」を選択して「実行」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. コネクションをクローズするには、close-jms-connectionコマンドを使用します。
    otxadmin> close-jms-connection [--wojmsCloseType <クローズ対象タイプ>] [--wojmsDestinationName <送信先名>] [--wojmsConnectionID <コネクションID>]

    例) 送信先 MyQueue に接続しているすべてのコンシューマが利用しているコネクションをクローズする場合
    otxadmin> close-jms-connection --wojmsCloseType CONSUMERS --wojmsDestinationName MyQueue

    例) 特定のコネクションをクローズする場合
    otxadmin> close-jms-connection --wojmsConnectionID 102030494848

    close-jms-connectionコマンドの詳細については、運用管理コマンドリファレンスの「close-jms-connection」を参照してください。

7.3.1.7. 送信先の再表示

JMSサーバクラスタを構成しているときに、別のドメインからの伝播により作成した送信先のMOを表示するときに利用します。

統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「JMSサービス」を選択し、右クリックするか、あるいは、メニューバーの[操作] を選択します。
  2. 表示されるメニューから「送信先の再表示」を選択すると、別のドメインで作成された送信先のMOが表示されます。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. JMSサーバクラスタを構成しているときに、別のドメインで作成した送信先のMOを表示するには、以下のコマンドを使用します。
    otxadmin> invoke server.jms-service.updateJmsDestinations

備考 :
情報が正しく取得できたかどうかは、以下のコマンドで確認できます。
otxadmin> list-jmsdest

7.3.1.8. スレッドダンプの取得

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. JMSサーバのスレッドダンプを取得するには、以下のコマンドを使用します。
    otxadmin> invoke server.jms-service.dumpThreads

    結果は、${ INSTANCE_ROOT}/logs/wojms/std.logファイルへ出力されます。

注意 :
スレッドダンプ取得操作は、統合運用管理ツールで行うことはできません。上記のコマンドを利用するか、JMSサーバが提供している wojmscmd dump thd コマンドを利用してください。
wojmscmd dump thdコマンドの詳細については、[ リファレンス集 運用管理・設定編 > 4. 運用管理コマンドリファレンス > 4.4. JMS > 4.4.2. wojmscmd > 4.4.2.4. dump thd ] を参照してください。


7.3.2. 送信先の操作

物理的な送信先の作成と削除、および、項目の参照と設定の手順について説明します。

7.3.2.1. 新規作成

統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. ツリービューより、「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「JMSサービス」を選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。
  2. メニューから「送信先作成」を選択します。
  3. 表示されるダイアログで、「基本」タブの「送信先名」、「送信先タイプ」を指定し、さらに、必要な属性の値を指定して「実行」ボタンをクリックします。また、「送信先リソースを同時に生成する」をチェックすることで、送信先リソースを同時に作成することができます。
  4. 作成が正常終了すると、ツリービューの「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「JMSサービス」-「<送信先名>」配下に、指定した送信先名でMOが表示されます。

    送信先の新規作成
    図7.3.2.1-1


運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. 送信先を新規に作成する場合は、create-jmsdestコマンドを使用します。
    otxadmin> create-jmsdest --desttype <送信先タイプ> [オプション]

    例) トピックと送信先リソースを作成する場合
    otxadmin> create-jmsdest --desttype topic --cascade MyTopic
    この例では、--cascadeオプションにより、物理的な送信先と、送信先リソースを同時に生成しています。送信先リソースのJNDI名は「jms/MyTopic(jms/<物理的な送信先名>)」となります。--jndinameオプションにより、JNDI名を明示的に指定することができます。

    作成時に、属性や、プロパティを指定することもできます。コマンドの詳細については運用管理コマンドリファレンスの「create-jmsdest」を参照してください。


  2. 送信先一覧を表示する場合は、list-jmsdestコマンドを使用します。
    otxadmin> list-jmsdest [--desttype <送信先タイプ>]

    例) トピックだけを表示する場合
    otxadmin> list-jmsdest --desttype topic

    list-jmsdestコマンドの詳細については、運用管理コマンドリファレンスの「list-jmsdest」を参照してください。

7.3.2.2. 削除

統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. ツリービューより、削除対象の「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「JMSサービス」-「送信先名」-「<送信先名>」を選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。
  2. メニューから「削除」を選択し、表示されるダイアログで「実行」ボタンをクリックします。「送信先リソースを同時に削除する」をチェックすることで、送信先リソースの送信先名に、削除対象の送信先名が指定されているものをすべて削除することができます。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. 送信先を削除する場合は、delete-jmsdest コマンドを使用します。
    otxadmin> delete-jmsdest <送信先名>
    例) トピックと送信先リソースを削除する場合
    otxadmin> delete-jmsdest --cascade MyTopic
    この例では、--cascadeオプションにより、送信先リソースの送信先名(wojmsDestinationName)に「MyTopic」が指定されているものをすべて削除しています。

    delete-jmsdest コマンドの詳細については、運用管理コマンドリファレンスの「delete-jmsdest」を参照してください。

7.3.2.3. 属性参照・設定

物理的な送信先の属性の詳細については、MO定義リファレンスの「jms-physical-destination」を参照してください。

統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「JMSサービス」-「送信先名」-「<送信先名>」を選択します(選択すると、リストビューから各属性を参照できます)。
  2. リストビューから変更したい属性を選択して変更します。
  3. 「更新」ボタンをクリックして変更を反映します。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. 属性に設定している値を参照するには、getコマンドを使用します。

    例) 1つの項目を参照する場合
    otxadmin> get server.jms-service.jms-physical-destination.MyQueue.maxBytesPerMsg

    例) すべての項目を参照する場合 (プロパティが設定されている場合は、プロパティも表示されます)
    otxadmin> get server.jms-service.jms-physical-destination.MyQueue.*


  2. 属性の値を設定するには、setコマンドを使用します。

    例) maxBytesPerMsgを設定する場合
    otxadmin> set server.jms-service.jms-physical-destination.MyQueue.maxBytesPerMsg=-1



7.3.2.4. 情報取得

送信先の動作状況や、その送信先に接続しているプロデューサやコンシューマの情報を確認する場合に利用します。表示する情報は次のとおりです。

統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「JMSサービス」-「送信先名」-「<送信先名>」を選択して右クリックするか、選択した状態でメニューバーの[操作]を選択します。
  2. 送信先の現時点の状態などを知りたい場合は、メニューから「情報取得」を選択し、表示されるダイアログで「実行」ボタンをクリックします。

    送信先の情報取得
    図7.3.2.4-1


運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. 送信先の現時点の状態などを知りたい場合は、get-jmsdest-infoコマンドを使用します。
    otxadmin> get-jmsdest-info <送信先名>

    例) トピックMyTopicの情報を表示する場合
    otxadmin> get-jmsdest-info MyTopic
     
    結果表示例) 
    Current State                      RUNNING
    Current Number of Messages         8
    Current Total Message Bytes        1192
    Current Number of Producers        2
    Current Number of Active Consumers 1
    Current Number of Backup Consumers 0
    Producers:
    --------------------------------------------------
    Producer ID         Connection ID       Client ID
    --------------------------------------------------
    7458277433419032321 7458277433419020544
    7458277433396530432 7458277433396232704
    Consumers:
    ----------------------------------------------------------------------------------------------
    Consumer ID         Connection ID       Client ID Last Ack Time           Selector
    ----------------------------------------------------------------------------------------------
    7458277433426870528 7458277433426854656           2009/03/04 11:46:12.590 TestProperty IS NULL
    コマンド get-jmsdest-info は正常に実行されました。
    
    get-jmsdest-infoコマンドの詳細については、運用管理コマンドリファレンスの「get-jmsdest-info」を参照してください。

7.3.2.5. 送信先の一時停止・再開

統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「JMSサービス」-「送信先名」-「<送信先名>」を選択して右クリックするか、選択した状態でメニューバーの[操作]を選択します。
  2. 送信先の一時停止をする場合は、メニューから「一時停止」を選択し、表示されるダイアログで「停止タイプ」を選択し、「実行」ボタンをクリックします。その送信先に接続しているコンシューマを停止させたいときは「CONSUMERS」を、プロデューサを停止させたいときは「PRODUCERS」を、コンシューマとプロデューサともに停止させたいときは「ALL」を選択します。

    送信先の一時停止・再開
    図7.3.2.5-1

  3. 一時停止中の送信先を再開する場合は、メニューから「再開」を選択し、表示されるダイアログで「実行」ボタンをクリックします。 「再開」は、どの停止状態(CONSUMERS_PAUSED、PRODUCERS_PAUSED、PAUSED)からでも再開します。

なお、現時点の送信先の停止状態は、「情報取得」で確認することができます。


運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. 送信先の一時停止をする場合は、以下のコマンドを使用します。
    otxadmin> invoke server.jms-service.jms-physical-destination.<送信先名>.pause <停止タイプ>
    停止タイプには、1から3の数字を指定します。それぞれの数字は、次を意味します。
    表7.3.2.5-1
    停止タイプ 説明
    1 コンシューマを停止(CONSUMERS_PAUSED)
    2 プロデューサを停止(PRODUCERS_PAUSED)
    3 コンシューマ、プロデューサともに停止(PAUSED)

    例) トピックMyTopicのプロデューサを停止する場合
    otxadmin> invoke server.jms-service.jms-physical-destination.MyTopic.pause 2

    なお、現時点の送信先の停止状態は、情報取得(get-jmsdest-info)コマンドで確認することができます。


  2. 一時停止中の送信先を再開する場合は、以下のコマンドを使用します。
    otxadmin> invoke server.jms-service.jms-physical-destination.<送信先名>.resume
    「再開」は、どの停止状態(CONSUMERS_PAUSED、PRODUCERS_PAUSED、PAUSED)からでも再開します。

    例) 一時停止状態のトピックMyTopicを再開させる場合
    otxadmin> invoke server.jms-service.jms-physical-destination.MyTopic.resume


7.3.2.6. メッセージ一覧の取得

送信先に滞留している一つ一つのメッセージ情報を確認する場合に利用します。表示する情報は次のとおりです。

表7.3.2.6-1
表示名 説明
Timestamp タイムスタンプ。JMSTimestamp ヘッダフィールドの値です。long 値を「yyyy/MM/dd HH:mm:ss.SSS」形式に変換して表示します。
Type メッセージタイプ。次のタイプが存在します。
TEXT_MESSAGE : javax.jms.TextMessage のメッセージ
BYTES_MESSAGE : javax.jms.BytesMessage のメッセージ
MAP_MESSAGE : javax.jms.MapMessage のメッセージ
STREAM_MESSAGE : javax.jms.StreamMessage のメッセージ
OBJECT_MESSAGE : javax.jms.ObjectMessage のメッセージ
MESSAGE : javax.jms.Message のメッセージ
MessageID メッセージID。JMSMessageID ヘッダフィールドの値です。
CorrelationID 相関ID。JMSCorrelationID ヘッダフィールドの値です。
DeliveryMode 配信モード。JMSDeliveryMode ヘッダフィールドの値です。
Expiration 有効期限。JMSExpiration ヘッダフィールドの値です。
State JMSサーバに存在するメッセージの状態。送信先がキューの場合のみ表示します。次の状態が存在します。
INITIAL : 配信対象のコンシューマが決定していない状態
ROUTED : 配信対象のコンシューマが決定した状態
DELIVERED : コンシューマにメッセージを配信した状態
CONSUMED : コンシューマでメッセージを受信した状態
ACKED : コンシューマからの応答確認(ACKNOWLEDGE)が返ってきた状態
DeliveryCount 配信回数。JMSXDeliveryCount プロパティの値です。送信先がキューの場合のみ表示します。
Priority 優先順位。JMSPriority ヘッダフィールドの値です。もっとも低い順位が 0 で、もっとも高い順位が 9 です。
MessageProperty メッセージプロパティ
MessageBody メッセージボディ。指定された場合のみ表示します。表示内容はメッセージタイプに応じて次のようになっています。
TEXT_MESSAGE : javax.jms.TextMessage のメッセージ
BYTES_MESSAGE、MAP_MESSAGE、STREAM_MESSAGE : メッセージボディのサイズのみ表示
OBJECT_MESSAGE : javax.jms.ObjectMessage のメッセージ
MESSAGE : (表示なし)

統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「JMSサービス」-「送信先名」-「<送信先名>」を選択して右クリックするか、選択した状態でメニューバーの[操作]を選択します。
  2. 送信先の現時点の状態などを知りたい場合は、メニューから「メッセージ一覧の取得」を選択し、表示されるダイアログで「メッセージ一覧開始点」、「メッセージ一覧終了点」、「セレクタ」、「メッセージ本体表示」を指定して、「実行」ボタンをクリックします。
注意 :
メッセージの最大表示件数は、JMSサービスのプロパティ「メッセージ一覧表示最大件数(displayMessageCount)」で制限されています。デフォルトは最大1000件です。


運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. 送信先に滞留しているメッセージの一覧を表示するには以下のコマンドを使用します。
    otxadmin> list-jmsdest-messages [--fromIndex <表示開始点>] [--toIndex <表示終了点>] [--selector <メッセージセレクタ>] [--messageBody=(true|false)] <送信先名>

    例) メッセージセレクタを指定して、キューMyQueueのメッセージ一覧を表示する場合
    otxadmin> list-jmsdest-messages --selector "NewsType = 'Sports' OR NewsType = 'Business'" MyQueue

list-jmsdest-messages コマンドの詳細については、運用管理コマンドリファレンスの「list-jmsdest-messages」を参照してください。


7.3.2.7. 指定メッセージパージ・メッセージ全件パージ

統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「JMSサービス」-「送信先名」-「<送信先名>」を選択して右クリックするか、選択した状態でメニューバーの[操作]を選択します。
  2. ある特定のメッセージをパージする場合は、メニューから「指定メッセージパージ」を選択し、表示されるダイアログで、パージ対象の「メッセージID」を入力して、「実行」ボタンをクリックします。
  3. この「メッセージID」は、メッセージ一覧の取得で表示されたメッセージIDを指定します。
  4. 送信先に滞留しているすべてのメッセージをパージする場合は、メニューから「メッセージ全件パージ」を選択し、表示されるダイアログで「実行」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. ある特定のメッセージをパージする場合は、以下のコマンドを使用します。
    otxadmin> invoke server.jms-service.jms-physical-destination.<送信先名>.purgeMessage <メッセージID>

    例) キューMyQueueに滞留しているメッセージをパージする場合
    otxadmin> invoke server.jms-service.jms-physical-destination.MyQueue.purgeMessage 6-172.16.254.239(fd:af:ca:bc:90:f6)-2380-1148467078081
    この「メッセージID」は、メッセージ一覧の取得で表示されたメッセージIDを指定します。


  2. 送信先に滞留しているすべてのメッセージをパージする場合は、以下のコマンドを使用します。
    otxadmin> invoke server.jms-service.jms-physical-destination.<送信先名>.purge

    例) キューMyQueueに滞留しているメッセージをパージする場合
    otxadmin> invoke server.jms-service.jms-physical-destination.MyQueue.purge
    この「メッセージID」は、メッセージ一覧の取得で表示されたメッセージIDを指定します。


7.3.2.8. 永続サブスクリプションの操作(トピックのみ)

統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「JMSサービス」-「送信先名」-「<送信先名>」を選択して右クリックするか、選択した状態でメニューバーの[操作]を選択します。
  2. トピックに対する永続サブスクリプションの一覧を表示するには、メニューから「永続サブスクリプションの一覧表示」を選択し、表示されるダイアログで「実行」ボタンをクリックします。表示する情報は、左から順に、永続サブスクリプション名、クライアントID、メッセージ数、状態(true:アクティブ/false:非アクティブ)です。

    永続サブスクリプションの操作
    図7.3.2.8-1

  3. 永続サブスクリプションのメッセージをパージするには、メニューから「永続サブスクリプションのメッセージのパージ」を選択し、表示されるダイアログで、パージ対象の「永続サブスクリプション名」と、「クライアントID」を入力して、「実行」ボタンをクリックします。この「永続サブスクリプション名」や、「クライアントID」には、2の一覧表示で表示されたものを指定します。
  4. 永続サブスクリプションを削除するには、メニューから「永続サブスクリプションの削除」を選択し、表示されるダイアログで、削除対象の「永続サブスクリプション名」と、「クライアントID」を入力して、「実行」ボタンをクリックします。この「永続サブスクリプション名」や、「クライアントID」には、2の一覧表示で表示されたものを指定します。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. トピックに対する永続サブスクリプションの一覧を表示するには、list-jmsdest-durコマンドを使用します。
    otxadmin> list-jmsdest-dur <トピック名>

    例) トピックMyTopicに対する永続サブスクリプションの一覧を表示する場合
    otxadmin> list-jmsdest-dur MyTopic
     
    結果表示例) 
    -------------------------------------------------------------------
    Durable Sub. Name Client ID Number of Messages Durable Sub. State
    -------------------------------------------------------------------
    subscription      client1   92                 false
    subscription      client2   0                  true
    Command list-jmsdest-dur executed successfully.
    
    表示する情報は、左から順に、永続サブスクリプション名、クライアントID、メッセージ数、状態(true:アクティブ/false:非アクティブ)です。

    list-jmsdest-durコマンドの詳細については、運用管理コマンドリファレンスの「list-jmsdest-dur」を参照してください。


  2. 永続サブスクリプションのメッセージをパージするには、以下のコマンドを使用します。
    otxadmin> invoke server.jms-service.jms-physical-destination.<送信先名>.purgeDur <永続サブスクリプション名> <クライアントID>

    例) トピックMyTopicの永続サブスクリプション(永続サブスクリプション名:subscription、クライアントID:clinet2)のメッセージをパージする場合
    otxadmin> invoke server.jms-service.jms-physical-destination.MyTopic.purgeDur subscription client2

    この「永続サブスクリプション名」や、「クライアントID」には、1の一覧表示で表示されたものを指定します。


  3. 永続サブスクリプションを削除するには、以下のコマンドを使用します。
    otxadmin> invoke server.jms-service.jms-physical-destination.<送信先名>.deleteDur <永続サブスクリプション名> <クライアントID>

    例) トピックMyTopicの永続サブスクリプション(永続サブスクリプション名:subscription、クライアントID:clinet2)を削除する場合
    otxadmin> invoke server.jms-service.jms-physical-destination.MyTopic.deleteDur subscription client2

    この「永続サブスクリプション名」や、「クライアントID」には、1の一覧表示で表示されたものを指定します。

7.3.2.9. JMSメッセージの送信

環境構築時の確認や、コンシューマアプリケーションの受信動作確認など、簡単なメッセージ送信に利用できます。1回のメッセージ送信操作で送信できるメッセージは、1件です。

送信メッセージに設定できる項目と既定値は、次のとおりです。設定項目の()内の記述は、対応するヘッダフィールド名を示します。

表7.3.2.9-1
設定項目 説明 既定値
メッセージタイプ 送信するメッセージのタイプ
次のタイプが送信可能。
TextMessage : メッセージボディにStringを含むもの
Message : メッセージボディのない軽量なメッセージ
BytesMessage : メッセージボディにバイト配列を含むもの
TextMessage
メッセージボディの指定方法 メッセージボディの指定方法
text : メッセージボディに指定された文字列をボディそのものとして設定
file : メッセージボディに指定された文字列をファイル名として、指定されたファイルの内容をメッセージボディに設定
text
メッセージボディ メッセージボディ
TextMessageの場合 : メッセージボディタイプのtext、fileをサポート。file を指定した場合、文字コードはプラットフォームのデフォルトエンコーディングなる
Messageの場合 : メッセージボディなし。指定されていても無視
BytesMessageの場合 : メッセージボディタイプはfileのみ有効。指定されたファイルの内容をバイト配列に変換して設定
-
配信モード (JMSDeliveryMode) メッセージを永続化するかどうか
PERSISTENT : 永続化する
NON_PERSISTENT : 永続化しない
PERSISTENT
有効期限 (JMSExpiration) メッセージの有効期限 (ミリ秒)
0 (有効期限なし)
優先順位 (JMSPriority) メッセージの優先順位 (0-9)
4
相関ID (JMSCorrelationID) メッセージを対応付けるための文字列
指定可能な値は、Stringのみ。
-
応答用送信先 (JMSReplyTo) メッセージを受信したコンシューマが返信する送信先
-
応答用送信先のタイプ 応答用送信先のタイプ
queue : キュー
topic : トピック
queue
タイプ (JMSType) 任意の文字列
-
配信遅延時間 配信遅延時間
WebOTX JMS固有の拡張機能で、相対時間(秒)での指定のみ可能。
0 (遅延時間なし)
メッセージプロパティ メッセージプロパティ
設定可能なプロパティ値は、Stringのみ。
-


統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「JMSサービス」-「送信先名」-「<送信先名>」を選択して右クリックするか、選択した状態でメニューバーの[操作]を選択します。
  2. メニューから「JMSメッセージの送信」を選択し、表示されるダイアログで必要な項目を設定して「実行」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. JMSメッセージを送信するには以下のコマンドを使用します。
    otxadmin> send-jms-message [--msgtype <メッセージタイプ>] [--msgbodytype <メッセージボディの指定方法>] [--msgbody <メッセージボディ>] [--msgpersistent <配信モード>] [--msgexpiration <有効期限>] [--msgpriority <優先順位>] [--msgcorrelationid <相関ID>] [--msgreplyto <応答用送信先>] [--msgreplytotype <応答用送信先タイプ>] [--msgjmstype <タイプ>] [--msgdelaytime <配信遅延時間>] [--property <メッセージプロパティ>] <送信先名>
    send-jms-message コマンドの詳細については、運用管理コマンドリファレンスの「send-jms-message」を参照してください。


7.3.2.10. メッセージ移動

送信先に滞留している通常メッセージや、不達メッセージ(再配信回数の上限を超えたメッセージ)、有効期限切れメッセージを別の送信先に移動する場合に利用します。移動後のメッセージはメッセージIDなどが変わります。移動によるメッセージヘッダや、プロパティの変更内容は次のとおりです。

表7.3.2.10-1
ヘッダ / プロパティ 移動対象
通常メッセージ / 永続サブスクリプション 不達メッセージ 有効期限切れメッセージ
JMSDestination 移動先の送信先
元の送信先の情報は、WOJMSOriginalDestinationName に設定します。
移動先の送信先
元の送信先の情報は、WOJMSOriginalDestinationName に設定します。
移動先の送信先
元の送信先の情報は、WOJMSOriginalDestinationName に設定します。
JMSDeliveryMode 変更しない WOJMSOriginalPersistentから復元 WOJMSOriginalPersistentから復元
JMSExpiration 変更しない WOJMSOriginalExpirationから復元 クリア(0を設定)
JMSPriority 変更しない 変更しない 変更しない
JMSMessageID 新規メッセージIDに変更
元の情報は、WOJMSOriginalMessageID に設定します。
WOJMSOriginalMessageIDから復元 WOJMSOriginalMessageIDから復元
JMSTimestamp 移動した時刻に変更 WOJMSOriginalTimeStampから復元 WOJMSOriginalTimeStampから復元
JMSCorrelationID 変更しない 変更しない 変更しない
JMSReplyTo 変更しない 変更しない 変更しない
JMSType 変更しない 変更しない 変更しない
JMSRedelivered 変更しない 変更しない 変更しない
WOJMSDelayTime 変更しない WOJMSOriginalDelayTimeから復元 WOJMSOriginalDelayTimeから復元
WOJMSOriginalMessageID 移動前のメッセージID 削除 削除
WOJMSOriginalDestinationName 移動前の送信先名 移動前の送信先名 移動前の送信先名
WOJMSOriginalExpiration - 削除 削除
WOJMSOriginalTransactionID - 削除 削除
WOJMSOriginalPersistent - 削除 削除
WOJMSOriginalTimeStamp - 削除 削除
WOJMSOriginalDelayTime - 削除 削除
WOJMSDeletedReason - 削除 削除
そのほかのメッセージプロパティ 変更しない (すべてのプロパティをそのまま設定) 変更しない (すべてのプロパティをそのまま設定) 変更しない (すべてのプロパティをそのまま設定)

備考 :

統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. 移動元と、移動先の送信先を、ALL(コンシューマ、プロデューサともに停止)で一時停止します。送信先の一時停止方法は、「送信先の一時停止・再開」を参照して下さい。
  2. 「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「JMSサービス」-「送信先名」-「<(移動元の)送信先名>」を選択して右クリックするか、選択した状態でメニューバーの[操作]を選択します。
  3. メニューから「メッセージ移動」を選択し、表示されるダイアログで、移動元の送信先のタイプに応じて必要な項目を指定し、「実行」ボタンをクリックします。
    キューの場合:
    「移動対象」、「移動先の送信先名」、移動メッセージの条件を絞りたい場合は「メッセージセレクタ」を指定します。
    トピックの場合:
    「永続サブスクリプション名」、「クライアントID」、「移動先の送信先名」を指定します。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. 移動元と、移動先の送信先を、ALL(コンシューマ、プロデューサともに停止)で一時停止します。送信先の一時停止方法は、「送信先の一時停止・再開」を参照して下さい。
  2. JMSメッセージを移動するには以下のコマンドを使用します。移動元の送信先のタイプに応じて指定するオプションが異なります。
    キューの場合:
    otxadmin> move-jmsdest-messages --msgmovetype move_type [--selector selector] <移動元の送信先名> <移動先の送信先名>
    トピックの場合:
    otxadmin> move-jmsdest-messages --msgmovedur durable_name --msgmovecid client_id <移動元の送信先名> <移動先の送信先名>
    例) キュー DMQ に転送された不達メッセージを元のキュー MyQueue へ戻す場合
    otxadmin> move-jmsdest-messages --msgmovetype redelivery DMQ MyQueue

    例) トピック MyTopic の永続サブスクリプション Sub1 からキュー MyQueue へ移動する場合
    otxadmin> move-jmsdest-messages --msgmovedur Sub1 --msgmovecid Client1 MyTopic MyQueue


move-jmsdest-messages コマンドの詳細については、運用管理コマンドリファレンスの「move-jmsdest-messages」を参照してください。


7.3.2.11. 滞留メッセージの優先順位変更

送信先に滞留しているメッセージの優先順位を、運用操作により変更する場合に利用します。

備考 :
統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「JMSサービス」-「送信先名」-「<送信先名>」を選択して右クリックするか、選択した状態でメニューバーの[操作]を選択します。
  2. メニューから「メッセージ優先順位変更」を選択し、表示されるダイアログで、変更対象の「メッセージID」を入力して、「実行」ボタンをクリックします。
  3. この「メッセージID」は、メッセージ一覧の取得で表示されたメッセージIDを指定します。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. ある特定のメッセージの優先順位を変更する場合は、以下のコマンドを使用します。
    otxadmin> update-jms-message [--msgpriority <優先順位>] <送信先名> <メッセージID>

    例) キュー MyQueue に滞留しているメッセージの優先順位を 9 に変更する場合
    otxadmin> update-jms-message --msgpriority 9 MyQueue 6-172.16.254.239(fd:af:ca:bc:90:f6)-2380-1148467078081
    この「メッセージID」は、メッセージ一覧の取得で表示されたメッセージIDを指定します。


7.3.3. JMSリソースの操作

JMSリソース(コネクションファクトリリソース、送信先リソース)の作成と削除、および、項目の参照と設定の手順について説明します。

7.3.3.1. 新規作成

統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. ツリービューより、「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「リソース」-「JMSリソース」を選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。

    JMSリソースの新規作成
    図7.3.3.1-1

  2. メニューから、作成するリソースに応じて、以下を選択します。
    • コネクションファクトリリソース : 「コネクションファクトリリソースの作成」
    • 送信先リソース : 「送信先リソースの作成」
  3. 表示されるダイアログで、「一般」タブの「JNDI名」、「リソースタイプ」を指定し、さらに、必要な属性の値を指定して「実行」ボタンをクリックします。
  4. 作成が正常終了すると、ツリービューにそれぞれ以下のMOが表示されます。

    コネクションファクトリリソース :
    「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「リソース」-「JMSリソース」-「コネクションファクトリリソース」-「<JNDI名>」

    コネクションファクトリリソース作成時には、以下のMOも自動的に作成して表示します。
    「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「リソース」-「コネクタコネクションプール」-「<JNDI名>」
    「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「リソース」-「コネクターリソース」-「<JNDI名>」
    「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「リソース参照」-「<JNDI名>」

    送信先リソース :
    「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「リソース」-「JMSリソース」-「送信先リソース」-「<JNDI名>」

    送信先リソース作成時には、以下のMOも自動的に作成して表示します。
    「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「リソース」-「admin-object-resource」-「<JNDI名>」
    「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「リソース参照」-「<JNDI名>」

    備考 :
    送信先リソース作成時に、「物理的な送信先を同時に生成する」をチェックすることで、「送信先名」に指定した物理的な送信先を同時に作成することができます。


運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. JMSリソースを新規に作成する場合は、create-jms-resourceコマンドを使用します。
    otxadmin> create-jms-resource --restype <リソースタイプ> [オプション] <JNDI名>

    例) 送信先リソースを作成する場合
    otxadmin> create-jms-resource --restype javax.jms.Topic --wojmsDestinationName MyTopic jms/MyTopic

注意 :
送信先リソースを作成する場合、物理的な送信先名(--wojmsDestinationName)の指定は必須です。

作成時に、属性や、プロパティを指定することもできます。また、送信先リソースの場合、--cascadeオプションを付加することによって、送信先名に指定した物理的な送信先を同時に作成することも可能です。コマンドの詳細については、運用管理コマンドリファレンスの「create-jms-resource」を参照してください。


7.3.3.2. 削除

統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. 対象のリソースに応じて、それぞれ以下を選択して右クリックするか、選択した状態でメニューバーの[操作]を選択します。

    コネクションファクトリリソース :
    「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「リソース」-「JMSリソース」-「コネクションファクトリリソース」-「<JNDI名>」
    送信先リソース :
    「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「リソース」-「JMSリソース」-「送信先リソース」-「<JNDI名>」


  2. メニューから「削除」を選択し、表示されるダイアログで「実行」ボタンをクリックします。

    JMSリソースの削除
    図7.3.3.2-1

    備考 :
    送信先リソース削除時に、「物理的な送信先を同時に削除する」をチェックすることで、「送信先名」に指定した物理的な送信先を同時に削除することができます。


運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. JMSリソースを削除する場合は、delete-jms-resourceコマンドを使用します。
    otxadmin> delete-jms-resource <JNDI名>

    例) 送信先リソースを削除する場合
    otxadmin> delete-jms-resource jms/MyTopic


送信先リソースの場合、--cascadeオプションを付加することによって、送信先名に指定した物理的な送信先を同時に削除することも可能です。delete-jms-resourceコマンドの詳細については、運用管理コマンドリファレンスの「delete-jms-resource」を参照してください。

7.3.3.3. 属性参照・設定

JMSリソース(コネクションファクトリリソース、送信先リソース)の属性の詳細については、MO定義リファレンスの「jms-connection-factory」、および、「jms-logical-destination」を参照してください。

統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. 対象のリソースに応じて、それぞれ以下を選択します(選択すると、リストビューから各属性を参照できます)。

    コネクションファクトリリソース :
    「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「リソース」-「JMSリソース」-「コネクションファクトリリソース」-「<JNDI名>」
    送信先リソース :
    「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「リソース」-「JMSリソース」-「送信先リソース」-「<JNDI名>」

  2. リストビューから変更したい属性を選択して変更します。
  3. 「更新」ボタンをクリックして変更を反映します。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. 項目に設定している値を参照するには、getコマンドを使用します。

    例) 1つの項目を参照する場合
    otxadmin> get server.resources.jms-resource.jms-connection-factory.jms/MyQueueFactory.wojmsConnectionType

    例) すべての項目を参照する場合(プロパティが設定されている場合は、プロパティも表示されます)
    otxadmin> get server.resources.jms-resource.jms-connection-factory.jms/MyQueueFactory.*

  2. 項目の値を設定するには、setコマンドを使用します。

    例) コネクションタイプを設定する場合
    otxadmin> set server.resources.jms-resource.jms-connection-factory.jms/MyQueueFactory.wojmsConnectionType=TCP


7.3.3.4. プロパティ参照・設定

統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. 対象のリソースに応じてそれぞれ以下を選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。

    コネクションファクトリリソース :
    「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「リソース」-「JMSリソース」-「コネクションファクトリリソース」-「<JNDI名>」
    送信先リソース :
    「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「リソース」-「JMSリソース」-「送信先リソース」-「<JNDI名>」

  2. プロパティを参照する場合は、メニューから「プロパティ一覧の取得」を選択し、表示されるダイアログで「実行」ボタンをクリックします。
  3. プロパティを設定する場合は、メニューから「プロパティの設定」を選択し、表示されるダイアログで設定値を入力して「実行」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作
属性の参照・設定と同様にgetコマンド、setコマンドを利用します。

例) すべてのプロパティを参照する場合
otxadmin> get server.resources.jms-resource.jms-connection-factory.jms/MyQueueFactory.property.*


7.3.4. JMSサービスの統計情報取得

JMSサービスに関する統計情報の採取、および、取得方法について説明します。統計情報の取得に関する詳細は、 [ ドメイン構築・基本設定ガイド > 9. モニタリング ] を参照してください。

統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. 統合運用管理ツールよりドメインと接続します。
  2. ツリービューより、「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「モニタリングサービス」-「モジュールモニタリングレベル」を選択します。
  3. リストビューの「JMSサービス」属性に「ON」を設定し、「更新」ボタンをクリックします。この設定を行うことで、JMSサービスに関する統計情報の表示が可能になります。

    JMSサービスの統計情報取得
    図7.3.4-1

  4. ツリービューより、「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「統計情報」-「<ドメイン名>」-「JMSサービス」を選択します。リストビューの「統計属性」で統計情報を参照できます。
  5. 物理的な送信先を登録している場合は、「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「統計情報」-「<ドメイン名>」-「JMSサービス」-「送信先名」-「<送信先名>」を選択することで、送信先に関する情報も参照できます。
  6. 4の状態で、「統計情報採取開始」の操作を選択することにより、統計情報のグラフ表示を行うことができます。

    JMSサービスの統計情報採取開始
    図7.3.4-2


運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. otxadmin コマンドを起動し、ドメインにログインします。
  2. 次のコマンドで、JMSサービスに関する統計情報の採取を開始します。
    otxadmin> set server.monitoring-service.module-monitoring-levels.jms-service=ON
  3. 統計情報を参照するには、getコマンドに--monitor=trueオプションをつけて実行します。

    例) JMSサービスの統計情報を参照する場合
    otxadmin> get --monitor=true server.jms-service.*

    例) 送信先の統計情報を参照する場合
    otxadmin> get --monitor=true server.jms-service.jms-physical-destination.MyTopic.*

備考 :
表示される情報の詳細については、[ リファレンス集 運用管理・設定編 > 3. モニタリング > 3.2. 採取可能なパフォーマンス情報 > JMSServiceStatsJMSPhysicalDestinationStats ]を参照してください。

7.4. Transactionサービス

Transactionサービスに関する運用操作法について説明します。なお、各属性の説明については[ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.9. Transactionサービス > 1.9.3. Transactionサービスに関する設定 ]をご参照ください。

7.4.1. Transactionサービスの起動・停止

Transactionサービスの起動、および停止処理の手順について説明します。

7.4.1.1. 統合運用管理ツールから操作

1.  統合運用管理ツールよりドメインと接続します。

2.  ツリービューより「<ドメイン名>」−「アプリケーションサーバ」−「Transactionサービス」を選択し右クリックします。

3.  「Transactionの開始」を選ぶとTransactionサービスを開始します。逆に「Transactionサービスの停止」を選ぶとTransactionサービスを停止します。


図7.4.1.1-1

7.4.1.2. コマンドから操作

1.  otxadmin コマンドを起動し、ドメインにログインします。

2.  Transactionサービスを開始する場合は次のコマンドを実行します。

otxadmin> start-transaction-service
あるいは
otxadmin> invoke server.transactionservice.start

3.  逆にTransactionサービスを停止する場合は次のコマンドを実行します。

otxadmin> stop-transaction-service
あるいは
otxadmin> invoke  server.transactionservice.stop

7.4.2. リソースの登録・削除

2フェーズコミットの途中で障害が発生した場合、Transactionサービスは、トランザクションのリカバリ処理を実行します。リカバリ処理で使用するデータベースやコネクタリソースの情報を、Transactionサービスのリソースとして定義します。ここでは、そのリソースの登録・削除操作の手順について説明します。

7.4.2.1. 統合運用管理ツールからリソース登録・削除

JDBCリソース、JCAリソース、C++ XAリソースの登録・削除を行う場合は、次の手順で操作を行ってください。JDBCリソースは、「JDBCデータソースのテスト」操作を行った時や、トランザクション実行時に自動的に生成されます。そのため、登録作業を省略することができます。

1.   統合運用管理ツールよりドメインと接続します。

2.   ツリービューより「<ドメイン名>」−「アプリケーションサーバ」−「Transactionサービス」−「リソース」を選択します。

3.   右クリックメニューより次のいずれかのオペレーションを実行します。

「JDBCリソースの登録」、または、「JDBCリソースの削除」
「JCAリソースの登録」、または、「JCAリソースの削除」
「XAリソースの登録(C++)」、または、「XAリソースの削除」

4.   表示された画面で、生成、または、削除するリソースの名前と、必要な情報を設定してください。設定内容の詳細は、[ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.9. Transactionサービス > 1.9.3. Transactionサービスに関する設定 ]を参照してください。

5.   自動生成されたJDBCリソースを表示するためには、「リソース」の「リソースの再表示」オペレーションを実行します。

また、AP用C++ XAリソースの登録・削除を行う場合は、次の手順で操作を行ってください。TransactionサービスとAPで同じC++ XAリソースを使用する場合は、AP用C++ XAリソースの登録作業を行う必要はありません。

1.  ツリービューより「<ドメイン名>」−「アプリケーションサーバ」−「Transactionサービス」−「リソース」−「cppxa-resource」−「C++XAリソース名」を選択します。

2.   右クリックメニューより次のいずれかのオペレーションを実行します。

「AP用C++XAリソースの登録」、または、「AP用C++XAリソースの削除」

3.   表示された画面で、生成、または、削除するリソースの名前と、必要な情報を設定してください。設定内容の詳細は、[ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.9. Transactionサービス > 1.9.3. Transactionサービスに関する設定 ]を参照してください。

7.4.2.2. コマンドからリソース登録・削除

1.   otxadmin コマンドを起動し、ドメインにログインします。

2.   リソースの登録、または、リソースの削除コマンドを実行します。

リソースの登録
otxadmin> create-ts-jdbc-resource リソース名
otxadmin> create-ts-jca-resource リソース名
otxadmin> create-ts-cppxa-resource --xaresourcetype XAリソースタイプ  --openstring オープン文字列  リソース名
otxadmin> create-ts-cppxa-ap-resource --xaresourcetype XAリソースタイプ  --openstring オープン文字列  上位のC++XAリソース名  登録するリソース名

リソースの削除
otxadmin> delete-ts-jdbc-resource  リソース名
otxadmin> delete-ts-jca-resource リソース名
otxadmin> delete-ts-cppxa-resource リソース名
otxadmin> delete-ts-cppxa-ap-resource 上位のC++ XAリソース名  削除するリソース名

3.   自動生成されたリソースを表示します。

otxadmin> invoke server.transactionservice.resources.refresh

7.4.3. トランザクション一覧情報の取得操作

稼動中のトランザクション一覧情報を取得するための手順について説明します。

WebOTXでは、業務アプリケーションの稼動状態などの統計情報を採取する機能を提供しています。Transactionサービスに関しても、稼動中のトランザクション一覧や数、平均処理時間などの情報を採取し、表示する機能を提供しています。

ただし全ての統計情報を採取すると逆にトランザクション自体の性能劣化につながります。そのためTransactionサービスでは3つの情報採取レベルを用意し、レベルに応じて採取する情報の量を調整できるようにしています。詳しくは、[ リファレンス集 運用管理・設定編 > 3. モニタリング > 3.2. 採取可能なパフォーマンス情報 > JTAStats ]を参照してください。

なお、表示するトランザクション情報もそのレベルに応じて変わります。

7.4.3.1. トランザクション情報採取レベル

Transactionサービスで用意している3つの情報採取レベルにはOFF/LOW/HIGHの3つがあります。それらのレベルに応じて表示する稼動中のトランザクション情報が異なります。障害状態になっているトランザクションなど重要度が高いものについては設定されているレベルが低くても表示されるようになっています。

表7.4.3.1-1

項目

説明

表示対象となるトランザクション情報

OFF (レベル0) 統計情報は基本的に採取しません。 次の状態のトランザクション情報のみ表示します。
  • StatusCommitted
  • StatusRolledBack
  • StatusUnknown
LOW (レベル1) Transactionサービスで提供する統計情報のうち、障害レベルのものについてのみ採取します。レベルOFFの場合に比べ、若干のトランザクション性能劣化が発生します。 次の状態のトランザクション情報のみ表示します。
  • StatusCommitting
  • StatusRollingBack
  • StatusCommitted
  • StatusRolledBack
  • StatusUnknown
HIGH (レベル2) Transactionサービスで提供する統計情報の全てを採取します。レベルLOWの場合に比べ、大きなトランザクション性能劣化が発生します。 トランザクションの状態に関わらず全てのトランザクション情報を表示します。

これらのレベルについては次の手順で参照することができます。


図7.4.3.1-1

統合運用管理ツールを用いたトランザクション情報採取レベルの参照

1.   統合運用管理ツールよりドメインと接続します。

2.   ツリービューより「<ドメイン名>」−「アプリケーションサーバ」−「Transactionサービス」−「Transaction情報」を選択すると右側に表示されます。

コマンドを用いたトランザクション情報採取レベルの参照

1.   otxadmin コマンドを起動し、ドメインにログインします。

2.   次のコマンドを実行します。0〜2の数字が戻り値として表示されます。

otxadmin> get server.transactionservice.tstxlist.monitor-level

なお、「Transaction情報」(tstxlist)からトランザクション情報採取レベルを設定することはできません。設定については上の絵の中に書かれているように「モニタリングサービス」のところから実施する必要があります。詳細は[ リファレンス集 運用管理・設定編 > 3. モニタリング ]を参照してください。ここでは簡単に方法を記載します。

統合運用管理ツールを用いたトランザクション情報採取レベルの操作

1.   統合運用管理ツールよりドメインと接続します。

2.   ツリービューより「<ドメイン名>」−「アプリケーションサーバ」−「モニタリングサービス」−「モジュールモニタリングレベル」を選択します。

3.   右側に表示される項目のうち、「transactionserviceモニタリングレベル」のところにOFF/LOW/HIGHのいずれかを指定します。

コマンドを用いたトランザクション情報採取レベルの参照

1.   otxadmin コマンドを起動し、ドメインにログインします。

2.   次のコマンドのいずれかを実行します。’=’の後に「OFF」「LOW」「HIGH」のいずれかの文字列を指定します。

otxadmin> set server.monitoring-service.module-monitoring-levels.transaction_service=OFF
otxadmin> set server.monitoring-service.module-monitoring-levels.transaction_service=LOW
otxadmin> set server.monitoring-service.module-monitoring-levels.transaction_service=HIGH

次に稼動中のトランザクション一覧の取得方法を記載します。

7.4.3.2. 統合運用管理ツールからトランザクション一覧の取得操作

1.   統合運用管理ツールよりドメインと接続します。

2.   ツリービューより「<ドメイン名>」−「アプリケーションサーバ」−「Transactionサービス」−「Transaction情報」を選択し右クリックします。

3.   「Transaction一覧取得」を選ぶとサーバに対して処理要求を実施します。

4.   「Transaction情報」ツリーの下に各トランザクション情報が表示されます。

7.4.3.3. コマンドからトランザクション一覧の取得操作

1.  otxadmin コマンドを起動し、ドメインにログインします。

2.   次のコマンドを実行します。

otxadmin> invoke server.transactionservice.tstxlist.txlist

3.   2.で実行したコマンドはサーバから情報を取得しただけなので、一覧を表示させるにはさらに次のコマンドを実行します。

otxadmin> list server.transactionservice.tstxlist.*

4.   3.を実行すると次のようにリスト表示されます。

server.transactionservice.tstxlist.0871227903690002
server.transactionservice.tstxlist.0910828752910004
数字の列がトランザクション識別子です。さらに例として次のようにすると各トランザクションの情報を見ることができます。
otxadmin> get server.transactionservice.tstxlist.*.*
次のように表示されます。ワイルドカードの部分を変えると表示内容を限定することができます。
server.transactionservice.tstxlist.0871227903690002.otid = 980614.3030323030354170723036323132363037303030303431343064726F6E676F
server.transactionservice.tstxlist.0871227903690002.owner = Recover
server.transactionservice.tstxlist.0871227903690002.starttime = 2005/4/6 21:26:9
server.transactionservice.tstxlist.0871227903690002.status = StatusUnknown
server.transactionservice.tstxlist.0871227903690002.stxid = 0871227903690002
server.transactionservice.tstxlist.0910828752910004.otid = 69637.7473430000000000000000000000000000002394000000004254DF1F000000004255211B00000004
server.transactionservice.tstxlist.0910828752910004.owner = Active
server.transactionservice.tstxlist.0910828752910004.starttime = 2005/4/7 21:1:31
server.transactionservice.tstxlist.0910828752910004.status = StatusUnknown
server.transactionservice.tstxlist.0910828752910004.stxid = 0910828752910004

7.4.4. トランザクションの操作

各トランザクションに対して強制的に完了操作を行うことができます。その手順について説明します。

7.4.4.1. 統合運用管理ツールから操作

1.   統合運用管理ツールよりドメインと接続します。

2.   ツリービューより「<ドメイン名>」−「アプリケーションサーバ」−「Transactionサービス」−「Transaction情報」−「<トランザクション識別子>(数字の部分)」を選択し右クリックします。右側にはトランザクションに関する情報が表示されます。

3.   該当するトランザクションに対して行いたい処理に応じてメニューを選択します。ただしトランザクションの状態に応じて実行可能なコマンドの種類は限定されますのでご注意ください。


図7.4.4.1-1

7.4.4.2. コマンドから操作

1.   otxadminコマンドを起動し、ドメインにログインします。

2.   次のコマンドを実施すると稼動中トランザクションの識別子一覧を見ることができます。

otxadmin> get server.transactionservice.tstxlist.*.stxid

3.   次のコマンドを実行してトランザクションの完了処理を行うことができます。<トランザクション識別子>のところには2.のコマンドで指定したstxid相当の数字を指定します。

強制コミットを行う場合
otxadmin> commit-transaction <トランザクション識別子>
強制ロールバックを行う場合
otxadmin> rollback-transaction <トランザクション識別子>
破棄(フォゲット)を行う場合
otxadmin> forget-transaction <トランザクション識別子>
強制削除を行う場合
otxadmin> delete-transaction <トランザクション識別子>


なお、強制削除を行うとトランザクションの継続処理を全く実施せずにトランザクション情報を削除してしまいますので、場合によってはトランザクション全体としての結果に矛盾が生じる場合があります。慎重に行ってください。

7.4.4.3. statsツリーからのトランザクションの操作

また、トランザクションの操作については、統合運用管理ツールの「<ドメイン名>」-「統計情報」−「domain」−「トランザクションサービス」のところでも実施することができます。詳細については [ ドメイン構築・基本設定ガイド > 3. ドメイン > 3.9. 統計情報の取得 > 3.9.4. Transactionサービス(JTA)統計情報の取得 ] をご参照ください。

7.4.5. リソースの運用操作

登録・削除以外の、リソースの運用操作を行うための手順について説明します。

7.4.5.1. リソースの開始と停止

データベースサーバのメンテナンスを行う場合など、データベースサーバとのコネクションを切断する必要がある場合は、リソースの停止オペレーションを実行します。データベースサーバのメンテナンスが終わった場合は、リソースの開始オペレーションを実行し、トランザクションのリカバリ処理を行うことができる状態に戻します。

7.4.5.2. 統合運用管理ツールからリソースの開始と停止

1.   統合運用管理ツールよりドメインと接続します。

2.   ツリービューより次のいずれかを選択します。

<ドメイン名>−「アプリケーションサーバ」−「Transactionサービス」−「リソース」−「jdbc-resource」−「リソース名」
<ドメイン名>−「アプリケーションサーバ」−「Transactionサービス」−「リソース」−「jca-resource」−「リソース名」
<ドメイン名>−「アプリケーションサーバ」−「Transactionサービス」−「リソース」−「cppxa-resource」−「リソース名」

3.   右クリックメニューより次のいずれかのオペレーションを実行します。

「リソースの開始」、または、「リソースの停止」

7.4.5.3. コマンドからリソースの開始と停止

1.   otxadmin コマンドを起動し、ドメインにログインします。

2.   リソースの開始、または、リソースの停止を実行します。

リソースの開始
otxadmin>  invoke server.transactionservice.resources.jdbc-resource.リソース名.start
otxadmin>  invoke server.transactionservice.resources.jca-resource.リソース名.start
otxadmin>  invoke server.transactionservice.resources.cppxa-resource.リソース名.start

リソースの停止
otxadmin>  invoke server.transactionservice.resources.jdbc-resource.リソース名.stop
otxadmin>  invoke server.transactionservice.resources.jca-resource.リソース名.stop
otxadmin>  invoke server.transactionservice.resources.cppxa-resource.リソース名.stop

7.4.5.4. トランザクションの手動リカバリ操作

トランザクションのリカバリ操作は、通常、本マニュアルの[ 3. ドメイン > 3.9. 統計情報の取得 > 3.9.4. Transactionサービス(JTA)統計情報の取得 > 3.9.4.3. トランザクションの操作 ]の説明に従って実行します。ただし、まれにDBMS間との状態不一致などによりトランザクションマネージャ側でトランザクションの結果を自動追跡できなくなる場合があります。そういう状態になった場合には、リソース毎にリカバリ操作を実行します。

なお、[ 3. ドメイン > 3.9. 統計情報の取得 > 3.9.4. Transactionサービス(JTA)統計情報の取得 > 3.9.4.3. トランザクションの操作 ]で表示されるトランザクションの情報は、リソース毎の操作では表示されません。

7.4.5.5. 統合運用管理ツールからトランザクションのリカバリ操作

1.   統合運用管理ツールよりドメインと接続します。

2.   ツリービューより次のいずれかを選択します。

<ドメイン名>−「アプリケーションサーバ」−「Transactionサービス」−「リソース」−「jdbc-resource」−「リソース名」
<ドメイン名>−「アプリケーションサーバ」−「Transactionサービス」−「リソース」−「jca-resource」−「リソース名」
<ドメイン名>−「アプリケーションサーバ」−「Transactionサービス」−「リソース」−「cppxa-resource」−「リソース名」

3.   右クリックメニューより「トランザクションの一覧表示」オペレーションを実行します。

オペレーションの実行結果として、次のような情報が表示されます。
   ShortTxId=[aaaa]status=[Heuristic]Xid=[formatID=xxxx1,gtrid=yyyy2,bqual=zzzz3]owner=[0]
   ShortTxId=[bbbb]status=[Heuristic]Xid=[formatID=xxxx1,gtrid=yyyy2,bqual=zzzz3]owner=[0]
   ShortTxId=[cccc]status=[Heuristic]Xid=[formatID=xxxx1,gtrid=yyyy2,bqual=zzzz3]owner=[0]

4.   「トランザクションの一覧表示」で表示された “ShortTxId”を指定して次のいずれかのオペレーションを実行します。

「トランザクションのコミット」
「トランザクションのロールバック」
「トランザクションのフォゲット」
「トランザクションの削除」

7.4.5.6. コマンドからトランザクションのリカバリ操作

1.   otxadmin コマンドを起動し、ドメインにログインします。

2.   トランザクションの一覧を表示します。

otxadmin> invoke server.transactionservice.resources.jdbc-resource.リソース名.list
otxadmin> invoke server.transactionservice.resources.jca-resource.リソース名.list
otxadmin> invoke server.transactionservice.resources.cppxa-resource.リソース名.list


3.   トランザクションのリカバリ処理を実行します。

otxadmin> invoke server.transactionservice.resources.リソースタイプ名.リソース名.commit ShortTxIdの値
otxadmin> invoke server.transactionservice.resources.リソースタイプ名.リソース名.rollback ShortTxIdの値
otxadmin> invoke server.transactionservice.resources.リソースタイプ名.リソース名.forget ShortTxIdの値
otxadmin> invoke server.transactionservice.resources.リソースタイプ名.リソース名.delete ShortTxIdの値


どの操作を行うかどうかについては、「トランザクションの一覧表示」で表示されたXidをキーにしてデータベース側のトランザクションの状態を確認した上で、決定してください。詳細は、各データベースのオンラインリファレンスを参照してください。

7.4.6. 1フェーズコミット対応リソースの2フェーズコミットへの参加

Transactionサービスは、X/Open分散トランザクション処理にしたがったデータベースへのアクセス、および更新をサポートしており、トランザクションマネージャとリソースマネージャとのやりとりにはXAインタフェースが使われます。

Transactionサービス内のリソースマネージャには、2フェーズコミットメントによるトランザクションの調整をサポートする「2フェーズコミット対応リソース」と、ローカルトランザクションのような1フェーズコミットメント調整だけをサポートする「1フェーズコミット対応リソース」の2種類が存在します。

例えば、ACOS上で管理されるデータベースのような2フェーズコミットメントをサポートしていないものへのアクセスにこの「1フェーズコミット対応リソース」を利用します。Transactionサービスでは、ACOS Access Toolkit(AAT)が提供するJDBCドライバと連携するための「1フェーズコミット対応リソース」を実装しており、それを使用することで、2フェーズコミットメントに対応していないACOS上のトランザクションをWebOTXシステムの2フェーズコミットトランザクションに参加できる機能を提供しています。 つまり同一のトランザクションで、ACOS上のデータベースと、Oracleなどオープンサーバ上のデータベースの同時更新を管理することができます。

7.4.6.1. フェーズコミット対応リソースを参加させるための準備

1フェーズコミット対応リソースをグローバルトランザクションに参加させる場合、JDBCデータソースに関する設定・登録が必要となります。登録の際にデータソースの種別(dataSourceType)に「JDBC API」を指定してください。リソースに対する運用操作については、リソースの種別に関わらず共通です。

JDBCデータソースに関する設定の詳細は、[ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.8. JDBCデータソース > 1.8.1. JDBCデータソース設定項目・設定方法 ]をご参照ください。また、AATとの連携のための準備についてもJDBCデータソースの章で掲載していますが、詳細はAATのマニュアルをご参照ください。

7.4.6.2. リソース混在時の注意事項

本来であれば、1つのグローバルトランザクション内で「2フェーズコミット対応リソース」と「1フェーズコミット対応リソース」を同時に参加させて、データの同時更新を行うことはできません。これは1フェーズコミット対応リソースが2フェーズコミットトランザクションに対応していないため、2フェーズコミットメントの第1段階(プリペア)を実行することができないからです。

WebOTXのTransactionサービスでは、上述のような混在を可能にする形態をサポートしています。ただしトランザクションの同時更新における一貫性を保証する関係上次のような構成上の制限をつけています。

・   1つのグローバルトランザクションに参加できる1フェーズコミット対応リソースは1つのみです。

例えば1フェーズコミット対応リソースが複数参加できてしまうと、片方の1フェーズコミット対応リソースのコミットが成功した後、別の1フェーズコミット対応リソースのコミットで失敗してしまうとデータの一貫性が守れないからです。
Transactionサービスでは、1つの1フェーズコミットメント対応リソースと任意の数の2フェーズコミット対応リソースの組み合わせでのトランザクション処理を行います。


・   伝播先トランザクションに1フェーズコミット対応リソースが参加している場合、伝播元(上位)のトランザクションに登録されているリソースが存在してはいけません。

提供機能編のTransactionサービスで記述したように、Transactionサービスでは「トランザクションの伝播機能」を提供しており、クライアントアプリケーションが呼び出したサーバオブジェクトを、クライアントが開始したトランザクションに参加させることができます。例えばEJB間の呼び出しを行う場合、EJBのトランザクション属性によってトランザクションの情報を伝播するか、呼び出し先で新たなトランザクションを開始させるか、トランザクションをサポートしないか、などを決めることができます。
そのEJBのトランザクション属性として、上位のトランザクションをそのまま伝播して使用するようなトランザクション構成をとる、かつ伝播先トランザクションで1フェーズコミット対応リソースにアクセスするようなものとすることも可能です。
ただしその場合、上位(伝播元)のトランザクションに登録されているリソース、および伝播トランザクションが存在してはいけません(伝播したトランザクションもトランザクションの参加者として登録されます)。例として図で表すと次のようになります(カッコ内はトランザクションを表しています)。


(OKの場合その1)


図7.4.6.2-1

(OKの場合その2)


図7.4.6.2-2

(OKの場合その3)


図7.4.6.2-3

(OKの場合その4)


図7.4.6.2-4

(NGの場合その1)


図7.4.6.2-5



(NGの場合その2)


図7.4.6.2-6

(NGの場合その3)


図7.4.6.2-7

このような制限を設ける理由として、例えばApplication間でのトランザクション連携が別ベンダ製品を含む複数アプリケーションサーバをまたがって行われている場合が考えられます。互いのアプリケーションサーバで、それぞれ1フェーズコミット対応リソースが参加していてもそれを互いに認識するためのインタフェースが提供されているとは限らないからです。少なくともWebOTXのTransactionサービスにはそれを通知するための手段は提供していません。

このような構成でトランザクションのコミットを実施しようとすると失敗します。トランザクション全体としてはロールバックしTRANSACTION_ROLLEDBACK例外が返されます。

7.4.6.3. トランザクション完了時の処理の流れ

トランザクションのコミット時には、まず2フェーズコミット対応リソース群に対して第1段階(プリペア)要求を発行します。2フェーズコミット対応リソース群のうち1つでも異常終了した場合は、トランザクション全体をロールバックさせます。

逆に全ての2フェーズコミット対応リソースから正常終了が戻ってきたら1フェーズコミット対応リソースに対して、コミット要求を発行します。プリペア相当は存在しないため、このタイミングですぐにコミット処理となります。AATと連携する場合、ACOS側データベースに対してAATが提供するJDBCドライバを経由してコミット要求を発行します。これが正常に終了するとトランザクション全体はコミットします。すなわち2フェーズコミット対応リソース群に対してコミットを要求します。逆に異常終了すると2フェーズコミット対応リソース群に対してロールバックを発行します。

7.4.6.4. フェーズコミット対応リソースに対するコミット失敗時の流れ

1フェーズコミット対応リソースがグローバルトランザクションに参加するモデルの場合、本来であれば1フェーズコミットメントでの動作を前提としているものを、いわば無理やり2フェーズコミットトランザクションに参加させているため、トランザクション完了処理の際にヒューリスティックとなる可能性が高くなります。つまりトランザクション全体をコミットしていいのかロールバックしていいのかTransactionサービス(トランザクションマネージャ)で判断がつかなくなる状態となります。

例えばACOSとの通信障害、あるいはアプリケーションの異常終了などにより1フェーズコミット対応リソースに対するコミット要求が失敗すると上述のような状態に陥ります。

この場合、ACOS側には処理要求が届いておりデータ更新が正常にコミットされているかもしれません。そうであればトランザクション全体をコミットする必要があります。逆に、処理要求自体がACOS側に到達していない可能性もあります。そうであればトランザクション全体をロールバックして更新を無効にしてあげなければなりません。

その際の復旧処理は次のように行います。

(1)   データベースの更新状況の判断

ACOS上のデータベースの更新状況を、トランザクションログなどを使って調査し、コミットすべきかロールバックすべきか決定します。


(2)   該当するトランザクションの検索

WebOTXが提供する統合運用管理ツール、あるいは運用管理コマンドよりトランザクション一覧を表示させます。トランザクション状態が「StatusPreparing」となっているトランザクションが該当するものです。


(3)   該当するトランザクションへのコマンド発行

(2)で見つけたトランザクションに対して、(1)の結果に応じて「強制コミット」あるいは「強制ロールバック」を発行して2フェーズコミット対応リソースへの完了要求を発行してください。詳細は本マニュアルの[ 3. ドメイン > 3.9. 統計情報の取得 > 3.9.4. Transactionサービス(JTA)統計情報の取得 > 3.9.4.3. トランザクションの操作 ]をご参照ください。


なお、トランザクション状態がStatusPreparingのものの一覧を表示させる場合、本マニュアルの[ 7.4.3. トランザクション一覧情報の取得操作 ]にあるように、トランザクションモニタレベルをHIGHにする必要があります。

7.4.7. クライアントアプリケーションの運用操作

クライアントアプリケーションにおいてもトランザクション機能を利用することができます。クライアントアプリケーションで利用するトランザクションを管理するためにProxy Recovery Coordination Server(以下Proxy RCS)、もしくは、リカバリサーバを利用する必要があります。ただし、EJBのクライアントであるアプリケーションクライアントではこれらのサーバは必要ありません。

Proxy RCSは統合運用管理ツールより起動することができます。詳細については、[ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.9. Transactionサービス > 1.9.3. Transactionサービスに関する設定 ]を参照してください。リカバリサーバはTS運用管理ツール、もしくは、サービス等から起動することができます。詳細については、 11.3. Transactionサービス (リカバリサーバ利用時) を参照してください。

なお、トランザクション機能を利用したクライアントアプリケーションのプログラミング方法については、 [ アプリケーション開発ガイド(CORBA) > 1. CORBA アプリケーション > 1.2. プログラミング・開発ガイド > 1.2.3. Transactionサービス ] の節を参照してください。

本節では、Proxy RCS、もしくは、リカバリサーバを利用するためのクライアント側の設定方法、及び、クライアントアプリケーションのトランザクションの動作トレースの採取の方法について説明します。

7.4.7.1. Proxy RCS、リカバリサーバを利用するための設定

Proxy RCS、もしくは、リカバリサーバを利用する際にはクライアントアプリケーション起動時にProxy RCS、もしくは、リカバリサーバのリファレンス(TransactionFactory)を取得する必要があります。このリファレンスは名前サーバに登録されています。このリファレンスを取得するためには以下のように設定します。

7.4.7.2. 設定内容

表7.4.7.2-1

名前

既定値

TFDecision Proxy RCS、リカバリサーバの位置

0: 自マシン上にある
1: 他のマシン上のものを利用
0
TFMachine TFDecisionが1の場合のマシン名 無し
NSRoot Proxy RCS、リカバリサーバが利用する名前サーバの初期コンテキストをINS形式で指定する。

例:corbaloc://ホスト名:ポート番号/NameService
無し(自ホストの名前サーバを利用)
TxTimeout トランザクションタイムアウト時間(秒)。0を指定するとタイムアウト無しとなる。 600

7.4.7.3. 設定方法

C++クライアントアプリケーションの場合)

Windows版:レジストリ(regeditで更新)\\HKEY_LOCAL_MACHINE\SOFTWARE\NEC\WebOTX_S\Client配下

UNIX版:/etc/WebOTX/TS/WebOTX_TS.confの[Client]セクション配下

Javaクライアントアプリケーションの場合)

クライアントアプリケーション起動時のシステムプロパティで指定する。(-D名前=値)

7.4.7.4. トレースを採取するための設定

クライアントアプリケーションのトランザクションの動作トレースの採取は以下の手順で行なえます。なお、EJBのアプリケーションクライアントに関しても同様の手順で採取できます。

1.   トレース採取方法設定ファイルを作成

C++クライアントアプリケーションの場合)

以下にあるので生成の必要はありません。

Windows: レジストリ\\HKEY_LOCAL_MACHINE\SOFTWARE\NEC\WebOTX\TS\Trace\WebOTX_S\Current配下
UNIX: /opt/share.nec/conf/comtrace.confの[WebOTX_S.Current]セクション
Javaクライアントアプリケーションの場合)

以下のJavaコマンドを実行して作成してください。これにより、trace.confファイルが生成されます。

Windows:コマンドプロンプトより以下を実行
> set CLASSPATH=(WebOTXインストールフォルダ)\TS\javalib\wots71.jar
> java jp.co.nec.WebOTX.TS.util.TraceGen -TraceFileName=CurTrace.trc
UNIX:以下のコマンドを実行
> setenv CLASSPATH=/opt/WebOTX/TS/javalib/wots71.jar
> java jp.co.nec.WebOTX.TS.util.TraceGen -TraceFileName=current.trc


2.   トレース採取方法設定ファイルの項目の設定

以下の項目を必要に応じて変更してください。

表7.4.7.4-1

名前

既定値

TraceLevel 0〜5

0:無し、1:エラー、2:警告、3:情報、4:詳細、5:デバッグ
1
TraceFileSize トレースファイルサイズ(Byte)、TraceLevelを5にする場合には、サイズを大きくして下さい 1048576(1MB)
TraceFileName 出力するトレースのファイル名 CurTrace.trc(C++)、もしくは、引数で指定したもの(Java)

3.   クライアントアプリケーション起動時にトレース採取方法設定ファイルを指定して実行

C++クライアントアプリケーションの場合)

特に指定しなくても自動的に参照します。

Javaクライアントアプリケーションの場合)

クライアントアプリケーション起動時のシステムプロパティに以下を追加してください。

-DJavaConfigPath=trace.conf


なお、採取したトレースを参照するためには以下のツールを利用してください。

Windows:(WebOTXインストールフォルダ)\TS\bin\trcview.exe
UNIX:/opt/WebOTX/TS/sbin/trcview


7.5. Working Domain Coordinator

Working Domain Coordinator に関する運用操作法について説明します。なお、各属性の説明については、[リファレンス集 運用管理・設定編 > 1.13. Working Domain Coordinator ]を参照してください。

7.5.1. Working Domain Coordinator の起動・停止

Working Domain Coordinator の起動、および停止処理の手順について説明します。

統合運用管理ツールから操作
あらかじめ、統合運用管理ツールより、Working Domain Coordinator の動作するドメインに接続しておきます。

  1. ツリービューより「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「ワーキングドメインコーディネータ」を選択し、右クリックします。
  2. 表示されるメニューから「Working Domain Coordinator の開始」を実行するとWorking Domain Coordinator を開始します。
    Working Domain Coordinator の開始を行うと、負荷分散制御機能が開始されます。また、制御対象サーバのデフォルトドメイン名が設定されており、かつ、他に起動しているドメインがない場合は、設定したデフォルトドメインが起動されます。
  3. 「Working Domain Coordinator の停止」を実行するとWorking Domain Coordinator を停止します。
    Working Domain Coordinator の停止を行うと、負荷分散制御機能が停止されます。起動しているドメインの停止は行われません。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、Working Domain Coordinator の動作するドメインにログインしておきます。

  1. Working Domain Coordinator を開始する場合は次のコマンドを実行します。
    otxadmin> start-working-domain-coordinator

    コマンドの詳細については、運用管理コマンドリファレンスの「start-working-domain-coordinator」を参照してください。


  2. 逆にWorking Domain Coordinator を停止する場合は次のコマンドを実行します。
    otxadmin> stop-working-domain-coordinator

    コマンドの詳細については、運用管理コマンドリファレンスの「stop-working-domain-coordinator」を参照してください。

7.5.2. ビジネスロジックグループの登録・削除

ビジネスロジックグループは、各ドメイン内で稼動し、監視の対象となるビジネスロジック(プロセスグループ)の論理的な集まりです。Working Domain Coordinatorはこのビジネスロジックグループを単位に負荷の監視、およびビジネスロジックの切り替えを行います。
ビジネスロジックグループの登録、および、削除の手順について説明します。

統合運用管理ツールから操作
あらかじめ、統合運用管理ツールより、Working Domain Coordinator の動作するドメインに接続しておきます。

  1. ツリービューより「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「ワーキングドメインコーディネータ」-「ビジネスロジックグループ」を選択し、右クリックします。
  2. 登録を行う場合は、「ビジネスロジックグループの登録」を選び、表示された画面で、ビジネスロジックグループの名前、および必要な情報を設定してください。設定内容の詳細は、 [ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.13. Working Domain Coordinator ] を参照してください。
  3. 削除を行う場合は、ツリービューに表示されている削除対象のビジネスロジックグループを右クリックします。表示された右クリックメニューの「ビジネスロジックグループの削除」を選択してください。また、ツリービューに表示されている「ビジネスロジックグループ」の右クリックメニューの「ビジネスロジックグループの削除」を選び、表示された画面でビジネスロジックグループ名を指定し削除することもできます。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、Working Domain Coordinator の動作するドメインにログインしておきます。

  1. ビジネスロジックグループの登録、または、ビジネスロジックグループの削除コマンドを実行します。

    ビジネスロジックグループの登録

    otxadmin> create-wdc-controlled-business-logic-group --maxQueuingRequests キュー滞留数上限値 ビジネスロジックグループ名

    コマンドの詳細については、運用管理コマンドリファレンスの「create-wdc-controlled-business-logic-group」を参照してください。

    ビジネスロジックグループの削除

    otxadmin> delete-wdc-controlled-business-logic-group ビジネスロジックグループ名

    コマンドの詳細については、運用管理コマンドリファレンスの「delete-wdc-controlled-business-logic-group」を参照してください。

7.5.3. ビジネスロジックの登録・削除

ビジネスロジックは、業務が動作するプロセスグループが該当します。
ビジネスロジックの登録、および削除の手順について説明します。

統合運用管理ツールから操作
あらかじめ、統合運用管理ツールより、Working Domain Coordinator の動作するドメインに接続しておきます。

  1. ツリービューより「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「ワーキングドメインコーディネータ」-「ビジネスロジックグループ」-「<ビジネスロジックグループ名>」-「ビジネスロジック」を選択し、右クリックします。
  2. 登録を行う場合は、「ビジネスロジックの登録」を選び、表示された画面で、対象のビジネスロジックの配備されているプロセスグループ名を設定してください。
  3. 削除を行う場合は、ツリービューに表示されている削除対象のビジネスロジックを右クリックします。表示された右クリックメニューの「ビジネスロジックの削除」を選択してください。また、ツリービューに表示されている「ビジネスロジック」の右クリックメニューの「ビジネスロジックの削除」を選び、表示された画面でビジネスロジック名を指定し削除することもできます。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、Working Domain Coordinator の動作するドメインにログインしておきます。

  1. ビジネスロジックの登録、または、ビジネスロジックの削除コマンドを実行します。

    ビジネスロジックの登録

    otxadmin> create-wdc-controlled-business-logic --businessLogicGroupName ビジネスロジックグループ名 ビジネスロジック名

    コマンドの詳細については、運用管理コマンドリファレンスの「create-wdc-controlled-business-logic」を参照してください。

    ビジネスロジックの削除

    otxadmin> delete-wdc-controlled-business-logic --businessLogicGroupName ビジネスロジックグループ名 ビジネスロジック名

    コマンドの詳細については、運用管理コマンドリファレンスの「delete-wdc-controlled-business-logic」を参照してください。

7.5.4. ロードバランサの登録・削除

ロードバランサは、業務の負荷を分散する負荷分散装置を表します。
ロードバランサの登録、および削除の手順について説明します。

統合運用管理ツールから操作
あらかじめ、統合運用管理ツールより、Working Domain Coordinator の動作するドメインに接続しておきます。

  1. ツリービューより「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「ワーキングドメインコーディネータ」-「ロードバランサ」を選択し、右クリックします。
  2. 登録を行う場合は、「ロードバランサの登録」を選び、表示された画面で、ロードバランサの名前、および必要な情報を設定してください。設定内容の詳細は、 [ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.13. Working Domain Coordinator ] を参照してください。
  3. 削除を行う場合は、ツリービューに表示されている削除対象のロードバランサを右クリックします。表示された右クリックメニューの「ロードバランサの削除」を選択してください。また、ツリービューに表示されている「ロードバランサ」の右クリックメニューの「ロードバランサの削除」を選び、表示された画面でロードバランサ名を指定し削除することもできます。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、Working Domain Coordinator の動作するドメインにログインしておきます。

  1. ロードバランサの登録、または、ロードバランサの削除コマンドを実行します。

    ロードバランサの登録

    otxadmin> create-wdc-loadbalancer --lbHostName ロードバランサのホスト名 ロードバランサ名

    コマンドの詳細については、運用管理コマンドリファレンスの「create-wdc-loadbalancer」を参照してください。

    ロードバランサの削除

    otxadmin> delete-wdc-loadbalancer ロードバランサ名

    コマンドの詳細については、運用管理コマンドリファレンスの「delete-wdc-loadbalancer」を参照してください。

7.5.5. 制御対象サーバの登録・削除

制御対象サーバは、WebOTX ASが稼動しているサーバのうち、Working Domain Coordinatorの負荷分散制御の対象となるサーバを表します。
制御対象サーバの登録、および削除の手順について説明します。

統合運用管理ツールから操作
あらかじめ、統合運用管理ツールより、Working Domain Coordinator の動作するドメインに接続しておきます。

  1. ツリービューより「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「ワーキングドメインコーディネータ」-「制御対象サーバ」を選択し、右クリックします。
  2. 登録を行う場合は、「制御対象サーバの登録」を選び、表示された画面で、制御対象サーバの名前、および必要な情報を設定してください。設定内容の詳細は、 [ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.13. Working Domain Coordinator ] を参照してください。
  3. 削除を行う場合は、ツリービューに表示されている削除対象の制御対象サーバを右クリックします。表示された右クリックメニューの「制御対象サーバの削除」を選択してください。また、ツリービューに表示されている「制御対象サーバ」の右クリックメニューの「制御対象サーバの削除」を選び、表示された画面で制御対象サーバ名を指定し削除することもできます。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、Working Domain Coordinator の動作するドメインにログインしておきます。

  1. 制御対象サーバの登録、または、制御対象サーバの削除コマンドを実行します。

    制御対象サーバの登録

    otxadmin> create-wdc-controlled-server --jmxAdminRemoteURL 管理ドメインのJMX Remote URL 制御対象サーバ名

    コマンドの詳細については、運用管理コマンドリファレンスの「create-wdc-controlled-server」を参照してください。

    制御対象サーバの削除

    otxadmin> delete-wdc-controlled-server 制御対象サーバ名

    コマンドの詳細については、運用管理コマンドリファレンスの「delete-wdc-controlled-server」を参照してください。

7.5.6. 制御対象ドメインの登録・削除

制御対象ドメインは、WebOTX ASが稼動しているサーバのドメインのうち、Working Domain Coordinatorの負荷分散制御の対象となるドメインを表します。
制御対象ドメインの登録、および削除の手順について説明します。

統合運用管理ツールから操作
あらかじめ、統合運用管理ツールより、Working Domain Coordinator の動作するドメインに接続しておきます。

  1. ツリービューより「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「ワーキングドメインコーディネータ」-「制御対象サーバ」-「<制御対象サーバ名>」-「制御対象ドメイン」を選択し、右クリックします。
  2. 登録を行う場合は、「制御対象ドメインの登録」を選び、表示された画面で、制御対象ドメインの名前、および必要な情報を設定してください。設定内容の詳細は、 [ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.13. Working Domain Coordinator ] を参照してください。
  3. 削除を行う場合は、ツリービューに表示されている削除対象の制御対象ドメインを右クリックします。表示された右クリックメニューの「制御対象ドメインの削除」を選択してください。また、ツリービューに表示されている「制御対象ドメイン」の右クリックメニューの「制御対象ドメインの削除」を選び、表示された画面で制御対象ドメイン名を指定し削除することもできます。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、Working Domain Coordinator の動作するドメインにログインしておきます。

  1. 制御対象ドメインの登録、または、制御対象ドメインの削除コマンドを実行します。

    制御対象ドメインの登録

    otxadmin> create-wdc-controlled-domain --controlledServerName 制御対象サーバ名 --jmxRemoteURL 制御対象ドメインのJMX Remote URL --businessLogicGroupName ビジネスロジックグループ名 制御対象ドメイン名

    コマンドの詳細については、運用管理コマンドリファレンスの「create-wdc-controlled-domain」を参照してください。

    制御対象ドメインの削除

    otxadmin> delete-wdc-controlled-domain --controlledServerName 制御対象サーバ名 制御対象ドメイン名

    コマンドの詳細については、運用管理コマンドリファレンスの「delete-wdc-controlled-domain」を参照してください。

7.5.7. 制御対象ドメインのインポート・エクスポート

多数の制御対象ドメインを登録する必要がある場合、登録済みの制御対象ドメインの設定内容を引用して登録を行うことができます。なお、この操作は統合運用管理ツールからのみ行うことができます。
制御対象ドメインのインポート・エクスポートを行う際の手順について説明します。

統合運用管理ツールから制御対象ドメインのインポート操作
あらかじめ、統合運用管理ツールより、Working Domain Coordinator の動作するドメインに接続しておきます。

  1. ツリービューより「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「ワーキングドメインコーディネータ」-「制御対象サーバ」-「<制御対象サーバ名>」-「制御対象ドメイン」を右クリックし、「制御対象ドメインのインポート」を選んでください。
  2. 表示された画面で、インポートする制御対象サーバと制御対象ドメインを設定してください。表示された画面に、選択した制御対象ドメインの設定が表示されます。
  3. 表示された画面の制御対象ドメインの名前および必要な情報を、実際のドメインの定義内容に合わせて編集してください。ビジネスロジックグループ名、ロードバランサ名、振り分け先のグループ名などを設定します。

統合運用管理ツールから制御対象ドメインのエクスポート操作
あらかじめ、統合運用管理ツールより、Working Domain Coordinator の動作するドメインに接続しておきます。

  1. ツリービューより「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「ワーキングドメインコーディネータ」-「制御対象サーバ」-「<制御対象サーバ名>」-「制御対象ドメイン」-「<エクスポートする制御対象ドメイン名>」を右クリックし、「制御対象ドメインのエクスポート」を選んでください。選択された制御対象ドメインの設定内容を引用した画面が表示されます。
  2. 表示された画面の「エクスポート先の制御対象サーバ名」と「生成する制御対象ドメイン名」を設定してください。また、それ以外の必要な情報を、実際のドメインの定義内容に合わせて編集してください。

7.5.8. 制御対象サーバのメンテナンス

制御対象サーバに定期的なサーバメンテナンスを行う必要がある場合、制御対象からの除外の設定を行うことで、そのサーバのみを負荷分散制御の対象から一時的に除外することができます。制御対象から除外されたサーバには、負荷の監視、および高負荷検出時の切り替え処理は行われません。
制御対象サーバのメンテナンスを行う際の手順について説明します。

統合運用管理ツールから操作
あらかじめ、統合運用管理ツールより、Working Domain Coordinator の動作するドメインに接続しておきます。

  1. ツリービューより「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「ワーキングドメインコーディネータ」-「制御対象サーバ」-「<メンテナンスを行う制御対象サーバ名>」を右クリックし、「制御対象から除外」を選んでください。
  2. 制御対象サーバのメンテナンスを行います。
  3. メンテナンス終了後、制御対象サーバを制御対象に復帰する場合は、ツリービューより「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「ワーキングドメインコーディネータ」-「制御対象サーバ」-「<メンテナンスを行った制御対象サーバ名>」を右クリックし、「制御対象に復帰」を選んでください。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、Working Domain Coordinator の動作するドメインにログインしておきます。

  1. 次のコマンドを発行し、メンテナンスを行う制御対象サーバを制御対象から除外します。

    制御対象サーバを制御対象から除外

    otxadmin> suspend-wdc-controlled-server メンテナンスを行う制御対象サーバ名

    コマンドの詳細については、運用管理コマンドリファレンスの「suspend-wdc-controlled-server」を参照してください。


  2. 制御対象サーバのメンテナンスを行います。


  3. メンテナンス終了後、次のコマンドを発行し、メンテナンスを行った制御対象サーバを制御対象に復帰します。

    制御対象サーバを制御対象に復帰

    otxadmin> resume-wdc-controlled-server メンテナンスを行った制御対象サーバ名

    コマンドの詳細については、運用管理コマンドリファレンスの「resume-wdc-controlled-server」を参照してください。

7.5.9. 負荷分散制御装置(LB)の制御

Working Domain Coordinatorには、LBの振り分け先の制御モードが3つあります。このLB制御モードが「LB制御依頼」に設定されている場合、LBの振り分け先の制御を運用担当者が行う必要があります。
LB制御モードが「LB制御依頼」に設定されている場合の切り替え処理の動作シーケンス、およびそれに伴う運用操作について説明します。

  1. Working Domain Coordinatorが高負荷時のサンプリング監視で継続的な高負荷状態を検出すると、余裕のある制御対象サーバを選択します。


  2. メッセージIDがOTX22040012のメッセージがイベントログ(UNIXではsyslog)に出力されます。


  3. 運用担当者は、2.で出力されたイベントログ(UNIX ではsyslog)のメッセージに記載されている制御対象ドメインをLB の振り分け先から削除します。制御対象ドメインのLB の振り分け先からの削除は、統合運用管理ツールのツリービューより該当サーバもしくはドメインを右クリック、「負荷分散装置から削除」を選択することでも可能です。


  4. 運用担当者は、統合運用管理ツールのツリービューより「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「ワーキングドメインコーディネータ」-「制御対象サーバ」-「<制御対象サーバ名>」-「制御対象ドメイン」-「<停止する制御対象ドメイン名>」を右クリックし、「ドメイン停止処理の再開」を選びます。


  5. Working Domain Coordinatorは、制御対象ドメインの停止を行います。


  6. Working Domain Coordinatorは、高負荷なビジネスロジックの配備された制御対象ドメインを起動します。制御対象ドメインが起動すると、メッセージIDがOTX22040011のメッセージをイベントログ(UNIXではsyslog)に出力します。


  7. 運用担当者は、6.で出力されたイベントログ(UNIX ではsyslog)のメッセージに記載されている制御対象ドメインをLB の振り分け先に追加します。制御対象ドメインのLB の振り分け先への追加は、統合運用管理ツールのツリービューより該当サーバもしくはドメインを右クリック、「負荷分散装置への登録」を選択することでも可能です。

7.6. WebOTX Webサーバ

7.6.1. はじめに

WebOTX Application Serverでは、Webサーバ層の提供機能として、 Javaベースの内蔵Webサーバと、Apache HTTP ServerベースのWebOTX Webサーバをバンドルしています。

本書では Apache HTTP Serverベースの WebOTX Webサーバを運用するための 運用操作法についての概要や具体的な設定項目や設定方法について記載しています。

7.6.2. 機能

ここでは、WebOTX Webサーバが提供する機能について説明します。

7.6.2.1. 機能概要

WebOTX Webサーバは、WebOTX Application Server の Webサーバ層の機能を 提供しており、Webサーバのデファクトスタンダードである Apache HTTP Server の 次のバージョンをバンドルしています。(2013年5月現在)

WebOTX Webサーバでは、Apache HTTP Server で提供される すべての機能に加え、次の機能を提供します。

なお、WebOTX Application Server では、ApacheベースのWebOTX Webサーバの 他に、Java ベースの Webサーバを内蔵しており、そちらも利用可能です。
さらに、Internet Information Service(IIS) 、LinuxマシンなどのOSに添付 されている Apache HTTP Server 2.2.24 以降、?Oracle iPlanet Web Server(旧 Sun Java System Web Server) 6.1、7.0との連携動作をサポート しています。

7.6.2.2. 基本機能

WebOTX Webサーバは、Apache HTTP Server が提供する Webサーバ動作に 関する基本機能をすべて提供します。

主に次の機能があります。

7.6.2.3. SSL 通信機能

SSSL (Secure Sockets Layer) は、公開鍵暗号方式を利用して データの暗号化を行い、公開鍵と秘密鍵と呼ばれるキーの対を利用して、 情報の暗号化と復号を行います。公開鍵は、特定のアルゴリズムを使用して データを暗号化するためのものであり、他社に配布可能です。 秘密鍵は、一般には配布せず、サーバ上に安全が保たれた状態で保管する 必要があります。
SSL を使用してサイトにクライアントが接続すると、 サーバは証明書の一部として公開キーとそれに付随する情報を送信し、 クライアントが公開鍵暗号方式を利用してサーバの身元を確認します。

証明書は、認証局 (CA : Certificate Authority)によって発行された 電子的はドキュメントであり、インターネット上で個人または企業の 身元を保証するものであり、証明書にはサイトの公開鍵が含まれている ため、クライアントはそれを利用して、サーバから送られてきたデータ を復号できます。

WebOTX Webサーバでは、OpenSSLライブラリを利用した mod_sslモジュールを使用して、SSL2.0/3.0 および TLS1.0 を利用して、 かつ128Bit以上の暗号化方式をサポートしたセキュアなWebサイト を構築することができます。
また、SSLクライアント認証機能も利用可能です。
クライアントがSSLを利用したセキュアなサイトにアクセスするには、 次の形式のURLを指定します。

https://ホストアドレス[:ポート]/ホスト内資源アドレス

HTTPS接続の場合、ポートは通常443が利用されます。ポート番号に 443を利用する場合は省略が可能です。

7.6.2.4. LDAP 連携機能

LDAP (Lightweight Directory Access Protocol)サーバと連携して、 HTTP認証をLDAPエントリデータに登録されたユーザで行うことができます。

なお、WebOTX Application Server では、LDAPサーバとして EnterpriseDirectoryServer(EDS)をバンドルしており、 EDSに登録したユーザを利用してHTTP認証を行うことができます。

7.6.2.5. IPv6 ネットワークのサポート

IPv6 ネットワーク環境での動作をサポートします。
IPv6/IPv4ネットワーク混在環境において、それぞれ別々のIPアドレス、ポートに対して待ち合わせが可能です。

待ち合わせ用のポート番号は、IPv6/IPv4で同一にすることもできますし、別々に設定することもできます。

7.6.2.6. 提供モジュール一覧

WebOTX Webサーバは、Apache HTTP Serverで提供される次のモジュール を提供しています。
デフォルトで組み込まれていないモジュールが提供する機能を利用する 場合には、 LoadModule 指示子により、モジュールのロードを行う 必要があります。

 

Apache 2.2
表7.6.2.6-1
モジュール 機能概要
(コアモジュール) (デフォルトで組み込まれている機能。ロードする必要はありません)

core, http_core

サーバのコア機能を提供します。

worker

(UNIX)UNIX版のMPMモジュールはworkerとしています。Workerは、複数のスレッドを有するプロセスが複数個動作するモードです。クライアントから要求は、各スレッド上で受け付けを行い、処理を行います。

mpm_winnt

(Windows)Windows向けに最適化されたマルチプロセッシングモジュールです。複数のスレッドを有するプロセスが動作するモードです。クライアントから要求は、各スレッド上で受け付けを行い、処理を行います。

mod_so

起動時や再起動時に実行コードとモジュールをサーバにロードします。

(オプションモジュール)

デフォルトで組み込まれていません。利用するにはLoadModule指示子により別途ロードする必要があります。
右欄は、W(Windows)、U(Unix: HP-UX/Solaris/Linux)を意味し、 各OSで提供しているモジュールに○をつけています。
W U

mod_actions

メディアタイプやリクエストメソッドに応じてCGIスクリプトを実行する機能を提供します。

mod_alias

ホストファイルシステム上のいろいろな違う場所をドキュメントツリーにマップする機能と、URLのリダイレクトを行う機能を提供します。

mod_asis

自分用のHTTPヘッダの書かれているファイルを送信します。

mod_auth_basic

Basic 認証機能を提供します。

mod_auth_digest

digest

mod_authn_alias

xxxxxx

mod_authn_anon

認証が必要な領域への "anonymouse"ユーザのアクセスを許可する。

mod_authn_dbd

SQL データベース

mod_authn_dbm

DBM ファイルを用いたユーザ認証機能を提供します。

mod_authnz_ldap

LDAPディレクトリに格納されたデータベースを利用してHTTP基本認証を許可します。

mod_authz_dbm

DBMファイルを用いたグループ認証

mod_authz_default

承認フォールバックモジュール

mod_authz_file

プレーンテキストファイルを用いたグループ承認

mod_authz_host

ホスト(名前もしくは IPアドレス)に基づいたグループ承認

mod_authz_owner

ファイルの所有者に基づいた承認

mod_authz_user

ユーザ承認

mod_autoindex

UnixのlsコマンドやWindowsのdirシェルコマンドに似たディレクトリインデックスを生成します。

mod_cache

URI をキーにしたコンテンツのキャッシュ

mod_cern_meta

CERN httpd が使う追加のHTTPヘッダ形式でメタ情報を指定できるようにします。

mod_cgi

CGI スクリプトを実行します。

mod_cgid

外部CGIデーモンを使用したCGI スクリプトを実行します。

mod_charset_lite

キャラクターセットの変換と記録を指定します。

mod_dav

分散オーサリングとバージョン管理(WebDAV)機能

mod_dav_fs

mod_dav のためのファイルシステムプロバイダ

mod_dav_lock

mod_dav 用の汎用ロックモジュール

mod_dbd

SQL データベースコネクションを管理する

mod_deflate

クライアントへ送られる前にコンテンツを圧縮します。

mod_dir

URLに指定される「最後のスラッシュ」のリダイレクトと、ディレクトリのインデックスファイルを扱う機能を提供します。

mod_disk_cache

URIをキーにしたコンテンツキャッシュストレージを管理します。

mod_dumpio

すべてのI/Oをエラーログにダンプします。

mod_env

CGIスクリプト及びSSIページに渡される環境変数を変更する機能を提供します。

mod_expires

ユーザの指定した基準に基づいたExpiresとCache-Control HTTPヘッダの生成をします。

mod_ext_filter

レスポンスのボディをクライアントに送る前に外部プログラムで処理します。

mod_file_cache

メモリ内にファイルの静的なリストをキャッシュします。

mod_filter

Context-sensitive smart filter configuration module

mod_headers

HTTPリクエストヘッダとレスポンスヘッダをカスタマイズします。

mod_ident

RFC 1413 ident lookups

mod_imagemap

サーバサイドのイメージマップを実行します。

mod_include

サーバがパースするhtmlドキュメント(Server Side Includes)

mod_info

サーバの設定の包括的な概観を提供します。

mod_ldap

LDAP連携用モジュール。

mod_log_config

サーバへのリクエストのロギングを行います。

mod_log_forensic

サーバに送られたリクエストをforensicロギングします。

mod_logio

リクエスト毎に入力バイト数と出力バイト数をロギングします。

mod_mem_cache

URIをキーにしたコンテンツキャッシュします。

mod_mime

リクエストされたファイルの拡張子とファイルの振る舞い(ハンドラとフィルタ)、内容(MIMEタイプ、言語、文字セット、エンコーディング)とを関連付けます。

mod_mime_magic

ファイルの内容を読み込んでMIMEタイプを決定します。

mod_negotiation

コンテントネゴシエーション機能を提供します。

mod_proxy

HTTP/1.1プロキシ/ゲートウェイサーバを提供します。

mod_proxy_ajp

mod_proxyで AJP をサポートするモジュール。

mod_proxy_balancer

負荷分散のための mod_proxy拡張モジュール。

mod_proxy_connect

CONNECT リクエストを扱う mod_proxy 拡張モジュール。

mod_proxy_ftp

mod_proxyでFTPをサポートするモジュール。

mod_proxy_http

mod_proxyでHTTPをサポートするモジュール。

mod_rewrite

URLの書き換えを行うリライトエンジンを提供します。

mod_setenvif

リクエストの特徴に基づいた環境変数の設定を可能にします。

mod_speling

ユーザが入力したであろう間違ったURLを、大文字小文字の区別を無視することと一つ以下の綴り間違いを許容することで修正を試みます。

mod_ssl   

SSL通信用のモジュール。

mod_status

サーバの活動状況と性能に関する情報を提供します。

mod_substitute

Perform seach and replace operations on response bodies

mod_unique_id

それぞれのリクエストに対する一意な識別子の入った環境変数を提供します。

mod_userdir

ユーザ専用のディレクトリを提供します。

mod_usertrack

Cookieによりユーザの追跡を行います。

mod_version

バージョン依存の設定をします。

mod_vhost_alias

バーチャルホストに関する動的な設定を提供します。

mod_jk-22

Webコンテナと接続を行うコネクタモジュール。 WebOTX AS Express 利用時や、WebOTX AS Standard/Enterprise の「Webコンテナの動作モード」設定で「スタンダードモード」を選択した 場合に利用されます。

mod_jk_om-22

(WebOTX 独自) マルチプロセス対応のWebコンテナと連携を行うためのコネクタモジュール。 WebOTX AS Standard/Enterprise の「Webコンテナの動作モード」 設定で「アドバンスドモード」を選択した場合に利用されます。

7.6.2.7. その他の機能

その他の機能の詳細は、以下の Apache HTTP Server の Webサイトを参照してください。

または、WebOTX をインストールしたマシン上で、ブラウザから 次のURL にアクセスし、Apache HTTP Server のドキュメントを参照 してください。

7.6.3. 定義情報

WebOTX Webサーバの定義情報は、定義情報ファイル(httpd.conf)に格納され、WebOTX Webサーバ起動時に読み込まれます。
定義情報を更新した場合には、WebOTX Webサーバの再起動が必要になります。

定義情報の詳細は[ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.3. HTTPサーバ > 1.3.2. WebOTX Webサーバ設定方法]を参照してください。

7.6.4. 運用

ここでは、WebOTX Webサーバの運用・操作方法について説明します。
また、特定機能を利用する場合の設定方法についても説明します。

7.6.4.1. 起動・停止

WebOTX Webサーバの起動・停止は、WebOTX Application Server のドメインの起動・停止に 連動して動作します。
WebOTX のドメインの起動・停止処理は、OS のサービスプログラムとして 動作しますので、通常、Webサーバの起動・停止だけを意識する必要はありませんが、 WebOTX Webサーバの定義情報を変更するような場合に有効です。

WebOTX のドメインが起動している状態で、WebOTX Webサーバを単独で起動・停止を行う 場合は、統合運用管理ツールから操作するか、次のコマンドを実行してください。

統合運用管理ツールからの操作

あらかじめ、統合運用管理ツールよりドメインに接続しておきます。

起動・停止方法

  1. 「WebOTX 管理ドメイン[<サーバ名>]」− 「<ドメイン名>」−「アプリケーションサーバ」−「WebServer」 を選択し、マウスを右クリックして操作メニューを表示します。 あるいは、メニューバーの[操作]を選択します。


    図7.6.4.1-1


  2. 表示されるメニューから「Webサーバの開始」を選択すると、 WebOTX Webサーバが起動します。
    また、「Webサーバの停止」を選択すると、WebOTX Webサーバが停止します。

運用管理コマンド(otxadmin)からの操作

あらかじめ、運用管理コマンドで、ドメインにログインしておきます。
otxadmin>login --user admin --passwprd adminadmin --port 6212

起動・停止方法
  1. WebOTX Webサーバを起動する場合、次のコマンドを実行します。

    otxadmin>invoke server.WebServer.start
    
  2. WebOTX Webサーバを停止する場合、次のコマンドを実行します。

    otxadmin>invoke server.WebServer.stop
    

7.6.4.2. 定義情報の参照

WebOTX Webサーバの定義情報のうち、動作に必要となる一部の必須情報を WebOTX の統合運用管理ツール および 運用管理コマンドから参照すること ができます。

統合運用管理ツールからの操作

あらかじめ、統合運用管理ツールよりドメインに接続しておきます。

定義情報の参照

  1. 「WebOTX 管理ドメイン[<サーバ名>]」− 「<ドメイン名>」−「アプリケーションサーバ」−「WebServer」 を選択し、Webサーバの各定義情報を表示します。


    図7.6.4.2-1


  2. 「定義情報」、「定義情報(SSL)」、「アクセスログ」の各タブ情報を 選択することで、各項目の情報を参照できます。

運用管理コマンド(otxadmin)からの操作

あらかじめ、運用管理コマンドで、ドメインにログインしておきます。
otxadmin>login --user admin --passwprd adminadmin --port 6212

定義情報の参照
  1. WebOTX Webサーバの定義情報を取得するには、次のコマンドを実行します。
    運用管理コマンド(またはツール)から参照可能な定義情報の一覧については、 次の表を参照してください。

    otxadmin>get server.WebServer.*
    

WebOTX 運用管理コマンド(ツール)から参照できる定義情報一覧

表7.6.4.2-1
統合運用管理ツールでの属性名 Server.WebServer.* 説明
ポート番号 Port Listen 指示子の設定値を取得します。
WebOTX Webサーバが待ち合わせを行うポート番号を表します。
バージョン情報 Version Webサーバのバージョン情報を表示します。
なお、この情報は httpd.conf には定義されていません。
ServerName ServerName ServerName 指示子の設定値を取得します。
DocumentRoot DocuumentRoot DocumentRoot 指示子の設定値を取得します。
ブラウザから見えるメインのドキュメントツリーになるディレクトリを 表します。
ErrorLog ErrorLog ErrorLog 指示子の設定値を取得します。
Webサーバのエラーログの出力先を表します。
LogLevel LogLevel LogLevel 指示子の設定値を取得します。
Webサーバのエラーログの出力レベルを表します。
最大同時接続数 MaxClients UNIX版の MaxClients 指示子、あるいは Windows版の ThreadsPerChild 指示子の設定値を取得します。
クライアント(ブラウザ)から接続できる最大同時接続数を表します。
SSL(HTTPS)通信の使用の有無 security-enabled SSL(HTTPS)通信を利用するかどうかの情報です。
チェックされている(コマンドで true が返却された)場合、 SSL(HTTPS) 通信が利用可能です。チェックされていない (コマンドで false が返却された)場合、SSL(HTTPS)通信は 利用できません。
この情報は、httpd.conf に定義されていません。
HTTPS 通信用ポート番号 ssl-port SSL用の定義情報ファイルである ssl.conf に定義されている Listen 指示子の設定値を取得します。
HTTPS通信で利用するポート番号を表します。
アクセスログ出力先と出力フォーマット AccessLog CustomLog 指示子の設定値を取得します。
アクセスログの出力先と、出力するフォーマット(LogFormat)情報の ニックネーム値を表します。
「リクエスト処理時間(秒)」情報の出力 AccesslogTat アクセスログに「リクエスト処理時間」の情報が出力されるように 設定されている(LogFormat 指示子に「%T」が設定されている) かどうかの情報を取得します。
チェックされている(コマンドで true が返却された)場合、アクセスログに リクエスト処理時間(秒単位)が出力されます。 チェックされていない(コマンドで false が返却された)場合、 アクセスログにリクエスト処理時間の情報は出力されません。
アクセスログのローテーション Rotatelog アクセスログがローテーション出力されるように設定されている (CustomLog 指示子にローテーション出力が設定されている) かどうかの情報を取得します。
チェックされている(コマンドで true が返却された)場合、アクセス ログはローテーション出力を行います。チェックされていない(コマンド で false が返却された)場合、アクセスログはローテーション 出力されません。
ローテーション間隔 RotationTime 上記「アクセスログのローテーション」が設定されている場合、 そのローテーション時間(秒単位)の情報を取得します。
既定値は 864000 秒(=24 時間)です。

7.6.4.3. 定義情報の更新

通常、WebOTX Webサーバの定義情報を更新するには、httpd.conf ファイルを直接編集する必要がありますが、一部の定義情報は、 WebOTX の統合運用管理ツール および 運用管理コマンドを利用して 設定値を更新することができます。

統合運用管理ツールからの操作

あらかじめ、統合運用管理ツールよりドメインに接続しておきます。

定義情報の更新
  1. 「WebOTX 管理ドメイン[<サーバ名>]」− 「<ドメイン名>」−「アプリケーションサーバ」−「WebServer」 を選択し、Webサーバの各定義情報を表示します。


    図7.6.4.3-1


  2. 「定義情報」、「定義情報(SSL)」、「アクセスログ」の各タブ情報を 選択し、各項目の情報を更新します。
    例えば、ポート番号を 8080 に変更する場合には、現在定義されている ポート番号の項目を選択し、「編集」ボタンを押下して、出力されたダイアログ に 8080 を設定します。

  3. 「更新」ボタンを押下することで、定義情報ファイル(httpd.conf)に変更した 情報が反映されます。

  4. Webサーバの再起動 または WebOTX のドメインの再起動を行うことで、 変更した情報で Webサーバ が起動します。

運用管理コマンド(otxadmin)からの操作

あらかじめ、運用管理コマンドで、ドメインにログインしておきます。
otxadmin>login --user admin --passwprd adminadmin --port 6212

定義情報の更新
  1. WebOTX Webサーバの定義情報を取得するには、次のコマンドを実行します。
    運用管理コマンド(またはツール)から参照可能な定義情報の一覧については、 次の表を参照してください。

    otxadmin>set server.WebServer.*=xxx
    

    例えば、ポート番号を 8080 に変更する場合には、次のコマンドを 実行します。
    otxadmin>set server.WebServer.port=8080
    
  2. Webサーバ の再起動または WebOTX のドメインの再起動を行うことで、 更新された情報で Webサーバが起動します。

WebOTX 運用管理コマンド(ツール)から更新できる定義情報一覧

表7.6.4.3-1
統合運用管理ツールでの属性名 Server.WebServer.* 説明
ポート番号 Port Listen 指示子を設定します。
WebOTX Webサーバが待ち合わせを行うポート番号を設定します。
[IPアドレス:]ポート番号 の形式で設定可能です。 また、複数の設定も可能です。
ServerName ServerName ServerName 指示子を設定します。
DocumentRoot DocuumentRoot DocumentRoot 指示子を設定します。
ブラウザから見えるメインのドキュメントツリーになるディレクトリを 設定します。
ErrorLog ErrorLog ErrorLog 指示子を設定します。
Webサーバのエラーログの出力先を設定します。
LogLevel LogLevel LogLevel 指示子を設定します。
Webサーバのエラーログの出力レベルを設定します。
最大同時接続数 MaxClients UNIX版の MaxClients 指示子、あるいは Windows版の ThreadsPerChild 指示子を設定します。
クライアント(ブラウザ)から接続できる最大同時接続数を設定します。
SSL(HTTPS)通信の使用の有無 security-enabled SSL(HTTPS)通信を利用するかどうかを設定します。
SSL(HTTPS)通信を利用する場合は、チェックを行い(コマンド では true を設定し)、SSL(HTTPS) 通信を利用しない場合は、 チェックを外します(コマンドでは false を設定します)。
HTTPS 通信用ポート番号 ssl-port SSL用の定義情報ファイルである ssl.conf に Listen 指示子を設定します。
HTTPS通信で利用するポート番号を設定します。
アクセスログ出力先と出力フォーマット AccessLog CustomLog 指示子を設定します。
アクセスログの出力先と、出力するフォーマット(LogFormat)情報の ニックネーム値を設定します。
「リクエスト処理時間(秒)」情報の出力 AccesslogTat アクセスログに「リクエスト処理時間」の情報を 出力する(LogFormat 指示子に「%T」を設定する) かどうかを設定します。
アクセスログにリクエスト処理時間(秒単位)を出力する場合、 チェックを行い(コマンドでは true を設定し)、 アクセスログにリクエスト処理時間の情報を出力しない場合、 チェックを外します(コマンドでは false を設定します)。
アクセスログのローテーション Rotatelog アクセスログをローテーション出力させるかどうかを設定します。
ローテーション出力を行う場合は、チェックを行い(コマンドでは true を設定し)、ローテーション出力を行わない場合は、 チェックを外します(コマンドでは false を設定します)。
ローテーション間隔 RotationTime 上記「アクセスログのローテーション」が設定されている場合、 そのローテーション時間(秒単位)を設定します。
既定値は 864000 秒(=24 時間)です。

7.6.4.4. 定義情報の追加

通常、WebOTX Webサーバの定義情報を更新するには、httpd.conf ファイルを直接編集する必要がありますが、WebOTX の統合運用管理 ツール および 運用管理コマンドを利用して、httpd.confファイルに 現在設定されていない定義情報を追加することができます。

統合運用管理ツールからの操作

あらかじめ、統合運用管理ツールよりドメインに接続しておきます。

定義情報の追加
  1. 「WebOTX 管理ドメイン[<サーバ名>]」− 「<ドメイン名>」−「アプリケーションサーバ」−「WebServer」 を選択し、マウスを右クリックして操作メニューを表示します。 あるいは、メニューバーの[操作]を選択します。


    図7.6.4.4-1


  2. 表示されるメニューから「定義情報の追加」を選択すると、「定義情報の追加」 ダイアログが表示されます。


    図7.6.4.4-2

  3. 「追加する定義情報」に追加する定義情報を設定します。
    定義情報は、<指示子><設定値>の形式で指定する必要があります。
    なお<指示子>だけの定義を設定する場合は、<指示子>の後に半角スペース を設定してください。

  4. 「実行」ボタンを押下することで、設定した定義情報が、定義情報ファイルに 追加されます。

  5. Webサーバの再起動 または WebOTX のドメインの再起動を行うことで、 変更した情報で Webサーバ が起動します。

運用管理コマンド(otxadmin)からの操作

あらかじめ、運用管理コマンドで、ドメインにログインしておきます。
otxadmin>login --user admin --passwprd adminadmin --port 6212

定義情報の追加
  1. WebOTX Webサーバの定義情報に情報を追加するには、 次のコマンドを実行します。

    otxadmin>invoke server.WebServer.setDirective "directive value"
    

    追加する定義情報は<指示子> <設定値> の形式で、 ダブルコーテーションで囲む必要があります。

    例えば、ListenBackLog 512 という定義情報を追加する場合、次のように指定します。

    otxadmin>invoke server.WebServer.setDirective "ListenBackLog 512"
    

    また、Win32DisableAcceptEx のような <指示子> だけの定義を追加する 場合には、<指示子> の後に半角スペースを付けて、次のように指定します。
    otxadmin>invoke server.WebServer.setDorective "Win32DisableAcceptEx "
    
  2. Webサーバ の再起動または WebOTX のドメインの再起動を行うことで、 更新された情報で Webサーバが起動します。

本節で説明している定義情報の追加処理は、httpd.conf ファイル に対してのみ有効です。ssl.conf ファイルに対しては、ツールやコマンドから 定義情報の追加を行うことはできません。

7.6.4.5. SSL(HTTPS通信) 設定方法

WebOTX Webサーバは、OpenSSL ライブラリを利用した mod_ssl モジュールと 連携することで、SSL プロトコルを利用した HTTPS 通信を実現することができます。
ブラウザとWebサーバ間に HTTPS 通信を利用するには、次の設定が必要です。

7.6.4.5.1. SSL通信用ライブラリのインストール

HTTPS通信を利用するには、WebOTX Webサーバ用のSSL通信用ライブラリが インストールされている必要があります。

Windows版の場合、インストール時にWebOTX Webサーバをインストールする ことを選択することで、SSL通信用ライブラリも一緒にインストールされます。
SSL 通信用ライブラリがマシンにインストールされているかの確認は、 「アプリケーションの追加と削除」(または「プログラムの追加と削除」)から 「SSL通信用ライブラリ (Webサーバ Ver2.2)」がインストールされているかを確認してください。


図7.6.4.5-1

UNIX版の場合、インストール時にWebOTX Webサーバのインストールを 選択すると、SSL通信用ライブラリをインストールするかどうかが 選択できます。
SSL通信用ライブラリのインストールを選択していない場合には、 次のパッケージを別途インストールしてください。

表7.6.4.5-1
プラットフォーム バージョン パッケージ

Linux (x86)

2.2

/MODSSL/LINUX/modssl22-2.20.xx.xx-1.i386.rpm

Linux (x64)

2.2

/MODSSL/LINUX/modssl22-2.20.xx.xx-1.x86_64.rpm
7.6.4.5.2. SSL設定の有効化

SSL通信用ライブラリをインストール後、SSL通信機能を有効にするために、 WebOTX Application Server の設定変更を行う必要があります。
次の手順により、設定変更を行ってください。

統合運用管理ツールからの操作

あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

SSL通信の有効化

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」 -「アプリケーションサーバ」-「WebServer」を選択し、「定義情報(SSL)」(※) タブの「SSL(HTTPS通信)の使用の有無」をチェックします。


    図7.6.4.5-2


    (※)「定義情報(SSL)」タブが表示されない場合、「4.5.1 SSL通信ライブラリのインストール」により、対応するSSL通信ライブラリをインストールし、WebOTX を再起動してください。

  2. 「更新」ボタンを押下すると、SSL設定が有効になります。
    SSLで利用するポート番号を変更する場合、 「HTTPS通信用の定義情報ファイル」の項目で表示されるファイルを 編集してください。
    または「HTTPS通信用のポート番号」の項目を更新します。

  3. WebOTX Webサーバを再起動することにより、SSL設定が有効になります。

運用管理コマンド(otxadmin)からの操作

あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

otxadmin>login --user admin --password adminadmin --port 6212

SSL通信の有効化

  1. WebOTX WebサーバのSSL通信を有効化するには、以下のコマンドを実行します。

    otxadmin>set server.WebServer.security-enabled=true
    
  2. SSL通信用のポート番号を変更するには、以下のコマンドを実行します。
    例えば、8443に変更する場合、次のコマンドを実行します。

    otxadmin>set server.WebServer.ssl-port=8443
    
  3. WebOTX Webサーバを再起動します。

    otxadmin>invoke server.WebServer.stop
    
    otxadmin>invoke server.WebServer.start
    
7.6.4.5.3. HTTPS 通信の接続確認

WebOTX Webサーバでは、SSL通信用ライブラリをインストールすることで、 HTTPS接続評価用の証明書ファイルと秘密鍵ファイルが同時にインストールされます。
したがって、インストール直後でもローカルマシンのブラウザからHTTPSでの接続確認が 可能です。

  1. ブラウザから次のURLを指定します。 SSL接続用のポート番号を変更している場合には、 そのポート番号も指定してください。 別マシンから接続確認を行う場合には、WebOTXをインストールした ホスト名を指定してください。

    https://localhost/manual/

  2. 例えば、Apache2.2を利用している場合、次のような画面が表示されれば、 SSLで接続できたことが確認できます。
    また、ブラウザのステータスバーに HTTPS 接続中であることを意味する 「鍵」マークが表示されていることを確認してください。


    図7.6.4.5-3


  3. ブラウザに表示される「鍵」マークをクリックすることで、 WebOTX WebサーバのSSL通信機能で利用している 証明書情報を参照することができます。
    ただし、WebOTX WebサーバのSSL通信ライブラリが インストールする本証明書は、接続確認用の自己署名証明書であるため、 以下のように「信頼された証明機関がこの証明書を確認できません」 と表示されます。
    「OK」ボタンを押下して証明書のダイアログを終了させてください。


    図7.6.4.5-4


  4. なお、Internet Explorer 7(IE 7)を利用した場合、次の画面 (IE7でのHTTPS接続画面-?)が表示されます。
    これは、IE 7で証明書のチェックが厳しくなったために 出力される情報であり、SSLでの接続ができないという 訳ではありません。
    「このサイトの閲覧を続行する(推奨されません)。」を選択すると、 さらに次の画面(IE7でのHTTPS接続画面-?)が表示され、 アドレスバーに「証明書エラー」と表示されます。
    本件は、信頼された証明機関から発行された正しい証明書 を利用することで解決します。
    次節に示す手順により、正しい証明書を入手してください。

    IE7でのHTTPS接続画面-?


    図7.6.4.5-5

    IE7でのHTTPS接続画面-?


    図7.6.4.5-6

7.6.4.5.4. サーバ証明書の取得

次に示す手順は、 CA機関に対して証明書の発行を要求する手順の一例です。
この例では、 Linux 上で OpenSSLコマンドを利用して、秘密鍵の生成と証明書署名要求の生成を行い、 CA機関に送付して証明書を取得し、WebOTX Webサーバへ設定を行うまでの手順を記載します。
詳細については、各CA機関での証明書の取得方法(Apacheの場合)を参照してください。

Windowsで OpenSSLコマンドを利用する場合には、OpenSSLのWindows用の バイナリファイルを入手する必要があります。以下を参照してください。
   http://www.openssl.org/related/binaries.html

  1. 秘密鍵の生成

    /usr/local/openssl/private に 秘密鍵ファイル(server.key)を生成します。
    キー生成のために、ランダムな情報が含まれている file1〜file3 をあらかじめ用意しておいてください。

      >openssl genrsa -rand file1:file2:file3 1024 -out /usr/local/openssl/private/server.key
    

    生成された秘密鍵ファイルにアクセス権の設定を行います。
      >chmod 400 /usr/local/openssl/private/server.key
    
      >chmod 700 /usr/local/openssl/private
    
  2. 証明書署名要求の生成

    証明書著名要求 (CSR)ファイルを生成し、CA機関に送付します。

      >openssl req -new -key server.key -out server.csr
    
  3. 証明書ファイルの取得

    CA機関から返信された証明書ファイル(server.crt)を /use/local/openssl/certs に格納し、アクセス権を設定します。

      >chmod 400 /usr/local/openssl/certs/server.crt
    
      >chmod 700 /usr/local/openssl/certs
    
  4. 証明書と秘密鍵の設定

    証明書ファイルと秘密鍵ファイルを、 WebOTX Webサーバに設定します。
    /opt/WebOTX/domains/domain1/conf/WebServer/ssl.confSSLCertificateFile 指示子に入手した証明書ファイルを、 SSLCertificateKeyFile 指示子に秘密鍵ファイルを設定してください。

    SSLCertificateFile /usr/local/openssl/certs/server.crt
    SSLCertificateKeyFile /user/local/openssl/private/server.key
  5. パスフレーズの取得設定

    秘密鍵作成時にパスフレーズを設定している場合、証明書にアクセスするために パスフレーズの読み込み処理を設定しておく必要があります。
    SSLPassPhraseDialog 指示子を参照し、パスフレーズの設定を行ってください。 また、パスフレーズの読み込み処理を行うスクリプト(例えば、次のpass.sh のようなシェルスクリプト)等をあらかじめ用意しておく必要があります。
    なお、Windows の場合には、パスフレーズなしで秘密鍵を作成してください。

    <</usr/local/openssl/private/pass.sh(※)の内容>>

    #!/bin/sh
    echo "passphrease"
    exit 0

       (※)pass.sh はアクセス権を設定しておく必要があります。
      >chmod 500 /usr/local/private/pass.sh
    
  6. Webサーバの再起動

    設定した内容を反映するために、WebOTX Webサーバまたは WebOTX のドメインを 再起動します。

7.6.4.6. アクセスログファイルのローテーション

WebOTX Webサーバの出力するログファイルには、 クライアントからのアクセス状況を出力するaccess.logと、 Webサーバ本体側の動作に関連した情報を出力するerror.logがあります。

既定値の設定のままでWebOTX Webサーバを長時間動作させたままにすると、 access.log に出力されるログ情報が蓄積されてディスク領域を 大きく占有する場合があります。
これを解消するために、access.logファイルを一定時間で ローテーションさせることが可能です。
次の例では、access.logファイルを24時間(86400秒)でローテーション (1日毎にaccess.logファイルを作成)させる設定方法について記載します。

統合運用管理ツールからの操作

あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

アクセスログファイルのローテーション

  1. 「WebOTX管理ドメイン[<ホスト名>]」- 「<ドメイン名>」-「アプリケーションサーバ」- 「WebServer」を選択し、「アクセスログ」タブの 「アクセスログのローテーション」をチェックします。


    図7.6.4.6-1


  2. 「ローテーション間隔」にローテーション時間を設定します。

  3. 「更新」ボタンを押下することで、設定内容が定義情報ファイルに反映されます。

  4. Webサーバを再起動することにより、設定内容が反映されます。

運用管理コマンド(otxadmin)からの操作

あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

otxadmin>login --user admin --password adminadmin --port 6212

アクセスログファイルのローテーション

  1. WebOTX Webサーバのアクセスログのローテーション設定を有効にするには、 以下のコマンドを実行します。

    otxadmin>set server.WebServer.Rotatelog=true
    
  2. ローテーション時間は既定値で24時間(=86400秒)が設定されますが、 ローテーション時間を変更するには、以下のコマンドを実行します。
    例えば、1週間(=604800秒)でローテーションさせる場合は、 次のコマンドを実行します。

    otxadmin>set server.WebServer.RotationTime=604800
    
  3. 設定内容を反映するには、Webサーバの再起動が必要です。

上記の設定により、定義情報ファイルに次の設定が追加されます。
なお、統合運用管理ツール/運用管理コマンドからの操作ができない場合には、 定義情報ファイルを直接編集し、次の設定を行ってください。

(UNIX)

CustomLog "|/opt/WebOTX/WebServer22/bin/rotatelogs \
/opt/WebOTX/domains/domain1/logs/web/access_log 86400" common


(Windows)

CustomLog "||C:/WebOTX/WebServer22/bin/rotatelogs.exe\
C:/WebOTX/domains/domain1/logs/web/access.log 86400" common

上記の設定により、Webサーバの再起動を実施することで、次のログファイルが順次生成されます。

access_log.1089207300
access_log.1083293700
access_log.1083380100

作成されたファイルのうち、小さい数字のものは過去のログとなりますので、ファイルの移動/削除等が可能となります。

なお、SSL通信用の定義情報ファイル(ssl.conf)に定義されている ssl_request_logファイルに対してローテーション設定を行う場合には、直接ssl.confファイルを編集し、次の設定を行ってください。

(UNIX)

CustomLog "|/opt/WebOTX/WebServer22/bin/rotatelogs \
  /opt/WebOTX/domains/domain1/logs/web/ssl_request_log 86400" \
  "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"


(Windows)

CustomLog "||C:/WebOTX/WebServer22/bin/rotatelogs.exe \
  C:/WebOTX/domains/domain1/logs/web/ssl_request_log 86400" \
  "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

 

7.6.4.7. リクエスト処理時間のログ出力

アクセスログに リクエスト処理時間の情報を出力することで、 Webサーバがそのリクエストを受け付けて、レスポンスを返却するまでの 時間を出力することができます。
この情報は、例えば、どのリクエスト(コンテンツ)に対する処理に時間が かかっているかを調査するような場合に役立つことがあります。

ここでは、access.logファイルにリクエスト処理時間を出力する設定方法 について記載します。

統合運用管理ツールからの操作

あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

リクエスト処理時間の情報出力

  1. 「WebOTX管理ドメイン[<ホスト名>]」- 「<ドメイン名>」-「アプリケーションサーバ」-「WebServer」を選択し、 「アクセスログ」タブの「リクエスト処理時間(秒)情報の出力」 をチェックします。


    図7.6.4.7-1


  2. 「更新」ボタンを押下することで、設定内容が定義情報ファイルに 反映されます。

  3. Webサーバを再起動することにより、設定内容が反映されます。

運用管理コマンド(otxadmin)からの操作

あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

otxadmin>login --user admin --password adminadmin --port 6212

リクエスト処理時間の情報出力

  1. WebOTX Webサーバのアクセスログにリクエスト処理時間 の情報を出力するには、以下のコマンドを実行します。

    otxadmin>set server.WebServer.AccesslogTat=true
    
  2. 設定内容を反映するには、Webサーバの再起動が必要です。

上記の設定により、定義情報ファイルに次の設定が追加されます。
なお、統合運用管理ツール/運用管理コマンドからの操作ができない場合には、 定義情報ファイルを直接編集し、LogFormat 指示子に%T を追加してください。

LogFormat "%h %l %u %t \”%r\”%>s %b %T" common

この設定により、アクセスログには次のログ情報が出力されます。最後の項目がリクエスト処理時間(秒)となります。
なお、1秒未満でリクエスト処理が完了した場合には、0が表示されます。

(アクセスログの出力内容例)


図7.6.4.7-2

7.6.4.8. 最大同時接続数の変更

多数のブラウザから接続要求が同時に行われた場合 (最大同時接続数を超えた場合)、次のメッセージがerror.logに出力されます。

(UNUX)
  [error] server reached MaxClients setting, consider raising the MaxClients setting

(Windows)
  [warn] Server ran out of threads to serve requests. Consider raising the ThreadsPerChild setting

最大同時接続数を増やすには、定義情報の次の設定を変更する必要があります。

統合運用管理ツールからの操作

あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

最大同時接続数の変更

  1. 「WebOTX管理ドメイン[<ホスト名>]」- 「<ドメイン名>」-「アプリケーションサーバ」-「WebServer」を選択し、 「定義情報」タブの「最大同時接続数」の値を変更します。


    図7.6.4.8-1


  2. 「更新」ボタンを押下することで、設定内容が定義情報ファイルに 反映されます。

  3. Webサーバを再起動することで、設定内容が反映されます。

運用管理コマンド(otxadmin)からの操作

あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

otxadmin>login --user admin --password adminadmin --port 6212

最大同時接続数の変更

  1. WebOTX Webサーバの最大同時接続数を変更するには、 以下のコマンドを実行します。

    otxadmin>set server.WebServer.MaxClients=250
    
  2. Webサーバを再起動することで、設定内容が反映されます。

なお、最大同時接続数の値を変更した場合は、次の設定も合わせて 変更してください。

定義情報ファイルを直接編集する場合には、次の設定を変更します。

 

7.6.4.9. 特定クライアントに対するアクセス制限

特定のクライアンに対してアクセス制限をかける場合、 次の設定を追加します。
定義情報ファイルを直接編集してください。

例えば、次の設定例では、特定のフォルダ(静的コンテンツ)ごとに アクセスを許可するクライアントを設定しています。
http://server/aaa にアクセスできるクライアントは yourdomain.comに属するマシンに限定し、http://server/bbb にアクセスできるクライアントは anotherdomain.com に属するマシンに限定しています。

<Directory /opt/WebOTX/domains/domain1/docroot/aaa>
  Order Deny,Allow
  Deny form all
  Allow from yourdomain.com
  ...
</Directory>

<Directory /opt/WebOTX/domains/domain1/docroot/bbb>
  Order Deny,Allow
  Deny form all
  Allow from anotherdomain.com
  ...
</Directory>

次の設定例では、特定のフォルダ(静的コンテンツ)に対してアクセスを拒否する クライアントを設定しています。
http://server/ccc にアクセスできるクライアントは、ccc.domain.com 以外に属するクライアントとなります。 ccc.domain.comに属するクライアントはhttp://server/cccにアクセスできません。

<Directory /opt/WebOTX/domains/domain1/docroot/ccc>
  Order Allow,Deny
  Allow from all
   Deny from ccc.domain.com
  ...
</Directory>

Webアプリケーションなどの動的コンテンツに対して、 アクセス制限する場合には、Location 指示子の設定を追加します。
例えば、http://server/webapp 配下に配備されているWebアプリケーションに対して、 yourdomain.com 以外からのアクセスを拒否するには、次のように設定します。

<Location /webapp>
  Order Deny,Allow
  Deny form all
  Allow from yourdomain.com
  ...
</Location>

7.6.4.10. LDAP 連携

WebOTX Webサーバは、WebOTX Application Server にバンドルされている Enterprise Directory Server(EDS)と連携動作が可能であり、 EDSに登録されたエントリ情報を、HTTP認証に利用することができます。
定義情報ファイル(httpd.conf) において、次の設定を追加します。

LoadModule ldap_module "/opt/WebOTX/WebServer2/modules/mod_ldap.so
LoadModule auth_ldap_module /opt/WebOTX/WebServer2/modules/mod_auth_ldap.so

<Directory /opt/WebOTX/domains/domain1/docroot>
  AuthType Basic
  AuthName "Enter username/password."
  AuthLDAPUrl ldap://ldap-server:ldap-port/dc=users,dc=webotx,o=NEC,c=JP?uid?sub
  Require valid-user
</Directory>

上記設定により、ブラウザから http://server/ に対してアクセスが行われた場合に、次のダイアログが出力されます。
ここで LDAPサーバに登録されたユーザ/パスワード を入力することで、ブラウザからのアクセスが可能となります。


図7.6.4.10-1

認証に失敗した場合には、次のメッセージ(HTTPステータスコード 401) がブラウザに出力されます。


図7.6.4.10-2

7.6.4.11. IPv6/IPv4 混在環境での設定

Windowsマシンに、IPv4 ネットワークとIPv6 ネットワーク のそれぞれのIPアドレスが設定されている環境において、 それぞれのIPアドレスに対してWebサーバでアクセス受付を行う場合、 Listen 指示子を利用して、IPv4とIPv6の それぞれのIPアドレスとポート番号を設定してください。

統合運用管理ツールからの操作

あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

ポート番号の設定

  1. 「WebOTX管理ドメイン[<ホスト名>]」- 「<ドメイン名>」-「アプリケーションサーバ」-「WebServer」を選択し、 「定義情報」タブの「ポート番号」の値を更新します。
    (例:WindowsマシンのIPv4/IPv6混在環境でポート番号80を有効にする場合、 編集ボタンや追加ボタンを押下して次の情報を設定します。)
       0.0.0.0:80
       [::]:80


    図7.6.4.11-1


  2. 「更新」ボタンを押下することで、設定内容が定義情報ファイル に反映されます。

  3. Webサーバを再起動することで、設定内容が反映されます。

運用管理コマンド(otxadmin)からの操作

あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

otxadmin>login --user admin --password adminadmin --port 6212

ポート番号の設定

  1. WebOTX Webサーバのポート番号を変更するには、以下のコマンドを実行します。

    otxadmin>set server.WebServer.port=0.0.0.0:80,[::]:80
    
  2. Webサーバを再起動することで、設定内容が反映されます。

上記の操作を行うことで、定義情報ファイルには、次の設定が反映されます。

#Listen 80
 Listen 0.0.0.0:80
 Listen [::]:80

それぞれIPアドレスに対して指定したポート番号で受付可能状態に なっているかを確認するには、netstat コマンド等を利用し、設定したポート番号が LISTENING 状態となっていることを確認してください。
次の例では、 IPv4 および IPv6 のそれぞれのアドレスに対して ポート番号 80 がLISTENING 状態(リクエスト受付可能状態)になっている ことを意味します。

>netstart -an
 Proto Local Address Foreign Address State
 TCP   0.0.0.0:80         0.0.0.0:0         LISTENING
 …
 TCP   [::]:80                [::]:0             LISTENING        0
 …

 

7.6.4.12. システム環境変数の設定

(UNIX)
LoadModule 指示子を利用してモジュールの動的ロードを行う場合、 モジュールが利用するライブラリをロードするために、 あらかじめシステム環境変数(LD_LIBRARY_PATH/SHLIB_PATH等)にライブラリ情報 を登録しておく必要がある場合があります。

この場合、次のファイルに必要となるシステム環境変数の設定を 追加してください。

${AS_INSTALL}/WebServer2/bin/envvars
<<envvarsの内容>>

LD_LIBRARY_PATH="xxx:/opt/WebOTX/WebServer22/lib:$LD_LIBRARY_PATH"
export LD_LIBRARY_PATH

 

7.6.4.13. 起動待ち合わせ時間の設定

WebOTX Webサーバは、WebOTX Application Server の起動と連動しており、 WebOTX Application Server の起動と同時にWebOTX Webサーバに対して、 アライブチェックモニタ機能が動作します。

WebOTX Webサーバの起動タイミングとアライブチェックモニタの 開始タイミングによっては、Webサーバが完全に起動する前に、 アライブチェックモニタ機能が動作するため、「Webサーバが起動していない」 というログが出力される場合があります。

この場合、WebOTX Application Server の JavaVM のオプションに次の設定を行うことで、Webサーバ起動後に アライブチェックモニタ機能を開始する時間(待ち合わせ時間) を秒単位で指定することができます。

あらかじめ、otxadminコマンドを起動し、ドメインにログインし、次のコマンドを実行します。

otxadmin>create-jvm-options -Dwebotx.webserver.startup_wait_count=xxx(秒単位)


7.6.4.14. WebOTX Webサーバ起動失敗時の対処方法について

WebOTX Webサーバの起動/停止は、WebOTX Application Server のドメイン起動/停止に連動していますが、ポートの重複や定義情報の設定ミス等 により、WebOTX Webサーバの起動に失敗する場合があります。

WebOTX Webサーバの起動に失敗した場合、次のファイルに エラーメッセージが出力されますので、その内容を確認し、 エラー発生箇所を修正し、WebOTX Webサーバの再起動を行ってください。

エラー出力先)
  /opt/WebOTX/domains/domain1/logs/webotx_agent.log
  /opt/WebOTX/domains/domain1/logs/web/webotx_websv.log

エラーメッセージ内容)
  OTX05230002: execute ExecException occurred
  Error: com.nec.webotx.enterprise.util.ExecException: abnormal sub process termination:
  Detailed Message: Error Message

または
  OTX05230002: コマンドの実行(execute)で例外(ExecException)が発生しました。(com.nec.webotx.enterprise.syste.webserver)
  Error: com.nec.webotx.enterprise.util.ExecException: abnormal sub process termination:
  Detailed Message: Error Message

Error Message には起動に失敗した原因を意味する メッセージが出力されます。

Webサーバの起動に失敗する主な原因は次のことが考えられます。

失敗原因についての詳細については、 [ トラブルシューティングガイド > 2. 障害解析 > 2.4. 機能別リンク > 2.4.9. Webサーバ(Apache HTTP Serverベース) ] を参照してください。

7.6.5. 注意・制限事項

WebOTX Webサーバの注意・制限事項については、[ 注意制限事項 > 2. Webサーバ(Apache HTTP Serverベース) ]を参照してください。


7.7. 分散管理サーバ

7.7.1. はじめに

分散管理サーバに関する運用操作法について説明します。おおまかな操作の流れは次の通りです。
  1. ドメイングループの登録
  2. 制御対象サーバ、制御対象ドメインの登録
  3. ドメイングループの管理対象一覧の更新
  4. 以上の操作で、ドメイングループの管理対象への操作(配備以外)を行なうことができるようになります。

  5. 分散配備サービスのコンポーネントリポジトリへのコンポーネントの登録
  6. 分散配備サービスの配備構成登録
  7. 分散配備サービスの配備構成への配備先サーバ追加
  8. 分散配備サービスの配備先サーバへのコンポーネントおよび設定ファイル登録
  9. 以上の操作で、ドメイングループの管理対象への配備操作を行なうことができるようになります。

なお、各属性の説明については、[リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) ]を参照してください。

PropertyChange
図7.7.1-1

7.7.2. ドメイングループの運用操作

ドメイングループに関する運用操作方法について説明します。

7.7.2.1. ドメイングループの登録・削除

統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりプロキシドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「ドメイングループ」を選択し、右クリックするか、あるいは、メニューバーの 「操作」を選択します。
  2. 表示される操作メニューから「グループの作成」または「グループの削除」を選択します。
  3. 表示される「ドメイングループの操作」ダイアログで、「実行」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、プロキシドメインにログインしておきます。

ドメイングループを作成する場合は、以下に示すcreate-domain-groupコマンドを使用します。
otxadmin> create-domain-group --anyedition=<Edition混在の許可フラグ[true|false]> --consistency=<自動的な設定差異検出の有無フラグ[true|false]> <グループ名>


ドメイングループを削除する場合は、以下に示すdelete-domain-groupコマンドを使用します。
otxadmin> delete-domain-group <グループ名>


作成済みのドメイングループを確認する場合は、以下に示すlist-domain-groupsコマンドを使用します。
otxadmin> list-domain-groups


7.7.2.2. 制御対象サーバの登録・削除

統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりプロキシドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「ドメイングループ」-「<グループ名>」-「制御対象サーバ」 を選択し、右クリックするか、あるいは、メニューバーの「操作」を選択します。
  2. 表示される操作メニューから「制御対象サーバの登録」または「制御対象サーバの削除」を選択します。
  3. 表示される「制御対象サーバの操作」ダイアログで、「実行」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、プロキシドメインにログインしておきます。

  1. 制御対象サーバを登録する場合は、create-wdc-controlled-serverコマンドを使用します。
    otxadmin> create-wdc-controlled-server --domainGroup <ドメイングループ名> --jmxAdminRemoteURL <管理ドメインのJMX Remote URL> <制御対象サーバ名>


  2. 制御対象サーバを削除する場合は、delete-wdc-controlled-serverコマンドを使用します。
    otxadmin> delete-wdc-controlled-server --domainGroup <ドメイングループ名> <制御対象サーバ名>


7.7.2.3. 制御対象ドメインの登録・削除

統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりプロキシドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「ドメイングループ」-「<グループ名>」-「制御対象サーバ」- 「<制御対象サーバ名>」-「制御対象ドメイン」を選択し、右クリックするか、あるいは、メニューバーの「操作」を選択 します。
  2. 表示される操作メニューから「制御対象ドメインの登録」または「制御対象ドメインの削除」を選択します。
  3. 表示される「制御対象ドメインの操作」ダイアログで、「実行」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、プロキシドメインにログインしておきます。

  1. 制御対象ドメインを登録する場合は、create-wdc-controlled-domainコマンドを使用します。
    otxadmin> create-wdc-controlled-domain --domainGroup <ドメイングループ名> --controlledServerName <制御対象サーバ名> --jmxRemoteURL <制御対象ドメインのJMX Remote URL> <制御対象ドメイン名>


  2. 制御対象ドメインを削除する場合は、delete-wdc-controlled-domainコマンドを使用します。
    otxadmin> delete-wdc-controlled-domain --domainGroup <ドメイングループ名> --controlledServerName <制御対象サーバ名> <制御対象ドメイン名>


次に、この操作により登録したドメイン環境を、後述するドメインの起動/停止や一括操作などの運用のためのグルーピング対象/非対象 とするために、以下の操作を行います。
統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりプロキシドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「ドメイングループ」-「<グループ名>」を選択し、右クリック するか、あるいは、メニューバーの「操作」を選択します。
  2. 表示される操作メニューから「ドメインの登録」または「ドメインの削除」を選択します。
  3. 表示される「<グループ名>の操作」ダイアログで、「実行」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、プロキシドメインにログインしておきます。

グループ内に運用対象とするドメインを登録する場合は、以下に示すadd-group-domainコマンドを使用します。
otxadmin> add-group-domain --groupname <グループ名> --replace=<固有情報再設定の要否フラグ[true|false]> <ホスト名> <ドメイン名>

グループ内から運用対象とするドメインを削除する場合は、以下に示すremove-group-domainコマンドを使用します。
(注意) この操作により、実際のドメイン環境(のファイルやリソース)が削除されることはありません。
otxadmin> remove-group-domain --groupname <グループ名> <ホスト名> <ドメイン名>

グループ内に登録済みのドメインを確認する場合は、以下に示すlist-group-domainsコマンドを使用します。
otxadmin> list-group-domains <グループ名>


ここで、上述の制御対象サーバの登録(7.7.2.2. 制御対象サーバの登録・削除)および制御対象ドメインの登録(7.7.2.3. 制御対象ドメインの登録・削除)の作業を、登録対象のドメインを管理するホスト上の管理ドメインによって自動化することができます。登録対象のホスト上のドメインが、VMwareなどの仮想化ソフトウェアが作成・展開したイメージを用いて動作し、そのような環境を複数台構築する場合などには、本機能により構築時間を短縮できます。 本機能を使用する場合、マスタ・イメージにおける登録対象のドメインを管理する管理ドメインにおいて、次の作業を実施します。
統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールより管理ドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」を選択し、右クリック するか、あるいは、メニューバーの「操作」を選択します。
  2. 表示される操作メニューから「分散管理サーバ」-「プロキシドメインへのドメイン登録のための設定」を選択します。
  3. 表示される「WebOTX管理ドメイン[<ホスト名>]の操作」ダイアログで、プロキシドメイン上のドメイングループへ制御対象とするドメインを登録するためのパラメータを入力し、「実行」ボタンをクリックします。
  4. 上記操作により設定した情報を確認するには、「分散管理サーバ」-「プロキシドメインへのドメイン登録のための設定情報一覧の表示」を選択します。表示される「WebOTX管理ドメイン[<ホスト名>]の操作」ダイアログで、「実行」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、管理ドメインにログインしておきます。

プロキシドメイン上のドメイングループへ制御対象とするドメインを登録するために、以下に示すinvokeコマンドを使用します。
otxadmin> invoke domain.setupForProxy <ドメイン名> <プロキシドメインに対するJMXリモート接続URL> <プロキシドメインに対するJMXリモート接続時のセキュリティ機能の有無[true|false]> <登録対象のドメイングループ名のリスト> <ドメイン固有情報に対する再設定処理の要否[true|false]>

上記コマンドにより設定した情報を確認するには、以下に示すinvokeコマンドを使用します。
otxadmin> invoke domain.listSetupInfoForProxy

本操作後、登録対象のドメイン起動時には、上記で設定した情報を基に、プロキシドメイン上のドメイングループに対して自動的に制御対象サーバおよび制御対象ドメインの登録処理が実施されます。
なお、登録対象のドメイン起動の際には、予めプロキシドメインが起動しており、登録対象のドメイングループが存在している必要があります。

7.7.2.4. ドメインの起動・停止

統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりプロキシドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「ドメイングループ」-「<グループ名>」を選択し、右クリック するか、あるいは、メニューバーの「操作」を選択します。
  2. 表示される操作メニューから「ドメインの起動」または「ドメインの停止」を選択します。グループ内の個々のドメインを起動 または停止するには、操作メニューから「特定のドメインの起動」または「特定のドメインの停止」を選択します。
  3. 表示される「<グループ名>の操作」ダイアログで、「実行」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、プロキシドメインにログインしておきます。

  1. グループ内のドメインを全て起動する場合は、以下に示すstart-group-domainコマンドを使用します。
    ※グループ内の個々のドメインは、並列に起動処理が開始されます。
    otxadmin> start-group-domain --waitingtimeout <タイムアウト時間(秒)> <グループ名>

    グループ内の特定のドメインを起動する場合は、以下に示すstart-group-domainコマンドを使用します。
    otxadmin> start-group-domain --targethost <ホスト名> --targetdomain <ドメイン名> --waitingtimeout <タイムアウト時間(秒)> <グループ名>

  2. グループ内のドメインを全て停止する場合は、以下に示すstop-group-domainコマンドを使用します。
    ※グループ内の個々のドメインは、並列に停止処理が開始されます。
    otxadmin> stop-group-domain --waitingtimeout <タイムアウト時間(秒)> --force=<タイムアウト時の強制停止フラグ[true|false]> <グループ名>

    グループ内の特定のドメインを停止する場合は、以下に示すstop-group-domainコマンドを使用します。
    otxadmin> stop-group-domain --targethost <ホスト名> --targetdomain <ドメイン名> --waitingtimeout <タイムアウト時間(秒)> --force=<タイムアウト時の強制停止フラグ[true|false]> <グループ名>

7.7.2.5. 管理対象一覧の更新

(注意) この操作を行う際には、グループ内のドメインが起動している必要があります。

統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりプロキシドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「ドメイングループ」-「<グループ名>」を選択し、右クリックするか、 あるいは、メニューバーの「操作」を選択します。
  2. 表示される操作メニューから「管理対象一覧の更新」を選択します。
  3. 表示される「<グループ名>の操作」ダイアログで、「実行」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、プロキシドメインにログインしておきます。

  1. 以下に示すrefresh-management-objectsコマンドを使用します。
    otxadmin> refresh-management-objects <グループ名>


7.7.2.6. 管理対象ドメインへのJMX接続タイムアウトについて

ドメイングループ内の各管理対象ドメインへのJMX接続のタイムアウトは以下の手順で変更可能です。

接続のアイドルタイムアウト時間

管理対象ドメインに対し、以下のシステムプロパティを設定することで指定可能です。この値は、設定された管理対象ドメインに対する接続のみに有効な値です。

com.nec.webotx.rmi.transport.tcp.readTimeout=<タイムアウト値[ms]>

設定方法は [ドメイン構築・基本設定ガイド] > [3. ドメイン] > [3.8. Java VMオプションの設定] > [3.8.2. ユーザ独自のJavaVMオプションの追加方法] を参照してください。

初期接続のタイムアウト時間

proxyドメインに対し、以下のシステムプロパティを設定することで指定可能です。この値は、proxyドメインから接続する全ての管理対象ドメインへの接続に対し有効な値です。

com.nec.webotx.rmi.transport.connectTimeout=<タイムアウト値[ms]>

既定値は10[s]です。

設定方法は [ドメイン構築・基本設定ガイド] > [3. ドメイン] > [3.8. Java VMオプションの設定] > [3.8.2. ユーザ独自のJavaVMオプションの追加方法] を参照してください。


7.7.3. 制御対象ドメインの一括操作

グループ内に登録されたドメインに対して、一括した運用操作を行うための方法について説明します。

7.7.3.1. 管理対象の設定更新

グループ内に登録されたドメインに対して、個々のドメイン内の管理対象に対する同一の設定項目を一括して変更するためには、次の 操作を行います。

統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「ドメイングループ」-「<グループ名>」配下に、登録されたドメイン上 の管理対象が表示されていることを確認します。表示されていない場合は、先述の「管理対象一覧の更新」操作を予め実施します。
  2. 設定を変更する管理対象を選択し、画面右側に表示される属性ビューから、設定を変更する項目に対して新しい設定値を入力します。
  3. 入力完了後、「更新」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. 以下に示すsetコマンドを使用します。
    otxadmin> set domain.groups.<グループ名>.<管理対象名>.<属性名>=<設定値>

    ここで、<管理対象名>および<属性名>には、通常のドメインに対してsetコマンドで指定する管理対象名(CLIName)および 属性名が該当します。

    (例) JVM構成の最大ヒープサイズを変更する場合

    管理対象名:server.java-config、属性名:max-heap-size

    従って、ドメイングループに対して同一の設定を行う場合には、次のように指定します。

    (例) グループ名 dg1 、最大ヒープサイズ 1024MB の場合
    set domain.groups.dg1.server.java-config.max-heap-size=1024m

7.7.4. 分散配備サービスの運用操作

分散配備のサービスMOに関する運用操作法について説明します。

7.7.4.1. 分散配備サービスの設定

統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「分散配備」を選択します。
  2. リストビューから変更したい属性を選択して変更します。
  3. 「更新」ボタンをクリックして変更を反映します。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. 属性に設定している値を参照するには、getコマンドを使用します。

    例) 1つの項目(タイムアウト)を参照する場合
    otxadmin> get domain.ddeployment.ddeployTimeout

    例) すべての項目を参照する場合
    otxadmin> get domain.ddeployment.*


  2. 属性の値を設定するには、setコマンドを使用します。

    例) タイムアウトを設定する場合
    otxadmin> set domain.ddeployment.ddeployTimeout=600


7.7.4.2. 分散配備サービスの起動・停止

統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

分散配備サービスの停止中は、配備に関わる操作は実行できません。情報の登録・削除等の操作は実行できます。



  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「分散配備」を選択し、右クリックするか、あるいは、メニューバーの[操作] を選択します。
  2. 表示されるメニューから「分散配備機能の開始」または「分散配備機能の停止」を選択します。
  3. 表示される「分散配備の操作」ダイアログで、「実行」ボタンをクリックします。
  4. 表示される「確認」ダイアログで、「はい」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. 分散配備サービスを開始する場合は、start-ddeploy-serviceコマンドを使用します。
    otxadmin> start-ddeploy-service


  2. 分散配備サービスを停止する場合は、stop-ddeploy-serviceコマンドを使用します。
    otxadmin> stop-ddeploy-service


7.7.4.3. 分散配備サービスの初期化

分散配備サービスに登録されているコンポーネントに関わる全ての情報を削除することができます。
統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。また、この操作はデフォルトでは表示されません。
[ 運用ツールガイド > 3.11.2. 画面表示 ]の「操作の表示レベル」を、「詳細レベルの情報を表示」 や「全レベルの情報を表示」に変更してください。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「分散配備」を選択し、右クリックするか、あるいは、メニューバーの[操作] を選択します。
  2. 表示されるメニューから「分散配備サービスの初期化」を選択します。
  3. 表示される「分散配備の操作」ダイアログで、「実行」ボタンをクリックします。
  4. 表示される「確認」ダイアログで、「はい」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. 分散配備サービスの初期化を行うためには、clear-ddeploy-serviceコマンドを使用します。
    otxadmin> clear-ddeploy-service


7.7.5. コンポーネントの管理

分散配備では、アプリケーションや設定ファイルをコンポーネントとして管理します。 それらの各種コンポーネントに関する運用操作法について説明します。

7.7.5.1. コンポーネントリポジトリへの登録・削除

統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. 登録するコンポーネントの種類に応じて「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「分散配備」-「コンポーネントリポジトリ」配下のEJBコンポーネントまたはESBサービスアセンブリ、 JavaEEアプリケーション、Webコンポーネント、CORBAコンポーネント、その他のコンポーネントのいずれかを選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。
  2. 表示されるメニューから「コンポーネントの登録」または「コンポーネントの削除」を選択します。
  3. 登録を行う場合は最低限コンポーネントIDとファイルパスを設定します。削除を行う場合は削除するコンポーネントのIDを選択します。
  4. 表示される「コンポーネントの操作」ダイアログで、「実行」ボタンをクリックします。
  5. 表示される「確認」ダイアログで、「はい」ボタンをクリックします。

コンポーネントの削除は、コンポーネントを直接選択して実行することもできます。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. コンポーネントを登録する場合は、ddeploy-register-componentコマンドを使用します。
    otxadmin> ddeploy-register-component --componentType ejb --componentId ejb1 ./ejb/sample.jar


  2. コンポーネントを削除する場合は、ddeploy-unregister-componentコマンドを使用します。
    otxadmin> ddeploy-unregister-component ejb1


7.7.5.2. 配備構成への追加・削除

統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「分散配備」-「配備構成」-「<配備構成名>」-「<サーバ名>」を選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。
  2. 表示されるメニューから「コンポーネントの追加」または「コンポーネントの削除」を選択します。
  3. 表示される「<サーバ名>の操作」ダイアログで、リストボックスからコンポーネントIDを選択します。
  4. 「実行」ボタンをクリックします。
  5. 表示される「確認」ダイアログで、「はい」ボタンをクリックします。

コンポーネントの削除は、コンポーネントを直接選択して実行することもできます。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. コンポーネントを追加する場合は、ddeploy-link-componentコマンドを使用します。
    otxadmin> ddeploy-link-component --constitutionName constitusion1 --serverName apg1-pg1 ejb1


  2. コンポーネントを削除する場合は、ddeploy-unlink-componentコマンドを使用します。
    otxadmin> ddeploy-unlink-component --constitutionName constitusion1 --serverName apg1-pg1 ejb1


7.7.5.3. アーカイブファイルの取り出し

統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「分散配備」-「コンポーネントリポジトリ」配下のEJBコンポーネントまたはESBサービスアセンブリ、 JavaEEアプリケーション、Webコンポーネント、CORBAコンポーネント、その他のコンポーネントのいずれかを選択して、その配下の「<コンポーネントID>」を選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。
  2. 表示されるメニューから「アーカイブファイルの取り出し」を選択します。
  3. 表示される「<コンポーネントID>の操作」ダイアログで、必要に応じて出力先ディレクトリを変更します。
  4. 「実行」ボタンをクリックします。
  5. 表示される「確認」ダイアログで、「はい」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. アーカイブファイルの取り出しを行う場合は、ddeploy-export-componentコマンドを使用します。
    otxadmin> ddeploy-export-component --path ../backup ejb1


7.7.5.4. CORBAコンポーネントの登録

CORBAコンポーネントの登録について説明します。

CORBAコンポーネントは、makecpkコマンドで作成したアーカイブファイル(cpk)を登録してください。

R5形式のCORBAアプリケーションを登録する場合は、アーカイブファイルに含まれるプロパティファイル名(拡張子を除く)を、 コンポーネントIDとして指定してください。プロパティファイルは、コンポーネント初期化ファイル名(component.initfuncで指定)が指定されているファイルです。 例として、corbaap.propertiesに指定されている場合は、corbaapをコンポーネントIDとして指定します。

CORBAアプリケーションの配備時に名前サーバへの登録も行う場合は、あらかじめ、名前サーバ登録情報ファイルをコンポーネントリポジトリに登録する必要があります。 名前サーバ登録情報ファイルは、「その他のコンポーネント」に登録します。その際、コンポーネントタイプとして「名前サーバ登録情報ファイル」 を指定します。登録した名前サーバ登録情報ファイルのコンポーネントIDを、CORBAコンポーネントの「名前サーバ登録情報ファイルコンポーネントID」 属性に指定します。

7.7.5.5. 共有コンポーネントの登録

共有コンポーネントの登録について説明します。

共有コンポーネントは、「その他のコンポーネント」に登録します。その際、コンポーネントタイプとして「共有コンポーネント」を指定します。

共有コンポーネントは、makecpkコマンドで作成したアーカイブファイル(spk)を登録してください。

7.7.5.6. 名前サーバ登録情報ファイルの登録

名前サーバ登録情報ファイルの登録について説明します。

名前サーバ登録情報ファイルは、CORBAアプリケーションの配備時に名前サーバへの登録を行う際、必要とする情報を記述したものです。

名前サーバ登録情報ファイルは、「その他のコンポーネント」に登録します。その際、コンポーネントタイプとして「名前サーバ登録情報ファイル」 を指定します。

名前サーバ登録情報ファイルは、次のxmlフォーマットに従って作成してください。


<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<DDNameServerInformation>
    <DDCORBAInterfaceInformation>
        <InterfaceName>インタフェース名</InterfaceName>
        <ConnectCtrlPolicy>コネクション制御ポリシ</ConnectCtrlPolicy>
        <SystemSetupRefer>TPシステム設定の参照の有無</SystemSetupRefer>
        <BindType>名前サーバへの登録</BindType>
        <UseMultiServer>登録するIORの生成方式(マルチサーバ使用有無)</UseMultiServer>
        <MultiServerID>複数サーバシステムグループ名</MultiServerID>
        <RoundRobinFunction>ラウンドロビン機能を使用有無</RoundRobinFunction>
        <RegisterName>名前サーバ登録名</RegisterName>
        <RegisterName>名前サーバ登録名</RegisterName>
    </DDCORBAInterfaceInformation>
</DDNameServerInformation>
要素名 説明 子要素 設定先
DDNameServerInformation 名前サーバ登録情報を設定します。名前サーバ登録情報ファイル内に1個だけ存在します。 DDCORBAInterfaceInformation[1]
DDCORBAInterfaceInformation DDNameServerInformation内に1個だけ記述します。 InterfaceName[0,1]
ConnectCtrlPolicy[0,1]
SystemSetupRefer[0,1]
BindType[0,1]
UseMultiServer[0,1]
MultiServerID[0,1]
RoundRobinFunction[0,1]
RegisterName[1,*]
InterfaceName インタフェース名を指定します。DDCORBAInterfaceInformation内に0個または1個だけ記述します。
ConnectCtrlPolicy コネクション制御ポリシを設定します。DDCORBAInterfaceInformation内に0個または1個だけ記述します。
指定された値は「設定先」の属性に設定されます。設定値は、BYHOST(ホスト単位), BYREFERENCE(オブジェクト単位) または NOREUSE(コネクションを再利用しない) です。
WebOTXCORBAObject MO の connectCtrlPolicy属性
SystemSetupRefer 名前サーバへの登録に関してTPシステムの設定を参照するか設定します。
DDCORBAInterfaceInformation内に0個または1個だけ記述します。
指定された値は「設定先」の属性に設定されます。設定値は、true または false です。
WebOTXCORBAObject MO の systemSetupRefer属性
BindType 名前サーバへの登録方法を設定します。
DDCORBAInterfaceInformation内に0個または1個だけ記述します。
指定された値は「設定先」の属性に設定されます。設定値は、TEMPORARY(一時的に扱う) または PERSIST(永続的に扱う) です。
WebOTXCORBAObject MO の bindType属性
UseMultiServer 登録するIORの生成方式を指定します。マルチサーバを使用する場合は、trueにしてください。
DDCORBAInterfaceInformation内に0個または1個だけ記述します。
指定された値は「設定先」の属性に設定されます。設定値は、true または false です。
WebOTXCORBAObject MO の useMultiServer属性
MultiServerID 複数サーバ設定を行うときシステムグループを設定します。UseMultiServerでtrueが設定されている場合のみ有効です。
DDCORBAInterfaceInformation内に0個または1個だけ記述します。
指定された値は「設定先」の属性に設定されます。設定値は設定先の属性値に従ってください。
WebOTXCORBAObject MO の multiServerID属性
RoundRobinFunction ラウンドロビン機能の利用を設定します。
DDCORBAInterfaceInformation内に0個または1個だけ記述します。
指定された値は「設定先」の属性に設定されます。設定値は、true または false です。
WebOTXCORBAObject MO の roundRobinFunction属性
RegisterName 名前サーバへの登録名を指定します。名前サーバへのIOR登録URLをcorbaname形式で指定します。
DDCORBAInterfaceInformation内に1個以上、任意の数だけ記述できます。
指定された値は「設定先」の属性に設定されます。設定値は設定先の属性値に従ってください。
WebOTXCORBAObject MO の urlList属性

7.7.6. 配備構成の管理

分散配備では、配備先サーバや配備対象のコンポーネントの組み合わせを配備構成として管理します。 その配備構成や、その配下の配備先サーバとコンポーネント、設定ファイルに関する運用操作法について説明します。

7.7.6.1. 配備構成の登録・削除・複製

統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「分散配備」-「配備構成」を選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。
  2. 表示されるメニューから「配備構成の登録」または「配備構成の削除」、「配備構成の複製」を選択します。
  3. 表示される「配備構成の操作」ダイアログで、配備構成名やドメイングループ名を指定します。
  4. 「実行」ボタンをクリックします。
  5. 表示される「確認」ダイアログで、「はい」ボタンをクリックします。

あらかじめドメイングループの登録(7.7.2.1. ドメイングループの登録・削除)を行っておくと、配備構成の登録時にリストボックスからドメイングループの名前を選択することができます。
配備構成の削除は、配備構成を直接選択して実行することもできます。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. 配備構成を登録する場合は、ddeploy-add-constitutionコマンドを使用します。
    otxadmin> ddeploy-add-constitution --domainGroup group1 constitusion1


  2. 配備構成を削除する場合は、ddeploy-delete-constitutionコマンドを使用します。
    otxadmin> ddeploy-delete-constitution constitusion1


  3. 配備構成を複製する場合は、ddeploy-copy-constitutionコマンドを使用します。
    otxadmin> ddeploy-copy-constitution --constitutionName constitusion1 constitution2


7.7.6.2. サーバの追加・削除

WebOTX AS Standard/Enterpriseのプロセスグループに対してアプリケーションを配備する場合には、サーバの追加を行う必要があります。ドメインのエージェントプロセスに対して アプリケーションを配備する場合は、自動的に生成される"server"を利用します。
統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「分散配備」-「配備構成」-「<配備構成名>」を選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。
  2. 表示されるメニューから「サーバの追加」または「サーバの削除」を選択します。
  3. 表示される「<配備構成名>の操作」ダイアログで、リストボックスからサーバ名を選択します。リストボックスが表示されない場合は、 アプリケーショングループ名-プロセスグループ名の形式で名前を入力してください。
  4. 「実行」ボタンをクリックします。
  5. 表示される「確認」ダイアログで、「はい」ボタンをクリックします。

あらかじめ、ドメイングループで管理対象一覧の更新(7.7.2.5. 管理対象一覧の更新)を行っておくと、サーバの追加時にリストボックスからサーバ名を選択することができます。 サーバの削除は、サーバを直接選択して実行することもできます。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. 配備構成を登録する場合は、ddeploy-add-serverコマンドを使用します。
    otxadmin> ddeploy-add-server --constitutionName constitution1 apg1-pg1


  2. 配備構成を削除する場合は、ddeploy-delete-serverコマンドを使用します。
    otxadmin> ddeploy-delete-server --constitutionName constitution1 apg1-pg1


7.7.6.3. コンポーネントの追加・削除

7.7.5.2. 配備構成への追加・削除を参照してください。

7.7.6.4. 設定ファイルの追加・削除

統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「分散配備」-「配備構成」-「<配備構成名>」-「設定ファイル」を選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。
  2. 表示されるメニューから「設定ファイルの追加」または「設定ファイルの削除」を選択します。
  3. 表示される「設定ファイルの操作」ダイアログで、リストボックスからコンポーネントIDを選択します。
  4. 「実行」ボタンをクリックします。
  5. 表示される「確認」ダイアログで、「はい」ボタンをクリックします。

設定ファイルの削除は、設定ファイルを直接選択して実行することもできます。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. 設定ファイルを追加する場合は、ddeploy-link-configurationコマンドを使用します。
    otxadmin> ddeploy-link-configuration --constitutionName constitution1 domain.properties


  2. 設定ファイルを削除する場合は、ddeploy-unlink-configurationコマンドを使用します。
    otxadmin> ddeploy-unlink-configuration --constitutionName constitution1 domain.properties


7.7.7. 配備操作

分散配備の様々な配備操作に関する運用操作法について説明します。

7.7.7.1. コンポーネントリポジトリの配備操作

コンポーネントリポジトリの配備操作を実行することで、登録されている全てのコンポーネントの配備操作を実行することができます。

7.7.7.2. 配備構成の配備操作

配備構成の配備操作を実行することで、特定の構成のシステムやサーバ(プロセスグループやエージェントプロセス)に配備を行うことができます。

自動配備対象ドメイン一覧に、配備操作の対象となる配備構成が存在する場合、配備操作を実行することはできません。
自動配備対象予約を取り消して配備操作を実行する場合には、自動配備対象ドメイン状態監視を停止後、 手動で「自動配備対象ドメイン一覧」属性からドメイン情報を削除してから、配備操作を行なってください。

CORBAコンポーネントの配備操作については、7.7.7.13. CORBAコンポーネントの配備操作も参照してください。

共有コンポーネントの配備操作については、7.7.7.14. 共有コンポーネントの配備操作も参照してください。

統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「分散配備」-「配備構成」-「<配備構成名>」を選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。
  2. 表示されるメニューから「配備操作の実行」を選択します。
  3. 表示される「<配備構成名>の操作」ダイアログで、リストボックスから実行する配備操作とドメイングループ名を選択します。
  4. 「実行」ボタンをクリックします。
  5. 表示される「確認」ダイアログで、「はい」ボタンをクリックします。

統合運用管理ツールから行った配備操作は、非同期に終了します。配備操作の進捗状況は、7.7.7.6. 配備操作状況の確認で確認してください。
非常に大きなアプリケーションを配備する場合は、タイムアウトの指定を調整してください。デフォルト値を変更する場合は、分散配備サービスMOのタイムアウトの値を変更してください。
障害等で配備を中断した後に再実行する場合は、配備制御モードにrecoveryやforceを指定してください。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. 配備および開始操作を実行する場合は、ddeploy-deployコマンドを使用します。
    otxadmin> ddeploy-deploy --constitutionName constitution1


  2. 停止および配備解除操作を実行する場合は、ddeploy-undeployコマンドを使用します。
    otxadmin> ddeploy-undeploy --constitutionName constitution1


  3. 開始操作を実行する場合は、ddeploy-startコマンドを使用します。
    otxadmin> ddeploy-start --constitutionName constitution1


  4. 停止操作を実行する場合は、ddeploy-stopコマンドを使用します。
    otxadmin> ddeploy-stop --constitutionName constitution1


  5. 配備操作を実行する場合は、ddeploy-distributeコマンドを使用します。
    otxadmin> ddeploy-distribute --constitutionName constitution1


  6. 置換操作を実行する場合は、ddeploy-replaceコマンドを使用します。
    otxadmin> ddeploy-replace --constitutionName constitution1


コマンドからの配備操作は、完了するまで応答が返りません。
各コマンドの詳細は、otxadminコマンドのhelpコマンドで説明を表示するか、[ リファレンス集 運用管理・設定編 > 4. 運用管理コマンドリファレンス > 4.2.2. コマンド検索一覧 > 運用管理コマンド (otxadmin) リファレンス ]を参照してください。

7.7.7.3. 配備先サーバの配備操作

配備先サーバの配備操作を実行することで、特定のサーバ(プロセスグループやエージェントプロセス)への配備を行うことができます。

統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「分散配備」-「配備構成」-「<配備構成名>」-「<サーバ名>」を選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。
  2. 表示されるメニューから「配備操作の実行」を選択します。
  3. 表示される「<サーバ名>の操作」ダイアログで、リストボックスから実行する配備操作とドメイングループ名を選択します。
  4. 「実行」ボタンをクリックします。
  5. 表示される「確認」ダイアログで、「はい」ボタンをクリックします。

統合運用管理ツールから行った配備操作は、非同期に終了します。配備操作の進捗状況は、7.7.7.6. 配備操作状況の確認で確認してください。
非常に大きなアプリケーションを配備する場合は、タイムアウトの指定を調整してください。デフォルト値を変更する場合は、分散配備サービスMOのタイムアウトの値を変更してください。
障害等で配備を中断した後に再実行する場合は、配備制御モードにrecoveryやforceを指定してください。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. 配備および開始操作を実行する場合は、ddeploy-deployコマンドを使用します。
    otxadmin> ddeploy-deploy --constitutionName constitution1 --serverName apg1-pg1


  2. 停止および配備解除操作を実行する場合は、ddeploy-undeployコマンドを使用します。
    otxadmin> ddeploy-undeploy --constitutionName constitution1 --serverName apg1-pg1


  3. 開始操作を実行する場合は、ddeploy-startコマンドを使用します。
    otxadmin> ddeploy-start --constitutionName constitution1 --serverName apg1-pg1


  4. 停止操作を実行する場合は、ddeploy-stopコマンドを使用します。
    otxadmin> ddeploy-stop --constitutionName constitution1 --serverName apg1-pg1


  5. 配備操作を実行する場合は、ddeploy-distributeコマンドを使用します。
    otxadmin> ddeploy-distribute --constitutionName constitution1 --serverName apg1-pg1


  6. 置換操作を実行する場合は、ddeploy-replaceコマンドを使用します。
    otxadmin> ddeploy-replace --constitutionName constitution1 --serverName apg1-pg1


コマンドからの配備操作は、完了するまで応答が返りません。
各コマンドの詳細は、otxadminコマンドのhelpコマンドで説明を表示するか、[ リファレンス集 運用管理・設定編 > 4. 運用管理コマンドリファレンス > 4.2.2. コマンド詳細 > コマンド索引一覧 ]を参照してください。

7.7.7.4. コンポーネントの配備操作

コンポーネントリポジトリに登録されているコンポーネントを個別に配備することができます。

統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「分散配備」-「コンポーネントリポジトリ」を選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。
  2. 表示されるメニューから「配備操作の実行」を選択します。
  3. 表示される「コンポーネントリポジトリの操作」ダイアログで、リストボックスから実行する配備操作とドメイングループ名を選択します。配備するコンポーネントIDを追加します。配備先のサーバ名を入力します。
  4. 「実行」ボタンをクリックします。
  5. 表示される「確認」ダイアログで、「はい」ボタンをクリックします。

統合運用管理ツールから行った配備操作は、非同期に終了します。配備操作の進捗状況は、7.7.7.6. 配備操作状況の確認で確認してください。
非常に大きなアプリケーションを配備する場合は、タイムアウトの指定を調整してください。デフォルト値を変更する場合は、分散配備サービスMOのタイムアウトの値を変更してください。
障害等で配備を中断した後に再実行する場合は、配備制御モードにrecoveryやforceを指定してください。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. 配備および開始操作を実行する場合は、ddeploy-deployコマンドを使用します。
    otxadmin> ddeploy-deploy --domainGroup domain1 --serverName apg1-pg1 --componentId ejb1


  2. 停止および配備解除操作を実行する場合は、ddeploy-undeployコマンドを使用します。
    otxadmin> ddeploy-undeploy --domainGroup domain1 --serverName apg1-pg1 --componentId ejb1


  3. 開始操作を実行する場合は、ddeploy-startコマンドを使用します。
    otxadmin> ddeploy-start --domainGroup domain1 --serverName apg1-pg1 --componentId ejb1


  4. 停止操作を実行する場合は、ddeploy-stopコマンドを使用します。
    otxadmin> ddeploy-stop --domainGroup domain1 --serverName apg1-pg1 --componentId ejb1


  5. 配備操作を実行する場合は、ddeploy-distributeコマンドを使用します。
    otxadmin> ddeploy-distribute --domainGroup domain1 --serverName apg1-pg1 --componentId ejb1


  6. 置換操作を実行する場合は、ddeploy-replaceコマンドを使用します。
    otxadmin> ddeploy-replace --domainGroup domain1 --serverName apg1-pg1 --componentId ejb1


コマンドからの配備操作は、完了するまで応答が返りません。
各コマンドの詳細は、otxadminコマンドのhelpコマンドで説明を表示するか、[ リファレンス集 運用管理・設定編 > 4. 運用管理コマンドリファレンス > 4.2.2. コマンド詳細 > コマンド索引一覧 ]を参照してください。

7.7.7.5. 設定ファイルの配備操作

コンポーネントリポジトリに登録されている設定ファイルによる設定をすることができます。

統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「分散配備」-「コンポーネントリポジトリ」-「その他のコンポーネント」-「<コンポーネントID>」を選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。
  2. 表示されるメニューから「配備操作の実行」を選択します。
  3. 表示される「<コンポーネントID>の操作」ダイアログで、リストボックスからドメイングループ名を選択します。
  4. 「実行」ボタンをクリックします。
  5. 表示される「確認」ダイアログで、「はい」ボタンをクリックします。

統合運用管理ツールから行った配備操作は、非同期に終了します。配備操作の進捗状況は、7.7.7.6. 配備操作状況の確認で確認してください。
非常に大きな設定を実施する場合は、タイムアウトの指定を調整してください。デフォルト値を変更する場合は、分散配備サービスMOのタイムアウトの値を変更してください。
障害等で配備を中断した後に再実行する場合は、配備制御モードにrecoveryやforceを指定してください。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. 設定を実行する場合は、ddeploy-configureコマンドを使用します。
    otxadmin> ddeploy-configure --domainGroup domain1 --componentId config1


コマンドからの配備操作は、完了するまで応答が返りません。
各コマンドの詳細は、otxadminコマンドのhelpコマンドで説明を表示するか、[ リファレンス集 運用管理・設定編 > 4. 運用管理コマンドリファレンス > 4.2.2. コマンド詳細 > コマンド索引一覧 ]を参照してください。

7.7.7.6. 配備操作状況の確認

配備操作の途中で、配備操作状況を確認することができます。

統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「分散配備」を選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。
  2. 表示されるメニューから「配備操作状況の参照」を選択します。
  3. 表示される「分散配備の操作」ダイアログで、必要に応じてコンポーネントの表示数を変更します。
  4. 「実行」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. 配備操作状況を確認するためには、ddeploy-statusコマンドを使用します。
    otxadmin> ddeploy-status

      実行結果は次のように表示されます。

    deploy operation  [DEPLOY]
    domain group      [group5]
    status            [DONE]
    
    distributed       1/1  * 100% completed *
    now distributing  0
    
    * * running components * *
    [Host,domain group,server(target),component,elapsed time]
    Command ddeploy-status executed successfully.
    


7.7.7.7. 配備操作の中止

配備操作を途中で中止することができます。

統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「分散配備」を選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。
  2. 表示されるメニューから「配備操作の中止」を選択します。
  3. 表示される「分散配備の操作」ダイアログで、必要に応じて中止操作のタイムアウト時間を変更します。
  4. 「実行」ボタンをクリックします。
  5. 表示される「確認」ダイアログで、「はい」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. 配備操作を中止するためには、ddeploy-cancelコマンドを使用します。
    otxadmin> ddeploy-cancel


7.7.7.8. 配備操作の再実行

指定された配備結果レポートをもとに配備に失敗した操作のみを再実行することができます。配備結果レポートについての詳細は、[ 製品構成と提供機能 > 3. 提供機能 > 3.8.3. 分散配備 ] の「配備結果の確認機能」を参照ください。

再実行の対象が配備構成の場合、対象の配備構成の「自動配備対象ドメイン一覧」属性に自動配備予約されたドメイン情報 が存在すると、再実行はできません。再実行したい場合は、自動配備対象ドメイン状態監視を停止後、 手動で「自動配備対象ドメイン一覧」属性からドメイン情報を削除してから、再実行をしてください。

配備操作の再実行は、配備結果に記載されている配備対象および配備構成をもとに配備操作を行いますので、 配備構成が変更されている場合も変更後の配備構成は有効となりません。

統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「分散配備」を選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。
  2. 表示されるメニューから「配備操作の再実行」を選択します。
  3. 「実行」ボタンをクリックします。
  4. 表示される「確認」ダイアログで、「はい」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. 配備操作の再実行をするためには、ddeploy-re-operationコマンドを使用します。
    otxadmin> ddeploy-re-operation


7.7.7.9. 自動配備対象ドメイン状態監視の開始

ドメイン起動時に自動配備するためのドメイン状態監視を開始することができます。

統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「分散配備」を選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。
  2. 表示されるメニューから「自動配備対象ドメイン状態監視の開始」を選択します。
  3. 「実行」ボタンをクリックします。
  4. 表示される「確認」ダイアログで、「はい」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. 自動配備対象ドメイン状態監視を開始するためには、ddeploy-start-admonitorコマンドを使用します。
    otxadmin> ddeploy-start-admonitor


7.7.7.10. 自動配備対象ドメイン状態監視の停止

ドメイン起動時に自動配備するためのドメイン状態監視を停止することができます。

統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「分散配備」を選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。
  2. 表示されるメニューから「自動配備対象ドメイン状態監視の停止」を選択します。
  3. 「実行」ボタンをクリックします。
  4. 表示される「確認」ダイアログで、「はい」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. 自動配備対象ドメイン状態監視を停止するためには、ddeploy-stop-admonitorコマンドを使用します。
    otxadmin> ddeploy-stop-admonitor


7.7.7.11. 自動配備対象ドメイン状態監視状況の参照

ドメイン起動時に自動配備するためのドメイン状態監視状態を参照することができます。

統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「分散配備」を選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。
  2. 表示されるメニューから「自動配備対象ドメイン状態監視状況の参照」を選択します。
  3. 「実行」ボタンをクリックします。
  4. 表示される「確認」ダイアログで、「はい」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. 自動配備対象ドメイン状態監視状況を参照するためには、ddeploy-admonitor-statusコマンドを使用します。
    otxadmin> ddeploy-admonitor-status


7.7.7.12. 自動配備対象ドメイン一覧

ドメイン起動時の自動配備待ちとなっているドメイン一覧を参照することができます。



統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「分散配備」を選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。
  2. 表示されるメニューから「自動配備対象ドメイン一覧」を選択します。
  3. 「実行」ボタンをクリックします。
  4. 表示される「確認」ダイアログで、「はい」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. ドメイン起動時の自動配備待ちとなっているドメイン一覧を参照するためには、ddeploy-reserved-domainsコマンドを使用します。
    otxadmin> ddeploy-reserved-domains


7.7.7.13. CORBAコンポーネントの配備操作

CORBAコンポーネントの配備操作について説明します。

CORBAコンポーネントの配備、再配備、配備解除を行う場合、CORBAアプリケーションの形式(「アプリケーション開発ガイド」参照)、配備先プロセスグループのバージョン によっては、アプリケーショングループが停止している必要があります。このような場合は、配備操作の実行時に「配備操作前の停止」 オプションで「通常停止」「強制停止」を指定すると、分散配備が配備操作前に配備対象アプリケーショングループを停止後、 配備処理を行います。その際、配備対象アプリケーショングループの停止に失敗すると、配備操作は失敗します。
配備対象のアプリケーショングループ、プロセスグループが多いと配備操作の実行に要する時間も長くなります。

通常のdeploy操作は、コンポーネント単位でdistribute操作、start操作を続けて実行します。
CORBAコンポーネントと共有コンポーネントのdeploy操作は、他コンポーネントとは異なり、CORBAコンポーネントと共有コンポーネント タイプの全コンポーネントのdistribute操作を実行後、全コンポーネントのstart操作を実行します。
deploy(replace)操作時、「配備操作前の停止」オプションで「通常停止」「強制停止」が指定されているとdistribute操作前に アプリケーショングループを停止し、start操作前にアプリケーショングループを開始します。
この時、アプリケーショングループの開始に失敗すると、配備操作は失敗します。

CORBAコンポーネントのdistribute操作、deploy操作時に名前サーバへの登録を行うことができます。
名前サーバへの登録を行う場合は、「その他のコンポーネント」に登録した名前サーバ登録情報ファイルのコンポーネントIDを CORBAコンポーネントの「名前サーバ登録情報ファイルコンポーネントID」に指定した状態で配備操作を行います。 名前サーバへの登録は、名前サーバ登録情報ファイルに指定された関連属性をWebOTXCORBAObject MOの属性に設定後、 名前サーバへの登録を実行します。

CORBAコンポーネントとその他の種別のコンポーネントとで配備構成を分けて作成してください。 「配備操作前の停止」にてアプリケーショングループの停止を行う場合、CORBAコンポーネントと その他の種別のコンポーネントとが混在していると、J2EEのプロセスグループも停止されます。 (J2EEとCORBAのプロセスグループが混在するアプリケーショングループの場合)

7.7.7.14. 共有コンポーネントの配備操作

共有コンポーネントの配備操作について説明します。

共有コンポーネントの配備操作を行う場合は、配備構成を登録し、server配下にコンポーネントを登録してください。