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

＞第1回から読む

前回、AWS上のLifeKeeper for Linux（以降、LifeKeeperと記載）とPostgreSQLを連携させて、PostgreSQLプロセスと共有ファイルシステム上のデータベースがフェールオーバーされることを確認しました。

PostgreSQLリソースで登録したプロセスは一つでしたので、今回はHULFTを導入して複数のプロセスを登録したリソースを作成してみます。具体的な構成としては、HULFTを各インスタンスに導入し、環境設定ファイル格納ディレクトリを共有ファイルシステム領域（”/data”）配下に設定します。

この状態でLifeKeeperへHULFTリソース（三つのプロセス）を登録することでHULFTの冗長化を行いたいと思います。

>>HULFTとLifeKeeperの連携ソリューションはこちら
関連資料：LifeKeeper for Linux HULFT Recovery Kit 管理ガイド

インフラ環境について

今回も「AWS上にLifeKeeper for Linux を導入してみた」にて構築した環境を使用します。環境の詳細については、以下の記事をご確認ください。

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

環境設定

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

インフラやLifeKeeperの設定値については、「AWS上にLifeKeeper for Linux を導入してみた」をご参照ください。

構成イメージ

環境イメージは以下となります。
Clustering subnet A/Bで起動した各インスタンスに導入したHULFTの環境設定ファイルの格納領域（ディレクトリ）は”/data/hulft/etc”となります。
“/data”配下はLifeKeeperのData Replication機能を利用した共有ファイルシステムとなっており、LifeKeeperがHULFTの三つのプロセスと環境設定ファイルの格納領域を管理します。

フェールオーバー時の挙動は、セカンダリ側がプライマリへ昇格し、仮想IPの付け替えを行い、共有ファイルシステムを”/data”へマウントした後に、HULFTの三つプロセスを起動します。
環境設定ファイルが共有ファイルシステム領域に格納されていることから、HULFTはセカンダリ・プライマリの区別無く、同じ環境設定で起動します。

操作の流れ

以下の流れで導入を行います。

■導入してみた
   HULFTを導入してみました。

■連携させてみた
   LifeKeeperとHULFTを連携させてみました。

■検証してみた
   擬似的に障害を発生させ、フェールオーバーを確認してみました。

導入してみた

各インスタンスにHULFTを導入します。基本的にコマンドラインでの操作となります。

※コマンドラインのプロンプトは「$」がログインユーザーとなり、「#」がrootユーザーとなります。
rootユーザーへのスイッチは”su -”で変更してください。

1.  “/etc/hosts”ファイルの編集
   LifeKeeperで設定した仮想IPに対して一意の論理ホスト名を”/etc/hosts”に記載します。

   # vi /etc/hosts           <仮想IPアドレス>△<論理のホスト名>          ※ △はスペースになります。

   ※論理ホスト名は任意の名前で問題ありません。
   ※プライマリ・セカンダリ共に同じ値を記載してください。

2.  HULFT本体とRecovery Kitのイメージファイルのアップロード
   ログインユーザーのホームディレクトリ”/home/ec2-user”へアップロードします。
3.  イメージファイルのマウント
   

   # mkdir /tmp/hulft   # mount -o loop -t iso9660 /home/ec2-user/hulft-unix-linux-v812.iso /media   # cp –p /media/64bit/linux_x86/hulft.tar /tmp/hulft/

4. アーカイブファイルの展開
   

   # tar /tmp/hulft/hulft.tar

5. インストーラーの起動
   

   # cd /tmp/hulft   # ./installer

6. 運用系ノードとしてHULFTを導入（プライマリインスタンス）
   ウィザードに従い運用系ノードとしてHULFTを導入します。必要な情報は以下となります。

   項目	入力/選択する値	備考
   Select a language that you want to use during installation.	Japanese(UTF-8)
   シリアル番号	シリアル番号	プロダクトキー発行   書類に記載
   プロダクトキー	プロダクトキー	プロダクトキー発行   書類に記載
   HULFT 実行モジュール格納ディレクトリ  (HULEXEP)	/usr/local/hulft
   HULFT 環境設定ファイル格納ディレクトリ  (HULPATH)	/data/hulft
   HULFTをインストールする環境	クラスタ環境 （運用系ノード）
   一時ファイル作成パス	/usr/local/hulft
   pidファイル作成パス	/usr/local/hulft/etc
   自ホスト名	論理ホスト名	項番1で設定した任意の  ホスト名
   日付形式の選択	YYYY/MM/DD

7. 待機系ノードとしてHULFTを導入（セカンダリインスタンス）
   ウィザードに従い待機系ノードとしてHULFTを導入します。必要な情報は以下となります。

   項目	入力/選択する値	備考
   Select a language that you want to use during installation.	Japanese(UTF-8)
   シリアル番号	シリアル番号	プロダクトキー発行   書類に記載
   プロダクトキー	プロダクトキー	プロダクトキー発行   書類に記載
   HULFT 実行モジュール格納ディレクトリ    (HULEXEP)	/usr/local/hulft
   HULFT 環境設定ファイル格納ディレクトリ  (HULPATH)	/data/hulft
   HULFTをインストールする環境	クラスタ環境 （運用系ノード）

8. 一時ファイルとpidファイルの格納ディレクトリの作成（セカンダリインスタンス）
   

   # mkdir /usr/local/hulft/tmp   # chmod 777 /usr/local/hulft/tmp   # mkdir /usr/local/hulft/etc   # chmod 777 /usr/local/hulft/etc

連携させてみた

HULFTの導入が完了しましたので、次はLifeKeeperにHULFTリソースの作成を行います。なお、項番2までは各インスタンスで行う必要があります。

1. イメージファイルのマウント
   

   # mount -o loop -t iso9660 /home/ec2-user/HULFTARK072814.iso /media

   ※イメージファイルのマウント時に以下のメッセージが出力されますが、無視して問題ありません。
       mount: /dev/loop0 is write-protected, mounting read-only

2.  HULFTのRecovery Kitパッケージの導入
   

   # rpm –ivh –force /media/steeleye-lkHUL-8.2.1-6353.noarch.rpm

3. LifeKeeperGUIの起動
   プライマリインスタンスにてLifeKeeperGUIを起動します。

   # lkGUIapp

4. ログイン
   インスタンスのrootユーザーでログインします。
5. HULFTの設定
   以下のボタンを押下して、HULFTのリソースを作成します。
   

   必要な情報は以下となります。

   項目	入力/選択する値	備考
   Please Select Recovery Kit	HULFT
   Switchback Type	intelligent
   Server	プライマリインスタンスのホスト名
   HULEXEP path	/usr/local/hulft/bin
   HULPATH path	/data/hulft/etc
   Filesystem Tag	none
   HULFT Tag	hulft
   Target Server	セカンダリインスタンスのホスト名
   Switchback Type	intelligent
   Template Priority	1
   Target Priority	10
   HULFT Tag	hulft

6. リソースの完成
   ここまで行えば、以下の状態となります。
   これでHULFTリソースの作成が完了しました。左ペインの「hulft」配下に三つのリソース（hulft-obs、hulft-rcv、hulft-snd）が登録されています。
   

検証してみた

LifeKeeperとHULFTの連携が完了しましたので、最後に実際に動作（フェールオーバー）するか確認してみます。今回もElastic IPが一つしかないことから、セカンダリインスタンスからログインして検証してみます。

1.  Elastic IPをセカンダリインスタンスに関連付ける
   AWS Management ConsoleにてElastic IPをセカンダリインスタンスに関連付けます。
2. LifeKeeperGUIの起動
   セカンダリインスタンスへログインしたら、LifeKeeperGUIを起動します。

   # lkGUIapp

3. LifeKeeperの状態確認
   LifeKeeperGUIへログインします。
   
   
4. 各リソースに登録されているプロセス（hulobsd、hulrcvd、hulsndd）の起動状況を確認
   セカンダリインスタンスにて以下のコマンドを実行して各hulftプロセスが起動していないことを確認します。

   $ ps –ef | grep hulft

5. プライマリインスタンスへログイン
   セカンダリインスタンスにて以下のコマンドを実行して、プライマリインスタンスへログインします。

   $ ssh –i <キーペア名> ec2-user@<プライマリインスタンスのプライマリプライベートIP>

6. プライマリインスタンスで擬似的に障害を発生させる
   プライマリインスタンスのNICを落とすことで、擬似的に障害を発生させます。
   プライマリインスタンスで以下のコマンドを実行します。

   # service network stop   ※ ifdownコマンドでも問題ありません。

7. LifeKeeperGUIを確認してみる
   プライマリインスタンスにてコマンドを実行後、暫くすると以下の表示なりました。右側で表示されていたAct表示が、左に移動しています。
   また、プライマリインスタンスが異常となったため、左ペインやインスタンスの画像に下記の注意 マークがついています。
   

   
   

8. 各リソースに登録されているプロセス（hulobsd、hulrcvd、hulsndd）の起動状況を確認
   もう一度、セカンダリインスタンスにて以下のコマンドを実行します。

   $ ps -ef |grep hulft        root    4098    1    0 19:51 ?    00:00:00        /usr/local/hulft/bin/hulrcvd -pipe 20 -oplsrc HULFT_CLS_COMMAND        -oplkey HULFT_RECEIVE_STARTUP -oplsdate 2017/05/24 -oplstime        19:51:40.116 -opluid root -oplshost hulft.ap-northeast-1.compute.internal        -oplsid 6A30B310EE4C7E33E016412AFE5E741732 -opllid        6A30B310EE4C7E33E016412AFE5E741732        root    4099    1    0 19:51 ?    00:00:00        /usr/local/hulft/bin/hulobsd -pipe 20 -oplsrc HULFT_CLS_COMMAND        -oplkey HULFT_REQUEST_ACKNOWLEDGE_STARTUP -oplsdate        2017/05/24 -oplstime 19:51:40.117 -opluid root -oplshost        hulft.ap-northeast-1.compute.internal -oplsid        CC2317AA91B9C88D2F1E4345D80A666832 -opllid        CC2317AA91B9C88D2F1E4345D80A666832        root    4100    1    0    19:51 ?    00:00:00        /usr/local/hulft/bin/hulsndd -pipe 20 -oplsrc HULFT_CLS_COMMAND        -oplkey HULFT_SEND_STARTUP -oplsdate 2017/05/24 -oplstime        19:51:40.115 -opluid root -oplshost hulft.ap-northeast-1.compute.internal        -oplsid 9242000D9D9C301D1EE7EEDAEE41F3C432 -opllid        9242000D9D9C301D1EE7EEDAEE41F3C432        root    4104    4099    0 19:51 ?    00:00:00        /usr/local/hulft/bin/hulobsd -pipe 20 -oplsrc HULFT_CLS_COMMAND        -oplkey HULFT_REQUEST_ACKNOWLEDGE_STARTUP -oplsdate        2017/05/24 -oplstime 19:51:40.117 -opluid root -oplshost        hulft.ap-northeast-1.compute.internal -oplsid        CC2317AA91B9C88D2F1E4345D80A666832 -opllid        CC2317AA91B9C88D2F1E4345D80A666832      ※上記のような表示が出力されます。

   ちゃんと切り替わって、HULFTの各プロセスが起動しています。
   これで正常にフェールオーバーがされていることが確認できました。

※NICを落としたプライマリインスタンスはAWS Management Console から、インスタンスの再起動処理を行えば、アクセスできるようになります。

まとめてみた

今回はLifeKeeperとHULFTを連携させてみました。PostgreSQLとの手順の違いは、共有ファイルシステム領域に環境設定ファイルを配置するところになります。

アプリケーション冗長化のポイントは、プライマリ・セカンダリ共通で使用するデータ（前回はデータベース、今回は環境設定ファイル）を、共有ファイルシステム領域に配置することになります。共有ファイルシステム領域に何を配置するかは、冗長化したいアプリケーションによって変わってきますが、Recovery Kitがあるアプリケーションの場合は、公式ドキュメントに配置先を含め基本的な手順が記載されておりますので、ご参照頂ければと思います。

次はこの構成にJP1を導入してみようと思います。

> 第４回　AWS上のLifeKeeper for Linux とJP1を連携させてみた　を読む