Contexte : projet annuel ESGI 2025, supervision Zabbix en haute disponibilité · Testé sur : Debian 12, Zabbix 7.0, Nginx, PHP 8.2, MariaDB Galera, Pacemaker et Corosync (VM sous VMware vSphere) · Dernière vérification : contenu de 2025 non revérifié
Mettre en place une supervision Zabbix 7.0 capable de résister à la panne d'un serveur :
SRV-ZABBIX-01 et SRV-ZABBIX-02, portant chacun Zabbix, Nginx, PHP 8.2 et MariaDB ;pcs).Zabbix ne prend en charge qu'un seul processus serveur actif : c'est Pacemaker qui décide sur quel nœud il tourne. Sur un nœud du cluster, le service
zabbix-serverne doit jamais être démarré à la main, mais toujours viapcs.
| Nœud | Adresse IP | Rôle |
|---|---|---|
| SRV-ZABBIX-01 | 192.168.30.10/24 | Serveur Zabbix initial, premier nœud Galera (amorçage du cluster) |
| SRV-ZABBIX-02 | 192.168.30.20/24 | Clone de SRV-ZABBIX-01, second nœud |
Passerelle de la maquette : 192.168.30.1. Interface web Zabbix : http://192.168.30.10/zabbix.
Composants mis en œuvre :
galera-4) : cluster zabbix-galera à deux nœuds, rsync pour la synchronisation initiale des nœuds ;zabbix-ha, ressource zabbix-server de type systemd surveillée toutes les 30 secondes, avec une stickiness de 100 pour éviter les basculements trop fréquents ;HANodeName renseigné dans /etc/zabbix/zabbix_server.conf sur chaque nœud.Depuis Zabbix 6.0, le paramètre
HANodeNameactive le mode haute disponibilité natif de Zabbix (un nœud actif, les autres en attente). Dans cette maquette, le démarrage du service reste confié à Pacemaker.
Le projet est documenté en trois tutoriels, à suivre dans l'ordre :
Pour aller plus loin : Scripts avec l'agent Zabbix (Bash et PowerShell) décrit la création de paramètres utilisateur personnalisés pour l'agent. L'ancienne procédure Zabbix 6.4 sur Debian 11 est conservée dans les archives.
Contrôles retenus pour valider le projet :
SHOW STATUS LIKE 'wsrep_cluster_size'; doit renvoyer 2.sudo pcs status doit afficher les deux nœuds en ligne et la ressource zabbix-server démarrée sur un seul d'entre eux.pcs status que Pacemaker a basculé la ressource zabbix-server sur SRV-ZABBIX-02 ;Hosts 'SRV-ZABBIX-01' not known to pcs : vérifier que /etc/hosts déclare les deux nœuds sur les deux serveurs. Si l'erreur persiste, détruire le cluster (pcs cluster destroy --all), refaire l'authentification puis la création, voire recloner la VM si son état est corrompu.stonith-enabled=false) faute de périphérique de fencing : acceptable en maquette, à revoir pour une mise en production.galera_new_cluster, le second avec un simple systemctl start mariadb.Une reprise du projet a été amorcée sur l'hôte Proxmox VE alpha, sous forme de conteneurs :
| CT | Nom | Adresse | État |
|---|---|---|---|
| 107 | Zabbix-PCT-107 | 192.168.1.107 | Zabbix 7.0 installé, arrêté ; frontend jamais configuré |
| 108 | Zabbix-PCT-108 | 192.168.1.108 | Clone du CT 107 destiné au futur cluster HA Galera, arrêté |
Le CT 107 ne doit pas être exposé sur Internet tant que son frontend n'est pas configuré et sécurisé. Détails et état à jour : Fiche service : Zabbix (CT 107 / 108).