1. Constituer le cluster — Préparer les trois nœuds avant d'assembler

1.2 Préparer les trois nœuds avant d'assembler

Vous avez travaillé jusqu'ici sur un seul serveur. Les deux autres arrivent dans l'état où était le vôtre au début de la formation : dépôt réservé aux abonnés encore actif, aucune mise à jour appliquée, aucun second pont. Trois choses sont à faire sur chacun d'eux avant de construire quoi que ce soit.

1. Le dépôt et les mises à jour — sur les trois nœuds

Un cluster fait dialoguer en permanence les mêmes composants : Corosync, pmxcfs, les outils pve*. Si un nœud est resté en arrière, il peut refuser de rejoindre, ou pire, rejoindre et se comporter de travers sans que rien ne le signale. On aligne les versions d'abord, on assemble ensuite.

Sur chaque nœud, refaites exactement ce que vous avez fait au chapitre 1 :

1. le serveur → Repositories → sélectionner chacune des deux lignes enterprise.proxmox.com (dépôt PVE et dépôt Ceph) → Disable
2. Add → No-Subscription → valider
3. Updates → Refresh, puis Upgrade
4. redémarrer le nœud si le noyau a été mis à jour

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

# Équivalent en ligne de commande, dans Shell, sur chaque noeud
apt update                                            # la liste des paquets
apt full-upgrade -y                                   # la mise à jour

# La verification qui compte
pveversion

Résultat attendu : pveversion renvoie la même version sur les trois nœuds, et apt update ne renvoie plus d'erreur 401. Faites ce contrôle avant d'aller plus loin — c'est trente secondes qui vous en économisent trente.

2. Le pont vmbr1 — sur les trois nœuds

Le réseau Corosync monté au chapitre précédent n'existe que sur votre serveur. Il doit exister à l'identique sur les deux autres, chacun avec sa propre adresse :

Sur chaque nœud : Network → Create → Linux Bridge.

→ Create, puis Apply Configuration. Sans ce second clic, le pont est enregistré mais pas actif.

3. Vérifier que les trois se voient

C'est maintenant que ce test a un sens : les trois ponts existent, ils peuvent se parler.

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

# Depuis le premier nœud, vers les deux autres
ping -c 3 10.<site>.<N+10>.12
ping -c 3 10.<site>.<N+10>.13   # puis vers le troisième

Résultat attendu, sur le lab (de pxe211 vers 10.59.11.12 puis 10.59.11.13) : rtt min/avg/max/mdev = 0.394/0.575/0.727/0.137 ms et 0.393/0.535/0.679/0.116 ms — moins d'une milliseconde, comme Corosync l'attend.

1.3 Créer le cluster et y joindre les nœuds

La création d'un cluster suit toujours le même ordre. On initialise le cluster sur le nœud qui sera le premier membre, puis on ajoute les autres un par un.

Il est crucial de réaliser cette étape avant de créer des VMs ou des conteneurs. Rejoindre un cluster efface la configuration locale du nœud entrant, pour adopter celle du cluster.

Créer le cluster — via l'interface graphique :

L'onglet Datacenter → Cluster d'un nœud encore seul. La ligne Standalone node - no cluster defined est l'état de départ de tous vos serveurs.

Trois boutons seulement : Create Cluster pour fonder, Join Cluster pour rejoindre, et Join Information — grisé, parce qu'un nœud sans cluster n'a aucune information de jonction à donner. C'est cet écran qui dit si un nœud a bien rejoint ou non.

Datacenter → Cluster → Create Cluster

La fenêtre remplie sur pxe211 (lab). Deux champs, et le second est celui qui compte.

• Cluster Name : le nom du cluster, purement identifiant. Ici cluster-tp.
• Cluster Network — Link 0 : l'adresse par laquelle les nœuds vont se parler. Ici 10.59.11.11, l'adresse de vmbr1 sur le réseau dédié à Corosync, et non celle de l'interface d'administration.
• Link 1, ajouté par le bouton Add : 10.59.1.11, l'adresse de vmbr0, en secours. La phrase sous les champs le dit : « Multiple links are used as failover, lower numbers have higher priority ». Si le premier réseau tombe, les nœuds continuent de se voir par le second et le cluster ne perd pas son quorum.

La création du pont vmbr1 sur le deuxième nœud, pxe212 : rattaché à une carte réseau physique distincte (ens19), portant l'adresse Corosync du nœud (10.59.11.12/24) et commenté COROSYNC. C'est le réseau que le cluster utilise pour ses échanges, séparé de vmbr0 qui porte l'administration et le trafic des machines.

C'est ici que se concrétisent les deux choix du §1.1 : le réseau dédié (vmbr1) devient le Link 0, et le réseau d'administration (vmbr0) le Link 1, en secours.

Choisissez bien l'adresse de vmbr1, pas celle de vmbr0. La liste déroulante propose les deux : c'est le seul moment où ce choix se fait, et il conditionne tout le reste du fonctionnement du cluster.

Attendez la coche verte dans la fenêtre de tâche. Ensuite : Datacenter → Cluster → Join Information → bouton Copy Information — ce bloc sera collé sur chaque nœud entrant.

Joindre un nœud — sur le nœud entrant :

Ce que le nœud fondateur fournit aux autres, une fois le cluster créé :

• son adresse IP,
• son empreinte de certificat, qui garantit au nœud rejoignant qu'il parle bien au bon serveur,
• et le bloc encodé qui contient les deux, à copier d'un clic sur Copy Information.

Sur le lab, l'adresse IP de la fenêtre est 10.59.1.11 : celle de vmbr0 du fondateur. C'est par elle que les autres nœuds le joignent pour adhérer ; Corosync, lui, passera par vmbr1.

Datacenter → Cluster → Join Cluster

La fenêtre Cluster Join, sur le nœud qui rejoint (pxe212). La case Assisted join étant cochée, Proxmox extrait seul du bloc collé l'adresse du pair (10.59.1.11) et l'empreinte. Il vous demande le mot de passe root du nœud fondateur.

Les deux champs Link restent vides, en rouge. À droite, Proxmox rappelle l'adresse du pair sur chaque lien (peer's link address: 10.59.11.11, puis 10.59.1.11) : choisissez en face l'adresse de ce nœud sur le même réseau.

Collez le contenu de Join Information, saisissez le mot de passe root du nœud fondateur, cliquez Join.

Équivalent CLI :

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

# ===== Sur le nœud fondateur =====
# Nom : lettres, chiffres, tirets — 15 caractères au plus
# --link0 : l'adresse Corosync (vmbr1) ; --link1 : le secours (vmbr0)
pvecm create cluster-tp --link0 10.<site>.<N+10>.11 --link1 10.<site>.<N>.11
pvecm status   # vérifier : le cluster existe, quorum à 1 voix

Résultat attendu (pxe211, juste après la création, extrait) :

Cluster information
-------------------
Name:             cluster-tp
Config Version:   1
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Tue Oct  6 19:28:31 2026
Quorum provider:  corosync_votequorum
Nodes:            1
Node ID:          0x00000001
Ring ID:          1.5
Quorate:          Yes

Un nœud seul, une voix : le cluster est déjà Quorate. La configuration est à sa version 1.

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

# ===== Sur chaque nœud qui rejoint, l'un après l'autre =====
# jonction au fondateur, avec ses deux liens : pvecm demande le mot de passe root
# du fondateur, puis fait accepter l'empreinte de son certificat (yes)
pvecm add 10.<site>.<N>.11 --link0 address=10.<site>.<N+10>.13 --link1 address=10.<site>.<N>.13

Résultat attendu (jonction du troisième nœud, pxe213) ; le mot de passe tapé ne s'affiche pas :

Please enter superuser (root) password for '10.59.1.11':
Establishing API connection with host '10.59.1.11'
The authenticity of host '10.59.1.11' can't be established.
X509 SHA256 key fingerprint is …
Are you sure you want to continue connecting (yes/no)? yes
Login succeeded.
check cluster join API version
Request addition of this node
Join request OK, finishing setup locally
stopping pve-cluster service
backup old database to '/var/lib/pve-cluster/backup/config-1791307887.sql.gz'
waiting for quorum...OK
(re)generate node files
generate new node certificate
merge authorized SSH keys
generated new node certificate, restart pveproxy and pvedaemon services
successfully added node 'pxe213' to cluster.

Deux adresses, sur deux réseaux. pvecm add <adresse> vise le fondateur, sur son interface d'administration.

--link0 address= et --link1 address= sont celles du nœud qui rejoint. La jonction prend une dizaine de secondes : échange des clés SSH, nouveau certificat, attente du quorum.

• 📖 Documentation Proxmox — Cluster Manager
• 📖 Créer un cluster Proxmox VE pas à pas — Technonagib

1.4 Vérifier l'état du cluster

Une fois les trois nœuds joints, la vérification s'effectue depuis n'importe quel nœud. C'est en soi le premier contrôle : un cluster sain donne la même réponse quel que soit le nœud interrogé. Deux nœuds qui décrivent différemment la composition du cluster est le symptôme d'une partition réseau.

(cluster cluster-tp du lab, Proxmox VE 9.2.21, juste après la jonction du troisième nœud). Datacenter → Summary résume l'état d'un coup d'œil. Le bloc Status indique le nom du cluster et Quorate: Yes.

Le bloc Nodes compte les nœuds en ligne (3) et hors ligne (0). Le bloc Guests additionne les machines de tous les nœuds. La même information, avec le détail des votes, est donnée par pvecm status ci-dessous.

Trois lignes de la sortie de pvecm status méritent d'être lues avant toutes les autres, et il faut savoir laquelle regarder en premier :

Ce sont les grandeurs du §1.1 : trois voix attendues, un quorum de deux. Tant que Quorate vaut Yes, le cluster a le droit d'agir.

L'interface web rend les mêmes informations, sous Datacenter → Cluster. Voici la maquette d'exemple de cette formation, un cluster de trois nœuds réellement en fonctionnement :

Le cluster cluster-tp du lab vu depuis l'interface (Proxmox VE 9.2.21) — trois nœuds, une voix chacun.

Trois colonnes de ce tableau méritent d'être commentées, parce qu'elles renvoient directement à ce qui précède et à ce qui suit.

La colonne Votes vaut 1 pour chaque nœud : trois voix au total, quorum à deux. C'est la traduction visuelle de la majorité stricte.

Le champ Config Version compte les versions successives de la configuration du cluster. Il vaut 3 ici : la création, puis deux jonctions. Chaque adhésion produit une nouvelle version de la configuration.

Et surtout, les colonnes Link 0 et Link 1 montrent deux adresses par nœud. 10.59.11.1x sur le réseau dédié du cluster (vmbr1, Link 0, prioritaire). 10.59.1.1x sur le réseau de gestion (vmbr0, Link 1, secours).

C'est exactement la redondance de liens Corosync présentée au §1.1. Sur vos nœuds, remplacez 59 par votre site et 1 par votre numéro.

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

# Vue d'ensemble du cluster (quorum, membres, transport)
pvecm status

# Liste des nœuds avec leur ID et leur état
pvecm nodes

# Inspecter la configuration Corosync générée automatiquement
cat /etc/pve/corosync.conf

Résultat sur pxe211, trois nœuds joints (extrait de pvecm status) :

Cluster information
-------------------
Name:             cluster-tp
Config Version:   3

Quorum information
------------------
Nodes:            3
Quorate:          Yes

Membership information
----------------------
    Nodeid      Votes Name
0x00000001          1 10.59.11.11 (local)
0x00000002          1 10.59.11.12
0x00000003          1 10.59.11.13

La section Membership affiche l'adresse du Link 0, pas le nom du nœud : c'est la preuve que Corosync passe par vmbr1. Pour les noms, pvecm nodes.

À retenir : un cluster s'assemble sur des nœuds prêts : même version, réseau de cluster (vmbr1) en place, ping croisé qui passe, aucune VM sur les nœuds qui rejoignent. On le crée sur un premier nœud (pvecm create), puis chaque autre le rejoint (pvecm add). pvecm status doit donner la même réponse sur tous les nœuds.