Comment construire un cluster Proxmox

01

Geler le périmètre et les prérequis

Sélectionnez une version Proxmox VE actuellement prise en charge dans le guide d'administration officiel et lisez ses exigences spécifiques à la version avant l'installation. Préparez des noms d'hôte uniques, des adresses de gestion stables, la synchronisation de l'heure, l'accès administratif, des sauvegardes vérifiées et un chemin de récupération indépendant. Enregistrez les budgets de ressources du nœud et des invités afin que les services de gestion, le stockage et les travaux de récupération ne soient pas alloués ailleurs.

Préférez des nœuds pouvant communiquer sur un chemin stable de type LAN. Proxmox documente un cluster basé sur quorum et exige une livraison Corosync fiable avec une latence inférieure à 5 millisecondes pour un fonctionnement stable. Cela rend un cluster étiré sur des régions publiques distantes une conception différente et généralement inadaptée, sauf si vous pouvez démontrer que son réseau répond aux exigences officielles. Aucun tissu inter-région privé n'est impliqué par une annonce de serveur public.

• Proxmox VE Guide d'administration ↗

02

Concevez le quorum avant de joindre les nœuds

Notez les votes et chaque partition que vous prévoyez de faire survivre. Un cluster à trois nœuds est le point de départ simple car la majorité peut rester après la perte d'un nœud votant. Une conception à deux nœuds ne devient pas sûre par un basculement souhaité ; Proxmox documente QDevice comme un moyen de fournir un vote supplémentaire, et ce votant externe introduit ses propres exigences de portée et de placement.

Le quorum protège l'état cohérent du cluster, pas la disponibilité des applications en soi. Décidez comment les invités sont redémarrés, quel stockage leurs disques nécessitent et ce qui se passe lorsqu'un nœud est isolé mais toujours en cours d'exécution. Évitez de modifier les votes attendus pour forcer une partition à être accessible en écriture comme réponse de routine.

03

Planifiez honnêtement le trafic Corosync et de charge de travail

Séparez la gestion des listes, Corosync, la migration, le stockage, la sauvegarde et le trafic public des invités, puis mappez chacun aux interfaces fournies et aux adresses routées. Des chemins physiques dédiés ou une séparation VLAN peuvent réduire les interférences, mais une commande Tungsto ne garantit pas un VLAN privé ni un lien de cluster supplémentaire. Confirmez toute fonctionnalité réseau requise avant de commander ; sinon, concevez dans les limites des interfaces et du routage public réellement fournis.

Corosync valorise une latence stable et une livraison ordonnée fiable plus que la bande passante nominale. La migration, la réplication et la sauvegarde peuvent créer des flux beaucoup plus importants, alors planifiez-les et mesurez-les sans affamer la communication du cluster. Appliquez les pare-feu hôtes à partir des exigences de port officielles et limitez l'exposition de la gestion ; ne copiez pas un ensemble de règles d'une version non liée.

04

Choisissez le stockage en fonction du résultat de récupération promis

Le stockage local simplifie les domaines de défaillance mais ne rend pas un disque invité disponible sur un autre nœud. La réplication locale ZFS peut réduire le point de récupération, mais elle est asynchrone et peut perdre des modifications entre les réplications. Le stockage partagé peut rendre les mêmes volumes invités visibles pour plusieurs nœuds, tandis que le stockage distribué ajoute des exigences de capacité, de réseau et d'exploitation. Aucun de ces éléments ne supprime le besoin d'une sauvegarde séparée.

Définissez où vivent les images ISO, les disques invités et les sauvegardes, comment l'espace libre est surveillé et ce qui se passe lorsque le stockage se remplit. Proxmox avertit que les invités utilisant un stockage thin-provisioning plein peuvent recevoir des erreurs d'E/S. Conservez les supports de restauration et les identifiants en dehors du cluster que vous pourriez avoir à reconstruire.

05

Utilisez un plan d'acceptation et d'échec par étapes

Corrigez et vérifiez chaque nœud autonome avant de créer le premier cluster, puis joignez un nœud à la fois en utilisant le guide de la version sélectionnée. Après chaque modification, enregistrez l'appartenance, le quorum, l'état temporel, la visibilité du stockage et l'état des sauvegardes. Ajoutez un invité non productif seulement après que le plan de contrôle est sain.

Planifiez des exercices contrôlés pour un nœud indisponible, un chemin Corosync indisponible, le stockage indisponible et la restauration à partir de la sauvegarde. Définissez le résultat attendu et les conditions d'abandon avant chaque exercice ; n'exécutez pas de tests destructifs contre la seule copie d'une charge de travail. Les demandes d'alimentation matérielle et de réinstallation Tungsto peuvent être mises en file d'attente pour traitement par l'opérateur, elles ne sont donc pas un contrôleur HA géré ni un minuteur de récupération garanti. Le livrable final est un runbook possédé avec des résultats observés de votre déploiement, pas une promesse de disponibilité sans réserve.