Système de fichiers de stockage distribué - Lequel / Y a-t-il un produit prêt à l'emploi?


31

Avec Hadoop et CouchDB partout dans les blogs et les actualités associées, qu'est-ce qu'un stockage (moteur) tolérant aux pannes qui fonctionne réellement?

  • CouchDB n'a pas de fonctionnalités de distribution intégrées, à ma connaissance, la colle pour distribuer automatiquement des entrées ou même des bases de données entières est tout simplement manquante.
  • Hadoop semble être très largement utilisé - au moins, il obtient une bonne presse, mais a toujours un seul point de défaillance: le NameNode. De plus, il ne peut être monté que via FUSE, je comprends que le HDFS n'est pas réellement l'objectif principal de Hadoop
  • GlusterFS a un concept de partage de rien, mais récemment j'ai lu plusieurs articles qui m'amènent à penser qu'il n'est pas aussi stable
  • Lustre a également un point de défaillance unique car il utilise un serveur de métadonnées dédié
  • Ceph semble être le joueur de choix, mais la page d'accueil indique qu'il est toujours en phase alpha.

La question est donc de savoir quel système de fichiers distribué possède l'ensemble de fonctionnalités suivant (sans ordre particulier):

  • Compatible POSIX
  • ajout / retrait facile des nœuds
  • concept de partage de rien
  • fonctionne sur du matériel bon marché (processeurs AMD Geode ou VIA Eden)
  • authentification / autorisation intégrée
  • un système de fichiers réseau (j'aimerais pouvoir le monter simultanément sur différents hôtes)

Agréable d'avoir:

  • fichiers accessibles localement: je peux prendre un nœud vers le bas monter la partition avec un système de fichiers local standard (ext3 / xfs / que ce soit ...) et toujours accéder aux fichiers

Je ne recherche pas d'applications hébergées, plutôt quelque chose qui me permettra de prendre par exemple 10 Go de chacun de nos boîtiers matériels et d'avoir ce stockage disponible sur notre réseau, facilement montable sur une multitude d'hôtes.


Alors, avec quoi vous êtes-vous retrouvé? Il serait intéressant de connaître votre configuration actuelle.
MattBianco

Lustre semble avoir ajouté des MDS actifs / passifs depuis que vous avez écrit ceci, il pourrait donc avoir besoin d'un autre regard.
pjz

D'après mon expérience, GlusterFS a été stable mais les performances sont assez médiocres. Pour de meilleures performances, vous aurez besoin d'un matériel haut de gamme, essentiellement RDMA. L'important est la latence entre tous les serveurs et la machine client GlusterFS.
Mikko Rantalainen

Réponses:


9

Je pense que vous devrez abandonner l'exigence POSIX, très peu de systèmes implémentent cela - en fait, même NFS ne le fait pas vraiment (pensez aux verrous, etc.) et cela n'a pas de redondance.

Tout système qui utilise la réplication synchrone va être glacialement lent; tout système qui a une réplication asynchrone (ou "cohérence éventuelle") va violer les règles POSIX et ne pas se comporter comme un système de fichiers "conventionnel".


Connaissez-vous des systèmes de fichiers qui prennent en charge à la fois la cohérence éventuelle et la cohérence stricte, peut-être qu'il pourrait être réglé pour les deux et créer 2 montures?
CMCDragonkai

16

Je ne peux pas parler du reste, mais vous semblez être confondu entre un «moteur de stockage distribué» et un «système de fichiers distribué». Ce ne sont pas la même chose, ils ne doivent pas être confondus avec la même chose, et ils ne seront jamais la même chose. Un système de fichiers est un moyen de garder une trace de l'emplacement des éléments sur un disque dur. Un moteur de stockage comme hadoop est un moyen de garder une trace d'un bloc de données identifié par une clé. Conceptuellement, pas beaucoup de différence. Le problème est qu'un système de fichiers est une dépendance d'un moteur de stockage ... après tout, il a besoin d'un moyen d'écrire sur un périphérique bloc, n'est-ce pas?

Tout cela mis à part, je peux parler de l'utilisation d'ocfs2 en tant que système de fichiers distribué dans un environnement de production. Si vous ne voulez pas les détails granuleux, arrêtez de lire après cette ligne: c'est plutôt cool, mais cela peut signifier plus de temps d'arrêt que vous ne le pensez.

Nous exécutons ocfs2 dans un environnement de production depuis quelques années. C'est OK, mais ce n'est pas génial pour beaucoup d'applications. Vous devriez vraiment regarder vos besoins et comprendre ce qu'ils sont - vous pourriez constater que vous avez beaucoup plus de latitude pour les défauts que vous ne le pensiez.

Par exemple, ocfs2 a un journal pour chaque machine du cluster qui va monter la partition. Supposons donc que vous ayez quatre machines Web, et lorsque vous effectuez cette partition à l'aide de mkfs.ocfs2, vous spécifiez qu'il y aura six machines au total pour vous donner de la place pour vous développer. Chacun de ces journaux prend de l'espace, ce qui réduit la quantité de données que vous pouvez stocker sur les disques. Maintenant, disons que vous devez évoluer vers sept machines. Dans cette situation, vous devez retirer l' ensemblecluster (c'est-à-dire démonter toutes les partitions ocfs2) et utiliser l'utilitaire tunefs.ocfs2 pour créer un journal supplémentaire, à condition qu'il y ait de l'espace disponible. Ensuite et seulement à ce moment-là, vous pouvez ajouter la septième machine au cluster (ce qui vous oblige à distribuer un fichier texte au reste du cluster à moins que vous n'utilisiez un utilitaire), à ​​tout restaurer, puis à monter la partition sur les sept Machines.

Tu vois ce que je veux dire? C'est censé être une haute disponibilité, ce qui signifie `` toujours en ligne '', mais là, vous avez un tas de temps d'arrêt ... et Dieu nous en préserve, vous êtes bondé d'espace disque. Vous ne voulez PAS voir ce qui se passe lorsque vous encombrez ocfs2.

Gardez à l'esprit que evms, qui était la méthode `` préférée '' pour gérer les clusters ocfs2, a pris le chemin de l'oiseau dodo en faveur de clvmd et lvm2. (Et bon débarras des evms.) De plus, le rythme cardiaque va rapidement se transformer en un projet zombie en faveur de la pile openais / pacemaker. (En plus: lors de la configuration initiale du cluster pour ocfs2, vous pouvez spécifier 'pcmk' comme moteur de cluster par opposition à Heartbeat. Non, cela n'est pas documenté.)

Pour ce que ça vaut, nous sommes revenus à nfs géré par pacemaker, car les quelques secondes de temps d'arrêt ou quelques paquets tcp abandonnés pendant que le pacemaker migre un partage nfs vers une autre machine sont triviaux par rapport à la quantité de temps d'arrêt que nous voyions pour la base opérations de stockage partagé comme l'ajout de machines lors de l'utilisation d'ocfs2.


2
Je voulais juste dire que c'est exactement mon expérience avec OCFS2 / Pacemaker vs NFS. Après avoir essayé OCFS2 comme magasin de données en cluster pendant un certain temps, je l'ai trouvé extrêmement manquant. Pendant ce temps, notre système HA NFS fonctionne comme un charme.
Kamil Kisiel le

1
OCFS2 n'est certainement pas ce que je regarde. Par distribué, je ne veux pas dire quelque chose avec une instance centrale de stockage mais plutôt quelque chose où je peux facilement ajouter / supprimer des nœuds qui fournissent du stockage tout en restant avec le reste du "cluster"
serverhorror

2
Comme je reçois toujours des votes positifs sur cette réponse, je dois ajouter que nous utilisons maintenant GlusterFS en production en remplacement de nfs. Cependant, nous ne stockons PAS d'images de disque de machine virtuelle, de fichiers de stockage de base de données (sqlite ou myisam ou autre), ou d'autres fichiers susceptibles de changer fréquemment sur glusterfs car cela provoque des coups de fouet de réplication. Ceux que nous stockons localement sur des hôtes VM dans LVM et utilisons DRBD pour les distribuer aux sites de basculement, ou utilisons la réplication intégrée.
Karl Katzke


3

Juste pour jeter mes 0,02 € ici: OpenAFS ne peut-il pas faire ce que vous voulez?



3

Que diriez - vous XtreemFS ? la version 1.4 (novembre 2012) est considérée comme Qualité de production.

Il est compatible POSIX et possède une tolérance aux pannes automatique exceptionnelle.


2

Lustre permet de stocker plusieurs métadonnées dans une configuration active / passive pour la redondance, donc pas de point de défaillance unique.

OCFS2 pourrait également être intéressant à regarder.

Notez que la suppression de la nécessité de plusieurs accès réseau simultanés permet de basculer vers quelque chose comme iSCSI ou même cifs ou nfs. L'inconvénient est que vous devez «découper» des morceaux de votre uberArray en bouchées pour chaque serveur qui a besoin d'espace.


2

À moins que ce ne soit à des fins académiques / de développement, ce genre de chose devrait être abordé en commençant par les exigences générales du projet. La plupart des systèmes de fichiers distribués ne sont pas suffisamment matures pour un déploiement sérieux - par exemple, que faites-vous si le tout s'effrite. Si c'est à des fins académiques / de développement, c'est en fait une bonne chose car vous pourriez en apprendre beaucoup et corriger de nombreux bugs.

Le commentaire demandant si vous avez vraiment besoin de la sémantique POSIX est un bon début. La sémantique des «systèmes de fichiers» non POSIX peut être beaucoup plus flexible, conduisant à des systèmes beaucoup plus fiables.

S'il s'agit d'une application héritée, je me demande vraiment pourquoi un système de fichiers distribué moderne pourrait être considéré comme la meilleure solution.

Ne vous méprenez pas - ce sont des jouets incroyablement amusants. Je ne voudrais tout simplement pas être responsable d'une solution interdépendante complexe qui n'est pas couramment utilisée et serait très difficile à corriger lorsqu'elle disparaîtra.


1

Avez-vous vraiment, absolument absolument besoin d'une sémantique POSIX? La vie devient beaucoup plus facile si vous pouvez utiliser une banque de données personnalisée. Nous avons un magasin de données écrit en interne qui est en fait un très grand magasin de valeurs-clés distribué. Vous y stockez un fichier et vous obtenez un jeton. Si vous souhaitez récupérer le fichier, donnez-lui le jeton qui vous a été donné plus tôt. Il est distribué, ne partage rien, les données sont répliquées trois fois, des nœuds peuvent être ajoutés et supprimés à volonté, à la fois des serveurs de stockage et des serveurs de contrôle.


Malheureusement, j'ai vraiment besoin de la sémantique POSIX. Nous avons de nombreuses "applications héritées" qui stockent des éléments dans le système de fichiers local. Réécrire tout cela est définitivement en dehors de tout budget
serverhorror

Je suppose que vous allez devoir abandonner certaines de vos autres exigences. Je regarderais GlusterFS, Luster, OCFS2, GFS, mais je doute que vous en trouviez un qui n'a rien partagé.
David Pashley

en.wikipedia.org/wiki/… répertorie les systèmes de fichiers distribués, mais très peu d'entre eux sont POSIX.
David Pashley

Il y a longtemps, j'utilisais une variante d'AFS (ce qui est maintenant OpenAFS). Cela a fonctionné mais était complexe et avait son propre ensemble de bizarreries.
Jauder Ho

1

Lustre a également un point de défaillance unique car il utilise un serveur de métadonnées dédié

Lustre est conçu pour prendre en charge le basculement et un MDS / MDT / OSS peut avoir un certain nombre d'adresses auxquelles il peut être contacté, le battement de cœur peut être utilisé pour migrer le service.

Sachez que certaines versions récentes ont eu des problèmes où le démontage semble fonctionner mais qu'il y a encore des données en vol sur le disque, mais la protection à double montage aurait dû aider (à part les problèmes intéressants qui ont eu) ...


1

Je vous recommande d'utiliser MooseFS (système de fichiers distribué tolérant aux pannes, évolutif et réseau). Il est compatible POSIX et depuis la version 1.6, MooseFS propose une authentification / autorisation simple, de type NFS. Voir également la configuration matérielle requise .

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.