3

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

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

我有几个要求：

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

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

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

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

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

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

4

3 回答 3

1

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

如果您依赖单个 Internet 连接，仍然存在单点故障。当然，你可以认为亚马逊本身就是一个失败点，但由于规模的原因，失败率总是要低得多。

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

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

缺点：

  • S3 上的文件是不可变的，它们只能被完全替换或删除。这对于缓存非常有用，但在对大文件进行小幅更改时对效率来说不是那么好。
  • 延迟和带宽取决于您的网络连接。缓存可以帮助改善这一点，但您永远无法获得相同水平的性能。

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

于 2008-11-28T16:12:40.293 回答
0

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

于 2008-11-28T15:52:15.123 回答
0

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

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

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

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

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

于 2008-11-28T16:46:47.090 回答