📍 Lecture connexe : Zabbix 7 LTS en 2026 : supervision open-source en production — pour la vue d’ensemble et les arbitrages.
Avant Zabbix 6.0, mettre Zabbix en haute disponibilité demandait Pacemaker, Keepalived ou Corosync, avec la complexité d’un cluster Linux générique. Depuis 6.0 et stabilisé en 7.0, Zabbix intègre nativement un mécanisme de HA : plusieurs nœuds Zabbix Server se déclarent dans la base partagée, un seul est actif à un instant T, et la bascule se fait automatiquement si le primaire ne renouvelle pas son lease. Ce tutoriel monte un cluster de deux nœuds, configure le lease, teste le failover, et explique les pièges opérationnels.
Prérequis
- Deux machines Linux (Debian 12 / Ubuntu 24.04) avec une IP routable entre elles
- Une base PostgreSQL accessible depuis les deux nœuds — soit installée sur une troisième machine, soit en cluster PostgreSQL répliqué
- Un load balancer ou un DNS qui distribue le frontend vers les deux nœuds
- Niveau attendu : avancé — vous maîtrisez l’installation Zabbix standalone
- Temps estimé : environ 2 heures
Étape 1 — Comprendre le modèle HA Zabbix 7
Le modèle est élégamment simple. Chaque nœud Zabbix Server enregistre périodiquement (toutes les 5 secondes) son statut et son last_access dans la table ha_node de la base partagée. À tout moment, exactement un nœud est en statut active ; les autres sont standby. Si l’active ne renouvelle pas son entrée pendant le failover delay (par défaut 60 secondes), un standby se promeut automatiquement et devient l’actif.
Ce mécanisme exige donc une seule chose : que la base de données soit elle-même hautement disponible. Si la base tombe, tout le cluster Zabbix tombe avec elle. Le sujet HA Zabbix se réduit en pratique au sujet HA PostgreSQL, qui se résout par PostgreSQL streaming replication + Patroni, ou par un cluster Galera pour MySQL.
L’autre point à comprendre : il n’y a pas de réplication entre nœuds Zabbix. Toute la cohérence d’état vit dans la base. Un nœud Zabbix est essentiellement un binaire stateless qui pointe vers la base.
Étape 2 — Préparer la base de données partagée
On suppose qu’on a déjà PostgreSQL 16 installé sur une machine dédiée (par exemple db.example.com). On crée la base zabbix et on autorise les connexions depuis les deux nœuds.
# Sur la machine PostgreSQL
sudo -u postgres createuser --pwprompt zabbix
sudo -u postgres createdb -O zabbix zabbix
# Configurer pg_hba.conf pour autoriser les nœuds
echo "host zabbix zabbix 10.0.0.20/32 scram-sha-256" | \
sudo tee -a /etc/postgresql/16/main/pg_hba.conf
echo "host zabbix zabbix 10.0.0.21/32 scram-sha-256" | \
sudo tee -a /etc/postgresql/16/main/pg_hba.conf
# Configurer listen_addresses
sudo sed -i "s/^#listen_addresses.*/listen_addresses = '*'/" \
/etc/postgresql/16/main/postgresql.conf
sudo systemctl restart postgresqlPour la production, on ne se contente pas d’une base PostgreSQL standalone : on monte un cluster PostgreSQL avec streaming replication primaire + standby + failover automatique via Patroni. Un disque qui crashe sur la base unique élimine tout l’effort de HA Zabbix.
Étape 3 — Installer Zabbix Server sur les deux nœuds
Sur chaque nœud (zabbix-node1 et zabbix-node2), on installe le serveur Zabbix avec la procédure standard du tutoriel d’installation. À la différence près qu’on ne charge le schéma SQL qu’une seule fois, depuis n’importe lequel des deux nœuds, vers la base partagée.
# Sur node1 uniquement
zcat /usr/share/zabbix-sql-scripts/postgresql/server.sql.gz | \
PGPASSWORD=mot_de_passe psql -h db.example.com -U zabbix zabbixLe second nœud n’a pas besoin de charger le schéma : il pointera vers la même base déjà initialisée. Charger le schéma deux fois écraserait les données, donc cette discipline est cruciale.
Étape 4 — Configurer chaque nœud avec un HA Node Name
La directive nouvelle qui active le mode HA est HANodeName dans /etc/zabbix/zabbix_server.conf. Si elle est vide (default), le serveur tourne en mode standalone classique. Si elle est non vide, le serveur s’enregistre comme nœud HA.
# Sur node1
sudo sed -i 's/^# HANodeName=.*/HANodeName=zabbix-node1/' \
/etc/zabbix/zabbix_server.conf
# Sur node2
sudo sed -i 's/^# HANodeName=.*/HANodeName=zabbix-node2/' \
/etc/zabbix/zabbix_server.conf
# Sur les deux : configurer la connexion à la base partagée
sudo sed -i 's/^DBHost=.*/DBHost=db.example.com/' \
/etc/zabbix/zabbix_server.conf
sudo sed -i 's/^# DBPassword=.*/DBPassword=mot_de_passe/' \
/etc/zabbix/zabbix_server.confOn ajoute aussi NodeAddress qui indique l’IP que le nœud expose pour la communication serveur ↔ proxy ↔ frontend. C’est cette IP que le frontend interrogera pour savoir quel nœud est actif.
# Sur node1
echo "NodeAddress=10.0.0.20:10051" | \
sudo tee -a /etc/zabbix/zabbix_server.conf
# Sur node2
echo "NodeAddress=10.0.0.21:10051" | \
sudo tee -a /etc/zabbix/zabbix_server.confÉtape 5 — Démarrer les deux nœuds et observer
On démarre les services sur les deux nœuds simultanément.
sudo systemctl restart zabbix-server # sur les deux nœuds
sudo systemctl status zabbix-serverAu démarrage, chaque nœud s’enregistre dans la table ha_node. Le premier à s’enregistrer prend le statut active ; le second détecte qu’il y a déjà un actif et reste en standby. On vérifie depuis n’importe quel nœud avec une requête SQL :
PGPASSWORD=mot_de_passe psql -h db.example.com -U zabbix zabbix \
-c "SELECT name, status, lastaccess FROM ha_node;"La sortie attendue : deux lignes, une avec status=3 (active), l’autre avec status=0 (standby). Les lastaccess doivent s’incrémenter en temps réel ; si l’un cesse de progresser, ce nœud est en panne.
Étape 6 — Configurer le frontend pour le HA
Le frontend doit pouvoir parler au nœud actif quel qu’il soit. Deux approches. La première : on configure dans zabbix.conf.php le paramètre $ZBX_SERVER à l’IP du nœud actif courant ; en cas de bascule, on doit modifier ce fichier (peu pratique). La seconde : on met un load balancer ou Keepalived devant les deux nœuds, qui route le trafic 10051 vers celui qui répond. C’est la voie recommandée.
Avec HAProxy par exemple :
listen zabbix_server
bind *:10051
mode tcp
option tcplog
server node1 10.0.0.20:10051 check
server node2 10.0.0.21:10051 check backupL’option backup sur node2 fait que le trafic ne va sur lui que si node1 ne répond pas. Pour un comportement plus actif, on retire cette option et HAProxy load-balance ; mais comme un seul nœud est actif à la fois côté Zabbix, c’est inutile et perturbe le diagnostic.
Étape 7 — Configurer plusieurs frontends
Le frontend PHP est aussi un point qu’on duplique pour la haute disponibilité. On installe deux frontends sur deux machines (souvent les mêmes que les nœuds serveur), on met un load balancer HTTP (HAProxy, Nginx upstream, ou un cloud LB) qui route le trafic HTTPS vers les deux frontends en active-active. Les deux frontends pointent vers la même base et le même $ZBX_SERVER — ils sont parfaitement interchangeables.
Quand un frontend tombe, le load balancer route vers l’autre. L’utilisateur ne voit aucune interruption à condition que sa session soit conservée dans la base (ce qui est le cas en Zabbix 5.0+).
Étape 8 — Tester le failover
Le test ultime : on tue brutalement le nœud actif et on observe la promotion automatique. Sur node1 (supposé actif) :
sudo systemctl stop zabbix-serverAu bout du failover delay (60 secondes par défaut), node2 détecte que node1 ne renouvelle plus son lease et se promeut. On vérifie via la requête SQL : node1 passe en status=2 (unavailable), node2 passe en status=3 (active).
Côté supervision, on observe une fenêtre d’environ 60 secondes pendant laquelle aucune métrique n’est traitée. Les agents bufferisent localement (en mode active) ou retentent (en mode passive), donc on ne perd pas les valeurs ; elles arrivent en différé après reprise.
On relance node1. Il rejoint la table en standby ; il ne reprend pas automatiquement la main, ce qui évite les yo-yo si node1 était instable. Pour forcer le retour de la main à node1, on stop node2 et on observe la nouvelle bascule.
Étape 9 — Configurer le failover delay
Le failover delay est paramétré globalement dans la table config via la directive HAFailoverDelay. Par défaut 60 secondes ; on peut le baisser à 30 ou monter à 300 selon la criticité.
Plus court (10-30 s) : bascule rapide mais risque de fausses bascules sur des hoquets réseau ponctuels. Plus long (300 s) : tolérant aux hoquets mais long aveuglement en cas de panne réelle. La valeur par défaut est un compromis solide pour la majorité des contextes.
On modifie via la commande de configuration côté frontend, ou via SQL :
UPDATE config SET ha_failover_delay = '30' WHERE configid = 1;Étape 10 — Surveiller le cluster lui-même
Un cluster HA dont on ne sait pas qu’il est en standby unique est faussement rassurant. On supervise donc la table ha_node en créant un item personnalisé qui interroge le statut. Le template officiel Zabbix server health by HA existe depuis 7.0 ; on le lie à un hôte représentant le cluster.
Trigger essentiels : « Pas d’actif disponible », « Plus d’un actif simultané », « Standby manquant depuis X minutes ». Sans ces triggers, on découvre la perte de la HA seulement le jour où le primaire tombe et qu’il n’y a personne pour reprendre.
Étape 11 — Maintenance d’un nœud
Pour mettre à jour ou redémarrer un nœud sans interruption visible, la procédure correcte est : si le nœud à intervenir est le standby, on l’arrête, on patche, on redémarre, on vérifie qu’il revient en standby. Si le nœud à intervenir est l’actif, on le stoppe — la bascule automatique opère —, on patche, on redémarre, il revient en standby. On peut ensuite forcer la main à revenir s’il était master initialement.
Cette procédure permet des upgrades sans coupure pour les utilisateurs frontend, à condition que le frontend soit lui-même en LB derrière deux instances. La discipline est de ne jamais arrêter les deux nœuds simultanément, et de toujours valider que le standby est bien sain avant d’arrêter le primaire.
Étape 12 — Limites et alternatives
Le mode HA Zabbix natif a deux limites à connaître. Premièrement, il ne gère pas la HA de la base de données : c’est à l’opérateur de monter PostgreSQL en streaming replication + Patroni si on veut un vrai SPOF-free. Deuxièmement, la latence de bascule (60 s par défaut) crée une fenêtre d’aveuglement ; pour les SLA très exigeants, on combine HA Zabbix avec des contrats de redondance externes (par exemple deux clusters Zabbix indépendants en différentes régions, supervisés mutuellement).
Pour des organisations qui ne veulent pas gérer la complexité de la HA infra, l’alternative est l’offre Zabbix Cloud hébergée par Zabbix LLC, qui prend en charge la HA et la base. Elle a un coût, mais pour des équipes < 10 personnes c’est souvent plus rentable que monter et maintenir le cluster soi-même.
Étape 13 — Cas multi-régions
Pour des organisations présentes dans plusieurs régions géographiques (par exemple Europe et Afrique), la HA Zabbix native n’est pas suffisante : si la liaison entre les deux régions tombe, les nœuds de chaque région ne peuvent plus se synchroniser sur la base partagée. Deux approches existent.
La première : un cluster Zabbix unique avec base répliquée par streaming PostgreSQL multi-régions. Tolérant aux pannes d’un nœud serveur ou base, mais pas aux coupures inter-région prolongées. La seconde : deux clusters Zabbix indépendants, un par région, avec proxies locaux. Chaque cluster supervise sa région ; ils se supervisent mutuellement via cross-cluster monitoring. Plus complexe à monter, mais résistant aux pannes inter-région totales.
Le choix dépend de la taille du déploiement et du SLA visé. Pour la majorité des cas, un cluster unique avec base répliquée mono-région suffit largement.
Étape 14 — Documentation et runbooks
Un cluster HA dont l’équipe ne sait pas comment déclencher une bascule manuelle est inutilisable. La discipline finale est de documenter trois procédures dans un runbook accessible. Bascule manuelle planifiée : étapes pour forcer la main vers le standby (typiquement systemctl stop sur le primaire). Récupération après panne : comment ramener un nœud tombé en standby et vérifier sa synchronisation. Test de failover : procédure trimestrielle pour valider que le mécanisme fonctionne toujours.
Sans ces trois procédures écrites et testées, le cluster est de la théorie. La pratique opérationnelle exige qu’au moins deux personnes de l’équipe sachent les exécuter sans hésitation à 3h du matin.
Erreurs fréquentes
| Erreur | Cause | Solution |
|---|---|---|
| Les deux nœuds sont en status « active » | HANodeName identique sur les deux ou base de données différente | Vérifier que les HANodeName sont uniques et que les deux pointent vers la même base |
| Bascule ne se produit pas malgré arrêt du primaire | HAFailoverDelay trop long ou standby ne pointe pas vers la même base | Vérifier SELECT * FROM ha_node et la connectivité base depuis le standby |
| Frontend qui dit « Zabbix server is not running » | Le LB ne route pas vers le bon nœud | Vérifier la santé HAProxy et que le bon nœud est actif |
| Yo-yo entre les nœuds | Latence base élevée ou réseau instable | Augmenter HAFailoverDelay et investiguer la cause réseau |
| Schéma chargé deux fois (erreurs UNIQUE constraints) | Schéma SQL importé depuis chaque nœud par erreur | Drop et recreate la base, charger une seule fois depuis un seul nœud |
Étape 15 — Coût opérationnel du HA
Quelques chiffres réels pour calibrer la décision. Le HA Zabbix natif demande typiquement +30 % de ressources matérielles par rapport au standalone (deux nœuds serveur, réplication base, load balancer). Le temps d’apprentissage de l’équipe est de quelques jours pour bien comprendre les mécanismes et écrire les runbooks. La maintenance courante ajoute un test de failover trimestriel. En contrepartie, la disponibilité passe de 99,5 % typique d’un standalone à 99,95 % ou plus pour un HA bien tenu, ce qui se traduit par cinq à dix incidents de supervision en moins par an.