Cluster Proxmox de trois nœuds, exploité comme en production

• nas : Core i5-13500, quatre disques de 6 To en RAIDZ1. Stockage, sauvegardes et pare-feu de secours. Il fonctionne avec 16 Go de RAM au lieu de 32, en attendant le retour d'une barrette en garantie.
• ms01 : Core i5-12600H, 32 Go, NVMe. Pare-feu principal, authentification et plan de contrôle Kubernetes.
• llm : Core i5-13600KF, 32 Go, RTX 3090 en passthrough vers une machine virtuelle. Inférence locale. Je l'allume à la demande pour limiter la consommation électrique.

Il faut trois nœuds pour garder le quorum quand l'un d'eux tombe. Quand llm est éteint, il ne reste que deux voix. J'ai prévu d'ajouter un QDevice sur le VPS pour corriger ce point.

Voir les trois hyperviseurs et leurs 21 machines

Adressage. Le VMID d'une machine correspond à son adresse IP : la machine 2040 est en 10.0.20.40 (VLAN 20, hôte 40). Je n'ai pas d'inventaire séparé à tenir à jour.

Réseau de stockage. La réplication, le NFS et le second anneau corosync passent par un VLAN dédié en 10 Gb/s. Ce VLAN n'a pas de passerelle, il est donc inaccessible depuis les autres réseaux.

Réplication. Les machines de nas et de ms01 sont sur du ZFS local et répliquées vers l'autre nœud toutes les 15 minutes (17 tâches).

Pare-feu. Deux OPNsense en CARP, un sur chaque nœud, avec 12 adresses virtuelles partagées. Je n'ai pas encore testé la bascule en conditions réelles.

Un nœud se figeait régulièrement, sans log ni alerte. J'ai testé une par une la température, l'alimentation, les disques et le processeur.

La cause était une barrette de RAM défectueuse. Le test mémoire affichait zéro erreur parce que la barrette n'était pas détectée au démarrage. C'est le code sonore du POST qui m'a mis sur la piste. La barrette est partie en garantie.

En attendant son retour, le nœud tourne avec la moitié de sa RAM, et le noyau a déjà arrêté une machine virtuelle par manque de mémoire.

• Proxmox Backup Server sauvegarde toutes les machines chaque nuit sur un miroir de disques dédié, puis synchronise vers un NAS situé sur un autre site.
• Au relevé du 1er octobre 2026, les 18 machines concernées avaient leur sauvegarde de la veille dans les deux copies. La copie distante occupe 1,9 To.
• L'ordre des tâches est fixe : sauvegarde, synchronisation, purge, puis nettoyage. Dans l'ordre inverse, la purge supprimerait des blocs que la copie distante n'a pas encore reçus.
• Un script vérifie chaque jour que la sauvegarde de la veille existe dans les deux copies. Il m'envoie un e-mail si ce n'est pas le cas.

J'ai audité toute l'installation le 1er octobre 2026. Deux points sont à corriger sur ce projet.

• Le pool NVMe de ms01 n'est plus en miroir. La réplication et la sauvegarde quotidienne limitent le risque, mais je dois reconstruire le miroir.
• Les deux copies de sauvegarde sont gérées par le même serveur. Il manque une copie hors de sa portée et un test de restauration complet.