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

Je ne peux pas parler pour le reste, mais vous semblez être confus 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, et ils ne seront jamais la même chose. Un système de fichiers est une manière de garder une trace de l'emplacement des choses sur un disque dur. Un moteur de stockage comme Hadoop est une manière de garder une trace d'un morceau 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'une manière d'écrire sur un périphérique de bloc, n'est-ce pas ?

En dehors de tout cela, je peux parler de l'utilisation de ocfs2 en tant que système de fichiers distribué dans un environnement de production. Si vous ne voulez pas les détails techniques, 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 utilisons ocfs2 dans un environnement de production depuis ces dernières années. C'est correct, mais ce n'est pas génial pour beaucoup d'applications. Vous devriez vraiment examiner vos besoins et comprendre ce qu'ils sont -- vous pourriez découvrir que vous avez beaucoup plus de latitude pour les erreurs que vous ne le pensiez.

Par exemple, ocfs2 a un journal pour chaque machine dans le cluster qui va monter la partition. Donc, imaginons que vous avez quatre machines web, et lorsque vous créez cette partition en utilisant mkfs.ocfs2, vous spécifiez qu'il y aura six machines au total pour vous donner de la marge de croissance. 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, imaginons que vous devez passer à sept machines. Dans cette situation, vous devez arrêter l'intégralité du cluster (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 ensuite, 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), remettre tout en marche, puis monter la partition sur les sept machines.

Vous voyez ce que je veux dire ? C'est censé être une haute disponibilité, ce qui est censé signifier 'toujours en ligne', mais là vous avez déjà pas mal de temps d'arrêt... et le ciel nous préserve si vous manquez d'espace disque. Vous NE voulez pas voir ce qui se passe lorsque vous manquez d'espace avec ocfs2.

Gardez à l'esprit qu'evms, qui était autrefois le moyen 'préféré' de gérer les clusters ocfs2, a disparu au profit de clvmd et lvm2. (Tant mieux pour evms.) De plus, heartbeat va rapidement devenir un projet zombie au profit de la pile openais/pacemaker. (Remarque : Lors de la configuration initiale du cluster pour ocfs2, vous pouvez spécifier 'pcmk' comme moteur de cluster au lieu de heartbeat. Non, ce n'est pas documenté.)

Pour ce que cela vaut, nous sommes revenus au nfs géré par pacemaker, car les quelques secondes de temps d'arrêt ou quelques paquets tcp perdus lorsque pacemaker migre un partage nfs vers une autre machine sont négligeables par rapport à la quantité de temps d'arrêt que nous avons constatée pour des opérations basiques de stockage partagé comme l'ajout de machines lorsque nous utilisions ocfs2.

Je pourrais mal comprendre vos exigences, mais avez-vous consulté http://en.wikipedia.org/wiki/List_of_file_systems#Distributed_file_systems

Juste pour ajouter mes €0.02 ici : ne peut pas OpenAFS faire ce que vous voulez?

Jetez un œil à chirp et parrot