WSFC与DFS

WSFC里面的文件服务器群集，文件始终是一份，数据始终存放在群集磁盘中，通过群集来维持文件服务器这项服务始终持续可用，在2012之前同一时间WSFC只能有一台节点对外提供文件服务，2012开始群集引入SOFS，同一时间多个节点都可以对外提供服务，但是注意，数据仍然是一份，2012是根据服务器连接随机决定访问到的节点，2012R2开始根据share目录来决定随机访问到的节点，即是说，数据还是一份，只不过后来多个节点同时对外提供服务，但都是访问的不同节点。

相比较而言，WSFC文件服务器群集是一种高可用架构，DFSR则是一种复制架构，同一份数据会被复制到多个成员服务器上，然后用户通过DFSN的一个逻辑名称去访问复制目标，后台由DFSR机制去驱动数据复制

每种方案都有自己的利弊，用户在实际环境使用时可以根据需要选择适用于自己的方案

DFS：适用于存放文件，应用，图片，等小文件，DFS复制不适用于复制打开后不会关闭的文件，例如VM，SQL文件，DFS复制最好是结果集文件，不建议频繁增删改的目录进行DFS复制，DFS复制通过DFS特有机制实现，管理员需要熟悉DFS复制原理，通过DFS可以针对复制时间进行控制，可以和AD集成控制不同站点子网客户端定位不同DFSR服务器，当侦测到一台DFSR成员服务器宕机，DFS可以自动完成切换，复制期间所有DFSR成员服务器都可以读写。

WSFC 传统文件服务器群集：简称TFSC（Traditional file server cluster），不同于DFS，如果将文件共享部署为TFSC架构，那么同一时间将只有一台节点对外提供服务，另外节点待命，当对外提供服务节点宕机，其它节点完成故障转移，TFSC支持和BranchCache整合，利用缓存提高用户对文件的访问速度，如果用户比较熟悉WSFC，那么可以考虑使用WSFC架构来为运营文件服务器群集，文件集中存放在共享存储，如有必要可以针对共享存储进行统一备份，不需要再单独学习其它功能。理论上来说传统文件服务器群集支持存放文件，应用，图片，大文件，数据库文件，虚拟机磁盘文件，ISO等，但是针对于数据库文件，虚拟机磁盘文件最佳还是建议存放至SOFS目录，因为可以结合SMB witness，DNS轮询等技术实现所有节点的AA架构，再配合SMB多通道，RDMA技术，性能更好，故障转移时间更短，TFSC只能做到AP架构。

WSFC 横向扩展文件服务器群集：简称SOFS（Scale-Out File Server），它最大的优势就是可以实现所有节点的AA模式，同一时间所有节点都可以对外提供服务，这样带来的好处就是故障转移时间更短，仅是一个重定向服务器的过程，对于存放虚拟机，数据库文件，性能更好，它的劣势就是对于信息工作者的文件，例如文档，图片等小文件并不适用于，这类文件在SOFS上面性能会缓慢，有时还会出现问题，因为SOFS不支持文件服务器的任何缓存，SOFS目前为止还是专门为虚拟机，数据库文件设计。

从归档的角度来说不论是SOFS还是TFSC都可以存放虚拟机磁盘文件，数据库文件，但是从正在使用的角度来说，假如是正在使用的虚拟机或数据库，则还是SOFS更加实用，因为SOFS底层是CSV，TFSC底层直接是群集磁盘，当发生故障转移时TFSC需要经过卸载挂载磁盘过程，SOFS底层是CSV，因此故障时间要短很多。

存储复制：Windows Server 2016新增技术，DFS复制是文件目录级别，存储复制是分区级别，DFS只支持复制关闭的文件，存储复制无此限制，DFS是分布式的，各个节点都可以读取，存储复制备站点暂时不可以读取，DFS可以提供统一对外名称，名称访问与复制功能分离，存储复制不提供统一对外名称，DFS主要用于复制关闭的文件，信息工作者文件，存储复制主要用于Hyper-V，SQL，文件服务器，大文件，私有云场景，存储复制可以在单机场景下帮我们保证分区级别的数据复制，也可以在群集场景下和WSFC整合，帮助我们跨站点的复制群集磁盘，保证计算+存储的双重高可用。

具体大家可以根据自身的场景选择合适的方案

上面我们说了一下WSFC和DFS以及最新的存储复制，所适用的不同场景，接下来我们再看WSFC和DFS的契合点

WSFC和DFS有关系的地方有三点

1. DFS独立根命名空间群集角色

2. DFS复制群集，通过DFS群集向外面成员服务器复制

3. 文件共享见证

之前老王曾经有篇文章和大家提到过DFS的一些基础知识，故不再做过多赘述，简单来说DFS命名空间有两种，一种是域命名空间，这种架构，当用户访问的时候会通过域控制器查询命名空间服务器，根据算法挑选一台节点进行访问，当一台域命名空间服务器宕机，自动切换至其它节点，另外一种是独立根命名空间，这种架构就是我们不把命名空间数据写入域数据库中，可以选择单机或群集，用户每次查询DFS路径时，由单机或群集来提供服务器路径，单机就是仅一台机器提供空间服务，群集就是我们在群集中创建一个独立根命名空间的角色，然后通过AP架构，同一时间只有一台节点提供命名空间查询，该节点宕机后切换至其它节点，由于根保留在群集中因此它具有高可用性。此外，存储在群集上的文件共享上的任何数据也是高度可用的，在此实现中使用DFS的价值在于名称空间和链接高度可用，但缺点在于故障转移切换时间对比域命名空间架构略长。

除了直接在群集中部署共享和DFS独立根命名空间角色外，我们也可以部署域命名空间架构，但是添加已经部署在群集里面的文件共享作为目标，这样既保证了文件共享的高可用，也利用域命名空间提供的快速切换。

DFS复制群集，国内比较冷门的一个场景，从Server 2008R2开始引入，其大概意思是在群集节点上面配置DFS复制目标，让群集作为复制组成员，将TFSC里面的共享复制到远程的单机DFS，或远程DFS群集，远程单机不知道我这面是单机或是群集，只知道来自这个群集计算机给我发送复制 或 我需要向它提供复制，但其实背后是经过群集引擎协调，当其中一个群集节点宕机，远程DFS依然可以和群集计算机复制，只不过已经切换到另外一个节点提供复制服务。

操作步骤如下

1. 为每个群集节点安装文件服务器，DFS管理工具

2. 为群集配置TFSC角色，向导将自动配置DFS复制服务以实现高可用性

3. 输入客户端访问点，远程DFS将通过此名称连接群集DFS，

4. 选择群集DFS要使用的群集共享磁盘
   

5. 在TFSC主节点开启DFS管理工具

6. 创建DFS复制组，选择复制模型，来源目标，复制策略

实作步骤：https://blogs.technet.microsoft.com/filecab/2009/06/29/deploying-dfs-replication-on-a-windows-failover-cluster-part-iii/

应用场景

1. 中心收集：各个分支机构汇总数据复制到总部，总部目标是群集架构，数据存放总部共享磁盘统一备份

2. 灾难恢复：核心业务除了在总部机构通过群集实现高可用，将文件服务器设计成群集DFS目标，并且复制一份数据到远程DFS

文件共享见证，老王之前看到一些国内博客在WSFC上面使用DFS复制来提供文件共享见证，看起来高可用，但其实这不是被推荐的做法

弊病体现在跨站点群集最明显，以下图为例，当前SiteA SiteB两个站点各自两个节点，站点间通过Server 2016存储复制实现存储HA，每个站点内部有两台DFS复制服务器，两个站点DFS目标服务器组成复制组进行复制，提供的复制路径作为群集文件共享见证。

这样运作看起来没问题，但一旦发生网络分区的情况，就会遇上脑裂，我的意思是指SiteA与SiteB站点网络上失去链接，两个站点各自都拥有到各自站点DFS目标见证的资格，因此两站点内的群集分区都会以为自己是可用的，每个站点都将正常执行SQL客户端连接和编写/更新数据库，当网络恢复正常，存储开始复制的时候，一个非常可能的结果是，一方写的所有内容现在都消失了，强制仲裁启动后，被强制启动的一方所更新的内容将完全盖过另外一方。

因此对于文件共享见证来说，在多站点的情况下，在每个站点放置DFS复制服务器是很危险的事情，极有可能会导致群集脑裂，到时候就不好玩了，因此群集文件共享见证，DFS非常有讲究，为了避免脑裂，可以选择仅部署DFSN不配置DFS复制，或在一个第三方站点部署DFS复制，当两个站点发生灾难的时候，谁能联系上第三个站点的DFS复制路径谁就能获得启动群集。

即便是在单站点数据中心内，如果要使用DFS复制作为群集文件共享见证，也一定要确保不会发生网络分区的情况，不会出现网络不通了但部分群集节点可以联系到一台DFS节点，部分节点可以联系到另外一台DFS节点的情况，否则在这段时间内其中一方产生的数据，会在下次网络恢复时被消失。

在WSFC 2008R2 - 2016中我们可以为群集指定经过复制或未经过复制的DFS路径作为文件共享见证，WSFC 2019开始配置文件共享见证时将进行IsAlive检测，一旦检测到是DFS路径，则直接报错，DFS路径在WSFC 2019中被直接禁止作为见证，WSFC 2019中可以选的见证架构：TSFC共享，单机共享，磁盘见证，云见证，具体大家可以根据自身环境，以及需要见证来完成的事情来选择合适的见证架构。

在WSFC2019之前，只要设计得当，仍然可以使用DFS路径作为文件共享见证，WSFC 2019之前微软只是说不推荐这样做，很大程度上会发生脑裂，但老王认为设计得当仍是可行的，因为文件共享见证里面仅用于存放群集数据库配置log，记载着当前那个节点的群集数据库paxos标记为最新，这个数据WSFC 2008之后是可以实时从各个节点捞的，节点更新群集数据之后会自动更新log至文件共享见证，即便共享里面log不是最新，也可以随时从节点上获取最新的配置数据 。