Avec VSAN 6.2, VMware reboote sa stratégie dans l’hyperconvergé

Virtual SAN 6.2 : déduplication, compression et qualité de service au programme

Virtual SAN (vSAN) a fait ses premiers débuts commerciaux au printemps 2014, avant de connaitre plusieurs améliorations majeures notamment lors du lancement de la seconde mouture du logiciel, rebaptisée VSAN 6.0. Cette technologie de stockage logicielle, qui s’intègre dans l’hyperviseur maison vSphere, permet de s'appuyer sur les SSD et disques dur intégrés dans les serveurs pour fournir un stockage distribué performant pour les machines virtuelles et donc de se passer d’une baie de stockage externe.

La nouvelle version 6.2 de Virtual SAN apporte le support de la déduplication inline, de la compression et de l’erasure coding. Toutefois ces nouvelles capacités ne sont disponibles que dans les environnements 100 % Flash et non sur les configurations hybrides jusqu’alors poussée par l’éditeur. Ce choix est logique d'un point de vue technique, mais il promet quelques opérations fastidieuses pour les clients existant de la technologie, puisqu’il leur faudra remplacer des disques traditionnels par des SSD, s’ils veulent profiter à plein des nouvelles capacités du logiciel.

Virtual SAN 6.2 apporte aussi la gestion de la qualité de service (via un mécanisme de garantie et/ou de plafonnement du nombre d’IOPS), une capacité exposée au niveau VMDK via les mécanismes de gestion de politiques de vSphere. Le logiciel s'enrichit aussi de nouvelles capacités visant à faciliter le monitoring et la supervision de son fonctionnement.

Selon VMware, les innovations embarquées dans Virtual SAN 6.2 devraient permettre d'abaisser les coûts du Gigaoctet 100 % Flash fourni par vSAN sous la barre du dollar. L’éditeur ne précise toutefois pas si ce prix a été obtenu en combinant déduplication, compression et erasure coding ou simplement avec les deux premières technologies.

L’utilisation de l’erasure coding, si elle permet de gains significatifs en matière de capacité par rapport au Raid-1, a en effet un impact sur les performances en écriture (et aussi sur les performances en lecture en cas de dégradation du cluster). Mais elle apporte aussi des contraintes additionnelles. Pour une configuration de type Raid-5 (3 fragments de données et un fragment de parité), il faut en effet au minimum 4 nœuds et il faut prévoir un minimum de 6 nœuds pour les configurations de type Raid 6 (4 fragments de données et 2 de parité). Ces minimums permettent à la fois de se protéger contre les défaillances de disques et contre les défaillances de nœuds.

L’échec d’EVO:Rail amène VMware à recentrer sa stratégie hyperconvergée autour de vSAN

Disponible via une licence séparée de celle de l’hyperviseur vSphere, Virtual SAN permet aux entreprises qui le souhaitent d’opter pour une approche de stockage hyperconvergée sur leurs clusters de serveurs vSphere. Mais il leur faut pour cela s’assurer que leurs serveurs respectent scrupuleusement les prérequis d’installation et réaliser eux-mêmes l’intégration et le paramétrage des différents composants logiciels.

Afin de contrer Nutanix et Simplivity, VMware avait donc décidé au printemps 2015 de dévoiler EVO:Rail, une solution pré-intégrée et préconfigurée commercialisée via un nombre limité de constructeurs partenaires. L’idée était qu’en fournissant un accès simplifié à sa technologie via une solution intégrée, les entreprises opteraient plus facilement pour le couple vSphere/VSAN que pour les solutions alternatives proposées par Nutanix ou Simplivity.

Problème, EVO:Rail a été lancé en décalage de phase avec des versions anciennes de vSphere et de VSAN alors que l’éditeur dévoilait quelques mois plus tard de nouvelles moutures de ses technologies. Pire, VMware a imposé un vrai diktat à ses partenaires constructeurs, allant jusqu’à spécifier le facteur de forme des serveurs pour Evo:Rail, ainsi que le nombre de disques, la mémoire vive ou les configurations CPU. Pour le soldat EVO:Rail, aucune tête ne devait dépasser.

Enfin, l’éditeur a commis la lourde erreur de ne pas permettre initialement à ses clients d’utiliser leurs licences existantes de vSphere dans EVO:Rail (alors qu’ironiquement, les clients peuvent réutiliser leurs licences vSphere dans les appliances de Nutanix et Simplivity), ce qui a rendu la solution très coûteuse (environ 120 K€ pour une configuration basique avec 4 nœuds serveurs).

Dans la pratique, ces erreurs, ou péchés d’arrogance – c’est ainsi que plusieurs constructeurs plutôt remontés contre l’attitude de VMware nous ont présenté la chose - ont torpillé le lancement d’EVO:Rail. Et la version 2.0 de la solution, lancée à VMworld San Francisco, n’a jamais réussi à redresser la barre. Lors d'un entretien avec Le MagIT, Bryan Evans, l'un des responsables de l'offre EVO:Rail avait admis les déconvenues de l'éditeur avec la solution, mais aussi commencé à laisser entrevoir l'avenir, à savoir un accent croissant mis sur VSAN.

Car d’une certaine façon, l’échec d’EVO:Rail a, masqué le succès croissant de VSAN. Car pendant qu’EVO:Rail buvait la tasse, VSAN, lui, rencontrait un certain succès. Selon l’éditeur, près de 3 000 clients utiliseraient aujourd’hui  la technologie de stockage maison sur tout ou partie de leurs clusters (20.000 licences du logiciel auraient été vendues durant le seul dernier trimestre 2015). Le logiciel aurait généré l’an passé un CA de près de 100 M$ pour l’éditeur. VMware a donc décidé de mettre en sourdine EVO:Rail pour rebooter son discours dans l’hyperconvergé autour de Virtual SAN.

VMware laisse désormais les constructeurs libres de leurs configurations

Comme l’explique Stéphane Croix de VMware, l’éditeur considère une offre comme hyperconvergée lorsqu’elle intègre a minima les trois solutions maison : vSphere, vCenter et Virtual SAN. Et il n’est plus question de passer sous les fourches caudines de l’éditeur pour valider une appliance prédéfinie. Là ou auparavant, VMware définissait les tables de la loi avec EVO:Rail, on ne parle plus que d’une certification a minima, baptisée VSAN Ready Nodes. Selon l’éditeur, près d’une centaine de configurations seraient aujourd’hui certifiées, contre cinq pour EVO:Rail.

Mieux, VMware laisse les constructeurs libres d’installer les 3 briques (vSphere, vCenter et Virtual SAN) à leur façon et d’ajouter les logiciels de configuration ou de management qu’ils souhaitent. La partie support est libre (elle peut être assumée à 100 % par le constructeur pour la partie logicielle et matérielle ou répartie entre VMware et le constructeur selon que le support porte sur le logiciel ou le matériel) et la partie licence est flexible (entendez par là qu’un client qui a déjà des licences vSphere peut les utiliser pour les appliances vSphere Ready Nodes).

EVO:Rail bouge encore, mais quid de EVO:SDDC ?

EVO:Rail n’est pas tout à fait mort pour autant. Le code de l’outil de configuration et de management qui avait été développé spécifiquement par l’éditeur est toujours disponible pour les constructeurs qui souhaiteraient l’utiliser afin de concevoir des appliances.

Notons que pour l’instant, on est sans nouvelle d’EVO:SDDC, la solution hyperconvergée haut de gamme que VMware a présenté à VMworld San Francisco et que l’éditeur espérait dévoiler au premier trimestre 2016. Selon Stéphane Croix, « le développement d’EVO:SDDC se poursuit ». Il permettra d’offrir une solution hyperconvergée encore plus ambitieuse puisque selon lui « la solution intégrera NSX pour la virtualisation du réseau et vRealize pour la gestion des opérations et le portail self service ».  

En toute logique, EVO:SDDC devrait être l’alternative proposée par VMware aux appliances Azure Stack de Microsoft. Avec un objectif somme toute assez similaire : offrir une solution de cloud privé prête à l’emploi, qui soit aussi une passerelle vers le cloud public de la fédération EMC.