it-swarm.cn

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

我们最近迁移了Windows网络,以使用DFS共享文件。 DFS运行良好,但有一个令人烦恼的问题:用户尝试访问一段时间未访问的DFS命名空间时会遇到很大的延迟。我曾尝试解决此问题,但到目前为止尚未获得任何成功,我希望这里的某人可能有帮助解决该问题的指示。

首先,我们网络的一些背景:

网络使用Windows 2008功能级别的Active Directory域和两个Windows 2008 DC和两个DNS服务器(每个DC上一个)。该网络仅是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中存在的文件夹。如果他们随后关闭资源管理器窗口并尝试在5分钟内再次访问\\ domain.name\namespace1 \,则内容将立即显示-如果他们等待的时间超过5分钟,它将再次经历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问题
  • 客户端和服务器上已禁用防病毒
  • 从几个命名空间中删除一个命名空间服务器-没什么区别

所以这就是我的专长-而且我没有想法。谁能说出造成延迟的原因和/或我下一步应该尝试什么?

22
Matt

好吧,我们最终在我们的环境中似乎已经解决了此问题。为了他人的利益,这是我们发现的问题以及解决问题的方法:

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

这些捕获显示出一些奇怪的现象:每当发生延迟时,在从客户端向DC发送DFS请求和从DC到客户端_到DFS根服务器的引用之间DC正在向网络发送多个广播名称查询。

首先,DC将广播DOMAIN的NetBIOS查找(其中DOMAIN是我们在Windows 2000之前的Active Directory域名)。几秒钟后,它将广播 [〜#〜] llmnr [〜#〜] 查找DOMAIN。接下来是对DOMAIN的另一个广播NetBios查找。在广播了这三个查找(我认为已超时)之后,DC最终将通过(正确的)对DFS根服务器的引用来响应客户端。

仅当发生长时间延迟打开DFS共享时才发送DOMAIN的这些广播名称查找,并且从Wireshark捕获中我们可以清楚地看到DC直到将引用返回DFS根服务器之前才返回所有三个查询均已发送(并经过了约7秒)。因此,这些广播名称查找显然是造成我们延迟的原因。

现在我们知道了问题所在,我们开始尝试找出为什么进行这些广播名称查找。经过更多谷歌搜索和反复试验后,我们找到了答案:我们没有将域控制器上的DfsDnsConfig注册表项设置为1,这是在仅DNS环境中使用DFS所必需的。

当我们最初在环境中设置DFS时,我们did阅读了有关如何为仅DNS环境配置DFS(例如 Microsoft KB24438 和其他),并且知道此注册表项,但是误解了有关何时/如何使用它的说明。

KB244380说:

必须将DFSDnsConfig注册表项添加到将参与DFS命名空间的每台服务器,以使所有计算机理解标准名称。

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

显然,我们对此结果感到满意,但我要补充一点的是,我仍然不是100%确信这是我们唯一的问题-我想知道是否将DfsDnsConfig = 1添加到我们的DC是否仅解决了问题,而不是解决了问题。我无法弄清楚为什么DC在DFS引用过程中会尝试查找DOMAIN(域名本身,而不是域中的服务器),即使在非DNS唯一的环境中,我也知道在其他(公认的是更小/更简单)仅DNS环境中,尚未在域控制器上设置DfsDnsConfig = 1,也没有遇到相同的问题。尽管如此,我们已经解决了问题,所以我们很高兴。

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

28
Matt

这可能是由DNS服务器网络掩码排序引起的。我们最近在Server 2003中遇到了这个问题。这取决于您当前的子网。

例。

站点1:IP子网10.0.0.0/24站点2:IP子网10.0.1.0/24

站点2中的客户端会对基于域的名称空间进行DNS查询,并且默认情况下,站点1中的DFS服务器将被赋予DFS服务器,因为DNS服务器不知道站点IP边界。您需要告诉DNS服务器使用哪个子网掩码来标识要响应的IP地址。

请参阅 http://support.Microsoft.com/kb/842197

3
Chris

Active Directory团队博客的文章共三部分,有关DFS延迟。

http://blogs.technet.com/b/askds/archive/2009/09/29/o-dfs-shares-where-art-thou-part-1-3.aspx

它介绍了推荐过程的基础知识,然后介绍了如何使用各种工具(包括dfsUtil和dfsDiag)来发现延迟的实际原因。

它帮助我找到了问题。结果证明对域用户的共享目录没有读取权限。

HTH,丹尼尔

3
Daniel B

闻起来像DNS问题,但是一切正常。我非常喜欢旧的FRS,因为像Ultrasound这样的诊断工具非常有用:7

您是否在目标的DFS复制事件日志中得到了任何东西? (“ DFS运行状况”报告将从事件日志中提取警告)

在没有WINS=的情况下运行是一个不错的目标,值得钦佩,尽管如果有任何Vista/2008以前的Windows系统出现,我并不赞成这样做,因为事情总是无法按预期或以最快的速度运行。在我的经验中,没有WINS=-尽管这并不重要。

2
Oskar Duveborn

因此,我在搜索中使用了这篇文章。我进行了所有设置,但仍然遇到问题。花了几天的时间调查问题并排除了所有“微软”之后,我猜想它与网络有关。原来我们的WAN Accelerator是问题所在。我让我们的网络专家为域控制器关闭了加速功能,一切都变得更好了。

1
David Jenkins

在多站点网络中,dfsutil/spcflush和dfsutil/pktflush也可以是一种解决方案,请确保主站点的DFS链接来自本地服务器而不是来自缓存。

1
Parag DJ

我们遇到了一个类似的问题,即用户在单击映射到DFS共享的驱动器与看到和浏览到共享中的文件夹之间会遇到延迟(最多一分钟)。

用户还将主驱动器映射到同一卷上的其他DFS共享,并且访问那里的文件夹没有延迟。

两者之间的区别是基于访问的枚举(ABE)-已启用问题共享(这是用户的通用驱动器,具有成千上万个文件夹-ABE意味着用户只能看到他们拥有权限的那些文件夹)。

禁用ABE可以完全解决问题。显然,这不是解决方案,因为用户随后会看到所有文件夹,使它们混乱。我已经将DFS共享复制到带有一些备用磁盘的服务器上,作为临时措施,即使在这个新目标上启用了ABE,延迟也已经消失了。

问题服务器为2k3R2,正常运行时间超过150天(!),因此它将重新启动并在有问题的卷上运行CHKDSK。如果这对问题有任何影响,我将在此发布。新目标位于2k8服务器上。

1
slag

有很多控制器,脚本也是如此(dnsdfs.cmd servername):

dfsutil server registry dfsdnsconfig set %1
sc \\%1 stop dfs
sc \\%1 start dfs
1
i3laze

客户端缓存DFS引用,即,当您输入\ domain.name\namespace时,它将缓存实际的服务器domain.name所引用。一旦引用从缓存中过期,则客户端基本上必须重新“发现”您的DFS拓扑,因此会产生延迟。

在这里看看: http://technet.Microsoft.com/zh-cn/library/cc758234(WS.10).aspx 并在这里 http://blogs.technet。 com/filecab/archive/2006/01/20/417832.aspx 了解有关其工作原理的更多信息。

可能的解决方案?解决这个问题的一种不明智的方法可能是编写一个小程序,每隔几分钟执行一次“保持活动”。例如一个copen程序,它首先找到fopen文件,然后立即关闭它。我没有尝试过或测试过,如果要这样做,您肯定需要仔细考虑。

1
Maximus Minimus

我知道原始海报没有使用WINS,但是我为了他人的利益而张贴,因为我们最常使用该张贴来帮助解决一个非常相似的问题。对我们而言,最终有人决定使用与域相同的名称来命名其工作站。因此,每次DC)为DFS引用查询域名时,它都想解析到该工作站,并且会导致相当长的10s秒的延迟。静态20将条目放入WINS指向DC,这已经解决了问题。如果没有WINS,则可以尝试将域名设置为LMHOSTS文件中的计算机名称指向DC,以获得20个查找,并设置优先级以使LMHOSTS成为解决netbios名称的第一个要查看的地方。

1
newguy

http://technet.Microsoft.com/zh-cn/library/cc780950(v = ws.10).aspx 此页面实际上同时提到了域控制器和DFSN,如果有帮助的话。

DFS域控制器和根服务器注册表项

以下注册表项位于

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs 

在根服务器和域控制器上。所有条目均为REG_DWORD。

1
Amy

您提到您有20台DFS服务器,但如果所有服务器都在同一设施中,就不会提及。

如果这些服务器不在同一设施中,并且每个其他站点都有其自己的域,则可能需要确保启用客户端故障回复。

0
Ishmael

对于那些最终通过谷歌搜索到这里并且有同样问题的人...

首先检查命名空间中的所有链接均可用且良好。在我的情况下就是这样,在名称空间中仍然有一个服务器宕机的链接,因此打开DNS的长时间停顿是因为它正在搜索该服务器而失败。一旦我禁用了DFS中的链接,长时间的停顿就消失了。

0
Bryan