Dell EMC multiplie les améliorations sur les baies Isilon

Des fichiers de plus grande taille pour améliorer l’imagerie et... les snapshots ?

« Dépasser la limite de 4 To pour un fichier était naturellement une demande des industriels de la vidéo ; les diffuseurs, en particulier, souhaitaient pouvoir transformer des films depuis les shoots originaux. Savoir stocker un fichier qui grimpe jusqu’à 16 To permet par exemple de changer en une seule fois la texture d’un décor récurrent », indique Cyrille d’Achon, responsable avant-vente sur les produits de stockage non-structuré.

« Cela permet aussi de combiner des images de très haute définition, comme dans le domaine du spatial ou du médical, avec d’autres couches de données, afin de superposer plus d’informations pour augmenter l’efficacité analytique. »

Accessoirement, répondre à ces besoins très précis servira à terme le tout-venant des entreprises : « sur des systèmes plus traditionnels, cela signifie aussi qu’il n’est plus besoin de découper le snapshot de serveurs virtuels ou le dump d’une base de données en deux ou trois segments de 4 To. Nous manquons encore de recul sur les bénéfices de cette fonctionnalité, car le découpage est de toute façon automatisé par OneFS. Mais il est certain que ne plus avoir à réconcilier plusieurs segments de données, contribuera à gagner du temps dans les applications », ajoute-t-il.

OneFS étant naturellement conçu pour un stockage en cluster, il n’est pas nécessaire que les nœuds disposent de disques durs de 16 To. Les fichiers, quelle que soit leur taille, sont découpés en « chunks » pour que leurs contenus et leurs accès soient répartis sur plusieurs nœuds. Pour mémoire, OneFS permet de mettre jusqu’à 252 nœuds Isilon en cluster.

Contenir la consommation d’espace même en utilisation permanente

La déduplication « inline » – comprendre au fur et à mesure que les données sont écrites et non a postériori – existait déjà sur les nœuds Isilon à base de SSD, comme le F810. Sur ce modèle, l’intérêt de dédupliquer les données avant de les écrire est de préserver la durée de vie des médias Flash. OneFS 8.2.2 ajoute désormais la déduplication inline aux nœuds H5600 à base de disques mécaniques. Cela paraît spontanément surprenant car ces disques ne vieillissent pas à cause du nombre d’écritures.

« Faire de la déduplication a postériori est possible à partir du moment où vous avez des périodes d’inactivité sur le cluster du stockage. Mais de plus en plus, nos solutions Isilon sont utilisées 24 heures sur 24, car les entreprises prennent l’habitude de lancer des processus d’analyses entre deux périodes d’ingestion des données. La déduplication étant un processus non prioritaire, nous nous retrouvions dans des situations où elle n’avait jamais lieu », explique Cyrille d’Achon.

La déduplication servant à éliminer les doublons dans les données pour économiser de l’espace disque, les utilisateurs de nœuds H5600 voyaient ainsi leur capacité de stockage se réduire plus vite que d’ordinaire.

« Il y avait une bonne raison de faire de la déduplication a postériori : cela servait à ne pas saturer la bande passante disponible en mobilisant de la puissance processeur sur une opération qui n’a rien à voir avec les accès. Mais nous avons contourné ce problème. Dans OneFS 8.2.2, un nouveau dispositif est capable de monitorer les accès des serveurs en NFS, pour ne lancer des opérations de déduplication qu’au moment où les accès sont moins intensifs », détaille le responsable avant-vente.

Rappelons que le modèle de nœud H5600, lancé il y a moins d’un an, contient, comme le modèle dédié à l’archivage A2000, 80 disques de 10 To chacun dans un boîtier 6U. La gestion des accès ainsi que la déduplication y sont assurées par quatre processeurs Xeon épaulés par 8 SSDs pour le cache. Au final, le H5600 supporte une bande passante de 8 Go/s et offre une capacité brute de 800 To qui, après déduplication, peut contenir plusieurs Po de données.

Vers une meilleure répartition de charge

Le monitoring existait déjà sur les accès en SMB, pour les serveurs Windows, mais la majorité des clients d’Isilon utilisent des serveurs Linux. « En SMB, le dispositif était simple puisqu’il se basait sur l’annuaire Active Directory. La nouveauté est que nous pouvons nous en passer. Pour l’heure, cela nous permet de repérer quelle adresse IP sur le réseau accède à quoi sur le NAS. Mais toutes les bases sont désormais posées pour que, dans une future version, OneFS soit capable, en temps réel, d’analyser la charge aux niveaux des applications et qu’il répartisse de manière optimale les accès », dit Cyrille d'Achon.

Une des premières applications de cette répartition de charge améliorée est la mise à jour des nœuds. Jusqu’alors, elle se faisait de manière séquentielle, un nœud après l’autre, pour éviter qu’il y ait trop de bande passante indisponible lors du processus. Revers de la médaille, la mise à jour du cluster était d’autant plus longue à se terminer. A partir de la version 8.2.2, OneFS répartit si bien les accès qu’il devient possible de mettre à jour plusieurs nœuds en même temps sans pénaliser la bande passante. Dell EMC conseille de fonctionner par lot de 10 nœuds, par exemple mettre à jour 4 nœuds en même temps sur un cluster de 40 nœuds.

« Dans cet exemple la mise à jour durera quatre fois moins longtemps, ce qui signifie que les entreprises vont pouvoir annoncer à leurs utilisateurs des périodes de maintenance d’autant moins longues », argumente Cyrille d’Achon.

Désormais intégré à Kubernetes

L’ouverture d’Isilon à Kubernetes correspond à l’arrivée d’un contrôleur CSI dédié. Un contrôleur CSI est, dans l’écosystème Kubernetes, un pilote qui présente aux applications en containers un stockage tiers comme s’il s’agissait d’un disque dur local.

Sans CSI, une application en container qui croit enregistrer des données dans le système de fichiers hôte, écrit en réalité dans l’image virtuelle du container. Comme cette image n’existe qu’en RAM, toutes les données écrites disparaissent avec l’extinction du container. Le CSI change ce comportement en détournant tous les accès fichiers vers une zone de stockage physique, qui résiste par nature à l’extinction du container.

Rappelons que, à la base, le mouvement DevOps militait pour n’utiliser les containers que dans le cadre d’applications web, lesquelles savent enregistrer durablement des données en envoyant une requête HTTP vers du stockage objet externe. Mais Kubernetes devenant une couche d’infrastructure pour tout le datacenter, les CSI ont été inventés afin de reproduire le comportement des serveurs d’applications classiques, qui lisent ou écrivent des fichiers avec des commandes Posix, des droits utilisateurs, etc.

« Nos clients développent toujours des applications traditionnelles, qui manipulent leurs données en mode fichier. Mais ils le font désormais au-dessus de Kubernetes pour les rendre plus élastiques. Nous devions donc répondre à leur besoin de stockage persistant », commente Cyrille d’Achon.

D’ordinaire, un CSI n’est développé spécifiquement que par un fournisseur de stockage en mode bloc, pour que Kubernetes sache s’interfacer avec les spécificités de ses baies de disques. En revanche, en mode NAS, c’est-à-dire le mode d’accès des Isilon, un CSI NFS générique est censé suffire.

« C’est vrai. Mais nous avons souhaité développer notre propre CSI, car nous n’aurions pas pu nous engager sur l’accompagnement et le support de nos clients si nous les avions renvoyés vers un CSI Open source tiers », répond notre interlocuteur.