VMware 仮想サーバ上でのクラスタ構成について
下記構成でVMwareにてサーバを立てた上で、冗長構成を構築していますが、セカンダリ機セットアップ時に失敗してしまいます。
ホスト名、HA用のIPを指定しようと考えていますが、プライマリ機及びセカンダリ機で入力するセットアップコマンドについては、下記になる認識で合っていますでしょうか。
また、冗長化する際に事前に設定しておくべき項目はありますでしょうか。
---------
■ 構成
□ 共通
OS ：CentOS7.9
kompiraバージョン ：1.6.8-bin
□ プライマリ機
ホスト名 ：mgr-cluster-test01
サービス用ネットワークデバイス ：ens160
サービス用IPアドレス ：xxx.xxx.xxx.192
HA用ネットワークデバイス ：ens192
HA用IPアドレス ：xxx.xxx.xxx.248
VIP ：xxx.xxx.xxx.196
□ セカンダリ機
ホスト名 ：mgr-cluster-test02
サービス用ネットワークデバイス：ens160
サービス用IPアドレス ：xxx.xxx.xxx.194
HA用ネットワークデバイス ：ens192
HA用IPアドレス ：xxx.xxx.xxx.206
■セットアップコマンド
プライマリ機
PRIMARY_NAME=mgr-cluster-test01 SECONDARY_NAME=mgr-cluster-test02 ./setup_cluster.sh --primary --manual-heartbeat --heartbeat-primary=xxx.xxx.xxx.248 --heartbeat-secondary=xxx.xxx.xxx.206 xxx.xxx.xxx.196/24
セカンダリ機
PRIMARY_NAME=mgr-cluster-test01 SECONDARY_NAME=mgr-cluster-test02 ./setup_cluster.sh --secondary --manual-heartbeat --heartbeat-primary=xxx.xxx.xxx.248 --heartbeat-secondary=xxx.xxx.xxx.206
■セカンダリ機スクリプト実行時のエラー
[2023-10-12 11:46:29] VERBOSE: run: sudo -u postgres pg_basebackup -h ha-kompira-other -U repl -D /var/lib/pgsql/12/data -X stream --checkpoint=fast -P
pg_basebackup: エラー: サーバに接続できませんでした: ホストへの経路がありません
サーバはホスト "ha-kompira-other" (xxx.xxx.xxx.248) で稼動しており、
また、ポート 5432 で TCP/IP 接続を受け付けていますか?
[2023-10-12 11:46:29] VERBOSE: status=1
[2023-10-12 11:46:29] ERROR: Backup FAILED!: restore /var/lib/pgsql/12/data
-
正式なコメント
ご確認ありがとうございます。
サービス用IPおよび、HA用IPは同一ネットワークとなっております。
VIPについても同一のネットワークを指定しておりました。こちら十分確認が取れてはいないのですが、サービス用IPおよびHA用IPは、個別のNICを別のネットワークで接続して異なるネットワークアドレスを割り当てていただくことを（暗黙的な）前提としていて、同一ネットワークであった場合の動作確認などは行われていない可能性がございます。
お手数ですが、両サーバのHA用IPアドレスについて、サービス用とは異なるネットワークで接続して異なるネットワークアドレスを割り当てて再度試してみていただくことは可能でしょうか。（現時点でこれで改善するという確証は得られてはいないため、状況変わらない可能性もございます）
VIP は外部からアクセスする用途のため、合わせるのであればサービス用ネットワークアドレスにしていただくのがよいかと思います。
以上、よろしくお願いいたします。
コメントアクション -
フィックスポイントの高橋です。
ホスト名、HA用のIPを指定しようと考えていますが、プライマリ機及びセカンダリ機で入力するセットアップコマンドについては、下記になる認識で合っていますでしょうか。
拝見した限りでは問題ないように見受けられます。
セカンダリ機セットアップ時に失敗してしまう、とのことですが、プライマリ機のセットアップは問題なく完了して正常に動作していますでしょうか？
セカンダリ機セットアップを行なう前に、プライマリ機での冗長構成セットアップが完了して、正常にすべてのリソースが起動できている必要があります。プライマリ機側のセットアップと正常起動を確認してから、セカンダリ機のセットアップを開始したか分かりますでしょうか？
現時点での、プライマリ機での各リソースの状況を確認するために、以下のコマンドを実行した結果をご提供いただけますでしょうか。
# crm_mon -rfA1
プライマリ機およびセカンダリ機の冗長構成セットアップ時のログファイル setup_cluster.XXXX.log をご提供いただけますでしょうか。
以上、よろしくお願いいたします。
-
ご回答ありがとうございます。
「crm_mon -rfA1」のコマンドの実行結果は下記になります。
また、セットアップ時のログについてはどのようにお渡しすれば良いでしょうか。
========
[root@mgr-cluster-test01 kompira-1.6.8-bin]# crm_mon -rfA1
Stack: corosync
Current DC: mgr-cluster-test01 (version 1.1.23-1.el7_9.1-9acf116022) - partition with quorum
Last updated: Thu Oct 12 17:15:43 2023
Last change: Thu Oct 12 11:46:33 2023 by root via crm_attribute on mgr-cluster-test012 nodes configured
9 resource instances configuredOnline: [ mgr-cluster-test01 mgr-cluster-test02 ]
Full list of resources:
Resource Group: webserver
res_memcached (systemd:memcached): Started mgr-cluster-test01
res_kompirad (systemd:kompirad): Started mgr-cluster-test01
res_kompira_jobmngrd (systemd:kompira_jobmngrd): Started mgr-cluster-test01
res_httpd (ocf::heartbeat:apache): Started mgr-cluster-test01
res_vip (ocf::heartbeat:IPaddr2): Started mgr-cluster-test01
Master/Slave Set: ms_pgsql [res_pgsql]
Masters: [ mgr-cluster-test01 ]
Stopped: [ mgr-cluster-test02 ]
Clone Set: res_rabbitmq-clone [res_rabbitmq]
Started: [ mgr-cluster-test01 ]
Stopped: [ mgr-cluster-test02 ]Node Attributes:
* Node mgr-cluster-test01:
+ master-res_pgsql : 1001
+ rmq-node-attr-last-known-res_rabbitmq : rabbit@mgr-cluster-test01
+ rmq-node-attr-res_rabbitmq : rabbit@mgr-cluster-test01
* Node mgr-cluster-test02:
+ master-res_pgsql : -1000Migration Summary:
* Node mgr-cluster-test01:
* Node mgr-cluster-test02:
res_pgsql: migration-threshold=1 fail-count=1000000 last-failure='Thu Oct 12 11:56:37 2023'
res_rabbitmq: migration-threshold=1 fail-count=1000000 last-failure='Thu Oct 12 11:56:36 2023'Failed Resource Actions:
* res_pgsql_stop_0 on mgr-cluster-test02 'unknown error' (1): call=38, status=complete, exitreason='Unexpected state for instance "res_pgsql" (returned 1)',
last-rc-change='Thu Oct 12 11:56:37 2023', queued=0ms, exec=109ms
* res_rabbitmq_start_0 on mgr-cluster-test02 'unknown error' (1): call=35, status=Timed Out, exitreason='',
last-rc-change='Thu Oct 12 11:46:35 2023', queued=0ms, exec=600676ms -
ログのご提供ありがとうございます。
ログを拝見したところ、少なくともプライマリ機のセットアップに問題はなく、
セカンダリ機のセットアップ時にデータベースの同期に失敗していることは分かります。HA用ネットワークデバイス間での導通は問題ないであろうと思いますが、
念のため相互に ping 導通できるかなどご確認いただけますでしょうか。また、両サーバでの以下のコマンド実行結果についてご提供いただけますでしょうか。
# iptables -L -v -n
セカンダリ機のセットアップのタイミングの問題、という可能性も考えられるため、
お手数ですが、両サーバの以下のログについて追加でご提供いただけますでしょうか。- /var/log/cluster/*
- /var/log/postgresql/*
- /var/log/rabbitmq/*以上、よろしくお願いいたします。
-
ログのご提供ありがとうございます。
セカンダリ機の postgresql ログを確認したところ、以下のようなエラーが記録されていました。
2023-10-12 11:46:35.685 JST:::9226[3]:FATAL: hot standby is not possible because max_wal_senders = 4 is a lower setting than on the master server (its value was 10)
弊社内で確認したところ、2台のサーバの設定ファイル /var/lib/pgsql/12/standby.conf にある
max_wal_senders = 4
という行を、片方だけ別の値（プライマリ側を大きな値）に変更してみたところ、
セカンダリ機で sync_master.sh を実行すると同様のエラーが記録されて、
データベースの同期ができずに起動に失敗するという現象が再現できました。この設定が合っていない可能性が考えられますので、お手数ですが、
両サーバで以下のコマンドを実行した結果をいただけますでしょうか。find /var/lib/pgsql/12 -name "*.conf" | xargs grep max_wal_senders
以上、よろしくお願いいたします。
-
ご連絡遅くなりまして申し訳ございません。
コマンドの実行結果は下記となります。
お手数ですが、ご確認いただきますようお願い致します。
======
■プライマリ機
[root@mgr-cluster-test01 ~]# find /var/lib/pgsql/12 -name "*.conf" | xargs grep max_wal_senders
/var/lib/pgsql/12/data/postgresql.conf:#max_wal_senders = 10 # max number of walsender processes
/var/lib/pgsql/12/standby.conf:max_wal_senders = 4■セカンダリ機
[root@mgr-cluster-test02 log]# find /var/lib/pgsql/12 -name "*.conf" | xargs grep max_wal_senders
/var/lib/pgsql/12/standby.conf:max_wal_senders = 4
/var/lib/pgsql/12/data/postgresql.conf:#max_wal_senders = 10 # max number of walsender processes -
コマンドの実行結果ありがとうございます。
設定ファイルとして正しいように見受けられます。設定が実行時に適用されていない可能性が考えられますので、お手数ですが、
プライマリ機で以下のコマンドを実行した結果をいただけますでしょうか。psql -U postgres -x -c "SELECT * FROM pg_settings WHERE name='max_wal_senders';"
もし、この実行結果で settings の行が 4 となっていない場合、全ての設定を
以下のようにファイルに出力していただいて、ファイル pg_settings.txt をご提供いただけますでしょうか。psql -U postgres -x -c "SELECT * FROM pg_settings" > pg_settings.txt
以上、よろしくお願いいたします。
-
ご教示頂きましたコマンドを実行したところ、プライマリ機での実行結果settingの値は4になっています。
========
HERE name='max_wal_senders';"
-[ RECORD 1 ]---+------------------------------------------------------------------------
name | max_wal_senders
setting | 4
unit |
category | Replication / Sending Servers
short_desc | Sets the maximum number of simultaneously running WAL sender processes.
extra_desc |
context | postmaster
vartype | integer
source | configuration file
min_val | 0
max_val | 262143
enumvals |
boot_val | 10
reset_val | 4
sourcefile | /var/lib/pgsql/12/data/../standby.conf
sourceline | 3
pending_restart | f以上、宜しくお願い致します。
-
ご確認ありがとうございます。
これらの結果から、プライマリ側の postgresql の設定は正しく、またその設定は動作中のサービスにも適用されているように見受けられます。
セカンダリ側の postgresql が起動に失敗したログと合致していないのが腑に落ちませんが、セカンダリ側の一時的な問題があった可能性も考えられます。
セカンダリ側で同期回復を実施するコマンドを実行してみていただけますでしょうか。成功するとプライマリ側に同期回復することになります。
/opt/kompira/bin/sync_master.sh
このコマンドの実行結果についてご提供いただけますでしょうか。
以上、よろしくお願いいたします。
-
ご教示頂きました通り、セカンダリ側で同期回復のコマンドを実行しましたところ、同期回復に失敗しているようです。お手数ですがご確認をお願いします。
====
[2023-10-17 14:19:34] ****: ****************************************************************
[2023-10-17 14:19:34] ****: Kompira-1.6.8:
[2023-10-17 14:19:34] ****: Start: Sync with the Master
[2023-10-17 14:19:34] ****:
[2023-10-17 14:19:34] INFO: SYSTEM = CENT
[2023-10-17 14:19:34] INFO: SYSTEM_NAME = cent7
[2023-10-17 14:19:34] INFO: SYSTEM_RELEASE = CentOS Linux release 7.9.2009 (Core)
[2023-10-17 14:19:34] INFO: SYSTEM_RELEASEVER = 7.9.2009
[2023-10-17 14:19:34] INFO: PLATFORM_PYTHON = /usr/libexec/platform-python
[2023-10-17 14:19:34] INFO: PYTHON = /usr/bin/python3.6
[2023-10-17 14:19:34] INFO: SYSTEMD = true
[2023-10-17 14:19:34] INFO: TMPDIR = /tmp
[2023-10-17 14:19:34] ****: ----------------------------------------------------------------
[2023-10-17 14:19:34] ****: Check cluster status.
[2023-10-17 14:19:34] ****:
[2023-10-17 14:19:34] WARN: PostgreSQL is stop (rc=2)
[2023-10-17 14:19:34] INFO: Pacemaker is running (SLAVE)
[2023-10-17 14:19:34] INFO: HA_LOCALNAME=mgr-cluster-test02
[2023-10-17 14:19:34] INFO: HA_OTHERNAME=mgr-cluster-test01
[2023-10-17 14:19:34] WARN: PostgreSQL is stop (rc=2)
[2023-10-17 14:19:34] INFO: PostgreSQL on this node needs to be synchronized with the Master.
[2023-10-17 14:19:34] INFO: Enter the pacemaker in maintenance mode.
[2023-10-17 14:19:34] VERBOSE: run: pcs property set maintenance-mode=true
[2023-10-17 14:19:35] VERBOSE: run: pcs resource debug-stop res_pgsql
Operation stop for res_pgsql:0 (ocf:heartbeat:pgsqlms) returned: 'unknown error' (1)
> stdout: /tmp:5432 - no response
> stdout: pg_ctl: no server running
> stderr: ocf-exit-reason:Instance "res_pgsql" controldata indicates a running secondary instance, the instance has probably crashed
> stderr: ocf-exit-reason:Unexpected state for instance "res_pgsql" (returned 1)
[2023-10-17 14:19:35] VERBOSE: status=1
[2023-10-17 14:19:35] VERBOSE: run: rm -f /var/lib/pgsql/12/tmp/PGSQL.lock
[2023-10-17 14:19:35] VERBOSE: run: rm -rf /var/lib/pgsql/12/data.old
[2023-10-17 14:19:35] VERBOSE: run: mv -f /var/lib/pgsql/12/data /var/lib/pgsql/12/data.old
[2023-10-17 14:19:35] VERBOSE: run: sudo -u postgres pg_basebackup -h ha-kompira-other -U repl -D /var/lib/pgsql/12/data -X stream --checkpoint=fast -P
pg_basebackup: エラー: サーバに接続できませんでした: ホストへの経路がありません
サーバはホスト "ha-kompira-other" (xxx.xxx.xxx.248) で稼動しており、
また、ポート 5432 で TCP/IP 接続を受け付けていますか?
[2023-10-17 14:19:35] VERBOSE: status=1
[2023-10-17 14:19:35] ERROR: Backup FAILED!: restore /var/lib/pgsql/12/data
[2023-10-17 14:19:35] ERROR: Failed to backup the database.
[2023-10-17 14:19:35] INFO: Exit the pacemaker from maintenance mode.
[2023-10-17 14:19:35] VERBOSE: run: pcs property set maintenance-mode=false
[2023-10-17 14:19:35] ERROR:
[2023-10-17 14:19:35] ERROR: Failed to sync with ha-kompira-other.
[2023-10-17 14:19:35] ERROR:
[2023-10-17 14:19:35] ****:
[2023-10-17 14:19:35] ****: Finish: Sync with the Master (status=1)
[2023-10-17 14:19:35] ****: **************************************************************** -
ご回答いただきありがとうございます。
ログにつきましては、昨日時点の内容を取得しており、セカンダリサーバ上のログファイルも確認いたしましたが更新されておりませんでした。また、発生している事象に対してサーバおよび、冗長化コマンドの観点から対応を行っておりましたので内容を記載させていただきます。
内容としては、両サーバを初期状態まで復元し、kompiraのインストールから行ったところ、今回の事象と同様にセカンダリ機セットアップ時に失敗しておりました。
その後、両機を冗長化コマンドを実行する前の状態に復元した上で、以下のコマンドを実行したところ、両機ともに正常に処理が完了しておりステータスも異常が見受けられませんでした。
しかし、冗長化を行うにあたっては両機のHA用IPを固定しておきたいと考えており、以下のコマンドでは、実行後に両機のHA用IPが変更されるので問題があります。
-------------
■プライマリ機
./setup_cluster.sh --primary --heartbeat-device ens192 xxx.xxx.xxx.196■セカンダリ機
./setup_cluster.sh --secondary --heartbeat-device ens192
-------------以上が対応していた内容になります。
お手数ですが、ご確認いただきますようお願い致します。
-
ご確認ありがとうございます。
ログにつきましては、昨日時点の内容を取得しており、セカンダリサーバ上のログファイルも確認いたしましたが更新されておりませんでした。
弊社での実験では、max_wal_senders を不整合にした状態でセカンダリサーバで sync_master.sh を実行したところ、同期には失敗するもののセカンダリサーバの postgresql のログにはエラーが記録されていたので、確認させていただきました。御社環境とは状況が異なっているのかもしれませんが、現時点でその要因については見当がついておりません。
内容としては、両サーバを初期状態まで復元し、kompiraのインストールから行ったところ、今回の事象と同様にセカンダリ機セットアップ時に失敗しておりました。その後、両機を冗長化コマンドを実行する前の状態に復元した上で、以下のコマンドを実行したところ、両機ともに正常に処理が完了しておりステータスも異常が見受けられませんでした。
ご確認ありがとうございます。上記結果からは HA 用のデバイスを介した冗長構成はできていると考えられるため、HA 用 IP アドレスに関連して何らかの問題が生じている可能性があるのかもしれません。
当初示していただいた、以下の構成について質問させてください。
□ プライマリ機
ホスト名 ：mgr-cluster-test01
サービス用ネットワークデバイス ：ens160
サービス用IPアドレス ：xxx.xxx.xxx.192
HA用ネットワークデバイス ：ens192
HA用IPアドレス ：xxx.xxx.xxx.248
VIP ：xxx.xxx.xxx.196- サービス用IPの xxx.xxx.xxx. 部と、HA用IP の xxx.xxx.xxx. 部は別ネットワークでしょうか？
- VIP の xxx.xxx.xxx. 部、上記いずれかと同じ、あるいは別ネットワークでしょうか？
以上、よろしくお願いいたします。
サインインしてコメントを残してください。
コメント
19件のコメント