场景：
我有一个目前没有内部部署服务器的分支机构.他们可以访问所有内容,包括跨12Mbps WAN链路(MPLS)的DC.链接未饱和,平均利用率约为20％.该电路非常稳定,具有高SLA和出色的正常运行时间.
但是,通过WAN从文件服务器进行的大型文件传输(主要是读取而非写入)可能很慢.我们目前不使用DFS.
研究完成：
我知道WAN加速,例如使用专用硬件(Riverbed)或专用软件VM(Silver Peak).但是价格超出了我们目前的预算,从我们的角度来看,需求还不是很明显(因为问题主要在于“拉动”情景,不一定是推/拉).
我主要是在这个分支机构部署Windows服务器,并使用DFS-R或BranchCache.查看表比较并假设我们正在查看“托管的branchcache服务器”而不是简单地分发：
看起来两者都有好处,即使两者都在服务器上“托管”.
我实际上有的问题：
>在哪些场景中,每种技术都会闪耀,你在哪里选择其中一种？
>查看托管的Branchcache服务器,您是否可以在中央文件服务器上设置“预取”某些文件夹/文件,以便可以在分支机构本地立即访问它们？您是否必须按计划(如果可能)这样做？
>看看DFS-R我的担忧(显然已经解决了第三方应用程序)是文件锁定并确保文件在写入操作期间正确更新(即,确保是否访问了这两个副本并且两者都被写入,哪个文件优先级和变化会发生什么？).理想情况似乎是锁定数据的任何备用副本,但它真的是一个大问题吗？
> Branchcache是否锁定了中央文件以进行编辑？
> branchcache是否只将增量传回给已更改内容的中心文件？
>如果分支机构服务器也将被用作域控制器,那么这两种技术都会被建议吗？
DFS没有锁定.没有弹性的WAN技术会锁定,因为如果/当WAN链路断开时无法锁定 – 因此它可以是弹性或锁定.
如果您需要版本控制/锁定才能正常工作,则只能使用中央服务器. BranchCache在这一刻可以帮助下载REPEATED下载速度.只要.
如果你没有 – 也就是你需要从很多地方做很多更新(这是一个QUITE不寻常的场景 – 大多数时候文件没有像公司那样被锁定)那么你必须支付更多的带宽.需要出现.或者你可以使用一些thind派对DFS-R项目,但是你有另一个问题….这确保带宽不会下降复制大量未使用的东西,因为DFS-Replication完全沿着文件共享线,而不是按需元素.
这真是一个“该死的,如果你这样做,该死的,如果你不这样做”的情景.特别是在LAN(高延迟,某些不可靠性)到位的情况下.
BranchCache例如作为更新缓存发光 – 无需在分支机构中拥有本地WSUS服务器.没有锁定,因为它是纯缓存机制 – 您无法编辑BranchCache文件.也就是说,由于没有锁定,写入将锁定CENTRAL文件 – 然后更新的版本将传播,因此它实际上可能适合您;)
DFS非常适合只读(安装图像,安装软件映像,集中编辑的策略文档等).有趣的是,我已归入此类别的大部分文件 – 我们在这里编辑的内容主要是使用其他同步技术(sharepoint文档管理)的中央文件. DFS是满足技术复制需求的出色技术解决方案.
http://pertorben.wordpress.com/2012/05/29/dfs-r-or-branchcache/
有一个非常好的深度解释.
BranchCache可能会工作….它不会停止单个下载延迟,但它将处理重复读取.它还允许锁定.
编辑：在更加彻底的讨价还价之后,看起来现在可以进行预加载.请参阅
