几年来，我一直尝试在标准 Linux 硬件上创建一个“分布式集群存储系统”（见下文）。我一直没有成功。我研究过购买一个，它们确实存在，但是太贵了，我买不起。它们也是为更大的企业设计的，并且有大量我不需要或不想要的功能。我希望 Linux 社区能够帮助我创建这个低成本的“分布式集群存储系统”，我认为其他小型企业可以使用它。请帮助我解决这个问题，以便我们可以将解决方案发布给开源社区。

我愿意接受任何合理的解决方案（包括购买一个），只要我能负担得起（低于 3000 美元）。我已经为此项目准备了一些硬件，包括所有节点和 2 台数据服务器，它们是：2 台 @ Supermicro 系统，配备双 Xeon 3.0 GHz CPU、8GB RAM、4 个 @ 750GB Seagate SATA 硬盘。

我曾尝试在不同的组合中使用所有这些技术来创建我的解决方案，但都没有成功。drbd、nfs、gfs、ocfs、aoe、iscsi、heartbeat、ldirectord、轮询 DNS、pvfs、cman、clvm、glusterfs 和几种 fencing 解决方案。

我的“分布式集群存储系统”的描述

• 数据服务器：2 个单元（设备/服务器），每个单元都有一个 4+ 驱动器的 RAID5 磁盘集（3 个活动，1 个热备）。这两个单元可以是主动/被动或主动/主动，我不在乎。这两个单元应实时相互镜像。如果 1 个单元因任何原因发生故障，另一个单元将接管负载并继续运行，客户端没有任何延迟或挂起时间。如果一个单元发生故障，当它恢复运行时，我希望数据能够自动重新同步。然后，该单元应该在同步后“恢复在线”（假设其正常状态为活动状态）。如果数据服务器可以是 1-N 而不仅仅是 1-2，那就更理想了。
• 数据客户端：服务器场（CentOS 5.4 操作系统）中的每台集群节点机器（客户端）将挂载 1 个或多个由数据服务器提供的（读/写模式）数据分区。多个客户端将同时以读/写模式挂载同一分区，因此需要网络文件锁定。如果服务器宕机（多个硬盘故障、网络问题、电源问题等），另一台服务器将接管 100% 的流量，客户端机器永远不会知道。

总结

• 2 台数据服务器实时相互镜像。
• 如果一台服务器发生故障，自动故障转移到工作服务器（无需客户端重启，甚至不会中断）。
• 如果发生故障的单元恢复在线，则自动重新同步数据，当同步完成时，该单元再次变为活动状态（假设其正常状态为活动状态）。
• 多台机器以读/写模式挂载同一分区（某种网络文件系统）。
• 集群节点上将使用 Linux CentOS。

以下是我尝试过的内容（部分）描述以及它未能满足要求的原因

在很大程度上，我让列出的所有技术都按广告宣传的那样工作了。问题主要与 1 台服务器发生故障有关，这可能会导致网络文件系统挂起 3 秒以上。问题在于，当服务器宕机时，任何使用 heartbeat 或轮询 DNS 的解决方案都会使网络文件系统挂起 3 秒或更长时间。虽然这对许多技术（如 http、ftp 和 ssh（heartbeat 的设计目的））来说不是问题，但这给文件系统带来了很大的问题。如果您正在加载一个网页，并且需要 3 秒钟，您可能甚至不会注意到，或者您会点击您的重新加载按钮，它会工作，但是文件系统远没有那么容忍延迟，当挂载点不可用 3 秒钟时，很多东西都会崩溃。

因此，在 active/passive 模式和 heartbeat 中使用 DRBD，我使用这些 说明 设置了一个“高可用性 NFS 服务器”。

使用 Linux 的 NFS 实现，NFS 挂载将挂起并需要手动干预才能恢复，即使 server #2 接管了虚拟 IP。有时您必须重启客户端机器才能恢复 NFS 挂载。这意味着它不再是“高可用性”了。

使用 iscsi，我找不到一种将 LUN 复制到多台机器的好方法。据我了解，该技术是 1 对 1 的关系，而不是 1 对多的关系。而且它会再次使用 heartbeat 或轮询 DNS 进行冗余，如果其中一台服务器宕机，这将导致挂起。

继续讨论 GFS，我发现几乎所有可用于 GFS 的 fencing 解决方案都使 GFS 完全无法使用。如果您有电源开关 fence，您的客户端机器将在问题可能是网络电缆松动或网络交换机过载时冷重启。冷重启任何服务器都非常危险（如果您问任何有经验的系统管理员）。一个简单的例子，如果您的引导加载程序在机器启动后因某种原因损坏，它可以运行多年而不会出现问题，如果您重启，引导加载程序会咬您一口。如果您有一个托管网络交换机，您可能会失去与服务器的所有通信，因为网络文件系统已关闭。许多服务器将需要网络通信来进行其他不依赖于网络文件系统的事情。再次强调，在我看来，对于可以通过另一种方式解决的问题来说，风险非常高。我确实喜欢的一种解决方案是 AOE fencing 方法。这只是从 AOE 软件服务器的“允许的 MAC 地址”中删除您无法访问的客户端的 MAC 地址。这不应影响客户端机器上的任何内容，除了网络文件系统。

我确实让 drbd、AOE、heartbeat、GFS 和 AOE fence 组合工作了，但是当服务器宕机时，网络文件系统仍然至少有 3 秒的挂起时间。

最后是 glusterfs。这似乎是理想的解决方案，我仍然在努力与 glusterfs 社区合作，使其能够工作。此解决方案的 2 个问题是

• 当服务器宕机时，挂载点仍然存在延迟/超时而不可用。
• 当发生故障的服务器恢复运行时，它无法与工作服务器“重新同步”。

第二个项目的原因是这是一个客户端复制解决方案。这意味着每个客户端负责将其文件写入每台服务器。所以基本上服务器彼此不知道。这种客户端复制的优点是可扩展性。根据 glusterfs 社区的说法，他们正在谈论数百台服务器和 PB 级存储。

关于所有这一切的最后一点说明，我对所有我知道的网络文件系统运行一个简单的测试，这将带来一致的结果。我发现任何网络文件系统最多只有本地文件系统速度的 10-25%。 （另请注意，这是通过 1gb 铜缆以太网而不是光纤通道）当运行时（这将创建一个 1gb 测试文件）

dd of=/network/mount/point/test.out if=/dev/zero bs=1024 count=1M

我在 NFS 上获得大约 11MB，在 glusterfs 上获得 25MB，在本地文件系统上获得 170+MB。所以你必须接受性能损失，这对于我正在做的事情来说是可以接受的。

附注：我刚了解到 Lustre，现在属于 Sun/Oracle 品牌。我很快会对其进行测试。