Introduction à SUSE Harvester

SUSE Harvester réunit machines virtuelles, conteneurs et stockage sur les mêmes serveurs, sans hyperviseur propriétaire. Il s'installe sur du bare metal depuis une image ISO, s'administre par une interface web, et repose sur Kubernetes plutôt que sur une pile de virtualisation classique. Cette page explique ce que recouvre l'hyperconvergence ici, ce que le produit sait faire, ce que son installation exige en matériel, et ce que son rattachement à Rancher change. Elle s'adresse à qui évalue une alternative libre à une plateforme de virtualisation commerciale, avant d'engager des serveurs dessus.

Ce que vous allez apprendre

• Ce que signifie hyperconvergé chez Harvester, et ce qui le sépare d'un hyperviseur classique
• Les fonctionnalités réellement disponibles : cycle de vie des VM, migration à chaud, sauvegarde
• L'architecture interne : le système immuable des nœuds et le stockage distribué
• Les prérequis matériels, et pourquoi le disque compte plus que le processeur
• Ce que l'intégration Rancher déplace, en particulier l'authentification

Qu'est-ce que SUSE Harvester ?

SUSE Harvester est une plateforme d'hyperconvergence libre. Le terme recouvre une idée simple : les mêmes serveurs portent à la fois le calcul, le stockage et le réseau, au lieu de confier chacun à une baie ou à un équipement dédié. Ce qui disparaît n'est pas la complexité, c'est le matériel spécialisé et les contrats qui vont avec.

Le projet est open source et porté par SUSE, qui en fait aussi une offre commerciale supportée. Cette double nature a une conséquence pratique : le code et la documentation sont publics, mais les cycles de version suivent une feuille de route d'éditeur, pas le rythme d'un projet communautaire.

Les fonctionnalités d'Harvester

La liste ci-dessous reprend ce que l'éditeur annonce, et sert à situer le périmètre du produit avant de l'évaluer. On y trouve un cycle de vie des VM complet, mais aussi des fonctions qui supposent un cluster de trois nœuds, la migration à chaud en tête : les prérequis de la section suivante expliquent pourquoi.

• Installation : Harvester peut être installé directement sur un serveur bare metal à l'aide d'une image ISO ou de scripts iPXE.
• Cycle de vie des VM : Les utilisateurs peuvent créer, éditer, cloner et supprimer des VMs facilement. L'injection de clés SSH et le cloud-init sont possibles.
• Migration à chaud des VM : Harvester permet la migration de VM d'un hôte à un autre sans temps d'arrêt.
• Sauvegarde et restauration des VM : Il supporte la sauvegarde de VMs sur des serveurs NFS, S3, ou des NAS. On peut utiliser ces sauvegardes pour des restaurations et des créations de nouvelles VM.
• Stockage et réseau : Harvester prend en charge le stockage bloc distribué et offre des fonctionnalités avancées de gestion réseau, y compris l'utilisation d'une IP virtuelle ou de plusieurs cartes réseau.
• Intégration à Rancher : Harvester s'intègre avec Rancher, permettant une gestion unifiée des charges de travail VM et Kubernetes au sein de Rancher.

Architecture d'Harvester

Harvester n'a écrit ni son propre hyperviseur ni son propre stockage : il assemble des briques open source déjà éprouvées, et c'est ce qui rend son architecture lisible. Savoir quelle brique fait quoi sert au diagnostic, car un incident se tracera dans les journaux de la brique concernée.

Harvester installe sur ses nœuds un système d'exploitation Linux immuable, Elemental for SUSE Linux Micro (version 6.2 en Harvester 1.8 et 1.9, anciennement nommé SLE Micro), conçu pour simplifier la maintenance et réduire la surface d'attaque des clusters Kubernetes.

Pour la virtualisation, Harvester fait appel à KubeVirt, lui-même bâti sur KVM (Kernel-based Virtual Machine). Concernant la gestion du stockage, Harvester emploie Longhorn, une solution offrant un stockage bloc distribué. Enfin, pour le monitoring et la journalisation, la plateforme s'appuie sur Grafana et Prometheus, ce qui donne une observabilité de l'ensemble sans outillage supplémentaire à poser.

Installation d'Harvester

L'installation se fait via une image ISO d'Harvester, qui se charge de la configuration des nœuds de gestion et l'initialisation du cluster. Après l'installation, il est important de configurer le réseau, le stockage avec Longhorn et les paramètres de sécurité. Harvester permet également d'ajouter des nœuds supplémentaires pour augmenter la capacité du système.

Pré-requis pour le déploiement d'Harvester

La première décision est la topologie, pas le matériel. La documentation Harvester est nette : « A three-node cluster is required to fully realize the multi-node features of Harvester ». Un déploiement à un seul nœud reste possible pour découvrir le produit, mais la documentation est nette : un tel cluster ne prend en charge ni la haute disponibilité, ni les réplicas multiples, ni la migration à chaud, c'est-à-dire précisément ce qu'on attend d'une plateforme HCI en production. Trois machines bare metal, des NUC suffisent, forment donc le socle réel.

Côté processeur, Harvester accepte ARM64 ou x86_64, à condition que la virtualisation assistée par le matériel soit disponible. Les autres seuils se lisent en deux colonnes, et l'écart entre elles n'est pas cosmétique :

Ressource	Test et développement	Production
Cœurs CPU	8 minimum	16 minimum
Mémoire	32 Go	64 Go
Disque	250 Go	500 Go, 1 To et plus recommandé
Performance disque	5 000 IOPS aléatoires	5 000 IOPS aléatoires
Réseau	1 carte, 1 Gbps	2 cartes agrégées, 10 Gbps

Glissez pour voir

Les 5 000 IOPS aléatoires supposent du SSD ou du NVMe : Longhorn réplique les volumes entre les nœuds, et un disque mécanique s'effondre sur ce profil d'écriture.

Des nœuds supplémentaires s'ajoutent après l'installation initiale, ce qui permet de démarrer sur le socle de trois machines puis d'étendre la capacité sans reconstruire le cluster.

Processus d'installation

Note

Cette section donne la trame de l'installation, pas un compte rendu de déploiement : elle n'a pas été rejouée sur un cluster de trois nœuds, qui est la topologie réellement supportée.

Pour installer SUSE Harvester, vous pouvez suivre le tutoriel détaillé disponible sur la documentation officielle. Voici les grandes lignes :

1. Téléchargez l'image ISO d'Harvester depuis la page des releases, qui publie les images x86_64 et arm64 de chaque version.
2. Préparez vos serveurs bare metal en vérifiant qu'ils répondent aux prérequis matériels.
3. Démarrez chaque serveur avec l'image ISO d'Harvester et suivez les instructions à l'écran pour l'installation.
4. Configurez votre premier nœud Harvester et ensuite rejoignez les autres nœuds au cluster.
5. Accédez à l'interface utilisateur web pour terminer la configuration du réseau, du stockage et des paramètres de sécurité.

Les étapes exactes dépendent de votre matériel et de votre réseau, et elles changent d'une version à l'autre. La documentation officielle versionnée reste donc la référence pour les commandes détaillées : cette page en donne la trame, pas le pas-à-pas.

Création de VM

Créer une VM suppose d'abord de fournir une image de système d'exploitation. N'importe quelle distribution Linux convient, à condition d'être livrée dans un format d'image que Harvester sait lire, typiquement une image cloud au format qcow2 ou raw. C'est aussi là que cloud-init entre en jeu, pour personnaliser la machine à son premier démarrage.

1. Préparez l'image de la VM : obtenez l'image du système à déployer. Elle peut être une ISO ou un format de disque pris en charge comme QCOW2.
2. Déposez l'image dans Harvester : accédez à l'interface utilisateur web d'Harvester, allez dans la section des images et déposez votre image.
3. Créez la VM : une fois l'image déposée, utilisez-la pour créer une nouvelle machine, en précisant CPU, mémoire et options de réseau.
4. Démarrez la VM : une fois configurée, démarrez-la depuis l'interface d'Harvester.

Utilisation de Terraform pour gérer les ressources

Un provider Terraform publié par le projet Harvester couvre les VM, les images, les réseaux et les volumes. C'est ce qui rend l'usage en CI/CD concret : un environnement de test se crée et se détruit par un apply puis un destroy, sans passer par l'interface web.

• Provider Terraform Harvester, sur GitHub
• Managing Harvester with Terraform, sur le blog SUSE

Si Terraform ne vous est pas familier, commencez par la formation Terraform.

Gestion et maintenance de SUSE Harvester

Deux points d'exploitation méritent d'être décidés avant la mise en production, pas après. Les mises à jour d'un cluster hyperconvergé touchent à la fois l'hyperviseur, le stockage et Kubernetes : elles se planifient sur une fenêtre, et se testent ailleurs d'abord. Et la gestion des accès se règle dans Rancher dès que le rattachement existe, ce qui déplace la question hors de l'interface d'Harvester.

Ce que Harvester apporte, et ce qu'il déplace

L'apport tient en une phrase : une plateforme de virtualisation complète, libre, posée sur du matériel banal, là où les solutions commerciales imposent leurs licences et leur matériel. Le provider Terraform rend en plus l'usage en pipeline CI/CD accessible, ce qui reste rare sur ce type de plateforme.

Côté authentification, Harvester documente le sujet et s'appuie sur Rancher dès qu'il lui est rattaché : la gestion de virtualisation hérite alors des fournisseurs d'identité de Rancher, dont Active Directory, OpenLDAP et SAML. L'annuaire ne se configure donc pas dans Harvester lui-même, mais au niveau de Rancher, ce qui change l'ordre des opérations quand on planifie un déploiement multi-utilisateurs.

Pour la gestion de configuration des VM, la voie est celle de n'importe quelle plateforme : l'agent et sa configuration se placent dans les images d'OS utilisées au déploiement, plutôt qu'après coup sur chaque machine.

À retenir

• Harvester est une plateforme hyperconvergée bâtie sur Kubernetes : les machines virtuelles y deviennent des ressources du cluster.
• Les nœuds tournent sur un système d'exploitation immuable, Elemental for SUSE Linux Micro 6.2, et non sur une distribution généraliste.
• Le stockage bloc distribué repose sur Longhorn, qui réplique les volumes entre nœuds : d'où l'exigence de 5 000 IOPS et de disques SSD ou NVMe.
• La migration à chaud d'une VM d'un hôte à l'autre se fait sans interruption.
• Les sauvegardes de VM partent vers NFS, S3 ou un NAS, et servent aussi à créer de nouvelles machines.
• L'authentification ne se configure pas dans Harvester mais dans Rancher, dès qu'il lui est rattaché : cela change l'ordre des opérations d'un déploiement multi-utilisateurs.
• Un provider Terraform publié par le projet rend l'usage en CI/CD concret.

Prochaines étapes

KubeVirt Le moteur de virtualisation sur lequel Harvester s'appuie.

Formation Virtualisation Situer l'hyperconvergence parmi les autres approches.

Formation Terraform Piloter les ressources Harvester en Infrastructure as Code.

Sources et références

La documentation officielle versionnée reste la référence pour les commandes et les prérequis, qui changent d'une version à l'autre. Les deux retours d'expérience qui suivent donnent un point de vue extérieur, utile avant d'engager du matériel :

• Documentation Harvester
• Harvester by SUSE, Devoteam
• Test (incomplet) de Rancher Labs Harvester, blog de Zwindler

×

📖 Voir la documentation →