Zabbix 7.0 LTS 内製HAクラスターの深層解剖：秒速フェイルオーバーの実現と低レイヤ最適化ハック
オブザーバビリティの世界において、監視システム自体のダウンタイムは「最大の背信行為」である。監視しているシステムがどれほど堅牢であっても、監視の要であるZabbix Serverが単一障害点（SPOF）となっていれば、それは砂上の楼閣にすぎない。
過去のバージョンにおいて、Zabbixの冗長化はPacemakerやCorosync、あるいはDRBDを組み合わせた力技のクラスタリングが主流であり、その複雑なステート管理とスプリットブレインの恐怖に夜間呼出しのトラウマを植え付けられたエンジニアリングチームも少なくないはずだ。
しかし、Zabbix 7.0 LTSの到来により、その景色は一変した。
ビルトインで実装されたネイティブHA（High Availability）クラスター機能は、外部オーケストレーターを不要とし、DB層の排他制御とノード間の心拍（Heartbeat）のみで完璧なアクティブ・スタンディ（あるいはマルチスタンバイ）構造を構築する。
本稿では、このZabbix 7.0のビルトインHAアーキテクチャの内部挙動を骨の髄まで剥き出しにし、極限までレイテンシーを削ぎ落とした構築手順、意図的な障害注入によるフェイルオーバーの挙動検証、そして現場の即戦力となる運用上のハックを、妥協のない高解像度で解説する。
—
1. Zabbix 7.0 HAアーキテクチャの内部解剖
まず、表面的な手順に入る前に、Zabbix 7.0のHA機能が内部でどのように動作しているのか、そのプリミティブなメカニズムを理解しなければならない。
ノードの状態遷移マシン
Zabbix Serverの各ノードは、起動時に `zabbix_server.conf` の設定に基づき、データベースの `ha_node` テーブルに対して自身の存在を登録する。ノードの状態（State）は以下の4つに分類される。
1. Standby (0): 待機状態。ポーリングや検知は行わず、マスターの生存監視のみを行う。
2. Active (1): アクティブ状態。現在監視を実行し、DBへの書き込み権限を持つ。
3. Stopped (2): 停止状態。シャットダウンシグナルを受け取った状態。
4. Unavailable (3): 障害状態。設定されたフェイルオーバー遅延時間を超えて心拍が途絶えた状態。
フェイルオーバーのトリガーメカニズム
アクティブノードは、定期的に（デフォルトでは毎秒）データベース上のタイムスタンプを更新し、自身が「生きている（Heartbeat）」ことを示す。
スタンバイノードはこのタイムスタンプを監視しており、アクティブノードの更新が `FailoverDelay`（最短10秒から設定可能）で指定された秒数を超えて途絶えた瞬間、コンセンサスアルゴリズム（DBの排他ロック）を競合的に取得し、自らを `Active` へ昇格させる。
> Architect’s Note:
> ここで重要なのは、「スプリットブレイン（脳梁破裂）の防止はデータベースのトランザクション分離レベルとユニーク制約に依存している」という点である。ネットワークが分断された際、複数のスタンバイノードが同時に昇格を試みても、RDBMSの行ロック競合により、勝者は常に1つに絞られる。したがって、ZabbixのHA構成において最も重要なSPOFは、実はZabbix ServerではなくBackend Database（PostgreSQL / MySQL）そのものである。DB側の冗長化（多重化・同期レプリケーション）が完了していない場合、HAの価値は半減する。
—
2. 冗長化構成の設計図と構築手順
今回は、検証環境として以下の構成を想定する。
- DB層: 高可用性PostgreSQLクラスター（Patroni等で冗長化済みを想定）
- Node 1 (Master/Primary): `zabbix-srv-01.internal` (IP: 192.168.10.11)
- Node 2 (Standby/Secondary): `zabbix-srv-02.internal` (IP: 192.168.10.12)
- フロントエンド: 共通のロードバランサー（Nginx / HAProxy）配下に配置
ステップ1: `zabbix_server.conf` の極限チューニング設定
両方のノードの `zabbix_server.conf` において、HA関連のディレクティブを以下のように定義する。単なるデフォルト値ではなく、障害検知の高速化とメモリ効率を最適化したプロダクション設定だ。
— Database Connection —
DBHost=192.168.10.100 # 冗長化されたDBの仮想IP/エンドポイント
DBName=zabbix
DBUser=zabbix
DBPassword=UltraSecureDBPassword_2024!
— High Availability Cluster Configuration —
このノードがクラスターに参加することを宣言
HANodeName=zabbix-srv-01
ノードアドレス（他のノードやフロントエンドからの到達性が必要）
NodeAddress=192.168.10.11:10051
フェイルオーバー遅延時間（秒）
デフォルトの1分は長すぎる。インフラのSLAを満たすため、極限の「10秒」に設定。
FailoverDelay=10
— Performance Tuning for High-Throughput —
StartPollers=100
StartPreprocessors=20
StartPollersUnreachable=20
StartTrappers=20
StartDiscoverers=10
CacheSize=512M
HistoryCacheSize=256M
HistoryIndexCacheSize=64M
ValueCacheSize=512M
(※Node 2側では `HANodeName=zabbix-srv-02` および `NodeAddress=192.168.10.12:10051` に書き換えること)
ステップ2: サービスの起動とクラスター状態の確認
両方のノードでZabbix Serverを起動する。
sudo systemctl enable –now zabbix-server
起動後、ZabbixのCLIツール、または直接データベースクエリを叩いて、HAクラスターの状態を確認する。Zabbix 7.0では、専用の管理コマンドが用意されている。
sudo zabbix_server -R ha_status
期待される出力例:
Zabbix server version: 7.0.0 LTS
Active haute disponibilité (HA) nodes:
Name Address Last access State
zabbix-srv-01 192.168.10.11:10051 0s active
zabbix-srv-02 192.168.10.12:10051 2s standby
Number of nodes: 2
この瞬間、Node 1がアクティブ、Node 2がスタンバイとして美しく調和していることが確認できる。
—
3. ライブフェイルオーバー検証：タイムラグの計測と挙動解析
アーキテクトとして最も重要なのは、「本当にドキュメント通りに動くのか」を極限状態ですべて数値化することである。ここでは、マスターノード（Node 1）を強制的にクラッシュさせ、Failoverが完了するまでのタイムラグと、監視データへの影響を検証する。
検証シナリオ
1. Node 1上で `kill -9` を実行し、OSパニックまたは突然のハードウェア故障を模倣する。
2. スタンバイノード（Node 2）のログを `tail -f` で監視し、`Unavailable` 検出から `Active` 昇格までのミリ秒単位のタイムラグを計測する。
3. エージェントからのトラップデータやアクティブチェックがどのようにハンドリングされるかを追跡する。
実行とログ解析
Node 1にてハードキルを実行:
sudo pkill -9 zabbix_server
同時に、Node 2のログ (`/var/log/zabbix/zabbix_server.log`) を監視する。
1423:20241027:120000.101 HA: node “zabbix-srv-01” status changed from active to unavailable
1423:20241027:120010.105 HA: New active node “zabbix-srv-02” elected
1423:20241027:120010.106 Zabbix Server’s role changed from standby to active
1423:20241027:120010.110 server #1 started [process target, idle 0.000000 sec]
解析結果:
- `zabbix-srv-01` のロスト検知: `12:00:00.101`
- `FailoverDelay` 設定値: 10秒
- 新アクティブノードの選出・昇格完了: `12:00:10.105`
検知からわずか 4ミリ秒 のオーバーヘッドで、Node 2は完全なActive状態へ遷移した。設定した `FailoverDelay=10` 秒に厳密に従い、フェイルオーバーが完了していることが実証された。
—
4. 運用上の致命的な罠とエキスパートハック
ここからが本記事の真骨頂である。マニュアルには決して書かれていない、本番運用で踏み抜く地雷と、それを回避するための低レイヤハックを伝授する。
罠1: アクティブチェック（Active Agent Checks）のバッファ溢れ
Zabbixエージェントがアクティブモードで動作している場合、エージェントは「どこのサーバーがアクティブか」を定期的に確認しに行く。フェイルオーバーが発生した瞬間、数千台のエージェントが一斉に新しいアクティブサーバー（Node 2）へ接続先を切り替える。
この時、トラッパープロセスの枯渇や、ヒストリキャッシュのロック競合が発生し、一時的なデータロスや遅延（Lag）を引き起こす。
【解決策】エージェント設定の最適化
すべてのZabbix Agent 2の設定ファイルにおいて、バッファサイズとバッファ保持期間を拡張し、一時的な接続断やフェイルオーバー中のメトリクス欠損を防ぐ。
/etc/zabbix/zabbix_agent2.conf
BufferSize=1000
BufferSend=5
HeartbeatFrequency=60
罠2: フロントエンド（Web UI）の接続先不整合
Zabbixフロントエンド（PHP）は、設定ファイル（`zabbix.conf.php`）に単一のサーバーアドレスがハードコードされている場合、バックエンドがフェイルオーバーしてもUI側から「Zabbixサーバーが稼働していません」という絶望的な赤字アラートが出続けることがある。
【解決策】APIと統合されたHAプロキシ構成（Nginx StreamによるL4ロードバランシング）
フロントエンドの前に軽量なL4ロードバランサー（Nginx）を挟み、両方のZabbix Serverのポート（10051）に対してヘルスチェックを行いながら自動ルーティングする構成を推奨する。
/etc/nginx/nginx.conf (Stream module)
stream {
upstream zabbix_backend {
# フェイルオーバーの高速化のためタイムアウトを短く設定
server 192.168.10.11:10051 max_fails=2 fail_timeout=5s;
server 192.168.10.12:10051 max_fails=2 fail_timeout=5s backup;
}
server {
listen 10051;
proxy_pass zabbix_backend;
proxy_connect_timeout 2s;
}
}
この構成により、エージェントからのトラフィックは常に生存しているアクティブノードへシームレスに転送される。
罠3: スプリットブレイン発生時の「ゾンビノード」問題
ネットワークの部分的切断（非対称ルーティング障害など）により、旧マスターが「自分はまだアクティブだ」と思い込み、データベースに対して書き込みを試みる最悪のシナリオ。
【エキスパートハック】カスタムフェンススクリプトとAPI監視
Zabbix 7.0のAPIを叩き、現在のクラスターステータスを監視する外形監視スクリプトを別の監視プレーン（あるいはクラウドWatchdog）から常時実行させよ。異常なノード状態（例: 複数のActive、あるいはUnavailableの長期化）を検知した場合、自動的にIPMIやクラウドAPI経由で該当インスタンスの電源を強制断（Stonith）するパイプラインを構築することこそが、真のSREのアーキテクチャである。
—
5. まとめ
Zabbix 7.0 LTSのビルトインHAクラスターは、もはや「おまけの機能」ではない。適切なパラメータチューニング、データベースの冗長化、そしてネットワークとエージェント層の設計が噛み合った時、商用高価APM製品の冗長化機構に匹敵する、極めて頑健なオブザーバビリティ基盤へと昇華する。
手動でのフェイルオーバー訓練を怠らず、ログのミリ秒単位の挙動を体に叩き込むこと。それこそが、障害の暗闇の中でもシステムを護り抜く、真の監視エンジニアの姿である。