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

# 概要

JOC、Controller、Agentにて、障害もしくは何らかの理由でリカバリーが必要となった場合の対応手段を整理したものです。
JS7 JobScheduler の管理を行う場合は押さえておくべき内容となります。

# 前提条件

- 本記事では、JobSchedulerのシステム設定のリカバリー操作について取り扱います。<br />環境構築、運用時に配置した証明書、実行用スクリプトの配備などは別途必要となります。<br />また、DBバックアップ／リストアや、スナップショット操作などは取り扱いません。
- 本記事は、やむを得ずバックアップ時に戻すなどの対応時の説明となります。<br />サーバー再構築、DBリストアなどを伴わないサービスの一時停止の場合、特別な対応は不要です。
- ジャーナル、Historyなど、Workflow実行時のデータの流れを理解していること。<br />こちらので記事で解説しています。[JS7® JobScheduler 一時停止時の影響について](https://qiita.com/saitamanokusa/items/ee7196cdcf080974bd83)
- DailyPlanの操作をおさえていること。<br />こちらので記事で解説しています。[JS7® JobScheduler DailyPlanによるスケジュール作成](https://qiita.com/saitamanokusa/items/fd640cf5e0fbde69b992)
- 本記事はJobScheduler Ver. 2.3.2、2.4.1 の環境で確認した内容です。

# はじめに

システムを運用していれば障害はつきものです。
またメンテナンス作業時など、フェイルバック手段を検討する必要もあるかと思います。

そこで本記事では、JS7のリカバリーを行う場合の段取り、対応のポイントについて解説します。
リカバリー時の操作の流れに合わせて、下記の説明をします。

- 設定の復元（JOCの復元時のみ）
- 各コンポーネント間の接続の回復 (JOC - Controller - Agent)
- インベントリ情報の復元
- Order情報の対処

# 設定の復元（JOCの復元時のみ）

まず設定の復元についてですが、こちらは基本的にDBのリストアでまるごと復元できます。
OSまるごとスナップショットを取得している場合は、そちらからの復元でも問題ありません。

JOCにログインして行う各種設定や、Orderの履歴、ログ情報は、すべてDBに更新されています。
そのため、環境構築手順＋DBバックアップがあれば、そこからリカバリーは可能です。
（Orderの履歴、ログ情報は、Controllerから収集完了したデータのみ）

:::note warn
コンポーネント間のhttps用の設定、証明書ファイル配置などは別途行う必要があります。
:::

# 各コンポーネント間の接続の回復

設定の復元はすんなり行えるのですが、場合によっては、Controller、Agentとの接続に障害が発生する可能性があります。

## 接続問題が発生する理由（目安）

※明確な動作を把握しているわけではないため、想定される内容での説明となります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2529537/a127a22a-3bc2-b223-b9c3-b35a25d5c0b6.png)

例えば 12時にDBバックアップ、15時にJOCがダウン、JOCを12時時点のデータで復元したとします。
この場合、12時以降、JOCがダウンする15時までの間も、JOC⇔Controller間で処理の実行、履歴収集などのやりとりが行われます。
JOCで保持している収集済みデータ（DBリストア内容）は12時時点ですが、Controllerで保持しているジャーナルデータは15時までの内容が更新済みであるため、JOC-Controller間で不整合が発生します。

同様のことが、Controller、Agentのリカバリー時でも発生します。<br />（もしくは新規セットアップ時はジャーナルに接続情報自体が入っていない）

この場合、接続問題が発生している箇所に応じて、リセット（ジャーナ初期化）の操作が必要となります。

- JOC - Controller 間の障害の場合<br /> → Controller,Agentにてリセットの対応が必要<br />（ControllerのリセットでAgnetとの整合性も崩れるため）
- Controller - Agent 間の障害の場合<br /> → Agentにてリセットの対応が必要<br />（JOC - Controller間の対応は不要）

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2529537/dd6568c9-d0b7-ee07-d122-11e83147d1f3.png)

:::note
ジャーナルデータの不整合が無ければ、特に問題なく通信が回復できます。この場合は以降の手順は不要です。
（計画メンテの場合、これを踏まえて、サービス停止することで、ジャーナル更新を防止する手段もあります）
:::

## JOC - Controller間の接続回復

JOCのDashboardより、Controllerの接続が確認できない場合の対応です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2529537/4b2dffd0-a3d3-ebab-bebf-a9cb76532504.png)

あらかじめ、JOC - Controller間の通信ができ、サービス起動状態も問題ないことを確認してください。
Controllerにて、サービスを停止、ジャーナルデータ削除、サービス起動をします。

※ジャーナルデータは`JS7_CONTROLLER_DATA/state`以下に生成されます。

```shell
# サービス名 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 の再起動を行ってください。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2529537/0bf37df8-d947-2184-91a8-37f6ab841638.png)

これで、Workflowのステータスや、ログが収集され、確認できるようになります。

## Controller - Agent間の接続回復

JOCのDashboardより、Agentの接続が確認できない場合の対応です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2529537/ac36c9c6-b7e2-30ef-fdaf-121d88a5ca4c.png)

---

あらかじめ、Controller－Agent間の通信ができ、サービス起動状態も問題ないことを確認してください。
また、必ず先にJOC - Controller 間の接続回復を済ませてください。

Manage Controllers and Agents より、該当エージェントを選択し、Reset Force を実行してください。<br  />（接続回復に1分程度かかります）
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2529537/b22cfffe-687f-0874-3af0-dc5ae9ef1e6e.png)

もしうまくいかない場合は、エージェントにて直接、サービスを停止、ジャーナルデータ削除、サービス起動をします。
※ジャーナルデータは`JS7_AGENT_DATA/state`以下に生成されます。

```shell
# サービス名 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新規登録時に行う操作と同じ)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2529537/321b9716-f542-7120-83aa-c18a390477b4.png)

Controller - Agent間の疎通は、これで回復するはずです。

# インベントリ情報の復元

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2529537/6b8bc9d9-0a98-db63-431d-7fa99aa2b4c8.png)

Controllerの接続復旧のためにリセット操作を行った場合、インベントリ情報も削除されます。
Workflowの画面を見ると、Statusが`not synchronized`となっており、実行できないことが分かります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2529537/cd875e76-825a-def8-e326-435b8efc6e0e.png)

この場合、Workflow、JobResourceなどのインベントリ情報は、改めてDeployを行ってください。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2529537/5507b8bc-976d-5970-06d9-d1700c2a904f.png)

Deploy後、動作テスト用に適当なWorkflowを実行して、正常に動作することを確認してください。

もしOrderの応答が返らない場合は、Controller、Agentのログを確認してください。
Agent側で実行されているにも関わらず、JOCに応答が返らない場合、history service の再起動が必要です。

# Order情報の対処

Controller、Agentでジャーナル初期化の操作を行った場合、ジャーナルデータに保存されたOrder情報も全て消去されます。<br />そのため、既存のOrderが実行済みか、未実行かをチェックし、状況に応じての対応が必要となります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2529537/4fa9ae48-8aa9-f648-9801-0f863e27a06a.png)

## 当日のOrder

まず、本来実行されるべきWorkflowが、どこまで実行完了しているか、確認してください。
`JS7_AGENT_DATA/logs/agent.log` で確認可能。もしくは処理に関連するシステム側でご確認ください。

ジャーナル初期化をすると、スケジュール済みのOrder情報もリセットされます。<br />そのため未実行のOrderについては、手動での対応が必要です。<br />手動でOrderを追加（即時、時刻指定など）、もしくはJS7を使わず直接必要スクリプトを実行でも可。

:::note warn
DailyPlan は、翌日以降しか作成できません。
そのため当日のOrderは、手動で実行する必要があります。
※9時以前の場合は（UTC日時で前日扱い）DailyPlanで当日Orderも作成可能です。その場合は次の「翌日以降」の手順を参考にしてください。
:::

## 翌日以降のOrder

DailyPlanでスケジュール実行をしている場合、翌日以降のOrderも登録しなおす必要があります。

まず、現在のSchedule済みOrderが全て消えていることを確認します。
※Agentのみリセットした場合は、すべてFailedとなります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2529537/25fe2339-f8ef-2a2f-0062-a6d51b279273.png)

既存のDailyPlanに登録されている、**翌日以降のOrderは全てキャンセル**します。
（登録されているOrderは、すべてFailedとなっている無効なOrderです）
※キャプチャの都合で翌月が見えないですが、翌月以降にOrderがある場合はそちらもキャンセル
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2529537/ba08eb00-30a9-ba72-b149-35e13de006a8.png)

さらに、**翌日以降のDailyPlanを削除**します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2529537/2c6c0d98-68a8-b216-d942-edda4fa25f98.png)

DailyPlanサービスの再起動で、翌日以降のDailyPlanを再作成します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2529537/64a74d55-35c7-1bb4-fce3-dac08b1d81b1.png)

翌日以降のScheduleが追加されたことを確認してください。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2529537/72ce64be-6374-e107-8a42-c33aa7e6f6cc.png)

:::note alert
単に既存のOrderをキャンセル/Submitted Order（またはDailyPlan再起動）の操作では、Orderが登録されないケースがあります。
この操作では、OrderIdが変わらず、このOrderIdは既にステータスFailedとなっているためです。
必ず既存のDailyPlanを削除し、作り直してください。
<br />※厳密にはControllerはリセットせず、Agentのみリセットした場合に発生する問題です。
:::

# 【補足】データの欠損について

本記事で説明したリセット操作を行った場合、未収集Order情報の欠損を避けることはできません。
たとえWorkflowが実行済みであっても、JOC側ではログは残りません。
データ欠損を避けたい場合は、JS7のHA構成を検討してください。（有償ライセンス）

# 最後に

本記事は、本稼働を行うためには是非おさえておきたい内容です。
理解をするのは大変ですが、大袈裟なリカバリーに限らず、サーバー入れ替え時をはじめ、随所で利用できる知識となります。
本記事の内容の内容が、本番利用の検討や、適切なバックアップ計画などのお役位立てれば幸いです。

# 参考

[JS7 - How to troubleshoot Controller journals](https://kb.sos-berlin.com/display/JS7/JS7+-+How+to+troubleshoot+Controller+journals)
[JS7 - How to troubleshoot Agent journals](https://kb.sos-berlin.com/display/JS7/JS7+-+How+to+troubleshoot+Agent+journals)
[JS7 - How to backup the job scheduling environment](https://kb.sos-berlin.com/display/JS7/JS7+-+How+to+backup+the+job+scheduling+environment)