Historique de la solution Harvester
Pour comprendre les raisons de sa naissance, il faut observer le repositionnement stratégique de l’entreprise allemande SUSE Enterprise.
Jusqu’en novembre 2020, SUSE était un leader du marché sur des distributions Linux de classe entreprise, faisant jeu égal avec Red Hat et Ubuntu. Leur distribution Linux SLES s’adapte à tous les cas d’usage des serveurs à architecture processeur ARM et x86 (1), avec SUSE Manager (Projet Uyuni fork du projet Spacewalk) pour gérer le cycle de vie du système. Des dépôts spécialisés adaptent la distribution à tous les cas d’usage : Desktop, Server, SAP, Real-Time, HA (High Availability), HPC (High Performance Computing), etc. SUSE propose une version payante SUSE Linux Enterprise (SLE) avec support mais distribue également une version Open Source dont les binaires sont identiques : openSUSE Leap.
Mais face à ses concurrents, notamment Red Hat et VMware, SUSE était absent de l’écosystème de la containerisation. En effet, depuis la publication de Kubernetes à la communauté le 21 Juillet 2015, cette technologie offre des perspectives exceptionnelles de croissance. Les applications cloud natives sont devenues la norme.
SUSE se devait de proposer sa propre distribution Kubernetes certifiée CNCF. En décembre 2021, SUSE annonce l’acquisition de Rancher Labs, qui propose
- Rancher (Management) Server, qui permet :
- la gestion multiple de clusters Kubernetes avec l’ABAC (Attribute-Based Access Control)
- la gestion par projets (ensemble de namespaces sur des groupes de clusters) utilisé pour le “continuous delivery” sur de multiples clusters
- Et de nombreuses autres fonctionnalités (Marketplace via des Helm Charts, Supervision, Puits de logs, Conformité, Sécurité, Sauvegarde, Déploiement de cluster, Template de cluster, …)
- Une distribution Kubernetes certifiée CNCF, RKE (Rancher Kubernetes Engine) pour un usage Datacenter (2).
C’est la distribution Kubernetes Open Source la plus populaire du moment (également nommée Rancher Labs). Cette acquisition propulse SUSE directement parmi les leaders du marché.
SUSE ne s’est pas contentée du rachat de Rancher Labs, mais a également poursuivi leurs initiatives. En août 2021, l’interface de management de Rancher Server fait peau neuve avec la sortie de la version 2.6 : l’expérience utilisateur est simplifiée par une navigation simplifiée. La distribution Kubernetes RKE (2) évolue en RKE2 pour gagner en sécurisation et intégrer de nouveaux CNI plugins (Cillium, Multus). Pour répondre aux besoins IOT, Rancher Labs annonce en février 2019 la distribution Kubernetes K3S : légère et capable de fonctionner sur un seul serveur, elle présente un véritable engouement de la communauté, ne serait-ce que pour remplacer minikube.
Qu’est-ce qu’une infrastructure hyper-convergée ?
SUSE Rancher est ainsi devenu un acteur majeur d’orchestration de conteneurs. Jusque là, rien à voir avec les infrastructures hyper-convergées, nous sommes bien d’accord.
Voici une définition simple d’une infrastructure hyper-convergée : “une solution d’orchestration qui permet de fournir des ressources réseaux, disques et de traitement en utilisant des solutions de virtualisation matérielle.”
Techniquement, nous voulons avoir des serveurs physiques (CPU / RAM / disk) reliés entre eux par des switchs et routeurs, permettant de créer toutes les ressources virtuelles nécessaires à la construction de composants d’un datacenter : Virtual Machine (VM), NAS, SAN, WAF, firewall, ADC (Application Delivery Controller), DDI (DNS-DHCP-IPAM), etc.
Dans les plateforme hyper-convergées, le tableau suivant présente les composants des principales solutions du marché :
Ces solutions sont à des stades de maturité très divers, mais toutes sont prêtes pour la production. Le but ici n’est pas de faire une analyse comparative, mais plutôt de procéder par analogie pour présenter cette nouvelle solution : Harvester.
Présentation globale de la solution Harvester
Comme nous pouvons le constater dans le tableau précédent, Harvester est une solution d’infrastructure hyper-convergée élégante à base de containers, cloud native by design. Si vous aviez l’habitude de faire tourner des containers dans des VMs, maintenant, vos VMs sont des containers !
SUSE Rancher propose de diminuer la complexité d’intégration de chaque composant par l’utilisation sa distribution Kubernetes RKE2, et de s’appuyer sur une installation décrite par des fichiers YAML :
- L’ensemble de la solution repose sur une valeur sûre de SUSE : SLE (SUSE Linux Enterprise), qui offre la technologie de virtualisation KVM.
- KVM est utilisée par l’architecture du projet KubeVirt. KubeVirt est installé dans un cluster Kubernetes RKE2 afin d’instancier des machines virtuelles.
- Mise en réseau du cluster RKE2 par le CNI flannel, qui utilise à son tour :
- Stockage par le CSI Longhorn qui fonctionne en distribuant les blocs de données sur les différents nœuds.
Présentation technique de la solution Harvester (deep dive)
Concernant le stockage, nous sommes encore loin des performances de Nutanix OAS, VMware vSAN ou Azure S2D capable d’atteindre facilement le million d’IOPS. Longhorn n’est pas un système de stockage distribué qui peut bénéficier nativement des performances d’une scalabilité horizontale. C’est une solution de stockage bloc comparable à ce que propose Ceph ou Portworx : elle répartit des réplicas de bloc sur différents serveurs pour assurer la résilience. À des fins d’optimisation, Kubernetes va planifier préférentiellement le démarrage d’un nouveau pod sur l’un des serveurs possédant un réplica de bloc. Vous imaginez déjà ce qu’il peut se passer si votre pod possède plusieurs disques (Persistent Volumes) !
Les performances lecture / écriture sont directement liées à la taille et à la performance individuelle des disques. La déduplication, la compression, le chiffrement et le tiering ne sont pas gérés : cependant, comme Longhorn utilise des systèmes de fichiers montés (et non des disques), la performance peut être gérée au niveau OS des serveurs : un système de fichiers tel que ZFS pourrait apporter une solution d’amélioration de la performance en proposant la gestion de la taille des disques, de la distribution d’écriture sur plusieurs disques, de chiffrement et de tiering (hiérarchisation de l’écriture en fonction du besoin d’accès). Toujours est-il que sans une optimisation de l’OS, Harvester recommande des disques full flash (SSD ou encore mieux : NVMe).
L’accès concurrentiel aux blocs est prévu dans un futur proche ; il est actuellement disponible à titre expérimental uniquement.
Pour la sauvegarde, Longhorn utilise des partages NFS ou du stockage de type objet compatible S3. Il gère la déduplication avec une granularité de 2 Mo.
Sur la partie réseau, le CNI canal (Container Network Interface) est un projet d’intégration de Calico et de Flannel. Flannel est un CNI “simple” et performant, mais aussi très limité, car il ne gère pas les Network Policies et le BGP. Il crée un réseau superposé (overlay layer 3 IPv4) qui interconnecte les serveurs via un tunnel VxLAN (encapsulation de la couche 2 dans la couche 4) (3). Mais, il ne supporte actuellement que le protocole IPv4 au niveau de la couche 3.
Les plugins Multus et Bridge permettent de configurer les interfaces du serveur et leur ségrégation par VLAN. La manipulation et le filtrage des paquets se fait via des chaînes iptables déployées sur Linux SLES.
L’intégration Calico apporte principalement :
- Le support des Networks Policies qui permet l’isolation par labellisation des pods.
- L’intégration du BGP nécessaire pour les architectures hybrides kubernetes (Cloud public / Cloud privé).
L’utilisation d’eBPF en remplacement d’iptables, comme le propose également le CNI Cilium, permettrait d’optimiser les performances réseau : en effet, eBPF permet de rester en espace kernel et au lieu de faire des aller-retours d’appels système entre le espace utilisateur et l’espace kernel. Cette fonctionnalité est actuellement supportée par le CNI Calico et ne semble pas encore être portée dans le CNI Canal.
Conclusion
Après un aperçu technique de la solution Harvester, cette intégration cloud native est prometteuse. Mais est-ce que cette réponse européenne pourrait se positionner face aux grands acteurs des infrastructures hyper-convergées comme VMware, Nutanix, Azure Stack, etc ?
Bien évidemment, de manière factuelle, Harvester souffre encore de sa jeunesse et de sa relative immaturité. Cependant, son potentiel et sa vitesse de développement pourraient surprendre, comme d’ailleurs tout l’écosystème Kubernetes. Certains grands comptes en voient déjà le potentiel et commencent à l’exploiter en production.
Durant les prochains mois, nous allons éprouver Harvester dans un lab interne chez Devoteam. Nous ne manquerons pas de vous partager les conclusions de nos expériences. Pour les plus impatients d’entre vous, un premier aperçu de sa prise en main a déjà été publié par SUSE en mai dernier : Getting Hands on with Harvester HCI.
Nous voulons explorer la solution dans son ergonomie d’utilisation, actuel point fort de Rancher Server ; mais aussi dans sa capacité à héberger un cluster Kubernetes, RKE2 ou K3S, utilisant la persistance de données Longhorn, fournies directement par Harvester. Nous ne manquerons pas de mesurer les performances en observant ce que le système de fichier ZFS pourrait apporter.
Devoteam Innovative Tech suit de près cette technologie. Entièrement fondé sur des produits Open Source et Cloud Native, Harvester peut être supporté durablement par l’éditeur SUSE et répond aux enjeux de production. Particulièrement adapté aux besoins de cloud privé, qu’il soit on premise, edge computing ou les deux, donc parfaitement capable de s’intégrer dans une stratégie de “souveraineté technologique européenne”, Harvester pourrait rapidement trouver sa place sur le marché.
(1) Les architectures IBM-Z et IBM-Power sont également prises en charge.
(2) Les distributions Kubernetes certifiées CNCF de SUSE sont étudiés à différents usages :
– RKE & RKE2 pour usage datacenter et cloud
– K3S pour un usage local (edge)
(3) Une très bonne introduction au CNI Canal Show me the Canal !.
Les articles Introduction to flannel (Detailed explanation of UTP, VXLAN, Host Gateway mode), Kubernetes Journey — Up and running out of the cloud — flannel et l’infographie Flannel setup with vxlan illustrent les manipulations de paquets et peuvent aider à la compréhension technique.
Autres articles de la série
Partie 1 : Microsoft Azure Stack HCI
