Monter un lab vSan 6.2 sur VMware Workstation
Oui, je sais, les performances seront déplorables, mais lorsqu’on n’a pas sous la main une véritable infra vSphere pour servir de lab, VMware Workstation est une bonne alternative.
Ca permettra de démystifier un peu vSan : voir comment configurer, tester les fonctionnalités, etc…
La mémoire
Lorsque VMware Workstation est utilisé, c’est généralement sur un PC ordinaire. Et à moins d’avoir une carte récente en X99, pouvant accueillir 64 voire 128 Go de RAM, c’est probablement la mémoire qui va limiter les tests.
Un article VMware détaille la consommation mémoire de vSan : https://kb.vmware.com/kb/2113954.
En gros il faut :
– 3 Go de mémoire à l’activation de vSan
– 500 Mo de mémoire par Disk Group
– 2 Mo de mémoire si stockage HDD, ou 7 Mo de mémoire si stockage SSD, par Go de cache SSD.
Avec un Disk Group contenant un SSD de cache de 100 Go et du stockage HDD, il faudra 3,7 Go de mémoire dédié à vSan dans chaque ESXi. Et avec 3 Disk Group en Full SSD on monte à 4,2 Go par ESXi.
Et vu qu’il faut au minimum 3 ESXi (je n’aborderai pas le cas d’un cluster 2 noeuds avec un Witness externe), et qu’il faut de la mémoire pour le reste de l’ESXi et pour les VMs, on monte vite en charge.
Et cette quantité de mémoire n’est pas une recommandation mais un impératif. En dessous de la quantité voulue, un message empêchera de configurer vSan.
Disques virtuels type HDD ou SSD
L’ESXi devrait détecter automatiquement le type de support qui lui est présenté. Cependant, d’une part la virtualisation de l’ESXi dans VMware Workstation peut parfois tromper l’ESX sur la véritable nature du stockage, et d’autre part le type de stockage présenté à l’ESXi ne correspond pas forcément au besoin.
Heureusement, il est possible d’ajouter des paramètres dans le fichier vmx pour forcer le type de stockage détecté.
Ainsi, si je définis 1 SSD de 50 Go pour le cache et 5 HDD de 100 pour les données, on verra quelque chose comme ceci dans le vmx :
scsi1:0.present = "TRUE" scsi1:0.fileName = "host01.infra.local-0.vmdk" scsi1:1.present = "TRUE" scsi1:1.fileName = "host01.infra.local-1.vmdk" scsi1:2.present = "TRUE" scsi1:2.fileName = "host01.infra.local-2.vmdk" scsi1:3.present = "TRUE" scsi1:3.fileName = "host01.infra.local-3.vmdk" scsi1:4.present = "TRUE" scsi1:4.fileName = "host01.infra.local-4.vmdk" scsi1:5.present = "TRUE" scsi1:5.fileName = "host01.infra.local-5.vmdk"
Il suffit d’ajouter quelques lignes pour indiquer le statut SSD de chaque disque scsi. Ici, le disque scsi1:0 sera vu comme un SSD alors que les autres seront vus comme HDD, bien qu’ils soient tous stockés sur le même support physique.
scsi1:0.present = "TRUE" scsi1:0.fileName = "host01.infra.local-0.vmdk" scsi1:0.virtualSSD = 1 scsi1:1.present = "TRUE" scsi1:1.fileName = "host01.infra.local-1.vmdk" scsi1:1.virtualSSD = 0 scsi1:2.present = "TRUE" scsi1:2.fileName = "host01.infra.local-2.vmdk" scsi1:2.virtualSSD = 0 scsi1:3.present = "TRUE" scsi1:3.fileName = "host01.infra.local-3.vmdk" scsi1:3.virtualSSD = 0 scsi1:4.present = "TRUE" scsi1:4.fileName = "host01.infra.local-4.vmdk" scsi1:4.virtualSSD = 0 scsi1:5.present = "TRUE" scsi1:5.fileName = "host01.infra.local-5.vmdk" scsi1:5.virtualSSD = 0
Configuration réseau
Créer sur chaque ESXi un VMkernel adapter dédié à vSan.
Il se crée comme un VMkernel classique, si ce n’est qu’il n’y a que via le Web Client qu’on peut activer l’option « Virtual SAN traffic ».
Activation de vSan
Là encore, il faut utiliser le Web Client.
Commencer par désactiver HA sur le cluster. Il doit être désactivé losqu’on active ou qu’on désactive vSan, et peut bien entendu être réactivé une fois le changement d’état effectué.
Au niveau du cluster, dans les settings, on voit que vSan n’est pas activé.
Cliquer sur configure. Les options par défaut peuvent être gardées dans un premier temps. Le premier onglet indique des propriétés de vSan, comme la prise en compte automatique des nouveaux disques ou la compression et déduplication. Le second onglet permet de vérifier que les bons VMkernels ont été pris en compte. Le troisième onglet permet de sélectionner des disques, mais ne rien sélectionner, on y reviendra. Après validation, on voit que vSan est bien actif, même si pour l’instant il est vide.
Ajout de disques
Se positionner sur Disk Management, sélectionner le premier host, et cliquer sur l’icône 
.
Dans la partie supérieure figure les volumes SSD pouvant servir de cache à un Disk Group, et dans la partie inférieure figurent les volumes HDD/SSD pouvant servir au stockage de données.
Sélectionner les éléments voulus. Dans le cas présent, le SSD et les 5 HDD.
Après quelques instants de configuration, le Disk Group apparaît au niveau du Host, ainsi que sa composition.
Recommencer avec les autres hosts du cluster…
Ensuite un retour sur Général montre qu’on a bien désormais un vSan en version 3.0 s’appuyant sur 18 disques (3 SSD et 115 HDD).
Et un datastore nommé vsanDatastore est apparu pour une capacité de 1,45 To.
Politique de stockage
Aller dans Policies and Profiles.
Puis dans VM Storage Policies. La politique de stockage vSan par défaut sera alors visible.
Et ses propriétés pourront être modifiées.
Il est possible de modifier la politique par défaut ou bien d’en créer de nouvelles. Lorsqu’une VM est stockée sur vSan, on lui indique quelle politique de stockage doit lui être appliquée.
Les principaux éléments des politique de stockage sont :
– Number of failure to tolerate : nombre de défaillance de stockage autorisées pour un objet (perte d’un host ou d’un disque). Pour un nombre N de défaillance autorisées, il faut un nombre N+1 d’exemplaires et 2N+1 hosts. Donc 1 défaillance nécessite le double d’espace disque et 3 hosts, tandis que 2 défaillances nécessitent le triple d’espace disque et 5 hosts.
– Number of disk stripes per object : sur combien de disques de stockage doit être hébergé l’objet. Un nombre supérieur à 1 peut permettre d’améliorer les performances, mais au prix d’une plus grande consommation de ressources.
– Force provisioning : permet de forcer la création de l’objet même si les ressources nécessaires ne sont pas présentes (par exemple 2 défaillances avec 3 hosts). L’objet est créé en mode dégradé, et les ressources seront attribuées dès que disponibles.
– Object space reservation (%) : pourcentage de l’espace logique à assigner immédiatement. 0% correspond à du Thin Provisioning et 100% à du Thick Provisioning, mais toutes les valeurs intermédiaires sont possibles.
– Flash read cache reservation (%) : réservation faite sur le SSD pour améliorer les performances. La partie non réservée sera utilisée pour tous les autres objects. A n’utiliser qu’en cas de problème de performances spécifiques, et avec circonspection sous peine d’écrouler les performances de tous les autres objets.
(Le terme objet est générique et désigne à la fois la VM, son répertoire, ses fichiers…)
Voilà, vous êtes parés. Amusez-vous bien…