Hitachi

JP1 Version 12 JP1/Automatic Job Management System 3 運用ガイド


11.2.3 メインサイトに運用を切り戻す

ここでは,メインサイトを再構築したあと,メインサイトでの運用を再開する手順について説明します。メインサイトでの運用再開は,次の流れで実施します。

図11‒18 メインサイトでの運用再開の流れ

[図データ]

〈この項の構成〉

(1) 運用再開の作業

運用再開を実施する前の作業と運用を再開する手順を説明します。

注意事項
  • ここで説明する手順は,メインサイトとリモートサイトの論理ホスト名が同一名の場合も別名の場合も,共通です。

  • メインサイトとリモートサイトの論理ホスト名が同一名の場合,手順の中でコマンドの引数として指定する「リモートサイトの論理ホスト名」は,メインサイトの論理ホスト名と同一です。

(a) 運用再開を実施する前の作業

JP1/Baseの論理ホストをJP1/AJS3の論理ホストと同じ共有ディスクで使用する場合は,メインサイトでの運用を再開する手順を実施する前にJP1/Baseの作業が必要です。メインサイトとリモートサイトで,論理ホスト名とIPアドレスが一致するかによって,必要となるJP1/Baseの作業手順が異なります。

それぞれの場合の作業について説明します。なお,JP1/Baseの論理ホストをJP1/AJS3の論理ホストと同じ共有ディスクで使用できるのは,JP1/BaseをJP1/AJS3だけの前提製品として使用する場合だけです。

■ メインサイトとリモートサイトの論理ホスト名およびIPアドレスが同一の場合

イベントDBを引き継ぐ場合は,JP1/Baseの作業は必要ありません。ただし,イベントDBが破損しているおそれがあります。状況によっては,復旧作業が必要になります。統合トレースログに出力されるメッセージごとに対処方法が記載されているので,手順に従って復旧作業をしてください。イベントDBを引き継がない場合は,「KAJP1059-Eが出力されたとき」の手順に従ってイベントDBを初期化してください。

KAJP1059-Eが出力されたとき

イベントDBが破損しているため,イベントサービスの起動ができません。次のコマンドを実行して,イベントDBを初期化してください。初期化することで,イベントDBの情報は失われます。

jevdbinit {-b | -n}

jevdbinitコマンドを実行すると,イベントDBが,削除されたあとに再作成されます。イベントDB内の通し番号は,削除前のイベントDB内の通し番号を引き継ぎます。初期化前に破損しているイベントDBをバックアップしたい場合は,-bオプションを,バックアップしない場合は-nオプションを指定してください。バックアップしたデータベースの内容は,jevexportコマンドでcsvファイルに出力して確認できます。jevdbinitコマンド,およびバックアップしたデータベースの詳細については,マニュアル「JP1/Base 運用ガイド」のjevdbinitコマンドの説明を参照してください。

なお,jevdbinitコマンド実行時に,イベントDB内の通し番号が引き継げない場合は初期化に失敗します。メッセージKAJP1789-Eが出力された場合は,次のように-sオプションで指定する開始番号に0を指定してイベントDBを再作成してください。

jevdbinit -s 0 {-b | -n}
KAJP1057-W,KAJP1058-Wが出力されたとき

イベントDBに不正なレコードがあり,検索性能が劣化するおそれがあります。再起動のタイミングで,「KAJP1059-Eが出力されたとき」の手順に従ってイベントDBを初期化してください。

KAJP1075-Wが出力されたとき

重複防止テーブルが不整合な状態です。イベントサービスを停止してから,jevdbmkrepコマンドを実行して重複防止テーブルを再構築してください。jevdbmkrepコマンドの詳細については,マニュアル「JP1/Base 運用ガイド」のjevdbmkrepコマンドの説明を参照してください。

■ メインサイトとリモートサイトの論理ホスト名が同一でIPアドレスが異なる場合

次に示す作業を実施してください。

  • 論理ホストのIPアドレスの変更に伴うJP1/Baseの設定変更作業

  • JP1/BaseのイベントDBの初期化

JP1/Baseの設定変更作業については,マニュアル「JP1/Base 運用ガイド」のIPアドレス変更時の作業を参照してください。JP1/BaseのイベントDBの初期化については,「メインサイトとリモートサイトの論理ホスト名およびIPアドレスが同一の場合」の「KAJP1059-Eが出力されたとき」の手順を参照してください。

■ メインサイトとリモートサイトで論理ホスト名およびIPアドレスが異なる場合

次に示す作業を実施してください。

  • 論理ホストのホスト名とIPアドレスの変更に伴うJP1/Baseの設定変更作業

  • JP1/BaseのイベントDBの初期化

JP1/Baseの設定変更作業については,マニュアル「JP1/Base 運用ガイド」のホスト名変更時の作業やIPアドレス変更時の作業を参照してください。JP1/BaseのイベントDBの初期化については,「メインサイトとリモートサイトの論理ホスト名およびIPアドレスが同一の場合」の「KAJP1059-Eが出力されたとき」を参照してください。

(b) 運用再開手順

メインサイトで運用を再開する手順を次に示します。なお,非クラスタ環境の場合は,実行系での作業だけを実施してください。

  1. リモートサイトの実行系および待機系でジョブを実行していないことを確認する。

    実行中のジョブがないことを確認します。

    異なるスケジューラーサービス間の実行順序を制御しているジョブネットコネクタ,およびジョブネットコネクタの転送先ホストの該当するジョブネットも終了させておいてください。

  2. リモートサイトの実行系および待機系でJP1/AJS3 - Managerを停止する。

    リモートサイトのキューレスエージェントサービスに論理ホストをアタッチ(接続)している場合は,次のコマンドを実行してデタッチ(切断)してください。

    ajsqldetach -h リモートサイトの論理ホスト名 -k

    ajsqldetachコマンドの詳細については,マニュアル「JP1/Automatic Job Management System 3 コマンドリファレンス 4. 特別な運用で使用するコマンド ajsqldetach」を参照してください。

    JP1/AJS3 - Managerを停止したら,ハードウェアの操作で共有ディスク間のコピーを停止し,メインサイトでメインボリュームが書き込みできる状態にします。

  3. メインサイトの実行系で,メインサイトとして運用する論理ホストを設定する。

    次のコマンドを実行します。

    jajs_rpsite -m CHANGE -h メインサイトの論理ホスト名

    メインサイトの定義を変更したら,ハードウェアの操作で,メインサイトからリモートサイトへのコピーを開始します。

  4. メインサイトとリモートサイトの論理ホストが別名の場合,イベント・アクション制御エージェントが記憶するリモートサイトの論理ホスト名を削除する。

    この手順は,メインサイトとリモートサイトの論理ホストが別名の場合にだけ実施します。

    リモートサイトの論理ホスト自身に対してイベントジョブを実行していた場合,論理ホスト上のイベント・アクション制御エージェントにリモートサイトの論理ホスト名が記憶されます。

    そのため,メインサイトとリモートサイトの論理ホスト名が別名の場合は,運用切り戻し時に,メインサイトの論理ホスト上のイベント・アクション制御エージェントからリモートサイトの論理ホスト名を削除する必要があります。

    共有しているエージェントまたはメインサイトの論理ホスト上で,次の操作を実行してください。

    (1) イベント・アクション制御エージェントが記憶するマネージャーホスト名の一覧を表示する。

    イベント・アクション制御エージェントにリモートサイトの論理ホスト名が記憶されているかどうかを確認するため,次のコマンドを実行します。

    メインサイトの論理ホスト上で実行する場合:

    jpoagoec -p -h メインサイトの論理ホスト名

    共有しているエージェント(物理ホスト)上で実行する場合:

    jpoagoec -p

    共有しているエージェント(論理ホスト)上で実行する場合:

    jpoagoec -p -h 論理ホスト名

    (2) (1)で表示した一覧にリモートサイトの論理ホスト名がある場合,次のコマンドを実行する。

    メインサイトの論理ホスト上で実行する場合:

    jpoagoec -d リモートサイトの論理ホスト名 -h メインサイトの論理ホスト名

    共有しているエージェント(物理ホスト)上で実行する場合:

    jpoagoec -d リモートサイトの論理ホスト名

    共有しているエージェント(論理ホスト)上で実行する場合:

    jpoagoec -d リモートサイトの論理ホスト名 -h 論理ホスト名

    jpoagoecコマンドの詳細については,マニュアル「JP1/Automatic Job Management System 3 コマンドリファレンス 3. 通常の運用で使用するコマンド jpoagoec」を参照してください。

  5. QUEUEジョブ,サブミットジョブ実行環境データベースのISAMファイルの状態を確認し,必要に応じて再作成する。

    標準構成で運用している場合,リモートサイトにコピーされたISAMファイルが正常な状態かどうかを確認する必要があります。ISAMファイルの状態を確認する方法については,マニュアル「JP1/Automatic Job Management System 3 トラブルシューティング 2.11.1 ISAMファイルの状態確認手順」を参照してください。

    ISAMファイルの状態が不正だと,ジョブの起動に失敗するなどの問題が発生し,リモートサイトでの運用が継続できないおそれがあります。その場合は,マニュアル「JP1/Automatic Job Management System 3 トラブルシューティング 2.11.2 QUEUEジョブ,サブミットジョブの実行環境データベースの再作成手順」を参照して,ISAMファイルを再作成してください。ただし,JP1/AJS3サービスの再起動方法については,次の手順に従ってください。

  6. メインサイトの実行系で,JP1/AJS3 - Managerをディザスターリカバリースタートする。

    ディザスターリカバリースタートとは,ジョブの実行を抑止した状態でJP1/AJS3 - Managerを起動することです。

    JP1/AJS3 - Managerをディザスターリカバリースタートするには,次の操作を実行します。

    Windowsの場合

    JP1/AJS3のスタートアップパラメーターに-disasterを指定して実行します。JP1/AJS3の起動時の動作を一時的に変更する方法については,「6.2.1 JP1/AJS3起動時の動作を一時的に変更する」を参照してください。

    UNIXの場合

    次のコマンドを実行します。

    jajs_spmd -h メインサイトの論理ホスト名 -disaster

    jajs_spmdコマンドの詳細については,マニュアル「JP1/Automatic Job Management System 3 コマンドリファレンス 3. 通常の運用で使用するコマンド jajs_spmd」を参照してください。

    なお,拠点を切り戻したあとの初回サービス起動時は,ホットスタートまたはウォームスタートで起動した場合でも,自動的にディザスターリカバリースタートに変更して起動します。

  7. メインサイトの実行系で,JP1/AJS3 - Managerをディザスターリカバリースタートしたあとに必要な作業を実施する。

    メインサイトで運用するために,実行エージェントの定義をメインサイト環境に合わせたり,ジョブの状態を確認したりする必要があります。

    メインサイトのJP1/AJS3 - Managerをディザスターリカバリースタートしたあとに必要な作業は,リモートサイトへの運用に切り替える場合にJP1/AJS3 - Managerの起動後に必要な作業と同様です。「11.2.1(2) JP1/AJS3 - Manager起動後の作業」を参照して,メインサイトでの運用に合わせて設定してください。

  8. メインサイトの実行系で,ジョブの実行抑止を解除する。

    次のコマンドを実行して,ジョブの実行抑止を解除します。

    ajsalter -s none -F スケジューラーサービス名

    ジョブの実行抑止を解除したら,メインサイトで業務を再開してください。