VMware rachète Bitfusion pour prendre le marché de l’IA
La solution de virtualisation de GPUs FlexDirect doit permettre à vSphere de communiquer avec des clusters TensorFlow, de plus en plus populaires chez les entreprises.
VMware rachète la startup Bitfusion pour un montant inconnu, dans le but d’intégrer à vSphere la connexion vers des clusters de GPU.
« Cette acquisition va renforcer notre support des traitements de Machine Learning (...) L’intérêt de la solution de Bitfusion est de virtualiser une infrastructure de GPU pour en faire un pool de ressources accessibles en réseau, plutôt que les contraindre à des serveurs en particulier (...) Ce type de fonctionnement s’accorde avec celui des machines virtuelles et des containers qui s’exécutent indépendamment des clouds, des réseaux et des systèmes », explique Krish Prasad, le patron de l’unité Cloud Platform, chez VMware, dans un billet de blog.
Les entreprises soucieuses de déployer des services d’intelligence artificielle s’intéressent de plus en plus aux GPUs, car ils sont pris en charge par TensorFlow, le moteur Open source de Google qui fait désormais office de standard en matière de machine Learning. En revanche, pour être efficace, TensorFlow doit utiliser ses GPUs sans être étranglé par des machines virtuelles qui feraient en même temps des entrées-sorties intempestives, ce qui est le lot quotidien des clusters VMware.
En rachetant BitFusion, VMware fait donc passer le message que ses solutions, moyennant l’ajout de serveurs remplis de GPUs sur le réseau, deviennent compatibles avec TensorFlow.
Les GPU, initialement conçus pour accélérer l’affichage 3D, excellent dans les calculs mathématiques, au point de peupler à présent les supercalculateurs.
Rappelons que les GPU, initialement conçus pour accélérer l’affichage 3D, excellent dans les calculs mathématiques, au point de peupler à présent les supercalculateurs.
Un cluster de VMs relié à un cluster de GPUs virtuels en RoCE
Appelée FlexDirect, la solution de Bitfusion est constituée de deux parties. FlexDirect Server est un hyperviseur qui s’installe sur un serveur physique bardé de cartes accélératrices ; le plus souvent il s’agit de cartes graphiques vendues par NVidia ou AMD, mais des FPGAs et des ASICs seraient aussi possibles. Son rôle est de découper leur puissance totale en cartes accélératrices virtuelles, individuellement disponibles pour une machine virtuelle du réseau.
FlexDirect Client est quant à lui un bout de logiciel à installer dans chaque machine virtuelle exécutée par VMware, sur un autre serveur physique. Il s’agit d’un pilote qui relie la VM à l’un des GPU virtuels exposés par FlexDirect Server, en lui faisant croire qu’il s’agit d’une carte d’extension interne.
La connexion entre le serveur rempli de GPUs et celui qui exécute les VMs peut-être un simple réseau TCP/IP. Néanmoins, BitFusion recommande d’utiliser des cartes réseau et des switches de type RoCE (RDMA over Converged Ethernet) pour éviter de perdre le bénéfice des GPUs en latence réseau. Les équipements RoCE, qui présentent l’intérêt d’éliminer les couches protocolaires, accélèrent en effet les transferts en copiant directement des données depuis la mémoire des VMs.
Ce fonctionnement, plus proche d’un véritable serveur qui dialogue avec son GPU interne, n’est néanmoins possible que sur une architecture locale. Or, VMware semble avoir l’ambition de proposer une solution qui fonctionne à cheval entre deux sites, voire qui interconnecte un cluster de VMs local avec un cluster de GPUs virtuels en cloud.
Une alternative à des solutions plutôt conçues pour le VDI
Sur le segment technique de la virtualisation de GPU, Bitfusion FlexDirect est considéré comme une alternative à des solutions plutôt écrites pour le VDI, c’est-à-dire d’abord conçues pour accélérer l’affichage des postes Windows virtuels.
Jusqu’ici, vSphere avait deux possibilités pour utiliser des GPU. Son propre module interne VMDirectPath I/O permet d’associer, au sein d’un même serveur hôte, une ou plusieurs cartes graphiques à une VM en particulier. Cette solution, la plus simple, présente l’inconvénient qu’aucune autre VM ne peut utiliser le GPU déjà pris. Pire, la VM intrinsèquement liée à des matériels ne peut plus être migrée à chaud, via la fonction vMotion, vers un autre serveur en cas d’incident. Sur le terrain, utiliser VMDirectPath I/O conjointement à un GPU (il peut servir à lier une VM à n’importe quelle autre ressource matérielle) est surtout destiné à proposer aux utilisateurs une station graphique utilisable à distance.
L’autre solution est Nvidia Quadro Virtual Data Center Workstation, plus connue sous le nom raccourci de Nvidia Grid. Il s’agit d’une option de NVidia spécifiquement conçue pour vSphere et qui permet de découper la puissance de traitement d’un GPU entre plusieurs machines virtuelles. Comme cette solution repose sur des pilotes à installer dans les VMs pour dialoguer avec un module au niveau de l’hyperviseur, les machines deviennent transférables via vMotion vers un autre serveur. Pour peu, évidemment qu’il dispose lui aussi de NVidia Grid. Cette solution est fréquemment rencontrée pour accélérer l’affichage des bureaux virtuels Windows.
VMDirectPath I/O et Nvidia Grid sont tous deux utilisables pour exploiter des GPU dans les calculs scientifiques. Néanmoins, ils sont limités par le nombre de cartes insérables dans des nœuds serveurs qui ont été achetées pour virtualiser des serveurs applicatifs, c’est-à-dire insuffisants pour exécuter un ambitieux moteur de Machine Learning, comme TensorFlow.
