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

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.

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".

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.

Je comprends peut-être mal vos besoins, mais avez-vous consulté http://en.wikipedia.org/wiki/List_of_file_systems#Distributed_file_systems

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

Jetez un œil à chirp http://www.cse.nd.edu/~ccl/software/chirp/ et parrot http://www.cse.nd.edu/~ccl/software/parrot/

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.

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.

À 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.

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.

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) ...

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 .