L’annonce de vSphere 7.0 s’accompagne évidemment d’une mise à jour pour vSAN. D’aucuns pourraient arguer que désormais vSAN fait partie intégrante de la suite vSphere (le codes est intégré nativement à ESXi et vCenter), certes, mais c’est tout de même un pilier assez spécifique pour avoir son propre billet ^^. De bonnes choses sur ce deuxième produit phare de VMware, dont certaines étaient déjà connues, mais qui font tout leur sens dans le cadre du projet Pacific. Voyons ça de plus près !
Les files services
On arrête pas d’en parler, un des gros enjeux de vSphere 7.0 est la prise en charge complète des workloads Kubernetes. Mais quand on parle de container, on s’attaque aussi à un écosystème globalement basé sur l’Open Source et donc à une approche stockage orientée vers les protocoles idoines. Les fameux persistent volumes du monde des containers sont souvent hébergés sur ce genre de service fichier, par simplicité et “universalité”.
Il fallait donc que vSAN s’adapte, c’est désormais chose faite avec la publication des “File Services” (prononcez faïle servicize, ça fait riche). vSAN 7.0 propose maintenant la connectivité NFS 3.0 et 4.1. Cette fonction est ouverte dans le sens ou elle peut être consommée techniquement par n’importe quelle application cliente, qu’elle soit membre du cluster ou non. Cependant, cela a été rappelé, l’objectif est avant tout d’ouvrir l’accès à vSAN avec un protocole file mais conserver une cohérence sur le type de données stockées sur le cluster : ce service n’a pas été pensé pour remplacer un NAS (d’autant qu’aujourd’hui, on ne parle pas de CIFS). VMware insiste donc sur le fait que les données stockées en mode file sont destinées aux utilisateurs du cluster vSAN sous-jacent, mais pas au monde entier. Les file services offrent également des fonctions avancées de Quota, de chiffrement et même de snapshots.
Intégration avec les services vLCM de vCenter, Life Cycle Management
J’en ai parlé dans mon billet sur vSphere 7, VMware a beaucoup travaillé sur la gestion du cycle de vie de ses produits et vSAN n’échappe pas à la règle. L’approche est vraiment nouvelle par rapport à ce qu’on connait en vSphere 6. vSAN est un élément particulièrement sensible à la conformité des configurations des clusters et leur compatibilité avec lui. De facto, comme le propose VxRail depuis plusieurs années, vous allez pouvoir préparer des images de ESXi composées à partir de toutes les sources de drivers, firmware et patchs et, ainsi, contrôler dans la durée que vos serveurs ne dévient pas par rapport à ce référentiel. C’est clairement une énorme avancée pour tous ceux qui ont construit leurs clusters vSAN “à la main”.
Amélioration dans la gestion des clusters stretched et 2-noeuds
VMware a également travaillé sur l’optimisation des performances et du comportement général de VSAN 7.0.
Concernant les phases de DR entre fault domains, la bande passante entre les deux site est toujours une ressource critique, voire contrainte, lors des reconstruction (d’ailleurs petite pub sur mon billet d’il y a quelques temps déjà au sujet de vSAN et du réseau). Désormais VSAN travaille en collaboration avec DRS afin de lui interdire de ré-équilibrer les VMs entre les deux site, tant que la reconstruction n’est pas terminée.
De même, on peut désormais forcer la gateway directement sur les vmk dédiées vSAN dans l’interface vCenter. Ca évite accessoirement de devoir y aller à coup de ligne de commande pour créer des routes statiques spécifiques entre les fault domains et le witness. Et, oui, sachez-le, si vous n’étiez pas au courant, sous vSphere 6 la recommandation pour le routage IP vSAN c’est de mettre des routes statiques sur tous vos hosts et pas de modifier la gateway par défaut (ce qui reste possible techniquement, mais ce n’est pas supporté visiblement …).
vSAN 7.0 gère mieux les contraintes locales de capacité (disque full, soyons clair ^^) entre fault domains ainsi que les situation non équilibrées (imbalanced). Les flux d’I/O sont reroutées en fonction de ces contraintes ponctuelles et on priorise désormais la continuité de service aux erreurs bloquantes. En gros, si d’aventure, pour une raison ou une autre, un de vos site devient trop rapidement full, au lieu de planter les VM par défaut de place, on va privilégier les I/O sur l’autre site, même si ponctuellement, le FTT n’est pas respecté sur les écritures.
Supervision
Au niveau de la supervision et du capacity planning de vSAN, là aussi, ça évolue pas mal. Pour la partie Skyline, de nouvelles fonctions voient le jour mais qui dépendent du niveau de support auquel vous avez souscrit bien sûr. Skyline peut vous proposer des conseils personnalisés sur des résolutions d’incident et connait aussi des produits autre que vSphere comme vROps, vCD ou même VxRail. Par ailleurs, les métrics remontés par vSAN et vCenter sont enfin cohérents entre eux … ce n’est pas un mal, clairement, vu les différences qu’on peut constater aujourd’hui entre l’API et les graphs vCenter (voir mon billet sur le jeu d’API du poto Erwan utilisé via Telegraf+InfluxDB+Grafana). Enfin, de nouveaux graphs et points de mesure dédiés à la consommation mémoire spécifique de vSAN sont disponibles (cache de 1er niveau, avant même les cache disks, ainsi que la gestion des metadatas entre hosts, j’imagine).
Ce n’est pas la révolution, mais ne pleurons pas trop, toute évolution dans ce domaine est bienvenue. J’aurais aimé une option pour suivre “à la seconde” ou en quasi temps-réel (15/30 secondes disons), via les API pourquoi pas, l’activité de vSAN, qui manque clairement aujourd’hui … ce sera pour une prochaine fois.
… et coté hardware ?
vSAN 7 est désormais capable de prendre en charge les disques capacitifs jusqu’à 32 To (outch… ça commence à peser, surtout lors de reconstructions éventuelles ^^. Et justement, il dispose aussi d’optimisations et traitements spécifiques pour ces disques de très grosse capacité afin de limiter les mouvements de données et améliorer le facteur de réduction de données sur ce type de support (on en saura pas plus pour le moment). Autant dire que des clusters avec des capacités de plusieurs Po seront bientôt monnaie courante, même sur un nombre limité de noeuds. Vous me direz, on va bientôt frôler les 400 To sur notre monstre d’ici quelques semaines et c’est déjà pas si mal à notre échelle. Je vous ferai un petit billet à l’occasion.
Autre nouveauté/amélioration : vCenter et vSAN supportent les mécanismes hotplug sur les disques NVMe. Personnellement, je pensais que c’était déjà le cas, mais visiblement, non. Donc si vous avez des cache disks NVMe et que l’un d’entre eux casse, vous ne serez plus obligés d’éteindre le host en question ^^.
Enfin, vSAN est désormais capable de présenter des vmdk totalement standards à des clusters Oracle RAC. Jusqu’à maintenant, ce type de disque partagé devait obligatoirement être créé en thick-eager-zero. Cela se traduisait par la nécessité de réserver 100% du disque sous vSAN, entre autres. avec vSAN 7.0, ces contraintes sautent. Bon, en même temps, vous avez des clusters RAC sur vSAN, vous ? Avant qu’un fournisseur accepte ça dans notre monde de la santé si conservateur, il y a encore du boulot d’évangélisation ^^
Le bon grain de l’ivraie
Que penser de toutes ces annonces au final ?
Globalement, vSAN évolue surtout pour prendre en compte les containers et les persistant volumes et cela parait logique. Il suit aussi les évolutions matérielles et se consolide sur les aspects plus opérationnels. Malgré tout, je dirais que c’est une évolution de moyenne envergure et que l’indice 7 n’était pas forcément justifié. Personnellement j’aurais adoré avoir des évolutions plus larges du coté Ops. En cela, c’est un peu décevant.
Maintenant, ne boudons pas notre plaisir d’avoir un produit aussi structurant et critique évoluer posément et ne pas “tout changer” à chaque itération. Quand on se souvient du cycle de développement de sa jeunesse, c’était beaucoup plus rock’n roll certes, mais je ne suis pas sûr que certains souhaitent revivre cela ^^. Rien que le nouveau système de gestion du cycle de vie est clairement une avancée majeure à mettre en prod d’urgence, pour ceux qui travaillent avec vSAN en DIY.
