目的
- HAについての勉強として、PG-REXをVM環境に構築する
- 手順書はコミュニティから公開されているので、それを試してみる
PG-REXとは
- PostgreSQLの同期レプリケーションとPacemakerを組み合わせたHAクラスタの名称
- PG-REXは製品名ではない。
- PacemakerがPostgreSQLを管理しており、以下のようなことができる
- 障害検知時の自動フェイルオーバ
- スイッチオーバ
- VIPの管理（PGのマスタ、スレーブを監視して自動で設定してくれる）
- 設定が大変ということで有名？
- 山場はPacemakerの設定
資材の取得先
- PG-REX9.6 構築手順書等
- PostgreSQL 9.6
- Pacemaker-1.1.16
構成の概要
NW周り
-
NWの設定は以下のようにする。
※ 手順書だと、NICが6本必要だがそんなに用意できないのでBONDINGなしでやる。
※ ネットマスクは255.255.255.0とする。hostname S-LAN D-LAN IC-LAN 1系 yama 192.168.1.1 192.168.2.1 192.168.3.1 192.168.2.1(※1) 2系 kawa 192.168.1.2 192.168.2.2 192.168.3.2 192.168.2.2(※1) (※1) IC-LANは2本必要以上が推奨のため、今回はD-LANを兼用する。
- 用語説明
- S-LAN：DBがクライアントからの接続を受け付けるのに使用
- D-LAN：DBのレプリケーションに使用
- IC-LAN：Pacemaker同士が死活監視に使用
- 用語説明
-
Pacemaker側で作成する各VIPは以下のようにする。
- ユーザやAPは基本的にVIPを接続先としてDBを使用する。
- VIPはPacemakerが自動で制御してくれるので、フェイルオーバが発生しても接続の変更が不要。
vip-master vip-slave vip-rep 192.168.1.10 192.168.1.20 192.168.2.3 -
用語説明
- vip-master：マスタ接続用のVIP
- vip-slave：スレーブ接続用のVIP
- vip-rep：レプリケーション接続用のVIP
概要図
構築手順
VM準備
- VM作成
- OSはCentOS7.3をインストールする
- NICは4本
- PG-REXとしては3本を使用
- 1本はNATで使用（各RPMを取得する用）
Pacemakerのセットアップ
-
（両系）RPMインストール、セットアップ
- 手順はLinux-HA Japnaのページを参考に進める。
- 注意：PG-REX9.6 構築手順書「3.3. Pacemaker」に必要な設定が書いてあるので、こちらも合わせて参照すること。
- 手順の詳細はリンクを参照してもらうとして、ざっくりの流れは以下のとおり。
- 既存yumリポジトリの設定変更し、新しくPacemakerリポジトリを設定する
- yumでPacemakerをインストール（corosyncもまとめてインストールされる）
- corosync設定（corosyncとは、HAクラスタとして制御するための機能を提供する製品）
- bindnetaddrには自分のIPアドレスを2つ設定する。
(expected_votes: 1にすることで、1つのIPで設定するのも可能) - 1つだけ設定することも可能。ただし、IC-LANが切れると危ないので、複数本のほうが安全という話。
- bindnetaddrには自分のIPアドレスを2つ設定する。
/etc/corosync/corosync.conftotem { version: 2 token: 1000 rrp_mode: active interface { ringnumber: 0 bindnetaddr: 192.168.3.1★ mcastaddr: 239.255.1.1 mcastport: 5405 } interface { ringnumber: 1 bindnetaddr: 192.168.2.1★ mcastaddr: 239.255.1.2 mcastport: 5405 } } logging { syslog_facility: daemon debug: off } quorum { provider: corosync_votequorum expected_votes: 2 }- あとは以下の設定が必要です。「PG-REX9.6 構築手順書」を参照しながら設定すること。
- Pacemakerの設定ファイル（/etc/sysconfig/pacemaker）を編集
- Pacemaker, corosyncのSeviceファイルを編集
- ログ(rsyslog, logconv)の出力設定
- とりあえず、NW監視、ディスク監視も全部やる設定にしておく。
- Pacemaker, corosyncの自動起動を停止
- pg_logconv, ifcheckd の自動起動を設定
- 手順はLinux-HA Japnaのページを参考に進める。
-
動作確認
- （両系）Pacemakerを起動する。
# systemctl start pacemaker- 1系または2系で「crm_mof -fA」を実行して、両ノードがOnlineになればOK！
# crm_mon -fA 2 nodes configured 0 resources configured Online: [ kawa yama ]★ No active resources Node Attributes: * Node kawa: + ringnumber_0 : 192.168.3.2 is UP + ringnumber_1 : 192.168.2.2 is UP * Node yama: + ringnumber_0 : 192.168.3.1 is UP + ringnumber_1 : 192.168.2.1 is UP Migration Summary: * Node yama: * Node kawa: -
（両系）Pacemaker停止
# systemctl stop pacemaker
やることは多いけど、意外と簡単にできた気がする。
PostgreSQLのセットアップ
「PG-REX9.6 構築手順書」を参照しながら作業を進める。
流れはこんなところ。
- （両系）RPMインストール
- （両系）/dbfp とその配下のディレクトリを作成
- PG-REXでは、PostgreSQLの領域は/dbfp配下をデフォルトとしている
- PGDATAの領域：/dbfp/pgdata
- WALの領域：/dbfp/pgxlog
- アーカイブログの領域：/dbfp/pgarch/arc1
- PG-REXでは、PostgreSQLの領域は/dbfp配下をデフォルトとしている
- （1系）initdb を実行する
- 2系はpg_basebackupで構築するので、以降は1系のみで操作する。
-
postgresql.confを推奨値に変更する
postgresql.conflisten_addresses = '*' wal_level = replica max_wal_senders = 4 wal_keep_segments = 32 hot_standby = on max_standby_streaming_delay = -1 max_standby_archive_delay = -1 archive_mode = on archive_command = '/bin/cp %p /dbfp/pgarch/arc1/%f' #synchronous_standby_names = '' synchronous_commit = on restart_after_crash = off wal_sender_timeout = 20s wal_receiver_status_interval = 5s hot_standby_feedback = on replication用のユーザ(repuser)作成
-
pg_hba.confを設定する
本当は必要な口しか開けないほうがよいが、手元環境なのでザル設定にする。pg_hba.confhost all all 192.168.1.0/24 trust host replication repuser 192.168.2.0/24 trust
PG-REX運用補助ツールのセットアップ
-
（両系）PG-REX運用補助ツールをインストールする
名前のとおり運用補助ツールとはPG-REXの操作を行うための便利ツール。これがないと手順がより複雑になるので必須。# wget https://ja.osdn.net/projects/pg-rex/downloads/68042/pg-rex96-1.0.2-CentOS7-NoSTONITH-1.tar.gz # tar -xvf pg-rex96-1.0.2-CentOS7-NoSTONITH-1.tar.gz # cd pg-rex96-1.0.2-CentOS7-NoSTONITH-1 # rpm -ivh Net_OpenSSH-0.62-1.el7.x86_64.rpm IO_Tty-1.11-1.el7.x86_64.rpm pg-rex_operation_tools_script-1.8.1-1.el7.noarch.rpm Preparing... ################################# [100%] Updating / installing... 1:Net_OpenSSH-0.62-1.el7 ################################# [ 33%] 2:pg-rex_operation_tools_script-1.8################################# [ 67%] 3:IO_Tty-1.11-1.el7 ################################# [100%] -
（両系）運用補助ツールの設定を行う
/etc/pg-rex_tools.confD-LAN_IPAddress = 192.168.2.1 , 192.168.2.2 Archive_dir = /dbfp/pgarch/arc1 STONITH = disable VIP_SLAVE = enable PGPATH = /usr/pgsql-9.6/bin DISKD_ResourceID = clnDiskd1 ssh鍵交換（必須ではない）
運用補助ツールはD-LAN上でrootでssh接続を行っています。今回はお試しなので、操作を端折るために鍵交換しておきます。
注意：利用マニュアル上では、セキュリティを考慮して必要に応じてpasswordを入力することを推奨しています。
PG-REXの構築
ココが最後にして最大級にややこしい部分なので、気を引き締めて作業しよう！
-
リソースエージェントの概要
- 手順ではないけど、簡単に リソースエージェント（以降、RAと呼ぶ）の説明
- RAとは、Pacemakerが監視を行うために使用するシェルスクリプト。
- PacemakerはRAから吸い上げた情報を元にクラスタを管理している。
- 例えば、PingRAというNWを監視するRAがあるが、こいつがOKを返せばNWは正常、NGになれば故障として検知する仕組みになっている。
- PG-REXは、PostgreSQLを監視するRA、NWを監視するRA、ディスクを監視するRA、VIPのRA等、様々なRAによって成り立っている。
- 手順ではないけど、簡単に リソースエージェント（以降、RAと呼ぶ）の説明
-
RAの設定表（xls）の編集を行う
おそらくココが一番むずかしい。。。どこの行を修正すべきかわかりにくい。。。設定ファイルは「pg-rex96-1.0.2-CentOS7-NoSTONITH-1.tar.gz」に同梱されている「PG-REX9.6_RHEL7_NoSTONITH_pm_crmgen.xls」というファイル。
※エクセルが無い場合、googleスプレッドシートを使えば編集できる。
- 基本的にオレンジの枠を設定していく（見やすくしてくれて助かる）
- 今回の環境では、監視対象のディスクが1つしかないので、以下の項目は今回は使用しないのでコメントアウト（A列に「#」を追記）した
- prmDiskd2, clnDiskd2, diskcheck_status の項目
- 48, 48, 228-240, 248, 249, 264, 275行目をコメントアウト
- prmDiskd2, clnDiskd2, diskcheck_status の項目
修正した設定表をcsv形式に変換し、winscp等で 1系 に送る
-
（1系）csvファイルをcrm形式に変換する
# # pm_crmgen -o PG-REX9.6_RHEL7_NoSTONITH_pm_crmgen.crm PG-REX9.6_RHEL7_NoSTONITH_pm_crmgen.csv # ls -l PG-REX9.6_RHEL7_NoSTONITH_pm_crmgen.crm -rwxrwx--- 1 root vboxsf 5216 Aug 19 08:16 PG-REX9.6_RHEL7_NoSTONITH_pm_crmgen.crm -
（1系）運用補助ツールを利用してPacemakerとPostgreSQLのマスタを起動する
# pg-rex_master_start PG-REX9.6_RHEL7_NoSTONITH_pm_crmgen.crm -
「crm_mon -fA」で1系がマスタ（以下のようなステータス）になったことを確認する。
- pgsql-data-status : LATEST
- pgsql-status : PRI
Node Attributes: * Node yama: + default_ping_set : 100 + diskcheck_status_internal : normal + master-pgsql : 1000 + pgsql-data-status : LATEST★ + pgsql-master-baseline : 0000000004000098 + pgsql-status : PRI★ + ringnumber_0 : 192.168.3.1 is UP + ringnumber_1 : 192.168.2.1 is UP -
（2系）運用補助ツールを利用してPacemakerとPostgreSQLのスレーブを起動する
# pg-rex_slave_start -b root@192.168.2.1's password: パスワードが入力されました 1. Pacemaker および Corosync が停止していることを確認 ...[OK] 2. 稼働中の Master が存在していることを確認 ...[OK] （・・・中略・・・） 9. Slave の起動 (アーカイブリカバリ対象 WAL セグメント数: 1) ...[OK] 10. Slave の起動確認 ...[OK] ノード(kawa)が Slave として起動しました -
PG-REX構成完成！
pg-rex_slave_startコマンドが完了していれば、以下のように2系がsync状態になっているはず。* Node kawa: + default_ping_set : 100 + diskcheck_status_internal : normal + master-pgsql : 100 + pgsql-data-status : STREAMING|SYNC + pgsql-status : HS:sync + ringnumber_0 : 192.168.3.2 is UP + ringnumber_1 : 192.168.2.2 is UP
FOの動作確認
せっかく組んだので、試しにFOをさせてみます。
一つのコンソールで「crm_mon -fA」を動かしておくことで、変化を見れるのでおすすめ。
1系（現在、マスタとして稼働中）のPostgreSQLを強制停止してい挙動を確認してみます。
# su - postgres
$ pg_ctl -m immediate stop
サーバ停止処理の完了を待っています....完了
サーバは停止しました
crm_monの結果が以下のようになり、2系がマスタとなり、FOが完了したことを確認できました。
* Node kawa:
+ default_ping_set : 100
+ diskcheck_status_internal : normal
+ master-pgsql : 1000
+ pgsql-data-status : LATEST
+ pgsql-master-baseline : 00000000060003E0
+ pgsql-status : PRI
+ ringnumber_0 : 192.168.3.2 is UP
+ ringnumber_1 : 192.168.2.2 is UP
もちろん、VIPも2系に貼り変わっているので、APはそのままサービスを継続できます。
最後、PacemakerとPostgreSQLを停止したいときは「pg-rex_stop」でOK。
さいごに
いちから作ってみてわかったのが、やはり一番難しいのは、「RAの設定表（xls）の編集」でした。
pg-rex_master_startコマンドが失敗する場合、十中八九、設定ファイルのどこかが間違っています。
実際、今回作ってみてRAを定義する設定ファイルの修正に一番時間が掛かりました。
一応、Pacemakerのログとかは、/var/log/ha-log に出ていますが、中身を読んで何が起きているのか理解するのは結構たいへんです。
とは言いつつ、やってやれないことはないので、ぜひチャレンジしてHAなPostgreSQLライフを楽しんでください。