Les architectures ARM s'émancipent et visent désormais les ordinateurs et autres serveurs, en plus des appareils mobiles. Après plusieurs essais ratés par le passé, les planètes semblent alignées pour une issue positive. VMware en profite pour adapter son hyperviseur ESXi, avec plusieurs idées en tête.
En février 2020, VMware annonçait le lancement d'un nouveau projet : le portage de son hyperviseur ESXi afin qu'il supporte différentes plateformes ARM. Un travail de longue haleine du fait de l'éclatement de cet écosystème, mais nécessaire puisque ces architectures bénéficiaient de nouveaux soutiens dans les serveurs.
ARM dans les serveurs : cette fois, c'est la bonne ?
Après le raté de Marvell et ses ThunderX, plus personne n'y croyait mais Amazon Web Services (AWS) et ses Graviton ont donné un signe positif au marché. En annonçant vouloir migrer tous ses Mac vers ses propres SoC ARM, Apple a fait beaucoup pour mettre en lumière la capacité de telles puces à être performantes et économes.
Il y a également la montée en puissance d'Ampere Computing et ses Altra ou le rachat de Nuvia par Qualcomm. Mais le plus gros coup de pouce est sans doute la décision de NVIDIA de se payer ARM pour 40 milliards de dollars, la société travaillant à ses propres CPU pour serveur, fédérant l'écosystème contre Intel, kit de développement à l'appui.
Voyant ces différentes initiatives fleurir ou émerger l'année dernière, VMware s'est sans doute dit qu'il s'agissait du bon moment pour sauter le pas. D'autant que le support d'ARM sous Linux est désormais plutôt bon, Marvell s'étant chargé d'une partie du travail, ses remplaçants, la fondation Raspberry Pi et la communauté faisant le reste.
Nom de code du projet : ptarmigan (lagopède). Les premiers mois, la société a surtout travaillé sur le développement des éléments de base, communicant sur les grandes lignes de sa stratégie de conférences en conférences. En septembre dernier, on avait droit à un nouveau logo. En octobre à une première version.
Depuis, elle a bien évolué, s'étendant aujourd'hui à de nouvelles plateformes.
Derrière ESXi pour ARM, le projet Monterey
Mais n'allez pas croire que la volonté de VMware est avant tout de proposer aux adeptes de Raspberry Pi et autres Micro PC d'utiliser son hyperviseur phare. Ces machines sont assez peu puissantes et même s'il peut être intéressant de virtualiser pour les gérer autrement et accéder à certaines distributions, l'objectif est ailleurs.
La robotique ? Pourquoi pas. Les serveurs ? Oui, mais pas forcément comme vous l'entendez. Certes, VMware veut une version pour ceux qui utiliseront des machines avec de gros CPU ARM, comme les Altra d'Ampere Computing. Mais il y a une autre classe de produits qui l'intéresse plus particulièrement, les SmartNIC.
Pour rappel, il en exite de différents types, NVIDIA proposant notamment ses Data Processing Unit (DPU), avec comme argument clé la promesse de disposer d'une « Datacenter Infrastructure-on-a-chip ».
Sur ces cartes de la gamme BlueField, outre les ports réseau et le contrôleur Mellanox, on retrouve un SoC ARM et des connecteurs pour du stockage. Mais surtout divers accélérateurs, notamment pour le traitement des données et la sécurité, parfois un GPU (série X). Une feuille de route complète est prévue pour les prochaines années, BlueField 2 commençant à arriver chez les intégrateurs, les versions 2X, 3(X) et 4 étant déjà sur la rampe.
Ces produits, que NVIDIA veut démocratiser rapidement pour se faire une place de choix dans les infrastructures, peuvent être utilisés pour effectuer différents traitements sur les données qui transitent par la carte réseau, pour la sécurité des flux ou la reconnaissance visuelle par exemple, sans jamais avoir à solliciter le processeur central. Il peut ainsi s'acquitter d'autres tâches, tout se fait au sein du DPU.
C'est là que le projet Monterey entre en scène chez VMware. Car l'objectif est de déporter sur le SmartNIC/DPU toute la couche de gestion de l'hyperviseur (VMM), en plus de la gestion du stockage, du réseau et de la sécurité. Le système boote alors depuis sa carte réseau, qui dispose d'une interface de gestion réseau dédiée.
Ainsi, dans un serveur avec deux CPU et une telle carte, plus besoin de réserver certains cœurs à la gestion des machines virtuelles ou même de conteneurs. Une situation presque idyllique pour certains acteurs tels que les fournisseurs de services cloud (CSP) pour qui l'intérêt direct est plus qu'évident.
Intel veut d'ailleurs aller dans le même sens avec l'évolution de ses SmartNIC en IPU (Infrastructure Processing Unit), un changement stratégique dévoilé il y a quelques jours. Bien entendu, tous ces acteurs visent également des usages plus classiques de traitement des flux réseau sans passer par le CPU, de Software Defined Network (SDN), etc.
VMware ESXi sur ARM
Problème : VMware n'existe pas sur ARM, et pour développer une telle solution il n'est pas forcément aisé de se reposer sur les SmartNIC et autres DPU qui ne sont pas forcément accessibles au plus grand nombre. Il fallait donc étendre le spectre pour s'assurer d'une base assez large d'utilisateurs à fédérer autour de ptarmigan.
Outre les travaux en cours avec Intel autour de ses produits, ceux sur base de Xeon notamment, VMware a donc opté pour une stratégie visant à développer d'abord pour des micro PC à large audience et autres serveurs ARM. Ainsi, les premiers systèmes supportés par ptarmigan étaient :
- Ampere Computing eMAG 8180 (Avantek, Lenovo, …)
- NXP LayerScape LX2160A-powered SolidRun HoneyComb
- NXP LayerScape LS1046A-powered NXP FRWY
- Raspberry Pi 4B (4 Go et 8 Go)
Certaines fonctionnalités de base sont bien entendu présentes, comme le support des stockages réseau via iSCSI, l'équipe ayant raconté depuis comment le support des Raspberry Pi avait commencé avec un thread Twitter. Elle a aussi mis en place de premiers pilotes pour récupérer la température du système par exemple.
Une version 1.1 a rapidement été mise en ligne, suivie de moutures 1.2 (novembre) et 1.3 (avril) aux améliorations utiles, mais mineures (et le support d'Altra 1P). Il y a quelques jours, la 1.4 était annoncée, avec là aussi des correctifs mais surtout le support de nouvelles plateformes, à un stade expérimental pour le moment : les serveurs à deux sockets pour SoC Altra d'Ampere Computing (plateforme Mt. Jade) et les Jetson Xavier AGX/NX de NVIDIA.
Les composants de la plateforme Jetson Xavier NX
Pour ce dernier, seuls quelques éléments sont fonctionnels pour le moment : les ports PCIe, USB, NVMe et SATA. Le guide d'installation précise ainsi qu'il faut utiliser un adaptateur réseau externe par exemple. Comme pour les autres machines, la procédure à suivre n'est pas forcément très simple, nécessitant pour le moment une mise à jour du firmware, un accès via la console série, nécessitant un adaptateur FTDI/USB (vendu quelques euros).
Mais on s'approche peu à peu d'une version utilisable et accessible largement. Pour le moment, aucun calendrier n'a été donné concernant l'arrivée de la version finale. Nous reviendrons prochainement dans des guides sur la manière d'utiliser VMware ESXi sur ARM, avant de pouvoir tenter notre chance avec un SmartNIC/DPU.
Commentaires (4)
#1
Quelle belle occasion de vendre plus de licences d’hyperviseur :) Ce serait dommage de passer à côté ^^
Vu la direction que prennent les KVM personnalisés, ils ont intérêt à se dépêcher s’ils ne veulent pas se faire siffler la clientèle…
#2
Ils ne faut pas oublier que tout le monde ne guide pas ses choix selon la gratuité ou non d’une solution, mais si elle répond au besoin. L’écosystème VMware répond à certains besoins, notamment de ceux qui voudront intégrer des solutions dans des SmartNIC. Après si l’on peut se contenter de KVM on a tout intérêt à le faire.
#3
Tu parles à un fan de vSphere ^^
Je dis juste qu’en faisant un hyperviseur ARM pour l’intégrer dans les SmartNIC/SmartSSD/SmartSLIPs/…, avec certainement une interconnexion Ethernet sur PCIe (un peu comme les serveurs lames), ils vont ajouter de la licence (C/G/D/I)PU.
Alors qu’ils auraient pu avoir des pilotes pour l’accès à la sous machine ARM, pour qu’elle soit programmable un peu à la sauce FPGA (mais plus poussée).
#4
Je ne comprends pas ce que tu veux dire avec la seconde partie. La demande est de déplacer le VMM dans le SmartNIC, ce n’est pas une invention de VMware pour faire de la licence, c’est un fait de marché et une demande de certains clients (voir le précédent article). Je ne vois pas ce qu’un pilote aurait pu changer à ça ?