¶ Introduction
Cette documentation a pour but de présenter le concept de "Virtual Volumes" aussi communément appelés "vvols".
Les "vvols" peuvent être considérés comme une sorte d'évolution ou de nouvelle génération du stockage de vSphere.
¶ Introduction aux vvols
Précédemment nous nous sommes familiarisé avec le stockage VMFS, les Datastores, les Datastores NFS, vSAN, etc.
Les "vvols" représentent une sorte d'évolution, de nouvelle étape dans le stockage, d'autant plus qu'ils prennent en compte une grande partie des architectures de stockage existantes.
Ils sont également compatibles avec la plupart des type de réseaux de stockage déjà existant tels que l'ISCSi, le Fiber Channel ou NFS par exemple.
Mais la plus grande différence avec ce que nous avons précédemment pu voir ensemble vient du fait que les objets de nos machines virtuels sont directement exposés à la baie de stockage.
Faisons une petite pause et réfléchissons à la manière dont le stockage fonctionne actuellement, c'est à dire sans les "vvols".
Ce que nous avons et utilisons ce sont des Datastores VMFS. Il s'agit d'un file system dont le formatage a été effectué par un ESXi.
Le problème que l'on peut rencontrer lorsqu'on utilise des Datastores formatés en VMFS c'est que l'on créé un file system que la baie de stockage ne comprend pas.
Elle n'est pas en mesure de creuser à l'intérieur de ce file system VMFS afin de visualiser les objets individuels des VMs.
La plus grande différence entre les "vvols" et l'architecture traditionnelle avec des LUN et du VMFS vient du fait que grâce aux "vvols" nous pouvons gérer les objets des VMS directement au niveau de la baie de stockage.
Cela rend des choses telles que le clonage de VMs ou les snapshots totalement différentes de ce qu'elles ne sont traditionnellement avec un datastore VMFS.
¶ Storage Container (Conteneur de stockage)
Avec une architecture de stockage de données traditionnelle nous disposons donc de LUNs.
Puis sur ces LUNs nous allons créer des Datastores VMFS.
Prenons le schéma suivant comme exemple. Nous avons deux LUNs et sur chacun d'entre eux nous avons créé un Datastore dans lequel nous pouvons stocker tous les objets de nos machines virtuelles.
Avec les "vvols" le concept de LUNs et de Datastores disparaît totalement.
Dans le cas d'une utilisation de "vvols", nous allons créer un nouvel objet appelé "Storage Container" (ou Conteneur de stockage en français).
Tous nos "Virtual Volumes", nos "vvols", seront stockées dans ce "Storage Container".
De plus, ce "Storage Container" n'a pas les limites traditionnelles d'un LUN.
En effet, la seule restriction sera la capacité maximale de stockage physique de la baie.
Mais alors, on peut se demander si les Datastores existent toujours dans le cas d'utilisation de "Virual Volumes".
Et bien techniquement oui, mais le Datastore n'est présent que pour des fonctionnalités telles la haute disponibilité de Datastores et d'autres choses de ce genre par exemple.
En utilisant des "Virual Volumes", ce qui va réellement se passer c'est que nous aurons un "Storage Container" sur notre baie de stockage qui permettra à celle-ci d'avoir une visibilité sur l'ensemble des objets des machines virtuelles qui s'y trouveront.
¶ Protocol Endpoint
Notre "Storage Container" est donc l'endroit où se trouvent tous nos volumes virtuels.
Comme nos VMs fonctionnent toujours de la même manière, elles ont donc besoin d'envoyer des commandes SCSI à leurs disques virtuels.
Pour que cela puisse fonctionner nous aurons ce que l'on appelle le "Protocol Endpoint".
Il servira d'interface avec le "Storage Container" et gèrera tout le trafic.
Notre ESXi ne se préoccupera donc pas du "Storage Container", de sa taille ou même s'il en existe plusieurs.
La seule chose qui lui sera nécessaire sera le "Protocol Endpoint" puisqu'il servira d'interface avec le "Storage Container".
Ainsi, lorsque notre machine virtuelle émettra une commande SCSI, cette commande sera émise par le contrôleur SCSI virtuel de la VM puis l'hyperviseur l'enverra vers l'adaptateur de stockage approprié qui lui même l'enverra vers le "Protocol Endpoint" du "Storage Container" et pour finir les données seront écrites sur le "Virual Volumes".
Voici donc par exemple quelques mécanismes de fonctionnement lorsque l'on utilise des "Virual Volumes".
Mais quels en sont les avantages ?
Je ne peux pas tous les citer mais imaginons que nous ayons besoin de cloner une VM.
Nous avons le compute de notre VM sur notre ESXi et le "vvol" dans le "Storage Container" sur la baie de stockage.
Plutôt que de gérer l'opération de clonage au niveau de l'hôte ESXi, nous pouvons le faire directement au niveau du "Storage Container" depuis la baie de stockage puisqu'elle peut voir l'ensemble des "vvol" contenus dans le "Storage Container".
Ce qui est beaucoup plus efficace en terme de performances.
En effet dans le cas d'un clonage effectué depuis l'ESXi, toutes les données de la VM doivent être transférées vers l'ESXi, puis une copie doit être renvoyée vers la baie de stockage.
Avec des "vvols", à la place de ce type de clonage traditionnel, on pourrait demander à vCenter d'envoyer une commande à la baie de stockage pour qu'elle effectue un clone ou même un snapshot d'un "Virual Volumes" ciblé.
Dans ce cas la baie de stockage prendra en charge elle même la charge de travail sans avoir à transmettre les données de la VM sur le réseau.
Nous pourrions ainsi déléguer cette tâche à la baie de stockage.
Evidemment il existe bien d'autres avantages aux "vvols" mais il est important de retenir que les "Virual Volumes" permettent de réaliser de gros gains d'efficacité et de performances sur certaines tâches.
C'est la raison pour laquelle ils représentent une sorte de nouvelle génération du stockage de vSphere et trouveront leur place dans de nombreuses infrastructures.
Chapitre précédent : 16 - vSAN Disk Groups - Chapitre suivant : 18 - Configuration du réseau vSAN : Démonstration