|
|
WebOTX Manual V10.3 (第4版) 目次を表示 |
|
|
|
WebOTX Manual V10.3 (第4版) 目次を表示 |
WebOTX Application Serverのサービスの起動失敗について説明します。
特定のアプリケーションだけでなく、WebOTX Application
Server全体に及ぶ問題が発生した場合は、こちらを参照して下さい。
TP モニタ・マネージャライフサイクルの起動停止には、TP モニタに関する制御を行うTP モニタ制御サー
ビス(oltpad)とTP モニタプロセス(tpmMain)が影響します。
これらのサービスやプロセスが起動失敗すると、TP システムが起動せず、TP モニタ・マネージャライフサ
イクルも起動失敗します。
TPモニタが必要とするファイルやディレクトリにアクセス権限がなかった場合、
あるいはファイルやディレクトリが不足していた場合、TPモニタは起動に失敗し、TP モニタ・マネージャも起動失敗となります。
→ TPモニタプロセス起動失敗 権限不足やファイル不足
UNIXにおいて、WebOTXの起動中に以下のコマンドを実行した場合、
TPモニタ・マネージャが状態不正となり異常終了します。
(HP-UX)
/sbin/init.d/WebOTXinit101 start
(Linux)
SysVinitの場合：
/etc/init.d/WebOTXinit101 start
systemdの場合：
systemctl start WebOTXinit101
→ TPモニタプロセス起動失敗 共有メモリ不正
TP モニタプロセスが何らかの理由で異常終了した場合、
他のTPモニタに関連するプロセスが動作しているのであれば、クライアントからのユーザアクセスは成功する可能性はあります。
しかし、TP システムに対する運用操作ができなくなります。
また、実行時に確保する共有メモリが残ってしまうため、次回以降のTP モニタ・マネージャの起動に失敗します。
この場合、プロセスグループのプロセスが起動しないため、クライアントからのユーザアクセスがエラーとなり（ユーザ実装による）、
統合運用管理ツールからはTP システムが停止していることが確認できます。
→ TPモニタプロセス異常終了 共有メモリ残留について
UNIX 版において、WebOTX起動時に運用ユーザを変更してしまう（otxown.sh を実行してしまう）と、
TP モニタ・マネージャが正常動作しなくなる可能性があります。
→ TPモニタプロセス異常終了 実行中の運用ユーザ変更について
リスナが正常に起動していない場合、全てのオペレーション呼び出しを行う事ができません。
起動時に問題があった場合や何らかのプログラム的問題による終了が考えられます。
起動時の問題としては、UNIXでIIOPリスナの場合は「最大同時接続クライアント数」、AJPリスナの場合は「最大同時リクエスト処理数」の設定
を増やした事によるカーネルパラメータの不足により起動に失敗する事があります。
あるいはリスナで使用するポートが既に使用されている可能性があります。
全てのオペレーション呼び出しに失敗する場合、
リスナ異常終了時/未起動以外が原因の可能性もあります。
以下にそれぞれ説明があります。
→ サーバポート未開設への対応
クライアントアプリケーションからサーバアプリケーションに対するオペレーション呼び出しに失敗した場合の調査方法を説明します。
調査のためには、何の呼び出しが何のエラーになったのかを確認する必要があります。
何のエラーかだけで調査が可能な場合もありますが、通信障害や遅延/無応答などの障害ではエラー情報で相手が特定できません。
何の呼び出しがエラーになったのかを確認することで対象を絞り込むことができます。
あらゆるCORBA システム例外で、minor 番号が3840〜4095
の範囲にある場合は、WebOTX のサーバ実 行環境からエラーを受けています。WebOTXのサーバ実行環境上で何らかの問題が起きています。
以下に、主な障害について説明します。
例外一覧は、[ リファレンス > 例外 ] で説明しているのでそちらも参照してください。
通信障害の発生を意味します。オペレーション呼び出し時のCOM_FAILUREなら実行基盤との間で問題があり、 リファレンス取得でのCOM_FAILUREなら名前サーバとの間で問題がおきています。
名前サーバから取得しようとしたリファレンスが存在しない場合に本エラーになります。
リファレンスの登録をAP起動と同期して行っている場合(一時的な登録の場合)、APが起動していない可能性があります。
→ プロセスグループ未起動への対応
リファレンスの登録時にラウンドロビン機能を使用する設定になっている場合、 名前サーバのラウンドロビン拡張機能が有効になっていない可能性もあります。 名前サーバのラウンドロビン拡張機能の設定を確認してください。 この設定については、ドメインの名前サーバを使用している場合は [ リファレンス > 設定 > CORBA通信基盤(Object Broker) > Object Broker設定項目・設定方法 ] を参照してください。
リファレンスの登録が永続的となっていて、まだ一度も呼び出しに成功したことがないという場合は、 単にリファレンス登録を行っていない可能性があります。 [コマンドリファレンス > TPシステム > woiorinfo ] で登録状況を確認するか、リファレンス登録を再実行してみてください。
クライアント側で指定したタイマ(デフォルト30秒)の間に応答が返ってこない場合にNO_RESPONSE例外が返ります。
NO_RESPONSE及び無応答の場合は、APサーバでデッドロックやループ障害などがおきている可能性があります。
→ APストールへの対応
→ CPU使用率の過剰への対応
また、デッドロックなどで完全に処理が止まっていなくても、
リクエスト量の増加による処理待ち時間増加やAPの修正による処理時間増加などによって遅延が起きている可能性もあります。
→ オペレーション遅延への対応
→ キュー滞留によるレスポンス遅延への対応
J2EEアプリケーションの場合、 同一プロセスグループ上で動作する異なるアプリケーションアーカイブファイルに含まれるアプリケーション間の呼び出しは、 リモート呼び出しとなり別スレッドでの実行完了を待ちます。 このため、実行スレッド不足によるデッドロックが発生する可能性があります。
例えば、同一プロセスグループにwarとejb-jarでアーカイブされたアプリケーションがそれぞれ別々に配備され、 スレッド数の設定が1である場合にサーブレットからEJBを呼び出すと、空きスレッド待ちの状態となってデッドロックが発生します。
プロセスグループのスレッド数を増やすことにより、 スレッド数よりクライアントの同時接続数が少ない場合はデッドロックが解消しますが、 スレッド数以上の要求を受け付けたときはやはりデッドロックとなる可能性があります。
このような場合は呼び出し元と呼び出し先のアプリケーションをひとつのアプリケーションとしてアーカイブして配備するか、 別々のプロセスグループに配備するようにしてください。
リクエスト量の増加による処理待ち時間増加やAPの修正による処理時間増加などによって遅延が起きている可能性があります。
オペレーションの遅延は運用アシスタント機能により自動的に検出することができます。詳細は [ 構築・運用 > ドメインの構築 > TPシステム > 運用アシスタント ] を参照してください。
エラーの詳細は不明ながらもクライアントの利用者からエラーの報告を受けることは多々あります。 可能であればトレースを設定して再現させてください。 トレースが取れない場合も、状況によってはある程度原因が絞り込める可能性があります。
・特定のオペレーションが常に失敗し、それ以外は成功する場合
成功するオペレーションがあるのでAPサーバへ到達するまでの設定に問題はなさそうです。 名前サーバやAP実行基盤の起動状態も問題ありません。 但し名前サーバが正しく見られているものの肝心のリファレンスがない可能性があります。 [ リファレンス > コマンドリファレンス > TPシステム > woiorinfo ] で登録状況を確認するか、リファレンス登録を再実行してみてください。
一番可能性が高いのが特定のオペレーションを含むプロセスグループかアプリケーショングループが
障害状態(または単に起動してない)ケースです。
→ アプリケーショングループ未起動への対応
→ プロセスグループ未起動への対応
・特定のクライアントのみ常に失敗となる
特定のクライアントだけがまったくうまく行かない、成功することがない、という場合です。 WebOTXのサーバではクライアントの設定がありません。 つまりクライアントのアドレスによってどうこうという処理がありません。 このため特定のクライアントのみ失敗するケースでサーバ要因の可能性は低く、 クライアント側の設定に問題がある可能性が高いです。 正常なクライアントとの間で環境の比較を行ってください。
・特定のオペレーションが成功したり失敗したりする
その特定のオペレーションに付与されたユーザデータの違いにより成功したり失敗したりしている可能性があります。 該当のプロセスグループで障害が起きていないか確認してください。 ユーザデータを含めた電文長が制限を越えている可能性も考えられます。 制限の約10M(9999998byte)を越えていないか確認してください。
・一度失敗すると失敗し続け、プロセスグループの再起動で復旧する場合
プロセスグループの再起動にあたり、正常停止操作がタイムアウトし、強制停止操作でようやく停止できたという場合は、 オペレーション実行がいつまで終わらない状況になっていた可能性があります。システムトレース（ [ 構築・運用 > ログ ] ）に実行中だったオペレーションの情報が残っているはずなので確認してください。
アプリケーションが起動/停止しない、アプリケーションの起動/停止に時間がかかる、 アプリケーションが異常終了するといった障害について説明しています。
起動操作を行った際に起動完了に著しく時間がかかった、または失敗した場合を起動障害とします。
タイムアウト障害
起動処理失敗
遅延
起動後しばらく動作していたものが異常終了したケースです。
イベントログ・syslogまたは ${INSTANCE_ROOT}/logs/tpsystem/history.act
を調査してください。
タイムアウト障害
オペレーション失敗
正常の終了
これらは${INSTANCE_ROOT}/logs/tpsystem/history.actに出力されるプロセス及びプロセスグループの正常停止メッセージであり、 運用停止時に出力されます。異常終了時は別のメッセージが出力されます。 APが異常終了したと思って調査したものの実際には運用停止操作が行われていた、といったことがまれにあります。 ${INSTANCE_ROOT}/logs/tpsystem/history.actを確認し、終了が異常か正常かを見極めてください。
停止操作を行った際に停止完了に著しく時間がかかった、または失敗した場合を停止障害とします。
アプリケーションプロセスの異常終了時の停止処理に著しく時間がかかった場合も停止障害とします。
タイムアウト障害
遅延
リクエスト量の増加による処理待ち時間増加やAPの修正による処理時間増加などによって遅延が起きている可能性があります。
→ オペレーション遅延への対応
または完全に処理が止まっているかもしれません。
→ APストールへの対応
(1)リソース不足
(2)同時接続数超過
(3)プロトコル不正
(4)運用管理操作により切断を指示された場合
(5)システム停止時
(6)通信障害
(7)無通信監視
スクリプトマネージャ機能を正しく使用して接続･切断をしていない、もしくは、その他の関連する設定が正しく行われていない可能性があります。
→ ユーザアプリケーションによるネットワークドライブへの接続･切断･アクセス失敗への対応