La traînée de poudre

LizardFS est un système de fichiers en nuage libre développé depuis 2012. Il dérive étroitement de MooseFS, et contrairement à à ce dernier il n’y a pas de fonctionnalités limitées dans la version libre (serveur de métadonnées en haute disponibilité, gestion de redondance avancée).

Architecture

Le système de fichiers est architecturé selon un mode classique. Les différents composants sont:

• les “Chunk Servers” qui fournissent le stockage proprement dit. Le stockage s’appuie sur un système de fichiers local standard.
• un “Master Server” qui tient le rôle classique de serveur de métadonnées, qui gère le nommage des objets, l’accès, l’orientation des clients vers le serveur “chunk” contenant les données recherchées.
• un “Metalogger Server” qui gère une liste des opérations en cours afin de pouvoir reprendre sur incident en cas de coupure brutale du “Master Server”.
• en option, un ou plusieurs “Shadow Servers” qui sont des serveurs de métadonnées de secours, afin de pouvoir prendre le relai du “Master Server” en cas de problème.
  • et finalement le client FUSE qui permet de monter le système de fichiers localement.

Bien sûr un serveur physique peut assumer simultanément la fonction de “Chunk Server” et de “Master”, “Metalogger” ou “Shadow Server”, ainsi qu’être client.

Le stockage local va généralement s’appuyer sur des grappes RAID. La redondance au niveau de la grappe de serveur va donc s’ajouter à une éventuelle redondance RAID locale.

La configuration de la grappe est assez simple et décrite dans la documentation LizardFS.

Notez qu’il est très facile de définir des modes de sécurité différents pour différentes parties du système de fichiers global. La granularité s’effectue au niveau du dossier ou même du fichier.

Interface utilisateur

LizardFS s’utilise avec des outils en ligne de commande assez simples, et fournit une interface web commode pour surveiller l’état de la grappe dans tous ses aspects.

L’administration utilise essentiellement les commandes lizardfs et lisardfs-admin pour modifier les paramètres de la grappe.

La commande lizardfs-admin communique avec le Master Server pour modifier les paramètres globaux, par exemple:

lizardfs-admin list-goals  

La commande lizardfs s’applique à des objets du système de fichiers et permet par exemple de définir le niveau de redondance pour un dossier, un fichier, etc. Exemple:

lizardfs setgoal -r important_file /mnt/lizardfs/IMPORTANT

Côté client, le montage se résume à :

mfsmount -o big_writes,nosuid,nodev,noatime /mnt/lizardfs

Pour améliorer les performances en lecture, on pourra ajouter quelques options:

mfsmount -o big_writes,nosuid,nodev,noatime -o cacheexpirationtime=500 -o readaheadmaxwindowsize=4096 /mnt/lizardfs

L’utilisation est globalement très simple pour un administrateur Linux.

L’interface web présente l’ensemble des états sous forme d’onglets, il est possible d’afficher plusieurs onglets simultanément en appuyant sur le petit “+”. Voici l’ensemble des écrans (cliquez pour agrandir):

Configuration testée

La configuration testée comprend 5 “Chunk Servers”. Un d’entre eux est également “Master”, un autre “Metalogger” et un troisième “Shadow Server”. Tous sont clients de la grappe. Une sixième machine identique est également utilisée comme client, soit via le module FUSE LizardFS, soit via un partage Samba du volume LizardFS depuis un des membres de la grappe.

Chaque machine comporte 16 disques de 8 To agrégés en RAID logiciel Linux (md-raid) d’un processeur Xeon D1541 2,1 Ghz 8 cœurs et de 16 Go de RAM et est connectée au réseau en 10 Gigabit ethernet.

La performance disque des serveurs seuls a été mesurée préalablement :

RAID-6 de 16x 8 To

• écriture : 800 Mo/s (limité par le processeur)
• lecture : 2400 Mo/s (1 flux), 1880 Mo/s (4 flux)

4 RAID-0 de 4x 8 To

• écriture : 1800 Mo/s
• lecture : 2500 Mo/s

Afin de comparer la performance relative du RAID-6 local et des différents mode de redondance de LizardFS, nous avons effectué un premier test avec les disques en RAID-6 sur les serveurs, et sans redondance au niveau de la grappe. Pour les tests suivants, nous avons reconfigurés les disques en 4 grappe RAID-0 de 4 disques, afin de maximiser la performance disque locale, afin de comparer les modes de redondances suivants:

• aucune redondance : pour référence. Évidemment à ne pas utiliser en production!
• réplication x2 : chaque bloc de données est répliqué sur deux “chunks” différents. C’est un mode “miroir”.
• XOR 3+1 : un bloc de parité est créé pour 3 blocs de données. Chacun des 4 blocs est écrit sur un “chunk” différent. C’est équivalent à un “RAID-5 de serveurs”
• Erasure Coding 3+2 : deux blocs de parité sont créés pour 3 blocs de données. Chacun des 5 blocs est écrit sur un “chunk” différent. C’est équivalent à un “RAID-6 de serveurs”.

Les tests se concentreront sur la performance séquentielle.

Les Tests

Test 1: RAID-0, pas de redondance

Le but de ce test est de définir une performance maximum, limitée par la bande passante réseau et disque. C’est notre point de référence, mais bien entendu n’utilisez pas une telle configuration en production, ce serait très risqué.

Test 2: RAID-6 local, pas de redondance de grappe

Ce test permet d’évaluer l’efficacité relative du calcul de parité réparti au niveau de la grappe par rapport à un calcul de parité local sur chaque serveur. Ce mode autorise la perte d’un ou deux disques par serveur, par contre en cas de panne d’un serveur entier la grappe sera inopérante.

Test 3: RAID-0, réplication x2

Ce mode de réplication sera sans doute favorisé pour les données les plus importantes. Il est le plus simple et dans notre cas, le plus rapide, surtout en lecture. Le facteur limitant semble être ici la bande passante réseau entre les nœuds.

Test 4: RAID-0, redondance XOR 3+1

Ce mode de redondance autorise la panne d’un “chunk” complet (typiquement, un serveur ou un volume RAID).

Test 5: RAID-0, redondance Erasure Coding 3+2

Ce mode de redondance autorise la panne de deux “chunks”. Bien que la documentation fasse état d’une performance optimale dans ce mode, la forte charge processeur limite la performance, particulièrement en écriture.

Test 6: RAID-6 local, pas de redondance, partage SMB

Le résultat de ce test est à comparer au test 2. Un seul client a été utilisé, mais accédant au volume via un montage SMB plutôt qu’en utilisant le client LizardFS. La performance est nettement inférieure, mais encore très satisfaisante.

Conclusion

La facilité de déploiement et d’utilisation de LizardFS en font un bon candidat pour des systèmes de stockage très massifs, destinés à l’archivage mais également à la production. Lors de prochains tests, nous évaluerons le comportement en cas de panne de nœud et d’extension de la grappe par ajout de nouveaux systèmes. Il sera également intéressant de comparer LizardFS à ses principaux concurrents.