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

フェールオーバー時挙動イメージ
Pocket

前回、AWS上にLifeKeeper for Linux(以降、LifeKeeperと記載)を導入したので、今回はその環境にPostgreSQLを導入してみました。

具体的な構成としては、PostgreSQLを各インスタンスに導入し、プライマリ側のデータベース保存領域を共有ファイルシステム領域(”/data”)配下とします。この状態でLifeKeeperへPostgreSQLを登録することでデータベースの冗長化を行いたいと思います。

インフラ環境について

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

環境設定

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

 項目    設定内容  
  バージョン     PostgreSQL 9.2.18      
  データベース管理ユーザー     postgres
  データベース保存領域   /data/pgsql/data  

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

構成イメージ

環境イメージは以下となります。

Clustering subnet A/Bで起動した各インスタンスに導入したPostgreSQLのデータベース保存領域は”/data/pgsql/data”となっています。
“/data”配下はLifeKeeperのData Replication機能を利用した共有ファイルシステムとなっており、LifeKeeperがPostgreSQLのプロセスおよび、データベース保存領域を管理します。

PostgresSQL構成イメージ

フェールオーバー時の挙動は、セカンダリ側がプライマリへ昇格し、仮想IPの付け替えを行い、共有ファイルシステムを”/data”へマウントした後に、PostgreSQLのプロセスを起動します。
そのため、PostgreSQLはセカンダリ側でもプライマリ側のデータベースと同じものを使用することができるようになります。

フェールオーバー時挙動イメージ

操作の流れ

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

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

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

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

導入してみた

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

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

  1. PostgreSQLの導入
     # yum install -y libxslt.i686
     # yum install -y postgresql postgresql-server postgresql-devel postgresql-contrib postgresql-docs

     ※ 上記は#からpostgresql-docsまでが1行となります。

  2.  PostgreSQLのバージョン確認
    意図したバージョンが導入されていることを確認します。

      # psql –version
              psql (PostgreSQL) 9.2.18
  3.  postgresユーザーのPW設定
      # passwd postgres
  4.  postgresユーザーの環境変数設定
      # cp -p /var/lib/pgsql/.bash_profile /var/lib/pgsql/.bash_profile.org
      # vi /var/lib/pgsql/.bash_profile
      PGDATA= /var/lib/pgsql/data
        ↓ ※書き換える
      PGDATA=/data/pgsql/data
  5. データベース保存領域の作成(プライマリインスタンスのみ)
      # mkdir -m 700 -p /data/pgsql/data
      # chown postgres:postgres -R /data/pgsql
  6. データベースの初期化(プライマリインスタンスのみ)
      # su postgres -c “initdb -D /data/pgsql/data”
  7. PostgreSQLの起動(プライマリインスタンスのみ)

      # su postgres -c “pg_ctl start -D /data/pgsql/data”
               server starting

      ※上記表示が出力されることを確認してください。

    ※今回はLifeKeeperと連携させることが目的であるため、データベースへの接続設定や認証設定についてはデフォルトのままとなります。実際にPostgreSQLを使用してサービスを提供する場合は、構成に合った変更を実施してください。
    なお、設定ファイルが配置されている場所は共有ファイルシステム配下となるため、設定ファイルの変更はプライマリインスタンスでのみ行えば自動でレプリケーションされます。

連携させてみた

PostgreSQLの導入が完了しましたので、次はLifeKeeperにて仮想IPリソースおよび、PostgreSQLリソースの作成を行います。なお、項番3までは各インスタンスで行う必要があります。

  1. ブロードキャストPINGの無効化
    仮想IPリソース作成のため、ブロードキャストPINGを無効化します。

      # cp -p LifeKeeper LifeKeeper.org
      # sed -i -e ‘s/NOBCASTPING=0/NOBCASTPING=1/g’ /etc/default/LifeKeeper
  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 -k

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

  3. PostgreSQLのRecovery Kitパッケージの導入
    lkPGSQLを選択し、Enterを押下します。

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

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

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

      項目   入力/選択する値   備考
      Please Select Recovery Kit     PostgreSQL Database  
      Switchback Type   intelligent  
      Server   プライマリインスタンスのホスト名  
      PostgreSQL Executable Location   /usr/bin  
      PostgreSQL Client Executable Location   /usr/bin/psql   
      PostgreSQL Administration Executable       Location   /usr/bin/pg_ctl  
      PostgreSQL data Directory   /data/pgsql/data   共有ファイルシステム領域
      PostgreSQL Port   5432  
      PostgreSQL Socket Path   /tmp/.s.PGSQL.5432  
      Enter Database Administrator User   postgres  
      PostgreSQL Logfile   /tmp/pgsql-5432.lk.log  
      PostgreSQL Database Tag   Pgsql-5432  
      Target Server   セカンダリインスタンスのホスト名  
      Switchback Type   intelligent  
      Template Priority   1  
      Target Priority   10  
      PostgreSQL Executable Location   /usr/bin  
      PostgreSQL Database Tag   Pgsql-5432  
  7. 仮想IPリソースの設定
    以下を参照してIPリソースを設定します。

     IP リソース階層の作成

    なお、Elastic IPはインスタンスかENIに関連付けられるため、LifeKeeperで作成されたElastic IPから仮想IPへアクセスするためには、仮想IPアドレスの付け替えを行う必要があります。今回はLifeKeeperとPostgreSQLの連携が目的のため、仮想IPの付け替えにつきましては記載しませんが、具体的な方法は以下の記事をご確認ください。

    Leveraging Multiple IP Addresses for Virtual IP Address Fail-over in 6 Simple Steps

  8. リソースの完成
    ここまで行えば、以下の状態となります。これで仮想IPとPostgreSQLのリソースの作成が完了しました。
    8.	リソースの完成

検証してみた

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

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

      # lkGUIapp
  3. LifeKeeperの状態確認
    LifeKeeperGUIへログインします。
    LifeKeeperGUIへログイン
  4. “postgres”プロセスの起動状況を確認
    セカンダリインスタンスにて以下のコマンドを実行して”postgres”プロセスが起動していないことを確認します。

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

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

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

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

    7.	LifeKeeperGUIを確認

  8. “postgres”プロセスの起動状況を確認
    もう一度、セカンダリインスタンスにて以下のコマンドを実行します。

      $ ps -ef |grep postgres
              postgres 32000  1 0 19:51 ?        00:00:00 /usr/bin/postgres -D /data/pgsql/data -i -k /tmp -p 5432
              postgres 32001 32000 0 19:51 ?        00:00:00 postgres: logger process
              postgres 32029 32000 0 19:51 ?        00:00:00 postgres: checkpointer process
              postgres 32030 32000 0 19:51 ?        00:00:00 postgres: writer process
              postgres 32031 32000 0 19:51 ?        00:00:00 postgres: wal writer process
              postgres 32032 32000 0 19:51 ?        00:00:00 postgres: autovacuum launcher process
              postgres 32033 32000 0 19:51 ?        00:00:00 postgres: stats collector process

            ※上記のような表示が出力されます。 

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

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

まとめてみた

今回はLifeKeeperとPostgreSQLの連携をさせてみましたが、ポイントとしては、PostgreSQLのデータベース保存領域を、LifeKeeper管理下の共有ファイルシステム領域に設定することだと思います。

この設定さえできれば、あとは専用のRecovery Kitパッケージのウィザードに従って、簡単に導入ができます。

なお、記事内でも記載いたしましたが、実際にPostgreSQLを使用してサービス提供をする場合は、設定ファイルへの接続設定や認証設定の変更、仮想IPの付け替えに対するAWS側の設定が必要となりますので、ご注意ください。

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

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

SNSでもご購読できます。