Terraform + Proxmox Provider : Infrastructure as Code pour ton homelab
Après deux ans à créer des VMs et LXC à la main dans l'interface Proxmox,…
Estimated reading time: 11 minutes
Chaque fois que je redémarrais heighliner pour une mise à jour kernel ou un test de configuration, l’intégralité de mes services tombait avec lui. Nextcloud, Vaultwarden, Pi-hole – tout. Pour un homelab personnel, c’est acceptable jusqu’au moment où tu passes un week-end sans accès à tes mots de passe parce que tu as oublié de désactiver le redémarrage automatique après une mise à jour de Proxmox. C’est ce qui m’a décidé à passer à un cluster deux nœuds.
Ce n’est pas une solution triviale, et la documentation officielle Proxmox sur le sujet mérite d’être lue intégralement avant de toucher quoi que ce soit. Ce guide couvre ce que j’ai fait, dans quel ordre, et ce qui a coincé.
Matériel et contexte
Le premier nœud existant : un MS-01 équipé d’un i9-13900H (14 cœurs / 20 threads), 32 GB DDR5, 1 TB NVMe, sous Proxmox VE 8.3. Hostname : heighliner. C’est la machine principale, celle qui héberge le plus de VMs et de containers LXC.
Pour le second nœud, j’ai choisi le même barebone MS-01 mais en version i5-12600H. Coût : 439 € pour le barebone, auquel j’ai ajouté 32 GB DDR5 et un NVMe 1 TB. Total : aux alentours de 600 € selon les promos. Hostname : guildship, en accord avec la convention de nommage Dune du homelab. Le MS-01 est particulièrement adapté à ce type d’usage : format compact, deux ports 2.5GbE onboard, et surtout deux emplacements SFP+ qui vont servir pour le lien cluster dédié.
Le réseau existant repose sur un ZenWifi XT8 pour le Wi-Fi et un TP-Link TL-SG108-M2 pour le câblage 2.5GbE. Les VLANs sont déjà en place : Management (VLAN 1), LAN (VLAN 10), IoT (VLAN 20), Serveurs (VLAN 30), Stockage (VLAN 40). Le NAS est un Synology DS414.
Le problème du quorum à deux nœuds
Corosync, le composant qui gère la communication entre les nœuds d’un cluster Proxmox, nécessite que plus de la moitié des votes soient présents pour maintenir le quorum. Avec trois nœuds, la perte d’un nœud laisse deux votes sur trois – le cluster continue. Avec deux nœuds et un vote chacun, la perte d’un nœud laisse un vote sur deux : on n’atteint pas la majorité, et les deux nœuds peuvent se retrouver dans un état de split-brain où chacun pense être le seul survivant et tente de prendre le contrôle des VMs. Le résultat est potentiellement catastrophique pour les données.
La solution standard pour un cluster à deux nœuds est un QDevice : un troisième participant léger qui ne porte pas de charge Proxmox mais fournit un vote supplémentaire au quorum. Avec deux nœuds + un QDevice, on a trois votes. La perte d’un nœud laisse deux votes – le quorum est maintenu.
Pour le QDevice, j’ai utilisé un LXC minimal (CT 113) tournant sur le Synology DS414 via le support Container Station. Un Raspberry Pi fait aussi très bien l’affaire. Ce qui compte, c’est que la machine soit indépendante des deux nœuds Proxmox et reste disponible même quand l’un d’eux tombe.
Architecture réseau du cluster
Avant de créer le cluster, il faut décider sur quelle interface Corosync va communiquer. Faire transiter le trafic cluster sur l’interface réseau principale (celle qui porte les VMs et les clients) n’est pas recommandé : en cas de forte charge réseau, les heartbeats Corosync peuvent être retardés et déclencher des faux positifs de nœud mort.
J’ai câblé un lien direct entre les deux MS-01 via SFP+. Un câble DAC (Direct Attach Copper) 10GbE SFP+ de 1 mètre, moins de 10 €. Ce lien ne passe pas par le switch – c’est un lien point à point dédié au trafic cluster et stockage. J’ai attribué des adresses statiques sur le VLAN Stockage (VLAN 40, sous-réseau 10.10.40.0/24) :
heighliner:10.10.40.10surenp2s0(l’interface SFP+)guildship:10.10.40.11surenp2s0
La configuration se fait dans /etc/network/interfaces sur chaque nœud. Sur heighliner :
auto enp2s0
iface enp2s0 inet static
address 10.10.40.10/24
Tester la connectivité entre les deux nœuds sur cette interface avant de continuer.
Création du cluster
Depuis heighliner (et uniquement depuis lui – on crée le cluster sur le nœud existant, pas sur le nouveau) :
pvecm create homelab-cluster
Proxmox demande des options de ring. Pour Corosync avec un lien cluster dédié, on configure le ring0 sur l’IP du lien dédié. Si tu as un seul lien, c’est suffisant :
pvecm create homelab-cluster --link0 10.10.40.10
Vérifier l’état du cluster :
pvecm status
À ce stade, le cluster existe avec un seul nœud. L’interface web de heighliner (port 8006) montre désormais la vue Datacenter avec un seul membre.
Ajout du second nœud
Depuis guildship, après avoir vérifié que heighliner est joignable sur son IP de management et sur l’IP du lien cluster :
pvecm add 10.10.1.10 --link0 10.10.40.11
Ici, 10.10.1.10 est l’IP de management de heighliner (réseau Serveurs, VLAN 30), et 10.10.40.11 est l’IP que guildship va utiliser pour Corosync sur le lien dédié.
La commande demande le mot de passe root de heighliner. Elle va :
Après quelques secondes, l’interface web de heighliner montre les deux nœuds. pvecm status affiche deux membres avec deux votes.
À ce stade, le cluster à deux nœuds sans QDevice est dans un état instable : la perte d’un nœud peut bloquer le cluster. Ne pas configurer le HA avant d’avoir installé le QDevice.
Installation du QDevice
Sur le LXC qui va jouer le rôle de QDevice (ici le CT 113 sur le Synology, Debian 12 minimal), installer corosync-qnetd :
apt update && apt install -y corosync-qnetd
systemctl enable corosync-qnetd
systemctl start corosync-qnetd
Depuis heighliner, configurer le QDevice en pointant vers l’IP du LXC (ici 10.10.1.113) :
pvecm qdevice setup 10.10.1.113
La commande installe corosync-qdevice sur les deux nœuds Proxmox, échange les certificats avec le daemon qnetd, et redémarre Corosync. Vérifier ensuite :
pvecm status
La sortie doit maintenant montrer trois votes : 1 pour heighliner, 1 pour guildship, 1 pour le QDevice. Le quorum nécessite 2 votes. Si un nœud Proxmox tombe, le QDevice et l’autre nœud maintiennent le quorum – le cluster continue.
Si pvecm qdevice setup échoue avec une erreur de certificat, vérifier que les ports 5403 (corosync-qnetd) et 5404-5405 (corosync) sont ouverts entre les nœuds et le QDevice.
Stockage partagé : NFS depuis le Synology
La migration live de VMs entre nœuds nécessite que le stockage soit accessible depuis les deux nœuds simultanément. Sans stockage partagé, les VMs ne peuvent être migrées qu’à froid (arrêt, transfert des fichiers, redémarrage), ce qui annule l’intérêt du HA.
Trois options principales :
J’ai choisi NFS pour commencer. Ce n’est pas la solution la plus performante – le DS414 avec ses disques SATA est le goulot d’étranglement évident – mais c’est celle que j’avais déjà configurée et qui fonctionnait.
Sur le Synology, créer un dossier partagé proxmox-shared et activer le service NFS en autorisant les adresses IP des deux nœuds (10.10.1.10 et 10.10.1.11) avec les droits lecture/écriture, sans squash root.
Dans l’interface Proxmox, Datacenter > Storage > Add > NFS :
nas-shared10.10.1.50 (IP du Synology sur le réseau Serveurs)/volume1/proxmox-sharedDisk image, ContainerVérifier depuis les deux nœuds que le montage NFS fonctionne :
pvesm status
Le datastore nas-shared doit apparaître comme disponible depuis heighliner et guildship.
Le DS414 avec des disques SATA 5400 RPM n’est pas fait pour héberger des VMs actives en production. Pour le homelab, c’est acceptable pour les VMs non critiques. Pour les VMs qui doivent survivre à un failover rapidement, préférer iSCSI ou, mieux, migrer les images sur des NVMe locaux avec réplication PBS.
Configuration du HA
Dans Proxmox, le HA se configure en deux étapes : créer un groupe HA, puis ajouter les VMs à protéger.
Datacenter > HA > Groups > Add :
homelab-haheighliner:2,guildship:1 (la priorité détermine où les VMs sont placées en priorité)La priorité plus élevée sur heighliner (l’i9) signifie que les VMs y seront placées en priorité. guildship est le nœud de secours.
Ensuite, ajouter les VMs critiques au HA. Datacenter > HA > Resources > Add :
homelab-haNe pas activer le HA sur toutes les VMs. Les VMs de développement, les environnements de test, les LXC jetables – laisse-les sans HA. Le daemon pve-ha-lrm (Local Resource Manager) a une surcharge non négligeable si il doit surveiller des dizaines de ressources.
Le problème des extensions CPU
C’est là que j’ai perdu une heure. La migration live entre deux nœuds nécessite que le CPU présenté à la VM soit compatible entre la source et la destination. Par défaut, Proxmox configure les VMs avec le type CPU host – ce qui expose toutes les instructions du CPU physique directement à la VM.
Or un i9-13900H et un i5-12600H n’ont pas exactement les mêmes extensions CPU disponibles. La migration live d’une VM configurée en host depuis heighliner (i9) vers guildship (i5) échoue avec une erreur de type :
migration failed: Can't migrate VM with PCIe passthrough or CPU type host
La solution est de configurer les VMs en mode CPU kvm64 – un profil générique x86-64 compatible avec tous les hôtes Intel et AMD de génération récente. Ce profil ne pas l’intégralité des instructions avancées, mais en homelab la différence de performance est imperceptible sur des charges applicatives standard (Nextcloud, Vaultwarden, des services web).
Pour changer le type CPU d’une VM, soit via l’interface (VM > Hardware > Processors > Type), soit en éditant directement le fichier de configuration :
nano /etc/pve/qemu-server/100.conf
Changer la ligne cpu: de host à kvm64 :
cpu: kvm64
Faire ça pour chaque VM qui doit supporter la migration live. Les VMs doivent être redémarrées pour que le changement prenne effet.
Test de failover
Avant de valider le cluster comme opérationnel, il faut tester. Pas en production, pas avec des données importantes, mais avec les VMs configurées en HA.
La procédure de test : éteindre heighliner physiquement (bouton power), observer ce qui se passe sur guildship et l’interface Proxmox.
Résultat mesuré :
heighliner s’éteintguildship commence le processus de failoverguildship90 secondes de downtime effectif pour des services web. C’est acceptable pour un homelab. En environnement de production réel, on viserait moins de 30s avec du stockage local répliqué en temps réel.
Les métriques sont visibles dans Grafana (via hubble.arewel.com) – Prometheus scrape les deux nœuds Proxmox via le pve_exporter. Les graphiques de CPU, RAM et disponibilité de chaque nœud permettent de confirmer que le basculement s’est bien produit au bon moment.
Pour rallumer heighliner et remettre les VMs à leur place d’origine, le HA le fait automatiquement une fois que le nœud revient en ligne, en respectant les priorités du groupe HA configuré. Le retour prend environ 2 minutes supplémentaires.
Ce que j’aurais fait différemment
Le stockage NFS sur le Synology DS414 est le maillon faible. Si le Synology tombe, les VMs hébergées sur nas-shared ne peuvent plus être démarrées, même si les deux nœuds Proxmox sont opérationnels. La prochaine étape est de migrer le stockage des VMs critiques sur des NVMe locaux avec une réplication Proxmox Backup Server entre les deux nœuds, et de réserver le Synology pour les backups et les données moins critiques.
L’autre point : j’aurais dû configurer le lien SFP+ en premier, avant même de créer le cluster. Reconfigurer l’interface Corosync après que le cluster est créé est possible mais implique de modifier /etc/pve/corosync.conf manuellement et de redémarrer Corosync sur les deux nœuds dans un ordre précis. Ce n’est pas une opération anodine.
La prochaine évolution naturelle serait un troisième nœud – ce qui élimine le besoin du QDevice et ouvre la possibilité de Ceph pour le stockage distribué. Mais à 600 € supplémentaires minimum, ça attendra.
slug: cluster-proxmox-deux-noeuds-haute-disponibilite-homelab
meta: Cluster Proxmox 2 nœuds avec HA : QDevice pour le quorum, NFS partagé sur Synology, failover testé à 90 secondes. Guide complet i9 + i5.
tags: proxmox, cluster, haute-disponibilite, corosync, qdevice, nfs, homelab
