和Hadoop和CouchDB在博客和相关新闻中到处都有关于真正起作用的分布式容错存储（引擎）的内容。
- CouchDB 实际上并没有内置任何分发功能，据我所知，自动分发条目甚至整个数据库的功能根本就不存在。
- Hadoop 似乎被广泛使用 - 至少它得到了好评，但仍然有一个单点故障：NameNode。此外，它只能通过 FUSE 安装，我知道 HDFS 实际上并不是 Hadoop 的主要目标
- 集群文件系统确实有一个无共享的概念，但最近我读了几篇文章，让我觉得它不太稳定
- 光泽由于使用专用元数据服务器，因此也存在单点故障
- 头孢似乎是首选的播放器，但主页显示它仍处于 alpha 阶段。
所以问题是哪个分布式文件系统具有以下功能集（无特定顺序）：
- POSIX 兼容
- 轻松添加/删除节点
- 无共享概念
- 可在廉价硬件上运行（AMD Geode 或 VIA Eden 级处理器）
- 内置身份验证/授权
- 网络文件系统（我希望能够同时在不同的主机上安装它）
很高兴有：
- 本地可访问的文件：我可以将一个节点关闭，使用标准本地文件系统（ext3/xfs/whatever...）安装分区，然后仍然可以访问这些文件
我是不是寻找托管应用程序，而不是一些可以让我占用每个硬件盒 10GB 空间并在我们的网络中提供存储空间的东西，并且可以轻松地安装在多个主机上。
答案1
我认为你必须放弃 POSIX 要求，很少有系统实现这一点 - 事实上甚至 NFS 也没有真正实现（想想锁等）并且没有冗余。
任何使用同步复制的系统都会变得非常缓慢；任何具有异步复制（或“最终一致性”）的系统都会违反 POSIX 规则，并且不会像“传统”文件系统那样运行。
答案2
我无法谈论其余部分，但您似乎混淆了“分布式存储引擎”和“分布式文件系统”。它们不是一回事，不应将它们误认为是一回事，而且它们永远不会是一回事。文件系统是一种跟踪硬盘上事物位置的方法。像 Hadoop 这样的存储引擎是一种跟踪由键标识的数据块的方法。从概念上讲，没有太大区别。问题是文件系统是存储引擎的依赖项……毕竟，它需要一种写入块设备的方法，不是吗？
除此之外，我能谈谈在生产环境中使用 ocfs2 作为分布式文件系统。如果您不想了解详细情况，请读完以下几行后停止阅读：这很酷，但可能意味着比您想象的更多的停机时间。
过去几年，我们一直在生产环境中运行 ocfs2。它还不错，但对很多应用程序来说并不好。您应该认真考虑您的要求并弄清楚它们是什么——您可能会发现，您对故障的容忍度比您想象的要高得多。
例如，ocfs2 为集群中每台将要挂载分区的机器都提供了一个日志。假设您有四台 Web 机器，当您使用 mkfs.ocfs2 创建该分区时，您指定总共有六台机器，以便给自己留出一些增长空间。这些日志中的每一个都会占用空间，这会减少您可以在磁盘上存储的数据量。现在，假设您需要扩展到七台机器。在这种情况下，您需要关闭全部的集群（即卸载所有 ocfs2 分区）并使用 tunefs.ocfs2 实用程序创建附加日志（前提是还有可用空间）。然后，您才可以将第七台机器添加到集群中（除非您使用实用程序，否则这需要您将文本文件分发到集群的其余部分），恢复一切，然后在所有七台机器上安装分区。
明白我的意思了吗？它应该是高可用性，也就是“始终在线”，但你却有很多停机时间……但愿你的磁盘空间不会拥挤。你不想看到当你拥挤 ocfs2 时会发生什么。
请记住，evms 曾经是管理 ocfs2 集群的“首选”方式，但现在它已经像渡渡鸟一样灭绝了，取而代之的是 clvmd 和 lvm2。（evms 终于走了。）此外，heartbeat 很快就会变成一个僵尸项目，取而代之的是 openais/pacemaker 堆栈。（附言：在为 ocfs2 进行初始集群配置时，您可以指定“pcmk”作为集群引擎，而不是 heartbeat。不，这没有记录。）
不管怎样，我们已经回到了由 Pacemaker 管理的 nfs，因为在 Pacemaker 将 nfs 共享迁移到另一台机器时，几秒钟的停机时间或几个丢失的 tcp 数据包与我们在使用 ocfs2 时添加机器等基本共享存储操作所看到的停机时间相比是微不足道的。