![Server 2008 与 Server 2008 R2 之间通过网关到网关 VPN 进行分布式文件系统复制 (DFSR) 导致极端的网络延迟](https://linux22.com/image/569060/Server%202008%20%E4%B8%8E%20Server%202008%20R2%20%E4%B9%8B%E9%97%B4%E9%80%9A%E8%BF%87%E7%BD%91%E5%85%B3%E5%88%B0%E7%BD%91%E5%85%B3%20VPN%20%E8%BF%9B%E8%A1%8C%E5%88%86%E5%B8%83%E5%BC%8F%E6%96%87%E4%BB%B6%E7%B3%BB%E7%BB%9F%E5%A4%8D%E5%88%B6%20(DFSR)%20%E5%AF%BC%E8%87%B4%E6%9E%81%E7%AB%AF%E7%9A%84%E7%BD%91%E7%BB%9C%E5%BB%B6%E8%BF%9F.png)
我所在的公司正在为我们的一位客户设立分支机构。我们在每个位置都有 1.5 Mbps 的上行/下行 T1,每个位置都有一个 Cisco RV042 路由器,在两个位置之间托管网关到网关 VPN 隧道,我们在总部有一台 SBS 2008 服务器,在分支机构有一台 Server 2008 R2 Standard 服务器。我们设置了 DFSR 以在两个办公室之间来回复制特定共享。我们不使用命名空间,只使用 DFSR。
我们的问题是,当在分支服务器上启用 DFSR 服务时,网络延迟会增加 100 倍到 200 倍。我仅使用从我的笔记本电脑到外部站点的连续 ping 来测量延迟。关闭 DFSR 时,平均延迟约为 11.5 毫秒。打开 DFSR 时,延迟在 ~1100 到 ~2500 毫秒之间变化。DFSR 计划设置为周一至周五上午 6 点到下午 6 点不进行复制,其他时间进行完全复制。即使在计划规定不应进行复制时,延迟也会增加。
作为测试,我将复制计划从 UTC 切换到本地时间。我曾假设 UTC 将查询并使用来自本地时间源的 UTC 偏移量。(现在想起来,我不知道为什么我会这样假设。)我没有看到任何立竿见影的改善,但在写这个问题之前,我去阅读了这里几篇与 DFSR 相关的帖子,现在,几分钟后,我发现延迟已经下降。Ping 现在报告在 300 到 400 毫秒之间,我从 Speakeasy.net Speedtest 获得了“正常”的结果。
所以我想这已经变成了一个由两部分组成的问题。这是我在 DFSR 中应该看到的延迟增加吗?如果不是,我可以做些什么来进一步调整、调优或调试它?
感谢您的阅读。如果您有任何不清楚的地方或需要更多信息,请告诉我。
答案1
由于没有复制,因此在非工作时间您不应该看到任何延迟增加。很有可能您只是配置错误(您似乎已经通过 UTC 评论弄清楚了这一点)。当您进行更改时,更改不会立即应用。它们必须复制到所有成员,这可能需要数小时,具体取决于您的 AD 拓扑。
所以我想这个问题分为两个部分。这是我在 DFSR 中应该看到的延迟增加吗?
在允许复制的时间内,绝对如此。1.5Mbps 不算什么,如果要复制大量数据,您的服务器很容易饱和。
如果没有,我该怎么做才能进一步调整、调优或调试它?
仔细检查您的配置并使用工具dfsdiag
查看是否存在积压或其他问题。
附注:测量延迟ping
实际上不是一种故障排除技术。您应该在每个站点的路由器/交换机上监控它。1.5Mbps 现在不是很多。您的性能很可能一整天都相当差,这取决于办公室里有多少人。您应该在正常的一天内进行基线测量在路由器上和然后比较。