以下のページに従って、2台のZabbixサーバが構築されていること
Zabbix 4.4 インストール手順(CentOS7 / Apache2.4 / PHP5.4 / MariaDB5.5)
後述の論理構成に従い、NICの追加とIPアドレスの設定が完了していること
各手順の小見出しの後に【共通】がついている箇所は2台のサーバ、【zbx01】【zbx02】はそれぞれのホスト名のホストで手順を実施すること

基本設計

論理構成

正常時の論理構成図は以下の通りです。

アクティブ機障害発生時にフェイルオーバした場合は、以下の通りです。

ネットワーク構成

ネットワーク構成は以下の通りです。

サービスセグメント(192.168.100.0/24): クライアントとサーバの通信に使用
インターコネクトセグメント1 / DBレプリケーションセグメント(172.16.10.0/24): フェイルオーバクラスタのノード間通信　兼　DBレプリケーション通信に使用
インターコネクトセグメント2: インターコネクトセグメント1のバックアップセグメント。同セグメントが切断された場合にスプリットブレイン状態(両系Active)が発生することを防止する

サーバ構成

サーバ構成は以下の通りです。

サーバはzbx01(アクティブ機)、zbx02(スタンバイ機)の2台構成
クライアント端末からZabbix WebUIへの接続先として、サービス用の仮想IPアドレス(以下サービス用VIP)を2台のサーバで共有する
各サーバのApache(mod-phpで動作するZabbix WebUI)とZabbix Serverは、ローカルのMySQL宛にDB接続を行う
MySQLは、Master/Slave構成
MySQLのSlaveノードがMasterノードにレプリケーションのリクエストを送信するための宛先として、レプリケーション用の仮想IPアドレス(以下 DBレプリケーション用VIP)を2台のサーバで共有する

冗長化方式

冗長化方式は以下の通りです。

サービス用VIP、DBレプリケーション用VIP、Apache、Zabbix Serverは、アクティブ機のみ起動する
MySQLは、サーバ2台とも起動する。アクティブ機をMasterノード、スタンバイ機をSlaveノードとする
アクティブ機の各VIP、プロセス、OSに異常が発生した場合は、スタンバイ機に左記をフェイルオーバする
フェイルオーバ発生時、スタンバイ機のMySQLはMasterノードに昇格する。可能であれば、アクティブ機のMySQLはSlaveノードに降格する
ばたつき防止のため、自動フェイルバックは行わない

Pacemaker / Corosyncのインストール【共通】

以下のコマンドを実行し、PacemakerとCorosyncに関連するパッケージをインストールします。

# yum -y install pcs pacemaker

以下のコマンドを実行し、Pacemaker / Corosyncの管理ツールであるpcsdサービスの起動と自動起動設定を行います。

# systemctl enable --now pcsd.service
Created symlink from /etc/systemd/system/multi-user.target.wants/pcsd.service to /usr/lib/systemd/system/pcsd.service.

OSの設定

サービス停止と自動起動の無効化【共通】

Zabbixを冗長化する場合、サービスの起動はPacemakerが管理します。そのため、ApacheとZabbix Serverのサービス停止と、サービス自動起動の無効化を行います。MariaDBは後述の作業があるので、サービス自動起動の無効化のみ行い、サービスは起動したままにしておきます。

# systemctl disable mariadb.service
Removed symlink /etc/systemd/system/multi-user.target.wants/mariadb.service.
# systemctl disable --now zabbix-server.service
Removed symlink /etc/systemd/system/multi-user.target.wants/zabbix-server.service.
# systemctl disable --now httpd.service
Removed symlink /etc/systemd/system/multi-user.target.wants/httpd.service.

HAクラスタ用ユーザの設定【共通】

Corosyncをインストールすると、クラスタ内のサーバ間通信で認証を行うためのOSユーザが作成されます。以下のコマンドを実行し、クラスタ認証用ユーザのパスワードを設定します。
今回は、検証のために単純なパスワード(hapass)を設定しています。そのため、よくないパスワード〜の警告メッセージが表示されていますが、無視して作業を進めます。

# passwd hacluster
ユーザー hacluster のパスワードを変更。
新しいパスワード: ← haclusterユーザのパスワードを入力
よくないパスワード: このパスワードは 8 未満の文字列です。
新しいパスワードを再入力してください: ← 同じパスワードを再度入力
passwd: すべての認証トークンが正しく更新できました

ファイアウォールの設定【共通】

インターコネクト用のファイアウォールゾーンを作成し、インターコネクト用インターフェースを割り当てます。

# firewall-cmd --permanent --new-zone interconnect
success
# firewall-cmd --permanent --zone=interconnect --change-interface=enp0s8
The interface is under control of NetworkManager, setting zone to 'interconnect'.
success
# firewall-cmd --permanent --zone=interconnect --change-interface=enp0s9
The interface is under control of NetworkManager, setting zone to 'interconnect'.
success

インターコネクト用ファイアウォールゾーンの通信許可サービスに、DBレプリケーション用のサービスと、HAクラスタ通信用のサービスを追加します。

# firewall-cmd --permanent --zone=interconnect --add-service=mysql
success
# firewall-cmd --permanent --zone=interconnect --add-service=high-availability
success

通常はfirewall-cmd --reloadコマンドで設定を反映するのですが、検証環境ではゾーンへのインターフェース割り当てが正常に行われませんでした。そのため、firewalldのサービスを再起動して設定を反映します。

# systemctl restart firewalld

インターコネクト用のファイアウォールゾーンが以下の設定になっていることを確認します。

# firewall-cmd --list-all --zone=interconnect
interconnect (active)
  target: default
  icmp-block-inversion: no
  interfaces: enp0s8 enp0s9
  sources: 
  services: high-availability mysql
  ports: 
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules:

Apacheの設定

ステータスページの設定【共通】

PacemakerがApacheの監視に使用するステータスページを設定します。ステータスページのパスは/server-statusを指定して、ローカルからのアクセスのみ許可します。

# cat <<-__EOF__ > /etc/httpd/conf.d/status.conf
<Location /server-status>
    SetHandler server-status
    Require local
</Location>
__EOF__

MariaDBの設定

レプリケーション用DBユーザの作成【zbx01】

以下のコマンドを実行し、MariaDBのCLIを起動します。

# mysql -uroot -p
Enter password: ← root(DBユーザ)のパスワードを入力

以下のSQLを実行し、レプリケーション用のDBユーザreplを外部通信用と内部動作用の2種類作成し、それぞれ権限を付与します。replpassの箇所は、任意のパスワードを入力します。

> CREATE USER 'repl'@'%' IDENTIFIED BY 'replpass';
Query OK, 0 rows affected (0.00 sec)

> CREATE USER 'repl'@'localhost' IDENTIFIED BY 'replpass';
Query OK, 0 rows affected (0.00 sec)

> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
Query OK, 0 rows affected (0.00 sec)

> GRANT PROCESS, SUPER, REPLICATION SLAVE, REPLICATION CLIENT, RELOAD ON *.* TO 'repl'@'localhost';
Query OK, 0 rows affected (0.00 sec)

> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)

> quit;
Bye

Masterノード設定ファイルの編集【zbx01】

zbx01で、viなどのテキストエディタでMasterノード側のMariaDB設定ファイルを開きます。

# vi /etc/my.cnf

編集内容は以下の通りです。[mariadb]以降をファイル末尾に追記します。server_idにはクラスタで一意の数値、log-basenameにはログファイル名に付与する名前としてホスト名を指定します。

[mariadb]
log-bin
server_id=1
log-basename=zbx01

Slaveノード設定ファイルの編集【zbx02】

zbx02で、viなどのテキストエディタでSlaveノード側のMariaDB設定ファイルを開きます。

# vi /etc/my.cnf

編集内容は以下の通りです。パラメータの考え方はzbx01と同様です。

[mariadb]
log-bin
server_id=2
log-basename=zbx02

DB物理バックアップの取得【zbx01】

zbx01で、MariaDBを停止してDBの物理バックアップを取得します。

# systemctl stop mariadb.service
# tar zcvf /tmp/dbbackup.tar.gz -C /var/lib mysql

取得した物理バックアップをzbx01へ転送し、zbx02からは削除します。

# scp /tmp/dbbackup.tar.gz 192.168.100.202:/tmp
# rm -f /tmp/dbbackup.tar.gz

DB物理バックアップの展開【zbx02】

zbx02で、MariaDBを停止して既存のDBディレクトリを削除します。

# systemctl stop mariadb.service
# rm -rf /var/lib/mysql

zbx01から転送したDBの物理バックアップをzbx02のDBディレクトリに展開します。展開した後は、アーカイブファイルを削除します。

# tar zxvf /tmp/dbbackup.tar.gz -C /var/lib
# rm -f /tmp/dbbackup.tar.gz

通常のDBレプリケーション設定では、この後レプリケーション有効化を行いますが、今回はPacemakerがMariaDBのレプリケーション状態を管理するので、MariaDBの設定は以上で完了です。

クラスタの設定

クラスタノードの認証【zbx01】

zbx01で以下のコマンドを実行し、クラスタに参加する全ノードに対して認証を行います。
IPアドレスの箇所には、クラスタに所属するノードの、全てのインターコネクト用インターフェースのIPアドレスを指定します。今回は、1ノードにつき2つのインターフェースで相互接続しているので、指定するIPアドレスは計4つです。
DNSを使用する環境では、ホスト名での指定も可能です。(以下、pcs clusterコマンドを使用する手順で共通)

# pcs cluster auth 172.16.10.1 172.16.10.2 172.16.20.1 172.16.20.2
Username:  ← haclusterを入力
Password:  ← haclusterのパスワードを入力
172.16.20.2: Authorized
172.16.10.2: Authorized
172.16.10.1: Authorized
172.16.20.1: Authorized

クラスタの作成【zbx01】

zbx01で以下のコマンドを実行し、Zabbix用のクラスタを作成します。clstr-zabbixの箇所は、任意のクラスタ名を入力します。
IPアドレスの箇所は、同じノードのIPアドレスをカンマで区切り、その塊をノード単位でスペースで区切ります。今回の場合だと、zbx01が172.16.10.1,172.16.20.1、zbx02が172.16.10.2,172.16.20.2となります。

# pcs cluster setup --name clstr_zabbix 172.16.10.1,172.16.20.1 172.16.10.2,172.16.20.2
Destroying cluster on nodes: 172.16.10.1, 172.16.10.2...
172.16.10.1: Stopping Cluster (pacemaker)...
172.16.10.2: Stopping Cluster (pacemaker)...
172.16.10.1: Successfully destroyed cluster
172.16.10.2: Successfully destroyed cluster

Sending 'pacemaker_remote authkey' to '172.16.10.1', '172.16.10.2'
172.16.10.1: successful distribution of the file 'pacemaker_remote authkey'
172.16.10.2: successful distribution of the file 'pacemaker_remote authkey'
Sending cluster config files to the nodes...
172.16.10.1: Succeeded
172.16.10.2: Succeeded

Synchronizing pcsd certificates on nodes 172.16.10.1, 172.16.10.2...
172.16.10.2: Success
172.16.10.1: Success
Restarting pcsd on the nodes in order to reload the certificates...
172.16.10.2: Success
172.16.10.1: Success

クラスタの起動【zbx01】

以下のコマンドを実行し、作成したクラスタの起動と自動起動設定を行います。

# pcs cluster start --all
172.16.10.1: Starting Cluster (corosync)...
172.16.10.2: Starting Cluster (corosync)...
172.16.10.2: Starting Cluster (pacemaker)...
172.16.10.1: Starting Cluster (pacemaker)...
# pcs cluster enable --all
172.16.10.1: Cluster Enabled
172.16.10.2: Cluster Enabled

PCSD Status:の項目で2台のサーバがそれぞれOnlineになっていることを確認します。なお、クラスタに追加されたノードの名前は、ノードに設定されたOS上のホスト名が自動的に設定されます。

# pcs cluster status
Cluster Status:
 Stack: corosync
 Current DC: zbx02 (version 1.1.20-5.el7_7.1-3c4c782f70) - partition with quorum
 Last updated: Tue Nov 19 16:14:56 2019
 Last change: Tue Nov 19 16:14:52 2019 by hacluster via crmd on zbx02
 2 nodes configured
 0 resources configured

PCSD Status:
  zbx01 (172.16.10.1): Online
  zbx02 (172.16.10.2): Online

STONITHの無効化【zbx01】

STONITHとは、インターコネクトのリンクが切断されたときにスプリットブレイン(両系Active状態)を防止するための機能です。フェイルオーバ時に元Active機の電源を強制的に切断します。今回の検証環境では、電源操作を行うためのハードウェア管理ボードが存在しないので、STONITH機能は無効化します。

# pcs property set stonith-enabled=false

クォーラム動作の変更【zbx01】

クォーラムとは、クラスタ内のネットワーク障害で、ノード間の疎通が分断したときに、疎通が取れるノード数が合計ノードの過半数以上のノードグループが正常グループと判断する機能です。今回構築するクラスタは2台構成のため、ノード間の疎通が切断された場合多数決が行えません。自ノードのグループがクラスタの過半数に満たない場合のリソース動作をデフォルトのstop(停止)からignore(そのまま動作)に変更します。

# pcs property set no-quorum-policy=ignore

リソースの設定

クラスタ内でPacemakerが管理する各種リソースを設定します。

zbx02のStandby移行【zbx01】

リソース設定時、zbx02のリソースを確実に停止状態にするため、クラスタノード状態を強制的にStandby状態に移行します。pcs statusコマンドの実行結果のうち、Node zbx02: standbyの表示があることを確認します。

# pcs cluster standby zbx02
# pcs status
(略)
Node zbx02: standby
Online: [ zbx01 ]
(略)

リソース共通設定【zbx01】

リソースを現在起動しているノードに留める粘着性を設定します。zbx01が故障しフェイルオーバした後、zbx01が回復した際に自動フェイルバックしないようにします。これは、半死状態のノードによるフェイルオーバのバタつきを防止することが目的の設定です。

# pcs resource defaults resource-stickiness=INFINITY
Warning: Defaults do not apply to resources which override them with their own defined values

リソースに障害が発生した時、フェイルオーバをするまでの障害回数を指定します。デフォルトではINFINITY(無限)になっているので、リソースに障害が発生すると再起動を試み続けます。これを1に変更し、1回の障害でフェイルオーバを行う挙動にします。

# pcs resource defaults migration-threshold=1
Warning: Defaults do not apply to resources which override them with their own defined values

DBレプリケーション用VIPリソースの作成【zbx01】

DBレプリケーションで使用する、Masterノード接続先VIPをリソースとして設定します。ip=とcidr_netmask=は、それぞれDBレプリケーション用VIPに使用するIPアドレスとサブネットマスクを指定します。nic=は、VIPが所属するインターフェース名を指定します。それ以外の箇所は、下記設定例のパラメータを指定します。

# pcs resource create rsc_repl-vip \
ocf:heartbeat:IPaddr2 \
ip=172.16.10.3 \
cidr_netmask=24 \
nic=enp0s8 \
op monitor interval=10s timeout=10s

後ほど設定する、MariaDBの管理に使用するMySQLリソースエージェント(ocf:heartbeat:mysql)は、Slaveノードに対してレプリケーション元Masterノードの接続先を設定します。デフォルトでは、Masterノード上でuname -nを実行した結果(ホスト名)をSlaveノードのMasterノード接続先に設定します。しかし、この挙動では名前解決ができない環境ではそもそも通信できません。名前解決できる環境でも、インターコネクトのIPアドレスでレプリケーション通信が行えない問題が発生します。そのため、<リソースID>_mysql_master_IPの名前で各クラスタノードにノード属性を作成し、先程DBレプリケーション用VIPで定義したIPアドレスを値に設定します。

# pcs node attribute zbx01  rsc_mariadb_mysql_master_IP=172.16.10.3
# pcs node attribute zbx02 rsc_mariadb_mysql_master_IP=172.16.10.3

MariaDBリソースの作成【zbx01】

MariaDB管理用リソースを作成します。
replication_passwd=の箇所は、レプリケーション用DBユーザに設定したパスワードを指定してください。それ以外の箇所は、下記設定例のパラメータを指定します。

# pcs resource create rsc_mariadb \
ocf:heartbeat:mysql \
binary=/usr/bin/mysqld_safe \
datadir=/var/lib/mysql \
log=/var/log/mariadb/mariadb.log \
pid=/run/mariadb/mariadb.pid \
replication_user=repl \
replication_passwd=replpass \
op monitor interval=10s timeout=10s \
master \
master-max=1 \
master-node-max=1 \
clone-max=2 \
clone-node-max=1 \
notify=true

Zabbix Serverリソースの作成【zbx01】

Zabbix Serverのリソースを作成します。下記設定例のパラメータを指定します。

# pcs resource create rsc_zabbix-server \
systemd:zabbix-server \
op monitor interval=10s timeout=10s

Apacheリソースの作成【zbx01】

Apacheのリソースを作成します。下記設定例のパラメータを指定します。

# pcs resource create rsc_apache \
ocf:heartbeat:apache \
configfile=/etc/httpd/conf/httpd.conf \
statusurl="http://127.0.0.1/server-status" \
op monitor interval=10s timeout=10s

サービス用VIPリソースの作成【zbx01】

クライアント端末が使用する、Zabbix WebUI接続先VIPをリソースとして設定します。ip=とcidr_netmask=は、それぞれサービス用VIPに使用するIPアドレスとサブネットマスクを指定します。nic=は、VIPの所属するインターフェース名を指定します。それ以外の箇所は、下記設定例のパラメータを指定します。

# pcs resource create rsc_service-vip \
ocf:heartbeat:IPaddr2 \
ip=192.168.100.203 \
cidr_netmask=24 \
nic=enp0s3 \
op monitor interval=10s timeout=10s

リソースグループの作成【zbx01】

複数のリソースの起動順序、起動先ノードをまとめて管理するため、リソースグループを作成します。ZabbixServer、Apache、サービス用VIPを所属リソースとして追加します。リソースグループを作成する時に指定するリソースは、指定した順番がそのまま起動順序になります。

# pcs resource group add grp_zabbix rsc_zabbix-server rsc_apache rsc_service-vip

なお、MariaDBは、Master/Slaveリソースという、複数ノードで起動してMaster/Slaveの状態を保有する特殊なリソースなので、リソースグループには所属できません。DBレプリケーション用VIPは、後程設定するリソース製薬設定で、MariaDBよりも先に起動するようにしていするのでリソースグループには所属させません。

リソース制約設定

リソースを作成しただけでは、zbx01とzbx02にリソースが分散してしまったり、MariaDBよりも先にZabbix Serverが起動してDB接続エラーが発生する問題があります。そのため、リソース制約設定を行い、整合性の取れたリソースの配置、起動を実現します。

順序の制約設定【zbx01】

順序の制約とは、リソースが起動する順序を指定する機能です。Zabbixサーバを構成するソフトウェアの中では、まずDBレプリケーション用VIPを起動した後、MariaDBを起動します。MariaDBを起動した後に、同ソフトウェアに接続を行うZabbixServer、Apacheを起動し、最後にクライアントからの接続を受け付けるVIPを起動します。

# pcs constraint order set rsc_repl-vip rsc_mariadb-master grp_zabbix

コロケーションの制約設定【zbx01】

コロケーションの制約とは、同じノードで同時に起動するリソースを指定する機能です。Pacemakerはデフォルトで、管理対象のリソースをクラスタ内で複数のノードに分散させようとします。今回構築するZabbixサーバは、ソフトウェア構成の整合性を保つために、以下の制約を設定します。

Zabbix Server、Apache、サービス用VIPはMariaDB(Master)の起動しているノードで起動する
MariaDB(Master)は、DBレプリケーション用VIPの起動しているノードで起動する

# pcs constraint colocation add grp_zabbix with master rsc_mariadb-master INFINITY
# pcs constraint colocation add master rsc_mariadb-master with rsc_repl-vip INFINITY

場所の制約設定【zbx01】

場所の制約とは、リソースをどのノードで起動するか指定する機能です。zbx01のDBレプリケーション用VIPのスコアをzbx02よりも高くすることで、zbx01で優先的に同リソースが起動します。先程設定したコロケーションの制約によって、他のリソースもDBレプリケーション用VIPに合わせてzbx01で優先的に起動します。名前解決できない環境の場合、コマンド中のノードの箇所はIPアドレスで指定します。

# pcs cluster status
(略)
PCSD Status:
  zbx01 (172.16.10.1): Online
  zbx02 (172.16.10.2): Online
# pcs constraint location rsc_repl-vip prefers 172.16.10.1=200 172.16.10.2=100

zbx02のStandby解除【zbx01】

全ての設定が完了したので、Azbx01が故障した場合にフェイルオーバが行えるように、zbx02のStandby状態を解除します。

# pcs cluster unstandby zbx02

設定完了時の状態確認【zbx01】

以上で全ての設定が完了しました。クラスタ状態を確認すると、以下のようになります。

# pcs status
Cluster name: clstr_zabbix

WARNINGS:
Corosync and pacemaker node names do not match (IPs used in setup?)

Stack: corosync
Current DC: zbx02 (version 1.1.20-5.el7_7.1-3c4c782f70) - partition with quorum
Last updated: Tue Nov 19 16:58:02 2019
Last change: Tue Nov 19 16:57:57 2019 by root via cibadmin on zbx01

2 nodes configured
6 resources configured

Online: [ zbx01 zbx02 ]

Full list of resources:

 rsc_repl-vip   (ocf::heartbeat:IPaddr2):   Started zbx01
 Master/Slave Set: rsc_mariadb-master [rsc_mariadb]
     Masters: [ zbx01 ]
     Slaves: [ zbx02 ]
 Resource Group: grp_zabbix
     rsc_zabbix-server  (systemd:zabbix-server):    Started zbx01
     rsc_apache (ocf::heartbeat:apache):    Started zbx01
     rsc_service-vip    (ocf::heartbeat:IPaddr2):   Started zbx01

Daemon Status:
  corosync: active/enabled
  pacemaker: active/enabled
  pcsd: active/enabled

動作確認

フェイルオーバ【zbx01】

zbx01からzbx02に各リソースをフェイルオーバします。なお、zbx01のシェルから自身のクラスタ設定を操作する場合は、引数の最後にノード名は不要です。

# pcs cluster standby

フェイルオーバが完了するまで10秒ほど待機します。クラスタの状態を表示すると、zbx01がStandby状態に変化し、各リソースがzbx02で動作し始めたことが確認できます。

# pcs status
(略)
Node zbx01: standby
Online: [ zbx02 ]

Full list of resources:

 Master/Slave Set: rsc_mariadb-master [rsc_mariadb]
     Masters: [ zbx02 ]
     Stopped: [ zbx01 ]
 Resource Group: grp_zabbix
     rsc_zabbix-server  (systemd:zabbix-server):    Started zbx02
     rsc_apache (ocf::heartbeat:apache):    Started zbx02
     rsc_service-vip    (ocf::heartbeat:IPaddr2):   Started zbx02
(略)

zbx01がStandby状態のままだとMariaDBがSlave状態にならないので、Standby状態を解除します。

# pcs cluster unstandby

MariaDBの起動が完了するまで10秒ほど待機します。クラスタの状態を表示すると、zbx01でMariaDBが起動し、Slave状態に移動していることが確認できます。

# pcs status
(略)
Online: [ zbx01 zbx02 ]

Full list of resources:

 rsc_repl-vip   (ocf::heartbeat:IPaddr2):   Started zbx02
 Master/Slave Set: rsc_mariadb-master [rsc_mariadb]
     Masters: [ zbx02 ]
     Slaves: [ zbx01 ]
 Resource Group: grp_zabbix
     rsc_zabbix-server  (systemd:zabbix-server):    Started zbx02
     rsc_apache (ocf::heartbeat:apache):    Started zbx02
     rsc_service-vip    (ocf::heartbeat:IPaddr2):   Started zbx02
(略)

フェイルバック【zbx02】

zbx01の障害対応を想定して、フェイルバックはzbx02で行います。zbx02からzbx01に各リソースをフェイルバックします。

# pcs cluster standby