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不是最新,也可以随时从节点上获取最新的配置数据 。