こんにちは、SCSKの前田です。
私が携わった LifeKeeper の案件で導入を行った ARK について紹介をかねてお話したいと思います。
今回は、日立製作所から提供されているジョブ管理製品である JP1/AJS3 を簡単に冗長化するための ARK の導入事例をご紹介していきます。
おさらい
LifeKeeper の ARK について、おさらいしたいと思います。
ARK とは、Application Recovery Kits の略で、LifeKeeper が特定のアプリケーション（オープンソースソフトウェアや商用アプリケーション）を容易にリソースとして組み込むことが可能になる製品です。
ARK による、アプリケーションのリソースへの組み込みはウィザード形式（GUI 上で設定）で作業が可能となり、ARK には、アプリケーションを操作（起動・停止・監視・再起動）するための4つのスクリプトがあらかじめ準備されているため、スクリプトを設計・作成するための開発工数の削減や人的なミスを防止することが出来ます。
概要説明
JP1/AJS3 の ARK としては、下記の通り大きく2つの種類があります。
① Generic ARK for JP1/AJS3 Manager
「JP1/Base」と「JP1/Automatic Job Management System 3」(略称：JP1/AJS3)の「Manager」を，LifeKeeper の保護対象リソースとして登録し，保護する機能を提供します。
② Generic ARK for JP1/AJS3 Agent
「JP1/Base」と「JP1/Automatic Job Management System 3」(略称：JP1/AJS3)の「Agent」を，LifeKeeper の保護対象リソースとして登録し，保護する機能を提供します。
JP1/AJS3 ARK は、汎用アプリケーション(Generic Application)リソースとして導入されます。
おさらいでお伝えした通り、「JP1/Base」と「JP1/Automatic Job Management System 3」のそれぞれを操作するため、起動・停止・監視・再起動を行うためのスクリプトが準備されており、リソース作成時にこれらのスクリプトを設定していきます。
この4つのスクリプトのうち、起動と停止は必須で、監視と再起動は任意となり、JP1製品の監視や再起動を実施する要件がなければ、対象のスクリプトを設定する必要もありません。
監視と再起動を導入しなければ、LifeKeeper として JP1/AJS3 の障害を検知することはなく、フェイルオーバーの対象にもなりません。また、監視は行うが、再起動は行わないことも出来ます。ただ、監視は行わず、再起動のみ行うことは出来ません。あくまでも監視で異常と検知された場合のみ、再起動が有効になります。
JP1/ASJ3 ARKを導入するための条件
JP1 が使用する共有ディスクリソースと，JP1 の論理ホスト名に紐づく仮想 IP リソースは、別で作成しておく必要があります。また、JP1 リソース作成後、共有ディスクリソースと仮想 IP リソースに対する依存関係を手動で設定する必要があります。
JP1/ASJ3 ARK の構築例
それでは、実際に JP1/AJS3 ARK の構築についてお話していきたいと思います。
スクリプトの修正
まずは、「JP1/Base」と「JP1/Automatic Job Management System 3」を操作するため、利用する全てのスクリプトを修正する必要があります。
スクリプトのパラメータ変更
次の変更可能なパラメータのうち、必要なパラメータを修正します。
※下記パラメータ以外を変更してしまうとサポートが受けられなくなりますので注意してください。
＜Windows版＞
| 内容 | パラメータ名 | 設定条件 |
|---|---|---|
| リソースタグ名 | APP | 任意 |
| 論理ホスト名 | VHOSTNAME | 必須 |
| JP1環境変数 | JP1PATH | 任意 |
| タイムアウト値（処理待ち時間） | DEFAULT_TIMEOUT | 任意 |
| タイムアウト値（後処理の待ち時間） | HANDLE_STOP_TIMEOUT | 任意 |
| 処理モード（※１） | PROCESS_MODE | 任意 |
※１：停止スクリプトのみ提供されるパラメーター
＜Linux版＞
| 内容 | パラメータ名 | 設定条件 |
|---|---|---|
| リソースタグ名 | APP | 任意 |
| 論理ホスト名 | VHOSTNAME | 必須 |
| タイムアウト値（処理待ち時間） | DEFAULT_TIMEOUT | 任意 |
| タイムアウト値（後処理の待ち時間） | HANDLE_STOP_TIMEOUT | 任意 |
| 待機時間（※２） | APP_FORCE_STOP_WAIT_TIME | 任意 |
※２：監視スクリプトは設定不要なパラメーター
(1)リソースタグ名(APP)の変更
リソースタグ名は保護対象リソースを一意に識別するための名称です。デフォルトで設定がされていますが、案件ごとに命名規則がありますので、案件にあったリソースタグ名に変更する必要があります。
(2)論理ホスト名(VHOSTNAME)の変更
論理ホスト名は JP1/AJS3 ARK で唯一の必須となるパラメータです。クラスタ環境（論理ホスト上）でJP1製品のコマンドを実行するため、論理ホスト名が必要になります。JP1/AJS3 ARK の各スクリプトでもJP1製品のコマンドを実行するため、必要不可欠なパラメータとなります。
(3)JP1環境変数(JP1PATH)の変更 ※Windows版のみ
JP1環境変数は JP1 製品のコマンドを実行するためのパス名です。各スクリプトにはJP1製品のデフォルトのインストールパス名があらかじめ記載されており、明示的にインストールパスを変更してJP1製品をインストールする場合、このJP1環境変数を変更する必要があります。
(4)タイムアウト値(DEFAULT_TIMEOUT,HANDLE_STOP_TIMEOUT)の変更
タイムアウト値は各スクリプトに設定するタイマー監視用の値です。各スクリプトで実行した JP1 製品のコマンドが無応答となった場合、設定したタイムアウト値によってタイマー監視を行い、各スクリプトを終了させます。
基本的には変更することはありませんが、処理時間が遅いだけで問題もなく各スクリプトがタイムアウトとなってしまう場合、環境に合わせ変更する必要があります。
(5)処理モード(PROCESS_MODE)の設定 ※Windows版の停止スクリプトのみ
処理モードはJP1製品の停止処理が失敗した場合における、後続処理の続行可否を判断するためのパラメータです。
処理モードが「0」：JP1製品の停止コマンドが失敗した場合、異常終了と判断し、フェイルオーバーが中断されます。
処理モードが「1」：JP1製品の停止コマンドが失敗した場合、正常終了と判断し、フェイルオーバーが継続されます。
※デフォルト値は「1」になります。
(6)待機時間(APP_FORCE_STOP_WAIT_TIME)の変更 ※Linux版の監視スクリプト以外
待機時間は各スクリプトで実行される JP1 製品の2重起動防止を目的とした強制停止コマンドの終了を待機する時間の値です。
JP1製品の強制停止コマンドの一部処理がバックグラウンドで実施され、待機時間を経過しても終了せず、その後の JP1 製品の開始に失敗することがある場合、デフォルトの5秒から変更する必要があります。
JP1/ASJ3 関連リソースの作成
前述の通り、JP1/AJS3 ARK では「JP1/Base」と「JP1/Automatic Job Management System 3」（Manager または Agent）のリソースを作成することが可能です。
この2つのリソースを LifeKeeper の GUI によって作成する流れを環境毎に例として紹介します。
＜Windows版＞
| 処理内容 | JP1/Base | JP1/Automatic Job Management System 3 |
|---|---|---|
| リソース作成前のツリー構造 |  |
|
| 冗長化対象ノードの選択 |  |
 |
| 保護アプリケーションの選択（汎用アプリケーション） |  |
 |
| Restore（起動）スクリプトの入力 |  |
 |
| Remove（停止）スクリプトの入力 |  |
 |
| QuickCheck（監視）スクリプトの入力 |  |
 |
| DeepCheck（詳細な監視）スクリプトの入力 ※対象無し |
 |
 |
| LocalRecovery（再起動）スクリプトの入力 |  |
 |
| アプリケーション情報の入力 ※入力無し |
 |
 |
| LocalRecoveryの有無の選択 ※デフォルト：有効 |
 |
 |
| リソースタグ名の入力 |  |
 |
| 稼働系ノードのリソース作成結果 |  |
 |
| 待機系ノードのリソース作成準備の確認結果 |  |
 |
| 待機系ノードの優先順位の設定 ※デフォルト：10 |
 |
 |
| 待機系ノードのリソース作成結果 |  |
 |
| リソース作成後のツリー構造 |  |
|
＜Linux版＞
| 処理内容 | JP1/Base | JP1/Automatic Job Management System 3 |
|---|---|---|
| リソース作成前のツリー構造 |  |
|
| 保護アプリケーションの選択（Generic Application） |  |
 |
| 稼働系ノードのSwitchbackタイプの選択 ※デフォルト：intelligent |
 |
 |
| 稼働系ノードの選択 |  |
 |
| Restore（起動）スクリプトの入力 |  |
 |
| Remove（停止）スクリプトの入力 |  |
 |
| QuickCheck（監視）スクリプトの入力 |  |
 |
| LocalRecovery（再起動）スクリプトの入力 |  |
 |
| 稼働系ノードのアプリケーション情報の入力 ※入力無し |
 |
 |
| リソース作成時の起動有無の選択 |  |
 |
| 稼働系ノードのリソースタグ名の入力 |  |
 |
| 稼働系ノードのリソース作成結果 |  |
 |
| 待機系ノードの選択 |  |
 |
| 待機系ノードのSwitchbackタイプの選択 ※デフォルト：intelligent |
 |
 |
| 稼働系ノードの優先順位の設定 ※デフォルト：1 |
 |
 |
| 待機系ノードの優先順位の設定 ※デフォルト：10 |
 |
 |
| 待機系ノードのリソース作成準備の確認結果 |  |
 |
| 待機系ノードのリソースタグ名の入力 |  |
 |
| 待機系ノードのアプリケーション情報の入力 ※入力無し |
 |
 |
| 待機系ノードのリソース作成結果 |   |
  |
| リソース作成後のツリー構造 |  |
|
これで、LifeKeeper による JP1/AJS3 製品 のリソースが完成です。
依存関係の作成
「JP1/Base」と「JP1/Automatic Job Management System 3」（Manager または Agent）のリソースを作成した後、全リソースの起動（停止）する順序を定義するため、リソース間の依存関係（リソースツリーの下から起動され、上から停止される）を作成する必要があります。
例として、別で作成していた共有ディスクリソースと，仮想 IP リソースを始めに起動させるようリソースツリーの下部に配置させ、その後に JP1/Base、JP1/AJS3 の順番で起動させるように依存関係を作成します。
| 処理内容 | Windows版 | Linux版 |
|---|---|---|
| 依存関係作成前のツリー構造 |  |
 |
| JP1/Baseリソースの依存関係作成後 |  |
 |
| JP1/AJS3リソースの依存関係作成後 |  |
 |
これで、JP1/AJS3 製品に関連する LifeKeeper によるリソース構成ツリーの完成です。
まとめ
今回は LifeKeeper ARK の導入事例と言うことで、JP1/AJS3 製品のリソース作成について紹介してみました。
JP1/AJS3 ARK を購入することで、正式なサポートを受けられるほか、LifeKeeper として JP1/AJS3 を操作（起動・停止・監視・再起動）するための4つのスクリプトがあらかじめ準備されており、必要最低限の修正だけで簡単にリソースとして導入が可能となっています。
LifeKeeper では JP1/AJS3 以外にも多数の ARK が用意されていますので、また次の機会に別の ARK について紹介していきたいと思います。
最後に JP1/AJS3 ARK を導入するための手順を纏めます。
・LifeKeeper GUI を用いて、JP1/Base と JP1/AJS3 のリソースを作成する
・共有ディスクリソースと仮想 IP リソース含め、リソースの起動順序を定義するため依存関係を作成する
