Dans cette documentation, nous allons comparer le stockage vSAN et le stockage classique avec une baie de stockage physique.
Commençons par la baie de stockage et voyons ensemble les éléments de base qui composent ce type de stockage. Cela fera une petite piqûre de rappel sur les éléments que l'on a déjà pu voir dans les chapitres précédents.
Prennons par exemple le schéma suivant.
Sur la gauche nos pouvons voir en vert notre VM.
S'agissant d'une machine virtuelle, elle ne possède pas de matériel physique.
Donc de la même manière que pour sa RAM et son CPU, cette VM ne dispose pas de matériel physique pour son stockage. A la place elle accède à une ressource partagée.
Traditionnellement pour le stockage nous avons des datastores VMFS ou même des datastores NFS.
Du point de vue de cette VM, pour fonctionner elle a besoin de "voir" le matériel de stockage physique.
Pour cela nous donnons à notre VM un contrôleur iSCSI virtuel, ce qui va nous permettre de lui faire croire qu'elle dispose d'un adapatateur de stockage physique.
Il s'agit en réalité d'un driver pour le contrôleur iSCSI virtuel.
Nous voyons donc ici le contrôleur iSCSI virtuel qui est présenté au système d'exploitation de notre VM. Grâce à lui nous arrivons à faire croire à la VM qu'elle dispose d'un matériel de stockage physique.
Puisque notre VM doit être en mesure de lire et d'écrire des données sur le disques, son système d'exploitation va alors générer des commandes SCSI.
Il s'agit de commandes de stockage qui tentent de lire et d'écrire des données sur le disque.
Donc nous avons des commandes SCSI, qui vont quitter la machine virtuelle à destination du stockage.
Lorsque ces commandes vont sortir de la VM, elles vont dans un premier temps suivre leur chemin jusqu'à l'ESXi qui sera le premier élément à réceptionner ces commandes.
L'ESXi possèdant un adaptateur de stockage physique, qui peut être par exemple un HBA Fibre Channel ou un port Ethernet, et il va pouvoir faire circuler le trafic SCSI de notre VM.
Lorsque l'ESXi réceptionne ces commandes il va les préparer pour la transmission sur le réseau physique puis les transmettre via son adaptateur de stockage sur le réseau.
Il les trasnmettra à destination du périphérique de stockage physique dédié possédant des LUNs (une baie de stockage).
Sur l'un de ces LUNs un datastore aura été créé et c'est dans ce datastore que se trouvent les différents fichiers qui composent la VM tel quel son vmdk, le fichier vmx, le vswp, etc.
Il s'agit ici évidemment d'un résumé du fonctionnement du stockage à l'aide d'une baie de stockage physique.
Nous avons donc une VM qui envoie des commandes SCSI, en lecture et/ou écriture, qui sont réceptionnées puis préparées par l'ESXi afin de les transmettre sur le réseau de stockage physique à destination d'une baie de stockage physique.
Et tout ça pour que les commandes de notre VM puissent être traitées.
L'un des grands avantages que ce type d'architecture permet c'est la mise en place d'un stockage partagé. Un stockage partagé est essentiel pour la mise en place de nombreux services indispensables pour minimiser les interruptions de services tels que la haute disponibilité, le vMotion, DRS, etc.
Prenons par exemple, dans le schéma suivant.
Dans cet exemple, nous avons une VM qui tourne sur l'ESXi 1.
Imaginons que pour des raisons de maintenance j'ai besoin d'éteindre cet ESXi, que ce soit pour faire un upgrade de RAM, régler une panne matériel ou n'importe quelle autre raison.
Cette VM est en cours d'exécution et je ne veux pas l'éteindre car il peut très bien s'agir d'une VM de prod ou d'une VM qui héberge un service essentiel à mon etreprise.
Ce que je souhaite faire par contre c'est la migrer vers un autre ESXi pendant qu'elle fonctionne encore.
Je vais donc utiliser le vMotion pour effectuer cette tâche.
Mais cette machine virtuelle doit toujours pouvoir accéder à l'ensemble de ses fichiers de configuration. Elle doit continuer d'avoir accès à son vmdk, son vswp et tous les fichiers qui sont stockés sur le datastore.
L'ensemble de ces fichiers doit continuer d'être accessible pendant le vMotion de la VM et lorsqu'elle aura migré sur l'ESXi 2.
Heureusement pour nous, dans cet exemple, nous pouvons voir que les deux ESXi ont une connexion physique avec le périphérique de sockage.
Ils ont tous les deux accès au datastore hébergeant les données de la VM.
Ainsi quel que soit l'endroit où la VM s'exécute, elle aura toujours accès à ses fichiers puisque les deux ESXi peuvent y accéder.
Nous comprennons donc mieux pourquoi l'utilisation de stockage partagé est essentiel et nécessaire pour des services tels que la haute disponibilité, le vMotion, DRS, etc.
Nous allons à présent voir en quoi le stockage vSAN est différent d'un stockage traditinnel utilisant une baie de stockage.
Dans le cas d'une utilisation de vSAN, une VM est décomposée en une série d'objets qui sont stockés localement sur le stockage physique des ESXi d'un même Cluster.
Prenons comme exemple le schéma suivant afin de mieux comprendre.
Nous pouvons voir que nous avons une VM appelée "VM1" dont le "compute" (les ressources de calcul) s'exécute sur l'ESXi appelé "ESXI1".
Cette VM est donc décomposée en une série d'objets et l'un de ces objets est son VMDK.
Il existe évidemment d'autres objets qui composent cette VM mais pour l'exemple nous allons nous concentrer sur le VMDK. Le fonctionnement sera le même pour chacun des objets.
Voici ce qui va se passer pour notre VM.
Plutôt que de créer un datastore VMFS sur un périphérique de stockage physique qui contiendra les fichiers de notre VM, nous allons à la place mettre l'objet VMDK de cette VM1 sur le stockage physique local d'un autre ESXi.
Ainsi lorsque cette VM voudra lire et écrire des données sur son disque virtuel, les commandes SCSI que son système d'exploitation enverra seront récupérées par un port VMKernel puis envoyées sur le réseau physique vers un port VMKernel d'un autre ESXi afin d'atteindre leur objet de destination qui est ici le VMDK de VM1.
C'est de cette manière que fonctionne vSAN.
Nous exploitons le stockage physique local de nos ESXi pour créer l'illusion d'un stockage partagé sur chacun d'entre eux.
Encore une fois il s'agit évidemment ici d'un résumé du fonctionnement de vSAN puisqu'il est bien plus complexe que ça.
Tous les changements effectués par notre VM, tout ce qui va se passer sur ce VMDK ne va pas se produire en réalité uniquement sur un seul ESXi.
En effet, le moindre changement sera copié sur un mirror du VMDK qui se trouve lui aussi sur un autre ESXi.
Ainsi en cas de panne de l'ESXi qui héberge le VMDk, nous ne perdrons pas les données de notre VM.
Tout comme pour l'utilisation d'une baie de stockage, si l'on regarde bien il s'agit ni plus ni moins ici d'une VM qui va envoyer des commandes de stockage SCSI qui seront interprétées par l'hyperviseur et envoyées sur le réseau physique afin d'atteindre les objets qui composent cette VM.
Dans les deux cas le système d'exploitation n'a aucune idée qu'il tourne dans une VM, que ce soit via une baie de stockage ou vSAN il "pense" avoir accès à son stockage physique.
La grosse différence avec vSAN c'est qu'au lieu d'acheter une baie de stockage physique dédiée, il nous suffira d'ajouter des disques physiques sur nos ESXi pour que vSAN les utilise sous la forme de ce que l'on appelle des groupes de disques. Et comme nous avons un réseau physique qui relie nos différents hôtes, nous disposons de toutes les fonctionnalités du stockage partagé.
Nous pourrons sans problème utiliser vMotion pour migrer le "compute" notre VM sur l'ESXi3 et grâce au réseau physique reliant l'ensemble de nos hôtes, la VM pourra toujours accéder aux objets qui la composent sur l'ESXi2.
vSAN est donc une très bonne solution puisqu'il prend en compte toutes les fonctionnalités nécessitant un stockage partagé telles que la haute disponibilité, la tolérance de panne, le DRS, etc.
Tout est pris en charge par vSAN de la même manière qu'avec une baie de stockage dédiée.
Chapitre précédent : 13 - Création d'un cluster Storage DRS (SDRS) dans vSphere 7 : Démonstration - Chapitre suivant : 15 - Introduction au vSAN