Erik Ableson 7 minute read
November 14, 2018

Hammerspace au Tech Field Day 17

Hammerspace a donné la séance d'ouverture auTech Field Day 17 et c'était rempli de choses intéressantes.

L'une des choses qui m'intéresse presque autant que les plongées techniques approfondies sur la façon dont les choses fonctionnent sont certaines des parties dans les introductions où les présentateurs essaient de mettre leur produit en contexte car cela donne un aperçu très utile du concepteur du produit et comment il sera positionné dans le marché.

Une des premières choses qui m'a sauté aux yeux a été la façon dont David Flynn a exprimé l'évolution du stockage en définissant la localité du système de fichiers. J'ai un certain nombre de séminaires où j'aborde le sujet d'une manière similaire mais différente car j'ai tendance à être préoccupé par les niveaux inférieurs de la pile de stockage, où le système de fichiers est juste la dernière couche qui se trouve au-dessus.

Mais du point de vue de Hammerspace, la chose la plus importante à propos du système de fichiers dans ce contexte est que c'est l'expression des métadonnées des fichiers qui existent dans un contexte particulier.

Tout tourne autour des métadonnées

Fondamentalement, l'architecture sous-jacente de Hammerspace est basée surpNFS qui est conçu pour séparer les métadonnées des fichiers partagés du chemin d'accès aux fichiers. Le résultat est qu'un espace de noms ou un point de montage partagé déclaré peut en fait être physiquement distribué sur différents serveurs NFS en back-end. Et maintenant que le point de montage est dirigé vers le service de métadonnées plutôt que vers un NAS physique spécifique, nous pouvons migrer (ou dupliquer !) les fichiers réels sur différents systèmes physiques de manière transparente pour le client pendant leur utilisation. Il y a unsuper article de Justin Parisi sur l'utilisation de pNFS par NetApp pour vous donner quelques idées sur le potentiel que cela débloque (en utilisant un protocole ouvert !).

Pour les utilisateurs de Windows, imaginez DFS-N, mais la granularité de la définition est au niveau du fichier plutôt qu'au niveau du partage. Vous vous connectez à un partage et les fichiers qui vous sont servis sont choisis en fonction de leur proximité relative sur le réseau.

Là où cela commence à devenir vraiment intéressant, c'est lorsque vous avez un service de métadonnées conforme à pNFS qui n'est pas limité à la sémantique de fichier basique d'un système de fichiers traditionnel (ACLs, taille, emplacement, URI, état, etc.) mais un ensemble de métadonnées extensible de façon arbitraire qui peut inclure des paires clé/valeur structurées ou de simples balises. Et c'est aussi très bien que NFSv4 inclut également la télémétrie de performance et d'accès dans les métadonnées. Ainsi, votre service de métadonnées sait qui accédait à un fichier, à partir de quel endroit, produisant combien d'IOPS et consommant combien de bande passante. Mais c'est la partie arbitrairement extensible de ce mélange qui le rend vraiment utile, où nous imaginons un scénario où le système contient des règles de placement du back-end qui exigent que chaque fichier d'une part donnée soit dupliqué - dans le sens technique d'avoir une copie des données sur un autre système physique, mais d'un point de vue métadonnées, est toujours le même fichier, juste avec un nouveau chemin d'accès supplémentaire - vers un hôte qui exécute automatiquement une sorte de scan ou applique un algorithme ML pour tout nouveau fichier ou modifié qui arrive. L'outil d'analyse peut alors prendre les résultats de son analyse et ajouter ces informations supplémentaires aux métadonnées associées au fichier via API au service de métadonnées Hammerspace. L'exemple donné dans la présentation était la routine de reconnaissance d'image (qui devient classique) où il ajoutera une étiquette indiquant que cette photo contient un chien (ou un chat, ou un émeu, ou autre). Une fois que cette balise a été remplie, le gestionnaire de données en arrière-plan remarque que la balise est remplie et supprime ensuite l'instance doublon du serveur. D'un point de vue pratique, je pense à des choses comme les outils pour scanner les fichiers à la recherche dePII et de les étiqueter de manière appropriée afin d'appliquer les règles de gouvernance des données appropriées. Fini les scans nocturnes des serveurs de fichiers.

Bien sûr, bien que pNFS soit disponible nativement sur toutes les distributions Linux modernes, cela ne résout pas le problème de la présentation des fichiers et des partages aux machines Windows sous deux angles. Tout d'abord, la communauté des utilisateurs est habituée à monter des partages SMB et comprend le flux de travail autour de cela. Deuxièmement et plus important encore, bien que Windows ait un client compatible NFS 4 depuis un certain temps maintenant, à ma connaissance, il ne supporte pas encore pNFS (je l'avoue, je n'ai pas encore vérifié sur Windows Server 2019).

Ainsi, Hammerspace fournit des services de données supplémentaires qui peuvent présenter le contenu des partages pNFS sur SMB afin que les utilisateurs réguliers de bureau puissent accéder aux fichiers stockés dans le monde Hammerspace.

Si certains de ces éléments semblent familiers, en particulier les éléments de gestion et déplacement des données, cela vient de leur histoire avec Primary Data, donc Hammerspace n'arrive pas sur la table avec une pile logicielle complètement nouvelle, mais que certaines des fonctionnalités principales autour du pNFS et de la gestion des données ont déjà été testées à fond. En fait, une grande partie du back-end Hammerspace est l'évolution de l'IP acquise auprès de Primary Data, avec une grande partie de l'équipe de base, réorienté vers le marché de la gestion des données, en place du marché de la gestion des infrastructures.

Je pense qu'ils ont ici une opportunité fascinante de déplacer la gestion des données non structurées du monde des scripts vers un monde basé sur des politiques qui peut prendre en compte tous les problèmes techniques autour de la localité des données pour des raisons de performance (y a-t-il une copie de ce fichier suffisamment proche du consommateur ?), d'utilisation des applications (déplacer toutes les données ingérées vers un nouveau « data lake » pour analyse) et de gouvernance (conserver ce type de données sur les systèmes dans l'UE).

Derniers notes

Oh, et que se passerait-il si Hammerspace ajoutait des « object stores » comme back-end pour s'assurer que le mouvement et l'accès des données basés sur des stratégies vous permettent de collecter des données en utilisant des outils de partage de fichiers réguliers, et s'assurer qu'ils sont également disponibles pour vos systèmes ML basés dans le cloud qui sont optimisés pour le stockage des objets ? Ou des applications basées sur le Cloud qui exportent des d'objets et qui doivent être mises à la disposition d'applications basées sur un NAS sur site ? Tout est géré par politique, pas par scripts.