前回は、AWS上のLifeKeeper for Linux（以降、LifeKeeperと記載）とHULFTを連携させて、リソース階層に登録された三つのリソースがフェールオーバーされることを確認しました。
これらは専用のRecovery Kitを導入してGUIでリソース階層までを作成しましたが、今回は専用スクリプトを用いて、JP１を冗長化したいと思います。
具体的には、JP1/Base（以降、Baseと記載）、JP1/AJS（以降、AJSと記載）を各インスタンスに導入し、共有ファイルシステム配下を指定した論理ホストを作成します。
その後、Base・AJSの制御スクリプトをLifeKeeperへ登録し、手動でリソース階層を設定する流れとなります。なお、AJSは導入サーバーのホスト名を32バイト以内とする制限事項があり、AWSのデフォルトで付与されるホスト名だと制限に触れることから、インスタンスを作り直しホスト名を変更しています。
インフラ環境について
今回は「AWS上にLifeKeeper for Linux を導入してみた」にホスト名変更の手順を加えて、環境を構築しています。基本的な環境の詳細については、以下の記事をご確認ください。
AWS上のインスタンスのホスト名変更については、以下をご確認ください。
また、実際にサービス提供環境などにJP1 Recovery Kitを導入する際は、同梱されている管理ガイドを参照して構築するようにしてください。
環境設定
BaseとAJSの設定は以下となります。
| 項目 | 設定内容 |
| Baseバージョン | JP1/Base 11-10 |
| AJSバージョン | JP1/Automatic Job Management System 3 |
| 認証サーバー | 論理ホスト |
| 論理ホスト | 仮想IPアドレスと関連付けた任意のホスト名 |
| 論理ホスト情報格納ディレクトリ | /data配下 |
構成イメージ
環境イメージは以下となります。
Clustering subnet A/Bで起動した各インスタンスに導入したBase・AJSは論理ホストにて起動し、環境設定ファイルの格納領域（ディレクトリ）は”/data/jp1base/”もしくは、”/data/jp1ajs2/”となります。
“/data”配下はLifeKeeperのData Replication機能を利用した共有ファイルシステムとなっており、LifeKeeperがリソース階層（①~⑤）として依存関係が構成されています。
フェールオーバー時の挙動は、リソース階層の下から切り替わりが発生します。
セカンダリ側でData Replicationのプライマリ昇格、”/data”へのマウント、仮想IPの付け替え、Baseプロセス（論理ホスト）、AJSプロセス（論理ホスト）の順番で起動します。
なお、論理ホストの環境設定ファイルが共有ファイルシステム領域に格納されていることから、Base・AJSはセカンダリ・プライマリの区別無く、同じ環境設定で起動します。
操作の流れ
以下の流れで導入を行います。
■導入してみた
Base・AJSを導入してみました。
■連携させてみた
LifeKeeperとBase・AJSを連携させてみました。
■検証してみた
擬似的に障害を発生させ、フェールオーバーを確認してみました。
導入してみた
環境の構築が完了しましたので、Base・AJSを導入します。
※コマンドラインのプロンプトは「$」がログインユーザーとなり、「#」がrootユーザーとなります。rootユーザーへのスイッチは”su -”で変更してください。
- Base・AJSの制限に触れないロケールに変更します。
今回は日本語のUTF-8を指定します。# localectl set-locale LANG=ja_JP.utf8 - 必須パッケージの導入
RHEL7にBaseを導入するために必要なパッケージを適用します。
※必須パッケージについてはBaseのリリースノートをご確認ください。 - JP1のイメージファイルのアップロード
ログインユーザーのホームディレクトリ”/home/ec2-user”へアップロードします。 - イメージファイルのマウント
# mount -o loop -t iso9660 /home/ec2-user/JP1AJS_1110L_P1.iso /media ※イメージファイルのマウント時に以下のメッセージが出力されますが、無視して問題ありません。
mount: /dev/loop0 is write-protected, mounting read-only - インストーラーの起動
# cd /media/linux
# ./setup /media - インストールの選択
キーボードの「ｉ」を押下します。
- Baseの導入
P-812C-6LBLを選択し、以降はウィザードに従って導入します。 - AJSの導入
P-CC8112-4KBLを選択し、以降はウィザードに従って導入します。 - rootの環境変数への追記
BaseとAJSのコマンド等のPATHを登録します。# vi /root/.bash_profile
PATH=$PATH:/opt/jp1base/bin/
PATH=$PATH:/etc/opt/jp1base/
PATH=$PATH:/opt/jp1ajs2/bin/
PATH=$PATH:/etc/opt/jp1ajs2/※追記した環境変数を有効にするため、一度rootアカウントを入りなおしてください。
- 認証サーバーの変更
# jbssetusrsrv <論理ホスト名>
※”/etc/hosts”に記載した論理ホスト名を指定してください。 - イベントサーバーの設定
# vi /etc/opt/jp1base/conf/event/servers/default/conf
<jp1hosts2> jp1imevt jp1imevtapi
↓ ※書き換える
<自ホスト名>
—
options remote-receive v5-unused save-rep
↓ ※書き換える
options sync remote-receive v5-unused save-rep - 物理ホストでの認証サーバー起動抑止
# cp -p /etc/opt/jp1base/conf/jp1bs_spmd.conf.model /etc/opt/jp1base/conf/jp1bs_spmd.conf - 論理ホスト環境ファイルの格納ディレクトリの作成（プライマリインスタンス）
# mkdir –p /data/jp1base/conf/
# mkdir –p /data/jp1base/log/
# mkdir –p /data/event/ - Baseの論理ホストの作成（プライマリインスタンス）
# jp1base_setup_cluster –h <論理ホスト名> -d /data –a <論理ホスト名> -s - AJSの論理ホストの作成（プライマリインスタンス）
# jajs_setup_cluster -h <論理ホスト名> -F AJSROOT2 -d /data -m hot -P 22221 -I _JF1 -M s - ジョブ実行環境の作成（プライマリインスタンス）
# jpqimport -dt isam -ci /data/jp1ajs2/conf/jpqsetup.conf -mh <論理ホスト名> - キューレスジョブのセットアップ（プライマリインスタンス）
# jsqlsetup -h <論理ホスト名> -F AJSROOT2 - 環境設定の抽出（プライマリインスタンス）
# jbsgetcnf -h <論理ホスト名> > /tmp/jp1_setup.conf - セカンダリインスタンスへ環境設定ファイルの転送（プライマリインスタンス）
# cd /home/ec2-user/
# scp –i <キーペア名> /tmp/jp1_setup.conf ec2-user@<プライマリインスタンスのプライマリプライベートIP> - 環境設定の読み込み（セカンダリインスタンス）
# jbssetcnf /tmp/jp1_setup.conf - Baseの論理ホストの作成（セカンダリインスタンス）
# jp1base_setup_cluster –h <論理ホスト名> - AJSの論理ホストの作成（セカンダリインスタンス）
# jajs_setup_cluster –h <論理ホスト名> -F AJSROOT2 - キューレスジョブのセットアップ（セカンダリインスタンス）
# ajsqlsetup -h <論理ホスト名> -F AJSROOT2 -nc - 起動スクリプトの編集
以下のコメント（:#）を削除します。# vi /opt/jp1ajs2/bin/jajs_start.cluster
52 : # /opt/jp1ajs2/bin/ajsqlstart >/dev/null 2>/dev/null
67 : # /opt/jp1ajs2/bin/ajsqlattach -h $JP1_HOSTNAME
70 : # exit 1
143 : # /opt/jp1ajs2/bin/ajsqldetach -h $JP1_HOSTNAME –k※左の数字は行番号になります。
※行番号が出力されていない場合は、コマンドモードで以下のコマンドを実行してください。
:set number - 停止スクリプトの編集
# vi /opt/jp1ajs2/bin/bin/jajs_stop.cluster
100 : # /opt/jp1ajs2/bin/ajsqldetach -h $JP1_HOSTNAME –k
103 : # ExitCord=1
104 : # exit $ExitCord
108 : # /opt/jp1ajs2/bin/ajsqlstop –c※左の数字は行番号になります。
※行番号が出力されていない場合は、コマンドモードで以下のコマンドを実行してください。
:set number - 各インスタンスの再起動
各インスタンスを再起動します。# reboot
連携させてみた
BaseとAJSの導入が完了したので、続いてLifeKeeperとの連携を行います。
- イメージファイルのマウント
# mount -o loop -t iso9660 /home/ec2-user/JP1_AJS3_MGR.iso /media ※イメージファイルのマウント時に以下のメッセージが出力されますが、無視して問題ありません。
mount: /dev/loop0 is write-protected, mounting read-only - Base・AJSのRecovery Kitパッケージのアーカイブをコピー
# cp –p /media/ Generic_ARK_for_JP1* /opt/LifeKeeper/share/ - アーカイブの展開とディレクトリ名の変更
# cd /opt/LifeKeeper/share/
# tar xvf Generic_ARK_for_JP1_Base.tgz
# tar xvf Generic_ARK_for_JP1_AJS3_Manager.tgz
# rm –rf ./ Generic_ARK_for_JP1*
# mv Generic_ARK_for_JP1_Base JP1_Base
# mv Generic_ARK_for_JP1_AJS3_Manager JP1_AJS3 - Baseのスクリプトの編集
制御用スクリプトの論理ホスト変数を、実際の論理ホスト名に書き換えます。
以下のファイル名を変更してquickCheck、recover、remove、restoreの四つのスクリプトに対して行います。# vi quickCheck
VHOSTNAME=” VHOSTNAME”
↓ ※書き換える
VHOSTNAME=”<論理ホスト名>” - AJSのスクリプトの編集
Baseのスクリプトと同じように、四つのスクリプトの論理ホスト変数を書き換えます。 - LifeKeeperGUIの起動
プライマリインスタンスにてLifeKeeperGUIを起動します。# lkGUIapp - ログイン
インスタンスのrootユーザーでログインします。 - Baseの設定
以下のボタンを押下して、Baseのリソースを作成します。
必要な情報は以下となります。
項目 入力/選択する値
備考 Please Select Recovery Kit Generic Application Switchback Type Intelligent Server プライマリインスタンスのホスト名 Restore Script /opt/LifeKeeper/share/JP1_Base/restore Remove Script /opt/LifeKeeper/share/JP1_Base/remove QuickCheck Script /opt/LifeKeeper/share/JP1_Base/quickCheck Local Recovery Script /opt/LifeKeeper/share/JP1_Base/recover Application Info 論理ホスト名 Bring Resource In Service Yes Resource Tag lkjp1_base スクリプト内のAPP変数に設定されている値 Target Server セカンダリインスタンスのホスト名 Switchback Type intelligent Template Priority 1 Target Priority 10 Resource Tag lkjp1_base スクリプト内のAPP変数に設定されている値 Application Info 論理ホスト名 - AJSの設定
以下のボタンを押下して、AJSのリソースを作成します。
必要な情報は以下となります。
項目 入力/選択する値
備考 Please Select Recovery Kit Generic Application Switchback Type Intelligent Server プライマリインスタンスのホスト名 Restore Script /opt/LifeKeeper/share/JP1_AJS3/restore Remove Script /opt/LifeKeeper/share/JP1_AJS3/remove QuickCheck Script /opt/LifeKeeper/share/JP1_AJS3/quickCheck Local Recovery Script /opt/LifeKeeper/share/JP1_AJS3/recover Application Info 論理ホスト名 Bring Resource In Service Yes Resource Tag lkjp1_ajsmgr スクリプト内のAPP変数に設定されている値 Target Server セカンダリインスタンスのホスト名 Switchback Type intelligent Template Priority 1 Target Priority 10 Resource Tag lkjp1_ajsmgr スクリプト内のAPP変数に設定されている値 Application Info 論理ホスト名 - 依存関係の設定
リソースを作成しただけですと、各リソースが別々に動作してしまうため、依存関係の設定を行います。
以下のボタンを押下して、依存関係を設定します。
なお、二つのリソースに対して依存関係を設定するため、以下の順番で三回操作します。
必要な情報は以下となります。（一回目）
項目 入力/選択する値 備考 Server プライマリインスタンスのホスト名 Parent Resource Tag lkjp1-ajsmgr Child Resource Tag lkjp1-base （二回目）
項目 入力/選択する値 備考 Server プライマリインスタンスのホスト名 Parent Resource Tag lkjp1-base Child Resource Tag 仮想IPリソース 仮想IPのリソースタグ名を指定します （三回目）
項目 入力/選択する値 備考 Server プライマリインスタンスのホスト名 Parent Resource Tag 仮想IPリソース 仮想IPのリソースタグ名を指定します Child Resource Tag /data/ データレプリケーションのリソースタグ名を指定します。 - リソース階層の完成
ここまで行えば、以下の状態となります。
これでBase・AJSリソースの作成が完了しました。
左ペインの「lkjp1-ajsmgr」配下に五つのリソースが階層として登録されています。
検証してみた
LifeKeeperとJP1の連携が完了しましたので、最後に実際に動作（フェールオーバー）するか確認してみます。今回もElastic IPが一つしかないことから、セカンダリインスタンスからログインして検証してみます。
- Elastic IPをセカンダリインスタンスに関連付ける
AWS Management ConsoleにてElastic IPをセカンダリインスタンスに関連付けます。 - LifeKeeperGUIの起動
セカンダリインスタンスへログインしたら、LifeKeeperGUIを起動します。# lkGUIapp - LifeKeeperの状態確認
LifeKeeperGUIへログインします。
- 各リソースに登録されているプロセス（Base・AJS）の起動状況を確認
セカンダリインスタンスにて以下のコマンドを実行して各プロセスが起動していないことを確認します。$ ps –ef | grep jbs
$ ps –ef | grep ajs - プライマリインスタンスへログイン
セカンダリインスタンスにて以下のコマンドを実行して、プライマリインスタンスへログインします。$ ssh –i <キーペア名> ec2-user@<プライマリインスタンスのプライマリプライベートIP> - プライマリインスタンスで擬似的に障害を発生させる
プライマリインスタンスのNICを落とすことで、擬似的に障害を発生させます。
プライマリインスタンスで以下のコマンドを実行します。# service network stop
※ifdownコマンドでも問題ありません。 - LifeKeeperGUIを確認してみる
プライマリインスタンスにてコマンドを実行後、暫くすると以下の表示になりました。
右側で表示されていたAct表示が、左に移動しています。また、プライマリインスタンスが異常となったため、左ペインやインスタンスの画像に 下記の注意マークがついています。
- 各リソースに登録されているプロセス（Base・AJS）の起動状況を確認
もう一度、セカンダリインスタンスにて以下のコマンドを実行します。$ ps –ef | grep jbs
$ ps –ef | grep ajs
今回はBase・AJSともにプロセス数が多すぎるため、記事には記載しませんが、各プロセスが起動していることが確認できます。これで正常にフェールオーバーがされていることが確認できました。
※NICを落としたプライマリインスタンスはAWS Management Console から、インスタンスの再起動処理を行えば、アクセスできるようになります。
まとめてみた
今回はLifeKeeperとJP1を連携させてみました。
今まで構築してきたアプリケーションの冗長化と違うところは、Generic Applicationを使用してリソースを作成すること、また自動で行われていたリソース階層の設定を手動で行うこととなります。
今回は専用のRecovery Kitとしてのスクリプトを使用しましたが、Generic Applicationは任意のアプリケーションに対して、「起動」「停止」を制御するスクリプトを作成すれば使用できます。更にスクリプトを登録したリソースに対して、他リソースとの依存関係を設定することができるため、今回のように先に共有ファイルシステムをマウントしてから、アプリケーションを起動するような動作も行えます。
つまり専用のRecovery Kitが無くとも、自作のスクリプトを使用してLifeKeeperでアプリケーションを制御することができるということです。
これにより、各リソースの依存関係など検討する点はあるものの、基本的にはスクリプトを作成し共有ファイルシステムの設定ができれば、あらゆるアプリケーションはLifeKeeperによる冗長化が可能ということになります。
また、今回のシリーズのようにAWSを使用してインフラ環境を構築してしまえば、面倒なオンプレミス環境の設計や構築も無く、可用性も一定以上を実現できます。
LifeKeeperは評価版があり、AWSは無料枠もありますので、このシリーズ記事をお読みの皆様も一度、構築されてはいかがでしょうか。
LifeKeeperによるJP1のクラスター構成ガイドはこちら
| ご注意 当記事の内容は、 JP1のサポート対象となる稼働環境（クラウド環境、
|
LifeKeeperとJP1の評価キット
また、JP1とLifeKeeperをAWS上で冗長化するための評価キットを、日立製作所様のサイトにて提供しております。ハンズオントレーニングで使った詳細な手順書がついておりますので、JP1案件の構成検証などにぜひお役立てください。
手順書目次
- AWSで仮想環境作成
- LifeKeeper導入/設定
- DataKeeper導入と設定
- リソース作成
- Transit Gateway設定
- JP1導入と設定
- 動作確認
