MooseFS, une nouvelle marque européenne pour les NAS distribués
Créé par une startup polonaise, le système de stockage Open source entend rivaliser avec les ténors des NAS extensibles que sont Qumulo ou Isilon.
Une alternative européenne aux solutions de stockage Qumulo et Dell Isilon (alias PowerScale). Telle est la définition que l’on pourrait donner de MooseFS, un système NAS distribué développé par la startup polonaise éponyme et que LeMagIT a pu rencontrer à l’occasion d’un événement IT Press Tour dédié aux acteurs européens qui innovent en matière de stockage.
« Comparativement à d’autres solutions de systèmes de fichiers distribués, c’est-à-dire qui supportent une élasticité maximale par simple ajout de nœuds, nous ne faisons que du logiciel. Et c’est ce que nos clients apprécient : nous ne leur imposons aucun matériel », dit Jakub Ratajczal, le PDG de la startup. Dans les faits, le système fonctionne sur n’importe quelle machine x86 ou ARM, y compris des Raspberry Pi et y compris des machines virtuelles.
La solution, aujourd’hui en version 4, est en développement depuis 2005, mais n’a vraiment débuté sa carrière commerciale qu’au début des années 2020.
Elle consiste à rassembler plusieurs serveurs bardés de disques durs ou de SSD en un cluster de stockage qui partage un seul volume de fichier sur le réseau. Ce type d’architecture, le NAS distribué, est particulièrement utilisé dans les studios de production vidéo, les médiathèques et les centres de recherche. Il leur permet d’étendre, au fil du temps et des documents produits, la taille d’un volume de stockage qui est partagé entre plusieurs stations ou postes de travail.
À date, MooseFS supporte jusqu’à 16 000 Po (16 Eo) de capacité et jusqu’à 2 milliards de fichiers par cluster.
L’autre fait saillant est que MooseFS est un produit Open source, librement installable par quiconque sans payer de licence. Il existe cependant une version « Pro » qui, elle, bénéficie d’un support de la part de l’éditeur et qui est facturée au nombre de disques. Le prix de cette licence est étendu au fur et à mesure que des disques sont ajoutés.
« Dans les faits, la version Open source nous sert d’accélérateur marketing, mais toutes les entreprises qui l’adoptent signent pour une version Pro. Car le stockage de données est quelque chose de critique pour une entreprise. Elle ne peut se permettre de ne pas avoir de support pour sa solution », avoue Jakub Ratajczal.
Un pilote propriétaire
Pour accéder au cluster de stockage, les machines clients ont besoin d’un pilote baptisé MFS-mount.
« Le volume que nous partageons est entièrement POSIX [avec tous les attributs des systèmes de fichiers Linux, NDR), mais nous n’utilisons pas le protocole NFS. Celui-ci n’est en effet pas résilient, il ne supporte pas qu’un nœud du cluster tombe en panne. Cela dit, si vous tenez à tout prix à utiliser depuis vos machines clientes les protocoles NFS, SMB ou même S3, il suffit de mettre entre elles et le cluster une passerelle proxy sur laquelle est installé le pilote et qui repartage le volume du cluster selon ces protocoles », précise Jakub Ratajczal.
Pour autant, l’usage d’un tel proxy n’est pas recommandé pour garantir la résistance du volume de données aux pannes. Seul le pilote assure à une machine cliente d’être redirigée vers un nœud fonctionnel en cas d’interruption de connexion.
Les données sont stockées sur des « chunkservers », littéralement des serveurs de morceaux de stockage, et directement transférables aux machines clientes via des liens Ethernet ou Infiniband directs. Ce ne sont pas ces serveurs-là qui partagent le volume sur le réseau. Le cluster est également composé de serveurs maîtres qui, eux, communiquent avec les pilotes MFS-mount pour présenter les répertoires, les noms de fichiers et les autorisations disponibles.
Lorsqu’ils reçoivent une requête pour lire ou écrire un fichier, ces serveurs maîtres indiquent au pilote sur quelle machine du cluster lire ou écrire. Ce mécanisme évite que le serveur de partage devienne un goulet d’étranglement, comme c’est le cas en NFS et en SMB. Il permet aussi d’ajouter des nœuds de stockage à la volée pour faire croître la capacité du cluster sans rien devoir interrompre ou redémarrer.
La startup précise qu’elle fait d’ailleurs tourner un cluster depuis 19 ans sans ne l’avoir jamais arrêté, alors que la capacité de celui-ci a régulièrement été augmentée, soit avec par l’ajout de nœuds, soit par le remplacement de disques durs. Toutefois, la démonstration faite par MooseFS au MagIT suggère qu’un nœud doit être temporairement mis en mode « maintenance », c’est-à-dire inaccessible à la production, lorsqu’on remplace ses disques.
Il est à noter que tous les serveurs du cluster fonctionnent sous Linux ou FreeBSD, les deux systèmes supportés par MooseFS. Aucun ne peut fonctionner sous Windows.
Des fonctions pour protéger les données
Les serveurs maîtres contiennent tous les mêmes métadonnées. Leur nombre sert juste à maintenir des accès parallèles entre les machines clientes et le cluster. Parmi ces serveurs, il en est tout de même un qui fait office de « leader », comprendre qui contient les métadonnées originales et les répliques sur tous les autres serveurs maîtres. Son rôle est aussi de maintenir à jour les verrous qui empêchent deux utilisateurs de modifier le même texte en même temps.
Pour des questions de performances, ces métadonnées sont toutes chargées dans la RAM des serveurs maîtres. Les serveurs maîtres synchronisent leurs métadonnées avec celles du serveur leader via des services baptisés Metaloggers.
« Si le leader venait à tomber en panne, MooseFS est capable d’attribuer en temps réel le rôle de leader à un autre serveur maître. Du moins dans la version Pro où tout est automatisé. La version Open source nécessite une intervention humaine dans ce cas de figure. Cela dit, il reste possible d’écrire des scripts pour automatiser de la même manière la version Open source », détaille Jakub Ratajczal.
En ce qui concerne les caractéristiques de haut niveau, citons la possibilité de synchroniser deux clusters distants, le support de centaines de milliers de requêtes par seconde, la possibilité de mélanger des équipements très différents et de leur attribuer des données chaudes ou froides selon leurs performances, ou encore la redondance des données (par Erasure coding) dans le cluster.
« Précisons que les machines clientes n’ont pas à répliquer elles-mêmes leurs écritures. Ce sont les serveurs maîtres qui se chargent de router en Y les écritures et qui, dans un second temps, appliquent des algorithmes d’Erasure coding pour stocker les données sous forme de fragments distribués sur plusieurs nœuds. De cette manière nous évitons au maximum les congestions entre les machines clients et le cluster de stockage », dit le PDG de la startup.
Dans la version Open source, les fichiers sont fragmentés sur huit disques, plus un disque de parité. Celui-ci sert à récupérer des données intactes quand n’importe lequel des huit autres disques tombe en panne. Cette caractéristique est réglable sur la version Pro.
Ce qui est aussi réglable, y compris dans la version Open source, c’est de conserver ou non, les répliques entières des fichiers qui ont été écrits en Y en première instance.
« En vérité, il n’est pas si rare que plusieurs disques tombent en panne en même temps. Pour la simple raison que les entreprises les achètent par lot. Or, si un disque a un défaut ou une faiblesse, il est probable que tous ceux du même lot l’aient aussi », dit Jakub Ratajczal, qui recommande de doubler la sécurité de l’Erasure coding par la conservation des répliques, surtout quand les différents nœuds qui les contiennent ont des disques de lots différents.
Enfin, sur le même principe, MooseFS sait geler ses contenus à un instant T sous la forme de snapshots. Les Snapshots servent à revenir à une version antérieure des fichiers. Un nouveau snapshot ne contient que les fichiers modifiés depuis celui créé précédemment, mais chaque snapshot référence l’intégralité des fichiers présents à un instant T dans le cluster.
Pour la suite, MooseFS planche sur la possibilité d’étendre le volume partagé entre plusieurs clusters, c’est-à-dire entre plusieurs sites géographiques.
