Installer un hôte Proxmox VE prend moins d’une heure. C’est précisément le piège : la plateforme fonctionne très vite, et les décisions qui feront sa solidité sont souvent prises par défaut. Six mois plus tard, on découvre qu’une sauvegarde n’a jamais été restaurée, qu’un cluster de deux nœuds s’est figé pendant une maintenance, ou que les mises à jour n’ont pas été faites depuis l’installation.
Voici les points qui séparent une maquette qui marche d’une production qu’on peut exploiter sans crainte.
La sauvegarde : intégrée, à condition de la vérifier
Proxmox VE sauvegarde nativement machines virtuelles et conteneurs, vers un partage réseau ou vers Proxmox Backup Server, le serveur de sauvegarde du même éditeur. Ce dernier apporte ce qui compte vraiment en production : la déduplication, qui rend les sauvegardes quotidiennes peu coûteuses en espace, le chiffrement côté client, la synchronisation vers un second site et surtout la vérification des sauvegardes, qui relit les données stockées pour détecter une corruption.
Trois règles évitent l’essentiel des mauvaises surprises.
- Une sauvegarde n’existe que si elle a été restaurée. Planifiez une restauration de test, mensuelle par exemple, sur une machine choisie au hasard, et notez le temps qu’elle a pris.
- Gardez une copie hors du cluster. Un serveur de sauvegarde hébergé sur le cluster qu’il protège disparaît avec lui. La copie distante, ou hors ligne, est ce qui reste après un rançongiciel.
- Distinguez instantané, réplication et sauvegarde. Un instantané protège d’une mauvaise manipulation, la réplication ZFS d’une panne d’hôte, la sauvegarde d’une perte de données. Aucun des trois ne remplace les deux autres.
Le cluster : tout se joue sur le quorum
Un cluster Proxmox VE repose sur Corosync, qui exige une majorité de votes pour prendre une décision. Avec trois nœuds, la perte d’un seul laisse une majorité de deux : le cluster continue. Avec deux nœuds, la perte d’un seul laisse un vote sur deux : il n’y a plus de majorité, et le nœud restant refuse de démarrer ou de déplacer des machines pour éviter qu’elles tournent en double.
C’est la première question à régler. Soit on construit trois nœuds, soit on ajoute un arbitre externe (QDevice), qui peut être une petite machine hors du cluster et apporte le vote manquant.
Le réseau du cluster mérite le même soin. Corosync supporte mal la latence : un lien dédié, ou au minimum séparé du trafic de sauvegarde et de migration, évite que le cluster perde ses nœuds au moment où le réseau est le plus chargé.
La haute disponibilité : ce qu’elle fait, et ce qu’elle ne fait pas
Le gestionnaire de haute disponibilité redémarre automatiquement sur un autre nœud les machines d’un hôte tombé. Il le fait après un délai de sûreté, le temps de s’assurer que l’hôte est réellement hors service, puis de l’isoler. Ce n’est donc pas une bascule instantanée : c’est un redémarrage automatique, avec une interruption de quelques minutes.
Pour que ce redémarrage soit possible, les disques des machines doivent être accessibles depuis un autre nœud. Deux familles de solutions existent :
| Option | Principe | À savoir |
|---|---|---|
| Stockage partagé existant | NFS, iSCSI ou Fibre Channel, vu par tous les nœuds | Simple si la baie existe ; la baie devient le point unique de défaillance |
| Ceph sur les nœuds | Stockage distribué, répliqué entre au moins trois nœuds | Pas de baie à acheter ; exige un réseau rapide dédié et des disques homogènes |
| Réplication ZFS | Copie périodique des disques vers un autre nœud | Économique ; on accepte de perdre les écritures depuis la dernière réplication |
Le bon choix dépend d’une question métier avant d’être technique : combien de temps chaque service peut-il être interrompu, et combien de données peut-on accepter de perdre ? Une application comptable et un serveur de fichiers de travail n’appellent pas la même réponse.
Les mises à jour : sans interruption, si on s’y prend bien
Dans un cluster, les mises à jour se font nœud par nœud : on migre les machines à chaud vers les autres nœuds, on met à jour et on redémarre le nœud vidé, puis on recommence. Avec trois nœuds et un peu de marge en mémoire, aucune machine n’est arrêtée.
Cela suppose deux choses qu’on oublie souvent : garder assez de ressources libres pour absorber les machines d’un nœud entier, et suivre les notes de version avant chaque mise à jour majeure. Le passage d’une version majeure à la suivante a sa propre procédure, documentée par l’éditeur, et se répète d’abord sur la maquette.
La liste de contrôle avant de déclarer la production prête
- Trois nœuds, ou deux nœuds et un arbitre externe.
- Un réseau de cluster séparé du trafic de sauvegarde et de migration.
- Un stockage choisi au regard de l’interruption et de la perte de données acceptables, service par service.
- Des sauvegardes vérifiées, avec une copie hors du cluster.
- Une restauration de test réussie et chronométrée.
- Une perte d’hôte simulée sur maquette, pour voir de ses yeux ce que fait la haute disponibilité.
- Une supervision qui alerte sur l’espace disque, l’état du cluster et l’échec d’une sauvegarde.
- Une procédure de mise à jour écrite, testée et datée.