到目前为止我已看到一篇关于性能和可扩展性的文章主要关注添加新链接需要多长时间。但是有没有关于文件数量、文件夹数量、总大小等限制的信息？
现在我有一台文件服务器，里面有数百万张 JPG（大约 45 TB），这些 JPG 通过几个标准文件共享在网络上共享。我计划创建一个 DFS 命名空间并将所有这些图像复制到另一台服务器以实现高可用性。我是否会遇到使用 DFS 时不会遇到的额外问题？有没有更推荐的方法来复制这数百万个文件并使其在网络上可用？
编辑2：
所有文件通常只写入磁盘一次，此后再也不会被修改。唯一被修改的时间是最终被删除时，可能是几年后。所以一切都相当静态。
编辑：
我会自己进行实验并写一篇博客文章，但我还没有第二台服务器的硬件。我想在购买 45 TB 的硬盘空间之前收集信息...
答案1
我们目前正在使用 2008 R2 DFSR，其中有 57 TB 的复制文件（160 万个），总卷大小超过 90 TB，没有任何问题。
因此，MS 测试的限制在这方面有点幼稚，恕我直言，他们应该购买更多的磁盘空间并进行更多测试。如果您对初始同步的时间要求不高，DFSR 也可以做到这一点。它尤其不喜欢的是同一个文件在多个主机上被修改，因为它必须进行仲裁以决定保留哪个文件。
答案2
有了 45TB 的数据，您就超出了 Server 2008 上 DFS-R 的测试限制，如下所示：
服务器上所有复制文件的大小：10 TB。
卷上复制的文件数量：800 万。
最大文件大小：64 GB。
编辑：
如果您的文件可能永远不会改变，您可以利用 DFS 的命名空间部分为您的共享创建虚拟化路径。然后，您可以在计划任务中运行 robocopy 来同步您的服务器。即使您要使用 DFS-R，您也需要使用类似 robocopy 的工具进行初始同步。
答案3
“有没有更推荐的方法来复制这些数百万个文件并使其在网络上可用？” 是的 - 要么使用 SAN 或 NAS 设备来集中它们，要么使用 Isilon、Gluster 等分布式存储。DFS 很好，但这意味着每台服务器都有所有内容的完整副本，因此如果您需要扩大规模，这不是一个好的架构。
此外，您的架构可能无论如何都难以扩展。我见过一些大型图像系统不以文件形式存储 - 它们有一个数据库来存储图像的元数据和字节偏移量，并将它们汇总到大型二进制文件中，这些文件以易于在磁盘和文件系统上分布的方式分布。需要图像时，它会查找 blob 文件并使用起始和结束字节从其中提取图像。