VVol : présentation et perspectives (entretien avec Veena Joshi et Karl Owen)

Suite à mon entretien avec Veena Joshi (Product Manager VVol) et Karl Owen (Specialiste de VVol sur la BU VNX), je vous propose un petit compte-rendu qui, j’espère, vous permettra de mieux appréhender le concept de VVol, vu par le prisme d’EMC, ainsi que les perspectives que l’on peut attendre d’une intégration complète de cette nouvelle fonction d’ici à quelques années.

VVol : pourquoi ?

Les deux axes majeurs qui ont présidé à la définition des Virtual Volumes sont : la granularité et l’extensibilité. En effet, aujourd’hui, lorsqu’on héberge des VM sur des datastores, on reste intrinsèquement lié à une certaine forme de mutualisation de moyens car chaque vmfs est chargé d’héberger un nombre plus ou moins important de machines. Certes il existe la possibilité de faire dans la granularité avec l’utilisation des Raw Device Mappings, mais on ajoute un niveau de lourdeur et de complexité dans le provisioning de chaque VM et qui plus est, la fonction RDM n’est finalement qu’un “workaround” pour arriver à rendre visible du stockage la ou les machines concernées. La méthode d’hébergement “mutualisé” des VM au sein d’ensemble plus important ne donne pas une granularité suffisante pour pouvoir pleinement apporter l’ensemble des fonctions disponibles sur le stockage. Enfin, la VM reste “contrainte” par les bornes supérieures que sont les tailles des datastores et leur gestion globale par vSphere. Sont extensibilité est donc liée à des paramètres externes.

L’objectif derrière cette initiative de VMWare et de ses partenaires fournisseurs de solutions de stockage, EMC en tête, est donc d’offrir “le meilleur des deux mondes” en rendant chaque VM visible du stockage sous-jacent, tout en offrant la richesse fonctionnelle que l’on connait sur vSphere. Fondamentalement, VVol repose sur la notion de “Policy based management”. Chaque provisoirement de machine se voir offrir une liste de fonctions “stockage” (niveau de RAID, type d’axes, Fast Cache, Déduplication, compression, Thin provisionning, garantie du nombre d’IOps minimum etc. …) correspondant à “une classe de service”. Une fois le choix réalisé, la VM est gérée par la baie de stockage comme un tout et stockée dans le respect de cette classe.

VVol : comment, sur quoi ?

VVol n’est possible que si vous disposez à la fois d’un stockage et d’une plateforme de virtualisation compatible avec VASA 2.0 (le jeu d’API de VMWare permettant de piloter un stockage à partir de vSphere).

Pour les environnements VNX, cette “interface VASA 2.0” sera intégrée aux flarecode des baies. Aujourd’hui, la seule baie officiellement annoncée comme compatible VVol est la VNX3200e, la seule reposant sur l’architecture “Unity”, cablée pour pouvoir maitriser cette nouvelle technologie. Il reste une inconnue concernant le support, ou non, de VVol sur la gamme VNX2 actuelle et EMC n’a pas encore tranché en interne. En effet, traditionnellement, les plateformes SAN sont capable de gérer quelques milliers de LUN. Cela ne pose aucun problème aujourd’hui pour la majorité d’entre nous. Par contre, avec VVol, on change d’ordre de grandeur étant donné le nombre potentiel de VM hébergée sur ce type de machines. Du coup, sur les plateforme existantes, les codes ne sont pas prévus nativement pour supporter des centaines de milliers d’objets et les limitations annoncées en même temps que VVol pourraient être rébarbatives pour les consommateurs que nous sommes. Quelle réaction auriez-vous si on vous disait que votre VNX2 5400 support VVol, mais seulement pour 500 VMs maximum ?

Pour les VMAX, vous devrez installer des virtual appliances pour assurer la “traduction” VASA vers VMax. Les deux approches sont totalement équivalentes fonctionnellement parlant dans la pratique.

VPLex est aussi concerné, évidemment, par cette évolution. Pas de problème a priori de ce coté mais pas non plus de visibilité claire sur les échéances (ou sous NDA …).

Enfin, concernant XtremIO, le discours d’EMC est clair : la plateforme sera, à terme, compatible avec VVol et ceci d’autant plus que la construction novatrice de cette baie est particulièrement adaptée à ce type de fonction (dixit Robin Ren, lors de mon entretien avec le management EMC d’XtremIO).

Coté vSphere, enfin, il faut attendre la sortie de vSphere 6, qui proposera nativement VASA 2.0, sans doute d’ici la rentrée à l’automne 2015.

VVol : l’approche technique

EMC fait reposer VVol sur la notion de “storage container”, une sorte de “super LUN”, qui peut lui-même être réparti/étalé sur plusieurs pools de stockage (les pools que nous connaissons aujourd’hui dans le monde VNX). Ce storage container définit l’ensemble des possibilités offerte par le stockage comme déjà évoqué (niveau de raid, fast cache, type de disques etc. …). Ensuite, lorsque vous souhaitez provisionner une nouvelle machine en Vvol, vous allez choisir le storage container correspondant à vos besoin ainsi que le niveau de service souhaité. Toutes les capacités de la baie sont remontées via l’interface VASA 2.0 et vous faites donc “votre marché” en indiquant spécifiquement, pour la VM en cours de préparation, les fonctions attendues. On retrouve ici la notion de granularité, évoqué plus haut.

Toutes les fonctions classiques comme les snapshot, les clones, les clones liés, etc. … seront automatiquement géré par la baie de stockage, tout comme le XCopy Off-load actuellement. Lorsqu’il s’agira de déménager une VM d’une baie à une autre, la fonction storage VMotion prendra le relais avec un pilotage vCenter. Il sera également possible de passer d’une VM “VVol” à une VM classique via un storage vmotion.

Aujourd’hui, la norme VASA 2.0 ne supporte pas la remontée de service de type “réplication / mirroring”. Ainsi, lors de la sortie des premières infrastructures et logiciels compatible, on ne pourra pas directement indiquer sur une VM que l’on souhaite, par exemple, une réplication via VPlex. Sur la roadmap VMWare ce type de fonction semble être prévu pour VASA 3.0, donc pas avant plusieurs années. Cela n’empêchera pas de proposer ce type de fonction de manière plus globale et “backend”, par exemple via la réplication VPlex de storage containers.

VVol : quand ?

C’est, finalement, la grande question : quand pourrons-nous commencer à évaluer VVol sur des équipements réels, quand pourrons-nous envisager de passer à VVol en production ? A toutes ces interrogations, EMC (et VMWare) nous répondent à mot couvert et en partie après avoir signé un NDA. Pour autant, il est clair que cette technologie d’avenir ne pourra se concrétiser qu’après la sortie d’une version stable et GA de vSphere 6, donc vraisemblablement pas avant le milieu de l’année prochaine. Il sera temps de revenir, à ce moment, au VMWorld 2015 par exemple, pour avoir cette fois-ci tous les détails et annonces des constructeurs qui ne manqueront pas de suivre la voie ouverte par VMWare.

Un grand merci à Veena Joshi et Karl Owen pour leur disponibilité.