Après une année de silence dans le développement, sur une nouvelle version du système de fichiers distribué résilient et deuxième candidat pour les sorties. Récemment, à la suite d'un changement de direction de l'entreprise développant LizardFS, une nouvelle équipe de direction a été mise en place et les développeurs ont changé. Au cours des deux dernières années, le projet s'est éloigné de la communauté et n'a pas consacré l'attention nécessaire, mais la nouvelle équipe a l'intention de raviver les anciennes relations avec la communauté et d'établir une interaction étroite. Le code du projet est écrit en C et C++ et sous licence GPLv3.
LizardFS est un système de fichiers distribué en cluster qui permet de répartir les données sur différents serveurs tout en offrant un accès à ces données sous la forme d'une grande partition unique, avec laquelle on interagit de façon similaire aux partitions de disque traditionnelles. La partition montée avec LizardFS prend en charge les attributs de fichiers POSIX, les ACL, les verrous, les sockets, les canaux, les fichiers de périphériques, ainsi que des liens symboliques et durs. Le système n'a pas de point de défaillance unique, tous les composants sont redondés. Il permet le parallélisme des opérations sur les données (plusieurs clients peuvent accéder simultanément aux fichiers).
Pour garantir la résilience, les données sont divisées en répliques qui sont réparties sur différents nœuds avec redondance (plusieurs copies sont placées sur différents nœuds). En cas de défaillance de nœuds ou de disques, le système continue de fonctionner sans perte d'informations et redistribue automatiquement les données en fonction des nœuds restants. Pour étendre le stockage, il suffit de connecter de nouveaux nœuds sans arrêter le service (le système réplique automatiquement une partie des données sur les nouveaux serveurs et équilibre le stockage en tenant compte des nouveaux serveurs). De même, il est possible de réduire la taille du cluster en déconnectant simplement l'équipement obsolète.
Les données et les métadonnées sont stockées séparément. Il est recommandé d'installer deux serveurs de métadonnées fonctionnant en mode maître-esclave, ainsi qu'au moins deux serveurs de stockage de données (chunkserver). De plus, des serveurs de journaux peuvent être utilisés pour sauvegarder les métadonnées, en stockant les informations relatives aux modifications des métadonnées et permettant de rétablir le fonctionnement en cas de défaillance de tous les serveurs de métadonnées disponibles. Chaque fichier est divisé en blocs (chunks) d'une taille allant jusqu'à 64 Mo. Les blocs sont répartis entre les serveurs de stockage en fonction du mode de réplication choisi : standard (définition explicite du nombre de copies à placer sur différents nœuds, y compris en lien avec des répertoires spécifiques — pour les données importantes, le nombre de copies peut être augmenté, tandis que pour les données non essentielles, il peut être réduit), XOR (RAID5) et EC (RAID6).
Le stockage peut être dimensionné jusqu'à plusieurs pétaoctets. Parmi ses applications, on mentionne la tenue d'archives, le stockage d'images de machines virtuelles, de données multimédias, de sauvegardes, ainsi que son utilisation en tant que DRC (Centre de Récupération après Sinistre) et comme stockage dans des clusters de calculs haute performance. LizardFS offre une très grande vitesse de lecture de fichiers de toute taille, et lors de l'écriture, il montre de bonnes performances pour l'écriture complète de gros et moyens fichiers, lorsqu'il n'y a pas de modification constante, d'accès intensif à des fichiers ouverts et d'opérations ponctuelles avec une multitude de petits fichiers.
Parmi les caractéristiques du système de fichiers, on peut également noter la prise en charge des snapshots, reflétant l'état des fichiers à un moment donné, et la mise en œuvre intégrée d'une « corbeille » (les fichiers ne sont pas supprimés immédiatement et restent disponibles pour la restauration durant un certain temps). L'accès à la section peut être limité par adresse IP ou mot de passe (similaire à NFS). Des mécanismes de quotas et de gestion de la qualité de service permettent de limiter la taille et la bande passante pour certaines catégories d'utilisateurs. Il est possible de créer des stockages géographiquement dispersés dont les segments sont hébergés dans différents centres de données.
Le projet LizardFS a été fondé en 2013 comme un fork , et se distingue principalement par la présence d'un mode de réplication basé sur les codes de correction d'erreurs de Reed-Solomon (analogue de raidzN), d'un support élargi pour l'ACL, d'un client pour la plateforme Windows, de certaines optimisations (par exemple, lors de la combinaison du client et du serveur de stockage, les blocs sont délivrés autant que possible depuis le nœud actuel, tandis que les métadonnées sont mises en cache en mémoire), d'un système de configuration plus flexible, d'un support pour la prélecture des données, de quotas sur les répertoires et de retravaillages internes.
La sortie de LizardFS 3.13.0 est prévue pour fin décembre. La principale nouveauté de LizardFS 3.13 est l'utilisation d'un algorithme de consensus pour assurer la résilience (basculement des serveurs principaux en cas de défaillance). (une implémentation propre de uRaft est utilisée, qui était précédemment appliquée dans des produits commerciaux). L'utilisation de uRaft facilite la configuration et réduit les délais de récupération après une défaillance, mais nécessite au moins trois nœuds opérationnels, dont un est utilisé pour le quorum.
Parmi les autres changements : un nouveau client basé sur le sous-système FUSE3, la résolution des problèmes de correction des erreurs, le plugin nfs-ganesha a été réécrit en C. Dans la mise à jour 3.13.0-rc2, plusieurs bogues critiques ont été corrigés, rendant les versions bêta précédentes de la branche 3.13 peu utilisables (les corrections pour la branche 3.12 n'ont pas encore été publiées, et la mise à jour de 3.12 à 3.13 entraîne toujours une perte totale de données).
En 2020, le travail se concentrera sur le développement
, un nouveau cœur entièrement réécrit de LizardFS, qui, selon les développeurs, garantira une augmentation des performances par rapport à la branche 3.12, multipliée par trois. Dans Agama, une transition vers une architecture orientée événements sera effectuée (event driven), avec une entrée/sortie asynchrone basée sur , et un fonctionnement principalement dans l'espace utilisateur (pour réduire la dépendance aux mécanismes de mise en cache du noyau). De plus, un nouveau sous-système de débogage et un analyseur d'activité réseau avec support pour l'auto-optimisation des performances seront proposés.
Le client LizardFS bénéficiera d'un support complet des opérations d'écriture avec versionnage, ce qui améliorera la fiabilité de la récupération après sinistre, résoudra les problèmes liés à l'accès simultané de différents clients aux mêmes données et permettra d'atteindre une augmentation significative des performances. Le client sera transféré vers un sous-système réseau propre, fonctionnant dans l'espace utilisateur. Le premier prototype opérationnel de LizardFS basé sur Agama devrait être prêt au deuxième trimestre de 2020. À ce moment-là, des outils pour intégrer LizardFS à la plateforme Kubernetes seront également promises.
Source : opennet.ru
