1. ホーム /
  2. クラウド /
  3. AWS上のLifeKeeper for Linux とHULFTを連携させてみた
  • 2017.06.22

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 管理ガイド

    Contents hide

    インフラ環境について

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

    環境設定

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

      項目    設定内容  
      バージョン    HULFT8 for Linux Ver.08.01.02    
      実行モジュール格納ディレクトリ（HULEXEP)  /usr/local/hulft/bin
      環境設定ファイル格納ディレクトリ（HULPATH）  /data/hulft/etc

    インフラや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）が登録されています。
      6. リソースの完成

    検証してみた

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

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

      3. LifeKeeperの状態確認
    4. 各リソースに登録されているプロセス（hulobsd、hulrcvd、hulsndd）の起動状況を確認
      セカンダリインスタンスにて以下のコマンドを実行して各hulftプロセスが起動していないことを確認します。
        $ ps –ef | grep hulft
    5. プライマリインスタンスへログイン
      セカンダリインスタンスにて以下のコマンドを実行して、プライマリインスタンスへログインします。
        $ ssh –i <キーペア名> ec2-user@<プライマリインスタンスのプライマリプライベートIP>
    6. プライマリインスタンスで擬似的に障害を発生させる
      プライマリインスタンスのNICを落とすことで、擬似的に障害を発生させます。
      プライマリインスタンスで以下のコマンドを実行します。
        # service network stop
        ※ ifdownコマンドでも問題ありません。
    7. LifeKeeperGUIを確認してみる
      プライマリインスタンスにてコマンドを実行後、暫くすると以下の表示なりました。右側で表示されていたAct表示が、左に移動しています。
      また、プライマリインスタンスが異常となったため、左ペインやインスタンスの画像に下記の注意 マークがついています。
      注意マーク

      7. LifeKeeperGUIを確認してみる
    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を連携させてみた　を読む