Proxmox VE est un hyperviseur open source populaire, développé par une entreprise autrichienne, aux atouts nombreux. Parmi eux, la possibilité de regrouper et de gérer plusieurs machines au sein d'un cluster, afin de les faire travailler de concert. De quoi améliorer la disponibilité de vos services.

Nous avons déjà vu comment installer Proxmox VE sur un PC pour en faire un serveur capable de lancer des machines virtuelles (VM) ou des conteneurs LXC. Une solution parfaite pour les « Home Lab », mais aussi les petites et moyennes entreprises (PME) qui veulent gérer elles-mêmes leurs infrastructures et services. 

• Proxmox VE 7.0 : installation sur un serveur et création d'une machine virtuelle
• Linux Containers (LXC) dans Proxmox VE 7.0 : installez simplement des distributions et services
• Proxmox VE 7.0 : comment ajouter du stockage via NVMe/TCP

Mais dans ce dernier cas, il faut s'assurer que tout peut continuer de fonctionner même en cas de panne ou simplement distribuer des VM et conteneurs sur des machines offrant un niveau de performance différent selon les besoins. Pour cela, Proxmox VE propose la gestion de clusters, permettant de regrouper différents serveurs.

Vous pouvez ainsi établir des règles de déploiement ou disposer d'une redondance automatique. On vous explique.

Créer un cluster dans Proxmox VE

Pour créer un cluster, il faut disposer d'au moins deux machines sous Proxmox VE (dans une version similaire si possible) et qu'elles soient capables de se joindre à travers le réseau auquel elles sont connectées. L'idéal est d'en avoir au moins trois : si l'une tombe, les deux autres disposent d'un « quorum » suffisant pour décider quoi faire.

Autre choix qui pourra avoir son importance par la suite : le système de fichiers. En la matière, ZFS dispose d'avantages puisqu'il permet une réplication efficace, pensez donc à l'utiliser (en RAID 0 si vous n'avez qu'un unique HDD/SSD au sein de la machine). Cela se décide au moment de l'installation.

Dans notre cas, nous avons opté pour trois serveurs différents : notre HPE ProLiant DL365 Gen10 Plus v2 à base de deux EPYC 7713 (Gemini) accompagné d'un second basé sur un Xeon E2388G, 4x 8 Go de DDR4 et la carte mère MX33-BS0 de Gigabyte (Tiny). Le troisième était une machine plus classique, composée d'un Core de 12e génération (Core i9-12900k, Alder Lake) sur une ROG Maximum Z690 Hero et 2x16 Go de DDR5 avec une carte réseau à 10 Gb/s (Newbie). Un débit utilisé pour ces trois machines reliées à travers le switch S5860-20SQ de FS.com.

Dans les paramètres du Datacenter de l'interface de Proxmox VE, la section cluster permet d'en créer un. Pour cela il suffit de lui trouver un nom et de déclarer les liens réseau utilisés. Par défaut c'est celui par lequel la machine est accessible, mais on peut en choisir d'autres qui prendront le relais en cas de problème (failover) et définir des priorités. Lorsque tout est validé, le cluster apparait, vous pouvez alors demander à voir ses « Join Information ».

Elles prennent la forme d'une clé qui est une forme encodée de l'adresse IP du serveur et de son empreinte, utilisées pour la connexion. Dans l'interface des autres serveurs, on sélectionne Join Cluster et on peut simplement copier la clé pour remplir les champs automatiquement, ou le faire manuellement. Il faudra néanmoins connaitre le mot de passe administrateur (root) du serveur ayant initié le cluster pour finaliser la procédure.

Si tout s'est bien passé, après avoir rechargé la page (et une reconnexion), tous les serveurs (nœuds) apparaissent dans chaque interface, au sein de la section Datacenter du menu de gauche. On peut alors les gérer de manière unifiée., depuis l'un ou l'autre membre du cluster, sans distinction. La section Summary affichera également les ressources de manière globale : stockage, mémoire, CPU, VM et conteneurs des nœuds y sont additionnés.

Pour supprimer un membre du cluster, seule une procédure manuelle est proposée.

Migration « live »

Une fois le cluster créé, on peut déplacer une machine virtuelle ou un conteneur d'un serveur à l'autre, on parle alors de migration. Elle peut être faite pendant que le système invité est fonctionnel (online) ou éteint (offline). Le premier cas est celui utilisé par défaut, sous conditions : il faut qu'aucun périphérique physique du serveur ne soit lié à la machine (carte graphique, réseau, périphérique de stockage, etc.).

Si vos nœuds utilisent des processeurs différents, il est aussi déconseillé d'utiliser le paramètre « host » pour le type de vCPU, qui déclare l'architecture physique comme étant celle utilisée au sein de la VM. En effet, la migration ne prendra pas en compte cette transition d'architecture et cela pourra poser des problèmes en pratique.

La gestion de la réplication se fait nœud par nœud et ressource par ressource

Notez que si vous disposez d'un système de fichier ZFS, la fonctionnalité de réplication pourra être activée (voir ci-dessus), effectuant une copie de sauvegarde du périphérique de stockage virtuel sur un serveur secondaire de manière régulière (toutes les x minutes, jours, à des heures précises, etc.). De quoi accélérer la migration.

Dans la pratique, nous avons ainsi pu passer une machine virtuelle Debian de Gemini à Tiny en quelques secondes, pendant qu'un benchmark OpenSSL tournait en boucle, avec un downtime de 90 ms seulement, invisible pour l'utilisateur, si ce n'est pour le faible impact observé sur l'un des tests :

Haute disponibilité et règles de groupe

Pour profiter de la gestion en cluster et de la migration, deux serveurs suffisent. On peut également se limiter à ce nombre pour les bases de la haute disponibilité (HA) et des groupes, accessibles dans les paramètres du Datacenter.

Les groupes permettent d'établir des règles communes à plusieurs nœuds du cluster avec des niveaux de priorité (sous la forme d'un entier). Si ces derniers sont définis, une machine virtuelle créée sur un serveur ira en priorité sur celui ayant la plus haute priorité, sauf exception. Chaque élément ajouté à la gestion de la haute disponibilité est vu comme une ressource, dont l'état doit être maintenu : démarré, arrêté, ignoré ou désactivé.

On indique combien de fois une tentative de redémarrage ou de relocalisation (migration offline) peut être effectuée (1 par défaut). Dans les options du Datacenter on choisit la politique d'arrêt d'un nœud. En le passant sur Migrate par exemple, les ressources seront déplacées dans un autre nœud avant que l'arrêt ne soit effectif.

Cela permet d'assurer une continuité de service lorsqu'une maintenance est programmée.

Création d'un groupe et sélection des nœuds (à gauche), vue de la haute disponibilité (à droite)

Et en cas de panne ? C'est là qu'il faut passer au moins à trois nœuds, puisqu'il faut constamment un « quorum » minimum au sein du cluster pour effectuer des migrations. Si une machine d'un cluster de deux tombe, il n'est plus atteint. Si une tombe sur un cluster de trois, c'est le cas. Nous avons donc ajouté un troisième nœud à notre cluster.

Nous avons placé trois VM sur Tiny : une répliquée sur Gemini, l'autre sur Newbie, la troisième sans réplication. Lorsque nous avons éteint Tiny, au bout de quelques minutes les machines virtuelles qui y étaient présentes se sont relancées automatiquement là où elles étaient répliquées. Pour celle qui ne l'était pas, c'était forcément plus compliqué et nous avons parfois rencontré des problèmes. L'idéal est donc d'avoir une réplication sur un noeud.

Une fois le serveur initial de retour, les ressources qui y étaient présentes pourront y être replacées ou non, cela dépendra essentiellement des règles de priorités définies au sein du cluster.

L'équipe de Proxmox VE précise que les fonctionnalités de HA sont des outils dans la recherche d'une meilleure disponibilité des services, mais ne sont pas les seules à mettre en place. Outre la multiplication des nœuds, il faut disposer de pièces de rechange pour réparer rapidement en cas de panne, avoir des équipes pouvant constamment intervenir, assurer une redondance du stockage, exploiter des services résilients par eux-mêmes là aussi par des mécaniques de type multi-instances, etc... Ou se reposer sur des tiers qui s'en occuperont pour vous.

Après la panne, les VM ont lancées sur d'autres nœuds, celle non répliquée a posé problème