Les fondamentaux de VMware vSAN

Avant de commencer par définir vSAN, il est essentiel d’expliquer quelques terminologies pour éviter toute confusion. Nous allons donc commencer par expliquer ce que le Software Defined Storage.

Le Software Defined Storage est l’automatisation et la mise en place du stockage à travers une application de contrôle qui a la capacité de fournir du stockage à partir de nœud de serveur. Ceci est une simplification significative à la façon dont le stockage est approvisionné et gérer, et permet la réduction des coûts.

Les produits Software Defined Storage sont des solutions qui permettent l’abstraction matérielle et de facilement approvisionner les ressources et de les présenter aux consommateurs en utilisant une interface graphique (UI) et une interface de programmation (API). Elle permet également le scale-in (expansion des ressources matérielle du nœud avec des disques dur par exemple) et scale-out (expansion du cluster en ajoutant des nœuds entier) sans effort opérationnel considérable.

La différence qui existe entre les solutions SDS et HCI (Hyperconvergés) sont le niveau d’intégration avec la plateforme sur laquelle elle est exécuté et le modèle de livraison d’où on en distingue 2 : livraison basée sur des appliances ou la livraison du software uniquement.

La stratégie de VMware concernant le SDS est de se focaliser sur ses initiatives reliées au stockage local, stockage partagé et de faire de vSphere la plateforme de service de stockage.

Par le passé, le stockage était configuré et déployé au début de chaque projet sans aucun changement durant son cycle de vie. Des LUN ou des volumes sont créés pour stocker les VMs. Dans certains cas, des changements des caractéristiques du stockage peuvent être demandé. Dans ce cas, il suffisait de supprimer et recréer le LUN ou le volume. Ceci est une opération risquée, qui demande des efforts opérationnels considérable due à la migration des VMs entre les LUNs et les volumes qui peuvent prendre des semaines de coordination.

Avec le SDS, le besoin en stockage des VMs peuvent être dynamiquement instancié. On peut maintenant se passer des LUN et des Volume. La charge des VMs et de leurs besoins changent continuellement et le stockage peut désormais s’adapter à cette charge à n’importe quel moment.

Et vSAN dans tout ça ?

vSAN est une solution VMware sorti en bêta en 2013 et disponible au grand public en Mars 2014. vSAN est complétement intégré avec VMware vSphere et supporte les fonctionnalités Core tel que HA, DRS et vMotion. C’est un système de stockage basé sur des objets qui permet de simplifier la décision de placement des VMs en utilisant les Storage Policy Based Management (SPBM).

vSAN vise à fournir un service de stockage et un niveau de service automatisé à travers la couche software depuis l’hôte par laquelle est intégrée et l’abstraction matérielle.

Le facteur clé du SDS est le storage-policy based management (SPBM). SPBM est le composant critique par laquelle VMware implémente le SDS. Grâce au SPBM, il est possible de créer différente règle sous forme de profil qu’on assigne directement à la VM ou aux disques virtuels. Les caractéristiques des profils se basent essentiellement sur la protection, disponibilité, performance de la VM  

Le but principal de vSAN est de fournir des fonctionnalités de résilience et d’expansion de stockage. La QoS peut également être le contexte de règle de stockage (SPBM) qui permettra de définir le niveau de performance et de disponibilité requise par VM ou même disque virtuelle.

vSAN est une solution de distribution de stockage basée sur du software intégrée directement au niveau Kernel de l’hyperviseur ESXi. Cette intégration est présente également au niveau du vCenter qui permet de gérer les SPBM mais également les différents clusters vSAN.

Les notions de base

Avant d’aller plus loin, je vais vous expliquer certaines notions qui vous aidera à comprendre la suite :

• FTT (Failure To Tolerate): Elle impose aux objets de stockage de tolérer au moins « n » panne sur le cluster. Je m’explique : Si la valeur du FTT est fixer à 1, 1 est le nombre de panne toléré (hôte, disque dur, réseaux) sans que les objets soient impactés par cette panne. Le FTT peut atteindre au maximum 3 pour le RAID 1 et 2 pour le RAID 5/6. Il est également possible de configurer un FTT à 0. Cela se traduit par aucune protection de la donnée.
• FTM (Failure Tolerance Method): Elle permet de définir le choix entre la performance et la capacité. Si vous souhaiter fournir le maximum de performance pour vos workloads, choisissez RAID1. Si la performance n’est pas vraiment le besoin principal mais plutôt l’utilisation du stockage, dans ce cas-là RAID5/6.
• Disk Group: Elle constitue la relation entre les disques de cache et de capacité. Chaque hôte dispose au minimum d’un disk group et de 5 au maximum. Chaque disk group est composé de 1 disque de cache minimum et 1 à 7 disques de capacité. Il est recommandé de configurer 2 disk group par hôte afin d’augmenter la performance et les domaines de panne et ainsi, les données ne seront pas évacuées de l’hôte source pour une reconstruction et évitant la charge sur le réseau en production. Il est à noter que si le disque cache est défaillant, le disk group devient inaccessible.
• Le tableau ci-dessous décrit les configurations possibles du FTT et du FTM

FTT	FTM	Configuration	Nombre minimum de nœud
1	RAID-5/6	RAID-5	4
1	RAID-1	RAID-1	3
2	RAID-5/6	RAID-6	6
2	RAID-1	RAID-1	5
3	RAID-1	RAID-1	7

Prérequis vSAN

Comme précédemment mentionné, vSAN est intégré au Kernel de l’hyperviseur ESXi et la gestion vSAN se fait à partir de vSphere. Donc aucune installation software n’est nécessaire. Il suffit tout simplement de remplir les prérequis ci-dessous avant de procéder à l’activation de vSAN depuis l’interface vSphere :

• Un minimum de 3 hôtes pour un déploiement datacenter standard (recommandé 4 pour les tâches de maintenance). Un minimum de 2 hôtes et un Witness dans le cas de petit déploiement tel que remote office/branch office. J’ai déjà publié un article en ce sens (voir l’article)
• VMware vCenter version 6.0 minimum. La version du vCenter doit être supérieur ou égale aux ESXi
• Au moins un disque de capacité tier de type magnétique qui contribuera à la formation du vSAN Datastore sur une configuration hybride d’un disque flash pour constituer le vSAN DataStore de la configuration All-Flash.
• Au moins un disque flash pour le cache tier qui jouera le rôle d’accélérateur en lecture et écriture des données. Sa capacité n’est pas incluse au vSAN DataStore. Seuls les disques de capacité constituent le vSAN Datastore.
• L’emplacement pour installer l’hyperviseur ESXi. Il peut être installé sur USB, SD Card, SATADOM ou disque local. Cependant, il est essentiel de prendre en considération la taille du core dump lors du choix du type de stockage et de sa capacité sur laquelle vous allez placer l’hyperviseur. Plus de détails sur la base de connaissance VMware 2147881.
• Un contrôle de disque. Le mode JBOD/Passthrough est recommandé. Les contrôleur RAID fonctionne également mais demandera plus de maintenance opérationnelle : Configuration de chaque disque en RAID 0, maintenance manuelle en cas de panne et remplacement de disque.
• Un port dédié pour le vSAN kernel. 1Gb est supporté pour les petits déploiement de type hybride mais pas sur la configuration All-Flash. 10Gb supporté pour la configuration All-Flash et recommandé car il n’est pas nécessaire de dédier le port entier pour vSAN, mais peut être partagé avec les autres flux tel que le trafic management, vMotion. vSAN est également supporté pour les adaptateur de 25Gb et 40Gb ce qui permet de réduire encore plus la latence.
• Un minimum de mémoire par hôte. Plus de détails sur la base de connaissance 2113954
• Aucune configuration n’est requise pour la partie switching étant donné qu’avant la version vSAN 6.6, il était indispensable de configurer Internet Group Management Protocol (IGMP) et le Protocol Independent Multicast (PIM) pour le Multicast. Depuis, vSAN utilise unicast et aucune configuration n’est requise.
• L’ensemble des composants vSAN doit respecter la matrice de compatibilité HCL VMware vSAN.( https://www.vmware.com/resources/compatibility/search.php?deviceCategory=vsanio)

Architecture vSAN

vSAN est capable de fournir des VMs performante et hautement disponible à travers l’utilisation du RAID distribué ou autrement dit le RAID à travers le réseaux. Du point de vue disponibilité, le RAID distribué signifie simplement que l’environnement vSAN est capable de supporter la défaillance d’un ou plusieurs hôtes ESXi ou un des composants de l’hôte tel qu’un disque ou une carte réseau, et continue à fournir une fonctionnalité complète des VMs. Pour cela, le RAID distribué de vSAN offre la possibilité de diviser les composants des VMs à travers plusieurs nœuds et disques.

Nous allons prendre un exemple très simple par lequel nous allons déployer une VM dont le nombre de FTT est égal à 1. On souhaite utiliser le RAID 1, pour des raisons de performance. Dans ce cas, 2 copies de la VM seront créées et chaque copie sera hébergée sur chaque nœud. Par contre, avec 2 copies, il n’y a aucune façon de différencier entre la panne du nœud ou un problème réseau. C’est là où intervient le Witness. Le Witness ne contient que des Metadatas et sa taille est de 16 Mega. C’est un composant lié à la VM qui permet à vSAN de déterminer qui devrait en devenir le propriétaire en cas de défaillance. Pour qu’une copie soit disponible, vSAN doit être capable d’accéder à plus de 50% des objets de cette copie. Explication: En absence du Witness, chaque copie représente 50% de vote, et donc pas suffisant à vSAN pour accéder aux objets. Si on ajoute le Witness, les 2 copies et le Witness représente chacune 33% de disponibilité. Si la première copie est inaccessible, le taux d’accessibilité devient donc 66% (33% deuxième copie + 33% Witness) et ce taux de disponibilité est suffisamment nécessaire pour permettre à vSAN d’accéder aux objets du réplica.

Pour q’un objet vSAN soit disponible, il faudrait répondre aux conditions suivantes:

• RAID1: au moins une copie doit être intacte pour être entièrement disponible. Il faut considérer le double de la capacité pour un RAID1/FTT1, le triple pour un RAID1/FTT2 et x4 pour un RAID1/FTT3. Par exemple, pour protéger une VM de 100Gb, 200Gb sont utiles pour une configuration FTT1.

• RAID5: 3 des 4 composants doivent être intacte et faudrait considérer une capacité de 133%. Exemple, pour protéger une VM de 100Gb en RAID5/FTT1, 133Gb seront utiles.

• RAID 6: 4 composants sur 6 doivent être intacte et tenir compte de 150% de capacité. Exemple, pour une VM de 100Gb en RAID6/FTT2, 150Gb seront nécessaire pour garantir la disponibilité des objets en RAID6.

Vous trouverez ci-dessous une vidéo récapitulative des différentes architectures RAID1, RAID5 et RAID6 et aussi une explication détaillée de l’architecture Stretched Cluster et de ses composants:

Installation de vSAN

Maintenant que nous avons compris l’aspect théorique de vSAN, passons à la partie la plus amusante « la pratique ». Sur la vidéo qui suit, j’ai procédé à l’installation d’un Lab vSAN version 6.7 composé de 3x nested ESXi. Je vous présente également les prérequis matérielle et la procédure d’activation de vSAN. Let the games begin! 😊

Démonstration de la tolérance au panne de vSAN

Après avoir mis en place le Lab, nous avons l’occasion de tester vSAN et découvrir les détails du cluster. Pour ce là, j’ai créé une VM Ubuntu sur le Cluster vSAN, observer et analyser la composition des objets et leurs répartition sur le cluster et surtout surveiller le comportement de vSAN et du HA de vSphere après la perte d’un nœud de mon cluster vSAN. Je vous laisse découvrir tout cela à partir de la vidéo:

Voilà, nous avons fais le tour. J’ai essayé depuis cet article de vous fournir le maximum d’informations concernant vSAN en passant directement par l’aspect technique en me basant sur mon expérience que ce soit en avant-vente ou déploiement des vSAN Ready Node et VxRail. Comme vous l’avez remarqué, vSAN est très simple à déployer et à mettre en place et il suffit juste d’avoir un background vSphere pour réussir à la manier. J’espère que cet article vous sera d’une grande utilité et j’espère pouvoir obtenir vos feedback afin de l’améliorer ou notamment rajouter des parties qui pourront être importantes pour certains d’entre vous.