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

    環境イメージ

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

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

    >前回から読む

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

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

    インフラ環境について

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

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

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

    【特別企画】ウェビナーのご紹介

    JP1onAzureオンラインハンズオンセミナー

    日立様 統合システム運用管理 ソフト「JP1」のホームページ上で正式に認定された、LifeKeeper for  Windowsを使ったJP1/AJS3のAWS上でのクラスタ構成を、自席やご自宅で気軽に体験いただける、ハンズオンウェブセミナーです。

    ※本セミナーは「LifeKeeperとJP1の評価キット」を使用いたします。 評価キットでLifeKeeperおよびJP1の評価版と構築手順書をセットにして提供しています。 https://www.hitachi.co.jp/Prod/comp/soft1/jp1/product/jp1/evaluate/lifekeeper/index.html

    環境設定

    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 -”で変更してください。

    1.  Base・AJSの制限に触れないロケールに変更します。
      今回は日本語のUTF-8を指定します。

        # localectl set-locale LANG=ja_JP.utf8  
    2.  必須パッケージの導入
      RHEL7にBaseを導入するために必要なパッケージを適用します。
      ※必須パッケージについてはBaseのリリースノートをご確認ください。
    3.  JP1のイメージファイルのアップロード
      ログインユーザーのホームディレクトリ”/home/ec2-user”へアップロードします。
    4.  イメージファイルのマウント
        # mount -o loop -t iso9660 /home/ec2-user/JP1AJS_1110L_P1.iso /media

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

    5.  インストーラーの起動
        # cd /media/linux
        # ./setup /media
    6.  インストールの選択
      キーボードの「i」を押下します。
      6. インストールの選択 キーボードの「i」を押下します
    7.  Baseの導入
      P-812C-6LBLを選択し、以降はウィザードに従って導入します。
    8.  AJSの導入
      P-CC8112-4KBLを選択し、以降はウィザードに従って導入します。
    9.  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アカウントを入りなおしてください。

    10.  認証サーバーの変更
        # jbssetusrsrv <論理ホスト名>
        ※”/etc/hosts”に記載した論理ホスト名を指定してください。
    11.  イベントサーバーの設定
        # 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
    12.  物理ホストでの認証サーバー起動抑止
        # cp -p /etc/opt/jp1base/conf/jp1bs_spmd.conf.model /etc/opt/jp1base/conf/jp1bs_spmd.conf
    13.  論理ホスト環境ファイルの格納ディレクトリの作成(プライマリインスタンス)
        # mkdir –p /data/jp1base/conf/
        # mkdir –p /data/jp1base/log/
        # mkdir –p /data/event/
    14.  Baseの論理ホストの作成(プライマリインスタンス)
        # jp1base_setup_cluster –h <論理ホスト名> -d /data –a <論理ホスト名> -s
    15.  AJSの論理ホストの作成(プライマリインスタンス)
        # jajs_setup_cluster -h <論理ホスト名> -F AJSROOT2 -d /data -m hot -P 22221 -I _JF1 -M s
    16.  ジョブ実行環境の作成(プライマリインスタンス)
        # jpqimport -dt isam -ci /data/jp1ajs2/conf/jpqsetup.conf -mh <論理ホスト名>
    17.  キューレスジョブのセットアップ(プライマリインスタンス)
        # jsqlsetup -h <論理ホスト名> -F AJSROOT2
    18.  環境設定の抽出(プライマリインスタンス)
        # jbsgetcnf -h <論理ホスト名> > /tmp/jp1_setup.conf
    19.  セカンダリインスタンスへ環境設定ファイルの転送(プライマリインスタンス)
        # cd /home/ec2-user/
        # scp –i <キーペア名> /tmp/jp1_setup.conf ec2-user@<プライマリインスタンスのプライマリプライベートIP>
    20.  環境設定の読み込み(セカンダリインスタンス)
        # jbssetcnf /tmp/jp1_setup.conf
    21.  Baseの論理ホストの作成(セカンダリインスタンス)
        # jp1base_setup_cluster –h <論理ホスト名>
    22.  AJSの論理ホストの作成(セカンダリインスタンス)
        # jajs_setup_cluster –h <論理ホスト名> -F AJSROOT2
    23.  キューレスジョブのセットアップ(セカンダリインスタンス)
        # ajsqlsetup -h <論理ホスト名> -F AJSROOT2 -nc
    24. 起動スクリプトの編集
      以下のコメント(:#)を削除します。

        # 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

    25.  停止スクリプトの編集
        # 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

    26.  各インスタンスの再起動
      各インスタンスを再起動します。

        # reboot

    連携させてみた

    BaseとAJSの導入が完了したので、続いてLifeKeeperとの連携を行います。

    1.  イメージファイルのマウント
        # mount -o loop -t iso9660 /home/ec2-user/JP1_AJS3_MGR.iso /media

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

    2.  Base・AJSのRecovery Kitパッケージのアーカイブをコピー
        # cp –p /media/ Generic_ARK_for_JP1* /opt/LifeKeeper/share/
    3.  アーカイブの展開とディレクトリ名の変更
        # 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
    4.  Baseのスクリプトの編集
      制御用スクリプトの論理ホスト変数を、実際の論理ホスト名に書き換えます。
      以下のファイル名を変更してquickCheck、recover、remove、restoreの四つのスクリプトに対して行います。

        # vi quickCheck
        VHOSTNAME=” VHOSTNAME”
          ↓   ※書き換える
        VHOSTNAME=”<論理ホスト名>”
    5.  AJSのスクリプトの編集
      Baseのスクリプトと同じように、四つのスクリプトの論理ホスト変数を書き換えます。
    6.  LifeKeeperGUIの起動
      プライマリインスタンスにてLifeKeeperGUIを起動します。

        # lkGUIapp
    7.  ログイン
      インスタンスのrootユーザーでログインします。
    8.  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  論理ホスト名 
    9.  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  論理ホスト名 
    10.  依存関係の設定
      リソースを作成しただけですと、各リソースが別々に動作してしまうため、依存関係の設定を行います。
      以下のボタンを押下して、依存関係を設定します。
      bottun_izon

      なお、二つのリソースに対して依存関係を設定するため、以下の順番で三回操作します。
      必要な情報は以下となります。

      (一回目)

        項目    入力/選択する値    備考  
        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/ データレプリケーションのリソースタグ名を指定します。
    11.  リソース階層の完成
      ここまで行えば、以下の状態となります。
      これでBase・AJSリソースの作成が完了しました。
      左ペインの「lkjp1-ajsmgr」配下に五つのリソースが階層として登録されています。
      lkjp1-ajsmgr」配下に五つのリソースが階層として登録される

    検証してみた

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

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

        # lkGUIapp
    3.  LifeKeeperの状態確認
      LifeKeeperGUIへログインします。
      LifeKeeperGUIへログイン
    4.  各リソースに登録されているプロセス(Base・AJS)の起動状況を確認
      セカンダリインスタンスにて以下のコマンドを実行して各プロセスが起動していないことを確認します。

        $ ps –ef | grep jbs
        $ ps –ef | grep ajs
    5.  プライマリインスタンスへログイン
      セカンダリインスタンスにて以下のコマンドを実行して、プライマリインスタンスへログインします。

        $ ssh –i <キーペア名> ec2-user@<プライマリインスタンスのプライマリプライベートIP>
    6.  プライマリインスタンスで擬似的に障害を発生させる
      プライマリインスタンスのNICを落とすことで、擬似的に障害を発生させます。
      プライマリインスタンスで以下のコマンドを実行します。

        # service network stop
          ※ifdownコマンドでも問題ありません。
    7.  LifeKeeperGUIを確認してみる
      プライマリインスタンスにてコマンドを実行後、暫くすると以下の表示になりました。
      右側で表示されていたAct表示が、左に移動しています。

      また、プライマリインスタンスが異常となったため、左ペインやインスタンスの画像に 下記の注意マークがついています。
      注意マーク

      7. LifeKeeperGUIを確認

    8.  各リソースに登録されているプロセス(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の販売会社様へご相談下さい。

     

     

     

    SNSでもご購読できます。