在博客和相关新闻中到处都是Hadoop和CouchDB，什么是真正有效的分布式容错存储（引擎）。
- CouchDB 实际上并没有内置任何分发功能，据我所知，自动分发条目甚至整个数据库的粘合剂根本就没有了。
- Hadoop 似乎被广泛使用——至少它得到了很好的报道，但仍然有一个单点故障：NameNode。另外，它只能通过 FUSE 安装，我知道 HDFS 实际上并不是 Hadoop 的主要目标
- GlusterFS确实有一个无共享的概念，但最近我读了几篇文章，让我认为它不太稳定
- Lustre还存在单点故障，因为它使用专用的元数据服务器
- Ceph似乎是首选播放器，但主页显示它仍处于 alpha 阶段。
所以问题是哪个分布式文件系统具有以下功能集（没有特定顺序）：
- POSIX 兼容
- 轻松添加/删除节点
- 无共享概念
- 在廉价硬件（AMD Geode 或 VIA Eden 类处理器）上运行
- 内置身份验证/授权
- 一个网络文件系统（我希望能够在不同的主机上同时挂载它）
很高兴有：
- 本地可访问的文件：我可以使用标准本地文件系统（ext3/xfs/whatever...）将一个节点挂载到分区并仍然可以访问这些文件
我不是在寻找托管应用程序，而是让我能够占用我们每个硬件盒的 10GB 并在我们的网络中使用该存储，并且可以轻松地安装在多个主机上的东西。
我无法与其他人交谈，但您似乎对“分布式存储引擎”和“分布式文件系统”感到困惑。它们不是同一种东西，它们不应该被误认为是同一种东西，它们永远不会是同一种东西。文件系统是一种跟踪事物在硬盘驱动器上的位置的方法。像 hadoop 这样的存储引擎是一种跟踪由键标识的数据块的方法。从概念上讲，差别不大。问题是文件系统是存储引擎的依赖项......毕竟，它需要一种写入块设备的方法，不是吗？
除此之外，我可以谈谈在生产环境中使用 ocfs2 作为分布式文件系统。如果您不想要粗暴的细节，请在此行之后停止阅读：这有点酷，但它可能意味着比您想象的更多的停机时间。
在过去的几年里，我们一直在生产环境中运行 ocfs2。没关系，但是对于很多应用程序来说并不是很好。你真的应该看看你的需求并弄清楚它们是什么——你可能会发现你有比你想象的更多的错误余地。
例如，ocfs2 对集群中将要挂载分区的每台机器都有一个日志。因此，假设您有四台 Web 机器，当您使用 mkfs.ocfs2 进行分区时，您指定总共将有六台机器给自己一些增长空间。这些日志中的每一个都占用空间，从而减少了可以存储在磁盘上的数据量。现在，假设您需要扩展到七台机器。在这种情况下，您需要取下整个集群（即卸载所有 ocfs2 分区）并使用 tunefs.ocfs2 实用程序创建一个额外的日志，前提是有可用空间。然后，只有这样，您才能将第七台机器添加到集群（这要求您将文本文件分发到集群的其余部分，除非您使用实用程序），恢复所有内容，然后在所有七台机器上安装分区机器。
明白了吗？它应该是高可用性，这应该意味着“始终在线”，但是在那里你有很多停机时间......上帝禁止你为磁盘空间而拥挤。您不想看到拥挤 ocfs2 时会发生什么。
请记住，曾经是管理 ocfs2 集群的“首选”方式的 evms 已经走上了渡渡鸟的道路，取而代之的是 clvmd 和 lvm2。（并且很好地摆脱了 evms。）此外，heartbeat 很快就会变成一个僵尸项目，有利于 openais/pacemaker 堆栈。（旁白：在为 ocfs2 进行初始集群配置时，您可以将“pcmk”指定为集群引擎，而不是心跳。不，这没有记录。）
对于它的价值，我们已经回到由起搏器管理的 nfs，因为与我们看到的基本停机时间相比，起搏器将 nfs 共享迁移到另一台机器时的几秒钟停机时间或一些丢弃的 tcp 数据包是微不足道的使用 ocfs2 时的共享存储操作，例如添加机器。
我认为您将不得不放弃 POSIX 要求，很少有系统实现这一点 - 事实上，即使 NFS 也不是真的（想想锁等）并且没有冗余。
任何使用同步复制的系统都会非常缓慢；任何具有异步复制（或“最终一致性”）的系统都将违反 POSIX 规则，并且其行为不像“传统”文件系统。
我可能误解了你的要求，但你看过http://en.wikipedia.org/wiki/List_of_file_systems#Distributed_file_systems
只是把我的 0.02 欧元扔在这里：OpenAFS不能做你想做的事吗？
看看啁啾http://www.cse.nd.edu/~ccl/software/chirp/和鹦鹉http://www.cse.nd.edu/~ccl/software/parrot/
Xtreemfs怎么样？1.4 版（2012 年 11 月）被认为是生产质量。
它与 POSIX 兼容，并具有出色的自动容错能力。
Lustre 允许在主动/被动配置中使用多个元数据存储以实现冗余，因此不会出现单点故障。
OCFS2 也可能值得一看。
请注意，消除对多个同时网络访问的要求使得可以切换到 iSCSI 甚至 cifs 或 nfs 之类的东西。不利的一面是，您必须为每个需要空间的服务器将 uberArray 的各个部分“分割”成小块。
除非是出于学术/开发目的，否则应该从项目的总体要求开始处理这种事情。大多数分布式文件系统还不够成熟，无法进行认真的部署——例如，如果整个事情都崩溃了，你会怎么做。如果是出于学术/开发目的，那么这实际上是一件好事，因为您可以学到很多东西并修复很多错误。
质疑您是否真的需要 POSIX 语义的评论是一个好的开始。非 POSIX “文件系统”语义可以更加灵活，从而产生更加可靠的系统。
如果这是一个遗留应用程序，我真的想知道为什么现代分布式文件系统可能被认为是最佳解决方案。
不要误会我的意思——这些玩具非常有趣。我只是不想负责一个复杂的相互依赖的解决方案，这种解决方案不常用，而且一旦出现问题就很难修复。
你真的，绝对肯定需要 POSIX 语义吗？如果您可以使用自定义数据存储，生活会变得更轻松。我们有一个内部编写的数据存储，它实际上是一个非常大的分布式键值存储。您在其中存储一个文件并获得一个令牌。如果您想要恢复文件，请将您之前获得的令牌提供给它。它是分布式的，无共享的，数据被复制三次，节点可以随意添加和删除，存储服务器和控制服务器都可以。
Lustre 旨在支持故障转移，MDS/MDT/OSS 可以有多个可以联系的地址，可以使用心跳来迁移服务。
请注意，最近的一些版本存在卸载似乎可以正常工作但仍有数据正在传输到光盘的问题，但是双重安装保护应该有所帮助（除了已经出现的有趣问题）....