JS7® JobScheduler リカバリー手段の検討

概要

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