AWS上にLifeKeeper for Linux を導入してみた

構成イメージ
Pocket

インフラ部分の可用性については一定の担保を提供するクラウド環境ですが、その上で動作しているアプリケーションの可用性は利用者に任されているのが現状です。

LifeKeeper for Linux(以降は、LifeKeeperと記載)はクラウド環境において担保外となっているアプリケーションの可用性を実現させるソフトウェアとなります。今回はLifeKeeperをAWSの無料枠を使用してEC2上に導入してみます。

AWSの無料枠

AWSの幾つかのサービス(EC2やS3、RDS等)は、新規の利用者に対して初回ログインから利用できる無料枠を提供しています。期間は12ヶ月となっていますが、無料枠自体は月単位の時間制(750時間)となっており、12ヶ月未満でも月間の無料枠を超えてしてしまうと、以降は従量課金となりますので注意してください。
詳細はAWSのページをご確認ください。

 https://aws.amazon.com/jp/free/

環境設定

環境設定は以下となります。

  項目   設定内容 
 リージョン   Tokyo
  AvailabilityZone   ap-northeast-1a  
  インスタンスタイプ   t2.micro
  AMI   Red Hat Enterprise Linux 7.3 (HVM), SSD Volume Type  
  インスタンス数   2つ
  プライベートIP   プライマリ / セカンダリ
  Elastic IP   1つ
  ディスクストレージ     プライマリボリューム / データ共有用ボリューム
  LifeKeeper      LifeKeeper for Linux v9.1.1
  データ共有方式   LifeKeeperのData Replication機能を利用

 

※無料枠内での環境となるため最小構成となります。実際にサービスを稼動させる場合は、サービス内容にあった構成を検討してください。

構成イメージ

環境イメージは以下となります。
Clustering subnet A/Bで起動した各インスタンスに導入したLifeKeeperのData Replication機能を使用して、各インスタンスの追加ボリュームを共有ファイルシステム化し任意のマウントポイント(今回は”/data”)へマウントします。

構成イメージ

フェールオーバー時の挙動は、セカンダリ側がプライマリへ昇格し、共有ファイルシステム化しているボリュームを、プライマリ側と同じマウントポイントへマウントします。

障害時イメージ

導入の流れ

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

■インフラを構築してみた
 AWS上にインフラ環境を構築してみました。

■クライアントの準備をしてみた
 インスタンスへアクセスするためのクライアント側の準備をしてみました。

■導入の準備をしてみた
 インスタンスにてLifeKeeperの導入準備をしてみました。

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

■操作してみた
 LifeKeeperの設定を行ってみました。

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

インフラを構築してみた

まずは、AWSにてインフラ環境を構築します。
WebUIで直感的に操作できることから、ポイントとなる箇所をピックアップして記載します。

  1. リージョンを選択
    AWS Management Consoleにサインインして、右上メニューからアジアパシフィック(東京)を選択します。

    リージョンを選択

  2. VPCの作成
    ネームタグは任意の名前で問題ありません。IPv4 CIDR blockは最大”/16”まで設定できますので、今回は最大で設定します。他の項目はそのままで作成します。


    VPCの作成

  3. インターネットゲートウェイの作成
    ネームタグは任意の名前で問題ありません


    3.	インターネットゲートウェイの作成

  4. インターネットゲートウェイのアタッチ
    作成したインターネットゲートウェイを作成したVPCにアタッチします。


    4.	インターネットゲートウェイのアタッチ

  5. サブネット(Clustering subnet A)の作成
    ネームタグは任意の名前で問題ありません。VPCは作成したVPCを選択します。
    アベイラビリティゾーンはap-northeast-1aを選択します。
    IPv4 CIDR blockはVPCに設定したサブネットマスクの範囲内となります。今回は”/24”で設定します。


    サブネット(Clustering subnet A)の作成

  6. サブネット(Clustering subnet B)の作成
    Clustering subnet Aと同じ方法で、IPv4 CIDR blockを変更します。こちらもサブネットマスクは”/24”で設定します。


    サブネット(Clustering subnet B)の作成

  7. ルートテーブルの作成
    ネームタグは任意の名前で問題ありません。VPCは作成したVPCを選択します。


    ルートテーブルの作成

  8. ルーティングの設定
    ルートテーブルへ作成したインターネットゲートウェイに対するルーティングを設定します。


    8.	ルーティングの設定

  9. ルートテーブルへサブネットの関連付け
    作成したサブネットを関連付けます。


    9.	ルートテーブルへサブネットの関連付け

  10.  セキュリティグループの作成
    ネームタグ、グループ名、説明は全て任意の名前や文言で問題ありません。

    10.	セキュリティグループの作成
    ※ここでは2バイト文字(日本語等)は使用できないため、注意してください。

  11. インバウンドルールの設定
    タイプを全てのトラフィックとし、送信元にはアクセス元となるグローバルIPを設定します。また、ルールを一つ追加し、タイプを全てのトラフィックとして、送信元に自身のセキュリティグループを設定します。

    11.	インバウンドルールの設定
  12. アウトバウンドルールの設定
    そのままで問題ありません。
  13. インスタンスの作成クラスタリング用インスタンスを二つ作成します。
    (1) AMIは「Red Hat Enterprise Linux 7.3 (HVM), SSD Volume Type」を選択します。

    (1)	AMIを選択
    (2) インスタンスタイプは「t2.micro」を選択します。

    (2)	インスタンスタイプを選択
    (3) インスタンスの詳細にて、ネットワークには作成したVPCを選択し、サブネットはインスタンス毎にそれぞれClustering subnet A、Clustering subnet Bを設定します。

    (3)	インスタンスの詳細

      更に、ネットワークインターフェースの項目で、セカンダリIPアドレスを追加します。

    セカンダリIPアドレスを追加
    (4) 新しいボリュームを追加します。今回は”8G”を選択します。


    (4)	新しいボリュームを追加
    (5) アクセス用キーペアを新規作成します。
    新しいキーペアの作成を選択後、キーペア名に任意の名前を入力しダウンロードします。

    (5)	アクセス用キーペアを新規作成
    ※一度、キーペアを作成した後は「既存のキーペアを使用する。」を選択し、作成したキーペア名を指定すれば、他インスタンスでも同じキーペアを使用できます。

  14.  Elastic IPの設定
    インターネット経由でインスタンスに接続するためのIPアドレス(Elastic IP)を関連付けます。インスタンスはアクセスしたいインスタンスを選択します。プライベートIPは、プライマリプライベートIPアドレスを選択します。

    14.	Elastic IPの設定

    ※Elastic IPは関連付けされたインスタンスが停止している場合や、関連付けされずにただ保有している状態になると、課金が発生するため注意してください。

  15.  インスタンスへの接続
    これでクライアント(ローカル端末)からインターネット経由でElastic IP宛にインスタンスへSSH接続することが可能になります。なお、今回はElastic IPは一つ(無料枠で使用できるのは一つ)しか使用しないため、各インスタンスでインターネットを使用する際はElastic IPを付け替える必要があります。

クライアントの準備をしてみた

AWSにてインフラ環境は構築しましたので、インスタンスに接続してLifeKeeperの導入を行いたいところですが、その前に接続元となるクライアント側でLifeKeeperを使用する準備が必要になります。

  1.  ターミナルソフトの準備
    今回はTeraTermを使用します。
    ※ソフトの取得や導入方法については、TeraTermのサイトを参照してください
  2.  Xサーバーの準備
    LifeKeeperの設定はGUIで行いますが、このGUIはX Window Systemを使用しているため、クライアント側にもWindows用Xサーバーが必要になります。今回はXmingを使用します。
    ※ソフトの取得や導入方法については、Xmingのサイトを参照してください
  3.  TeraTermの設定
    ターミナルソフトにてX WindowへのSSH転送の設定を追加します。
    設定>SSH転送を選択しリモートの(X)アプリケーションをローカルのXサーバーに表示する。にチェックを入れます。
    3.	TeraTermの設定
    ※設定を行った後は、変更内容を設定ファイルに保存するのは忘れないでください。
    ※この設定は使用するターミナルソフトの全てで設定が必要となるので、各ソフトのマニュアルを参照して設定を行ってください。
  4.  インスタンスへの接続
    Elastic IPアドレス宛にSSH接続を行います。ログイン情報は以下となります。

    IPアドレス:Elastic IP
    ログインID:ec2-user
    PW:インスタンス作成時に作成したキーペアを使用

    ※Elastic IPを付け替えてインスタンスへ接続する場合、ホスト鍵が一致しない旨のメッセージが表示されますので、都度ホスト鍵を上書きするようにしてください。

導入の準備をしてみた

クライアントの準備ができましたので、作成したインスタンスへ接続しOSの設定とLifeKeeperの導入の準備を行います。ここからは主にコマンドラインでの操作となります。

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

  1.  タイムゾーンの変更(日本時間に変更)
      # timedatectl set-timezone Asia/Tokyo
  2.  SELinuxの無効化
      # cp -p /etc/selinux/config /etc/selinux/config.org
      # vi /etc/selinux/config
            SELINUX=enforcing
            ↓ ※書き換える
            SELINUX=disabled
  3.  X Windowの導入
      # yum -y groupinstall “x11”
      # systemctl set-default graphical.target
  4.  redhat-lsbの導入
      # yum -y install redhat-lsb
  5. 名前解決の設定
    自身のDNS情報と対向インスタンスの名前解決設定を追加します。
    なおIPアドレスは各インスタンスのプライマリプライベートIPアドレスを設定してください。

      # cp -p /etc/hosts /etc/hosts.org
      # vi /etc/hosts
             10.10.20.***  ip-10.10.20.***.ap-northeast-1.compute.internal
             10.10.30.***  ip-10.10.30.***.ap-northeast-1.compute.internal

      ※  IPアドレス△ホスト名 の書式で記載してください。(△はスペース)

    ※各インスタンスのホスト名は、インスタンス作成時にAWSが自動で設定します。ホスト名の確認方法は各インスタンスにて”hostname”コマンドで確認してください。

  6.  NICの追加
    インスタンス作成時に追加したセカンダリプライベートIPアドレスは、OS側では自動で認識しないため、ファイルを作成して認識させる必要があります。

      # vi /etc/sysconfig/network-scripts/ifcfg-eth0:1
             DEVICE=”eth0:1″
             BOOTPROTO=”static”
             IPADDR=”セカンダリプライベートIPアドレス”
             NETMASK=”255.255.255.0″
             ONBOOT=”yes”
             TYPE=”Ethernet”
             USERCTL=”yes”
             PEERDNS=”yes”
             IPV6INIT=”no”
  7.  再起動
      # reboot
  8.  X Windowの設定確認・変更
    X Windowはログインしたユーザーの環境変数と認証情報、GUI画面を起動したユーザーの環境変数と認証情報がそれぞれ一致している必要があります。

      $ echo $DISPLAY
      # echo $DISPLAY
      $ xauth list
      # xauth list
      ※ それぞれの出力結果が一致していることを確認します。

    ※それぞれの情報が一致していない場合、以下のコマンドでログインユーザー側の情報と一致させてください。
    # export DISPLAY=ログインユーザーの$DISPLAYの出力結果
    # xauth add ログインユーザーのxauth listの出力結果
    また、永続的に環境変数を設定する場合は、別途ユーザーの環境変数(.bash_profile等)を編集してください。

導入してみた

インフラ環境、クライアント、OSの準備ができましたので、いよいよLifeKeeperの導入を行います。
なお、LifeKeeperはクラスタリングする全てのインスタンスへ導入する必要があります。

  1.  LifeKeeperのイメージファイルとライセンスキーファイルのアップロード
    各インスタンスのログインユーザーのホームディレクトリ”/home/ec2-user”へアップロードします。
  2.  イメージファイルのマウント
      # mount -o loop -t iso9660 /home/ec2-user/LKL_V911_011617.iso /media  
      # mount /media/sps_911.img -t iso9660 -o loop /mnt
      # /mnt/setup

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

  3.  LifeKeeperの導入
    Enterキーを押して、LifeKeeperのインストールを開始します。
    なお、以降はウィザードに従って進めるだけで導入が完了します。

    3.	LifeKeeperの導入
  4. データ共有用(DataKeeper)のモジュールの導入
    Data Replication機能を使用するため、Enterキーを押下します。

    4.	データ共有用(DataKeeper)のモジュールの導入
  5.  ライセンスキーの導入
    後ほど実施するため、そのままEnterを押下します。

    5.	ライセンスキーの導入
  6. Recovery Kitパッケージの導入
    lkDRを選択し、Enterを押下します。
    6.	Recovery Kitパッケージの導入
  7.  導入の完了
    以下の表示が出力されれば、導入は完了です。

    7.	導入の完了
  8.  ライセンスキーの登録
    LifeKeeperのライセンスキーを登録します。

      # /opt/LifeKeeper/bin/lkkeyins /home/ec2-user/<ライセンスーファイル名>
  9. rootの環境変数への追記
    LifeKeeperのコマンド等のPATHを登録します。

      # cp -p /root/.bash_profile /root/.bash_profile.org
      # vi /root/.bash_profile
             # For LifeKeeper
             PATH=$PATH:/opt/LifeKeeper/bin
            MANPATH=$MANTPATH:/opt/LifeKeeper/man

            export PATH MANPATH

操作してみた

LifeKeeperの導入が完了しましたので、GUIを起動して各インスタンスをクラスタリングし、その後、Data Replication機能を使用して追加ボリュームを共有ファイルシステム化します。

  1.  LifeKeeperの起動
    各インスタンスにてLifeKeeperを起動します。

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

      # lkGUIapp

    ※LifeKeeperGUIを起動する時は、クライアント側でXサーバー(Xming)を起動しておいてください。

  3.  ログイン
    インスタンスのrootユーザーでログインします。
    ※インスタンスのrootユーザーのPWを設定していない場合、以下のコマンドでPWを設定してください。

      # passwd
  4. 一つ目のコミュニケーションパスの作成
    下記のボタンを押下して、コミュニケーションパスを作成します。
    ボタン

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

      項目   入力/選択する値   備考  
       Local Server     プライマリインスタンスのホスト名    
      Remote Server     セカンダリインスタンスのホスト名  
      Device Type   TCP  
      Local IP Address    プライマリインスタンスのIPアドレス    プライマリプライベートIP
      Remote IP Address     セカンダリインスタンスのIPアドレス    プライマリプライベートIP 
      Priority   1  
  5. 二つ目のコミュニケーションパスの作成
    予備用のコミュニケーションパスを作成します。
    再度、以下のボタンを押下して、予備用コミュニケーションパスを作成します。
    ボタン

    なお、以下の情報のみ変更します。

      項目   入力/選択する値   備考  
      Local IP Address    プライマリインスタンスのIPアドレス   セカンダリプライベートIP
      Remote IP Address     セカンダリインスタンスのIPアドレス     セカンダリプライベートIP  
      Priority   1   
  6.  Data Replicationの設定
    以下のボタンを押下して、Data Replication機能を使用した共有ファイルシステムを作成します。
    ボタン

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

      項目   入力/選択する値   備考  
      Please Select Recovery Kit     Data Replication      
      Switchback Type   intelligent  
      Server   プライマリインスタンスのホスト名    
      Hierarchy Type   Replicate New Filesystem  
      Source Disk   /dev/xvdf (8G)   追加ボリューム 
      New Mount point   /data  
      New Filesystem Type   ext4  
      Data Replication Resource Tag     datarep-data  
      File System Resource Tag   /data  
      Bitmap File   /opt/LifeKeeper/bitmap__data  
      Enable Asynchronous Replication?     no  
      Target Server セカンダリインスタンスのホスト名  
      Switchback Type   intelligent  
      Template Priority   1  
      Target Priority   10  
      Mount point   /data  
      Root Tag   /data  
      Target Disk   /dev/xvdf (8G)   追加ボリューム
      Data Replication Resource Tag   datarep-data  
      Bitmap File   /opt/LifeKeeper/bitmap__data  
      Replication Path   予備用コミュニケーションパス  
  7.  クラスタリングの完了
    以上まで行えば、以下の状態となります。これで共有ファイルシステムを搭載したクラスタリング環境の完成です。
    7.	クラスタリングの完了

検証してみた

これでAWS上にLifeKeeperの導入は完了しましたが、最後に実際に動作(フェールオーバー)するか確認してみます。しかし、今回の構成ではElastic IPが一つしかないことから、ログインしているインスタンスのNICを落としてしまうと、LifeKeeperGUIも落ちてしまいます。
そのため、セカンダリインスタンスからログインして検証をしてみます。

  1.  Elastic IPをセカンダリインスタンスに関連付ける
    まずは、「インフラ環境を構築してみた」の項番14を参照して、Elastic IPをセカンダリインスタンスに関連付けます。
  2.  LifeKeeperGUIの起動
    LifeKeeperGUIを起動します。

      # lkGUIapp
  3.  LifeKeeperの状態確認
    LifeKeeperGUIへログインします。プライマリインスタンスにてGUIを起動していた場合と表示が逆になっているのを確認します。

    3.	LifeKeeperの状態確認
  4. セカンダリインスタンスへキーペアをアップロード
    セカンダリインスタンスへのホームディレクトリ”/home/ec2-user”へキーペアをアップロードします。
  5. ターミナルをもう一つ起動する。
    ターミナルをもう一つ起動して、セカンダリインスタンスへログインします。
  6. “/data”のマウント状況を確認
    ”/data”がマウントされていないことを確認します。

     $ df –T 
  7.  プライマリインスタンスへログイン
    セカンダリインスタンスからプライマリインスタンスへログインします。

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

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


    9.	LifeKeeperGUIを確認してみる

  10.  “/data”のマウント状況を確認
    もう一度、セカンダリインスタンスにて以下のコマンドを実行します。

      $ df –T
           /dev/md0–   – – ext4 —   – –   16382844–   – -45080–  15482520–   – 1% /data
          ※上記のような表示が出力されます。

ちゃんと切り替わって、ボリュームがマウントされています。
これで正常にフェールオーバーがされていることが確認できました。
※NICを落としたプライマリインスタンスはAWS Management Console から、インスタンスの再起動処理を行えば、アクセスできるようになります。

まとめてみた

AWSでの構築はGUIとなるため直感的に操作しやすいのですが、独自の用語が多く、理解していないと次の作業に取り掛かれない場合があるかと思います。記事内では作業毎に必要なポイントを記載しておりますので、インフラ環境の構築はできるかと思いますが、用語や操作の意味などは別の機会にお調べすることをお勧めします。

なお、LifeKeeper自体は、基本的にウィザードに従えば導入できてしまうため、インフラ環境と必要な資材の準備ができれば難しいことは無いと思います。

LifeKeeperの設定について、疑問点や別の構成で導入する場合等は、豊富に用意されている公式のドキュメントをご参照ください。

次は今回作成した環境にPostgreSQLを導入し、LifeKeeperと連携させてみようと思います。

 

>第2回 「AWS上のLifeKeeper for Linux とPostgreSQLを連携させてみた」を読む

SNSでもご購読できます。