The Operations Loop 03 — Vérifier le basculement et la reprise

EdwardMoon

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

PROD a été installé sur un disque vide de 32 GiB avec une carte réseau interne. SSH via le bastion a confirmé Rocky Linux 10.2, l’adresse 10.77.20.101/24, SELinux Enforcing et le marqueur de fin PXE. La mémoire a ensuite été réduite de 4 à 1 GiB.

Le travail de vérification a confirmé la réception de données réelles et récentes de durée de fonctionnement. La validation exigeait à la fois l’enregistrement et la collecte effective des données.

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.

Après installation PXE sur disque vide, DEV a terminé le Workflow 30 : enregistrement 31, mise à jour d’inventaire 32 et vérification 34. L’hôte supervisé 10684 utilisait le Proxy DEV 2, sur un chemin distinct 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.

STG a également fourni des données récentes et réelles. AWX contenait les trois hôtes avec leurs adresses de gestion et variables d’environnement. L’approbation initiale de l’identité SSH restait une étape opérateur, sans contournement des 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

La base NetBox a été sauvegardée avec pg_dump puis restaurée avec pg_restore dans une base de vérification séparée. L’actif fml-prod-app-01 et sa relation avec l’adresse de gestion principale ont été vérifiés.

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.

Les premiers essais ont révélé un retard de reprise NetBox lié aux tentatives de reconnexion au cache. Après examen du code de configuration, le Sentinel local a été priorisé et les tentatives de connexion limitées, puis l’essai a été répété.

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

Le nœud central 2, actif pour PostgreSQL, Redis et Zabbix, a été arrêté brutalement. Le transfert des rôles et les réponses des services sur le nœud 1 ont été confirmés. Des erreurs temporaires sont apparues pendant la transition : le basculement n’est donc pas qualifié de sans interruption.

Pendant l’arrêt du nœud 2, un marqueur a été écrit, relu puis retiré d’un actif NetBox. L’actif et son adresse de gestion ont été conservés, confirmant l’écriture via la base survivante. La reprise de la réponse d’état AWX ne prouve pas la continuité des travaux en cours.

Après redémarrage, le nœud 2 a repris son rôle de réplica synchrone PostgreSQL et NetBox est redevenu sain. Le maintien du service et le retour de la capacité de secours ont été contrôlés séparément.

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

Le sens inverse a été testé en arrêtant le nœud 1. Le nœud 2 a conservé l’adresse de service et le rôle d’écriture de la base. Les requêtes NetBox et les nouvelles données Zabbix ont repris, avec conservation des identifiants et adresses de gestion.

AWX était uniquement installé sur le nœud 1 et indisponible pendant son arrêt. Le redémarrage a rétabli AWX, la réplication et NetBox. Il s’agit de la reprise du serveur d’origine, et non d’un succès de haute disponibilité AWX.

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é

Seul le transport de supervision TCP 10051 du Proxy PROD 10.77.20.10 vers le réseau central a été bloqué. SSH, la collecte locale des agents et DEV sont restés accessibles. Les mises à jour centrales de PROD se sont arrêtées tandis que DEV continuait.

La consultation en lecture seule de la base du Proxy PROD a confirmé la présence de données encore absentes du serveur central. Le total des lignes n’a pas été assimilé aux données non envoyées, car des lignes déjà transmises peuvent attendre leur nettoyage.

La règle temporaire est restée active malgré son expiration configurée. Elle a été supprimée explicitement et la connectivité vérifiée. Les essais suivants contrôlent la suppression réelle sans se fier uniquement au minuteur.

Après rétablissement, les données conservées ont intégré l’historique central dans leur ordre et selon leur intervalle d’origine ; les valeurs récentes ont repris. La rétention longue, le disque plein et la panne de la VM Proxy restent des validations distinctes.

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

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.