分布式文件系统完整性检查[关闭]

Question

我需要一个分布式文件系统，该系统必须扩展到非常大的大小（实际最大值约为 100TB）。文件大小大多在 10-1500KB 范围内，但有些文件可能会达到 250MB 左右的峰值。

我非常喜欢像 GFS 这样的系统，它具有内置的备份冗余，从统计上讲，这将使文件丢失成为过去。

我有几个要求：

• 开源
• 没有单点故障
• 自动文件复制（即不需要 RAID）
• 托管客户端访问
• 文件的平面命名空间 - 最好
• 内置版本控制/延迟删除
• 经过验证的部署

我认真研究过 MogileFS，因为它确实满足了大部分要求。它没有任何托管客户端，但它应该相当直接地做一个 Java 客户端的移植。但是，没有内置版本控制。没有版本控制，除了 MogileFS 中内置的文件复制之外，我将不得不进行常规备份。

基本上，我需要防止突然清除大量不应包含的文件的编程错误。虽然 MogileFS 确实通过在 X 台设备上复制我的文件来保护我免受磁盘和机器错误的影响，但如果我进行了无根据的删除，它并不能拯救我。

我希望能够指定删除操作直到 Y 天后才真正生效。删除逻辑上会发生，但我可以将文件状态恢复 Y 天，直到它被实际删除。此外，MogileFS 无法在写入期间检查磁盘损坏 - 不过，可以再次添加。

由于我们是一家 Microsoft 商店（Windows、.NET、MSSQL），我最希望核心部分在 Windows 上运行以便于维护，而存储节点由于许可而运行 *nix（或组合） .

在我考虑推出自己的产品之前，你有什么建议让我看看吗？我还检查了 HadoopFS、OpenAFS、Lustre 和 GFS - 但似乎都不符合我的要求。

Answer 1

您绝对需要在自己的服务器上托管它吗？您需要的大部分内容都可以由 Amazon S3 提供。延迟删除功能可以通过将删除记录到 SimpleDB 表并定期运行垃圾收集传递以在必要时删除文件来实现。

如果您依赖单一互联网连接，仍然会出现单点故障。当然，您可以将亚马逊本身视为失败点，但由于规模的原因，失败率总是要低得多。

希望您能意识到其他好处，即扩展至任何容量的能力。 IT 人员无需更换故障磁盘或系统。随着磁盘容量和带宽变得更便宜（而您购买的磁盘贬值），使用成本将不断下降。

还可以采用混合方法，将 S3 用作安全的后端存档并在本地缓存“热”数据，并找到最适合您的使用模型的缓存策略。这可以大大减少带宽使用并改善 I/O，尤其是在数据不经常更改的情况下。

缺点：

• S3 上的文件是不可变的，它们可以 只能完全更换或 删除。这非常适合缓存， 效率不高 对大文件进行小的更改。
• 延迟和带宽是 您的网络连接。缓存可以 帮助改善这一点，但你永远不会 获得相同水平的性能。

版本控制也是一种自定义解决方案，但可以使用 SimpleDB 和 S3 来实现，以跟踪文件的修订集。总的来说，这真的取决于你的用例是否合适。

Answer 2

您可以尝试在可靠的文件系统之上运行源代码控制系统。然后问题就变成了如何在超时后删除旧的签到。您可以使用 DAV_SVN 设置 Apache 服务器，它将提交通过 DAV 接口所做的每项更改。我不确定随着您描述的大文件大小，这将如何扩展。

Answer 3

@tweakt
我也广泛考虑过 S3，但从长远来看，我认为它不会让我们满意。我们有很多必须安全存储的文件——不是通过文件 ACL，而是通过我们的应用层。虽然这也可以通过 S3 完成，但我们对文件存储的控制确实少了一点。此外，当我们进行文件操作时，延迟形式也会有一个主要的缺点 - 初始保存（虽然可以异步完成），而且当我们稍后读取文件并必须对它们执行操作时。

至于 SPOF，这并不是真正的问题。我们确实有与数据中心的冗余连接，虽然我不想要任何 SPOF，但 S3 的短暂停机时间是可以接受的。

无限的可扩展性和无需维护绝对是一个优势。

关于混合方法。如果我们直接从 S3 托管 - 除非我们想在本地存储所有内容（并且只使用 S3 作为备份），否则当我们添加 S3 + CloudFront 时带宽价格太高了（CloudFront 是必要的，因为我们有来自各地的客户）。目前，我们在欧洲的数据中心托管所有内容，并在美国设置了自己的反向 squid，以实现低预算的 CDN 功能。

虽然它非常依赖于域，但不可变性对我们来说不是问题。我们可能会替换文件（即密钥 X 获取新内容），但我们绝不会对文件进行细微修改。我们所有的文件都是 blob。