Lab de formation Proxmox — simulation de crise pour techniciens

Les techniciens de maintenance doivent s'entraîner sur un cluster Proxmox qui se comporte comme la production — quorum, réseaux, stockage, sauvegardes — sans aucun risque pour l'installation réelle. L'objectif : répéter incidents et remises en service sur une copie fidèle, autant de fois que nécessaire, et acquérir les bons réflexes avant d'en avoir besoin sur la ligne.

La spec de formation part d'un inventaire en lecture seule du cluster de production, réalisé via un rebond : aucune modification sur la prod et aucun mot de passe consigné. Il fixe ce que le lab doit reproduire :

• Trois nœuds avec un quorum de deux, Corosync sur un lien dédié avec authentification sécurisée.
• Réseaux management, Corosync et migration / réplication séparés, avec agrégats LACP sur les nœuds de calcul.
• Bridges VLAN-aware portant plusieurs zones SDN et leurs VNets.
• Stockage local, LVM-thin et ZFS, et un Proxmox Backup Server avec tâches de prune, de vérification et de garbage collection.

Les adresses, noms d'hôtes et noms de réseaux de l'installation réelle ne figurent pas sur cette page.

Un seul hôte physique fait tourner un lab complet et isolé par élève : trois nœuds Proxmox VE virtuels et un Proxmox Backup Server virtuel — l'architecture de production, réduite plutôt que simplifiée.

• Trois nœuds et un quorum de deux, avec un troisième nœud plus léger qui joue le rôle du nœud de quorum de la prod.
• Management, Corosync et migration maintenus sur des réseaux séparés, même sur des sous-réseaux de lab plus petits.
• Les zones SDN de production et leurs principaux VNets recréés en premier ; la longue liste de VNets vient dans un second palier.
• Stockage local et LVM-thin partout, ZFS sur deux nœuds, et un datastore de sauvegarde calqué sur celui de la prod.
• Les élèves travaillent depuis un navigateur via Apache Guacamole, une session chacun.

Chaque exercice part d'un cluster sain et connu. Le formateur injecte ensuite une panne — lien Corosync coupé, pool LVM-thin saturé et autres défaillances réalistes — et chaque technicien diagnostique puis rétablit le service sur son propre cluster, comme lors d'un vrai incident.

1. Figer un état de référence propre de chaque lab : le snapshot golden « initial ».
2. Injecter le scénario et laisser chaque technicien intervenir sur son cluster.
3. Sauvegarder l'avancement dans un snapshot « actuel » quand une séance doit s'interrompre.
4. Remettre tous les labs à « initial », en parallèle, pour l'exercice ou le groupe suivant.

Un outil Python écrit pour le formateur, utilisable en interface plein écran dans le terminal (curses) ou en ligne de commande : status, snapshot, restore.

• Par lab : nombre de VM démarrées, et présence des snapshots « initial » et « actuel ».
• Les labs se cochent dans l'interface ; les actions s'exécutent en parallèle sur tous les labs cochés, avec un journal en direct.
• Ordonnancement propre : VM arrêtées dans l'ordre inverse (serveur de sauvegarde d'abord), snapshot ou rollback, puis redémarrage dans l'ordre de boot.
• Une confirmation avant chaque action, et une seconde avant d'écraser un snapshot existant.
• SSH par clé uniquement, en mode batch ; tout passe par les commandes standard qm et pvesh.

Les techniciens peuvent casser et réparer un cluster semblable à la prod autant de fois que nécessaire, et le formateur remet chaque lab à l'état propre en une seule commande — sans jamais toucher à la production.