Proxmox VE — Cluster, haute disponibilité et backups

Pourquoi passer en cluster — le single point of failure

Un serveur Proxmox seul, c’est un SPOF (Single Point of Failure). Si le hardware lâche — alimentation, disque, carte mère — toute ton infrastructure s’arrête. Pas de migration, pas de failover, pas de maintenance sans downtime.

Le cluster Proxmox résout ce problème en fédérant plusieurs nœuds dans une entité logique unique. Tu gères l’ensemble depuis une seule interface, les VMs migrent entre nœuds sans interruption, et le système de haute disponibilité redémarre automatiquement les machines sur un nœud sain en cas de panne.

🔥 Cas réel : Une PME héberge son ERP, sa messagerie et son CRM sur un Proxmox unique. Le contrôleur RAID tombe un vendredi soir. Résultat : 3 jours de downtime, perte de données partielle, et un week-end entier de restauration. Avec un cluster de 3 nœuds et Ceph, le nœud défaillant aurait été isolé en 2 minutes, et les VMs auraient redémarré automatiquement sur les nœuds restants.

Ce cours couvre la mise en place d’un cluster, la haute disponibilité avec fencing, le stockage distribué Ceph, et les backups avec Proxmox Backup Server.

Créer et configurer un cluster

Prérequis et préparation réseau

Un cluster Proxmox nécessite au minimum 3 nœuds pour le quorum — le mécanisme de vote qui empêche le split-brain. Avec 2 nœuds, il faut ajouter un QDevice (un service tiers léger, même un Raspberry Pi suffit).

La préparation réseau est critique. Idéalement, deux réseaux séparés : un pour le management et le trafic VM, un dédié pour Corosync (la communication inter-nœuds). Configure /etc/hosts sur chaque nœud pour que la résolution de noms fonctionne sans DNS.

# /etc/hosts — sur chaque nœud
192.168.1.11  pve1.lab.local pve1
192.168.1.12  pve2.lab.local pve2
192.168.1.13  pve3.lab.local pve3

Initialisation et jonction

Le premier nœud crée le cluster, les autres le rejoignent :

# Sur pve1 — créer le cluster avec réseau Corosync dédié
pvecm create mon-cluster --link0 10.10.10.11 --link1 192.168.1.11

# Sur pve2 — rejoindre
pvecm add 192.168.1.11 --link0 10.10.10.12 --link1 192.168.1.12

# Sur pve3 — rejoindre
pvecm add 192.168.1.11 --link0 10.10.10.13 --link1 192.168.1.13

# Vérifier depuis n'importe quel nœud
pvecm status
pvecm nodes

Le résultat attendu montre Quorate: Yes et les 3 nœuds visibles. Si un nœud manque, vérifie la connectivité réseau et les ports Corosync (UDP 5405-5412).

💡 Tip DevOps : Le dual-link Corosync (--link0 et --link1) assure la redondance de communication. Si un réseau tombe, le cluster continue de fonctionner via l’autre. En production, c’est non-négociable.

Haute disponibilité — failover automatique

Le mécanisme HA

Le HA Proxmox repose sur quatre composants : Corosync détecte les pannes entre nœuds, le quorum vérifie qu’une majorité de nœuds est joignable, le fencing isole le nœud défaillant, et le HA Manager redémarre les VMs marquées HA sur un nœud sain.

Le workflow complet lors d’une panne :

1. Corosync détecte la perte d’un nœud (timeout ~6s)
2. Le quorum est vérifié — on a encore la majorité ?
3. Le fencing isole le nœud (reboot forcé via IPMI ou watchdog)
4. Les VMs HA sont redémarrées sur les nœuds restants
5. Temps total : 1-2 minutes

Configuration pratique

Crée un groupe HA qui définit où les VMs peuvent tourner, puis ajoute les VMs :

# Groupe HA avec priorités (plus élevé = préféré)
ha-manager groupadd prod-group --nodes pve1:2,pve2:1,pve3:1 --nofailback 0

# Ajouter des VMs au HA
ha-manager add vm:100 --group prod-group --state started --max_restart 3 --max_relocate 2
ha-manager add vm:101 --group prod-group --state started

# Vérifier l'état
ha-manager status

Le paramètre --nofailback 0 ramène la VM sur son nœud préféré quand il revient. En production, --nofailback 1 est souvent préférable pour éviter des migrations inutiles.

Le fencing — éviter le split-brain

Le fencing est le mécanisme qui force l’arrêt d’un nœud défaillant. Sans lui, un nœud “zombie” pourrait continuer à écrire sur les mêmes disques qu’un autre nœud — corruption de données garantie.

La méthode la plus simple est le watchdog (softdog) : si un nœud perd le quorum, il se reboot lui-même :

# Sur chaque nœud — activer le watchdog
echo "softdog" >> /etc/modules-load.d/softdog.conf
modprobe softdog
ls -la /dev/watchdog*

⚠️ Attention : Le softdog repose sur la capacité du nœud à se rebooter lui-même. Si le kernel est complètement planté, ça ne marchera pas. En production sérieuse, utilise IPMI/BMC ou un PDU intelligent qui coupe physiquement l’alimentation du serveur.

Ceph — le stockage distribué intégré

Pourquoi Ceph change tout

Ceph élimine le besoin d’un SAN ou NAS externe. Les disques de chaque nœud forment un pool de stockage distribué où chaque donnée est répliquée sur 2 ou 3 nœuds. Si un disque ou un nœud meurt, Ceph re-réplique automatiquement les données sur les nœuds restants.

C’est aussi ce qui rend la migration live possible : le stockage étant accessible depuis tous les nœuds, déplacer une VM ne nécessite pas de copier les disques.

Prérequis : minimum 3 nœuds, réseau dédié 10 Gbps (Ceph est gourmand en bande passante), disques dédiés (pas le disque système), et environ 2 Go de RAM par OSD.

Installation et configuration

# Sur chaque nœud — installer Ceph
pveceph install --repository no-subscription

# Sur pve1 — initialiser avec réseau dédié
pveceph init --network 10.10.20.0/24

# Créer les monitors (sur les 3 nœuds)
pveceph mon create    # exécuter sur chaque nœud

# Créer les managers (sur 2 nœuds pour la redondance)
pveceph mgr create    # sur pve1 et pve2

# Créer les OSDs — un par disque dédié, sur chaque nœud
pveceph osd create /dev/sdb
pveceph osd create /dev/sdc

Puis crée un pool pour les VMs :

# Pool avec triple réplication
pveceph pool create vm-pool --size 3 --min_size 2 --pg_autoscale_mode on

# Enregistrer dans Proxmox
pvesm add rbd ceph-vm --pool vm-pool --content images,rootdir

# Vérifier l'état
ceph status
ceph osd tree

Un HEALTH_OK avec tous les OSDs up et in signifie que tout fonctionne. Surveille régulièrement avec ceph health detail.

🧠 À retenir : Ceph avec size 3 et min_size 2 signifie que chaque donnée existe en 3 copies, et que le cluster continue d’accepter les écritures tant qu’au moins 2 copies sont disponibles. Tu peux perdre un nœud entier sans perte de données.

Proxmox Backup Server — la stratégie de sauvegarde

PBS en bref

Proxmox Backup Server est le complément essentiel de PVE. Il offre la déduplication au niveau bloc (seuls les blocs uniques sont stockés), la compression zstd, le chiffrement côté client, et des backups incrémentaux — seuls les blocs modifiés transitent sur le réseau.

Configuration et intégration

PBS s’installe sur un serveur séparé (même une VM suffit pour commencer). Une fois installé, connecte-le à ton cluster PVE :

# Sur PBS — créer un datastore avec rétention GFS
proxmox-backup-manager datastore create backups /mnt/backup-storage
proxmox-backup-manager datastore update backups \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --keep-yearly 2

# Sur PVE — ajouter PBS comme stockage
pvesm add pbs pbs-backup \
  --server 192.168.1.20 \
  --username backup@pbs \
  --password \
  --datastore backups \
  --content backup \
  --fingerprint XX:XX:XX...

Planification et restauration

Automatise les backups quotidiens et teste régulièrement les restaurations :

# Job de backup quotidien à 2h du matin
pvesh create /cluster/backup \
  --id daily-backup \
  --schedule "0 2 * * *" \
  --storage pbs-backup \
  --mode snapshot \
  --compress zstd \
  --all 1 --enabled 1

# Restaurer une VM
qmrestore pbs-backup:backup/vm/100/2026-03-21T02:00:00Z 100

# Restaurer vers un nouveau VMID (évite les conflits)
qmrestore pbs-backup:backup/vm/100/2026-03-21T02:00:00Z 150 --unique true

💡 Tip DevOps : Planifie une vérification hebdomadaire de l’intégrité des backups sur PBS (proxmox-backup-manager verify-job create). Un backup corrompu qu’on découvre le jour de la restauration, c’est comme pas de backup du tout.

La règle 3-2-1

La stratégie de sauvegarde minimale viable :

• 3 copies de chaque donnée (production + backup local + backup distant)
• 2 supports différents (disques Ceph + PBS sur des disques séparés)
• 1 copie hors-site (PBS distant synchronisé, ou export vers un cloud)

🔥 Cas réel : Un ransomware chiffre toutes les VMs d’un cluster Proxmox. Les snapshots locaux sont également chiffrés (même stockage). Mais le PBS distant, sur un site séparé avec accès restreint, est intact. Restauration complète en 4 heures au lieu de payer la rançon. La règle 3-2-1 a littéralement sauvé l’entreprise.

Bonnes pratiques et pièges à éviter

Migration live — Elle nécessite un stockage partagé (Ceph, NFS, iSCSI) ou la réplication ZFS. Le CPU type doit être compatible entre nœuds — x86-64-v2-AES est le meilleur compromis. Avec host, pas de migration possible.

Maintenance d’un nœud — Migre les VMs HA vers un autre nœud (ha-manager migrate), mets à jour (apt full-upgrade), reboot, vérifie le retour dans le cluster avec pvecm status.

Pièges classiques :

• Cluster à 2 nœuds sans QDevice → perte de quorum dès qu’un nœud tombe
• Ceph sur le même réseau que le management → saturation et latence
• Pas de fencing configuré → split-brain et corruption de données
• Backups sur le même stockage que les VMs → si le stockage meurt, tout est perdu
• Oublier de tester les restaurations → fausse sécurité

Checklist cluster production :

• ✅ 3+ nœuds (ou 2 + QDevice)
• ✅ Réseau Corosync dédié avec dual-link
• ✅ Fencing configuré (watchdog minimum, IPMI idéal)
• ✅ Ceph sur réseau 10G dédié
• ✅ PBS configuré avec rétention GFS
• ✅ Copie hors-site (règle 3-2-1)
• ✅ Restauration testée régulièrement

Résumé

Le cluster Proxmox transforme des serveurs indépendants en une plateforme unifiée et résiliente. Le quorum (3 nœuds minimum) protège contre le split-brain, et le dual-link Corosync assure la redondance de communication.

La haute disponibilité redémarre automatiquement les VMs sur un nœud sain en 1-2 minutes. Le fencing est non-négociable — sans lui, le HA est dangereux plutôt qu’utile.

Ceph intègre le stockage distribué directement dans le cluster : triple réplication, self-healing, et migration live sans SAN externe. C’est la fondation qui rend tout le reste possible.

PBS complète l’ensemble avec des backups incrémentaux, dédupliqués et vérifiables. Combiné avec la règle 3-2-1, tu as une stratégie de protection des données solide.

🧠 À retenir : Un cluster sans backup testé est un château de cartes. La résilience vient de la combinaison HA + Ceph + PBS + hors-site. Chaque couche couvre les failles de la précédente.