Un incident d’exploitation Proxmox, c’est une panne provoquée par la manière dont on a installé ou opéré le cluster, pas par un défaut du produit. Sur les dossiers qu’on m’appelle à démêler, c’est la quasi-totalité. Voici les huit configurations qui reviennent.
Les incidents Proxmox en production viennent presque tous de l’exploitation, pas du produit : quorum à deux nœuds, sauvegardes jamais restaurées, réseau de cluster partagé avec les VM, MTU incohérente et mises à jour lancées sans filet en sont les pièges récurrents.
Les huit pièges
1. Le cluster à deux nœuds sans QDevice. Vous perdez un nœud, le quorum s’effondre, le survivant bascule en lecture seule et plus aucune VM ne démarre. C’est mécanique. Trois nœuds, ou deux plus un QDevice : même un petit Raspberry Pi posé dans un coin fait l’affaire pour départager.
2. La sauvegarde jamais restaurée. PBS tourne, les jobs passent au vert chaque nuit, les points de restauration s’empilent depuis des mois. Mais personne n’a jamais cliqué sur « restore ». Le jour où il le faut, on découvre que le datastore était corrompu, ou que la VM remonte sans sa base. Une sauvegarde jamais rejouée ne protège de rien : restaurez pour de vrai, au moins une fois par trimestre, vers un emplacement de test.
3. Le réseau de cluster partagé avec les VM. Le trafic des machines sature le lien, corosync n’a plus assez de marge pour ses battements de cœur, et le cluster croit qu’un nœud est mort alors qu’il se porte très bien. Un client industriel a enchaîné les migrations HA fantômes pendant des semaines pour cette seule raison : une sauvegarde nocturne qui noyait corosync. Donnez-lui son propre lien, ou au minimum une priorité réseau dédiée.
4. La MTU incohérente. 9000 côté serveurs, 1500 sur un switch oublié au milieu. Ça ne plante pas franchement, et c’est bien le problème : des lenteurs, des transferts qui pendouillent, des pertes que rien ne signale. Vérifiez la MTU de bout en bout, et testez-la pour de bon avec un ping qui interdit la fragmentation.
5. Les mises à jour lancées sans filet. Un apt upgrade en pleine journée, depuis le dépôt non stabilisé, sans snapshot ni fenêtre annoncée. Branchez le dépôt entreprise et planifiez la fenêtre.
6. La HA activée sans fencing. Sans mécanisme pour isoler le nœud défaillant, votre VM peut redémarrer en double, deux instances écrivant sur le même disque. La corruption est alors quasi garantie. Pas de HA tant que le fencing n’est pas validé par un test réel, watchdog compris (le minuteur matériel qui force le redémarrage d’un nœud qui ne répond plus de lui-même).
7. L’espace disque qu’on ne surveille pas. Un pool ZFS qui frôle les 100 %, un datastore PBS plein, et les sauvegardes commencent à échouer en silence pendant que les voyants restent au vert ailleurs. Posez une alerte qui sonne bien avant le mur, vers 80 %, pas à 99.
8. Aucun runbook. Le cluster fonctionne tant que la personne qui l’a monté est joignable. Elle part en congés, change de boîte, et plus personne ne sait dans quel ordre redémarrer quoi. Écrivez l’architecture et les procédures. Un document moche mais à jour vaut mieux que la mémoire d’une seule tête.
Ce qu’ils ont en commun
Relisez la liste : aucun de ces points n’accuse Proxmox. Ce sont des raccourcis d’exploitation, et chacun se paie au premier incident un peu sérieux. Une installation de production se reconnaît à ce qu’on l’a déjà malmenée volontairement, un nœud débranché pour voir, une restauration menée jusqu’au bout. Le réel finira par tester votre cluster ; autant passer devant lui.
Par où commencer, concrètement ? Bloquez deux heures cette semaine et débranchez physiquement un nœud, en dehors des horaires de prod. Vous saurez en une fois si votre quorum tient, si la HA réagit comme prévu et si vos VM survivent. Ce seul test fait remonter la moitié des pièges ci-dessus avant qu’un incident ne s’en charge.