VSAN7 File Services : plus facile, plus rapide, plus séduisant !

Salut à tous ! Ce début d’année commence sur les chapeaux de roues (mise en place de centres de vaccination, relance de très gros projets sur le SAMU, mise en place prochaine de notre nouveau Dossier Patients informatisé etc.). Pour autant, j’ai quand même trouvé un peu d’énergie depuis une semaine pour relancer mon vLab et surtout trouver enfin une solution pour l’upgrader en vSphere 7. L’occasion pour moi de découvrir, entre autres, VSAN7u1 “File Services” et de vous en faire un retour “à chaud”.

Pour rappel, VSAN File Services, annoncé en même temps que VSAN7 (voir ici) a pas mal évolué depuis son introduction. Pour résumer, l’objectif est de déployer une fonction NAS au dessus de votre cluster VSAN et d’utiliser l’espace de stockage associé pour du service fichier classique (captain obvious). Pour autant et de mon point de vue, cela ne se substitue pas *encore* à un vrai service NAS avancé, car les options, vous le verrez, sont relativement basiques. Cependant, cela peut être parfait pour de la ressource technique, un repository d’images iso ou de distributions, des espaces de manœuvre et ou temporaires, des fichiers de configuration, des templates divers. Dans certains cas, des profils utilisateurs ou VDI, sont possibles sans souci je pense, si vous n’avez pas besoin de suivi fin de quotas ou attributs spéciaux. Au passage, VMware insiste aussi sur la partie stockage persistent pour des containers et c’est vrai que cela ouvre VSAN à des usages dans ce domaine. Pour le coup, je n’ai pas encore plongé à fond dans le monde des containers, mais il est temps que je m’y mette sérieusement …

Si File Services a commencé uniquement avec NFS, avec l’Update 1 annoncée en Septembre 2020, SMB2/3 est désormais là avec l’intégration Active Directory (voir ici). Vous êtes par contre toujours limités à 32 shares ainsi qu’aux clusters non stretched. De plus, j’ai testé avec un cluster 2 noeuds et malgré le fait que VMware ne supporte pas cette configuration, elle fonctionne parfaitement, en tout cas en mode nomminal. Je n’ai pas réussi à avoir l’info sur ce qui pose exactement problème mais au moins vous pouvez tester facilement en lab ^^. Je trouve ça assez dommage, d’autant plus que les 2nodes+witness sont particulièrement adaptés aux sites distants et SOHO, qui pourraient tirer avantage des files services intégrés. Nul doute que cela évolue avec le temps et qu’on ait une raison plus explicite.

Principe de fonctionnement

Je ne vais, là encore, pas trop m’étendre sur le fonctionnement interne de File Services, d’autres sites le décrivent très bien (voir ici), mais en substance, VMware ne réinvente pas la roue et s’appuie sur des VMs de service qui assurent les fonctions de têtes NAS. Elles fournissent l’accès aux ressources du datastore VSAN via des protocoles ouverts ainsi qu’une haute disponibilité et une répartition de charge massive (une VM par membre du cluster). On reprend les principes du HCI et on les décline en service fichier, simple et élégant.

On active le bouzin ?

Sur VSAN7u1, l’activation de File Services se fait directement via la console vSphere, dans l’onglet Configuration/VSAN. Pour le coup, je vous illustre ça avec des copies d’écrans, dont je ne vous ai pas abreuvé récemment, donc ceux qui aiment ça seront comblés ^^.

Les premières phases sont classiques, une petite introduction, on définit les paramètres réseau de base, enfin la connexion à votre instance Active Directory. En effet, chaque tête NAS File Services va s’enregistrer en tant que serveur dans le domaine associé, pour pouvoir ensuite partager la base de comptes et assurer le RBAC. Ensuite, on indique sur quel portGroup de votre dvs vous allez “cabler” ces VMs. VMware recommande de dédier un portgroup pour les file services car certaines fonctions spécifiques (mac-address learning et le mode promiscuous, notamment) sont utilisées pendant la configuration initiale. Vous pouvez consulter le billet de Duncan Epping sur ce sujet, ici.

Ensuite, on donne l’identité réseau de chaque VM qui va être créé sur chaque host, au sein du cluster. Attention à bien tout déclarer sur vos DNS au préalable, comme toujours avec vSAN et vSphere. Après, une phase d’auto-configuration qui prend quelques minutes, suivant la taille de votre environnement, les File Services sont opérationnels et prêts à être utilisés.

On teste le bouzin ?

La création de share, qu’ils soit NFS ou SMB, ne pose pas de problème non plus à travers vSphere, comme vous pouvez le voir. Chaque share donne une visibilité de toute la volumétrie disponible sur VSAN a l’instant T, par contre, des volume-quotas sont disponibles, pour réfréner la nature, car comme vous le savez, la nature a horreur du vide !

Vous noterez que les UNC/URI des shares sont parfaitement détaillées et peuvent être directement copiées/collées depuis leur page de description. De même, pour les shares SMB, on peut même utiliser le snapin Windows dédié pour travailler sur les droits d’accès, pour le coup, je trouve ça très pratique.

J’ai fait quelques essais de performances de transferts. Ca vaut ce que ça vaut, c’est à dire pas grand chose, mais il semble que CIFS et NFS soient au coude à coude, les essais étant été réalisés avec une VM Linux sous CentOS, ainsi que sous Windows 2016. Les débits, par rapport aux capacités de mon vLab, sont très proches des maximums que j’imaginais pouvoir atteindre, sachant que l’ensemble des flux VSAN, File Services et manager sont tous routés vers des interfaces 10G qui synchronisent, sur les deux machines qui participent au cluster 2-node (zeus et cronos), à 2,5 Gbit/s. On obtient entre 150 et 180 Mo/s soit environ 1,5 Gbit/s. Sur les graphiques Grafana des interfaces, on constate bien l’envoi par la machine source, ainsi que la réplication “temps réel” du FTT1 dans le cluster. Pour autant, je ne peux pas dire si la limite de 1,5 Gbit/s est liée à mon setup ou à une contention interne software. Je n’ai pas pu obtenir plus en tout cas. Si vous vous intéressez à la chose, ne faites pas l’économie un petit PoC et quelques workshops sur le sujet, cela me parait indispensable étant donné la jeunesse du service !

Plus surprenant, je me suis rendu compte sur la machine cliente qui faisait les transferts, les deux mac-address des deux têtes NAS du cluster n’étaient pas des mac-adress VMware traditionnelles en 00:50:56:xx:xx:xx mais des mac-address “Docker” en 02:42:xx:xx:xx:xx . Pour le coup, ça semble logique (étant donné que la plateforme de service est visiblement du PhotonOS). J’imagine que ces têtes NAS de service sont plus ou moins stateless et tirent leurs données des API vSAN. Le fait d’avoir des mac-adress flottantes et différentes de la VM de service permet aussi sans doute de pouvoir changer d’identité réseau très vite en cas d’indisponibilité d’un ou plusieurs ESXi.

Conclusion

Au final, File Services est système très séduisant sur le papier. La base semble saine, la prochaine étape sera, pour moi en tout cas, de le voir “en prod”, avec un usage quotidien et des centaines de connexions simultanées. Alors, VSAN File Services, plus facile, plus rapide, plus séduisant ? vous connaissez la suite, “pas le plus fort” ? A nous, consommateurs, de l’essayer et de l’apprivoiser pour en tester ses limites et voir si les promesses sont tenues :)