前回、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のプロセスおよび、データベース保存領域を管理します。
フェールオーバー時の挙動は、セカンダリ側がプライマリへ昇格し、仮想IPの付け替えを行い、共有ファイルシステムを”/data”へマウントした後に、PostgreSQLのプロセスを起動します。
そのため、PostgreSQLはセカンダリ側でもプライマリ側のデータベースと同じものを使用することができるようになります。
操作の流れ
以下の流れで導入を行います。
■導入してみた
PostgreSQLを導入してみました。
■連携させてみた
LifeKeeperとPostgreSQLを連携させてみました。
■検証してみた
擬似的に障害を発生させ、フェールオーバーを確認してみました。
導入してみた
各インスタンスにPostgreSQLを導入します。基本的にコマンドラインでの操作となります。
※コマンドラインのプロンプトは「$」がログインユーザーとなり、「#」がrootユーザーとなります。
rootユーザーへのスイッチは”su -”で変更してください。
- PostgreSQLの導入
# yum install -y libxslt.i686
# yum install -y postgresql postgresql-server postgresql-devel postgresql-contrib postgresql-docs※ 上記は#からpostgresql-docsまでが１行となります。
- PostgreSQLのバージョン確認
意図したバージョンが導入されていることを確認します。# psql –version
psql (PostgreSQL) 9.2.18 - postgresユーザーのPW設定
# passwd postgres - 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 - データベース保存領域の作成（プライマリインスタンスのみ）
# mkdir -m 700 -p /data/pgsql/data
# chown postgres:postgres -R /data/pgsql - データベースの初期化（プライマリインスタンスのみ）
# su postgres -c “initdb -D /data/pgsql/data” - PostgreSQLの起動（プライマリインスタンスのみ）
# su postgres -c “pg_ctl start -D /data/pgsql/data”
server starting※上記表示が出力されることを確認してください。
※今回はLifeKeeperと連携させることが目的であるため、データベースへの接続設定や認証設定についてはデフォルトのままとなります。実際にPostgreSQLを使用してサービスを提供する場合は、構成に合った変更を実施してください。
なお、設定ファイルが配置されている場所は共有ファイルシステム配下となるため、設定ファイルの変更はプライマリインスタンスでのみ行えば自動でレプリケーションされます。
連携させてみた
PostgreSQLの導入が完了しましたので、次はLifeKeeperにて仮想IPリソースおよび、PostgreSQLリソースの作成を行います。なお、項番3までは各インスタンスで行う必要があります。
- ブロードキャストPINGの無効化
仮想IPリソース作成のため、ブロードキャストPINGを無効化します。# cp -p LifeKeeper LifeKeeper.org
# sed -i -e ‘s/NOBCASTPING=0/NOBCASTPING=1/g’ /etc/default/LifeKeeper - イメージファイルのマウント
# 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 - PostgreSQLのRecovery Kitパッケージの導入
lkPGSQLを選択し、Enterを押下します。
- LifeKeeperGUIの起動
プライマリインスタンスにてLifeKeeperGUIを起動します。# lkGUIapp - ログイン
インスタンスのrootユーザーでログインします。 - 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 - 仮想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
- リソースの完成
ここまで行えば、以下の状態となります。これで仮想IPとPostgreSQLのリソースの作成が完了しました。
検証してみた
LifeKeeperとPostgreSQLの連携が完了しましたので、最後に実際に動作（フェールオーバー）するか確認してみます。今回もElastic IPが一つしかないことから、セカンダリインスタンスからログインして検証してみます。
- Elastic IPをセカンダリインスタンスに関連付ける
AWS Management ConsoleにてElastic IPをセカンダリインスタンスに関連付けます。 - LifeKeeperGUIの起動
セカンダリインスタンスへログインしたら、LifeKeeperGUIを起動します。# lkGUIapp - LifeKeeperの状態確認
LifeKeeperGUIへログインします。
- “postgres”プロセスの起動状況を確認
セカンダリインスタンスにて以下のコマンドを実行して”postgres”プロセスが起動していないことを確認します。$ ps –ef | grep postgres - プライマリインスタンスへログイン
セカンダリインスタンスにて以下のコマンドを実行して、プライマリインスタンスへログインします。$ ssh –i <キーペア名> ec2-user@<プライマリインスタンスのプライマリプライベートIP> - プライマリインスタンスで擬似的に障害を発生させる
プライマリインスタンスのNICを落とすことで、擬似的に障害を発生させます。
プライマリインスタンスで以下のコマンドを実行します。# service network stop
※ ifdownコマンドでも問題ありません。 - LifeKeeperGUIを確認してみる
プライマリインスタンスにてコマンドを実行後、暫くすると以下の表示になりました。
右側で表示されていたAct表示が、左に移動しています。また、プライマリインスタンスが異常となったため、左ペインやインスタンスの画像に下記の注意マークがついています。
- “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を導入してみようと思います。
