Andrea Danti - Fotolia

Hyperconvergence : Canonical lance MicroCloud

Alors qu’il disposait déjà de distributions pour déployer des clusters Kubernetes, Canonical revient à un produit qui concurrence VMware et Nutanix, mais plus ciblé pour les PME.

Cet article est extrait d'un de nos magazines. Téléchargez gratuitement ce numéro de : STORAGE: Storage 38 – Quel stockage après le rachat de VMware ?

Sept minutes pour configurer vingt-cinq serveurs, moins du double pour en configurer cinquante. Canonical, l’éditeur du Linux Ubuntu, se lance dans une plateforme d’hyperconvergence, baptisée MicroCloud, qui se veut plus fiable, plus simple, plus rapide à mettre en œuvre que des clusters VMware vSAN, Nutanix HCI ou Red Hat OpenShift.

« Notre idée est de démocratiser les infrastructures du cloud. Nous voulons que quiconque puisse installer un cloud dans ses locaux : une PME, une usine, un studio de développement d’applications, etc. », lance Miona Aleksic, la directrice produits de Canonical, lors d’une rencontre avec LeMagIT.

Pour commencer, la distribution MicroCloud n’est pas officiellement présentée comme une solution d’hyperconvergence, car le terme est jugé trop technique pour le public visé. En revanche, elle en a toutes les caractéristiques.

Les hyperviseurs KVM et LXD exécutent et répartissent des machines virtuelles (VM) et des containers, respectivement, sur un cluster. Le SDS Ceph – ici rationalisé en une version prête à l’emploi MicroCeph – se charge de constituer un pool de stockage global depuis les disques présents dans tous les serveurs. Le SDN OVN, enfin, assure la mise en réseau, l’attribution dynamique des adresses IP et le routage. La taille minimale est, comme sur toutes les infrastructures hyperconvergées, de trois nœuds.

Une infrastructure hyperconvergée est l’assemblage le plus simple pour constituer un cloud. C’est-à-dire un cluster où il suffit d’ajouter des serveurs physiques (des nœuds) pour augmenter automatiquement la puissance de calcul et la capacité de stockage utilisables par les applications. Pour que cela fonctionne, ces applications doivent être livrées sous la forme de modules suffisamment autonomes pour pouvoir s’exécuter sur n’importe quel nœud : des machines virtuelles ou des containers.

LXD, Snap et Raft : les ingrédients maison

« Notre idée est de démocratiser les infrastructures du cloud. »
Miona AleksicDirectrice produits, Canonical

L’hyperviseur LXD est le démon (en anglais « daemon », un processus système) plus particulièrement mis au point par Canonical pour lancer, paramétrer, stocker et mettre en réseau les containers LXC du noyau Linux. En ce sens, il est concurrent de Docker. Ici, cela signifie surtout qu’il dispose de son propre système de packages, appelé Snap. « Snap est la clé de la simplicité de notre déploiement. Car le package .snap d’un module fonctionnel ou d’une application contient lui-même toutes les dépendances pour que l’exécution réussisse du premier coup. Sous Linux, un package .deb télécharge automatiquement toutes les dépendances sur un même serveur. Mais dans un cloud, les dépendances sont d’autres VM ou d’autres containers susceptibles de s’installer sur d’autres serveurs. C’est ce point qui rend d’ordinaire le déploiement d’un cloud complexe et que MicroCloud simplifie avec Snap », explique Miona Aleksic.

Pour éviter que les mises à jour ne soient trop lourdes en réinstallant chaque fois les mêmes dépendances, le système Snap comprend dans ses dernières versions la possibilité de n’installer que les binaires ayant changé depuis l’installation précédente. « Accessoirement, ce système permet de faire la mise à jour d’une application ou d’un service sans couper son fonctionnement », assure notre interlocutrice.   

Au-dessus de LXD – et de KVM qui fait la même chose que lui, mais pour les machines virtuelles –, il n’y a pas de Kubernetes pour orchestrer le fonctionnement, les accès et le routage des applications au sein du cluster. MicroCloud se débrouille tout seul, avec un minimum de couches fonctionnelles, toujours dans un souci de légèreté et gain de performances.

« Nous utilisons la technologie de tolérance de panne Raft. Il s’agit d’un algorithme qui s’assure de répartir les containers et les VM dans le cluster de sorte à maximiser les vitesses d’accès et la continuité d’activité en cas de défaillance », dit Miona Aleksic.

De leur côté, le SDS Ceph et le SDN OVN sont des couches d’infrastructures classiques du monde Open source. Ceph est notamment utilisé pour incarner le stockage dans tous les produits de Red Hat, dont OpenShift, sa version de Kubernetes. OVN, également utilisé dans OpenShift, a surtout été rendu célèbre par son utilisation dans OpenStack, comme une extension d’Open vSwitch pour virtualiser les réseaux.

Concurrencer vSphere et Nutanix

MicroCloud a vocation à concurrencer, pour les PME, des produits de virtualisation plus lourds, comme vSphere de VMware et HCI de Nutanix. Pour autant, Canonical avait initialement suivi la même voie que son concurrent Red Hat, à savoir parier que la virtualisation ne servait plus à rien et qu’il suffisait de déployer un cluster qui n’exécute que des containers.

L’intérêt des containers est qu’ils ne contiennent que l’applicatif, alors que les VMs, généralement dix fois plus lourdes, contiennent aussi tout un système d’exploitation et toutes les bibliothèques nécessaires.

De fait, Ubuntu et Red Hat proposent tous deux à leur catalogue des distributions basées sur Kubernetes, qui fait office de standard dans l’orchestration de containers. Respectivement, il s’agit de Charmed Kubernetes et d’OpenShift pour les clusters d’entreprise, et de MicoK8s et MicroShift pour les clusters d’appoint à installer en PME, en usine, ou dans l’arrière-salle d’un point de vente.

« Ces produits sont faits pour les entreprises qui veulent utiliser Kubernetes avec de nouvelles applications conçues pour le web. Utiliser Kubernetes pour exécuter des applications historiques nécessite de les réécrire pour qu’elles ne soient plus dépendantes d’un OS. Or, nous nous sommes aperçus que ce n’est pas ce que veulent les entreprises, car cette transformation leur coûterait bien trop cher. Elles souhaitent pouvoir utiliser telles quelles leurs applications. Donc, les utiliser sous la forme de machines virtuelles », argumente Miona Aleksic.

Elle insiste pour dire que MicroCloud est forcément basé sur un noyau Linux Ubuntu – alors que Kubernetes peut s’installer au-dessus de n’importe quel Linux ou Windows –, mais qu’il peut exécuter en VM n’importe quel OS. Le Linux de Canonical (Ubuntu) comme celui de Red Hat (RHEL). Et bien sûr Windows.

« Nous ne sommes pas en train de mettre un nouveau système de containers par-dessus une vieille distribution qui ne faisait que des machines virtuelles. »
Miona AleksicDirectrice produits, Canonical

Et, aussi, OpenShift. Car, comme le disait déjà récemment VMware au MagIT, la manière la plus simple d’installer OpenShift reste, pour les entreprises, de l’encapsuler dans une VM. Ce constat, partagé par plusieurs analystes du marché, semble de fait condamner la carrière des produits qui proposent de déployer Kubernetes directement sur des serveurs matériels. D’où l’idée de Canonical de revenir à un produit de virtualisation.

« Mais que ce soit clair : nous ne sommes pas en train de mettre un nouveau système de containers par-dessus une vieille distribution qui ne faisait que des machines virtuelles », intervient la directrice produits. LeMagIT croit comprendre qu’elle fait référence à VMware et son offre Tanzu. « Nous lançons une toute nouvelle plateforme et celle-ci continue volontairement de supporter les VM. »

« Par ailleurs, MicroCloud est 100 % Open source », ajoute-t-elle. Cette fois-ci pour se différencier de Red Hat, lequel a récemment changé sa licence pour que RHEL ne soit plus clonable.

À date, MicroCloud n’est utilisable que pour déployer des clusters d’appoint, c’est-à-dire qui s’administrent un par un, soit localement, soit à distance. Dans un avenir plus ou moins proche, Canonical proposera une console qui servira à administrer centralement une flotte de clusters MicroCloud déployés sur plusieurs sites.

Pour approfondir sur Infrastructure hyperconvergée

Close