Systèmes de fichiers distribués: GridFS vs GlusterFS vs Ceph vs HekaFS Benchmarks
Je recherche actuellement un bon système de fichiers distribué.
Cela devrait:
- être open-source
- être évolutif horizontalement (réplication et partitionnement)
- n'ont pas de point de défaillance unique
- avoir une empreinte relativement petite
Voici les quatre candidats les plus prometteurs à mon avis:
Le système de fichiers sera principalement utilisé pour les fichiers multimédias (images et audio). Il existe des fichiers très petits et de taille moyenne (1 Ko - 10 Mo). La quantité de fichiers devrait être de plusieurs millions.
Existe-t-il des points de référence concernant les performances , Charge CPU , consommation de mémoire et évolutivité ? Quelle est votre expérience de l'utilisation de ces systèmes de fichiers ou d'autres systèmes distribués?
Je ne suis pas sûr que votre liste soit tout à fait correcte. Cela dépend de ce que vous entendez par système de fichiers.
Si vous voulez dire un système de fichiers qui peut être monté dans un système d'exploitation et utilisable par n'importe quelle application qui lit et écrit des fichiers à l'aide d'appels POSIX, alors GridFS n'est pas vraiment qualifié. C'est juste comment MongoDB stocke les objets au format BSON. Il s'agit d'un système d'objets plutôt que d'un système de fichiers.
Il y a n projet pour rendre GridFS montable , mais c'est un peu bizarre parce que GridFS n'a pas de concepts pour des choses comme les répertoires hiérarchiques, bien que les chemins soient autorisés. De plus, je ne sais pas comment les écritures distribuées sur gridfs-Fuse seraient.
GlusterFS et Ceph sont comparables et sont des systèmes de fichiers montables et réplicables distribués. Vous pouvez lire une comparaison entre les deux ici (et mise à jour de suivi de la comparaison ), mais gardez à l'esprit que les benchmarks sont effectués par quelqu'un qui est un peu biaisé. Vous pouvez également regarder ce débat sur le sujet .
Quant à HekaFS, c'est GlusterFS qui est configuré pour le cloud computing, en ajoutant le chiffrement et la mutualisation ainsi qu'une interface utilisateur administrative.
Après avoir travaillé avec Ceph pendant 11 mois, je suis arrivé à la conclusion que ça craint complètement donc je suggère de l'éviter. J'ai essayé XtreemFS, RozoFS et QuantcastFS mais je ne les ai pas trouvés assez bons non plus.
Je recommande de tout cœur LizardFS qui est un fork de maintenant propriétaire MooseFS. LizardFS présente l'intégrité des données, la surveillance et des performances supérieures avec très peu de dépendances.
Mise à jour 2019 : la situation a changé et LizardFS n'est plus activement maintenu.
MooseFS est plus fort que jamais et exempt de la plupart des bogues LizardFS. MooseFS est bien entretenu et plus rapide que LizardFS.
RozoFS a mûri et mérite peut-être un essai.
GfarmFS a sa niche mais aujourd'hui j'aurais choisi MooseFS pour la plupart des applications.
OrangeFS, quelqu'un?
Je recherche un DFS HPC et j'ai trouvé cette discussion ici: http://forums.gentoo.org/viewtopic-t-901744-start-0.html
Beaucoup de bonnes données et comparaisons :)
Après quelques discussions, l'OP a décidé pour OrangeFS, en citant: "OrangeFS. Il ne prend pas en charge les quotas ni les verrous de fichiers (bien que toutes les opérations d'E/S soient atomiques et que la cohérence soit conservée sans verrous). Mais cela fonctionne, et fonctionne bien et stable . De plus, il ne s'agit pas d'un système général de stockage de fichiers, mais d'un système dédié HPC, ciblé sur les E/S parallèles, y compris le support ROMIO. Tous les tests ont été effectués pour la distribution des données par bandes. A) Pas de quotas - aux quotas infernaux. J'ai abandonné. de toute façon, même glusterfs ne prend pas en charge les quotas basés sur uid/gid, mais les limitations de taille de répertoire, plus comme LVM fonctionne. b) Plusieurs serveurs de métadonnées actifs sont pris en charge et stables. Par rapport au stockage de métadonnées dédié (nœud unique), cela donne + 50% de performances sur petits fichiers et pas de différence significative sur les gros c) Excellentes performances sur les gros morceaux de données (dd bs = 1M) Il est limité par une somme de disque dur local (n'oubliez pas que chaque nœud participe également en tant que serveur de données) et la bande passante réseau disponible. la consommation sur une telle charge est décente et représente environ 50% du cœur unique sur un nœud client et environ 10% en pourcentage sur les autres nœuds du serveur de données. d) Performances satisfaisantes sur de grands ensembles de petits fichiers. Pour le test, j'ai dénoué le noyau Linux 3.1. Il a fallu 5 minutes sur OrangeFS (avec des paramètres réglés) et près de 2 minutes sur NFSv4 (également réglé) pour la comparaison. La charge du processeur représente environ 50% du cœur unique (bien sûr, il est en fait distribué entre les cœurs) sur le client et environ plusieurs pourcentages sur chaque nœud. e) Prise en charge de ROMIO MPI API d'E/S. Ceci est un délicieux délicieux pour les applications sensibles à MPI, qui permet d'utiliser les entrées-sorties parallèles PVFS2/OrangeFS) fonctionnalités directement à partir des applications. f) Pas de prise en charge des fichiers spéciaux (sockets, fifo, blocs périphériques) .Par conséquent, ne peut pas être utilisé en toute sécurité comme/home et j'utilise NFSv4 pour cette tâche en fournissant aux utilisateurs un petit espace domestique limité en quota. les systèmes de fichiers ne prennent pas en charge les fichiers spéciaux de toute façon. "
Je ne connais pas les autres systèmes que vous avez publiés, mais j'ai fait une comparaison de 3 PHP CMS/Frameworks sur le stockage local vs GlusterFS pour voir si cela fait mieux sur les tests du monde réel que sur les benchmarks bruts. Malheureusement pas.
http://blog.lavoie.sl/2013/12/glusterfs-performance-on-different-frameworks.html