マネージャーは,実行ホスト(エージェント)を監視したり,実行登録したジョブ※をポーリング監視したりします。JP1/AJS2では,通常,ジョブの状態は実行ホストからマネージャーに自動的に通知されますが,マネージャーと実行ホスト間の通信障害や,マネージャーのシステムダウンなどが発生した場合,ジョブの状態が正しく通知されないことがあります。このような障害時のリカバリー処理のために監視処理を実行します。
(1) 実行中のジョブの監視
マネージャーは,実行中のジョブを5分間隔でポーリング監視します。ジョブが終了したとき,マネージャーは実行ホストからの終了通知によって,ジョブの状態を終了状態にします。しかし,一時的な通信障害などによって終了通知を受けられなかった場合,このポーリング監視によってジョブの終了を検知します。また,マネージャーのポーリング監視が通信障害などによって失敗し,実行中のジョブの状態を確認できない状態がおよそ12~30分(実行ホストの監視間隔とジョブの実行開始時間のタイミングによって変わります)続く場合,マネージャーはその実行中のジョブの状態を変更します。なお,複数の実行ホストに対してジョブを実行している場合,実行ホストごとに実行中のジョブの状態を確認します。そのため,障害状態として管理する実行ホスト数に比例して通信回数が増えます。
ジョブネットに定義しているジョブの場合,ジョブの状態を「強制終了」に変更し終了コードに-1を設定します。jpqjobsubコマンドで実行するジョブの場合,-rsオプションで指定した状態に変更します。詳細については,マニュアル「JP1/Automatic Job Management System 2 コマンドリファレンス 1. コマンド jpqjobsub」を参照してください。
このとき統合トレースログには次に示すメッセージが表示されます。
KAVU4534-W エージェント(エージェントホスト名)の応答がないためジョブ(ジョブ番号)を回復状態(状態名)にしました
ここで監視対象となるジョブは,標準ジョブ(ただし,ほかのシステムで実行しているQUEUEジョブは対象外),アクションジョブ,およびカスタムジョブです。
(2) 実行ホスト(エージェント)の監視
マネージャーは,実行ホストにジョブを実行登録するときの通信に失敗すると,実行ホストに障害が発生している,または実行ホストが停止していると認識します。障害の状態,または停止の状態を検知すると,その実行ホストを5分間隔でポーリング監視し,実行ホストの運用を確認します。実行ホストに障害が発生している間,または実行ホストが停止している間は,ジョブはキューイング状態で実行ホストの回復を待ちます。実行ホストの運用の回復(障害の状態,または停止の状態の回復)を検知すると,実行ホストにジョブの実行登録を再開します。しかし,実行ホストへのジョブの実行登録に失敗してから10~15分以上(実行ホストの監視間隔とジョブの実行登録要求時間のタイミングによって変わります)経過しても実行ホストが回復しない場合は,そのジョブの状態は「起動失敗」となります。なお,実行ホストごとに実行ホストへの状態を確認するため,障害状態として管理する実行ホスト数に比例して通信回数が増えます。
このとき統合トレースログには次のメッセージが表示されます。
KAVU4593-W 実行可能なエージェントがありません
ここで監視対象となるジョブは,標準ジョブ(ただし,ほかのシステムで実行しているQUEUEジョブは対象外),アクションジョブ,およびカスタムジョブです。
(3) 他システムジョブの監視
マネージャーは,他システム(JP1/NQSEXECやJP1/OJEなど)に実行登録したジョブを5分間隔でポーリング監視し,ジョブの状態を確認します。およそ一時間以上通信状態が回復しない場合は,次に示すエラーメッセージを統合トレースログに出力してジョブの状態を異常終了にします。
KAVU6218-W 状態通知プロセスのTCP/IP通信でエラーが発生したためジョブ情報が取得できませんでした。ジョブは正常終了している可能性があります(マネージャー名:マネージャー名,ジョブ番号:ジョブ番号) |
他システムの中には,ジョブの状態が変化した時点でマネージャーに通知する機能をサポートしていないものもあります。その場合,5分間のポーリング監視だけでジョブの状態を取得するためジョブの状態が変わるのに最大で5分ほど掛かることがあります。ジョブの状態変化を通知する機能のサポートの有無については,他システムのマニュアルを参照してください。
なお,jpqjobsubコマンドを使用して他システムにサブミットジョブを登録した場合は,5分間隔のポーリング監視は行いません。jpqjobgetコマンドを使用して,ジョブの状態を確認してください。
(4) ジョブの実行ホストの障害検知および障害回復待ち時間
JP1/AJS2では,ジョブ(標準ジョブ,アクションジョブおよびカスタムジョブ)の実行ホスト(エージェントホスト)が障害状態になった場合や通信障害が発生した場合でも,即時に異常検知とはしません。ある程度の待ち時間を設けて通信リトライすることで,エージェントホスト上のシステム障害や通信障害状態が回復するのを待ちます。これによって,一時的な障害による,回復可能な業務停止を防止しています。
また,運用によっては障害が発生した場合は回復を待つよりも,直ちに異常を検知して早急なリカバリーを優先させる場合があります。その場合は,TCP/IP通信接続による通信時間または障害回復待ち時間を短縮することにより,早急な障害検知ができます。障害検知までの時間を短縮する場合は,マニュアル「JP1/Automatic Job Management System 2 セットアップガイド 7.24 エージェントの障害回復待ち時間を短縮する設定方法」またはマニュアル「JP1/Automatic Job Management System 2 セットアップガイド 16.22 エージェントの障害回復待ち時間を短縮する設定方法」を参照してください。
ジョブの配信時とジョブの実行時では,エージェントホストの障害を検知するまでの時間がそれぞれ異なります。次に説明します。
(a) ジョブ配信時の障害検知および障害回復待ち時間
マネージャーホストからエージェントホストへジョブを配信する際は,TCP/IP通信を使用しています。そのため,エージェントホストが起動していない場合やネットワーク障害が発生している場合,TCP/IP通信の接続エラーが発生します。ただし,通常はリトライしているため,エラーとするまでに最大でおよそ5分掛かることがあります。通信接続エラーとなったエージェントホストは障害状態として管理します。それ以降のジョブ配信時はエージェントホストの障害状態が回復していない場合,TCP/IP通信接続はしません。
エージェントホストが障害状態の場合,どのジョブも障害回復待ち時間(デフォルト10分)の間エージェントホストの回復を待ちます。その間,ジョブはキューイング中(サブミットジョブの場合は実行待ち)となりますが,障害回復待ち時間を過ぎてもエージェントホストが回復しない場合は,その時点で起動失敗となります。したがって,ジョブが実行登録されてから起動失敗となるまでの時間はTCP/IP通信をする場合としない場合とで次の2とおりがあります。
(b) ジョブ実行中の障害検知および障害回復待ち時間
マネージャーホストは,エージェントホストからジョブの実行開始通知を受けるとジョブの状態を実行中に変更し,エージェント監視インターバルのデフォルト300秒(5分)間隔のポーリングで,エージェントホストごとにジョブの状態確認をします。その際,プロセス間で情報を受け渡すためにTCP/IP通信を使用しています。エージェントホストが起動していない場合やネットワーク障害が発生している場合,TCP/IP通信の接続エラーが発生します。ただし,通常はリトライしているため,エラーとするまでに最大で310秒(5分10秒)掛かることがあります。※1
通信接続エラーが発生した際に,エージェントホストの障害回復待ち時間(デフォルト10分)の範囲内であれば,さらにポーリングの状態確認を続行します。エージェントホストの障害回復待ち時間を超えている場合は,その時点で異常検知となり,マネージャーホストはジョブを強制終了状態※2に変更します。そのため,実際にエージェントホストで障害が発生してからジョブが異常を検知するまでに合計時間として,およそ12分から30分ほど掛かることになります。※3
障害検知までの合計時間 ≒
(エージェント監視インターバル * 2回)
+ (通信時間 * 3回)
+ 障害発生時間から最初の状態確認までの時間