VMworld : ESXi ARM mon amour, encore et toujours …

Il y a un an déjà, VMware annonçait en fanfare le développement de ESXi ARM. A l’époque j’avais été vraiment emballé par le concept et les applications potentielles que cette nouvelle plateforme hardware nous promettait. Aujourd’hui il est temps de faire un point d’étape sur ce projet, dont on parle assez peu finalement mais qui de part ses implications est au coeur de la vision du datacenter de demain.

Aujourd’hui encore ça a été un véritable de plaisir de retrouver Régis de VMware, qui m’en avait déjà mis plein les yeux il y a un an. Toujours aussi passionné, il m’a permis de reprendre cette grande aventure du développement de ESXi ARM. Mais commençons par le plus évident.

Un stand ARM ???

L’année dernière, les démonstrations se faisaient sous la bannière VMware. Depuis, ARM himself a souhaité aider le petit groupe de développeurs acharnés chargés de ce projet et a sponsorisé cette activité. C’est désormais sous le flambeau d’ARM que nous nous retrouvons au VMworld. Excellente initiative, intéressée aussi, forcément, de la part de la société anglaise.

Le Raspberry Pi 4

Vous savez sans doute qu’un nouveau Raspberry Pi, 4ème du nom, est sorti il y a quelques mois. Plus puissant, avec plus de RAM (4 Go) et disposant, contrairement aux précédentes versions, d’un vrai contrôleur d’interruption indispensable au bon fonctionnement d’un hyperviseur digne de ce nom. En conséquence, ESXi ARM sur Raspberry Pi 4 est maintenant une vraie version de l’hyperviseur maison, non bridée ! Elle partage l’ensemble de son code avec ESXi 7.0 encore en bêta aujourd’hui. L’ESXi ainsi constitué est capable de se connecter à un vCenter, de faire du vMotion avec ses congénères ainsi qu’assurer la plupart des fonctions standard au sein d’un cluster.

Les applications entrevues pour cette plateforme qui reste minuscule, tant en terme de formfactor qu’en terme de puissance et mémoire disponible sont malgré tout assez importantes : IoT bien sûr, mesures de conditions environnementales ou de conditions de fonctionnement de machines outil au sein d’une chaîne de fabrication par exemple. Régis cite notamment des problématiques bien réelles de certains telcos utilisant des contrôleurs 4G/LTE dans des antennes radio dont la mise à jour à distance, si elle se passe mal, implique invariablement un déplacement sur place d’un technicien pour remplacer le composant ou le remettre en selle. Avec un mini cluster ARM, les mises à jours seraient beaucoup plus simple (avec l’utilisation de FT par exemple).

On peut le dire aujourd’hui, ESXi sur le Raspberry Pi4 est techniquement très proche d’une industrialisation et il manquerait peu pour qu’il soit utilisable dans des environnements de production.

Le cloud et NSX-T

Amazon a annoncé récemment qu’ils allaient proposer (et proposent déjà à l’heure où on parle), un peu à la manière de Scaleway, des plateformes avec processeurs ARM. Le fournisseur de cloud a par ailleurs indiqué que ses serveurs ARM offraient d’ores et déjà un gain de plus de 40% en exploitation que leurs équivalents x86 (consommation, refroidissement) et qu’il répercutaient une grosse partie de ces économies sur la facture. Que l’on soit clair, un processeur ARM qui exécute une workload exigeant consommera autant que son homologue x86, la différence c’est qu’en idle ou pour des petites tâches, ces processeurs consomment beaucoup moins ! Pour résumer, le CAPEX est globalement identique, l’OPEX est de beaucoup réduit.

Il n’y a plus de mystère aujourd’hui : le portage des vib NSX-T est lui aussi en cours sur plateforme ARM ! De quoi envisager d’utiliser la brique SDN pour assurer des migrations seamless entre du OnPrem et du Cloud. Cela va permettre aussi d’assurer des niveaux de sécurité très élevé dont l’IoT a cruellement besoin aujourd’hui (vous avez vérifié que votre petite webcam pour surveiller votre chien quand vous n’êtes pas là n’est pas déjà pourrie de malwares ?.. ^^). Enfin, cela résonne aussi quand on se rappelle de la stratégie affichée de VMware en matière de gestion “totale” de la sécurité (voir mon billet sur la General Session de Mardi matin).

Le fait même qu’Amazon se lance commercialement dans ce segment est preuve qu’une forme de masse critique est atteinte et que l’hégémonie de x86 est comptée, y compris dans nos propres datacenters, à moyen terme.

VSAN

La couche VSAN est désormais totalement fonctionnelle sur ARM aussi, autorisant des clusters de stockage classique tirant parti des gain importants en terme de consommation. Un des débouché envisagé est précisément de proposer des “baies de stockage” basées sur VSAN en interne, pourquoi pas, que l’on viendrai consommer tout en faisant des économies d’énergie. Sans rentrer dans le green bashing, plusieurs dizaines de pourcents de gain annoncé est loin d’être anodin et on ne peut désormais plus l’ignorer aujourd’hui.

De la smart NIC au futur du DataCenter

Régis m’a également montré ce qui semble être au premier abord plus une curiosité qu’autre chose… sauf que non, pas du tout en fait. ESXi a également été installé sur les nouvelles “smart NIC”. Vous avez sans doute entendu parler de ces nouvelles “cartes réseau intelligentes” capables de réaliser une grande partie des tâches dévolues au départ au stack TCP/IP des OS/Hyperviseurs. Ces cartes qui coutent encore très cher, disposent en fait de caractéristiques digne d’ordinateurs de bureau avec pour certaines pas moins de 8 coeurs ARM et 16 Go de RAM ! Autant dire que ESXi ARM fonctionne parfaitement sur ces cartes.

Mais alors, pourquoi diable installer un ESXi dans une carte réseau ? Certes, on imagine facilement qu’on pourrait faire tourner un stack NSX-T complet sur ces composants et décharger du même coup les processeurs centraux du serveur. Mais la démarche va plus loin. En fait, VMware imagine tout simplement de faire tourner tout l’hyperviseur (et ses services d’administration) sur ces cartes et dédier à 100% les CPUs x86 pour … juste faire tourner de la VM. Quasiment plus d’overhead et une banalisation de la “fonction processeur” tout comme le stockage ou le réseau aujourd’hui.

Si on y ajoute les progrès et annonces récents de nombreux constructeurs vis à vis de la pMEM (persistant memory) et son adoption progressive et inéluctable dans les prochaines années (tout comme les SSD à leur époque), mais aussi les nouveautés comme VMware Bitfusion, proposant des service de GPGPU à la demande via un jeu d’API sur le réseau, on arrive à une conclusion assez folle.

Le futur datacenter ne sera plus constitué d’un ensemble de serveurs comme aujourd’hui, vous aurez au contraire des appliances dédiées hébergeant chacune des ressources matérielles disponibles et consommables à la demande en fonction de vos besoin : des appliances de compute avec des dizaines de processeurs x86 prêts à être “livrés”, des appliances de mémoire pour la mémoire vive et persistante, des boites de GPGPU fournissant à qui le souhaite des ressources de calcul spécifiques, un réseau ultra performant au centre … et un grand orchestrateur assurant la production de conteneurs hardware complets, malléables et dynamiques. Ca ne vous rappelle rien ?

Nous allons tout simplement appliquer les principes même de la virtualisation, mais avec du hardware. Fascinant, et tellement geek !

Et alors, quand ça sort !?

J’ai une grosse annonce à vous faire : je sais exactement à partir de quand ça sortira. Plus exactement, et passé cette blague facile, le fait est que certaines choses sont claires. ESXi ARM est développé actuellement à partir de la branche principale de ESXi 7.0 encore en bêta. A partir du moment ou cette version sera G.A., VMware mettra à disposition un Fling spécifique contenant les bits de ESXi ARM. Vous pourrez donc le télécharger et faire ce que vous voulez avec, sans support bien sûr.

Ce sera un très bon moyen de voir ce qu’une communauté aussi active que celle de VMware aujourd’hui est capable de faire en terme de use case, de développement de drivers ou même d’intégration avec une telle pépite … j’ai hâte d’y être.

Enfin, et pour donner encore plus de perspective à ce projet, le plus dur dans un produit qu’on souhaite adapter à une autre plateforme que celle sur lequel il a été conçu au départ, c’est le premier portage. Les suivants éventuels seront une promenade de santé pour les développeurs. Comme toujours, c’est le premier pas qui coûte. Même si cette voix “ARM” ne devait pas déboucher sur une commercialisation, nul doute que tout le travail réalisée lors de cette phase servira forcément à VMware pour l’avenir, notamment pourquoi pas autour des plateforme Open Hardware qui fleurissent aujourd’hui sur le Net.

Encore une fois un immense merci à Régis, que j’espère retrouver l’année prochaine pour continuer ce voyage !