The Operations Loop : bilan de vérification, de l’enregistrement à la reprise après panne

AI_Manager

Le critère de validation n’est pas de savoir si l’écran s’ouvre, mais si les données et les chemins sont réellement connectés. Cet article enregistre les tâches exécutées et les résultats observés lors de l’exercice VirtualBox du 2026-09-20. Il distingue les attentes de conception, les tests réels et le périmètre non encore exécuté.

• 1. Environnement de validation et critères d’évaluation
• 2. Enregistrement d’un intégrant normal réel
• 3. Problèmes découverts et corrigés jusqu’au chemin normal
• 4. Sauvegarde et restauration isolée
• 5. Test de panne du nœud central
• 6. Coupure du proxy et retransmission de données différées
• 7. Protection des données d’actifs et validation des chemins
• 8. Installation sur une cible sans Internet et validation des paquets
• 9. Validation de l’écran d’architecture
• 10. Liste de contrôle de validation et limites
• Lectures recommandées et matériaux de configuration

1. Environnement de validation et critères d’évaluation

Rocky Linux 10.2, Zabbix 7.0.30 LTS, NetBox 4.7.1 et AWX 24.6.1 ont été utilisés. Deux VM centrales avec quorum, une passerelle, un provisionnement et un proxy/bastion pour les trois environnements ont été configurés. Toutes les VM partagent la mémoire, le CPU et le stockage d’un même PC physique.

Un intégrant normal doit réussir l’ensemble des étapes suivantes pour être validé : installation PXE -> chemin SSH autorisé -> collecte d’actifs réelle -> IPAM natif NetBox -> enregistrement Zabbix -> synchronisation d’inventaire AWX basée sur NetBox -> confirmation de la dernière valeur réelle. La réponse à l’enregistrement API et la réception des dernières données sont des éléments de vérification distincts.

2. Enregistrement d’un intégrant normal réel

La cible PROD a été installée avec un disque vide de 32GiB et une seule carte réseau de réseau interne. Le 2026-09-20 à 04:13 KST, nous avons vérifié l’indicateur d’achèvement de l’installation PXE pour Rocky 10.2, 10.77.20.101/24, SELinux Enforcing via SSH en passant par le Bastion. La RAM d’installation de 4GiB a été ramenée à 1GiB après un arrêt normal.

Le Verify Job a vérifié lastclock=1789846239, lastvalue=942 et l’heure de vérification était 1789846262. Il s’agit de la valeur d’uptime réelle collectée 23 secondes avant le moment de la vérification. Cette valeur n’est pas un chiffre créé à titre d’exemple, mais un enregistrement lu à partir des résultats du Job.

NetBox contient 1 vCPU, 954 Mio de mémoire disponible pour l’invité, 32768 Mio de disque, Rocky Linux 10.2, un type de virtualisation virtualbox, la NIC de gestion enp0s3, ainsi que l’environnement PROD et la structure de partition réelle. La valeur observée de la mémoire de l’invité (954 Mio) et la valeur allouée par VirtualBox (1024 Mio) sont différentes.

L’inventaire NetBox d’AWX a reçu ansible_host=10.77.20.101, ansible_user=labadmin, fml_environment=prod et fml_subnet=20. Non seulement le nom de la ressource a été synchronisé, mais l’adresse IP de gestion et les variables d’environnement nécessaires au calcul du chemin du bastion ont également été vérifiées.

DEV a également effectué une installation PXE à partir d’un disque vide, puis a exécuté le Workflow 30. De 05:00:40 à 05:03:34 KST, Onboard 31, inventory update 32 et Verify 34 se sont tous terminés avec le statut successful. L’hôte Zabbix 10684, le proxy 2 et l’élément d’uptime 50884 ont été connectés à un environnement différent de PROD.

STG s’exécute automatiquement lors de la détection de la fin de l’installation

Après avoir approuvé la première identité SSH de STG avec la clé publique et l’empreinte de la console série VirtualBox, la RAM d’installation a été réduite de 4 Gio à 1 Gio. Le contrôleur de fin d’installation a vérifié la clé d’approbation, le marqueur d’installation, le nom d’hôte ainsi que l’ID de machine, et a synchronisé le SCM et l’inventaire de bootstrap. Ensuite, le Job 38 a été lancé sans exécution manuelle du Workflow.

Nous avons vérifié la valeur d’activité réelle jusqu’à 17 secondes avant l’heure de vérification. Les trois hôtes PROD, DEV et STG ainsi que leurs adresses IP de gestion et variables d’environnement respectives ont également été interrogés dans l’inventaire NetBox d’AWX. La première approbation d’identité SSH est une étape de gestion intentionnellement conservée, et les connexions automatiques ne contournent pas les clés non approuvées.

3. Problèmes identifiés et corrigés jusqu’au parcours normal

Les tâches échouées n’ont pas non plus été supprimées. Elles ont été conservées pour permettre de comparer le commit de correction avec le résultat du Job suivant. Les cas d’échec survenus avant l’enregistrement dans NetBox/Zabbix ne doivent pas être confondus avec une situation de création en double d’actifs réels.

4. Sauvegarde et restauration en isolement

Le 20-09-2026 à 04:40 KST, la base de données NetBox a été sauvegardée au format personnalisé pg_dump et restaurée dans un netbox_restore_20260919194012 distinct de la base de données NetBox de production à l’aide de pg_restore. L’ID de VM 1, fml-prod-app-01 et primary_ip4_id 1 ont été interrogés dans la base de données restaurée.

Le hachage SHA-256 de la sauvegarde est 06914eb419d88edb97245ed435177b396309a625b65eb14b72ae9fb627667390. Une base de données de vérification séparée a été utilisée sans écraser la base de données existante. Ce résultat constitue un test de restauration logique de la base de données NetBox et non un test de reprise après sinistre visant à récupérer l’ensemble des machines virtuelles, des médias, d’AWX et de Git en une seule fois.

5. Test de défaillance du nœud central

Juste avant le premier test, le leader PostgreSQL était ops02, ops01 était en attente synchrone (sync standby) et le décalage de réplication était de 0. Zabbix avait ops01 en actif et ops02 en attente. L’alimentation du premier serveur a été coupée de force pour simuler une perte d’alimentation de la machine virtuelle.

L’adresse VIP 10.77.10.10 a basculé vers le deuxième serveur. Cependant, pendant la phase de transition, le backend NetBox a renvoyé 500 et la VIP a renvoyé 503. Par la suite, Zabbix a démarré les tâches actives sur le deuxième serveur et a reçu les connexions des trois proxys. Ce test n’a pas été validé comme un « succès de la haute disponibilité sans interruption ».

Le premier fichier journal de l’outil d’observation n’a pas été généré en raison d’un chemin incompatible avec la politique SELinux. Par conséquent, aucun RTO précis n’est calculé pour ce test. Le chemin des journaux a été déplacé sous /var/log et le test a été rejoué après vérification de l’enregistrement normal.

En vérifiant le code de configuration réel de NetBox 4.7.1, SENTINEL_TIMEOUT pour la mise en cache ne correspondait pas au même fonctionnement que la file d’attente des tâches. Lors du deuxième test avec l’ajout du seul délai d’attente, une seule requête de cache a tout de même pris 55,6 secondes. À ce moment-là, la première réponse réussie de NetBox après la coupure de courant du premier serveur est intervenue environ 104 secondes plus tard. Par la suite, une recherche prioritaire locale dans Sentinel et une limitation explicite des nouvelles tentatives ont été appliquées conjointement.

Perte d’alimentation du second serveur actif (base de données, Redis, Zabbix) après correction

Arrêt forcé d’ops02 à 05:08:20.777 KST. Juste avant, ops02 était le primary PostgreSQL, le master Redis et le Zabbix active, tandis que ops01 était le DB sync standby/lag 0. Les API indépendantes ont été interrogées depuis la machine 1 avec un intervalle de 5 secondes et un délai d’attente (timeout) de requête de 4 secondes. Les valeurs ci-dessous vont de l’heure de la commande d’incident jusqu’à l’heure de la première observation dudit état et ne constituent pas un temps de basculement interne précis ni un SLA garanti.

À 05:10:11, la machine 2 étant éteinte, un marquage de test a été appliqué via PATCH sur les commentaires de l’actif NetBox, lu via GET, puis restauré à son contenu d’origine. L’ID d’actif 1 et l’IP primaire ont été conservés. Non seulement l’écran de consultation s’est ouvert, mais l’écriture sur le chemin de la base de données active a également été confirmée. Le rétablissement du ping d’AWX ne signifie pas une absence d’interruption (zero-downtime) du Job en cours d’exécution. Ne pas extrapoler en concluant au succès d’un nouveau Job exécuté pendant ce test.

La machine 2 a redémarré à 05:11:19. PostgreSQL a été récupéré selon la timeline 3 et vérifié lors du contrôle de 05:18 en tant que sync standby/lag 0. NetBox a pris plus de temps à être prêt en raison de l’initialisation et du lancement du worker Python, et le contrôle de 05:23 a confirmé qu’il était healthy avec un HTTP 200. Le temps de survie du service et le temps de retour du nœud défaillant à la capacité de réserve sont deux choses différentes.

Perte de puissance de la machine 1 active pour VIP/DB/Zabbix après modification

Le sens inverse a également été testé. Arrêt forcé d’ops01 à 05:24:28.045 KST. Le VIP 10.77.10.10 a été vérifié sur ops02, et le primary PostgreSQL a été observé en environ 39 secondes, la réponse normale de l’API Zabbix après l’erreur en environ 44 secondes, la requête d’actifs NetBox en environ 69 secondes, et la valeur de supervision post-incident en environ 111 secondes. L’ID d’actif et l’IP de gestion ont été conservés.

AWX n’étant présent que sur ops01, il n’a pas pu être joint pendant que le nœud était éteint. Après avoir rallumé ops01 à 05:26:44, le ping d’AWX s’est rétabli à 05:29:24. Cette valeur ne correspond pas à un succès de la HA d’AWX en soi, mais à la reprise du service suite à la récupération du nœud d’origine. Après le redémarrage, PostgreSQL est revenu au sync standby/lag 0 de la timeline 4 et NetBox App était également healthy.

Les deux tests incluent des temps de timeout et des erreurs HTTP 500/503 dans la section de transition. Le terme « sans interruption » ne doit pas être utilisé. Les chiffres avant et après l’amélioration pour des tests similaires impliquant des emplacements de bases de données actives et des charges différentes, il ne faut pas déduire hâtivement l’effet d’amélioration des performances sur la base d’un simple ratio.

6. Coupure du Proxy et retransmission des données en différé

À 05:12:43 KST, seule la plage TCP 10051 a été bloquée par la passerelle (Gateway) depuis PROD Edge 10.77.20.10 vers la plage centrale. Les chemins SSH, Agent→Proxy et DEV ont été maintenus. L’uptime PROD central s’est figé au clock 1789848759, mais DEV a continué à se mettre à jour toutes les 30 secondes.

En interrogeant le SQLite du Proxy PROD en lecture seule, des valeurs telles que clock 1789848879, qui n’étaient pas encore présentes au centre, existaient dans proxy_history. Le nombre total de lignes dans SQLite pouvant inclure des lignes dont le transfert était terminé avant le nettoyage, le nombre de lignes en soi n’a pas été interprété comme le « nombre de lignes non transmises ».

Bien que timeout=240 ait été spécifié dans la règle temporaire, la règle était toujours présente lors de la vérification à 05:18:52. La règle de test correspondante a été explicitement supprimée, et la section de blocage réelle a été enregistrée à environ 6 minutes et 9 secondes. Ne pas écrire que le rétablissement a eu lieu après 4 minutes en se fiant uniquement à l’option de minuterie. Pour les tests répétés, la planification de la récupération externe et la vérification de l’absence de règles sont effectuées conjointement.

À 05:19:30, les résultats du history.get central ont affiché à nouveau les valeurs collectées pendant la coupure, de 1789848789, 8819, 8849, 8879 à 9119, en maintenant un intervalle de 30 secondes. La valeur la plus récente a également été mise à jour à 1789849149. La collecte locale pendant l’interruption de la transmission → le stockage sur disque → la répercussion de l’historique à l’heure d’origine après le rétablissement ont été confirmés par des données réelles. Ce test court ne valide pas la conservation d’une mémoire tampon (buffer) de 24 heures, le remplissage du disque ou une panne de la machine virtuelle (VM) Proxy elle-même.

7. Protection des données d’actifs et vérification des chemins

Sur la base des résultats de collecte PROD réels, la même inscription NetBox a été exécutée à nouveau. L’ID de VM 1 et l’ID d’adresse IP 1 ont été conservés, et un seul exemplaire du même nom et de la même adresse existait. La mise à jour de l’heure de collecte et la création d’actifs en double ont été distinguées.

L’échec de collecte partielle est une entrée créée pour les tests et n’est pas présenté comme un cas réel de panne de disque. Les conditions de rejet sont vérifiées en premier avant toute modification, et dans les situations où seule une partie des API réussit, les objets ayant réussi ne sont pas supprimés aveuglément afin de permettre une nouvelle exécution.

8. Installation de cibles sans accès Internet et vérification des paquets

La cible PXE possède une seule carte réseau sur le réseau interne et ne dispose pas de carte réseau NAT ou pont. Le système d’exploitation a été obtenu à partir de l’arborescence d’installation Rocky 10.2 Minimal de Provision. Après avoir vidé le cache RPM de l’agent sur PROD, zabbix-agent2 7.0.30 a été réinstallé en activant uniquement deux dépôts internes. Le téléchargement effectif de 6.4 Mo, la vérification GPG et l’activation du service ont été confirmés.

Sur la même cible dont la connexion externe est refusée, HTTPS NetBox utilisant les métadonnées de dépôt internes et la vérification CA a renvoyé 200. La réinstallation complète du système central sur un nouveau réseau isolé relève d’un périmètre distinct. Ce qui a été vérifié cette fois-ci, c’est l’installation du système d’exploitation, le déploiement de l’agent et l’intégration de l’API interne sur une cible sans accès Internet.

9. Vérification de l’écran d’architecture

L’état de panne et la lecture du flux de l’architecture sont à des fins descriptives. Il ne s’agit pas d’un tableau de bord opérationnel envoyant des commandes aux serveurs ou affichant l’état réel.

10. Liste de contrôle de vérification et limites

L’UEFI PXE du serveur physique réel, l’automatisation BMC/RAID, la défaillance entre deux hôtes physiques, la défaillance complète du stockage et la détection des versions de tous les produits commerciaux DB/WAS ne sont pas considérés comme validés par cette pratique sur VM. Il convient de dissocier l’implémentation de chaque fonctionnalité et la portée réelle du test.

Il faut également distinguer l’installation initiale en ligne de l’installation sur une cible sans Internet et du déploiement d’agents. Le test de réinstallation complète de l’ensemble du système central à partir de zéro dans un nouveau réseau fermé doit inclure la vérification des dépendances du lot d’importation. Cela ne peut être remplacé par le simple résultat d’une coupure de la carte réseau externe sur un service existant.

Les éléments validés dans cette pratique et les prochaines tâches de vérification sont présentés dans le même tableau. Le résultat obtenu sur un PC personnel ne doit pas être présenté comme garantissant le SLA de production ou une absence totale de perte de données en cas de panne.

Lectures associées et documents de configuration

Article original du portfolio · Guide de construction des réseaux en ligne et fermés · Scénarios de pannes et historique de validation · Historique de dépannage de la configuration VirtualBox

ZIP des sources de configuration et d’automatisation de la pratique · ZIP SHA-256

Le fichier ZIP public contient les modèles de configuration et les sources d’automatisation. Il n’inclut pas le système d’exploitation, les RPM, les images de conteneurs ni les identifiants. Configurez-le avec vos propres adresses, votre autorité de certification publique, vos clés SSH approuvées et votre gestionnaire de secrets avant de l’appliquer.