1. Constituer le cluster

Avant de cliquer sur Create Cluster, il faut savoir ce qu'on construit. Un cluster tient par trois choses : un vote à la majorité, le quorum ; un réseau sur lequel les nœuds se parlent ; et un second chemin si ce réseau tombe. Ce sont elles qui dictent la préparation des nœuds (§1.2) et les choix de la fenêtre de création (§1.3).

1.1 Avant d'assembler : ce qu'est un cluster, et ce qui le fait tenir

À quoi sert un cluster

Un cluster Proxmox VE est un groupe de nœuds administrés comme une seule entité. Il apporte trois choses qu'un serveur seul ne peut pas offrir :

Ce qu'un cluster n'est pas :

• un stockage partagé : chaque nœud garde ses disques. Pour qu'une VM soit visible de partout, il faut une brique de plus, comme Ceph (§3), NFS ou iSCSI (chapitre 3) ;
• un répartiteur de charge : il ne répartit pas les requêtes des utilisateurs entre les VM.

Sa limite principale, c'est le réseau. Les nœuds doivent rester proches : même salle ou même site, avec un délai de quelques millisecondes au plus.

On ne fait pas un cluster entre deux villes. Pour administrer plusieurs clusters ou des sites éloignés, il existe Proxmox Datacenter Manager, une console web qui les réunit.

Deux composants sur chaque nœud

Corosync est le moteur de communication du cluster. Il envoie des messages de type « battement de cœur » (heartbeat) entre les nœuds, à intervalle régulier, pour vérifier que chaque membre est toujours vivant. Il compte aussi les nœuds présents : c'est lui qui calcule le quorum.

pmxcfs (Proxmox Cluster File System) est le système de fichiers monté sur /etc/pve/. Son contenu vit dans une petite base SQLite locale (/var/lib/pve-cluster/config.db), gardée en mémoire pour la vitesse. Chaque modification est répliquée en temps réel sur tous les nœuds du cluster, par l'intermédiaire de Corosync.

C'est là que vivent les configurations des VMs, des conteneurs, des stockages et des utilisateurs. Quand vous modifiez la configuration d'une VM depuis n'importe quel nœud, le changement se propage instantanément sur l'ensemble du cluster.

Dans un cluster, il n'y a pas de nœud « de stockage » ou de nœud « de gestion ». Chaque serveur exécute la même pile de services, et c'est leur accord qui fait le cluster.

Le quorum : décider à la majorité

Le scénario le plus redouté dans un cluster est le split-brain. Le réseau se coupe en deux. Chaque moitié croit l'autre morte, et prend des décisions contradictoires sur les mêmes ressources.

Par exemple, chacune démarre la même VM sur le même disque partagé. Deux systèmes écrivent alors en même temps sur le même disque : ses données sont corrompues, sans retour possible.

Le quorum est la protection contre ce scénario. Chaque nœud a une voix. Un groupe de nœuds n'a le droit d'agir que s'il réunit plus de la moitié des voix du cluster : la moitié, arrondie à l'entier inférieur, plus une.

Le groupe minoritaire, lui, se bloque de lui-même : /etc/pve passe en lecture seule, plus rien ne démarre. Mieux vaut un cluster figé et cohérent que deux moitiés qui divergent.

À deux nœuds, une coupure laisse deux groupes d'une voix chacun : aucun n'a la majorité, tout se fige. À trois, le groupe de deux voix continue, et le nœud isolé passe en lecture seule.

Combien de pannes un cluster supporte :

D'où la règle : un nombre impair de nœuds, et trois au minimum en production. Passer de 3 à 4 n'apporte aucune tolérance de plus.

Le cas particulier des deux nœuds. Proxmox écrit alors dans corosync.conf l'option two_node: 1, qui permet de fonctionner avec une voix sur deux.

Elle s'accompagne de wait_for_all: 1 : au démarrage, les deux nœuds doivent s'être vus au moins une fois avant que le quorum s'établisse. Le fichier du lab, à trois nœuds, n'en contient pas (§2.3).

Un cluster à deux nœuds reste fragile. La solution est un QDevice : un petit serveur extérieur, qui n'est pas un nœud Proxmox et n'héberge aucune VM, mais apporte une troisième voix.

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Ajouter un QDevice externe pour un cluster à 2 nœuds (non pratiqué : le lab a trois nœuds)
pvecm qdevice setup <IP-QDevice>

Avec un QDevice, pvecm status compte trois voix attendues pour deux nœuds : si l'un tombe, l'autre garde le quorum (sa voix plus celle du QDevice).

Les termes, un par un :

Un réseau dédié à Corosync

Corosync ne transporte pas les données des VM. Il transporte les battements de cœur : quelques octets, envoyés plusieurs fois par seconde par chaque nœud. C'est sur eux, et uniquement sur eux, que le cluster décide qui est vivant, donc qui a le quorum.

D'où une exigence contre-intuitive : Corosync a besoin d'une latence faible et régulière, pas de débit. Quelques kilo-octets par seconde lui suffisent.

Mais un battement en retard fait croire à la disparition d'un nœud. La documentation Proxmox demande moins de 5 ms entre les nœuds ; le lab mesure 0,5 ms (§1.2).

Or une sauvegarde ou une migration à chaud peut saturer le réseau d'administration pendant plusieurs minutes. Si Corosync partage ce réseau, ses battements prennent du retard. Le cluster croit un nœud mort, l'exclut, et la haute disponibilité redémarre ses VM ailleurs, alors qu'il fonctionnait.

C'est pourquoi on donne à Corosync son propre réseau. Dans cette formation, c'est le pont vmbr1, sur la carte ens19, préparé au chapitre 3. Le réseau d'administration, vmbr0, garde l'interface web, les migrations et les sauvegardes.

Pourquoi doubler le lien

Un réseau dédié peut tomber à son tour : un commutateur en panne, un câble arraché. Avec un seul lien, les nœuds ne se voient plus, et le cluster perd son quorum.

Depuis Proxmox VE 6, Corosync utilise le transport knet (Kronosnet). Il apporte deux choses :

• plusieurs liens entre les mêmes nœuds : Link 0, Link 1, jusqu'à huit. Un seul sert à la fois, celui de plus haute priorité ; si ses battements ne passent plus, Corosync bascule seul sur le suivant ;
• le chiffrement des échanges entre nœuds, activé par défaut (secauth: on).

Dans cette formation : Link 0 sur vmbr1, le réseau dédié, prioritaire ; Link 1 sur vmbr0, le réseau d'administration, en secours. Ce dernier n'est pas idéal en temps normal, mais il vaut mieux que rien quand le premier tombe.

Trois cas, de gauche à droite :

• ① Un seul réseau : la sauvegarde sature vmbr0, le battement du nœud 3 arrive en retard, et le nœud est exclu à tort.
• ② Un réseau dédié : les battements circulent seuls sur vmbr1, la sauvegarde ne les gêne plus.
• ③ Deux liens : vmbr1 tombe, Corosync bascule sur vmbr0, et le quorum tient.

Survolez chaque cas pour le détail.

Et une agrégation de cartes (bond) ? Doubler les cartes sous un même lien est une autre façon de se protéger. Si le réseau Corosync passe par un bond :

• le mode active-backup est sûr : une carte à la fois, l'autre en secours ;
• les modes qui répartissent la charge, dont LACP (802.3ad), peuvent créer une connectivité asymétrique quand une seule carte du bond faiblit : certains nœuds se voient encore, d'autres non ;
• avec LACP en réglage par défaut, la bascule peut prendre jusqu'à 90 secondes, plus que le délai au bout duquel la haute disponibilité isole un nœud. Des nœuds sains peuvent alors être redémarrés de force. On règle bond-lacp-rate fast des deux côtés, sur le nœud et sur le commutateur.

Les deux liens de knet restent la protection la plus simple : c'est celle du lab.

Ce qu'il faut avant d'assembler