Zabbix 6.0の概要紹介(第二回)

Zabbix 6.0の概要紹介を不定期に連載しております。
前回の記事はこちらです。

今回はZabbix 6.0のインストールを弊社の検証用サーバを用いて行ってみることにします。
インストールのついでに、Zabbix 6.0の新機能である、Zabbix内蔵のHAクラスタ構成機能も試してみます。

HAとはHigh Availabilityという熟語の頭文字を取ったもので、日本語では「高可用性」と訳されます。
可用性とはあるシステムが継続して稼働できる能力の事を指します。システムが無停止で安定稼働している時間が長ければ長いほど、そのシステムは可用性が高い(=高可用性)ということになります。
HAクラスタはシステムの可用性を高める技術の一種です。ZabbixにおけるHAクラスタとは、複数台のZabbixサーバを相互接続し、システムの冗長化を図る技術を指します。障害などである1台のZabbixサーバが完全に沈黙してしまったとしても、他に生き残っているZabbixサーバが引き続き監視を行うことで、システム全体としては無停止で稼働し続けている状態を保つことが出来ます。

ポイント

• Zabbix Server1,2で1つのDBを共有する
• 今回はサーバ2台のクラスタリングだが、3台以上のクラスタリング設定も可
• 取れる構成はアクティブ-スタンバイ型のみ(監視は常にアクティブになっている1ノードのみが行う)
• HA化できるのはZabbixサーバのみ。Zabbix ProxyのHA化には現状非対応。

• OS : AlmaLinux 8.5
• Zabbix : Zabbix 6.0.4
• Web : httpd 2.4.37、php-fpm 7.2.24
• DB : MySQL 8.0.26

• OSのインストール手順は省略しています。
• dnfコマンドでインターネット上のソフトウェアリポジトリを参照するため、Zabbixサーバ・DBサーバはインターネットに出ていけること
  (インターネット越しに監視をしないのであれば、構築完了後インターネット接続は遮断しても問題ありません。)
• サーバのSELinux・firewalldは無効である前提です。本記事を参考にZabbixサーバを構築される方がいらっしゃいましたら、皆様の環境に合わせて別途必要なセキュリティ対策は行ってください。

Zabbixの監視設定や取得してきた監視データはZabbix DBというデータベース上に格納されます。
今回は2台のZabbixサーバが1つのDBを共有する構成をとるためDB部分は別サーバに分離して構築しています。

MySQLのインストール

DBサーバにログインし、下記コマンドでMySQLのインストールとセットアップを行います。

dnf install mysql-server

インストールされるバージョンに注意
Zabbix6.0ではサポートするデータベースソフトのバージョン指定が厳しくなっています。
OSの標準リポジトリで公開されているソフトのバージョンはZabbixのサポート範囲外の場合があります。サポート外の場合は各データベースソフトの開発元が提供するリポジトリからのダウンロードを行いましょう。
詳しくは第1回の記事をご参照下さい。

インストール後設定

設定ファイルの編集

/etc/my.cnf.d/mysql-server.cnf

#以下を追記して保存(既存行は残す)
innodb_file_per_table
character_set_server=UTF8MB4
collation_server=utf8mb4_bin
skip-character-set-client-handshake
performance_schema=0

MySQLサービス起動と自動起動の有効化を同時に行う

systemctl enable --now mysqld.service

最低限のセキュリティ設定を行ってくれるコマンド(mysql_secure_installation)実行

mysql_secure_installation
以下、質問に沿って回答
Would you like to setup VALIDATE PASSWORD component? <= MySQLユーザのパスワードポリシーを設けるか(8文字以上のパスワードを強制するなど。利用するかは任意)
New password: <= (MySQL上の)rootユーザのパスワードを入力
Re-enter new password: <= 同上
Remove anonymous users? <= anonymous ユーザを削除するか。不要なのでYes。 Disallow root login remotely? <= 自サーバ外からのrootログインを許可するか。通常はNo。
Remove test database and access to it? <= "test"データベースを削除するか。不要なのでYes。
Reload privilege tables now? <= 上記権限の変更を今すぐ反映するか。通常はYes。

Zabbixデータベースの作成

mysql -uroot -p
Enter password: <= 先程設定したrootパスワードを入力

CREATE DATABASE zabbix CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
CREATE USER zabbix@'10.34.0.0/255.255.255.0' IDENTIFIED BY 'zabbixdb'; <= ZabbixDBへのアクセスを許可するソースIP(=ZabbixサーバがいるIPレンジ)を指定 環境に合わせて変更してください IDENTIFIED BY句に続くパスワード(zabbixdb)も必要に応じて変更してください
GRANT all privileges ON zabbix.* TO zabbix@'10.34.0.0/255.255.255.0';
exit


ここまで設定が終わったら一旦DBサーバを離れ、引き続きZabbixサーバの構築に移ります。

今回はZabbixサーバを2台構築しますが、特に注意書きが無い限り2台のサーバでは同一のコマンドを実行します。
クラウドサービスや仮想環境上で構築する場合は1台目のサーバを途中まで構築しておいて、2台目は1台目をクローンする形で作るのがスマートかもしれません。

Zabbixパッケージのインストール

Zabbixオフィシャルリポジトリの追加

dnf install https://repo.zabbix.com/zabbix/6.0/rhel/8/x86_64/zabbix-release-6.0-1.el8.noarch.rpm

Zabbix関連パッケージのインストール

下記を実行すると依存関係でhttpdが一緒にインストールされますが、ZabbixではWebサーバとしてNginxを利用することも可能です。
Nginxを使う場合はzabbix-apache-confの代わりにzabbix-nginx-confをインストールしてください。

dnf install zabbix-server-mysql zabbix-web-mysql zabbix-web-japanese zabbix-apache-conf zabbix-sql-scripts zabbix-selinux-policy mysql

Zabbix Agent2のインストール

Agentのインストールは必須要件ではないためコマンドを別出しにしています。
が、特別な事情が無い限りは構築対象のすべてのサーバにインストールすることを推奨します。

dnf install zabbix-agent2

初期セットアップ(CLI)

Zabbix DBの初期スキーマ作成

下記は Zabbixサーバの どちらか1台だけで実行してください。
コマンドはZabbixサーバで実行しますが、スキーマはDBサーバ上のDBに作成されます。
(mysqlコマンドの-hオプションでスキーマを流し込む先のサーバを指定しています。)

cd /usr/share/doc/zabbix-sql-scripts/mysql
zcat server.sql.gz | mysql -uzabbix -p zabbix -h
Enter password: <= "zabbix"ユーザのパスワードを入力

zabbix_server.confの編集

DBHost行でDBサーバのIPアドレスを指定します。デフォルトではlocalhost(Zabbixサーバと同じホスト)ですが、今回は冒頭に述べた通りZabbixサーバとDBサーバは分離していますので変更します。
HANodeNameとNodeAddressには 自ホストの (今作業中の)ホスト名とIPアドレスを記入します。クラスタリング設定に馴染みがある方だとつい対向装置の情報を記入してしまうかもしれませんが、Zabbixの場合は自ホストの情報となりますので注意しましょう。

/etc/zabbix/zabbix_server.conf

# 以下の記述を探し必要な個所を変更
DBHost=
DBName=zabbix
DBUser=zabbix
DBPassword=
HANodeName=
NodeAddress=:10051


zabbix_agent2.confの編集

/etc/zabbix/zabbix_agent2.conf

Server=,
ServerActive=; <= 通常サーバ同士はコロンで区切りますが、HAクラスタを組んでいる場合はセミコロンで区切ります。
Hostname=<自分自身のホスト名> <= OS設定上のHostnameとは異なる名前を定義可能ですが、ZabbixのWebUI上でホスト登録を行う際、ここで記述したHostnameと同じ名前で登録を行う必要があります。


Zabbixとその関連サービス起動

zabbix-serverサービス起動後は/var/log/zabbix/zabbix_server.logを参照し、起動エラーが出力されていないのを確認した後に後続のサービスを起動することを推奨します。

systemctl enable --now zabbix-server
systemctl enable --now zabbix-agent2
systemctl enable --now httpd
systemctl enable --now php-fpm


初期セットアップ(GUI)

Webブラウザに
http://<Zabbixサーバ1または2のIPアドレス>/zabbix/
と入力し、Webインターフェースのセットアップ画面を開きます。

Webインターフェースの各設定

言語を日本語に変更し、「次のステップ」。

すべてOKであることを確認し、「次のステップ」。

Zabbix DBの情報を入力。"データベースホスト"の記入値はデフォルトはlocalhostですが、今回はZabbixサーバとDBを別建てにしているためDBサーバのIPアドレスに変更します。ZabbixサーバとDBが同居している場合はlocalhostのままで構いません。

Zabbixサーバー名を入力。ここでの入力名はWebUI上の単なる表示名に過ぎないので、OS設定上のHostnameと同じである必要はありません。
また、タイムゾーンをAsia/Tokyoへ変更します。

設定値が間違いないことを確認し、「次のステップ」。

おめでとうございます。

ログイン画面に遷移するので、ユーザー名、パスワードを入力しサインイン。

正常にログイン出来れば、下記のようなダッシュボードが表示されます。
(例で障害が出ているのは筆者環境の問題なので気にしないで下さい)

[レポート] -> [システム情報]から、HAクラスタが組めていることを確認します。
(IPアドレスの部分は伏せています)
正常であれば、図のようにクラスタを組んだホスト名が表示されており、かつアクティブ-スタンバイの構成となります。
この図だと、平常時はZabbix1が監視を一手に担い、Zabbix1が何らかの原因で疎通不可能になるとZabbix2がアクティブに昇格し、それまでZabbix1が行っていた監視を引き継ぐ、ということになります。

稼働中のサーバで問題が生じてサーバが停止してしまった際に、自動的に待機系のサーバに処理を引き継ぐ仕組みをフェイルオーバーといいます。
今回2台のZabbixサーバを構築しましたが、ここでは稼働系Zabbixサーバのzabbix-serverプロセスを手動で止めることで疑似的にZabbixサーバに障害を起こし、フェイルオーバーが発生することを確認してみます。

zabbix-serverプロセスを止める

下記コマンドを 稼働系のZabbixサーバで 実行
現在どちらのZabbixサーバが稼働系かは、前述したWebUIメニューの[レポート] -> [システム情報]から確認することが出来ます。

フェイルオーバー発生前

Zabbix1が稼働系(アクティブ)

フェイルオーバー発生後

待機系(スタンバイ)だったZabbix2がアクティブに昇格しています。

監視状況

下記の図はCPU使用率監視のグラフデータです。
先程のzabbix-serverプロセス停止によるフェイルオーバーは16:09頃に発生しましたが、フェイルオーバー後も監視は途切れていません。
ここから、Zabbix1で行われていた監視処理はZabbix2へと引き継がれており、かつ監視システム全体としては無停止状態が継続できていることが窺えます。

フェイルオーバーの遅延

今回はzabbix-serverプロセスを手動で(=計画的に)止めてフェイルオーバーを発生させました。計画的な停止の場合はシステム停止とフェイルオーバーはほぼ同時に発生しますが、非計画的な停止(ネットワークインターフェースのdownなど)の場合は停止からフェイルオーバーまでに多少のラグが発生します。(グラフ欠けが発生するかはアイテムの監視間隔設定等によります)
先程のシステム情報の図の中に、"フェールオーバーの遅延"という項目があります。ここに記載されている時間が(非計画的な)システム停止の発生からフェイルオーバー発生までのラグとなります。図では1分となっていますがこれはあくまで目安であり、クラスタを組んでいるサーバ同士で生死チェックが入るタイミングによって、フェイルオーバー発生までの時間は多少前後します。

記事の冒頭で、2台のZabbixサーバが1つのDBを共有する、と述べました。
勘の良い方はお気づきの事と思いますが、この構成ではDBサーバがSPOF(単一障害点)になってしまっています。
商用目的でクラスタ構成のZabbixサーバを構築する場合は、別途DBの冗長化についても併せてご検討頂くか、あるいはクラウド上のマネージドデータベースのような、初めから冗長構成としてサービス提供されているデータベースをご利用頂くのも良いかもしれません。
また上記に関連するところではありますが、ZabbixのHAクラスタには各Zabbixサーバのローカルディスク同士を同期させる機能はありません。ACT-ACT構成にしたい、DBサーバを別建てしたくないなどの希望がある場合は従来のPacemaker+Corosyncなどのサードパーティ製品を使った冗長化が選択肢となります。

今回構築したZabbixサーバを使って、Zabbix6.0の新機能を引き続きご紹介する予定です。
内容は目下検討中です。。。