VSAN : Installation et premiers pas

Après une très grosse série d’articles et même une vidéo d’installation de EMC ScaleIO, il fallait évidemment que je continue mon voyage au sein des offres de SDS du marché. Il me reste encore beaucoup de chemin à parcourir (Atlantis USX et sans doute aussi HP StoreVirtual) mais je ne pouvais pas passer à coté de celui qui, malgré tout, a la cote en ce moment : VSAN !

Pour se faire, il a fallut que je mette à jour mon petit vLab personnel. Rappelez-vous, à l’époque, je vous avais présenté ma modeste configuration pour commencer à travailler chez moi et disposer du minimum pour avoir un vCenter et quelques Go RAM pour héberger des VM (en plus des petites machines personnelles). Depuis, le vLab a pas mal évolué et est désormais constitué de 3 Mac Mini chacun pourvu de 16 Go de RAM et surtout d’un couple identique de disques : un SSD de 256 Go et un disque classique d’1 To.

Et la vous me dites : mais, Dieu me tamponne, c’est juste le minimum requis pour installer VSAN ou bien ? Diantre, mais oui, comme c’est curieux ! Il n’en fallait pas plus pour se lancer dans la découverte de ce produit pur VMWare, suivez-moi !

Avant toute chose et pour vous faire une idée plus précise du vLab support de cette installation, voici le schéma synoptique de la configuration ainsi que quelques photos des bestioles :


Précision également, coté réseau, je suis limité à 1 Gbps et de-facto mes transferts iSCSI ou VSAN seront plafonnés (on le verra dans la suite). Enfin, pour terminer ce préambule, j’ai travaillé avec vCenter 6 et VSAN 6.1, la dernière version en date.

1. Préparation

Pour pouvoir implanter VSAN, les pré-requis sont simples : minimum 3 hosts ESXi et un couple SSD/Disque à plateau (ou 2 SSD éventuellement) pour chaque host. Une fois remplis, l’installation proprement dite est vraiment très simple vous allez le voir. VSAN s’appuie sur un cluster ESXi, donc les paramètres de configuration se trouvent à ce niveau dans l’interface. Première étape, activer VSAN. L’opération dure quelques secondes et permet aux serveurs ESXi du cluster de préparer l’arrivée de la volumétrie associée et aussi de réserver l’espace mémoire minimum sur chaque serveur : 3 Go. C’est beaucoup pour mon environnement (20% de la mémoire dispo sur chaque machine), mais ça reste quasi négligeable pour de la grosse production. En plus des 3 Go de base, cette quantité de mémoire augmente en fonction de la volumétrie globale attribuée au SDS mais aussi en fonction du type de disques présents. Si vous souhaitez en savoir plus sur les règles de calcul, vous pouvez lire cet article de VMWare qui détail tout cela.

2. Provisionnement

Une fois VSAN activé, on va associer les disques disponibles de chaque ESXi en fonction de leur type et de leur usage pour construire des “diskgroup”, des entités logiques autonomes. Il faut au minimum un diskgroup par serveur, mais on pourrait imaginer plusieurs volumes VSAN au sein de notre cluster, chacun porté par des diskgroup locaux différents. VSAN contient deux type de destination pour les disques déclarés, le “Cache tier” et le “Capacity tier”. Le cache tier ne participe pas directement au stockage des données mais, comme son nom l’indique, permet d’accélérer et bufferiser les I/Os sur des disques rapides. Seuls les disques de type SSD sont autorisés pour cela. Le capacity tier quant à lui est destiné à stocker réellement les données. Enfin, le cache tier n’intervient pas dans la volumétrie globale disponible. Pour notre exemple, j’ai donc sélectionné les disques SSD en cache tier et les disques SATA en capacity.

3. Allons plus loin …

Une fois ajouté nos 6 disques : 3 SSD de 250 Go et 3 disques S-ATA de 1 To, on obtient donc un volume VSAN de 2,7 To (en base 1024), soit l’espace cumulé de mes trois disques à plateau. Au premier abord, cela parait un peu étrange dans le sens ou on s’attendrait logiquement à en voir “moins”, disons 1,8 To … un espèce de RAID5 en gros. En fait, VSAN est beaucoup plus souple que cela. En effet, la tolérance aux pannes matérielles n’est pas liée au cluster VSAN lui-même, mais porté par chaque VM copiée sur ce volume global ! Cela signifie que vous pouvez affecter des politiques différentes à chaque VM et non pas à chaque volume. Ainsi, lorsque vous migrez ou créez une nouvelle VM sur un volume VSAN, vous allez indiquer via la sélection d’une politique de stockage de VM le type de résilience souhaité. Une politique de stockage VSAN est composé de paramètres régissant le comportement du cluster en fonction des pertes potentielles d’éléments matériels :


Par défaut lors de la création du cluster, vCenter créé une politique par défaut qui protège chaque machine déplacée ou créée sur VSAN contre la perte d’un élément matériel (un ESXi, isolation réseau d’un des serveurs, perte d’un disque etc. …). Avec celle-ci, chaque block de donnée est donc copié deux fois, sur deux diskgroups différents, donc deux ESXi différents.

Il est possible aussi de mettre en place des “fault domains” pour organiser ses serveurs ESXi en fonction de leur localisation physique, ainsi on peu construire des clusters étendus sur plusieurs salles et indiquer à VSAN de répartir les données stockées entre ces emplacements.

4. Chargeons la mule …

Avant toute chose, rappelez-vous que mon vLab est relativement limité dans ses performances : petites machines, petits disques, 1 Gbit/s de réseau. De plus chaque Mac Mini est connecté en direct sur le NAS, ce qui l’autorise à tirer quasiment 110 Mo/s sur la source iSCSI en cas de besoin.

Afin d’éprouver un peu VSAN et voir ce qu’il a dans le ventre, j’ai lancé un svMotion de 3 VM simultanément depuis mon NAS en iSCSI et vmfs standard vers le datastore VSAN. A ce 2 VM moment, tournaient sur un des trois serveurs ESXi et la troisième sur un second. Le storage vMotion s’est déroulé sur une quinzaine de minutes en tout, pour un peu plus de 90 Go logique à copier. Cela ne parait pas énorme, mais si on regarde les graphs du seul SSD source iSCSI et surtout les graphs réseau, on se rend compte que c’est surtout le réseau qui limitait le potentiel de VSAN. De plus, les 90 Gos ont du être écrits deux fois (suivant la politique VM choisie, 2 copie de chaque bloc). Ce sont donc pas moins de 90 Go en lecture et 180 Go en écriture qui ont transités entre le NAS et les ESXi cibles… et tout cela en quinze minutes : un score plutôt honorable :)

On remarque tout de même que les CPUs des machines (des Core i5 mobile double coeur) sont pas mal sollicités pendant cette opération (de 20 à plus de 40% à certains moments), mais ça parait logique étant donné que de nombreuses couches soft sont utilisées et que les CPUs sont loin d’être des bêtes de course.

Après une demi-heure environ et en plein test de charge, j’ai eu une petite frayeur quand j’ai vu débarquer une dizaine d’alertes quasi simultanéement, dont certaines critiques sur la console… j’ai tout cassé ?! En fait non (mais ça m’arrive je vous rassure ^^). L’adrénaline est vite retombée quand j’ai constaté que ces alertes provenaient du module de contrôle de l’état de santé de VSAN. En effet, vCenter est capable d’aller chercher dans la HCL de VMWare pour vérifier si les composants utilisés pour VSAN sont bien référencés, ceci afin de prendre toutes les garanties quant au bon fonctionnement de la couche SDS. Evidemment, on imagine bien que les Mac Mini et de banals contrôleurs SATA intégrés ne sont sans doute pas supportés, d’où les alertes.

A noter aussi que désormais, lorsque vous tentez de mettre en maintenance un serveur membre de votre cluster VSAN, vous avez une option supplémentaire vous permettant de choisir le type de comportement à appliquer concernant les données hébergées sur la machine en question. Trois options sont proposées :
– pas de migration de donnée : potentiellement, certaines VM non protégées à cause d’une politique particulière sans tolérance aux pannes peuvent voir leurs données indisponibles si la machine n’est plus accessible.
– maintenir l’accessibilité des VM : VSAN va vérifier que toutes les données présentent sur la machine sont bien également présentes sur d’autres serveurs du cluster. Si ce n’est pas le cas, une copie sera réalisée avant la mise en maintenance
– copier l’intégralité des données : cette dernière option réduit de-facto la taille globale du cluster VSAN mais permet éventuellement de supprimer définitivement et sans risque cette machine (en cas de reconditionnement ou sortie pour fin de vie par exemple)

Au final, mes premiers pas sur VSAN sont plus que concluants : simplicité de mise en oeuvre (quelques clics de souris), grande souplesse dans le choix du niveau de réslience “à la VM” et intégration native dans vSphere 6 … quel confort ! Sur ce dernier point, ScaleIO est battu à plate couture évidemment. Par contre, un petit bémol vis à vis des contraintes matérielles (mais bon, le SSD ne vaut plus grand chose désormais).

Pour des environnements 100% virtuels, VSAN semble être à la hauteur de sa réputation même s’il faudra réellement le comparer sur le terrain vis à vis notamment de ses latences moyennes. Avec le matériel à ma disposition, je ne peux vraiment pas me prononcer aujourd’hui, mais j’essayerai de poster via twitter quelques tests complémentaires notamment à la lumière de mes essais en cours avec IOmeter.

Il serait temps aussi de se lancer dans un comparatif “point à point” des solutions testées, histoire d’y voir un peu plus clair objectivement… comme toujours, à suivre !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *