Infrastructure

Proxmox, penser le design du cluster avant de parler de production

Article orienté runbook sur le design d’un cluster Proxmox VE, le quorum, le stockage, le réseau, les sauvegardes et les vérifications minimales avant de présenter la plateforme comme une base de production.

20 avr. 2026 proxmoxvirtualisationclusterstoragenetworking

Installer Proxmox VE est simple. Présenter le résultat comme une plateforme de production demande beaucoup plus de discipline. L’interface rend la création de cluster rapide, mais le quorum, le stockage, le design réseau, les sauvegardes et la reprise décident si la plateforme restera stable après le premier incident.

L’objectif ici n’est pas de décrire un laboratoire à un seul nœud. Le but est de cadrer un petit cluster Proxmox VE crédible, capable de supporter une maintenance normale, un redémarrage de nœud et quelques erreurs opérateur prévisibles.

Périmètre utilisé dans les exemples

text 
Nœuds:        pve01, pve02, pve03
Management:   10.20.0.0/24
Trafic cluster: 10.21.0.0/24
Trafic VM:    bridges adossés à des VLAN
Stockage:     stockage partagé ou modèle local assumé
Sauvegardes:  Proxmox Backup Server ou cible maîtrisée équivalente

Trois nœuds constituent la base raisonnable quand le quorum compte réellement. Proxmox s’appuie sur Corosync pour la communication de cluster et le quorum fait partie du design, pas d’un confort optionnel. La documentation Proxmox le rappelle clairement.

Commencer par des contrôles d’hôte

Avant de créer le cluster, vérifier que chaque nœud est suffisamment sain pour éviter d’attribuer au cluster un problème d’hôte.

bash 
hostnamectl
ip -br a
pveversion -v
pveperf
chronyc sources -v
lsblk
cat /etc/network/interfaces

pveperf n’est pas un gadget. Cette commande donne rapidement un signal sur la latence de stockage et le comportement CPU avant que les VM commencent à concurrencer les ressources.

Construire proprement le premier nœud

Créer d’abord le cluster sur un seul nœud.

bash 
CLUSTER_NAME="pve-prod-01"
CLUSTER_IP="10.21.0.11"

pvecm create $CLUSTER_NAME --bindnet0_addr $CLUSTER_IP

Puis contrôler l’état du cluster et la vue Corosync.

bash 
pvecm status
corosync-cfgtool -s
journalctl -u corosync --no-pager -n 50

Si ces vérifications sont déjà instables sur le premier nœud, il faut s’arrêter là. Ajouter d’autres nœuds ne fera que masquer le problème un temps.

Joindre les deuxième et troisième nœuds

Sur chaque nœud supplémentaire, utiliser l’IP cluster du premier nœud.

bash 
pvecm add 10.21.0.11

Valider après chaque ajout, au lieu de tout enchaîner d’un seul bloc.

bash 
pvecm nodes
pvecm status
journalctl -u corosync --no-pager -n 100

Séparer management, trafic cluster et trafic invité quand c’est pertinent

Un réseau plat peut convenir à un lab. Sous charge, il devient beaucoup plus difficile à raisonner, notamment pendant la réplication, les sauvegardes et la reprise d’un nœud. La documentation Proxmox évoque explicitement les réseaux de cluster séparés et la redondance.

Exemple d’hôte minimal.

ini /etc/network/interfaces 
auto lo
iface lo inet loopback

auto eno1
iface eno1 inet manual

auto eno2
iface eno2 inet manual

auto vmbr0
iface vmbr0 inet static
  address 10.20.0.11/24
  gateway 10.20.0.1
  bridge-ports eno1
  bridge-stp off
  bridge-fd 0

auto vmbr1
iface vmbr1 inet static
  address 10.21.0.11/24
  bridge-ports eno2
  bridge-stp off
  bridge-fd 0
  mtu 9000

Ce n’est pas le seul design valable, mais il est bien plus facile à diagnostiquer qu’un empilement de flux sur une seule interface.

Choisir le modèle de stockage avant de créer des VM importantes

C’est ici que beaucoup de clusters deviennent trompeurs.

Un cluster Proxmox ne fournit pas magiquement du stockage partagé. Il faut choisir un modèle explicite.

Stockage partagé pour mobilité et HA.

Ou bien stockage local avec limites opérationnelles pleinement assumées.

Inventaire rapide.

bash 
pvesm status
cat /etc/pve/storage.cfg

Si le choix est du stockage local uniquement, il faut le dire clairement. Les attentes sur la migration à chaud, la HA et la reprise ne seront pas les mêmes qu’avec un stockage partagé.

Exemple pour une cible NFS.

ini /etc/pve/storage.cfg 
dir: local
  path /var/lib/vz
  content iso,vztmpl,backup

nfs: nfs-prod-01
  export /srv/pve
  path /mnt/pve/nfs-prod-01
  server 10.20.30.50
  content images,iso,backup,vztmpl
  options vers=4.1

Les sauvegardes font partie de la plateforme

Un cluster sans chemin de sauvegarde et de restauration explicite reste un laboratoire. Proxmox documente séparément la sauvegarde et la restauration parce que c’est un sujet d’exploitation central.

Exemple de planification simple.

bash 
pvesh create /cluster/backup --storage pbs-prod-01 --mode snapshot --compress zstd --node pve01 --schedule 'mon..sat 23:00' --all 1

La validation compte autant que la planification.

bash 
pvesh get /cluster/backup
vzdump --dumpdir /tmp/vzdump-test --mode snapshot 101
qmrestore /tmp/vzdump-test/vzdump-qemu-101-*.vma.zst 901 --storage nfs-prod-01 --unique 1

Si une restauration n’a jamais été testée, la sauvegarde reste une hypothèse.

La haute disponibilité n’est pas une case à cocher

Il ne faut pas présenter le cluster comme hautement disponible simplement parce que le panneau HA existe. La HA suppose un quorum cohérent, des choix de stockage adaptés au redémarrage ou à la relocalisation, et une bonne compréhension des dépendances de service. La documentation Proxmox sépare clairement HA, réplication de stockage et design de cluster.

Contrôles utiles avant d’activer la HA sur une VM.

bash 
ha-manager status
pvesh get /cluster/resources --type vm
pvecm status
pvesm status

Les schémas d’échec qui apparaissent vite en vrai

Cluster à deux nœuds présenté comme plateforme de production

Deux nœuds peuvent fonctionner dans des cas très contraints, mais le quorum et la maintenance deviennent plus délicats.

Capacité de stockage supposée parce que le cluster existe

L’appartenance au cluster ne transforme pas des disques locaux en stockage partagé.

Réseau unique pour tout le monde

Quand management, communication cluster, réplication et trafic invité partagent le même chemin, le diagnostic devient beaucoup plus coûteux sous contrainte.

Cible de sauvegarde joignable mais restauration jamais testée

C’est un classique de la virtualisation.

Attentes de migration avec stockage local

Le stockage local n’est pas mauvais en soi. Il devient problématique seulement quand le modèle opérationnel prétend qu’il se comporte comme du stockage partagé.

Runbook de validation avant de parler de production

bash 
pveversion -v
pvecm status
pvecm nodes
corosync-cfgtool -s
pvesm status
ha-manager status
pvesh get /nodes
pvesh get /cluster/resources
pvesh get /cluster/backup
journalctl -u corosync --no-pager -n 100
journalctl -u pvedaemon --no-pager -n 100

Ensuite, il faut tester ce que l’on évite souvent.

Migration à chaud ou comportement équivalent attendu.

Redémarrage contrôlé d’un nœud.

Restauration dans un identifiant de VM de test.

Fenêtre de sauvegarde pendant un trafic normal.

Règles de design utiles à conserver

Trois nœuds forment la base raisonnable quand le quorum compte réellement.

Le modèle de stockage doit être explicite avant de parler des attentes de service.

Sauvegardes et tests de restauration doivent faire partie de la construction de plateforme.

La séparation réseau n’est pas obligatoire partout, mais l’ambiguïté coûte cher.

Si la plateforme est en réalité un lab, il vaut mieux l’assumer. Le design devient plus honnête et les attentes plus réalistes.

Références