Iis 是否应使用DFS同步wwwroot？

我想知道使用DFS跨web场同步内容是否是个好主意？有人有过这样的经历吗？我们过去使用过机器人技术，但发现它有点零碎和笨重。 从本质上讲，我们希望避免每次一个文件更改时都要对内容进行十次更改（这种情况经常发生，因为我们的网站很旧，通常使用经典的ASP。）

据我所知，DFS通常用于地理位置不同的位置，用于使UNC共享对用户来说更简单，也更易于管理

我想用它实现的是只将内容更改复制到十台服务器中的一台，这十台服务器将成为中心。然后，我将使用FRS将其他九个服务器配置为辐条

---

如果您对这种方法有任何想法或对更好的设置有任何建议，我们将不胜感激。

如果您使用的是Win2003，请确保安装R2，DFS复制将得到很大改进，并且不使用FRS。即使在局域网上，它也能做你想做的事情。

出于性能原因，不要将网站指向UNC路径。与几乎所有其他文件访问方法相比，SMB文件访问效率非常低，速度非常慢

---

您可以使用DFS-R（通过Windows 2003 R2）在启用DFS的共享之间启用复制，但一定要将IIS设置为指向共享的本地路径，而不是UNC。

不要为此使用FRS，它可能会混淆。使用DFS和其他同步技术（例如）可以很好地工作。确保在Active Directoy中创建具有IP范围的正确站点结构，以便DFS选择正确的服务器

---

几年前，我曾在FRS上尝试过，当时Windows 2003还是新的（在SP1之前，事情可能已经变得更好了，但我不确定）。FRS两次完全发疯并删除了我们的文件，更不用说它只是阻塞了并且无法恢复自身的次数了。FRS也只同步关闭的文件，不同步打开的文件（例如，在收集日志文件时）。在服务器上有少量相对较小的文件且没有太多更改的环境中，FRS很好。

我最近禁用了UNC DFS作为服务器上的站点根目录；在重载情况下，站点将对请求无响应。将站点wwwroot指向本地驱动器并重新启动IIS可快速恢复站点速度。我不得不建议，如果您选择DFS路径，只需将其复制到本地驱动器，而不是使用UNC路径作为wwwroot。

我就是这么想的，从上载新文件到将其推送到其他内容服务器之间的时间来看，复制是否可以轻松配置？谢谢您的警告。我的计划是使用本地目录（始终是d:\WebData），这是否意味着在我提议的方案中名称空间非常冗余？如果是，是否应该禁用它（如果可能的话）？如果IIS指向本地路径，则DFS设置本身是不相关的。我想您应该利用DFS-R来管理web场，以实现容错或负载平衡。基于域或基于主机的命名空间方法由您决定，因为您将是唯一通过UNC路径访问它的人。我对此有点困惑，您是说如果您建议使用Symantic工具（我将对此进行调查），您是说不要使用DFS同步（我相信它是DFS中内置的FRS？）吗；t这否定了DFS，因为我只想在复制过程中使用它，因为用户永远不会使用名称空间，因为主要目的只是同步将通过FTP更新的IIS数据，因此文件永远不会被打开，我也不会同步日志文件夹。我要说的是，通常使用DFS是可以的（使用“正常的”在UNC路径上使用网站的注意事项），但不能使用内置同步（即FRS）。当然，如果您在每台web服务器上都有一个复制代理（假设您使用的是Symantec工具），同步到本地目录并将其用作本地web源目录，您将获得最佳性能。Thaks，我现在开始理解了。然而，似乎如果我使用其他代理，比如Symantc，那么拥有DFS就没有意义了，因为该代理将完成我首先想要DFS（使用FRS）的部分工作。我没听错吧？很抱歉延迟回复。。。但是是的，你是对的。DFS仍然可以设置为这样一个副本上的分布式UNC共享，这就是我想说的。但是在没有基于UNC的web根的web托管的情况下，就不再需要DFS了，对吧。