Aller au contenu
Tous les projets

Projet BTS SIO SISR

Un cluster Proxmox qui redémarre seul ses serveurs

Trois hyperviseurs en haute disponibilité. Si une machine physique s'arrête, les services critiques repartent ailleurs.

Contexte

Deuxième réalisation du cas LGI2A, après le cœur de réseau. Sur le site de Brest, tous les serveurs (annuaire, gestion de parc, supervision) tournaient sur un seul hyperviseur. Une panne de cette machine arrêtait tout.

Le problème

Un seul hôte constitue un point de panne unique. Pour qu’un service redémarre seul sur une autre machine, il faut trois choses : plusieurs hôtes qui se mettent d’accord, un stockage visible par tous, et un réseau qui ne lâche pas.

PostesHyperviseur uniqueADGLPIKumaSPOF : la machine physiqueUne seule machine, un seul disque local, aucun redémarrage ailleursTrafic normal : les services répondentPanne de l’hôte : tous les services s’arrêtent
Avant : tous les services sur un seul hyperviseur. Si la machine s’arrête, tout s’arrête.
PostesHyperviseur uniqueADGLPIKumaSPOF : la machine physiqueUne seule machine, un seul disque local, aucun redémarrage ailleursTrafic normal : les services répondentPanne de l’hôte : tous les services s’arrêtent

Ce que j’ai mis en place

  • Un cluster de trois nœuds. Avec trois votes, le cluster garde le quorum (2 sur 3) quand un nœud tombe. Avec deux nœuds seulement, une panne bloquerait toute décision.
  • Corosync en transport chiffré pour la communication entre les nœuds, avec authentification activée.
  • Un bond LACP sur chaque hôte, en RJ45, relié aux switchs d’étage du projet réseau. Un câble ou un port en panne ne coupe pas le serveur.
  • Un pont réseau « VLAN aware » sur l’agrégat, pour isoler l’administration et les machines virtuelles dans le VLAN serveurs.
  • Deux stockages distincts. Un partage NFS sur TrueNAS accueille les VM critiques : c’est lui qui permet à n’importe quel nœud de les redémarrer. Un stockage local sert au reste.
  • Des snapshots sur les deux stockages, pris sans arrêter les VM.
  • Un groupe HA qui contient les VM critiques (Active Directory, GLPI, Uptime Kuma), avec une priorité de redémarrage pour l’annuaire Active Directory, GLPI et Uptime Kuma.
Corosync · quorum 2/3pve1pve2pve3Switchs d’étagebond LACPTrueNASNFS · VM critiquesdernier point de panne uniqueUne VM critique redémarre sur un nœud sain via le groupe HATrafic normal : les trois nœuds écrivent sur le NFSpve2 en panne : le groupe HA redémarre ses VM sur pve1 ou pve3TrueNAS en panne : plus de stockage partagé, dernier SPOF
Après : trois nœuds, un stockage NFS partagé, un bond LACP par hôte. Le TrueNAS reste le dernier point de panne unique.
Corosync · quorum 2/3pve1pve2pve3Switchs d’étagebond LACPTrueNASNFS · VM critiquesdernier point de panne uniqueUne VM critique redémarre sur un nœud sain via le groupe HATrafic normal : les trois nœuds écrivent sur le NFSpve2 en panne : le groupe HA redémarre ses VM sur pve1 ou pve3TrueNAS en panne : plus de stockage partagé, dernier SPOF

Comment j’ai vérifié

  1. pvecm status : trois nœuds, quorum atteint.
  2. Migration à chaud d’une VM d’un nœud à l’autre, sans coupure.
  3. Arrêt brutal d’un nœud : le gestionnaire HA redémarre l’annuaire, GLPI et Uptime Kuma sur un nœud sain.
  4. Débranchement d’un câble du bond LACP : le serveur reste joignable.

Tests réalisés

  • J'arrête brutalement un nœud du cluster

    Le gestionnaire HA redémarre l'annuaire, GLPI et Uptime Kuma sur un nœud sain

  • Je débranche un câble du bond LACP

    Le serveur reste joignable

  • Je migre une VM à chaud d'un nœud à l'autre

    La VM passe sans coupure

Difficulté rencontrée

Les temporisations LACP doivent être identiques côté serveur et côté switch. Tant qu’elles différaient, j’observais des micro-coupures sur l’agrégat.

Et ensuite

Le cluster tient. Il reste à y installer les services du site : annuaire, GLPI et supervision.

Ce que je ferais mieux

Le TrueNAS reste le dernier point de panne unique du projet. Une réplication vers un second NAS sécuriserait cette ressource.