概要
JobScheduler 各コンポーネントの一時停止時の影響について整理します。
まず、Workflow実行時におけるJOC、Controller、Agent 間のデータの流れを確認します。
それを踏まえてJOC、Controller、Agentが一時停止した際の影響を確認します。
前提条件
- JOC、Controller、Agentとも、スタンドアロン構成とします。(OSS版の機能制限)
- JobSchedulerについて、検証環境であっても、自ら環境構築、Workflow設計、スケジュール作成など行い、運用している程度の知識があると望ましい。
- 本記事はJobScheduler Ver. 2.3.2、2.4.1 の環境で確認した内容です。
Workflow実行時のデータの流れ
Workflowの実行時に、JOC-Controller-Agent間でどのようなデータのやり取りがあるか、大雑把に見てみます。
1. InventoryのDeploy
- JOCにて、Workflow、JobResourceなどのインベントリ情報を作成、更新し、Deployする
- DeployされたInventory情報は、Controller上のJournal Dataに保存される。
2. Orderの追加
- JOCにて、（DailyPlanや手動などで）Orderを追加する。
- Order情報（開始日時、実行Workflowなど）は、Controllerに送られ、Journal Dataに保存される。
- Controllerより、該当Agent宛てに、Order情報と関連Inventory情報が送られ、Agent上のJournal Dataに保存される
※Workflowの構成によっては、実行時に初めてAgentに送られるケースもあり。 - JOC上で表示されるOrderのステータスは、Controllerから収集した内容となります
3. Workflow実行
- Agentにて、Order情報で指定されたスケジュールに従い、Workflowが実行される
- Order、Jobの実行状況や、標準出力／エラーなどのログ情報は、随時Agent上のJournal Dataに保存される
- Controllerでは、Agent上のJournal Dataの収集を随時行い、Order、Job実行状況、ログ情報はController上のJournal Dataに保存される
- JOCではhistory serviceが、Controller上のJournal Dataの収集を随時行い、Order、Job実行状況、ログ情報はDBに更新される
- JOC上で表示されるログやOrderステータスは、Controllerから収集した内容となります
4. Journal Data 消去
- Agentでは、Controllerからの収集が終わったJournal Dataは、適宜消去される。
- Controllerでは、JOCからの収集が終わったJournal Dataは、適宜消去される。
- この仕組みによりJournal Data の肥大化は防止される。
コンポーネント停止時の影響について
運用をしていれば、サーバー、ネットワーク、OSなどのメンテナンス停止、その他軽微な障害などによる一時的な停止など、度々発生するかと思います。
この場合、特別なリカバリー操作をせずとも、正常起動でき次第、復旧します。
上記のデータの流れを踏まえて、各コンポーネントの停止時の影響について説明します。
JOC停止時
- JOCのweb管理画面にはログインできず、Workflowの状況を確認できない
- 必然的に、インベントリの管理（作成、更新など）Orderの操作(追加、キャンセル、一時停止など)、ログ確認もできない。
- 既存のController、Agentの動作にはただちに影響はない
- Controller、AgentはOrder情報を受け取っていれば、それを自律的に実行する
※DailyPlanのデフォルト設定で3日後までOrderが追加されている - Orderが完了しても、JOCでの情報収集ができないため、Notification設定でのメール通知等は遅延する（JOC起動後に通知される）
- Jobの数や内容、停止時間によっては、Controller/Agentのジャーナルデータが肥大化する可能性はある。（JOC起動後に縮小する）
Controller停止時
- Agentは既に追加されたOrderについては、スケジュールどおりにWorkrlowを実行する。
ただしWorkFlowが複数AgentのJobで構成される場合は保留となる。 - JOCからのOrder追加、キャンセル、一時停止などのControllerとのやり取りはすべて遅延する。（JOC上のproxy serviceで保持される）
- インベントリ管理（Workflow、JobResourceなどのDeploy）は行えない。
- Agentでの実行結果はAgent上のJournal Dataで保持。ただし、JOCにはWorkFlowの実行データが更新されない。（Controller起動後に更新される）
- Orderが完了しても、JOCからの情報収集ができないため、Notification設定でのメール通知等は遅延する（Controller起動後に通知される）
- Jobの数や内容、停止時間によっては、Agentのジャーナルデータが肥大化する可能性はある。（Controller起動後に縮小する）
Controllerが停止している間は、JOCは再起動をしないこと、Order操作を行わないことを推奨します。
proxy service での保持状況は、確認が困難で、かつJOCサービスを再起動すると、消滅します。
Agent停止時
- 該当AgentではWorkflowが実行できない。
- スケジュール開始時刻が過ぎた場合は、Agentが起動したタイミングで実行される。
- JOCからのOrderの操作(追加、キャンセル、一時停止など)は遅延する。（Agent起動後に実行される）
Controller、Agentでは、Journal Dataを一時データとして使うことで、どのコンポーネントが一時停止しても、影響は最小限におさえられます。
また、コンポーネントが起動次第、処理の実行、ログ収集などの処理が随時行われ、速やかに復旧します。
最後に
本記事の内容で、JS7の予期せぬ一時停止や、計画メンテナンスによる停止による影響範囲の整理などできるようになるかと思います。
万が一の障害対応時以外にも、サーバー入替やエージェント変更時など、様々な場面で役に立つ基礎知識となります。
JS7の管理を行う際は是非おさえてください。
参考
JS7 - Resilience
JS7 - Implementation Architecture
JS7 - FAQ - What happens to workflows in case of outages