こんにちは！現場のインフラを預かるエンジニアなら、一度はこんな悪夢を見たことがあるはずです。
「夜中に突然鳴り響くアラート。起きて確認したら、よりによって監視サーバー自身がハードウェア障害で沈んでいた……。監視しているはずのシステムがブラックボックス化し、何が起きているか全くわからない絶望の沈黙」
監視サーバーのダウンは、運用者にとって最大の恐怖です。これまで、Zabbixでこの単一障害点（SPOF）を回避するためには、PacemakerとCorosyncを組み合わせたり、共有ストレージを用意したりと、極めて複雑で頭の痛くなるクラスター設計が必要でした。
しかし、Zabbix 7.0 LTSの登場により、その苦悩は過去のものとなりました。
Zabbix 7.0では、ビルトイン（標準機能）の高可用性（HA）クラスター機能が非常に実用的な形で我々の手元に届きました。外部の複雑なクラスタウェアに頼らず、Zabbixサーバープロセスだけでセキュアかつ堅牢な冗長化が組めるのです。
これをマスターすれば、あなたの夜の安眠と、障害時の絶望的な心理的負担が劇的に軽減されますよ。さあ、一緒にその中身と実践的な構築手順を紐解いていきましょう！
—
1. Zabbix 7.0 ビルトインHAクラスターのアーキテクチャを知る
まずは、「なぜZabbix 7.0のHAが優れているのか」という設計思想からお話しします。
従来のZabbixサーバーは、1つのデータベースに対して1つのサーバープロセスが接続する形をとっていました。Zabbix 7.0のHAクラスターでは、複数のZabbixサーバー（ノード）を起動し、それらを「Active（アクティブ）」と「Standby（スタンバイ）」の役割に自動で振り分けます。
[ Zabbix Frontend (Nginx/Apache) ]
│
├──> [ Zabbix Server Node 1 (Active) ] ──┐
│ │ (DB共有 &
└──> [ Zabbix Server Node 2 (Standby) ] ──┴ Heartbeat)
│
[ PostgreSQL / MySQL ]
- Activeノード: 実際の監視実行、ポーリング、トリガー評価、エージェントからのデータ受信をすべて行います。
- Standbyノード: 常に待機状態であり、データベースへの接続を維持しつつ、アクティブノードからの生存確認（ハートビート）を監視しています。
- 自動フェイルオーバー: アクティブノードが応答しなくなると、スタンバイノードがそれを検知し、自らをアクティブに昇格させて処理を引き継ぎます。
特筆すべきは、外部の複雑なクラスタ制御機構が不要という点です。Zabbixサーバーのプロセス内部で自律的に調停が行われるため、構築のハードルが圧倒的に下がっています。
—
2. 構築ハンズオン：2ノードHAクラスターを作ってみよう
今回は、検証用に2台のLinuxサーバー（Node 1, Node 2）を用意し、Zabbix 7.0 LTSのHAクラスターを組み上げていきます。データベースは外部の共通DB（PostgreSQLまたはMySQL）を1つ用意してください。
前提条件
- OS: Ubuntu 22.04 LTS または RHEL 9系
- Zabbixバージョン: 7.0 LTS
- 共通データベースサーバーが構築済みであること
—
Step 1: 各ノードへのZabbix 7.0のインストール
Node 1とNode 2の両方で、公式リポジトリを追加し、Zabbixサーバーをインストールします（今回はDBにPostgreSQLを使用する例で進めます）。
Zabbix 7.0 リポジトリのインストール (Ubuntu 22.04の場合)
wget https://repo.zabbix.com/zabbix/7.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_7.0-2+ubuntu22.04_all.deb
sudo dpkg -i zabbix-release_7.0-2+ubuntu22.04_all.deb
sudo apt update
Zabbixサーバー、フロントエージェントのインストール
sudo apt install -y zabbix-server-pgsql zabbix-frontend-php zabbix-apache-conf zabbix-sql-scripts
Step 2: データベースの初期設定（初回のみ）
Node 1からのみ、共通DBに対してスキーマを流し込みます。Node 2からは流し込む必要はありません（同じDBを見るため）。
DBの作成とスキーマインポート (DBホストが別にある想定)
zcat /usr/share/zabbix-sql-scripts/postgresql/server.sql.gz | sudo -u zabbix psql -h
—
Step 3: Zabbixサーバー設定ファイル（zabbix_server.conf）の魔法の記述
ここが最も重要な心臓部です。Node 1とNode 2の両方の `/etc/zabbix/zabbix_server.conf` を編集し、HAに関するパラメータを書き込みます。
両方のサーバーで、共通のDB接続情報を書いた上で、以下のHA関連パラメータを設定してください。
【Node 1 の設定例】
— 基本的なDB接続設定 —
DBHost=
DBName=zabbix
DBUser=zabbix
DBPassword=your_secure_password
— HAクラスター設定 —
このノードが参加するHAクラスターの名前（両ノードで完全に一致させること）
HANodeName=zabbix-node-01
このノードのフロントエンドやエージェントから見える自ホストのIP/ホスト名
NodeAddress=192.168.1.101:10051
【Node 2 の設定例】
— 基本的なDB接続設定 —
DBHost=
DBName=zabbix
DBUser=zabbix
DBPassword=your_secure_password
— HAクラスター設定 —
クラスター名はNode 1と同一にする
HANodeName=zabbix-node-02
このノードのIP/ホスト名
NodeAddress=192.168.1.102:10051
> 💡 先輩エンジニアのワンポイントアドバイス
> `NodeAddress` は非常に重要です。フェイルオーバーが発生した際、Zabbixのフロントエンド（Web画面）は「現在どのノードがアクティブか」を判断し、アクティブなサーバーへトラフィックを誘導するためにこのアドレスを参照します。正確なIPまたはDNS名を記述してください。
—
Step 4: サービスの起動とクラスター状態の確認
設定が完了したら、両方のノードでZabbixサーバーを起動します。
sudo systemctl restart zabbix-server
sudo systemctl enable zabbix-server
さあ、正しくクラスターが組めているか、Zabbixのログまたは専用コマンドで確認してみましょう！以下のコマンドを叩いてみてください。
sudo zabbix_server -R ha_status
【実行結果のイメージ】
Nodes in cluster:
ID HOST PORT STATUS LAST ACCESS
192.168.1.101 zabbix-node-01 10051 active [ 3s ago ]
192.168.1.102 zabbix-node-02 10051 standby [ 3s ago ]
お見事！Node 1が `active`、Node 2が `standby` として美しく協調動作を始めています。この瞬間、あなたの監視基盤はSPOFを脱却しました。
—
3. 運命の瞬間：フェイルオーバー挙動の検証とタイムラグ
理論が分かったところで、実際に障害をシミュレートしてみましょう。「本当に自動で切り替わるのか？」をご自身の目で確かめるのが一番の安心につながります。
検証シナリオ：Activeノードの強制停止
Node 1（アクティブ）のサービスを強制的に停止させます。
[Node 1にて]
sudo systemctl stop zabbix-server
この瞬間からストップウォッチを片手に、Node 2のログ（`/var/log/zabbix/zabbix_server.log`）を監視してみましょう。
【ログの推移】
Node 1からのハートビートが途絶え、フェイルオーバーのカウントダウンが始まる
zabbix_server [PID] : HA: node “zabbix-node-01” status changed to offline
zabbix_server [PID]: HA: our status has been changed to active
フェイルオーバーにかかるタイムラグの正体
Zabbix 7.0では、アクティブノードがダウンしてからスタンバイノードが「おや、主が死んだぞ」と気づいて昇格するまでにタイムアウト時間が存在します。
デフォルトでは、フェイルオーバーの判定時間は30秒に設定されています（環境やバージョンによって微調整可能ですが、標準では約30秒〜最大でも数分以内に切り替わります）。
つまり、Node 1を停止してから約30秒後、`zabbix_server -R ha_status` をNode 2側で実行すると……
Nodes in cluster:
ID HOST PORT STATUS LAST ACCESS
192.168.1.101 zabbix-node-01 10051 offline [ 25s ago ]
192.168.1.102 zabbix-node-02 10051 active [ 1s ago ]
見事にNode 2が `active` に昇格しました！
この間、Zabbixのフロントエンドにアクセスすると、自動的に新しいアクティブノード（Node 2）へと接続が切り替わり、監視データが途切れることなく（厳密には30秒間のポーリング空白は生まれますが、プロセス自体は継続して）動き続けます。
—
4. 現場で絶対に知っておくべき運用上の注意点
これで完璧にHA構成が組めましたが、現場のプロとして、運用上絶対に押さえておかなべき「落とし穴」をいくつか共有しておきます。
1. データベース（DB）は依然としてSPOFである
Zabbixサーバー自体は冗長化されましたが、その背後にあるPostgreSQL/MySQLが単一障害点であれば、システム全体としては止まります。DB側も必ずレピュケーション構成やマネージドサービス（AWS RDSなど）で冗長化してください。
2. コンフィグファイルの完全な同期
Node 1とNode 2の `zabbix_server.conf` の内容（特にカスタムパラメータや外部スクリプトのパスなど）は、常に完全に一致させておく必要があります。片方だけ設定を変え忘れると、フェイルオーバーした瞬間に予期せぬ挙動を引き起こします。
3. フェイルバック（復旧時の戻し）の挙動
障害から復旧した元のノード（今回の例ではNode 1）を再起動した場合、こいつは勝手にActiveを奪い返すことはしません。安全のために「Standby」ノードとしてクラスターに復帰します。
必要であれば、手動で役割を戻すか、そのままスタンバイとして稼働させ続けます（この「勝手に暴走して主権を奪い合わない」設計が非常にスマートで安全です）。
—
まとめ
今回は、Zabbix 7.0 LTSの新機能であるビルトインHAクラスターの構築と、フェイルオーバーの挙動をディープに解説しました。
- 面倒なクラスタウェア（Pacemaker等）はもう不要
- 設定ファイルに数行書くだけでマルチノード冗長化が完了
- アクティブ・スタンバイ間のフェイルオーバーも完全自動
これをマスターすれば、あなたの管理する監視基盤の信頼性は文字通り「次のステージ」へと引き上げられます。「夜中に監視サーバーの死活で起こされる悪夢」とは今日でお別れしましょう。
明日のインフラ運用が、もっと快適でエキサイティングなものになりますように。それではまた、現場でお会いしましょう！