# Comment construire un cluster Proxmox avec des serveurs dédiés loués ? > Comment construire un cluster Proxmox avec des serveurs dédiés : 3 nœuds dans une même ville, corosync sous 5 ms, réplication ZFS. | Lumenfer - URL: https://lumenfer.com/fr/proxmox-cluster-dedicated-servers/ - Dernière mise à jour: 2026-11-01 - Éditeur: Lumenfer (https://lumenfer.com) Quorum, corosync sur IP publiques, stockage adapté à un port partagé, et adresses des invités qui changent quand une VM se déplace : un cluster Proxmox VE à trois nœuds sur des machines Lumenfer louées. **Réponse rapide — Comment construire un cluster Proxmox avec des serveurs dédiés loués ?** Pour construire un cluster Proxmox avec des serveurs dédiés loués chez **Lumenfer**, commandez trois machines identiques dans une même ville avec l'image Proxmox VE 9. Ouvrez les ports UDP 5405-5412 de corosync entre leurs IP publiques uniquement, vérifiez que la latence reste sous 5 ms, puis exécutez `pvecm create` et `pvecm add`. Avec un seul port partagé par serveur, utilisez la réplication ZFS plutôt que Ceph. À partir de 109,37 $US par nœud pour 30 jours, sans KYC, payable en crypto. ## Un cluster Proxmox sur Lumenfer : les chiffres qui comptent | Attribut | Valeur | | --- | --- | | Version actuelle de Proxmox VE | 9.2 (roadmap Proxmox, consultée le 1er novembre 2026) ; l'image au paiement est Proxmox VE 9 | | Nœuds pour la haute disponibilité | Trois, ou deux plus un vote QDevice externe | | Ports corosync | UDP 5405-5412 entre tous les nœuds, plus SSH sur TCP 22 | | Latence requise par corosync | Sous 5 ms entre tous les nœuds | | Port et trafic, plus petit et plus grand plan | 30 TB par mois à 1 Gbit/s; 150 TB par mois à 1 Gbit/s | | Réseau privé entre serveurs | Non inclus dans les plans : le trafic du cluster utilise les adresses publiques | | Disques | Les offres à deux disques sont livrées avec le système d'exploitation sur un miroir RAID 1 logiciel ; demandez au support avant la livraison si vous préférez un RAID 0 ou deux disques séparés | | Console | Il n'y a pas de console IPMI ni KVM-over-IP pour les clients : vous demandez les redémarrages et les réinstallations dans le tableau de bord et l'équipe les exécute | | Emplacements | Amsterdam (Pays-Bas), Reykjavik (Islande), Zurich (Suisse) et Bucarest (Roumanie) : les cinq plans dans les quatre villes, un seul prix partout | ## De combien de serveurs un cluster Proxmox a-t-il besoin ? **Trois, si vous voulez la haute disponibilité.** Proxmox donne à chaque nœud une voix, et les changements nécessitent une majorité de voix en ligne. Un cluster qui perd le quorum passe en lecture seule. Avec deux nœuds, la perte de l'un ou de l'autre fait perdre la majorité. Un QDevice ajoute une voix depuis une machine externe, et Proxmox en recommande un pour les clusters à deux nœuds. Il communique avec le cluster via TCP et n'est pas soumis à la limite de latence de corosync. N'importe quelle machine Debian disposant du paquet `corosync-qnetd` peut l'héberger. Proxmox déconseille un QDevice sur les clusters à nombre impair de nœuds, où il devient proche d'un point de défaillance unique. ### Voix et défaillances, selon la taille du cluster | Cluster | Votes | Votes requises pour le quorum | Nœuds pouvant échouer | | --- | --- | --- | --- | | 2 nœuds | 2 | 2 | Aucune | | 2 nœuds + QDevice | 3 | 2 | Un nœud, ou le QDevice | | 3 nœuds | 3 | 2 | Un | | 4 nœuds | 4 | 3 | Un | | 5 nœuds | 5 | 3 | Deux | ## Quel réseau corosync faut-il entre des serveurs loués ? **Latence faible et régulière : Proxmox exige moins de 5 ms entre tous les nœuds.** Corosync a besoin de peu de bande passante mais réagit mal à la gigue. Au-delà de trois nœuds et autour de 10 ms, Proxmox juge un cluster stable improbable. Il veut corosync sur son propre réseau physique, et jamais sur un réseau partagé avec le stockage. Un serveur Lumenfer a un seul port réseau et uniquement des adresses publiques. Cela dicte la conception : - **Une ville par cluster.** Nos villes sont séparées par un WAN, pas par un LAN. Construisez chaque cluster à l'intérieur d'une seule d'entre elles. - **Mesurez avant de rejoindre.** Proxmox suggère de tester la liaison avec ping. Lancez-le plusieurs minutes et lisez les pires temps, pas la moyenne. - **Contenez le trafic de masse.** Fixez des limites de bande passante sur les tâches de migration et de réplication, pour qu'elles n'affament pas corosync. - **Firewall vers les seules adresses des pairs.** Autorisez UDP 5405-5412 et TCP 22 et 8006 depuis les autres nœuds. Avec le firewall Proxmox activé, il écrit lui-même les règles corosync. Corosync 3 passe par Kronosnet en UDP unicast. Proxmox prévient que les transports hérités udp ou udpu désactivent toute la cryptographie et la redondance : gardez la valeur par défaut. ## Comment créer le cluster, étape par étape ? D'après le chapitre Cluster Manager de la documentation Proxmox VE (consultée le 1er novembre 2026). Chaque nœud tourne avec l'image Proxmox VE 9. 1. **Commandez trois nœuds sur un même plan, dans une même ville** — Choisissez l'image Proxmox VE 9 pour chacun. Un même plan signifie des CPU identiques, ce qui simplifie la migration à chaud. 2. **Donnez à chaque nœud son nom définitif** — Définissez chaque hostname avant que le cluster existe. Ajoutez les trois noms et les IP publiques dans /etc/hosts sur chaque nœud. 3. **Vérifiez l'heure et la latence** — Les horloges doivent être synchronisées : timedatectl doit indiquer synchronized. Ensuite, faites un ping sur chaque pair pendant plusieurs minutes et gardez le pire résultat sous 5 ms. 4. **Ouvrez les ports du cluster aux seuls pairs** — Autorisez UDP 5405-5412 et TCP 22 et 8006 entre les trois IP publiques, et rien de plus large. 5. **Créez le cluster sur le nœud 1** — Lancez pvecm create avec l'IP publique du nœud 1 comme link 0. Utilisez un nom de cluster que personne d'autre n'utilise sur ce réseau. 6. **Définissez un mot de passe root sur le nœud 1** — pvecm add se connecte à l'API du nœud 1 en root@pam avec un mot de passe et vérifie l'empreinte de son certificat. La connexion SSH par mot de passe peut rester désactivée. 7. **Rejoignez les nœuds 2 et 3** — Sur chacun, lancez pvecm add avec l'IP du nœud 1 et sa propre IP comme link 0. pvecm status doit alors afficher trois votes et Quorate: Yes. *Créer et rejoindre le cluster (Proxmox VE 9)* ```bash # node 1 pvecm create lf-cluster --link0 NODE1_IP passwd # root@pam password, asked for by pvecm add # node 2 (then node 3 with its own address) pvecm add NODE1_IP --link0 NODE2_IP # any node pvecm status # expect 3 votes and "Quorate: Yes" ping -c 300 -i 0.2 NODE2_IP | tail -2 # watch the max and mdev values ``` ## Faut-il faire tourner Ceph sur des serveurs loués ? **Pas sur ces ports.** Le chapitre Ceph de Proxmox demande au moins trois serveurs, de préférence identiques. Il recommande au moins 10 Gbps dédiés uniquement à Ceph, et 25 Gbps ou plus pour les disques NVMe. Il prévient que le trafic de récupération sur un réseau partagé peut perturber corosync et coûter le quorum. Comparez avec un nœud Lumenfer : 60 TB par mois à 1 Gbit/s sur un port partagé, et deux disques. Proxmox recommande aussi au moins 12 OSD sur trois nœuds, avec 8 GiB de mémoire par OSD. **Ceph sur un seul port partagé sous 10 Gbps passe à côté de la recommandation de Proxmox avant même d'avoir stocké un octet.** Si vous avez besoin de Ceph, louez chez un hébergeur qui vend un réseau privé de 10 Gbps ou plus. **Utilisez plutôt la réplication de stockage ZFS.** Elle copie les disques de chaque invité vers un autre nœud selon un calendrier, d'une fois par minute à une fois par semaine. Après la première copie complète, seules les modifications circulent. La haute disponibilité fonctionne avec elle, mais les écritures depuis la dernière synchro sont perdues quand un nœud tombe. La réplication nécessite un stockage ZFS local sur chaque nœud. Les offres à deux disques sont livrées avec le système d'exploitation sur un miroir RAID 1 logiciel ; demandez au support avant la livraison si vous préférez un RAID 0 ou deux disques séparés. Demandez au support, avant la livraison, quelle disposition utilisera l'image Proxmox VE. ZFS vérifie les données par somme de contrôle, et la mémoire ECC les protège avant qu'elles n'atteignent le disque : voyez [si vous avez besoin de RAM ECC](https://lumenfer.com/fr/ecc-ram-dedicated-server/ "Do I need ECC RAM on a rented dedicated server?"). ## Qu'arrive-t-il aux adresses des invités quand une VM se déplace entre nœuds ? **Chaque nœud a sa propre IPv4 publique : un invité derrière NAT change donc d'adresse publique quand il se déplace.** Pointez le DNS vers le nœud qui l'exécute, ou lancez un reverse proxy sur chaque nœud. Une adresse IPv4 dédiée et un IPv6 /64 sont fournis avec chaque serveur. Chaque offre indique sa vitesse de port et son trafic mensuel, compté sur les données sortantes par 30 jours ; tout dépassement ne déclenche jamais de facturation automatique. Les adresses IPv4 supplémentaires ne sont pas vendues. Pour un réseau privé entre invités sur des nœuds différents, créez une zone SDN VXLAN entre les hôtes. VXLAN utilise UDP 4789 et n'a pas de chiffrement propre : faites-le passer par WireGuard entre les nœuds. Réglez les invités sur un MTU de 1450, car VXLAN prend 50 octets. La migration à chaud copie la mémoire d'un invité sur le réseau. Proxmox recommande fortement le type de migration sécurisé sur tout réseau que vous ne contrôlez pas entièrement, et ces liaisons traversent des adresses publiques. ## Quels plans Lumenfer conviennent à un cluster Proxmox ? **Achetez les trois nœuds en même temps et sur la même offre, pour avoir le quorum dès la première heure.** Parmi les hébergeurs de l'enquête Lumenfer sur 30 October 2026 qui indiquent un délai de livraison, la promesse médiane était de 24 heures. La fourchette allait de 30 minutes à 10 jours ouvrés. Lumenfer est bien plus rapide que cette médiane : chaque nœud tourne quelques minutes après le paiement, une heure au plus. Dimensionnez chaque nœud pour prendre en charge les invités d'un pair défaillant. Pour le choix des disques, lisez [combien de fois le NVMe est plus rapide qu'un SSD SATA](https://lumenfer.com/fr/nvme-vs-sata-ssd-dedicated-server/ "How much faster is NVMe than SATA SSD in dedicated server hosting?"). Pour le CPU, voyez [combien de cœurs un serveur nécessite](https://lumenfer.com/fr/how-many-cores-dedicated-server/ "How many CPU cores do I need on a rented dedicated server?"). Tous les prix sont sur [combien coûte un serveur Lumenfer](https://lumenfer.com/fr/pricing/ "Lumenfer bare-metal plans and prices per 30 days"). ### Plans Lumenfer comme nœuds Proxmox | Offre | CPU | RAM | Disques | Par nœud, 30 jours | Par nœud, 12 mois | Rôle | | --- | --- | --- | --- | --- | --- | --- | | Lumen 6 | AMD EPYC 4244P | 32 GB DDR5 ECC | 2 × 960 GB NVMe | $91.65 | $769.86 | Cible de sauvegarde ou hôte QDevice | | Lumen 8 | AMD Ryzen 7 9700X | 64 GB DDR5 | 2 × 1 TB NVMe | $109.37 | $918.70 | Cluster de démarrage à trois nœuds | | Lumen 16 | AMD Ryzen 9 9950X | 128 GB DDR5 | 2 × 1,92 TB NVMe | $205.27 | $1724.26 | Charges de travail VM mixtes | | Lumen 24 | AMD EPYC 9254 | 256 GB DDR5 ECC | 2 × 1,92 TB NVMe | $356.25 | $2992.50 | ZFS avec ECC, invités plus grands | | Lumen 32 | AMD EPYC 9354 | 384 GB DDR5 ECC | 2 × 3,84 TB NVMe | $749.67 | $6297.22 | Hôtes denses, nombreuses VM | ## Clusters Proxmox sur serveurs loués : FAQ ### Puis-je créer un cluster Proxmox à deux nœuds ? Oui, avec un QDevice. Deux nœuds ont deux votes, et la perte de l'un ou l'autre fait perdre le quorum. Un QDevice sur une troisième machine ajoute la voix décisive via TCP, même depuis une autre ville. ### Un cluster Proxmox peut-il couvrir deux de vos villes ? Pas de manière fiable. Corosync exige moins de 5 ms entre tous les nœuds, soit des performances de LAN. Créez un cluster par ville et déplacez les données entre villes via des sauvegardes. ### Puis-je mélanger les offres dans un même cluster ? Oui. Proxmox prend en charge la migration à chaud entre processeurs d'un même fabricant, et toutes les offres ici sont en AMD. Un invité avec le type de CPU `host` ne doit toutefois migrer qu'entre processeurs identiques. ### Est-ce que Lumenfer sauvegarde mon cluster ? Les sauvegardes ne sont pas incluses : conservez des copies de vos données ailleurs. Envoyez des jobs `vzdump` ou un datastore Proxmox Backup Server vers une machine hors du cluster, idéalement dans une autre ville. ### Que se passe-t-il si un nœud tombe en panne ? Les deux autres conservent le quorum, et les invités en haute disponibilité redémarrent dessus si leurs disques étaient répliqués. Signalez la panne dans le tableau de bord. Une nouvelle machine n'est pas instantanée : Quelques minutes après la confirmation du paiement, et jamais plus d'une heure. **Commandez les trois nœuds de votre cluster** Proxmox VE 9 au paiement, trois machines dans une même ville. Sans KYC, payer en crypto. [Commander Lumen 16](https://lumenfer.com/app/checkout/?plan=lumen-16&lang=fr) · [Comparer les offres](https://lumenfer.com/fr/pricing/ "Combien coûte un serveur bare-metal Lumenfer ?") ## Sources 1. [Cluster Manager (prérequis, réseau, QDevice, migration)](https://pve.proxmox.com/pve-docs/chapter-pvecm.html) — Proxmox VE documentation (read 2026-11-01) 2. [Deploy Hyper-Converged Ceph Cluster (recommendations)](https://pve.proxmox.com/pve-docs/chapter-pveceph.html) — Proxmox VE documentation (read 2026-11-01) 3. [Storage Replication](https://pve.proxmox.com/pve-docs/chapter-pvesr.html) — Proxmox VE documentation (read 2026-11-01) 4. [Software-Defined Network (zones VXLAN, WireGuard)](https://pve.proxmox.com/pve-docs/chapter-pvesdn.html) — Proxmox VE documentation (read 2026-11-01) 5. [Roadmap (Proxmox VE 9.2)](https://pve.proxmox.com/wiki/Roadmap) — Proxmox VE wiki (read 2026-11-01) --- Lumenfer: Lumenfer loue des serveurs bare-metal de génération actuelle à Amsterdam, Reykjavik, Zurich et Bucarest, payés en crypto sans KYC : pas de pièce d'identité, pas de selfie, pas de documents. Chaque machine dispose d'un CPU lancé en 2022 ou plus récent, de mémoire DDR5 et de disques NVMe, et est louée entière à un seul client avec accès root. Elle est exploitée par DomaineGoat LLC, une société panaméenne qui ignore les notifications DMCA, ne répond que devant la loi panaméenne, autorise les relais de sortie Tor et ne conserve aucun journal. Sur l'engagement de 30 jours, chaque offre est facturée au moins 25 % sous un serveur de génération actuelle équivalent nommé, parmi 13 hébergeurs crypto sans KYC, relevés le 30 octobre 2026.