１．ありがちな定常ジョブネットワークを構築
1-1.盛り込むこと（ポイント）
・「ジョブグループ－ルートジョブネット－ネストジョブネット－ジョブ」のように階層構造にする
※親ジョブグループ－子ジョブグループ（複数）ってする
※ルートジョブネット－ネストジョブネット（複数）ってする
・別のジョブネットにイベントを送信する「イベント送信ジョブ」を含める
・別のジョブネットからイベントを受信する「イベント受信ジョブ」を含める
・何をするときにどのリソースをどのくらい使うか？
リソースはメモリとCPU
1-2.構築
・ジョブグループ
※ジョブグループはカレンダー情報を保有するユニット
・カレンダー
- 複数のカレンダーの合成
・ルートジョブネット
- 日時指定
・スケジュール
- 複数のスケジュールの使い分け
- 複数のスケジュールの合成
・ネストジョブネット
・UNIXジョブ
- 待ち合わせ実行とは
- 分岐と合流
-
1-3.テスト
・
２．1．で作成した定常ジョブネットワークを操作してみる
※「実行制御」は下記のとおり
①実行登録、②実行登録解除、③遅延監視一時変更、④計画日時変更（日時変更）、⑤計画一時変更（即時実行）、⑥計画一時変更（実行中止）、⑦保留、⑧保留解除、⑨優先順位の一時変更、⑩中断、⑪強制終了、⑫再実行、⑬状態変更
※「状態」は下記の通り
未登録、開始時刻待ち、先行終了待ち、保留中、実行待ち、未実行終了（実行予定なし）、未実行終了（実行予定あり）、計画未実行、実行中、キューイング、異常検出実行中、異常警告検出実行中、正常終了、警告検出終了、異常検出終了、繰越未実行（実行予定なし）、繰越未実行（実行予定あり）、順序不正、中断、強制終了、起動失敗、終了状態不明、閉塞、開始遅延、ネスト開始遅延、終了遅延、ネスト終了遅延
2-1.保留からの再実行
2-2.ジョブネットを中断してスケジュール一時変更して再開して翌日に元のスケジュールに戻す
・
2-3.実行中止して一日分スキップして2日後から平常に実行
2-4.ジョブをわざとこけさせて次のジョブから実行
2-5.ジョブをわざとこけさせてジョブスクリプトを修正後こけたジョブから再開
2-6.予定通り終わらないジョブを強制終了して次のジョブから再開
2-7.開始遅延監視検証
・ノーマルな遅延監視
・遅延開始一時変更からの戻し
2-8.終了遅延監視検証
・ノーマルな遅延監視
・遅延開始一時変更からの戻し
2-9.監視静観
2-10.強制停止
■ジョブのフォアグラウンドプロセスへの強制終了
→強制終了が発行された時点までの処理が完了し発行以後の処理が未済になることを確認
■ジョブのバックグラウンドプロセスへの強制終了
→強制終了が発行された後も処理が最後まで完了してから子プロセスが終了することを確認
３．１．で作成したジョブネットワークを別のJP1/AJS3マネージャホストに移行する
3-0.バックアップとリストア
■ジョブグループ1のリソースを別のジョブグループ2にコピー（バックアップ&リストア）
・操作
・動作確認
■JP1/AJS3のエクスポートとかインポートのような機能でリソースのバックアップとリストア
・操作
・動作確認
3-1.単純移行
3-2.ホスト名とIPアドレスを変更して移行
3-3.
4．通信やプロセスに関して2～3のリバースエンジニアリングもどき
4-1.マネージャホストとエージェントホスト間の通信を覗く
マネージャとエージェントのファイアウォールの透過方向（=通信の方向とport番号一覧）
4-2.プロセスにメスを入れてみる
・UNIXジョブの環境変数調査
・UNIXジョブの実行ユーザ調査
- トラバースできるディレクトリ、できないディレクトリ
- 書き込めるディレクトリ、できないディレクトリ
・フォアグランド実行するジョブ
・バックグラウンド実行するジョブ（振り逃げジョブ）
・主なプロセスに関してlsofしてみる
・メモリやFDの使い方が気になるプロセスをstraceしてみる
4-3.変なカーネルモジュールの使い方してるプロセスは居るか？
4-4.変なライブラリとリンクしてるプロセスは居るか？
4-5.変なプロセス間通信してるプロセスは居るか？
・共有メモリ
・パイプ
・ソケット
・その他
4-6.ログの種類と持ち方
4-7.スケジューラサービスのリバースエンジニアリングもどき
※エージェントホストがマネージャホストの名前解決に失敗してエージェントからマネージャへジョブ終了通知が届かなかった際に一定期間マネージャ側でキューイングされていた。
途中で通信断があった際にジョブの状態はタイムアウトまで（もし設定されていれば）キューイングされるっぽい。
→どこにキューが居るのか？ジョブマネージャもメールサーバやプリンタサーバやメッセージキューのようにメッセージや文書のロストを防ぐのと同様にジョブの状態の情報をロストしないように先入先出なキューが居るんだよね（たぶん）
→ジョブスケジューラがロスとしてはいけないのはマネージャ⇔エージェント間で取り交わされる情報のうち何？ マネージャから→エージェントは実行命令？ エージェントからマネージャは実行結果？ ジョブスケジューラにとってすべてのユニットの状態が「未確定」であることは許されない？ 成功、失敗、実行中、キューイング中、・・・など必ず状態が確定する必要がある？ ジョブスケジューラでもっともやってはいけないことはジョブの多重実行、ジョブ実行漏れ、ジョブ状態通知ミス、ジョブ結果通知ミス？ほかに何？ もし2重実行してはいけないプロセスを2重実行してしまったらホスト上のデータやシステムを破損しかねない
契約上その日にやらなければならないジョブは確実に正しくやれてる必要がある一方、万一異常があった場合には確実に把握される必要がある？ 正しくやれるというのはただ実行すればいいだけじゃなくて順序性が定義通り守られたうえで実行される必要がある
これらのジョブスケジューラに求められる要件を満たすためにジョブスケジューラにはいろいろな七面倒くさい仕様があるのだと思う。てへぺろ。
5.イベントジョブの動作を調べる
5-1.JP1イベント受信監視ジョブ
5-2.ファイル監視ジョブ
5-3.ログファイル監視ジョブ
5-4.実行間隔制御ジョブ
----これ以降はやれればやる----
6.JP1/AJS3 Managerクラスタ構成
6-1.設計
6-2.構築
6-3.動作確認
■TKOしてみる
■
１．ありがちな定常ジョブネットワークを構築
1-1.盛り込むこと（ポイント）
・「ジョブグループ－ルートジョブネット－ネストジョブネット－ジョブ」のように階層構造にする
※親ジョブグループ－子ジョブグループ（複数）ってする
※ルートジョブネット－ネストジョブネット（複数）ってする
・別のジョブネットにイベントを送信する「イベント送信ジョブ」を含める
・別のジョブネットからイベントを受信する「イベント受信ジョブ」を含める
・何をするときにどのリソースをどのくらい使うか？
リソースはメモリとCPU
1-2.構築
・ジョブグループ
・カレンダー
- 複数のカレンダーの合成
・ルートジョブネット
- 日時指定
・スケジュール
- 複数のスケジュールの使い分け
- 複数のスケジュールの合成
・ネストジョブネット
・UNIXジョブ
- 待ち合わせ実行とは
- 分岐と合流
-
1-3.テスト
・
２．1．で作成した定常ジョブネットワークを操作してみる
2-1.保留からの再実行
2-2.ジョブネットを中断してスケジュール一時変更して再開して翌日に元のスケジュールに戻す
・
2-3.実行中止して一日分スキップして2日後から平常に実行
2-4.ジョブをわざとこけさせて次のジョブから実行
2-5.ジョブをわざとこけさせてジョブスクリプトを修正後こけたジョブから再開
2-6.予定通り終わらないジョブを強制終了して次のジョブから再開
2-7.開始遅延監視検証
・ノーマルな遅延監視
・遅延開始一時変更からの戻し
2-8.終了遅延監視検証
・ノーマルな遅延監視
・遅延開始一時変更からの戻し
2-9.監視静観
2-10.
３．１．で作成したジョブネットワークを別のJP1/AJS3マネージャホストに移行する
3-0.バックアップとリストア
■ジョブグループ1のリソースを別のジョブグループ2にコピー（バックアップ&リストア）
・操作
・動作確認
■JP1/AJS3のエクスポートとかインポートのような機能でリソースのバックアップとリストア
・操作
・動作確認
3-1.単純移行
3-2.ホスト名とIPアドレスを変更して移行
3-3.リグレ環境でテスト後ホスト名等を変えて本番環境にジョブネットワーク資源をリリース
4．通信やプロセスに関して2～3のリバースエンジニアリングもどき
4-1.マネージャホストとエージェントホスト間の通信を覗く
マネージャとエージェントのファイアウォールの透過方向（=通信の方向とport番号一覧）
4-2.プロセスにメスを入れてみる
・主なプロセスに関してlsofしてみる
・メモリやFDの使い方が気になるプロセスをstraceしてみる
4-3.変なカーネルモジュールの使い方してるプロセスは居るか？
4-4.変なライブラリとリンクしてるプロセスは居るか？
4-5.変なプロセス間通信してるプロセスは居るか？
・共有メモリ
・パイプ
・ソケット
・その他
4-6.ログの種類と持ち方
4-7.スケジューラサービスのリバースエンジニアリングもどき
※エージェントホストがマネージャホストの名前解決に失敗してエージェントからマネージャへジョブ終了通知が届かなかった際に一定期間マネージャ側でキューイングされていた。
途中で通信断があった際にジョブの状態はタイムアウトまで（もし設定されていれば）キューイングされるっぽい。
→どこにキューが居るのか？ジョブマネージャもメールサーバやプリンタサーバやメッセージキューのようにメッセージや文書のロストを防ぐのと同様にジョブの状態の情報をロストしないように先入先出なキューが居るんだよね（たぶん）
→ジョブスケジューラがロストしてはいけないのはマネージャ⇔エージェント間で取り交わされる情報のうち何？ マネージャから→エージェントは実行命令？ エージェントからマネージャは実行結果？ ジョブスケジューラにとってすべてのユニットの状態が「未確定」であることは許されない？ 成功、失敗、実行中、キューイング中、・・・など必ず状態が確定する必要がある？ ジョブスケジューラでもっともやってはいけないことはジョブの多重実行、ジョブ実行漏れ、ジョブ状態通知ミス、ジョブ結果通知ミス？ほかに何？ もし2重実行してはいけないプロセスを2重実行してしまったらホスト上のデータやシステムを破損しかねない
契約上その日にやらなければならないジョブは確実に正しくやれてる必要がある一方、万一異常があった場合には確実に把握される必要がある？ 正しくやれるというのはただ実行すればいいだけじゃなくて順序性が定義通り守られたうえで実行される必要がある
これらのジョブスケジューラに求められる要件を満たすためにジョブスケジューラにはいろいろな七面倒くさい仕様があるのだと思う。てへぺろ。
5.イベントジョブの動作を調べる
5-1.JP1イベント受信監視ジョブ
5-2.ファイル監視ジョブ
5-3.ログファイル監視ジョブ
5-4.実行間隔制御ジョブ
----これ以降はやれればやる----
6.JP1/AJS3 Agenthostクラスタ構成
6-1.設計
■論理ホスト
■物理ホスト
6-2.構築
■論理ホストと物理ホストが共存するジョブネットワーク
※例えばデータバックアップは共有ディスク（共有ディスク方式の場合）にアクセス権がある方のノード（アクティブな論理ホスト）上でジョブを実行する
一方、システムバックアップはプライマリホストとセカンダリホストの両方のホスト（物理ホスト）上のジョブを実行する。
6-3.動作確認
■TKOしてみる
■
