PacemakerでPostgreSQLレプリケーションクラスター構成

Linux,Pacemaker,PostgreSQL,Zabbix

こんにちは。プラットフォーム技術部の佐藤(賢)です。

Zabbixでも必要になるリレーショナルデータベースですが、オンプレミス環境での可用性確保にはさまざまな手法があります。

  • 共有ディスク利用
  • DRBDなどのブロックデバイスレプリケーションを利用
  • データベースのレプリケーション機能を利用

3点目のデータベースレプリケーション機能ですが、Pacemaker/Corosyncを使うと比較的簡単に構築できます。MySQLやMariaDBに関しては日本語の記事も多く出回っているのですが、PostgreSQLに関しては情報をあまり見かけなかったため、紹介したいと思います。

ちなみにクォーラムなしの2ノードクラスターですので、スプリットブレインが起こりうる構成であることをあらかじめご理解ください。

Zabbixの構築や運用のご相談はアークシステムへ！
認定技術者が最適なソリューションをご提供

なぜPostgreSQLなのか

あくまでも個人的見解ですが、以下の理由によります。

  • Zabbixでは大規模データ保持用にTimescaleDBがサポートされるなどPostgreSQLの採用率が高まると考えられる
  • Red Hat Enterprise Linux 8では、アップストリームバージョンがエンドオブライフを迎えてもサポートを続けるのはPostgreSQLとされている（MySQLやMariaDBはアップストリーム、すなわち開発元に依存）

※参照にはサブスクリプションが必要です

今回構築する構成と参考情報

  • CentOS 8.3
  • PostgreSQL 10 （CentOS 8.3同梱）
  • Pacemaker + Corosync + resource-agents （CentOS 8.3同梱）
  • ノード1：pcmk11 （192.168.56.11）
  • ノード2：pcmk12 （192.168.56.12）
  • クラスター名：pcmk10
  • VIP：192.168.56.10

CentOS 8もしくはRed Hat Enterprise Linux 8+High Availability Add-Onで構成できるようにしています。
CentOS 8/RHEL 8ではPostgreSQL 12も利用可能ですが、resource-agentsパッケージ付属のpgsqlリソースエージェントはPostgreSQL 12に対応していないため10を採用しています。

PostgreSQL 12はレプリケーション構成にrecovery.confを使わなくなったためですが、pgsqlリソースエージェントもGitHubの開発版ではrecovery.confを使わない形式にも対応しているようです。

参考にする手順は以下です。

最近のPacemakerではMaster/Slaveセットという考え方ではなく、promotableというメタ属性がtrueに設定されたクローンリソースという考え方になったようです。そのリソース作成方法として3つめのDRBD部分を参考にしています。

なお、両ノードとも/etc/hostsファイルには以下のエントリーを追記済みです。ホスト名も短いホスト名にしています。

1
2
192.168.56.11   pcmk11
192.168.56.12   pcmk12

SELinux、Firewalldは無効化しておりますのでこちらもご理解のほどを。

PostgreSQL単独でのレプリケーション構成

まずはPacemaker関係なく、PostgreSQL単独でのレプリケーション構成を構築します。

ノード1側の作業

PostgreSQLのインストールと初期化を実施します。

1
2
3
4
# yum install postgresql-server
# postgresql-setup --initdb
 * Initializing database in '/var/lib/pgsql/data'
 * Initialized, logs are in /var/lib/pgsql/initdb_postgresql.log

一度起動してレプリケーションユーザーを作成します。

1
2
3
# systemctl start postgresql.service
# sudo -u postgres createuser -P repuser --replication
# systemctl stop postgresql.service

レプリケーションユーザー認証用のパスワードファイルを作成します。パスワード(password)はrepuser作成時に指定したパスワードに合わせます。

1
2
3
# echo '*:5432:replication:repuser:password' > /var/lib/pgsql/.pgpass
# chown postgres: /var/lib/pgsql/.pgpass
# chmod 600 /var/lib/pgsql/.pgpass

PostgreSQLの設定を実施します。スタンバイとして起動される際の設定も含まれています。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
# cat <<__EOF__>> /var/lib/pgsql/data/postgresql.conf
# Server Configuration - Connection Settings
listen_addresses = '*'
 
# Server Configuration - Error Handling
restart_after_crash = off
 
# Write Ahead Log - Setting
wal_level = hot_standby
synchronous_commit = on
 
# Write Ahead Log - Archiving
archive_mode = on
archive_command = 'cp %p /var/lib/pgsql/pg_archive/%f'
 
# Replication - Sending Server
max_wal_senders=5
wal_keep_segments = 32
 
# Replication - Standby Servers
hot_standby = on
max_standby_archive_delay = -1
max_standby_streaming_delay = -1
wal_receiver_status_interval = 2
hot_standby_feedback = on
__EOF__

認証設定をおこないます。セキュリティ面もある程度考慮していますが、稼働優先とご理解ください。

1
2
3
4
5
6
7
8
9
# cat <<__EOF__> /var/lib/pgsql/data/pg_hba.conf
local   all             all                                     peer
host    all             all             127.0.0.1/32            md5
host    all             all             ::1/128                 md5
host    replication     repuser         192.168.56.11/32        md5
host    replication     repuser         192.168.56.12/32        md5
__EOF__
# chown postgres: /var/lib/pgsql/data/pg_hba.conf
# chmod 600 /var/lib/pgsql/data/pg_hba.conf

アーカイブディレクトリーを作成します。

1
2
3
# mkdir /var/lib/pgsql/pg_archive
# chown postgres: /var/lib/pgsql/pg_archive
# chmod 700 /var/lib/pgsql/pg_archive

起動します。

1
2
3
4
5
6
7
8
9
10
# su - postgres
$ pg_ctl -D /var/lib/pgsql/data start
waiting for server to start....2021-03-01 12:00:10.514 JST [5832] LOG:  listening on IPv4 address "0.0.0.0", port 5432
2021-03-01 12:00:10.514 JST [5832] LOG:  listening on IPv6 address "::", port 5432
2021-03-01 12:00:10.517 JST [5832] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2021-03-01 12:00:10.523 JST [5832] LOG:  listening on Unix socket "/tmp/.s.PGSQL.5432"
2021-03-01 12:00:10.531 JST [5832] LOG:  redirecting log output to logging collector process
2021-03-01 12:00:10.531 JST [5832] HINT:  Future log output will appear in directory "log".
 done
server started

ノード2側の作業

続いてノード2側の作業です。ノード1同様にPostgreSQLのインストールと初期化を実施します。

1
2
3
4
# yum install postgresql-server
# postgresql-setup --initdb
 * Initializing database in '/var/lib/pgsql/data'
 * Initialized, logs are in /var/lib/pgsql/initdb_postgresql.log

レプリケーションユーザー認証用のパスワードファイルを作成します。パスワード(password)はrepuser作成時に指定したパスワードに合わせます。

1
2
3
# echo '*:5432:replication:repuser:password' > /var/lib/pgsql/.pgpass
# chown postgres: /var/lib/pgsql/.pgpass
# chmod 600 /var/lib/pgsql/.pgpass

ノード1からデータを複製します。レプリケーションユーザー指定で実施します。

1
2
3
4
# su - postgres
$ rm -rf /var/lib/pgsql/data/*
$ pg_basebackup -h pcmk11 -U repuser -D /var/lib/pgsql/data -X stream -P
23565/23565 kB (100%), 1/1 tablespace

アーカイブディレクトリーを作成します。

1
2
$ mkdir /var/lib/pgsql/pg_archive
$ chmod 700 /var/lib/pgsql/pg_archive

recovery.confを作成します。

1
2
3
4
5
6
7
$ cat <<__EOF__> /var/lib/pgsql/data/recovery.conf
standby_mode = 'on'
primary_conninfo = 'host=pcmk11 port=5432 user=repuser application_name=pcmk12'
restore_command = 'cp /var/lib/pgsql/pg_archive/%f %p'
recovery_target_timeline = 'latest'
__EOF__
$ chmod 600 /var/lib/pgsql/data/recovery.conf

起動します。

1
2
3
4
5
6
7
8
9
$ pg_ctl -D /var/lib/pgsql/data/ start
waiting for server to start....2021-03-01 12:00:15.958 JST [5574] LOG:  listening on IPv4 address "0.0.0.0", port 5432
2021-03-01 12:00:15.958 JST [5574] LOG:  listening on IPv6 address "::", port 542
2021-03-01 12:00:15.960 JST [5574] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2021-03-01 12:00:15.964 JST [5574] LOG:  listening on Unix socket "/tmp/.s.PGSQL.5432"
2021-03-01 12:00:15.972 JST [5574] LOG:  redirecting log output to logging collector process
2021-03-01 12:00:15.972 JST [5574] HINT:  Future log output will appear in directory "log".
 done
server started

ノード1で確認すると、pcmk12（192.168.56.12）に対して同期されていることがわかります。

1
2
3
4
5
6
# su - postgres
$ psql -c "select client_addr,sync_state from pg_stat_replication;"
  client_addr  | sync_state
---------------+------------
 192.168.56.12 | async
(1 row)

PostgreSQL停止

両ノードで起動したPostgreSQLを停止します。

1
2
3
4
5
# su - postgres
$ pg_ctl -D /var/lib/pgsql/data/ stop
waiting for server to shut down.... done
server stopped
$ exit

Pacemakerでのレプリケーション環境構築

両ノードに高可用性パッケージ群を導入し起動します。CentOS 8ではHighAvailabilityリポジトリーは無効化されていますので、––enablerepo=haで一時的に有効化しています。

1
2
3
# yum --enablerepo=ha install pcs pacemaker fence-agents-all
# systemctl start pcsd.service
# systemctl enable pcsd.service

haclusterユーザーにパスワードを設定し、両ノードを認証します。

1
2
3
4
5
6
7
8
9
# passwd hacluster
Changing password for user hacluster.
New password:
passwd: all authentication tokens updated successfully.
# pcs host auth pcmk11 pcmk12
Username: hacluster
Password:
pcmk12: Authorized
pcmk11: Authorized

クラスターを作成し、初期設定をおこないます。

1
2
3
4
5
# pcs cluster setup pcmk10 --start pcmk11 pcmk12
# pcs property set no-quorum-policy="ignore"
# pcs property set stonith-enabled="false"
# pcs resource defaults update resource-stickiness="INFINITY"
# pcs resource defaults update migration-threshold="1"

pcs cluster cibで設定を作成していきます。長いですが主にClusterIPとClusterDBリソースを作成しています。
ClusterIPリソースがレプリケーション元のIPアドレスにもなりますので、マスターと同じノードになるようcolocation制約を設定します。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
# pcs cluster cib db_cfg
 
# pcs -f db_cfg resource create ClusterIP IPaddr2 \
   ip="192.168.56.10" \
   cidr_netmask="24" \
   op start   timeout="60s" interval="0s"  on-fail="restart" \
   op monitor timeout="60s" interval="10s" on-fail="restart" \
   op stop    timeout="60s" interval="0s"  on-fail="block"
 
# pcs -f db_cfg resource create ClusterDB pgsql \
   rep_mode="sync" \
   node_list="pcmk11 pcmk12" \
   restore_command="cp /var/lib/pgsql/pg_archive/%f %p" \
   primary_conninfo_opt="keepalives_idle=60 keepalives_interval=5 keepalives_count=5" \
   master_ip="192.168.56.10" \
   repuser="repuser" \
   restart_on_promote='true' \
   op start   timeout="60s" interval="0s"  on-fail="restart" \
   op monitor timeout="60s" interval="4s"  on-fail="restart" \
   op monitor timeout="60s" interval="3s"  on-fail="restart" role="Master" \
   op promote timeout="60s" interval="0s"  on-fail="restart" \
   op demote  timeout="60s" interval="0s"  on-fail="stop" \
   op stop    timeout="60s" interval="0s"  on-fail="block" \
   op notify  timeout="60s" interval="0s"
 
# pcs -f db_cfg resource promotable ClusterDB notify=true
 
# pcs -f db_cfg constraint colocation add ClusterIP with Master ClusterDB-clone INFINITY
# pcs -f db_cfg constraint order promote ClusterDB-clone then start ClusterIP symmetrical=false score=INFINITY
# pcs -f db_cfg constraint order demote  ClusterDB-clone then stop  ClusterIP symmetrical=false score=0

作成した設定をcib-pushで投入します。

1
# pcs cluster cib-push db_cfg

クラスターステータスを確認するとMaster/Slaveで動作していることが確認できます。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# pcs status
Cluster name: pcmk10
Cluster Summary:
  * Stack: corosync
  * Current DC: pcmk11 (version 2.0.4-6.el8_3.1-2deceaa3ae) - partition with quorum
  * Last updated: Tue Mar  1 12:58:37 2021
  * Last change:  Tue Mar  1 12:58:27 2021 by root via crm_attribute on pcmk11
  * 2 nodes configured
  * 3 resource instances configured
 
Node List:
  * Online: [ pcmk11 pcmk12 ]
 
Full List of Resources:
  * ClusterIP   (ocf::heartbeat:IPaddr2):        Started pcmk11
  * Clone Set: ClusterDB-clone [ClusterDB] (promotable):
    * Masters: [ pcmk11 ]
    * Slaves: [ pcmk12 ]
 
Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

ノード1のPostgreSQLでステータスを確認してみます。

1
2
3
4
5
6
7
# su - postgres
Last login: Tue Mar  1 12:21:57 JST 2021 on pts/0
$ psql -c "select client_addr,sync_state from pg_stat_replication;"
  client_addr  | sync_state
---------------+------------
 192.168.56.12 | sync
(1 row)

クラスター操作

ノード1からノード2へのフェイルオーバー実施

ノード1のPostgreSQLを強制終了してフェイルオーバーさせてみます。

1
# killall -9 postgres

クラスターステータスを確認してみると、ノード2がマスターに昇格したことがわかります。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
# pcs status --full
Cluster name: pcmk10
Cluster Summary:
  * Stack: corosync
  * Current DC: pcmk11 (1) (version 2.0.4-6.el8_3.1-2deceaa3ae) - partition with quorum
  * Last updated: Tue Mar  1 13:05:30 2021
  * Last change:  Tue Mar  1 13:04:06 2021 by root via crm_attribute on pcmk12
  * 2 nodes configured
  * 3 resource instances configured
 
Node List:
  * Online: [ pcmk11 (1) pcmk12 (2) ]
 
Full List of Resources:
  * ClusterIP   (ocf::heartbeat:IPaddr2):        Started pcmk12
  * Clone Set: ClusterDB-clone [ClusterDB] (promotable):
    * ClusterDB (ocf::heartbeat:pgsql):  Master pcmk12
    * ClusterDB (ocf::heartbeat:pgsql):  Stopped
 
Node Attributes:
  * Node: pcmk11 (1):
    * ClusterDB-data-status             : DISCONNECT
    * ClusterDB-status                  : STOP
    * master-ClusterDB                  : -INFINITY
  * Node: pcmk12 (2):
    * ClusterDB-data-status             : LATEST
    * ClusterDB-master-baseline         : 0000000005000140
    * ClusterDB-status                  : PRI
    * master-ClusterDB                  : 1000
 
Migration Summary:
  * Node: pcmk11 (1):
    * ClusterDB: migration-threshold=1 fail-count=1 last-failure='Tue Mar  1 13:04:04 2021'
 
Failed Resource Actions:
  * ClusterDB_monitor_3000 on pcmk11 'not running' (7): call=19, status='complete', exitreason='', last-rc-change='2021-03-01 13:04:04 +09:00', queued=0ms, exec=0ms
 
Tickets:
 
PCSD Status:
  pcmk11: Online
  pcmk12: Online
 
Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

ノード1の復帰

ノード1を復帰させてみます。リソースのエラーカウントをクリアします。

1
# pcs resource cleanup node=pcmk11

ところが復帰しません。pcs statusで確認するとエラー内容がさきほどと変わっています。

1
2
Failed Resource Actions:
  * ClusterDB_start_0 on pcmk11 'error' (1): call=35, status='complete', exitreason='My data may be inconsistent. You have to remove /var/lib/pgsql/tmp/PGSQL.lock file to force start.', last-rc-change='2021-03-01 15:10:26 +09:00', queued=0ms, exec=231ms

「データが正しくないかもしれないけど、/var/lib/pgsql/tmp/PGSQL.lock を削除すれば起動できるよ」と言われております。今回はディスクが壊れたりしたわけではないのでロックファイルを削除して起動できるようにしてみます。

1
2
# rm -f /var/lib/pgsql/tmp/PGSQL.lock
# pcs resource cleanup node=pcmk11

クラスターステータスを確認するとノード1がスレーブとしてクラスターに復帰しています。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
# pcs status --full
Cluster name: pcmk10
Cluster Summary:
  * Stack: corosync
  * Current DC: pcmk11 (1) (version 2.0.4-6.el8_3.1-2deceaa3ae) - partition with quorum
  * Last updated: Tue Mar  1 13:15:17 2021
  * Last change:  Tue Mar  1 13:15:06 2021 by root via crm_attribute on pcmk12
  * 2 nodes configured
  * 3 resource instances configured
 
Node List:
  * Online: [ pcmk11 (1) pcmk12 (2) ]
 
Full List of Resources:
  * ClusterIP   (ocf::heartbeat:IPaddr2):        Started pcmk12
  * Clone Set: ClusterDB-clone [ClusterDB] (promotable):
    * ClusterDB (ocf::heartbeat:pgsql):  Slave pcmk11
    * ClusterDB (ocf::heartbeat:pgsql):  Master pcmk12
 
Node Attributes:
  * Node: pcmk11 (1):
    * ClusterDB-data-status             : STREAMING|SYNC
    * ClusterDB-status                  : HS:sync
    * master-ClusterDB                  : 100
  * Node: pcmk12 (2):
    * ClusterDB-data-status             : LATEST
    * ClusterDB-master-baseline         : 0000000005000140
    * ClusterDB-status                  : PRI
    * master-ClusterDB                  : 1000
 
Migration Summary:
 
Tickets:
 
PCSD Status:
  pcmk11: Online
  pcmk12: Online
 
Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

仮にデータ損壊などの疑いがある場合は、現在マスターとなっているノード2（192.168.56.12）からデータを複製して復旧する必要があります。

1
2
3
4
5
6
# su - postgres
$ rm -rf /var/lib/pgsql/data/
$ pg_basebackup -h 192.168.56.12 -U repuser -D /var/lib/pgsql/data -X stream -P
$ rm -f /var/lib/pgsql/tmp/PGSQL.lock
$ exit
# pcs resource cleanup node=pcmk11

Zabbixサーバーもクラスターに組み込み

データベースがクラスター化されましたので、折角ですからZabbixサーバーも組み込んでみます。

Zabbixサーバーパッケージ群のインストールと設定

両ノードでZabbixパッケージ群をインストールします。

1
2
3
# yum install https://repo.zabbix.com/zabbix/5.0/rhel/8/x86_64/zabbix-release-5.0-1.el8.noarch.rpm
# yum clean all
# yum install zabbix-server-pgsql zabbix-web-pgsql zabbix-apache-conf zabbix-agent

データベースを作成します。こちらはマスターになっているノードのみで実行します。

1
2
3
# sudo -u postgres createuser --pwprompt zabbix
# sudo -u postgres createdb -O zabbix zabbix
# zcat /usr/share/doc/zabbix-server-pgsql*/create.sql.gz | sudo -u zabbix psql zabbix

両ノードでデータベースユーザーのパスワードとソースIPをClusterIPとする設定を追加します。

1
2
3
4
# cat <<__EOF__>> /etc/zabbix/zabbix_server.conf
DBPassword=password
SourceIP=192.168.56.10
__EOF__

両ノードでWebフロントエンドにタイムゾーンの設定を追加します。

1
2
3
# cat <<__EOF__>> /etc/php-fpm.d/zabbix.conf
php_value[date.timezone] = Asia/Tokyo
__EOF__

クラスター環境への組み込み

ZabbixサーバーとApache HTTPサーバーのクラスターリソースを設定します。Apacheにはocf:heartbeat:apacheリソースエージェントもありますが、お手軽にsystemdを使います。厳密にいうとphp-fpmもクラスターリソースに組み込んだほうがよいのですが省略します。

リソースの起動順序や制約もちょっと安直ではありますが、とりあえずマスターノードで稼働するClusterIPに依存する形としました。（可能ならグループ化したほうがいいと思います）

1
2
3
4
5
6
7
8
# pcs cluster cib zabbix_cfg
# pcs -f zabbix_cfg resource create ZabbixServer systemd:zabbix-server
# pcs -f zabbix_cfg resource create ApacheServer systemd:httpd
# pcs -f zabbix_cfg constraint colocation add ZabbixServer with ClusterIP
# pcs -f zabbix_cfg constraint colocation add ApacheServer with ClusterIP
# pcs -f zabbix_cfg constraint order ClusterIP then start ZabbixServer
# pcs -f zabbix_cfg constraint order ClusterIP then start ApacheServer
# pcs cluster cib-push zabbix_cfg

無事起動しました！

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
# pcs status --full
Cluster name: pcmk10
Cluster Summary:
  * Stack: corosync
  * Current DC: pcmk11 (1) (version 2.0.4-6.el8_3.1-2deceaa3ae) - partition with quorum
  * Last updated: Tue Mar  1 20:35:03 2021
  * Last change:  Tue Mar  1 20:34:42 2021 by root via crm_attribute on pcmk11
  * 2 nodes configured
  * 5 resource instances configured
 
Node List:
  * Online: [ pcmk11 (1) pcmk12 (2) ]
 
Full List of Resources:
  * ClusterIP   (ocf::heartbeat:IPaddr2):        Started pcmk11
  * Clone Set: ClusterDB-clone [ClusterDB] (promotable):
    * ClusterDB (ocf::heartbeat:pgsql):  Master pcmk11
    * ClusterDB (ocf::heartbeat:pgsql):  Slave pcmk12
  * ZabbixServer        (systemd:zabbix-server):         Started pcmk11
  * ApacheServer        (systemd:httpd):         Started pcmk11
 
Node Attributes:
  * Node: pcmk11 (1):
    * ClusterDB-data-status             : LATEST
    * ClusterDB-master-baseline         : 0000000006000098
    * ClusterDB-status                  : PRI
    * master-ClusterDB                  : 1000
  * Node: pcmk12 (2):
    * ClusterDB-data-status             : STREAMING|SYNC
    * ClusterDB-status                  : HS:sync
    * master-ClusterDB                  : 100
 
Migration Summary:
 
Tickets:
 
PCSD Status:
  pcmk11: Online
  pcmk12: Online
 
Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

あとはhttp://192.168.56.10/zabbix/にアクセスしてWebフロントエンドの設定を実施すれば完成です！
また、初期登録されているZabbixサーバーのIPアドレスをClusterIP（192.168.56.10）に変更すると、Zabbixサーバーが稼働しているノード側で自動的に監視されるようになります。ZabbixサーバーホストはZabbix性能情報のみ監視して、各ノードはLinuxホストとして監視するようにすればよい気がします。

ノード1からからノード2へのテイクオーバー実施

障害を想定したプロセス停止からのフェイルオーバーではなく、テイクオーバー（コマンド操作による意図的な系切り替え）を実施してみます。テイクオーバーにはpcs resource moveを使用します。

1
2
3
4
# pcs resource move ClusterDB-clone --master
Warning: Creating location constraint 'cli-ban-ClusterDB-clone-on-pcmk11' with a score of -INFINITY for resource ClusterDB-clone on pcmk11.
        This will prevent ClusterDB-clone from being promoted on pcmk11 until the constraint is removed
        This will be the case even if pcmk11 is the last node in the cluster

pcs resource moveでは実行時のメッセージからもわかるように、masterだったノードで動作しないようなロケーション制約が作成されます。こちらはテイクオーバー完了後にクリアする必要がありますが、先にステータスを確認します。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
# pcs status --full
Cluster name: pcmk10
Cluster Summary:
  * Stack: corosync
  * Current DC: pcmk12 (2) (version 2.0.4-6.el8_3.1-2deceaa3ae) - partition with quorum
  * Last updated: Tue Mar  1 21:07:14 2021
  * Last change:  Tue Mar  1 21:06:09 2021 by root via crm_attribute on pcmk12
  * 2 nodes configured
  * 5 resource instances configured
 
Node List:
  * Online: [ pcmk11 (1) pcmk12 (2) ]
 
Full List of Resources:
  * Clone Set: ClusterDB-clone [ClusterDB] (promotable):
    * ClusterDB (ocf::heartbeat:pgsql):  Stopped pcmk11 (Monitoring)
    * ClusterDB (ocf::heartbeat:pgsql):  Master pcmk12
  * ClusterIP   (ocf::heartbeat:IPaddr2):        Started pcmk12
  * ZabbixServer        (systemd:zabbix-server):         Started pcmk12
  * ApacheServer        (systemd:httpd):         Started pcmk12
 
Node Attributes:
  * Node: pcmk11 (1):
    * ClusterDB-data-status             : DISCONNECT
    * ClusterDB-status                  : STOP
    * master-ClusterDB                  : -INFINITY
  * Node: pcmk12 (2):
    * ClusterDB-data-status             : LATEST
    * ClusterDB-master-baseline         : 000000002C000098
    * ClusterDB-status                  : PRI
    * master-ClusterDB                  : 1000
 
Migration Summary:
  * Node: pcmk11 (1):
    * ClusterDB: migration-threshold=1 fail-count=1 last-failure='Tue Mar  1 21:06:10 2021'
 
Failed Resource Actions:
  * ClusterDB_monitor_4000 on pcmk11 'not running' (7): call=65, status='complete', exitreason='', last-rc-change='2021-03-01 21:06:10 +09:00', queued=0ms, exec=271ms
 
Tickets:
 
PCSD Status:
  pcmk11: Online
  pcmk12: Online
 
Daemon Status:
  corosync: active/disabled
  pacemaker: active/enabled
  pcsd: active/enabled

ノード2がマスターとなりテイクオーバーが完了したようなので、先ほどのロケーション制約をクリアします。

1
2
# pcs resource clear ClusterDB-clone
Removing constraint: cli-ban-ClusterDB-clone-on-pcmk11

また、ノード1にはフェイルオーバー時と同様にロックファイルが残っていて起動できない状態になっていますので、そちらを削除しリソースのエラーカウントをクリアします。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
# rm -f /var/lib/pgsql/tmp/PGSQL.lock
# pcs resource cleanup node=pcmk11
Cleaned up all resources on pcmk11
Waiting for 1 reply from the controller. OK
# pcs status --full
Cluster name: pcmk10
Cluster Summary:
  * Stack: corosync
  * Current DC: pcmk12 (2) (version 2.0.4-6.el8_3.1-2deceaa3ae) - partition with quorum
  * Last updated: Tue Mar  1 21:19:25 2021
  * Last change:  Tue Mar  1 21:17:52 2021 by root via crm_attribute on pcmk12
  * 2 nodes configured
  * 5 resource instances configured
 
Node List:
  * Online: [ pcmk11 (1) pcmk12 (2) ]
 
Full List of Resources:
  * Clone Set: ClusterDB-clone [ClusterDB] (promotable):
    * ClusterDB (ocf::heartbeat:pgsql):  Slave pcmk11
    * ClusterDB (ocf::heartbeat:pgsql):  Master pcmk12
  * ClusterIP   (ocf::heartbeat:IPaddr2):        Started pcmk12
  * ZabbixServer        (systemd:zabbix-server):         Started pcmk12
  * ApacheServer        (systemd:httpd):         Started pcmk12
 
Node Attributes:
  * Node: pcmk11 (1):
    * ClusterDB-data-status             : STREAMING|SYNC
    * ClusterDB-status                  : HS:sync
    * master-ClusterDB                  : 100
  * Node: pcmk12 (2):
    * ClusterDB-data-status             : LATEST
    * ClusterDB-master-baseline         : 000000002C000098
    * ClusterDB-status                  : PRI
    * master-ClusterDB                  : 1000
 
Migration Summary:
 
Tickets:
 
PCSD Status:
  pcmk11: Online
  pcmk12: Online
 
Daemon Status:
  corosync: active/disabled
  pacemaker: active/enabled
  pcsd: active/enabled

ノード1がスレーブとしてクラスターに復帰しました。

最後に

後半、かなり駆け足となりましたが、PacemakerによるPostgreSQLレプリケーションクラスター環境の構築と、Zabbixサーバーのクラスター組み込みを紹介しました。

最近はAWSなどクラウド基盤に構築することも多くなり、オンプレミス環境でデータベースをクラスター構築することは少なくなりつつあります。
ただ、今回紹介した構成を採用するとなると、クラスターソフトウェアに加えてデータベース機能の理解も必要になりますので、おいそれと手を出せる代物ではありません。
共有ディスク型が最も簡便かと思いますが、ハードウェアなどの調達コストを考えると、レプリケーション構成も選択肢としては残るのかなと思っています。

当社のZabbix構築パッケージサービスでは、こういった方式に加えて「快適Z 高可用性オプション」という簡素な構成も提供しています。お客様のご要望に応じて最適なシステム構成を提案させていただきますので、お気軽にご相談ください。

Zabbixの導入・構築でお困りですか？

Zabbixの導入・構築でお困りですか？アークシステムは、Zabbix Japan LLCの公式認定パートナーとして、豊富な実績と高い技術力でお客様をサポートします。

アークシステムが選ばれる理由

  • 豊富な経験: 多くのZabbix導入・構築プロジェクトを成功に導いた実績
  • 確かな技術力: Zabbix認定資格を持つエンジニアが対応
  • 独自のソリューション: 「監視定義テンプレート」を活用した迅速かつ高品質な実装
  • 最新情報へのアクセス: Zabbix社との強力なパートナーシップを活かした最新技術対応

こんな方に最適です

  • Zabbixの新規導入を検討している
  • 現行システムの運用に課題を感じている
  • 大規模環境での監視体制を整えたい

アークシステムでは、Zabbixの導入・運用に関する課題を解決し、最適な環境を構築します。どんなご相談でもお気軽にお問い合わせください！

Zabbixのプロフェッショナルに相談
  • Zabbix Enterprise Appliance
  • 低コスト・短納期で提供するまるごとおまかせZabbix

プラットフォーム技術部

Posted by ksato