Créer un cluster Proxmox à haute disponibilité sur serveurs dédiés

D'abord la réponse : ce que ça demande, ce que ça apporte

Les exigences, selon la documentation même de Proxmox et sans se bercer d'illusions :

• Trois nœuds minimum pour un quorum fiable. (Un cluster à deux nœuds fonctionne avec une QDevice externe comme arbitre, détails plus bas, mais trois est là où la conception veut vraiment être.)
• Un réseau fiable à faible latence entre les nœuds, sous 5 ms, avec le trafic du cluster idéalement sur sa propre carte réseau. C'est une exigence de même site, de LAN privé, pas quelque chose à étirer entre régions.
• Un stockage que les nœuds survivants peuvent atteindre : Ceph hyperconvergent, réplication ZFS par invité, ou stockage partagé externe.

Ce que ça apporte, dit tout aussi platement : quand un nœud meurt, la HA redémarre ses invités sur les nœuds survivants, automatiquement, en quelques minutes. C'est de la reprise après panne sans intervention humaine, extrêmement précieuse, mais ce n'est pas de la tolérance aux pannes sans interruption : les invités redémarrent. La migration à chaud (pour les déplacements planifiés) est la variante invisible ; le failover est un redémarrage.

Si votre besoin réel est de « récupérer des pannes en une journée ouvrée », une bonne pratique de sauvegarde et restauration sur un seul hôte solide demande moins de machinerie. Le clustering justifie sa complexité quand les minutes comptent, ou quand vous exploitez assez d'invités pour que la gestion centralisée et la migration à chaud se rentabilisent au quotidien.

Le clustering avant la HA : déjà utile en soi

Une confusion courante : cluster ≠ HA. Regrouper des nœuds en cluster (pvecm) vous donne, sans la moindre configuration HA : une seule interface web pour gérer chaque nœud, la migration à chaud des VM entre nœuds (maintenance matérielle sans interruption), la configuration réseau SDN et pare-feu à l'échelle du cluster, et une gestion partagée des tâches et des droits. De nombreux clusters de production s'en tiennent exactement là (des humains décident quand les invités déménagent) et n'ajoutent la HA que plus tard, sélectivement, par invité, pour les services qui justifient un failover automatisé.

Quorum : pourquoi trois nœuds

Le problème que résout le quorum, c'est le split-brain. Si les liaisons du cluster tombent et que les nœuds ne se voient plus, chaque côté doit décider : « suis-je le cluster, maintenant ? » Si les deux côtés répondent oui, tous deux démarrent les mêmes VM sur le même stockage partagé, et vous découvrez à quoi ressemblent des images disque corrompues. La règle qui empêche cela : seul un groupe détenant la majorité des voix peut agir. Avec trois nœuds, toute partition a un côté majoritaire (2) et un côté minoritaire (1) qui se fige ; avec deux nœuds, une liaison rompue rend les deux côtés minoritaires : aucun ne peut agir, et la disponibilité est alors pire qu'avec un seul nœud.

D'où les deux formes admises : trois nœuds ou plus, ou deux nœuds plus une QDevice, un minuscule daemon témoin corosync sur une troisième machine quelconque (un VPS ou un petit serveur suffit ; il n'exécute aucun invité, il ne fait que voter). Ce qui n'est jamais admis, c'est la solution de contournement que les forums suggèrent à minuit : régler manuellement le nombre de voix attendues sur 1 pour forcer l'activation d'un nœud partitionné. C'est exactement ce genre de bascule qui transforme le split-brain en expérience personnelle.

Le réseau corosync : la latence fait loi

Corosync, la couche de membership et de messagerie du cluster, est le composant dont les exigences sont les moins négociables et les plus souvent violées :

• Une latence sous 5 ms entre tous les nœuds. C'est de la physique LAN : même site, réseau privé. Des nœuds dans des villes différentes ne forment pas un cluster ; ce sont deux clusters et une stratégie de réplication.
• La bande passante est sans importance ; la contention est fatale. Corosync n'a besoin que de quelques kilobits, mais dès qu'il partage une liaison avec des jobs de sauvegarde, du trafic de stockage ou une migration de VM et que cette liaison sature, les paquets de membership arrivent en retard, des nœuds sont déclarés morts, et la HA se met à « récupérer » des invités qui allaient très bien. La recommandation officielle, à suivre au pied de la lettre : une carte réseau dédiée (1 Gbit suffit largement) pour le trafic du cluster, et jusqu'à huit liaisons corosync redondantes si vous avez des chemins disponibles. Au minimum, une seconde liaison sur un autre réseau en secours.
• Le trafic de stockage (Ceph en particulier) veut lui aussi sa propre voie ; voir plus bas.

Sur nos serveurs dédiés, cela se traduit directement : le réseau privé entre vos machines transporte corosync (et le stockage) sur des interfaces qui n'entrent jamais en concurrence avec le trafic public.

Stockage : la vraie décision d'architecture

Le principe de la HA est que les disques d'un invité survivent au nœud sur lequel il tournait. Trois façons d'y arriver :

Ceph : hyperconvergent, la réponse complète

Proxmox intègre Ceph nativement : chaque nœud fournit des disques (OSD), Ceph réplique les données entre les nœuds (3 copies par défaut), chaque nœud voit tout le stockage, et perdre un nœud ne fait rien perdre du tout. Autoréparateur, sans SAN externe, il monte en charge en ajoutant des nœuds. C'est le cluster hyperconvergent canonique, et les exigences officielles sont honnêtes sur son appétit : trois serveurs ou plus, de préférence identiques, un réseau dédié à 10 Gbit/s+ exclusivement pour Ceph (25 Gbit/s+ dès que le NVMe entre en jeu : un seul NVMe moderne peut saturer 10 Gbit/s à lui seul), des disques sur des HBA, pas des contrôleurs RAID (Ceph gère lui-même la redondance ; une couche RAID en dessous nuit activement), grosso modo un thread CPU par service Ceph et ~8 GiB de RAM par OSD pour le confort. Budgétez ces ressources comme une surcharge d'infrastructure sur chaque nœud, en plus du dimensionnement des invités.

Réplication ZFS : le compromis pragmatique

Là où les exigences de Ceph dépassent le budget, pvesr réplique les volumes des invités entre nœuds selon un calendrier (aussi serré que chaque minute) via le réseau de migration, du ZFS vers du ZFS. Le failover redémarre alors l'invité à partir de sa réplique, avec une réserve que Ceph n'a pas : une fenêtre explicite de perte de données. Tout ce qui a changé depuis la dernière synchronisation (jusqu'à une minute, ou selon votre calendrier) est perdu. Pour beaucoup de charges de travail, cet échange est excellent : aucune complexité de stockage partagé, la vitesse du NVMe local pour chaque invité, une redondance par invité plutôt qu'à l'échelle du cluster. Nécessite un stockage d'invité reposant sur ZFS aux deux extrémités.

Stockage partagé externe

Du NFS ou de l'iSCSI accessible par tous les nœuds satisfait aussi la HA, le plus simple sur le plan conceptuel, et cela déplace le problème : cette baie de stockage est désormais le point unique de défaillance que votre cluster ne couvre pas. Sensé quand il s'agit d'un système de stockage réellement résilient ; une fausse économie quand il s'agit d'un seul serveur NFS dans la même baie.

À quoi ressemble réellement un failover

Le mécanisme mérite d'être démystifié, car « le cluster s'en occupe » cache un comportement assez corsé. Chaque nœud qui exécute des invités HA arme un watchdog, un dispositif homme mort (watchdog matériel là où il est configuré, sinon le softdog du kernel). Quand un nœud perd son quorum, il cesse de nourrir le watchdog, et après le délai (~60 secondes), le nœud s'applique le fencing à lui-même : il redémarre, ce qui garantit que ses invités sont vraiment morts et leurs disques libérés. La majorité en quorum attend la fin de cette fenêtre, puis redémarre les invités HA du nœud fencé depuis le stockage partagé ou répliqué.

Interruption totale ressentie pour un invité : fenêtre de watchdog + ordonnancement + démarrage de l'invité, typiquement quelques minutes. La configuration se fait par invité (Datacenter → HA) : marquez les invités qui le méritent, des règles de groupe et d'affinité orientent où ils atterrissent (PVE 9 a ajouté de vraies règles d'affinité de ressources, et l'ordonnanceur de charge dynamique de la 9.2 peut équilibrer selon l'usage en temps réel). Deux remarques opérationnelles qui évitent les incidents auto-infligés : utilisez le mode maintenance (et le désarmement HA à l'échelle du cluster de la 9.2) avant tout redémarrage délibéré, pour que la mécanique du watchdog ne « récupère » pas un nœud que vous êtes en train de patcher ; et sachez que le fencing est aussi la raison pour laquelle on ne simule jamais un quorum sur un nœud partitionné : le watchdog est la dernière ligne empêchant deux copies de votre base de données d'écrire sur un seul disque.

Quand ne pas clusteriser

• Deux nœuds, aucune troisième voix nulle part. Ajoutez une QDevice (une petite VM quelconque ailleurs) ou restez sans cluster : un cluster à deux nœuds sans QDevice échoue plus mal que des nœuds indépendants.
• Des nœuds séparés par une latence réelle. >5 ms signifie non. La résilience multisite se résout avec des sites indépendants plus de la réplication et des sauvegardes, pas avec un cluster étiré.
• Quand l'exigence honnête est « restauré d'ici demain ». Un seul hôte bien sauvegardé avec un reprovisionnement en moins d'une minute derrière lui demande bien moins d'exploitation, et la restauration à chaud de PBS réduit encore l'écart.
• Un matériel dépareillé pour Ceph. Des nœuds très différents rendent Ceph malheureux (le disque le plus lent impose le rythme) ; la réplication ZFS tolère bien mieux l'asymétrie.

Questions fréquentes

Puis-je créer un cluster à deux nœuds ?

Oui, avec la QDevice comme troisième voix obligatoire : corosync-qnetd sur n'importe quelle machine allumée en permanence en dehors de la paire (une petite instance cloud est le choix classique ; elle n'exécute aucun invité et ne demande presque aucune ressource). Avec elle, l'un ou l'autre nœud peut tomber, et le survivant conserve le quorum et exécute la récupération HA. Sans elle, ne le faites pas : la moindre panne de liaison ou de nœud gèle tout le cluster, ce qui est strictement pire que deux hôtes indépendants.

La HA me donne-t-elle un failover sans interruption ?

Non. Et comprendre pourquoi permet d'avoir les bonnes attentes. Un failover non planifié suit le schéma fencing puis redémarrage : les invités du nœud tombé redémarrent à neuf sur les survivants après la fenêtre du watchdog, donc prévoyez quelques minutes d'interruption et concevez les applications pour qu'elles se rétablissent proprement après un arrêt brutal (ce qu'elles devraient de toute façon savoir faire). Ce qui est sans interruption, c'est le déplacement planifié : la migration à chaud vide un nœud avant une maintenance pendant que les invités continuent de tourner. La HA gère les imprévus ; la migration à chaud gère le calendrier.

Mes nœuds peuvent-ils se trouver dans des datacenters différents ?

Des racks ou des salles différents au sein d'un même site avec une connectivité privée sous 5 ms : oui, et c'est même une bonne hygiène de domaine de panne. Des villes différentes : non. La membership corosync et (pire) la réplication Ceph synchrone deviennent toutes deux instables avec la latence WAN. Le schéma multirégion consiste en des clusters indépendants par site, avec réplication asynchrone et synchronisation des sauvegardes entre eux, et un failover qui devient un acte délibéré plutôt qu'automatique.

Tous les nœuds doivent-ils avoir un matériel identique ?

Pour le cluster lui-même, non. Des nœuds mixtes se regroupent sans problème, et la migration à chaud entre générations de CPU différentes fonctionne avec un type de CPU de référence commun défini sur les invités (le coût : les invités ne peuvent pas utiliser les instructions plus récentes). Pour Ceph, un matériel quasi identique est fortement recommandé : la capacité et la performance s'équilibrent entre les OSD, et un nœud lent ralentit tout le pool. Schéma pragmatique pour les parcs mixtes : regroupez-les tous pour la gestion, exécutez Ceph (ou des paires de réplication) sur le sous-ensemble assorti, et épinglez-y les invités HA.

Déploiement chez Serverside

Le cluster que décrit cet article se traduit par une commande concrète : trois serveurs dédiés assortis (Proxmox préinstallé, NVMe sur HBA pour Ceph ou ZFS pour la réplication) reliés via notre réseau privé pour le trafic corosync et de stockage (votre bande passante publique ne voit jamais le bavardage du cluster), chacun avec du KVM-over-IP pour le jour où un nœud a besoin d'une intervention hors bande. Le provisionnement prend moins d'une minute sur l'ASN 55285, ce qui rend même le schéma QDevice trivial : n'importe quelle petite troisième machine fait l'affaire.

Progressez-y avec la série : mise en place, réseau, LXC contre VM, et sauvegardes, dont vous aurez toujours besoin ; un cluster réplique vos erreurs avec une excellente disponibilité.