我们刚刚build立了连接我们组织中两个build筑物的广域网连接。 该链路由100 Mbps点对点线路提供。 我们在链接的每一侧都有一个Windows Server 2008 R2域控制器。
现在我们计划在整个组织中为文件服务设置DFS。 估计的数据量超过2TB，并将以每年约20％的速度增长。 我的想法是在每个build筑物中build立一个文件服务器并安装DFS，以便所有的内容在100Mbps链路上保持复制。 我希望这可以确保在从DFS文件夹请求文件时，任何用户都将被引导到最近（最快）的服务器。
我担心的是100 Mbps的广域网链路是否足以保证DFS复制。 我没有DFS的经验，所以任何可靠的build议是值得欢迎的。 这条线是可靠的（即它不会经常崩溃），我们的数据传输testing表明，5 MB /秒的传输速率很容易实现。 这大约是标称带宽的40％。
我也关心延迟。 我的意思是，用户需要等待多长时间才能在链路另一端发生变化后才能看到链路的一个变化。
我的问题是：networking之间的链接是build立DFS复制的可靠基础架构吗？ 什么延迟时间是典型的（秒，分钟，小时，天）？ 你会build议我们在这种情况下去DFS，还是有更好的select？ 非常感谢。
DFS …像旧的或新的复制机制？
旧的 – 根本不可行，不能通过局域网连接…我对大型场景不可靠。
新的（DFS复制） – 是的，当然。 完美的作品。 这是非常可靠的，它会按需要排队。 只要你的链路有足够的带宽，最终就可以工作。 我保持了超过512kbit的一些链接，有时排队20GB转移….需要一些日子，但它的工作原理。
它应该适合你的链接。 我们通过更慢的链接来做到这一点。 我们configuration复制，以便在非工作时间使用最高带宽。 我认为你的意思是新的DFSR而不是旧版本。
是否有可能两个副本上同时由两个不同的用户编辑同一个文件？ DFS不提供分布式locking机制来保护这一点。