我们最近迁移了我们的 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 中的文件夹。如果他们随后关闭资源管理器窗口并尝试在五分钟内再次访问 …
通过阅读 DFS 文档,AD 似乎是必需的。
这对我们来说是个问题,因为我们的服务器要么是独立的(不在 AD 中),要么是我们托管服务 AD 的一部分,而 AD 不在我们的掌控之中。
问题是:当服务器处于以下状态时,如何进行 DFS 或类似 DFS 的操作:
机器是 Win2012-R2 和/或 Server 2016
希望在接近分钟的基础上自动镜像跨机器的 tlog 备份和 sql 备份。
我在 Google 或 Technet 上找不到答案的问题...
授予SYSTEM
用户对 DFS 共享文件和文件夹的权限对 DFS 复制有任何影响吗?(虽然我们在这,有没有什么好的理由不能让SYSTEM
有权限的DFS共享文件?)
它出现是因为我有一组 DFS 命名空间和文件夹,我无法解决其他人的问题,并且在解决一个 DFS 副本无缘无故无法与另一个 DFS 副本复制的问题时,我观察到SYSTEM
帐户没有对相关文件夹中的任何文件或文件夹授予任何权限。
所以我设置SYSTEM
了完全控制并向下传播,我们的 DFS 健康诊断报告从显示约 80 个文件的积压到约 100,000 个积压......事情开始复制,包括一些丢失的文件在一台服务器或另一台服务器上(因此不仅仅是权限更改开始复制)。
自然,这让我很好奇 DFS 是否需要该SYSTEM
帐户具有执行其工作的权限,或者是否只是对相关文件夹树的任何更改促使 DFS 采取行动。如果重要的话,我们的 DFS 命名空间是在 2000/2003 下设置的,我最近刚刚完成将所有服务器升级到 2008 R2 或 2012(启用 UAC,blech),但还没有开始提高 DFS 命名空间的功能Server 2008 的级别。
(如果有人有关于 NTFS 文件权限和SYSTEM
与 DFS 或网络文件有关的帐户的官方 Microsoft 文章,则可获得加分。)
这里有两个略有不同但相似的场景:
2. 在我的文档中有一个 POP/IMAP 帐户的 PST。然后将文档文件夹重定向到网络共享。现在,尽管数据文件选项卡指示文件的正确网络路径 (\\server\share\user.name\Documents\outlook.pst),但 Outlook 无法访问与该帐户关联的 PST。Outlook 加载,但它声称找不到 PST,因此无法查看关联帐户的收件箱。*
*事实证明这是一个特定的已知问题。稍后我会发布链接
为什么在执行这些类型的重定向时会“中断”,即使从前端的角度来看文件的路径仍然相同?
我们设置了 DFS 命名空间,以便 \\company.local\users 托管在英国服务器和美国服务器上,并根据用户的站点进行引用。除了我们今天怀疑之外,DFS 对某些用户的故障转移到了美国。之所以怀疑,是因为我们能看到的唯一证据是他们从美国复制回来的私人文件(例如 cookie、漫游配置文件)。通常,他们走另一条路。
用户如何确定 \company.local\users 在其会话中解析到的位置?是否有命令行工具或他们可以查看的东西?类似于 net use 但用于 DFS 命名空间。
谢谢,罗伯。
这是配置。专用网络和域 ( foo.bar
)。2 个运行 2K8R2(file1.foo.bar
和file2.foo.bar
)的文件服务器。在每台服务器上创建一个共享 ( \\file1\share and \\file2\share
)。在域上设置 DFS 并创建命名空间 ( \\foo.bar
)。dfsshare
在 DFS 中创建了一个文件夹 ( ),其中包含 2 个目标 (\\file1\share
和\\file2\share
)。创建复制组,一切正常,除了...
在测试期间(Win 7 SP1 x64 客户端),如果我将一个大文件 (230MB) 复制到 DFS 共享 ( \\foo.bar\dfsshare
),我会收到以下错误:
Error 0x8007003B: An unexpected network error occured.
Run Code Online (Sandbox Code Playgroud)
如果我将同一个文件直接复制到其中一个文件服务器 ( \\file1\share
),则不会出现错误,并且该文件会复制到另一台文件服务器并显示在 DFS 共享中。将小文件复制到 DFS 共享时没有错误。
我找到了hotfix 983620
http://support.microsoft.com/kb/983620,但该修补程序包含在 Windows 7 的 SP1 中。
更新:将其缩小到 ~41MB 文件大小。在此之上,我得到了错误。在此之下,它工作正常。此外,网络是运行 1000Base T 的 LAN(我和服务器之间没有路由器)。
UPDATE2:还验证了 Windows XP …
Windows DFS 推荐如何适用于远离办公室的笔记本电脑?
[编辑 2014-11-26] 我已经了解站点是如何由子网等定义的。但我想知道的是,根本不适合任何站点的用户会发生什么?例如,家庭用户通过 VPN。由于 VPN 系统的工作方式,VPN 不提供任何站点内的 IP,因此这无助于定义站点。它是否将所有 DFS 命名空间目标视为完全相同,因为此时客户端位于零个站点?有什么方法可以鼓励 DFSN 将一个站点中的 DFSN 目标视为基于邻近性或用户常用站点的首选?(我知道怎么说“当一切都平等时,将 X 服务器视为首选”,但这不是我在这里要求的。)
本文的其余部分只是您感兴趣或娱乐的背景。
我的印象是笔记本电脑会保留它所在的最后一个站点或它连接到的最后一个 DC 的站点。然后该站点将出于推荐排名的目的确定该笔记本电脑当前所在的站点。
我问的原因是因为我们让一些笔记本电脑用户得到了一些他们从未真正去过的办公室的奇怪推荐。这些笔记本电脑与它们应该连接到的其他站点中的服务器连接良好。在这种情况下,奇怪的推荐目标是一个不可靠的服务器。如果它基于某种速度或可靠性指标,那就完全错了。问题只是第一行,本文的其余部分只是背景。
所涉及的硬件/软件是:适用于所有事物的 Windows 2008 R2 服务器;Windows 7 64 位和 Windows XP 32 位笔记本电脑。
这是一个关于 DFS 命名空间的问题,而不是关于 DFS 复制的问题。
DFS 的工作原理:DFS 流程和交互说明如下:
启用最便宜的目标选择后,DFS 将按以下顺序将目标放置在引用中:
与客户端位于同一站点的目标以随机顺序列在推荐的顶部。
客户站点之外的目标按最低成本到最高成本的顺序列出。具有相同成本的推荐被分组在一起,并且在每个组中,目标以随机顺序列出。
如果笔记本电脑位于客户办公室、酒店、家庭等,它是否仍被视为在站点内?如果是这样,我假设该站点将用于上述第一组目标。如果它不在站点内,我认为它会完全跳过第一组并随机分配目标。但我们看到的行为是,它更像是后者而不是前者。
编辑:(太平洋时间 5 月 21 日凌晨 3 点)
似乎将“覆盖推荐顺序”设置为“同等成本目标中的第一个”的文件夹变得愚蠢。愚蠢的部分是具有该启用的目标似乎是最后一个,而不是第一个。我正在取消这些设置,看看会发生什么。稍后汇报。
到目前为止,我看到了一篇关于性能和可扩展性的文章,主要关注添加新链接需要多长时间。但是是否有关于文件数量、文件夹数量、总大小等限制的信息?
现在我有一个文件服务器,其中包含数百万个 JPG(价值约 45 TB),这些文件通过几个标准文件共享在网络上共享。我计划创建一个 DFS 命名空间并将所有这些映像复制到另一台服务器以实现高可用性目的。我是否会遇到 DFS 的额外问题,而我在使用普通文件共享时不会遇到这些问题?是否有更推荐的方法来复制这数百万个文件并使它们在网络上可用?
编辑2:
所有文件通常都会写入磁盘一次,之后再也不会修改。它们被修改的唯一时间是它们最终被删除时,可能是几年后。所以一切都是静态的。
编辑:
我会自己试验并写一篇关于它的博客文章,但我还没有第二台服务器的硬件。我想在购买 45 TB 硬盘空间之前收集信息...
目前正在执行一个项目,将所有用户从映射驱动器主文件夹迁移到重定向文件夹(文档)。
目前有一个奇怪的问题,即用户重定向文件夹 Documents 真的很慢(本地),即使浏览文件夹也可能需要几秒钟才能填充文件列表。
我已将驱动器映射到相同的 DFS 命名空间,这样速度很好,我还通过将文件夹重定向重定向到共享名称而不是 DFS 命名空间进行了测试,这也很好。因此,将文件夹重定向到 DFS 命名空间的组合似乎导致了缓慢。
根据 Microsoft 的建议,DFS 是一个不复制到 NAS 的单点。
任何人都有类似的东西或任何想法可能导致问题的原因?
我需要你的帮助。我已经为此苦苦挣扎了几个月,我在网上找到的任何东西都没有帮助我。问题是,域计算机有时会指向不同站点中不正确的域控制器。我有两个通过 VPN 连接的站点:站点 A带有两个域控制器,站点 B带有一个域控制器。这是我目前的配置:
Site-A 中的计算机通常连接到 SRV-1 或 SRV-2(它们应该连接),但 Site-B 中的计算机很少连接到 SRV-3。站点之间的 ADSL 连接速度非常慢,因此连接到错误的站点会使客户端几乎无法使用。
所有 DC 也是 DFS 服务器。最大的缺点是,当客户端连接到错误的 DC 时,它们也会连接到错误的 DFS 服务器,并且只将错误站点中的服务器列为可用的 DFS 服务器。
SRV-1 上有一个 WINS 服务器,所有机器都将其 WINS 客户端指向 192.168.0.70。WINS 记录似乎没问题:
我还查看了所有服务器上的 DNS 记录,它们似乎是正确的。服务器位于 AD 站点和服务中的正确站点中,并且它们已分配了正确的子网。所有服务器都在 NTDS 设置中相互连接(双向)。
我所做的一些观察:
站点 A 中的 SRV-1 (192.168.0.0/24):
C:\Users\Administrator>nltest /DCLIST:DOMAIN
Get list of DCs in domain 'DOMAIN' from '\\SRV-1'.
SRV-1.domain.example.local [PDC] [DS] Site: Site-A
SRV-2.domain.example.local [DS] Site: Site-A …
Run Code Online (Sandbox Code Playgroud)