访问 DFS 命名空间时的长时间停顿

Question

我们最近迁移了我们的 Windows 网络以将 DFS 用于共享文件。DFS 运行良好，除了一个恼人的问题：用户在尝试访问他们有一段时间没有访问过的 DFS 命名空间时会遇到明显的延迟。我已经尝试解决该问题，但到目前为止还没有取得任何成功，我希望这里有人可以提供一些帮助来解决问题的建议。

首先，我们网络的一些背景：

该网络使用带有两个 Windows 2008 DC 和两个 DNS 服务器（每个 DC 上一个）的 Windows 2008 功能级别 Active Directory 域。网络只有 DNS - 没有 WINS。所有计算机都位于同一站点并通过千兆以太网连接。我们在 Windows 2008 模式下有大约 20 个基于域的 DFS 命名空间，每个 DFS 命名空间都有两个 Windows 2008 DFS 命名空间服务器（所有命名空间都使用相同的两个服务器）。所有命名空间服务器都处于 FQDN 模式，并且所有文件夹目标都使用其 FQDN 指定。所有计算机都安装了最新的 Service Pack 和补丁。

实际的文件夹目标（即 SMB 共享我们的 DFS 文件夹指向）分散在多个文件和应用程序服务器上，所有服务器都运行 Windows 2008 和运行 Windows 2003 R2 的两个应用程序服务器，根本没有复制设置（例如当前所有 DFS 文件夹只有一个文件夹目标）。

关于这个问题的更多细节：

命名空间访问延迟通常为 1 到 10 秒长，并且似乎发生在特定计算机大约五分钟或更长时间未访问请求的命名空间时。

例如，如果用户超过五分钟没有访问 \\domain.name\namespace1\ 并尝试通过 Windows 资源管理器访问 \\domain.name\namespace1\，则资源管理器窗口将冻结 1 - 10 秒，然后最终恢复并显示存在于 \\domain.name\namespace1 中的文件夹。如果他们随后关闭资源管理器窗口并尝试在五分钟内再次访问 \\domain.name\namespace1\，内容将几乎立即显示 - 如果他们等待的时间超过五分钟，它将再次经历 1 - 10 秒的暂停。

一旦“进入”命名空间，一切都很好而且很快，只是与命名空间的初始连接变慢了。

浏览延迟似乎会影响我们使用的所有 Windows 变体（Windows 2008 x64 SP2、Windows 2003 R2 x86 SP2、Windows XP Pro x86 SP3）——它在 Windows XP / 2003 中可能比在 Windows 2008 中差一点，但我不确定差异是否不仅仅是心理上的。

直接访问底层文件夹目标完全没有延迟 - 即，如果直接访问 DFS 指向的 SMB 共享（绕过 DFS），则没有暂停。

在排除故障期间，我注意到我们所有 DFS 根的“缓存持续时间”设置为 300 秒 - 5 分钟。鉴于这与触发暂停所需的时间相同，我假设此缓存在某种程度上相关，尽管我不确定客户端上缓存的究竟是什么，因此在 5 分钟过去后需要再次查找什么。

在尝试解决问题时，我已经尝试/检查了以下内容（没有成功）：

• 在两个域控制器上运行 dcdiag - 没有发现问题
• 做了一些基本的 DNS 服务器检查但没有发现任何问题 - 我不知道如何详细检查 DNS 服务器，但我想补充一点，网络没有表现出任何其他可能指向 DNS 问题的奇怪行为
• 在客户端和服务器上禁用防病毒
• 从几个命名空间中删除一个命名空间服务器 - 没有区别

所以这就是我要做的 - 我没有想法。任何人都可以建议可能导致延迟的原因和/或我接下来应该尝试什么？

Answer 1

好吧，我们似乎终于在我们的环境中解决了这个问题。为了他人的利益，以下是我们的发现以及解决问题的方法：

为了进一步了解延迟之前/期间/之后发生的情况，我们在客户端计算机上使用 Wireshark 来捕获/分析该客户端尝试访问 DFS 共享时的网络流量。

这些捕获显示了一些奇怪的东西：每当延迟发生时，在从客户端发送到 DC 的 DFS 请求和从 DC 返回到客户端的 DFS 根服务器的引用之间，DC 发送几个广播名称对网络的查找。

首先，DC 将广播对 DOMAIN 的 NetBIOS 查找（其中 DOMAIN 是我们在 Windows 2000 之前的 Active Directory 域名）。几秒钟后，它将广播对 DOMAIN的LLMNR查找。接下来是另一个针对 DOMAIN 的广播 NetBios 查找。在广播这三个查找之后（我假设已经超时），DC 最终将通过（正确）引用到 DFS 根服务器来响应客户端。

这些针对 DOMAIN 的广播名称查找仅在打开 DFS 共享的长时间延迟发生时发送，我们可以从 Wireshark 捕获中清楚地看到，在所有三个查找都发送之前，DC 不会返回对 DFS 根服务器的引用（并且过去了约 7 秒）。因此，这些广播名称查找显然是我们延迟的原因。

既然我们知道问题出在哪里，我们就开始尝试找出这些广播名称查找发生的原因。经过更多的谷歌搜索和一些反复试验，我们找到了答案：我们没有将域控制器上的 DfsDnsConfig 注册表项设置为 1，这是在仅 DNS 的环境中使用 DFS 时所必需的。

当我们最初在我们的环境中设置 DFS 时，我们确实阅读了有关如何为纯 DNS 环境（例如Microsoft KB244380和其他）配置 DFS 的各种文章，并且知道此注册表项，但误解了有关何时/如何配置的说明用它。

KB244380 说：

必须将 DFSDnsConfig 注册表项添加到将参与 DFS 命名空间的每台服务器，以便所有计算机都能理解完全限定的名称。

我们认为这意味着必须仅在 DFS命名空间服务器上设置注册表项，而没有意识到域控制器上也需要它。在我们的域控制器上将 DfsDnsConfig 设置为 1（并重新启动“DFS 命名空间”服务）后，问题就消失了。

显然我们对这个结果很满意，但我要补充一点，我仍然不能 100% 相信这是我们唯一的问题 - 我想知道将 DfsDnsConfig=1 添加到我们的 DC 是否只能解决这个问题，而不是解决它. 我不明白为什么 DC 会在 DFS 引用过程中尝试查找 DOMAIN（域名本身，而不是域中的服务器），即使在非 DNS 专用环境中也是如此，而且我也知道我还没有在其他（公认的更小/更简单）仅 DNS 环境中的域控制器上设置 DfsDnsConfig=1 并且没有遇到相同的问题。不过，我们已经解决了我们的问题，所以我们很高兴。

我希望这对遇到类似问题的其他人有所帮助 - 再次感谢那些在此过程中提供建议的人。