AWS上のLifeKeeper for Linux とJP1を連携させてみた

前回は、AWS上のLifeKeeper for Linux（以降、LifeKeeperと記載）とHULFTを連携させて、リソース階層に登録された三つのリソースがフェールオーバーされることを確認しました。

これらは専用のRecovery Kitを導入してGUIでリソース階層までを作成しましたが、今回は専用スクリプトを用いて、JP１を冗長化したいと思います。

具体的には、JP1/Base（以降、Baseと記載）、JP1/AJS（以降、AJSと記載）を各インスタンスに導入し、共有ファイルシステム配下を指定した論理ホストを作成します。

その後、Base・AJSの制御スクリプトをLifeKeeperへ登録し、手動でリソース階層を設定する流れとなります。なお、AJSは導入サーバーのホスト名を32バイト以内とする制限事項があり、AWSのデフォルトで付与されるホスト名だと制限に触れることから、インスタンスを作り直しホスト名を変更しています。

Contents hide

インフラ環境について
環境設定
構成イメージ
操作の流れ
まとめてみた
LifeKeeperとJP1の評価キット

インフラ環境について

今回は「AWS上にLifeKeeper for Linux を導入してみた」にホスト名変更の手順を加えて、環境を構築しています。基本的な環境の詳細については、以下の記事をご確認ください。

「AWS上にLifeKeeper for Linux を導入してみた」記事

AWS上のインスタンスのホスト名変更については、以下をご確認ください。

RHEL 7 または Centos 7 を実行するプライベート Amazon EC2 インスタンスに静的ホスト名を割り当てる方法を教えてください。

また、実際にサービス提供環境などにJP1 Recovery Kitを導入する際は、同梱されている管理ガイドを参照して構築するようにしてください。

環境設定

BaseとAJSの設定は以下となります。

項目	設定内容
Baseバージョン	JP1/Base　11-10
AJSバージョン	JP1/Automatic Job Management System 3 11-10-01
認証サーバー	論理ホスト
論理ホスト	仮想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は無料枠もありますので、このシリーズ記事をお読みの皆様も一度、構築されてはいかがでしょうか。

>>JP1のクラスタ構成による可用性の向上パターンはこちら

LifeKeeperによるJP1のクラスター構成ガイドはこちら

ご注意
当記事の内容は、弊社が独自に実施した検証結果に基づいたものです。

JP1のサポート対象となる稼働環境（クラウド環境、データミラー構成の可否、等）に関しては以下Webサイトをご参照の上、具体的なご要望に関しては日立製作所様又はJP1の販売会社様へご相談下さい。

http://www.hitachi.co.jp/Prod/comp/soft1/jp1/products/environments/index.html

LifeKeeperとJP1の評価キット

また、JP1とLifeKeeperをAWS上で冗長化するための評価キットを、日立製作所様のサイトにて提供しております。ハンズオントレーニングで使った詳細な手順書がついておりますので、JP1案件の構成検証などにぜひお役立てください。

手順書目次

AWSで仮想環境作成
LifeKeeper導入/設定
DataKeeper導入と設定
リソース作成
Transit Gateway設定
JP1導入と設定
動作確認

AWS上のLifeKeeper for Linux とJP1を連携させてみた

インフラ環境について

環境設定

構成イメージ