我有一个作为Windows文件集群运行的两个Windows 2012 R2。 iSCSI驱动器和SMB共享节点之间几乎可以立即进行故障切换，文件集群工作正常。
我还拥有另一台Windows 2012 R2文件服务器，其中包含远程位置数据的预先播种副本。 我使用了新的DFSR数据库导出function。 我使用指南作为几乎完整的参考： http : //blogs.technet.com/b/filecab/archive/2013/08/21/dfs-replication-initial-sync-in-windows-server-2012-r2-attack -of最clones.aspx
一旦复制开始就没有问题。 在初始复制过程中，文件服务器正在解决文件之间的冲突问题。 但是，我确实遇到了访问SMB-Shares的客户端networking性能的显着下降。 它是随机的，并不会立即影响所有人。 在整个过程中，两个文件服务器上的资源使用率都很低。
然后随机地，整个DFSR服务在群集上进入失败状态。 导致级联效应，使所有SMB-Share退出，并对networking上的任何人无响应。 最重要的是，它可以防止SMB共享故障转移到其他集群 。 DFSR服务卡住，不能通过services.msc停止。 你被迫杀了实际的过程。
我遇到了必须手动停止DFSR服务的情况，而且大部分时间都不起作用。 带领我杀死DFSR进程。
我已经尝试重新创buildDFSR组，文件夹，连接多次。 包括在AD中完全删除DFSR数据和系统卷信息文件夹。
即使从头开始全新的设置，问题仍然存在。 记住数据是预先播种的，而我是DFSR克隆数据库。 我想知道有没有人遇到这样的问题？
这是使用MS和Vmware的最佳实践在Vmware上运行的群集。
其约3TB的数据，许多小文件，预先复制。
我已经能够在服务器中的数据之间达到百分之百的网格，只有当发生大的变化时才能解决上述问题。
DFSR非常不稳定
适当的复制banwidth限制被设置，数据通过站点到站点的VPN在两个服务器之间转移。
我正在使用DFS命名空间（与dfsr文件夹无关），我正在使用DFS的域path。