概要
JOC、Controller、Agentにて、障害もしくは何らかの理由でリカバリーが必要となった場合の対応手段を整理したものです。
JS7 JobScheduler の管理を行う場合は押さえておくべき内容となります。
前提条件
- 本記事では、JobSchedulerのシステム設定のリカバリー操作について取り扱います。
環境構築、運用時に配置した証明書、実行用スクリプトの配備などは別途必要となります。
また、DBバックアップ／リストアや、スナップショット操作などは取り扱いません。 - 本記事は、やむを得ずバックアップ時に戻すなどの対応時の説明となります。
サーバー再構築、DBリストアなどを伴わないサービスの一時停止の場合、特別な対応は不要です。 - ジャーナル、Historyなど、Workflow実行時のデータの流れを理解していること。
こちらので記事で解説しています。JS7® JobScheduler 一時停止時の影響について - DailyPlanの操作をおさえていること。
こちらので記事で解説しています。JS7® JobScheduler DailyPlanによるスケジュール作成 - 本記事はJobScheduler Ver. 2.3.2、2.4.1 の環境で確認した内容です。
はじめに
システムを運用していれば障害はつきものです。
またメンテナンス作業時など、フェイルバック手段を検討する必要もあるかと思います。
そこで本記事では、JS7のリカバリーを行う場合の段取り、対応のポイントについて解説します。
リカバリー時の操作の流れに合わせて、下記の説明をします。
- 設定の復元（JOCの復元時のみ）
- 各コンポーネント間の接続の回復 (JOC - Controller - Agent)
- インベントリ情報の復元
- Order情報の対処
設定の復元（JOCの復元時のみ）
まず設定の復元についてですが、こちらは基本的にDBのリストアでまるごと復元できます。
OSまるごとスナップショットを取得している場合は、そちらからの復元でも問題ありません。
JOCにログインして行う各種設定や、Orderの履歴、ログ情報は、すべてDBに更新されています。
そのため、環境構築手順＋DBバックアップがあれば、そこからリカバリーは可能です。
（Orderの履歴、ログ情報は、Controllerから収集完了したデータのみ）
コンポーネント間のhttps用の設定、証明書ファイル配置などは別途行う必要があります。
各コンポーネント間の接続の回復
設定の復元はすんなり行えるのですが、場合によっては、Controller、Agentとの接続に障害が発生する可能性があります。
接続問題が発生する理由（目安）
※明確な動作を把握しているわけではないため、想定される内容での説明となります。
例えば 12時にDBバックアップ、15時にJOCがダウン、JOCを12時時点のデータで復元したとします。
この場合、12時以降、JOCがダウンする15時までの間も、JOC⇔Controller間で処理の実行、履歴収集などのやりとりが行われます。
JOCで保持している収集済みデータ（DBリストア内容）は12時時点ですが、Controllerで保持しているジャーナルデータは15時までの内容が更新済みであるため、JOC-Controller間で不整合が発生します。
同様のことが、Controller、Agentのリカバリー時でも発生します。
（もしくは新規セットアップ時はジャーナルに接続情報自体が入っていない）
この場合、接続問題が発生している箇所に応じて、リセット（ジャーナ初期化）の操作が必要となります。
- JOC - Controller 間の障害の場合
→ Controller,Agentにてリセットの対応が必要
（ControllerのリセットでAgnetとの整合性も崩れるため） - Controller - Agent 間の障害の場合
→ Agentにてリセットの対応が必要
（JOC - Controller間の対応は不要）
ジャーナルデータの不整合が無ければ、特に問題なく通信が回復できます。この場合は以降の手順は不要です。
（計画メンテの場合、これを踏まえて、サービス停止することで、ジャーナル更新を防止する手段もあります）
JOC - Controller間の接続回復
JOCのDashboardより、Controllerの接続が確認できない場合の対応です。
あらかじめ、JOC - Controller間の通信ができ、サービス起動状態も問題ないことを確認してください。
Controllerにて、サービスを停止、ジャーナルデータ削除、サービス起動をします。
※ジャーナルデータはJS7_CONTROLLER_DATA/state以下に生成されます。
# サービス名 js7controller 、JS7_CONTROLLER_DATA が /opt/sos-berlin.com/js7/controller/var の場合
sudo systemctl stop js7controller.service
sudo rm -f /opt/sos-berlin.com/js7/controller/var/state/*
sudo systemctl start js7controller.service
※Controllerを新規構築した場合は不要です。
JOC - Controller間の疎通は、これで回復するはずです。
【補足】history service再起動について
Controllerのリセットを行った場合、JOC側でControllerの接続はでき、AgentにてOrderの実行ができているにも関わらず、JOCではOrderの実行情報（ステータス、ログ）が表示されないことを確認しています。
この場合、Dashboardより、history service の再起動を行ってください。
これで、Workflowのステータスや、ログが収集され、確認できるようになります。
Controller - Agent間の接続回復
JOCのDashboardより、Agentの接続が確認できない場合の対応です。
あらかじめ、Controller－Agent間の通信ができ、サービス起動状態も問題ないことを確認してください。
また、必ず先にJOC - Controller 間の接続回復を済ませてください。
Manage Controllers and Agents より、該当エージェントを選択し、Reset Force を実行してください。
（接続回復に1分程度かかります）
もしうまくいかない場合は、エージェントにて直接、サービスを停止、ジャーナルデータ削除、サービス起動をします。
※ジャーナルデータはJS7_AGENT_DATA/state以下に生成されます。
# サービス名 js7agent_4445 、JS7_AGENT_DATA が /opt/sos-berlin.com/js7/agent/var_4445 の場合
sudo systemctl stop js7agent_4445.service
sudo rm -f /opt/sos-berlin.com/js7/agent/var_4445/state/*
sudo systemctl start js7agent_4445.service
直接でジャーナル削除した場合は、さらに Manage Controllers and Agents より、Revoke を実行後、deployを行ってください。(Agent新規登録時に行う操作と同じ)
Controller - Agent間の疎通は、これで回復するはずです。
インベントリ情報の復元
Controllerの接続復旧のためにリセット操作を行った場合、インベントリ情報も削除されます。
Workflowの画面を見ると、Statusがnot synchronizedとなっており、実行できないことが分かります。
この場合、Workflow、JobResourceなどのインベントリ情報は、改めてDeployを行ってください。
Deploy後、動作テスト用に適当なWorkflowを実行して、正常に動作することを確認してください。
もしOrderの応答が返らない場合は、Controller、Agentのログを確認してください。
Agent側で実行されているにも関わらず、JOCに応答が返らない場合、history service の再起動が必要です。
Order情報の対処
Controller、Agentでジャーナル初期化の操作を行った場合、ジャーナルデータに保存されたOrder情報も全て消去されます。
そのため、既存のOrderが実行済みか、未実行かをチェックし、状況に応じての対応が必要となります。
当日のOrder
まず、本来実行されるべきWorkflowが、どこまで実行完了しているか、確認してください。
JS7_AGENT_DATA/logs/agent.log で確認可能。もしくは処理に関連するシステム側でご確認ください。
ジャーナル初期化をすると、スケジュール済みのOrder情報もリセットされます。
そのため未実行のOrderについては、手動での対応が必要です。
手動でOrderを追加（即時、時刻指定など）、もしくはJS7を使わず直接必要スクリプトを実行でも可。
DailyPlan は、翌日以降しか作成できません。
そのため当日のOrderは、手動で実行する必要があります。
※9時以前の場合は（UTC日時で前日扱い）DailyPlanで当日Orderも作成可能です。その場合は次の「翌日以降」の手順を参考にしてください。
翌日以降のOrder
DailyPlanでスケジュール実行をしている場合、翌日以降のOrderも登録しなおす必要があります。
まず、現在のSchedule済みOrderが全て消えていることを確認します。
※Agentのみリセットした場合は、すべてFailedとなります。
既存のDailyPlanに登録されている、翌日以降のOrderは全てキャンセルします。
（登録されているOrderは、すべてFailedとなっている無効なOrderです）
※キャプチャの都合で翌月が見えないですが、翌月以降にOrderがある場合はそちらもキャンセル
さらに、翌日以降のDailyPlanを削除します。
DailyPlanサービスの再起動で、翌日以降のDailyPlanを再作成します。
翌日以降のScheduleが追加されたことを確認してください。
単に既存のOrderをキャンセル/Submitted Order（またはDailyPlan再起動）の操作では、Orderが登録されないケースがあります。
この操作では、OrderIdが変わらず、このOrderIdは既にステータスFailedとなっているためです。
必ず既存のDailyPlanを削除し、作り直してください。
※厳密にはControllerはリセットせず、Agentのみリセットした場合に発生する問題です。
【補足】データの欠損について
本記事で説明したリセット操作を行った場合、未収集Order情報の欠損を避けることはできません。
たとえWorkflowが実行済みであっても、JOC側ではログは残りません。
データ欠損を避けたい場合は、JS7のHA構成を検討してください。（有償ライセンス）
最後に
本記事は、本稼働を行うためには是非おさえておきたい内容です。
理解をするのは大変ですが、大袈裟なリカバリーに限らず、サーバー入れ替え時をはじめ、随所で利用できる知識となります。
本記事の内容の内容が、本番利用の検討や、適切なバックアップ計画などのお役位立てれば幸いです。
参考
JS7 - How to troubleshoot Controller journals
JS7 - How to troubleshoot Agent journals
JS7 - How to backup the job scheduling environment