MooseFS, une nouvelle marque européenne pour les NAS distribués

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.