是否应该使用 DFS 来同步 wwwroot？
我想知道使用 DFS 跨网络场同步内容是否是一个好主意？ 有人有这方面的经验吗？ 我们过去使用过 Robocopy，但发现它有点不完整且笨重。 本质上，我们希望避免每次一个文件更改时都必须对内容进行十次更改（这种情况经常发生，因为我们的网站很旧并且使用经典的 ASP。）
据我所知，DFS 通常适用于地理位置不同的位置，并用于制作UNC 共享对用户来说显得更简单且更易于管理。
我想用它实现的目标是仅将内容更改复制到将成为中心的十台服务器之一。 然后，我使用 FRS 将其他九台服务器配置为辐条。
任何有关此方法的想法或更好设置的建议将不胜感激。
I'm wondering if it's a good idea to use DFS to sync content across a web farm? Does anyone have any experience of this? We've used Robocopy in the past but found it a little patchy and clunky.
Essentially we want to avoid having to make ten changes to content each time one file changes (this happens a lot since our site is old and usues classic ASP.)
From what I gather, DFS is usually meant for geographically seperated locations and used to make the UNC shares appear simpler to users and easier to manage.
What I'd like to achieve with it is to only copy content changes to one of ten servers which will be the hub. I'd then configure the other nine servers as spokes using FRS.
Any thoughts on this methodology or suggestions for better setups would be much appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
出于性能原因，请勿将网站指向 UNC 路径。 与几乎任何其他文件访问方法相比，SMB 文件访问效率极低且缓慢。
您可以使用 DFS-R（通过 Windows 2003 R2）在启用 DFS 的共享之间启用复制，但一定要将 IIS 设置为指向共享的本地路径，而不是 UNC。
For performance reasons, don't point a web site to a UNC path. SMB file access is horribly inefficient and slow compared to pretty much any other file access method.
You can use DFS-R (via Windows 2003 R2) to enable replication between DFS-enabled shares, but definitely setup IIS to point to the share's local path, not UNC.
如果您使用的是 Win2003，请确保安装 R2，DFS 复制得到了很大改进，并且不使用 FRS。 即使通过 LAN，它也会执行您想要的操作。
If you're using Win2003 make sure to install R2, DFS replication is much improved and doesn't use FRS. It will do what you want, even over a LAN.
不要为此使用 FRS，它可能会造成混乱。 使用 DFS 和其他同步技术（例如 Symantec Replication Exec）效果很好。 确保在 Active Directory 中使用 IP 范围创建正确的站点结构，以便 DFS 选择正确的服务器。
几年前，当 Windows 2003 刚刚推出时（在 SP1 之前，情况可能会变得更好，但我不确定），我在几年前使用 FRS 进行了尝试。 FRS 两次完全发疯并删除了我们的文件，更不用说它堵塞并且无法自行恢复的次数了。 FRS 还只同步关闭的文件，保持打开的文件不同步（例如在进行日志文件收集时）。 FRS 适用于拥有适量相对较小文件且服务器上没有进行太多更改的环境。
Don't use FRS for this, it may get confused. Using DFS and another sync technique, such as Symantec Replication Exec, works fine. Make sure to create the correct site structure with IP ranges in Active Directoy so that the correct servers are chosen by DFS.
I tried that some years ago with FRS, when Windows 2003 was new (before SP1, things may have become better since then, but I'm not sure). FRS twice completely went nuts and deleted our files, not to talk from the amount of times it just clogged up and failed to recover itself. FRS also does only sync files which are closed, files which are left open are not synched (when doing log file collection for instance). FRS is fine in environments where you have a moderate amount of relatively small files with not too many changes going on on the server.
我最近禁用了 UNC DFS 作为服务器上的站点根； 在重负载下，该网站将变得无法响应请求。 将站点 wwwroot 指向本地驱动器并重新启动 IIS 可以快速恢复站点速度。 我必须建议，如果您采用 DFS 路线，只需将其复制到本地驱动器，而不是使用 UNC 路径作为 wwwroot。
I have very recently disabled the UNC DFS as the site root on a server; under heavy load the site would become unresponsive to requests. Pointing the site wwwroot to a local drive and restarting IIS quickly restored the site speed. I have to recommend that if you go the DFS route, simply have it replicate to a local drive instead of using the UNC path as the wwwroot.