中山テック 代表の中山です。
さて、過去7回に渡って説明させていただいた冗長構成の環境構築。
実際にどこかのサーバが落ちた時も平常運転できるのかを確かめる回です。
早速検証してきましょう。
構成のおさらい
HTTPサーバがKeepAliveでフェイルオーバー対策されていることで主系が落ちても副系が代わりになることが可能です。
この構成は発行されたVIPにアクセスすることでどっちにアクセスするかの切り分けが可能となります。
APIサーバであるTomcatはpgpoolのVIP2にアクセス。
pgpool同士もPostgreSQLも監視下にあるため、どれか一つずつ落ちたとしても通常運行できる想定です。
UI（画面）
冗長構成の動作確認を目的としているのでTomcatに入っているアプリは実に簡素です。
ユーザ追加機能を付けても良いのですが、あらかじめPostgreSQLにログイン情報を仕込み、検索して後続処理が出来る事を確認するため割愛します。
認証に成功するとこのような画面が出ます。
見出し「ようこそ～」内のメールアドレスはログイン画面で認証出来たアドレスを表示しております。
別アドレスを登録して実施も可能。とは言え、かなり簡素な機能となっております。
String psUrl = "jdbc:postgresql://192.168.230.100:9999/nakayama";
String psUser = "postgres";
String psPass = "postgres";JDBCの設定です。
主系が落ちても大丈夫なようにVIPを指定しております。
「nakayama」はログインテーブルがCREATEされたDB名です。
Nginx主系ダウン
Server1をダウン状態にします（シャットダウンですが）。
想定ではKeepAlivedの監視で主系が落ちても副系が代わりを担い正常に表示されることです。
主系(IP末尾132)を落としたら副系(IP末尾133)がHTTPサーバのLISTENを担うようになりました！
もちろん画面表示もログも問題なし！
※サードパーティのエラーはガン無視で進めます
192.168.230.1 - - [24/Feb/2024:23:25:21 +0900] "POST /test-ntech/login HTTP/1.1" 500 2502 "http://192.168.230.50/test-ntech/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36"
192.168.230.1 - - [24/Feb/2024:23:25:21 +0900] "GET /test-ntech/css/common.css HTTP/1.1" 200 2624 "http://192.168.230.50/test-ntech/login" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36"
Tomcat主系ダウン
Tomcatの主系ダウンですが、こちらはKeepAliveによる監視はありません。
しかし、NginxのヘルスチェックによりServer1が落ちていることを確認のうえServer2の方にアクセスしに行く想定。
もちろん表示されました。
が、時間が掛かってます。理由はNginxが無償版だから。
無償版はパッシブヘルスチェックという一度アクセス⇒ダメだからもう片方にアクセスという手間による遅延。
有償版はアクティブヘルスチェックのため、片系が落ちても常に「副系しか今はダメだ！」と判断がつくためアクセスは早いです。
※理由はこちらのサイトを参考にさせて頂きました
pgpoolリーダーダウン
Nginx同様に相互監視（ハートビート）によりリーダーが落ちたらメンバーがリーダーに昇格する想定。
この辺の動きはこちらのブログで検証済みのため、問題ない認識です。
※pgpoolはTomcatと同じサーバにいまして、前項でサーバ落として動作確認してるため、pgpoolのみ落とします
systemctl stop pgpool-II.service念のため、副系の状態を確認します。
[postgres@study_04 ~]$ pcp_watchdog_info -p 9898 -U postgres -h localhost -v
Password:
Watchdog Cluster Information
Total Nodes : 2
Remote Nodes : 1
Member Remote Nodes : 1
Alive Remote Nodes : 0
Nodes required for quorum: 1
Quorum state : QUORUM IS ON THE EDGE
Local node escalation : YES
Leader Node Name : 192.168.230.131:9999 Linux study_04
Leader Host Name : 192.168.230.131
Watchdog Node Information
Node Name : 192.168.230.131:9999 Linux study_04
Host Name : 192.168.230.131
Delegate IP : 192.168.230.100
Pgpool port : 9999
Watchdog port : 9000
Node priority : 1
Status : 4
Status Name : LEADER
Membership Status : MEMBER
Node Name : 192.168.230.130:9999 Linux study_03
Host Name : 192.168.230.130
Delegate IP : 192.168.230.100
Pgpool port : 9999
Watchdog port : 9000
Node priority : 1
Status : 10
Status Name : SHUTDOWN
Membership Status : MEMBER主系がIPの末尾「130」、SHUTDOWNとなっているので末尾「131」がリーダーに変更になりました。
これで準備は完了です。
問題なし！素晴らしき冗長構成！
PostgreSQLのPRIMARYダウン
こちらはpgpoolによるPostgreSQL監視が聞いてるので副系がPRIMARYになり、処理に影響はない認識です。
ただ、検証終了後「pcp_attach」にてダウンした主系をup状態にしてあげる必要があります。
node_id | hostname | port | status | pg_status | lb_weight | role | pg_role | select_cnt | load_balance_node | replication_delay | replication_state | replication_sync_state | last_status_change
---------+-----------------+------+--------+-----------+-----------+---------+---------+------------+-------------------+-------------------+-------------------+------------------------+---------------------
0 | 192.168.230.128 | 5432 | down | down | 0.500000 | standby | unknown | 0 | false | 0 | | | 2024-02-25 00:02:07
1 | 192.168.230.129 | 5432 | up | up | 0.500000 | primary | primary | 0 | true | 0 | | | 2024-02-25 00:02:33
ひとまず副系がPrimaryに昇格。主系は無事down状態となりました。
※データ差分があったので「pg_backup」でリカバリを行ってはおりますが・・・
さて、結果は・・・
もちろん、行きました！
ただPostgreSQLの起動と停止を繰り返しているとロックが掛かることもあり、慎重に操作しましょう。
※本当にデリケートです・・・
"pgpool-2024-02-25_002756.log" [readonly] 223L, 19177C
+ OLD_MAIN_NODE_ID=0
+ OLD_PRIMARY_NODE_ID=0
+ NEW_MAIN_NODE_PORT=5432
+ NEW_MAIN_NODE_PGDATA=/var/lib/pgsql/15/data
+ OLD_PRIMARY_NODE_HOST=192.168.230.128
+ OLD_PRIMARY_NODE_PORT=5432
+ PGHOME=/usr/pgsql-15
+ REPL_SLOT_NAME=192_168_230_128
+ POSTGRESQL_STARTUP_USER=postgres
+ SSH_KEY_FILE=id_rsa_pgpool
+ SSH_OPTIONS='-p 50022 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -i ~/.ssh/id_rsa_pgpool'
+ echo failover.sh: start: failed_node_id=0 failed_host=192.168.230.128 old_primary_node_id=0 new_main_node_id=1 new_main_host=192.168.230.129
failover.sh: start: failed_node_id=0 failed_host=192.168.230.128 old_primary_node_id=0 new_main_node_id=1 new_main_host=192.168.230.129
+ '[' 1 -lt 0 ']'
+ ssh -T -p 50022 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -i '~/.ssh/id_rsa_pgpool' postgres@192.168.230.129 ls /tmp
Warning: Permanently added '[192.168.230.129]:50022' (ECDSA) to the list of known hosts.^M
+ '[' 0 -ne 0 ']'
+ '[' 0 '!=' -1 -a 0 '!=' 0 ']'
+ echo failover.sh: primary node is down, promote new_main_node_id=1 on 192.168.230.129.
failover.sh: primary node is down, promote new_main_node_id=1 on 192.168.230.129.
+ ssh -T -p 50022 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -i '~/.ssh/id_rsa_pgpool' postgres@192.168.230.129 /usr/pgsql-15/bin/pg_ctl -D /var/lib/pgsql/15/data -w promote
Warning: Permanently added '[192.168.230.129]:50022' (ECDSA) to the list of known hosts.^M
2024-02-25 00:32:54.838: health_check0 pid 3197: LOG: failed to connect to PostgreSQL server on "192.168.230.128:5432", getsockopt() failed
2024-02-25 00:32:54.838: health_check0 pid 3197: DETAIL: Operation now in progress
2024-02-25 00:32:54.838: health_check0 pid 3197: LOG: health check retrying on DB node: 0 (round:2)
サーバーの昇格を待っています....完了
サーバーは昇格しました
+ '[' 0 -ne 0 ']'
+ echo failover.sh: end: new_main_node_id=1 on 192.168.230.129 is promoted to a primary
failover.sh: end: new_main_node_id=1 on 192.168.230.129 is promoted to a primary
+ exit 0pgpoolはPostgreSQLを監視し、片系が落ちたのを確認したら昇格する役割を担っています。
結果はログを参照しましょう！もしこのメッセージが出なければpgpool側の設定が悪さをしている可能性があります。
まとめ
PostgreSQLに苦戦を強いられましたが何とか個別での検証は完了です。
このように高可用性のサーバを構築することが良質なサービスを提供できる近道なのです。
実際に運用するとなるとアクセス数次第では多くのサーバを立ち上げるのが吉。
是非皆様も試してみてください！
※今回でVMWare × CentOSシリーズは終了です！
