XCP-ng: Evolution du Lab - Architecture et Introduction

Introduction

Cela fait déjà plus de deux ans que le séisme du rachat de VMware par Broadcom a fait trembler l’IT mondiale.

La position ultra dominante des produits de virtualisation de l’éditeur a profondément été remise en cause dans de nombreuses entreprises en raison de l’explosion tarifaire et des changements de licences associés.

Même si la crise s’est quelque peu calmée, la guerre des hyperviseurs se poursuit avec la montée en importance d’acteurs, non pas nouveaux (ou très peu), mais qui jouaient jusque-là sur des marchés différents ou adressaient à des communautés d’utilisateurs spécifiques.

Parmi ceux qui ont connu la plus grosse hype sur ces dernières années, on peut citer sans trop se tromper ProxMox. Robuste, reposant sur KVM et présent depuis 2008, Proxmox a explosé ces derniers temps avec une adoption en flèche et l’arrivée de nouveaux produits, comme la console Datacenter Manager.

ProxMox est clairement en train de s’installer comme l’alternative principale à VMware et son hyperviseur ESX.

Néanmoins, d’autres éditeurs tirent également leur épingle du jeu. Comme je n’aime pas toujours faire comme tout le monde, c’est vers l’un deux que je me suis dirigé voilà maintenant plus d’un an: la société française Vates et son produit XCP-ng basé sur l’hyperviseur Xen.

J’ai déjà eu l’occasion de présenter l’entreprise et sa gamme de produits. Je vous invite donc à lire l’article dédié pour en apprendre davantage.

J’ai démarré doucement avec leur écosystème en commençant par un petit cluster de deux nœuds, le tout sous management de XenOrchestra, leur « vCenter » like.

J’ai décrit également toute l’installation et la configuration de base dans ce même article.

Dans mon usage, je n’avais activé que très peu de fonctionnalité avancée et mes deux nodes, bien que présent dans un même pool, n’avaient aucun stockage commun et pas de fonctionnalité de HA activée pour se secourir l’un l’autre.

Il est maintenant temps pour moi d’aller plus loin et de passer à la vitesse supérieure en créant un véritable cluster capable de supporter la migration de VM d’un node à un autre avec une reprise sur incident.

Objectifs et cibles

C’est pourquoi je démarre cette série de quelques articles pour décrire l’installation de ce nouveau lab entièrement basé sur XCP-ng et Xen Orchestra.

On va démarrer, comme j’en ai l’habitude, en posant l’architecture et en décrivant les différents composants qui vont entrer en jeu.

Il est toujours important de définir sa cible avant de se lancer tête baissée…et pour ça, rien de mieux qu’un schéma.

Les objectifs du lab vont être d’exploiter le maximum de fonctionnalités de l’écosystème de Vates en se rapprochant le plus possible d’un cluster VMware ESX pour a minima proposer:

• Du HA : redémarrage et reprise automatique des VMs en cas de perte d’un node sur les nodes survivants.
• De la Migration de VMs à chaud : déplacement d’une VM d’un node à un autre (vMotion like) et d’un stockage à un autre (vStorage like).

Nous verrons si d’autres fonctions, comme un rééquilibrage possible des VMs en fonction de la charge sont possibles (DRS like).

Choix matériel

Serveur

L’IA étant en train de cannibaliser tous les marchés du hardware au moment d’écrire ces lignes, et n’ayant pas un budget illimité, on va faire dans le recyclage.

Pour ça je vais capitaliser sur mes Lenovo ThinkCenter M920q. De modestes mini-PC équipés d’un CPU Intel i5-8500T à 6 cœurs et de 16 Go de mémoire vive DDR4.

Je vais quelque peu booster ces derniers en les poussant jusqu’à 64Go de mémoire. Même si ce n’est pas officiellement supporté, j’ai déjà ce type de config en place, notamment pour VMware et mon lab existant sous XCP-ng.

Je vais partir sur un ensemble de trois serveurs, soit les deux que j’utilisais déjà sous XCP-ng et un que j’exploitais jusqu’à présent sous VMware.

L’avantage de ces petites machines pour un lab c’est qu’elles sont compactes et consomment peu, sans trop chauffer.

Néanmoins, je ne saurais vous conseiller de passer par un changement de pâte thermique en démontant le bloc de refroidissement. En exploitant une pâte de meilleure qualité, on arrive facilement à gagner 2 à 3° qui peuvent s’avérer bénéfiques dans de petits espaces, tout en réduisant la nuisance sonore des ventilateurs.

On peut facilement se procurer ces machines d’occasion. De plus, il y a beaucoup de pièces détachées disponibles et de nombreux mods permettant de transformer leur usage, car elles présentent l’avantage d’avoir un port PCI express interne.

Par contre ça reste des PC de bureau qui commencent à accuser leur âge, il ne faut pas s’attendre à des performances exceptionnelles…mais, pour un LAB et quelques VMs ça peut parfaitement faire l’affaire.

Petite anecdote, la mise à jour de leur bios ne peut se faire qu’avec des barrettes d’origine… Et il n’y a rien qui ne vous l’indique quand vous vous lancez dans les opérations… Vous avez juste un écran noir au redémarrage de l’update… qui ne s’est finalement jamais fait… Vous forcez le redémarrage et vous êtes au même point qu’avant l’update avec l’ancienne version du BIOS. Bref, même Gemini, Claude ou ChatGPT n’ont pu m’aider… et c’est un bon vieux post Reddit qui m’a permis de trouver la solution.

Disque

Si certains ThinkCenter disposent de deux emplacements NVME, les miens n’en ont qu’un seul avec un modeste 256Go par défaut.

C’est insuffisant pour mon besoin, je les ai donc remplacés par des Samsung 990 Pro de 1TO. Même si leurs prix ont augmenté, j’ai pu tomber sur quelques pièces encore accessibles sur Amazon (170€).

Réseau

Par défaut, les ThinkCenter n’ont qu’une seule carte réseau intégrée de 1G. C’est une Intel I219-LM. Elle a l’avantage d’être supportée nativement par énormément d’OS et de solution, mais c’est très limité pour un besoin de clustering d’hyperviseur, surtout si on souhaite mettre en place un réseau de stockage partagé.

C’est pourquoi j’ai profité de l’emplacement PCI express interne pour ajouter une carte 10G.

Sur mon ancien lab, j’avais déjà procédé à cet ajout de carte, mais via une configuration quatre ports 1G.

Ici ce n’est pas suffisant, il me faut davantage de bandes passantes et le passage au 10G est obligatoire.

Je me suis donc tourné vers une ConnectX-3 avec un chipset Mellanox MT27500 réputé pour être très bien supporté par l’open source avec une chauffe réduite pour une carte 10G et une compacité adaptée au peu d’espace proposé par un ThinkCenter. (Compté 65€ la carte sur Amazon)

Il faut juste une équerre PCI spécifique, disponible sans problème sur AliExpress ou autre pour connecter la carte… Et partir du principe qu’on ne pourra pas forcément fixer le bout de la carte en sortie du serveur.

Il est important de noter qu’il s’agit d’une carte avec un emplacement SFP+ et non d’un port 10G en cuivre.

Ce choix se justifie par la chauffe moins importante, surtout si on exploite ensuite un câble SFP+ DAC ou le SFP est intégré.

Il semble anodin, mais un SFP en cuivre consommera entre 2 watts et 5 watts, alors qu’un câble DAC Twinax sera limité à 0,5 watt. Dans une machine comme un ThinkCenter où la circulation de l’air est très limitée, ça a son importance.

Pour connecter tout ce beau petit monde, j’ai sorti la CB pour un MikroTik CRS309-1G-8S+IN (257€ sur Amazon).

Le commutateur/routeur de la marque lettone est très apprécié dans le homelab. Il dispose de 8 ports SFP+ 10G et surtout, il est entièrement passif. C’est un avantage lorsqu’il se trouve au milieu d’un salon…

Grâce à son OS RouteurOS, il offre énormément de fonctions et demeure un must du rapport qualité prix.

Je m’appuierais aussi sur mes switchs existant (Netgear et Zyxel ) pour les connexions 1G (je les appellerais switch legacy)

Architecture

System

Le LAB est composé de trois serveurs sur lesquels XCP-ng est déployé:

• prdxcpsrv001 (192.168.10.20/24)
• prdxcpsrv002 (192.168.10.21/24)
• prdxcpsrv003 (192.168.10.22/24)

Ils devront être dans un pool XCP-ng que je vais nommer xcp-pool.

Un pool permet de regrouper les capacités de calcul (CPU) et de mémoire (RAM) de tous les serveurs.

Dans l’écosystème XCP-ng, chaque groupe de serveurs (appelé donc pool) a un serveur maître (pool master) qui agit comme chef d’orchestre. Dans mon cas sera prdxcpsrv001.

C’est lui également qui hébergera la première VM prdxcpxor501 (192.168.10.23) pour l’installation de Xen Ochestra, mais nous verrons cela dans un article spécifique.

Sans Pool, pas de LiveMigration ou de Hight Availability.

Network

La partie réseau est importante, car elle va devoir répondre à plusieurs besoins :

• Offrir une interface de management distincte pour séparer le flux de travail du flux d’administration.
• Proposer plusieurs VLANs pour segmenter le trafic par usage.
• Offrir une bande passante importante, notamment pour le stockage répliqué dont nous parlerons juste après.

Pour ça voici la cible :

Je ne vais pas rentrer plus loin à ce stade, nous verrons le détail de la configuration dans un article spécifique.

Storage

Matériellement, je ne dispose qu’un disque de 1To par serveur. L’objectif va être de le découper en trois parties.

• OS & Système : environ 40Go dédiés a l’installation de XCP-ng et du système.
• SR local : un SR pour Storage Repository soit l’équivalent d’un datastore chez VMware. C’est un espace de stockage dédié à l’hébergement des VMs. Chaque serveur disposera d’un SR local de 150Go. Les VMs qui y seront hébergées ne pourront pas être exécutées ailleurs que sur le serveur ou se trouvent leurs données. Va être utile pour des VMs dont la redondance est assurée par la solution logiciel associée, comme par exemple, des control plane Kubernetes….
• SR répliqué : Le reste de l’espace disque, soit environ 740 Go, sera consacré à l’usage de la solution de stockage en bloc de réplication Vates: xostor.

La dernière partie du disque est particulière. Le but va être de créer un stockage combinant l’ensemble des trois partitions de 740Go pour construire un SR global au cluster via xostor.

J’aurai l’occasion d’en parler spécifiquement quand on traitera de sa mise en place, mais xostor est l’implémentation de LINSTOR/DRBD dans un cluster XCP-ng. Si aucun de ces termes ne vous parle, sachez juste pour l’instant qu’il s’agit d’une solution de réplication de données de stockage bloc permettant de synchroniser entre eux plusieurs stockages locaux. On bénéficie ainsi d’une réplication des données d’un serveur à un autre. Ceci permet à une VM de pouvoir être exécutée sur différents nodes (a raison d'un node à la fois bien sure) et d’avoir une duplication de sa donnée.

Dans mon cas, je vais choisir d’avoir un niveau de réplication de deux, c’est-à-dire qu’une VM qui sera sur le SR XOSTOR verra sa donnée écrite sur deux disques, l’une sur le disque du serveur local où elle s’exécute, l’autre sur un des serveurs restants du cluster. La VM pourra ainsi être démarrée sur n’importe lequel des trois serveurs si son node principales venait à tomber. Même la troisième machine qui ne disposerait pas de la donnée sur son disque (réplication de 2) serait capable de transiter à travers le réseau pour accéder à la donnée du second serveur.

(On pourrait avoir une réplication de trois, mais on perdrait encore davantage d'espaces. Deux est un bon compromis, puisqu'on arrive à un espace utile total d'un peu plus d'un To.)

D’où l’obligation d’exploiter un réseau 10G pour être certains d’avoir la bande passante et la latence nécessaires pour cet usage.

Chacun des serveurs va donc avoir une IP dédiée sur le VLAN storage pour échanger les données bloc :

• prdxcpsrv001 : 192.168.12.1
• prdxcpsrv002 : 192.168.12.2
• prdxcpsrv003 : 192.168.12.3

Là aussi prdxcpsrv001 sera le chef d’orchestre de la coordination des données.

A noter également que cette mécanique ne peut fonctionner qu'avec un minimum de trois serveurs, ceci pour des questions d'arbitrage et de quorum. Enfin mon NAS (un terramaster F4-424) sera mis à contribution pour faire office d'espace NFS ou seront disponibles les différentes ISOs d'installation des OS que je pourrais être amené à utiliser pour déployer mes VMs.

Conclusion

Voilà, le décor est planté, il n’y a plus qu’a….

Pour réaliser ce lab, il va falloir se baser entièrement sur les sources de l’écosystème XCP-ng, car les Appliance et installation assistées sont réservées à ceux qui souscrivent une licence auprès de l’éditeur. (l’appliance peut être utilisée gratuitement, mais ses fonctions seront alors limitées). Je m’appuierais bien sûr sur ce que j’ai déjà pu faire, notamment pour l’installation de l’hyperviseur et de Xen Orchestrator, mais la partie storage va être différente, et il va sans doute falloir transpirer un peu pour arriver au but. On verra par la suite !