La startup Nexustorage fait le pari de diviser par 20 le coût du stockage primaire
Lancée par un ancien de Caringo, cette startup édite le système Nexfs qui a la particularité de pouvoir placer la majorité des exécutables et des systèmes d’exploitation sur un cluster objet peu cher.
Nexustorage est une startup néo-zélandaise qui vient d’arriver sur le marché des solutions d’infrastructure avec un produit pour le moins original : son système de stockage Nexfs place le contenu des partitions de boot sur un service de stockage objet ! Selon le fondateur de cette startup, Glen Olsen – un ancien de Caringo (entretemps racheté par DataCore) – Nexfs présenterait l’énorme avantage économique de réduire drastiquement le besoin en stockage primaire, la catégorie la plus chère. Il donne un exemple : pour un volume de boot de 300 Go, seulement 15 Go nécessiteraient d’être encore enregistrés sur les SSD d’une baie de production tier1.
« Le stockage objet est génial, car il utilise les disques le moins cher possible, et vous pouvez accroître sa capacité très facilement. Mais le problème habituel avec le stockage objet est que vous ne pouvez y stocker que des documents de travail, car la manière d’y accéder est résolument incompatible avec le stockage d’exécutables, à savoir les binaires qui composent les applications et les systèmes d’exploitation. C’est ce problème sur lequel nous nous penchons », lance le fondateur, lors d’un entretien avec le MagIT.
Et d’ajouter : Nexfs ne fait pas que déplacer des exécutables sur du stockage moins cher. Dès lors que ces fichiers sont sur du stockage objet, ils seraient naturellement protégés par les dispositifs de redondance internes à ce type de produits. C’est-à-dire qu’il n’est même plus besoin d’investir dans une solution de sauvegarde tierce pour protéger ses serveurs.
Comme du stockage en mode bloc, mais sur du stockage objet
Le secret ? Nexfs n’enregistre pas des fichiers sur le stockage objet, mais des fragments, des « chunks », exactement comme le fait un système d’exploitation hôte quand il enregistre tous ses fichiers sur un disque dur préalablement formaté. Le formatage, qui remonte à l’époque des disquettes, est la base du stockage en mode bloc : il consiste à diviser la surface d’un disque en secteurs, tous de la même taille, tous numérotés. Ce principe sert à gérer l’espace disponible sur un disque, car comme tous les secteurs ont la même taille, il devient trivial de mettre les fragments d’un nouveau fichier à la place des fragments d’un fichier précédemment effacé.
Mais ce fonctionnement par secteurs indexés a peu à peu dépassé le simple cadre des systèmes d’exploitation : il est aussi utilisé par les bases de données SQL qui ne réenregistrent pas toute la base à chaque fois qu’elles changent une donnée, mais juste le fragment correspondant à cette donnée sur le secteur qui la porte.
C’est exactement ce que fait Nexfs : du point de vue des serveurs, il se présente comme une baie SAN iSCSI en mode bloc, donc compatible avec les accès des systèmes d’exploitation – qui chargent les exécutables – et ceux des bases SQL. Sauf qu’il n’enregistre pas forcément les blocs qu’on lui envoie sur les secteurs des disques présents dans le serveur qui l’anime. Il les envoie dans la majorité des cas sous la forme d’un enregistrement objet vers un stockage de type S3, en l’occurrence les systèmes de stockage objet sur site Cloudian et Minio, voire le service en ligne S3 d’AWS, dont la compatibilité a été validée par Nexastore.
Cela dit, Nexfs n’envoie pas non plus tous les blocs vers du stockage objet. « Le stockage objet reste lent, trop lent pour rapatrier à chaque fois des exécutables que vous utilisez tout le temps. Donc Nexfs accole, à tous les fragments de fichiers qu’il gère, une watermark, c’est-à-dire un score de chaleur. Selon le score d’un fragment, celui-ci restera sur un disque NVMe très rapide, sera déplacé sur un stockage Tier2 avec des disques durs SATA moyennement rapides, ou sera déménagé vers un stockage objet », explique Glen Olsen.
Et c’est là que réside toute l’importance de stocker des fragments de fichiers plutôt que des fichiers entiers : « l’usage classique sera celui des machines virtuelles. Pour chaque machine virtuelle, vous chargez une image-disque de plusieurs centaines de Go qui contient un système d’exploitation, disons Windows, et des applications. Mais dans la majorité des cas, votre machine virtuelle n’exécutera qu’une faible portion des exécutables présents dans cette image disque. L’idée consiste donc à ne laisser sur les disques NVMe que les fragments de cette image disque qui contiennent les exécutables que vous utilisez vraiment. »
D’où l’exemple cité plus haut des 300 Go qui se réduisent à seulement 15 Go sur les SSD de production. Glen Olsen explique que, dans ce cas, 125 Go correspondent à des exécutables qui ne sont jamais lancés par la machine virtuelle et 160 Go sont la réserve que les entreprises provisionnent en général pour parer à toute éventualité de croissance des données en cours de travail. « Avec Nexfs, ces 285 Go supplémentaires restent sur le stockage objet s’ils sont inutiles, voire sont placés par fragments sur le stockage intermédiaire quand ils deviennent ponctuellement utiles. »
Des fonctions pour optimiser le VDI et la protection des données
Au-delà du principe de base, l’intérêt de Nexfs réside aussi dans toutes les fonctions accessoires qui accompagnent son noyau. Il en va ainsi de la fonction SmartClone qui simule la présence de deux images disques identiques à partir des mêmes fragments, pour servir deux machines virtuelles, puis qui n’enregistre individuellement que les fragments modifiés par chacune des machines virtuelles.
« Le cas d’usage auquel on pense est celui des postes de travail virtuels en VDI, où chaque utilisateur part du même environnement Windows et y crée ses propres changements. Songez à une application dans le cadre de l’enseignement, où chaque élève enregistre ses documents sur un stockage objet. Nous pouvons désormais dire à ces établissements que leur stockage objet va aussi servir grâce à Nexfs à faire des économies dans le stockage primaire qui héberge leurs postes virtuels », argumente le fondateur de Nexstorage.
« Lorsque vous aurez remis en production des SSD dans votre baie de stockage primaire, Nexfs ira automatiquement les réhydrater, avec les fragments stockés dans le cluster objet qui ont le score le plus chaud. »
Glen OlsenFondateur Nexustorage
Bien entendu, Nexfs s’occupe aussi de stocker des copies redondantes de chaque fragment sur le pool de stockage dont il a la charge. C’est la fonction SmartProtect qui s’en occupe. Ses caractéristiques sont prometteuses : si d’aventure les SSD NVMe de stockage primaire tombaient en panne, Nexfs redirigerait automatiquement les accès vers les fragments stockés ailleurs, sur la baie secondaire avec des disques SATA moyennement rapides (Glen Olsen prend l’exemple d’un NAS), ou sur le cluster de stockage objet où se situe une copie de tous les fragments possibles.
« Et lorsque vous aurez remis en production des SSD dans votre baie de stockage primaire, Nexfs ira automatiquement les réhydrater, avec les fragments stockés dans le cluster objet qui ont le score le plus chaud inscrit dans leur watermark », ajoute Glen Olsen en suggérant que SmartProtect revient à une sorte de super RAID qui n’interrompt pas la production quand il reconstruit les données.
Enfin la fonction principale est celle appelée SmartTier. C’est elle qui migre les fragments selon leur score de chaleur. « SmartTier est programmable : comme pour les sauvegardes, vous pouvez définir des fenêtres quotidiennes, typiquement aux heures creuses de la nuit, pour déplacer les fragments d’un tiers de stockage à l’autre selon les derniers scores que Nexfs leur a attribués. Cela dit, afin d’économiser au maximum le stockage le plus cher, SmartTier migrera sans attendre un fragment qui obtiendrait un score le plus bas possible alors qu’il se trouve sur une baie de stockage primaire ».
Glen Olsen ne précise pas au bout de combien de temps Nexfs détermine un score pour les nouveaux fragments. Il reste également discret sur la proportion idéale entre les capacités de stockage primaire, secondaire et objet qu’une entreprise devrait déployer. Car, a priori, avant de déterminer qu’un fragment est inutile, il faut observer quelle est la fréquence de ses accès en production.
Encore en version beta
Le moteur qui indexe tous les fragments sur le pool de stockage géré Nexfs s’appelle Nexassert. C’est lui qui détermine la taille des fragments, lesquels peuvent aller de 64 Ko à 8 Mo, une taille de 1 Mo étant, selon Glen Olsen, la plus fréquente.
À l’heure actuelle, Nexfs est encore au stade de la préproduction. Des versions beta sont de temps en temps téléchargeables gratuitement depuis le site de Nexastor. La dernière en date n’était pas autonome, elle nécessitait d’être installée par-dessus un Linux ; l’éditeur conseille Ubuntu, RedHat ou CoreOS.
Si Nexfs est installable sur un seul serveur x86 – relié à du stockage primaire (SSD NVMe internes), secondaire (NAS en réseau) et objet (cluster externe, sur site, voire dans le cloud) –, Nexastor recommande toutefois de déployer son logiciel sur plusieurs serveurs frontaux, pour parer à toute panne de l’index contenu dans le moteur Nexassert.
