Comment construire un cluster Proxmox avec des serveurs dédiés loués ?

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.

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.

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.

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, car le troisième ne se commande pas dans l'urgence. 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 plus lent que cette médiane : Jusqu'à 72 heures à partir du moment où votre paiement est confirmé.

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. Pour le CPU, voyez combien de cœurs un serveur nécessite. Tous les prix sont sur combien coûte un serveur Lumenfer.