ZabbixのHA構成について

ZabbixのHA構成

Zabbixサーバをお使いになられている方の中にはシングル構成で運用されている方も多いかと思いますが、こういった構成の場合、1台のZabbixサーバが停止してしまうと監視が止まってしまいます。

こういった事態を避けるためにはZabbixを冗長化する必要に迫られるわけですが、Zabbix6.0まではZabbix自身の機能としての冗長化というものはありませんでした。Zabbix6.0から新しくZabbixネイティブのHA機能として、Zabbix HAという機能が追加されていますので、今回はこの機能について紹介いたします。

構成

Zabbix HA環境の構成としては以下のように複数個のZabbixが1つのDBを共有するという構成となり、1台が稼働し監視を実施、その他のZabbixサーバはHA用のサービスプロセスであるha managerのみが起動しているといった構成になります。（Zabbixのサイトより抜粋）

使用する主要ソフトウエアとバージョンは以下で検証しています。

	Zabbixサーバ	DBサーバ
OS	AlmaLinux 8.9	AlmaLinux 8.9
Zabbix	6.0.32	6.0.32（zabbix-sql-scriptsのみ）
DB	なし	MariaDB 10.5.25 （mariadb.orgリポジトリ版）

構築

構築としてのポイントは、DBサーバをZabbixサーバと同じOS上に構築するのではなく、「外出し」にするという点です。このため、Zabbixサーバ用に加えてDBサーバ用の3台のサーバを用意する必要があります。

（Zabbixと同じOSにDBを構築し、そのDBを共有して使用することもできなくはないと思いますが、こういった構成にしてしまうとDB搭載側のOSが停止してしまった場合のことを考えるとHA構成の意味が薄くなってしまうため）

Zabbixサーバインストール

2台のZabbixサーバには公開されているマニュアル通りにZabbixサーバをインストールしますが、zabbix-sql-scriptsはDB構築用のスクリプトが入ったパッケージのためインストール不要です。（インストールしても特に問題ありません）

MariaDBインストール

残りの1台には今回MariaDBを使用しますが、ここで気を付けたいのがZabbixで推奨されているMariaDBのバージョンが10.5以上であるということです。10.5未満であっても、zabbix_server.confの「AllowUnsupportedDBVersions」をデフォルトの「0」から「1」に設定すれば使用は可能ですが、非推奨となります。

AlmaLinuxのOSリポジトリのMariaDBではこのblog執筆時は10.3系がインストールされてしまうため、mariadb.orgからインストールします。

と言っても難しいことはなく、基本的にはサイトにアクセスしたら「MariaDB Server Repositories」タブ（図の赤丸）を選択後、自分のOSに合ったディストリビューションとMariaDBのバージョンを選択（図の上段の赤枠）すると、リポジトリ設定ファイルの中身（図の下段の赤枠）が表示されるため、指示に従って/etc/yum.repos.d/Mariadb.repoファイルを作成し、指示通りにインストールコマンドを実行すればインストール完了です。

MariaDB設定

MariaDBインストール後はMariaDBの設定を実施してDB起動し、その後は基本的にZabbixマニュアル通りに設定すればZabbixのDBは完成しますが、ZabbixのマニュアルにはローカルからDBに接続するためのユーザーしか作成していません。今回はDBとは別のサーバから接続されるため、そのためのDBユーザーの作成と権限付与を実施する必要があります。

mysql> create user ‘zabbix’@'<Zabbixサーバ1のIP>’ identified by ‘<パスワード>’;
mysql> grant all privileges on zabbix.* to ‘zabbix’@'<Zabbixサーバ1のIP>’;
mysql> create user ‘zabbix’@'<Zabbixサーバ2のIP>’ identified by ‘<パスワード>’;
mysql> grant all privileges on zabbix.* to ‘zabbix’@'<Zabbixサーバ2のIP>’;

Zabbix設定

Zabbixサーバインストール後はZabbixの設定をしていきます。zabbix_server.confの設定で通常と異なる設定は以下の項目の設定となります。

DBHost
DBをZabbixサーバとは異なるサーバに構築しているため、通常はDBHostに自サーバのIPやlocalhostと設定しますが、DBサーバのIPアドレスを設定します。
HANodeName
通常この項目は設定しませんが、設定することでHAクラスタのホストとして起動するようになります。この設定はわかりやすいように自分のホスト名を登録したほうが良いと思います。
ここで設定した名前が、以降で説明するHAクラスタ内の各ホストの状態確認時に各ホストを区別する名前として表示されることになります。
NodeAddress
こちらも通常設定しない項目になります。こちらの設定は、HAクラスタ内の各ZabbixのWebUIが、ActiveとなっているZabbixサーバに接続しに行くための情報として使用されます。自身のIPアドレスを設定します。
この設定が間違っていると、誤った設定となっているZabbixサーバがActiveとなった際に、WebUIで以下のエラーが発生するなどの弊害が発生します。

その他設定

その他に設定は特にしなくても問題ありませんが、監視対象のログ監視を実施したいなど、アイテムタイプが「Zabbixエージェント（アクティブ）」の監視アイテムが存在する場合は、エージェント側の「ServerActive」の設定方法が少々異なります。（マニュアルはこちら）

通常は複数のZabbixサーバを記載する場合は「,」（カンマ）区切りでIPアドレスなどを設定しますが、ZabbixサーバがHA構成である場合は、「;」（セミコロン）区切りで設定します。

SELinux設定

この他に、今回の構成の場合はSELinuxの設定も追加で必要でした。

Zabbix6.0ではSELinuxをEnforcingの状態でも使用可能なように、あらかじめ「zabbix-selinux-policy」パッケージが用意されており、基本的にはインストールすれば使用できる状態になっています。但し、DBを外出しにする際は、別途SELinuxの設定をする必要があり、Zabbixのマニュアルにも明記されています。

今回の構成では、上記マニュアル記載の「httpd_can_network_connect_db」をONにするだけではZabbixサーバとDB間の通信ができない状態のままでした。このため、SELinuxでどのbool値をONにすればよいかを調査し、「zabbix_can_network」もONにしています。

動作

上記設定を実施し、Zabbixサーバを起動すると、ActiveのZabbixサーバのみ各種Zabbixサーバのプロセスが起動します。また、すべてのHAクラスタ内の各Zabbixで共通して「ha manager」というプロセスが起動するといったプロセス構成となります。

フェールオーバー

各Zabbixサーバは5秒に1回の頻度で、共通して使用しているDBに自身のステータスを更新して記録しており、お互いにその状態を確認しています。基本的にはこのDBに記録されている情報と更新日時をベースとして、系切り替えの判断などをしているようです。

系が切り替わる動作としては、ActiveノードがこのDBのテーブルを更新して終了したかどうかで切り替わる時間が異なります。

DBを更新して終了した場合（正常終了）
DBを更新して終了した場合は、各Zabbixサーバが5秒間隔でDBを見に行く際に、Activeノードのステータスが変わったことを検知し、最大で5秒で系が切り替わります。
DBを更新せず終了した場合（異常終了など）
DBを更新せず終了した場合は、各Zabbixサーバが5秒間隔でDBを見に行く際に、Activeノードのステータス更新の有無を確認し、判断するようで、最大でフェイルオーバー遅延時間+5秒で切り替わります。

※フェイルオーバー遅延時間はデフォルトで1分で設定されていますが、変更も可能です。

なお、ActiveノードではZabbixが起動しているが、何らかの理由でDBに接続できずデータを更新できなかった場合は、フェイルオーバー遅延時間-5秒の間にデータ更新できなければ、監視に使用しているプロセスを落として自信をスタンバイノードとして稼働させる動きをします。

この場合、他のサーバから見るとActiveノードが「DBを更新せず終了した」と判断され、系が切り替わる　といった動作をします。

系確認

現在HAクラスタの状態は主に2つの方法で確認可能です。

コマンドでの確認
下記コマンドを実行することで各ノードの状態を確認することができます。
zabbix_server -R ha_status
Zabbix WebUIで確認
レポート→システム情報を参照することで各ノードの状態を確認することができます。

感想

5.0まではZabbix自身の機能によって簡単にHA構成。組めるといったものはなかったため、こういった機能を実装し始めたという点はとても良いと思いますが、気になる点が無いというわけでもありません。

最期に今回の検証で気になった点を記載します。

気になった点

単純にサーバ台数が多くなる
Zabbix2台を両現用で動かすという冗長化に比較して、DB台数分だけサーバ台数が多くなります。運用などを行う際にこの+1台の運用コストをどう見るか。
DBやネットワークが冗長ではない
せっかくZabbixサーバが冗長になっても、DBやDBに接続するまでのネットワーク部分が冗長でない場合は結局シングル構成の時と同じという結果になってしまいます。その点を考慮されているクラウド環境等であればこの問題は解消されます。
Zabbix以外の設計要素が必要
たとえば監視対象やアイテムが多いZabbixで導入する場合は、DBとのNW帯域の太さも考慮するなど、別の設計要素が必要になる可能性があります。
各サーバでUIの変更が難しい
たとえば、運用するにあたり、どのZabbixを見ているかを簡単に把握するために、ZabbixのUIテーマをサーバごとに変更するといった使い方をされている方もいらっしゃるかと思いますが、HA構成の場合、使用しているDBが同一であるため、正系・副系でZabbixUIのテーマを別に設定しようとしても設定できません。
系切り替え/切り戻しコマンドが無い
メンテナンスなどで計画的に系切り替え/切り戻しをおこなうことは運用上発生すると思いますが、こういった際に使用可能なコマンドがなく、実際に実施する場合は、ActiveのノードでZabbixサーバサービスを停止するしかなさそうです。
切り替え時間が最速で10秒以上
Zabbix異常終了時の系切り替えはフェイルオーバー遅延時間+5秒だが、フェイルオーバー遅延時間の設定可能レンジは10秒～15分の間となっています。このためZabix異常時の切り替えは最速でも10秒以上はかかることになります。つまり「10秒」は監視できない時間が存在することになります。これを許容可能かという点がこの機能を使用するかの1つの判断ポイントとなると思います。

上記HA構成を組みたいなど、Zabbixに関してのご相談、お困りごとなどございましたらぜひ弊社までご連絡ください。

当サイトはパーソルクロステクノロジー㈱より提供しています