Aller au contenu

Semaine 7 — Le cluster Proxmox et le stockage partagé

Durée estimée : 45 min · Prérequis : Templates et cloud-init, Sauvegarder une VM et la remettre en place

0. Plan de la séance

Théorie - Ce document : regrouper plusieurs serveurs en un seul cluster et leur donner un stockage commun. - Migration à chaud et haute disponibilité : déplacer une VM sans l'arrêter, et la faire repartir seule quand son serveur tombe.

Pratique - Exercice 1 — Former le cluster d'Aria Airlines - Exercice 2 — Brancher le stockage partagé - Exercice 3 — Préparer le template sur le stockage partagé - Exercice 4 — Déployer Aria Airlines - Exercice 5 — Migrer à chaud pendant une vente - Exercice 6 — Activer la HA et survivre à une panne

Objectifs d'apprentissage

  • Expliquer ce qu'un cluster apporte par rapport à trois serveurs indépendants.
  • Décrire le rôle de corosync et du système de fichiers /etc/pve.
  • Calculer le quorum d'un cluster et prédire ce qui arrive quand il est perdu.
  • Distinguer un stockage local d'un stockage partagé, et dire lequel permet de déplacer une VM sans copier son disque.

1. Le problème : un serveur, c'est un point de défaillance

Aria Airlines vend ses billets en ligne jour et nuit. À l'aéroport, les commis d'enregistrement passent chaque passager par le même logiciel : sans lui, personne ne reçoit de carte d'embarquement et l'avion ne part pas.

Jusqu'ici, chaque VM vivait sur un seul serveur. Si ce serveur tombe en panne, la VM tombe avec lui. Si vous devez le mettre à jour et le redémarrer, il faut couper le service. Un serveur unique est un point de défaillance unique (single point of failure, SPOF) : une seule pièce qui lâche, et tout s'arrête.

La solution n'est pas d'acheter un meilleur serveur. C'est de faire travailler plusieurs serveurs ensemble, pour qu'aucun ne soit indispensable.

2. Ce qu'est un cluster

Un cluster (grappe) est un groupe de serveurs Proxmox qui se gèrent comme un seul. Chaque serveur du groupe s'appelle un nœud (node).

Concrètement, trois choses changent dès que les serveurs forment un cluster :

  • Une seule interface. Vous ouvrez l'interface web de n'importe quel nœud, et vous voyez les trois serveurs dans l'arborescence, avec toutes leurs VM.
  • Une seule configuration. Les VM, les stockages, les utilisateurs et les droits sont déclarés une fois, pour tout le cluster.
  • Des identifiants uniques. Deux VM ne peuvent plus porter le même numéro, même sur deux nœuds différents. La VM 711 n'existe qu'une fois dans tout le cluster.

Le cluster est surtout la base qui permet d'activer d'autres fonctionnalités, qui n'existent pas sur un serveur seul. Elles ont toutes le même but : garder les services disponibles le plus longtemps possible, et réduire le temps pendant lequel ils sont arrêtés (downtime). Les principales :

  • la migration à chaud, qui déplace une VM d'un nœud à l'autre sans l'arrêter ;
  • la réplication, qui recopie le disque d'une VM vers un autre nœud à intervalle régulier (sur du stockage ZFS local, que vous n'utiliserez pas cette semaine) ;
  • la haute disponibilité, qui redémarre les VM d'un nœud en panne sur les autres nœuds ;
  • l'équilibrage de charge, qui répartit les VM entre les nœuds quand la haute disponibilité les démarre ou les reprend après une panne, pour éviter qu'un seul nœud reçoive tout.

Vous verrez la migration à chaud et la haute disponibilité dans la deuxième note de la semaine.

Corosync : les nœuds se parlent

Les nœuds doivent savoir en permanence lesquels sont vivants. C'est le travail de corosync, un service qui envoie de petits messages entre les nœuds plusieurs fois par seconde. Un nœud qui ne répond plus est considéré comme absent.

Corosync supporte mal un réseau lent. La documentation de Proxmox exige une latence sous 5 millisecondes entre les nœuds, et recommande un réseau dédié en production. Dans le laboratoire, corosync passe par le réseau de gestion, en même temps que l'interface web.

/etc/pve : la configuration partagée

Sur un nœud Proxmox, toute la configuration est rangée dans /etc/pve. Ce dossier n'est pas un dossier ordinaire : c'est pmxcfs, le système de fichiers de cluster de Proxmox. Ce qu'un nœud y écrit apparaît sur les autres nœuds en moins d'une seconde.

Texte
/etc/pve/
├── corosync.conf             la liste des nœuds du cluster
├── storage.cfg               les stockages, pour tout le cluster
└── nodes/
    ├── pve12/qemu-server/    les VM qui tournent sur pve12
    ├── pve13/qemu-server/
    └── pve14/qemu-server/

Le fichier d'une VM est rangé dans le dossier du nœud qui l'héberge. Déplacer une VM, c'est donc entre autres déplacer ce fichier d'un dossier à l'autre. Chaque nœud a une copie complète de /etc/pve : si l'un d'eux disparaît, la configuration de ses VM reste lisible par les autres.

Un nœud qui joint un cluster perd sa propre configuration

Au moment de joindre le cluster, le contenu de /etc/pve du nouveau nœud est remplacé par celui du cluster. C'est pourquoi Proxmox refuse qu'un nœud contienne la moindre VM au moment où il joint : ses identifiants pourraient entrer en conflit avec ceux du cluster. Le nom d'hôte et l'adresse IP du nœud ne peuvent plus changer ensuite.

3. Le quorum : la majorité décide

Imaginez un cluster de deux nœuds dont le câble réseau qui les relie est coupé. Chaque nœud voit l'autre disparaître. Chacun conclut que l'autre est en panne et démarre les VM de l'autre. Vous avez maintenant deux copies de la même VM, qui écrivent en même temps dans le même disque. Le disque est corrompu en quelques secondes.

Cette situation s'appelle un split-brain (cerveau divisé). Pour l'empêcher, Proxmox applique une règle simple : un groupe de nœuds n'a le droit d'agir que s'il forme une majorité stricte. Cette majorité s'appelle le quorum.

Nœuds dans le cluster Quorum (votes nécessaires) Pannes tolérées
2 2 aucune
3 2 une
4 3 une
5 3 deux

Avec trois nœuds, un nœud isolé n'a qu'un vote sur trois : il n'a pas le quorum, il ne fait rien. Les deux autres ont deux votes sur trois : ils continuent. Il ne peut jamais y avoir deux groupes majoritaires en même temps, donc jamais deux copies d'une même VM.

Un nœud qui perd le quorum passe en lecture seule : il ne peut plus démarrer de VM, en créer, ni modifier leur configuration. Les VM qui tournaient déjà sur lui continuent de tourner.

Le tableau montre aussi pourquoi un cluster de deux nœuds n'est pas fiable : la panne d'un seul nœud fait perdre le quorum à l'autre. Pour la haute disponibilité, Proxmox exige au moins trois nœuds. Un petit cluster de deux serveurs peut emprunter un troisième vote à un QDevice, un petit service installé sur une autre machine qui ne fait que voter.

La commande pvecm status affiche l'état du quorum. Les lignes à lire :

Texte
Nodes:            3
Quorate:          Yes
Expected votes:   3
Total votes:      3
Quorum:           2

Quorate: Yes signifie que ce nœud fait partie de la majorité. Total votes compte les nœuds présents en ce moment, et Quorum donne le minimum à atteindre.

4. Le stockage : local ou partagé

Le cluster permet de déplacer une VM d'un nœud à l'autre. Il reste un problème : son disque.

Le stockage local

Depuis la semaine 2, les disques de vos VM sont sur local-lvm, c'est-à-dire sur les disques physiques du serveur lui-même. Le serveur 3 ne peut pas lire un disque qui se trouve dans le serveur 2.

Pour déplacer une VM dont le disque est local, Proxmox doit recopier le disque entier par le réseau vers l'autre nœud. Un disque de 32 Go, c'est plusieurs minutes. Et si le serveur 2 est en panne, il n'y a plus rien à recopier : le disque est enfermé dans une machine éteinte.

Le stockage partagé

Un stockage partagé est un espace disque que tous les nœuds voient en même temps, généralement par le réseau. Le disque de la VM ne se trouve dans aucun des nœuds : il est sur une machine à part, et chaque nœud peut l'ouvrir.

flowchart TB
    subgraph Cluster aria
        N1["pve · serveur 1"]
        N2["pve · serveur 2"]
        N3["pve · serveur 3"]
    end
    NAS[("Serveur NFS<br/>disques des VM")]
    N1 --- NAS
    N2 --- NAS
    N3 --- NAS

Avec un stockage partagé, déplacer une VM ne demande plus de copier son disque. Seul le contenu de la mémoire vive voyage, et la VM change de nœud en quelques secondes. Si un nœud tombe, ses VM peuvent redémarrer ailleurs, puisque leurs disques sont toujours là. Pas de stockage partagé, pas de haute disponibilité.

Proxmox sait utiliser plusieurs types de stockage. Le type décide s'il est partagé ou non.

Type Où sont les données Partagé
dir, lvmthin (local, local-lvm) sur les disques du nœud non
zfspool sur les disques du nœud non
nfs, cifs sur un serveur de fichiers, par le réseau oui
iscsi + lvm sur une baie de stockage, par le réseau oui
rbd (Ceph) réparti sur les disques de tous les nœuds oui

NFS

NFS (Network File System) permet à un serveur de prêter un de ses dossiers à d'autres machines. Ce dossier prêté s'appelle un export. Chaque nœud Proxmox monte l'export sous /mnt/pve/<nom-du-stockage>, et y range les disques des VM comme dans un dossier ordinaire.

NFS est le stockage partagé le plus simple à mettre en place : une seule machine, un dossier, une ligne de configuration. C'est celui que vous utiliserez cette semaine. Les disques y sont rangés sous forme de fichiers .qcow2, un format qui sait faire des snapshots et des clones liés.

Un stockage se déclare une seule fois pour tout le cluster, dans Datacenter > Storage. La déclaration est écrite dans /etc/pve/storage.cfg, et chaque nœud monte l'export de lui-même.

Le serveur NFS devient à son tour un point de défaillance

Si le serveur NFS tombe, les disques de toutes les VM disparaissent en même temps, sur tous les nœuds. Le cluster protège contre la panne d'un nœud, pas contre celle du stockage. En production, le stockage lui-même est doublé : une baie avec deux contrôleurs, ou Ceph, qui recopie chaque bloc sur plusieurs nœuds.

Pièges fréquents

  • Joindre un nœud qui contient encore une VM. Proxmox refuse. Il faut d'abord sauvegarder et supprimer les VM du nœud, joindre, puis restaurer sous un nouvel identifiant.
  • Joindre depuis le mauvais nœud. Le cluster se crée sur un nœud, et les autres le rejoignent. Créer un cluster sur chaque nœud donne trois clusters d'un seul nœud, qui ne pourront plus se rejoindre sans réinstallation.
  • Monter un cluster de deux nœuds et s'attendre à de la haute disponibilité. La panne d'un nœud fait perdre le quorum à l'autre, qui passe en lecture seule.
  • Croire qu'un stockage est partagé parce qu'il porte le même nom partout. local-lvm existe sur chaque nœud, mais chacun désigne ses propres disques. Ce n'est pas le même stockage.

Vérification des acquis

Question 1

Votre cluster compte trois nœuds. Le câble réseau du serveur 3 est arraché. Que se passe-t-il sur le serveur 3 ?

  • a) Il démarre les VM des serveurs 1 et 2, qu'il croit en panne.
  • b) Il perd le quorum et passe en lecture seule. Ses VM continuent de tourner, mais il ne peut plus en démarrer.
  • c) Il s'éteint immédiatement pour protéger les disques.
  • d) Rien ne change : chaque nœud reste autonome.
Voir la réponse **b) Il perd le quorum et passe en lecture seule.** Le serveur 3 n'a plus qu'un vote sur trois, ce qui est sous le quorum de deux. Il n'a donc plus le droit de démarrer ou de modifier quoi que ce soit. Les serveurs 1 et 2, eux, gardent deux votes et continuent normalement. Le choix a) décrit exactement le split-brain que le quorum empêche. Un nœud minoritaire ne prend jamais de décision, justement parce qu'il ne peut pas savoir si ce sont les autres qui sont en panne ou lui qui est isolé.

Question 2

Pourquoi un cluster de deux nœuds ne convient-il pas à la haute disponibilité ?

  • a) Parce que corosync a besoin d'au moins trois adresses IP pour fonctionner.
  • b) Parce que la panne d'un nœud laisse l'autre avec un vote sur deux, ce qui n'est pas une majorité stricte.
  • c) Parce que Proxmox limite les clusters de deux nœuds à dix VM.
Voir la réponse **b) Parce que la panne d'un nœud laisse l'autre avec un vote sur deux.** Le quorum demande une majorité **stricte** : plus de la moitié des votes. Un vote sur deux, c'est exactement la moitié, et non une majorité. Le nœud survivant passe donc en lecture seule au moment précis où il devrait reprendre les VM de l'autre. Le choix a) est faux : un cluster de deux nœuds se forme sans difficulté. Il fonctionne très bien tant que les deux nœuds sont présents. Le problème n'apparaît qu'à la première panne.

Question 3

Une VM a son disque sur local-lvm du serveur 2. Le serveur 2 tombe en panne de courant. Pourquoi la VM ne peut-elle pas redémarrer sur le serveur 1 ?

  • a) Parce que son fichier de configuration a disparu avec le serveur 2.
  • b) Parce que son disque se trouve physiquement dans le serveur 2, que plus personne ne peut lire.
  • c) Parce que le serveur 1 n'a pas assez de mémoire.
Voir la réponse **b) Parce que son disque se trouve physiquement dans le serveur 2.** `local-lvm` désigne les disques du nœud lui-même. Le serveur 1 a son propre `local-lvm`, qui porte le même nom mais ne contient pas ce disque. Seul un stockage partagé laisse un autre nœud ouvrir le disque d'une VM dont le serveur est éteint. Le choix a) est tentant, mais faux : la configuration est dans `/etc/pve`, que chaque nœud du cluster garde en copie complète. Le serveur 1 sait parfaitement à quoi ressemblait la VM. C'est son disque qui manque.

Question 4

Vous ajoutez un stockage NFS dans Datacenter > Storage depuis l'interface du serveur 1. Sur quels nœuds est-il disponible ?

  • a) Sur le serveur 1 seulement. Il faut refaire la manipulation sur chaque nœud.
  • b) Sur tous les nœuds du cluster, parce que la déclaration est écrite dans /etc/pve/storage.cfg.
  • c) Sur tous les nœuds, mais seulement après leur redémarrage.
Voir la réponse **b) Sur tous les nœuds du cluster.** `storage.cfg` se trouve dans `/etc/pve`, que pmxcfs recopie sur chaque nœud en moins d'une seconde. Chaque nœud lit la nouvelle déclaration et monte l'export NFS de lui-même, sans redémarrage. Le choix a) correspond à ce que vous faisiez avant le cluster : chaque serveur avait sa propre configuration. C'est précisément ce que le cluster supprime.

Pour aller plus loin