Zabbix 6.0のHAを試す

目次

MariaDBのクラスタを組んでZabbix 6.0の新機能であるHigh Availability機能を試したメモ

きっかけ

Zabbixでは6.0から別のソフトを使わずに冗長構成が組めるようになった。
公式ドキュメント: https://www.zabbix.com/documentation/6.0/en/manual/concepts/server/ha

ZabbixのHA機能では、冗長構成を組むZabbix Serverの全てが同一のDBの読み書きが行える必要がある。
そのため、今回はMariaDBでクラスタを組みHA機能を使ってみた。

なお、現時点では6.0は開発中であるため、正式公開時には仕様が変わっている可能性がある。試したバージョンは6.0.0alpha7である。

前提

  1. Zabbix Serverは3台で冗長構成を組む。
    これはMariaDBのクラスタ(MariaDB Galera Cluster)がスプリットブレインを防止するために $$ 3+2n (n>=0) $$ のサーバを要求するためである。
    クラウド環境でマネージドなDBを使う場合や、Zabbix ServerとDBサーバを分ける場合、Zabbix Serverの台数は2台でも問題ないはず。

    なお、スプリットブレインのリスクを無視して2台でクラスタを組むこともできる。その場合は、ignore_sb=trueを設定する。

  2. VIP(ACT機につくIPアドレス)は利用しない。 VIPはPacemaker+Corosyncなどでつけることができるが、その制御をするならVIP切り替えと同時にZabbix Serverを切り替えることができるので、Zabbix ServerのHA機能を使う必要がない。
    ちなみにPacemaker+CorosyncでZabbix Serverを冗長化する方法は、DRBDなどで作った分散ストレージ上にDBの中身を載せる方法が一般的な気がする。
    DBのレプリケーション機能を使う方法もあるようだった。

    また、フロントエンドにアクセスする時は、どれか動いている1ノードのIPアドレスを指定する必要がある。 この問題は、ロードバランサが使える場合は間に挟むことで解決できる。

    本当はZabbix ServerのHA機能がVIPを持ってくれる機能を持ってくれれば良いのだけど…。

  3. 各Zabbix ServerはlocalhostのDBにアクセスする。 Zabbix ServerのHA機能ではスタンバイ機もDBに書き込みができる必要がある。
    今回は(L4の)ロードバランサを用意していないため、このような構成になる。
    なお、MariaDBはレプリケーションではなくクラスタを組んでいるため、全ホスト読み書き可能であるため、この構成でも(パフォーマンス上の弱点はあるものの)動作はする。

    ちなみに、スタンバイ機は5秒に1回以下のクエリを実行していた。

    begin
    select ha_nodeid,name,status,lastaccess,address,port,ha_sessionid from ha_node order by ha_nodeid for update
    select ha_failover_delay,auditlog_enabled from config
    select unix_timestamp() from config
    update ha_node set lastaccess=unix_timestamp() where ha_nodeid='xxxxxxxxxxxxxxxxxxxxxxxxx'
    commit
    

環境

  • OS: Ubuntu 20.04.3
  • RAM 4GB
  • SSD 40GB
  • MariaDB 10.6.5
  • Zabbix 6.0.0alpha7

  • 1台目

    • ホスト名: zabbix-01.notr.app
    • IPアドレス: 192.168.50.5
  • 2台目

    • ホスト名: zabbix-02.notr.app
    • IPアドレス: 192.168.50.6
  • 3台目

    • ホスト名: zabbix-03.notr.app
    • IPアドレス: 192.168.50.7

MariaDB Galera Clusterのセットアップ

  1. (3台共通) 必要なリポジトリ、パッケージをインストール

    sudo apt-get -y install software-properties-common dirmngr apt-transport-https
    sudo apt-key adv --fetch-keys 'https://mariadb.org/mariadb_release_signing_key.asc'
    sudo add-apt-repository 'deb [arch=amd64,arm64,ppc64el,s390x] https://ftp.yz.yamagata-u.ac.jp/pub/dbms/mariadb/repo/10.6/ubuntu focal main'
    
    sudo apt-get install mariadb-server mariadb-client galera-4
    
  2. (3台共通) MariaDBの初期設定

    $ sudo mysql_secure_installation
    

    基本的にそのままEnterで回答。rootのパスワードだけちゃんと設定する。

    NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MariaDB
          SERVERS IN PRODUCTION USE!  PLEASE READ EACH STEP CAREFULLY!
    
    In order to log into MariaDB to secure it, we'll need the current
    password for the root user. If you've just installed MariaDB, and
    haven't set the root password yet, you should just press enter here.
    
    Enter current password for root (enter for none): 
    OK, successfully used password, moving on...
    
    Setting the root password or using the unix_socket ensures that nobody
    can log into the MariaDB root user without the proper authorisation.
    
    You already have your root account protected, so you can safely answer 'n'.
    
    Switch to unix_socket authentication [Y/n] 
    Enabled successfully!
    Reloading privilege tables..
    ... Success!
    
    
    You already have your root account protected, so you can safely answer 'n'.
    
    Change the root password? [Y/n] 
    New password: (パスワードを入力)
    Re-enter new password: (パスワードを入力)
    Password updated successfully!
    Reloading privilege tables..
    ... Success!
    
    (中略)
    
    Thanks for using MariaDB!
    
  3. (3台共通) クラスタ設定の投入 /etc/mysql/mariadb.conf.d/50-server.cnf を編集する。
    以下に変更点のみ記載する。

    bind-address            = 0.0.0.0
    
    [mariadb]
    wsrep_on=ON
    wsrep_provider=/usr/lib/galera/libgalera_smm.so
    wsrep_cluster_address="gcomm://192.168.50.5,192.168.50.6,192.168.50.7"
    binlog_format=ROW
    default_storage_engine=InnoDB
    innodb_autoinc_lock_mode=2
    innodb_doublewrite=1
    wsrep_cluster_name="zabbix_db"
    

    wsrep_cluster_addressにはクラスタに参加する全ノードのIPアドレスを記述する。DNS名でも可能なようだが、パフォーマンス上はIPアドレスを記述したほうが有利とのこと。
    wsrep_cluster_nameはクラスタ名。ご自由に。

  4. (1台目のみで実行) クラスタのセットアップ

    sudo systemctl stop mariadb
    sudo galera_new_cluster
    

    galera_new_clusterは何も出ないでシェルが戻って来れば成功。MariaDBが起動しているはず。

  5. (2台目、3台目のみで実行) クラスタへの参加

    sudo systemctl restart mariadb
    

    シェルが戻ってきてMariaDBが起動すれば成功。

なお、MariaDB Galera Clusterは全ホストがシャットダウンした場合は、再起動時に再度クラスタのセットアップから実行する必要がある。
ホスト起動時にMariaDBが起動するが、そのままシャットダウンしてしまう。

Zabbix Serverのインストール

Zabbix公式サイトに従ってインストール。今回はUbuntu 20.04、Apache2、Zabbix Agent2の構成。
なお、開発版の6.0のため、リポジトリのバージョン部分が5.5になっている。
正式リリース時には変更されるため、公式ページを確認する。

wget https://repo.zabbix.com/zabbix/5.5/ubuntu/pool/main/z/zabbix-release/zabbix-release_5.5-1+ubuntu20.04_all.deb
sudo dpkg -i zabbix-release_5.5-1+ubuntu20.04_all.deb
sudo apt update
sudo apt install zabbix-server-mysql zabbix-frontend-php zabbix-apache-conf zabbix-sql-scripts zabbix-agent2

# DBの設定
mysql -uroot -p
(パスワードを入力)

mysql> create database zabbix character set utf8mb4 collate utf8mb4_bin;
mysql> create user zabbix@localhost identified by 'password';
mysql> grant all privileges on zabbix.* to zabbix@localhost;
mysql> quit;

zcat /usr/share/doc/zabbix-sql-scripts/mysql/create.sql.gz | mysql -uzabbix -p zabbix
(Zabbixユーザのパスワードを入力)

Zabbixの設定

Server

/etc/zabbix/zabbix_server.conf を編集する。 追記部分のみ記載する。

DBPassword=password
HANodeName=zabbix-01
NodeAddress=192.168.50.5

HANodeNameはホスト名を設定した。NodeAddressはそのホストのIPアドレスを記載した。
(2台目の場合はそれぞれ zabbix-02, 192.168.50.6)

Agent2

/etc/zabbix/zabbix_agent2.conf を編集する。 修正部分のみ記載する。

Server=127.0.0.1,192.168.50.5,192.168.50.6,192.168.50.7
ServerActive=127.0.0.1,192.168.50.5,192.168.50.6,192.168.50.7
Hostname=zabbix-01.notr.app

ServerServerActiveは全ホストのIPアドレスを設定した。
Hostnameは設定しているホスト名を設定した。(2台目の場合はzabbix-02.notr.app)

サービス起動、自動起動設定

sudo systemctl restart zabbix-server zabbix-agent2 apache2
sudo systemctl enable zabbix-server zabbix-agent2 apache2

フロントエンドの初期設定

フロントエンドの設定はDBに書き込まれないため、全台で実施する必要がある。
ホスト名の設定とDBのパスワード設定を行うだけで、他は全てデフォルトでOK。

確認と細かい設定

Zabbixフロントエンドにログインして、レポートのシステム情報をみた時、以下の画像のように「HAクラスター」が有効になっていて、下のリストに全ノードが表示されていればOK。

HAステータス

初期設定ではZabbix serverというホストが1つ登録されており、テンプレートが2つLinux by Zabbix agentZabbix server healthリンクされているが、127.0.0.1のLinux監視を行ってもあまり嬉しくないため、Linux by Zabbix agentのリンクと保存データを削除を実行し、Linux監視は各ホストを登録してLinux by Zabbix agentをリンクして実施する。

以下のように設定した。

ホスト一覧

アクティブだったノードに障害が発生した場合、初期設定では1分後にアクティブ機の切り替えが行われる。

クラスタ切り替わり

また、以下の2つの警報が発生する。自動でクローズされないため、フロントエンドからクローズする。

クラスタ切り替わり警報

今回はネットワークを切断して障害を発生させ復帰させた。
障害が発生したノードのZabbix Serverのログは以下の通りだった。

17176:20211212:092106.051 [Z3005] query failed: [1047] WSREP has not yet prepared node for application use [select userid from users limit 1]
17176:20211212:092106.051 database is down: retrying in 10 seconds
17176:20211212:092116.051 database connection re-established
17176:20211212:092116.051 [Z3005] query failed: [1047] WSREP has not yet prepared node for application use [select userid from users limit 1]
17176:20211212:092116.051 database is down: retrying in 10 seconds
17176:20211212:092126.052 database connection re-established
17176:20211212:092126.053 current database version (mandatory/optional): 05050111/05050111
17176:20211212:092126.053 required mandatory version: 05050111
17190:20211212:092126.061 starting HA manager
17190:20211212:092126.064 HA manager started in standby mode
17176:20211212:092126.161 "zabbix-01" node started in "standby" mode

MariaDBのクラスタが外れたことから、10秒ごとに3行のログが出力されたいた。

ちなみに切り替わった先のZabbix Serverのログは以下の通りだった。(093540にactiveに切り替わり、Zabbix Serverの各種プロセスが起動している。)

16544:20211212:074830.139 starting HA manager
16544:20211212:074830.144 HA manager started in standby mode
16543:20211212:074830.239 "zabbix-03" node started in "standby" mode
16543:20211212:084830.144 "zabbix-03" node is working in "standby" mode
16543:20211212:093540.142 "zabbix-03" node switched to "active" mode
16543:20211212:093540.143 server #0 started [main process]
17237:20211212:093540.144 server #1 started [service manager #1]
17239:20211212:093540.145 server #2 started [configuration syncer #1]

なお、クラスタの状況は以下のコマンドを実行することでZabbix Serverのログに出力される。

sudo zabbix_server -R ha_status
17063:20211212:091644.916 cluster status:
17063:20211212:091644.916    #  ID                        Name                      Address                        Status      Last Access
17063:20211212:091644.916    1. ckx2xpoyz0001brmzylpvmzgv zabbix-01                 192.168.50.5:10051             unavailable 1m 19s
17063:20211212:091644.916    2. ckx2xs3oc0001i3n08a94prkv zabbix-02                 192.168.50.6:10051             active      0s
17063:20211212:091644.916    3. ckx2xsdwi0001d5n1t45xhsyc zabbix-03                 192.168.50.7:10051             standby     4s

また、フェイルオーバーにかかる時間は、アクティブ機にて以下のコマンドを使うことで設定できる。以下の例だと10秒(設定できる最短値)になる。

sudo zabbix_server -R ha_set_failover_delay=10s

アクティブ機のZabbix Serverのログ

 17190:20211212:093210.068 HA failover delay set to 10s

1台で設定すれば全台に反映されるようだった。

なお、フェイルバックの設定は見当たらなかったため、切り替えが発生した後にアクティブ機を戻したい場合は、意図的にアクティブ機のシャットダウンを行うなどする必要がありそう。
ちなみに、今回の設定ではMariaDBとZabbix Serverを自動起動にしているため、ネットワーク障害や電源障害の場合は、復旧後にサーバを起動すれば自動的に再度クラスタへ組み込まれる。
復旧時に確認が必要な場合はsystemctlで自動起動を無効にすること。