WSFC 2019 Cluster Set探索

Cluster Set是WSFC 2019中新的技术，将它翻译成集群集不太合适，我认为应该叫它群集横向扩展，Cluster Set功能能够帮助咱们跨多个群集实现虚拟机的流动，将虚拟化，S2D的规模从群集扩展至数据中心，统一管理数据中心群集生命周期，结合本地端可用性集技术实现虚拟机跨群集故障转移

Cluser Set主要应用场景以下

1. 群集规模扩展，单个群集内的虚拟机限制没法知足企业需求，所以构建多个2019群集，组成Cluster Set，解除单个群集限制，仍然能够统一管理

2. S2D规模扩展，S2D最多每一个群集16个节点，能够经过Clueter Set技术，将4个4节点的S2D群集组合起来，更好的弹性容许更多计算节点出现故障

3. 虚拟机跨群集手动迁移，跨群集故障转移，当虚拟机建立放置时能够评估各群集负载，选择合适的群集放置

4. 兼容不一样架构群集，能够不一样成员群集配置为不一样的存储架构，例如1个群集为SAN架构，1个群集为S2D架构，实现虚拟机跨域不一样存储架构的群集迁移，Cluster Set技术与CPU兼容技术整合，虚拟机能够在相同厂商可是不一样代数的群集之间迁移

5. 改变群集生命周期管理，在Cluster Set技术中，若是咱们要替换一个群集，能够直接将该群集中的虚拟机所有迁移至其它群集，而后从Cluster Set中移除该群集，卸载掉该群集角色，群集主机得以释放。

6. 带来可用性集技术，将Azure上面的可用性集技术带到本地，有专门用于Cluster Set的可用性集新技术，能够将多个群集添加到一个故障域中，而后再建立逻辑可用性集技术，凡是放置在可用性集的虚拟机，均会被放置到不一样的FD故障域，一个FD域是能够是一个群集或者是多个群集，进而实现跨FD故障域的故障转移，进一步提升高可用性。

Cluster Set 新概念及技术核心

看图说话，Cluster Set技术要想获得实现，引入的新核心技术有两个

基于WSFC 2019 新SOFS的统一命名空间，全部虚拟机都在一个大的统一命名空间下面跨群集流动

在WSFC 2019中，SOFS有了新的改变，利用此文咱们进行简单介绍

1. 改变CSV数据流尝试逻辑

      横向扩展文件服务器（SOFS）依赖于DNS循环来发送到群集节点的入站链接。在Windows Server 2016及更早版本上使用存储空间时，此行为可能效率低下：若是链接路由到不是群集共享卷协调节点的群集节点，则全部数据都会经过网络重定向到返回客户端以前的另外一个节点，SMB Witness服务检测到缺乏直接I / O再将链接移动到协调器，这可能会致使延误。

    在Windows Server 2019中效率更高，SMB服务器服务肯定卷上的直接I / O是否可行。若是能够直接进行I / O，则会经过链接。若是重定向I / O，它将在I / O启动以前将链接移动到协调器。并同步客户端重定向须要SMB客户端中的更改，所以只有Windows Server 2019和Windows 10 Fall 2017客户端在与Windows 2019故障转移群集通讯时才能使用此新功能。

2.SMB绕过CSV文件系统

在Windows Server 2016中，SOFS使用存储空间，客户端链接到SMB服务器与CSV文件系统通讯，CSV文件系统与NTFS通讯。来自远程SMB客户端的全部I / O都经过SMB服务器，CSVFS，NTFS和存储堆栈的其他部分。因为没法在REFS上进行直接I / O，所以CSV文件系统仅有助于隐藏存储故障。这一样适用于SMB连续可用性。咱们在Windows Server 2019中进行了更改，咱们仍然能够保留一个隐藏存储故障的层，但也绕过了CSV文件系统。为此，SMB服务器从CSVFS路径查询REFS/NTFS并直接在REFS/NTFS上打开文件。这些打开的全部I / O将绕过CSVFS并从SMB服务器直接转到REFS/NTFS

3.新横向扩展文件服务器角色

Windows Server 2019中有一个名为Infrastructure File Server的新扩展文件服务器角色。建立基础结构文件服务器时，它将自动为CSV驱动器建立单个命名空间共享（即\\ InfraSOFSName \ Volume1）。在超融合配置中，Infrastructure SOFS容许SMB客户端（Hyper-V主机）与基础设施SOFS SMB服务器的有保证的连续可用性（CA）进行通讯。故障转移群集上最多只能有一个基础架构SOFS群集角色。在Windows Server 2019中使用SOFS时，咱们如今在Infrastructure共享上进行“身份隧道”。从同一群集或Cluster Set访问基础架构共享时，应用程序令牌将被序列化并经过隧道传输到服务器，并使用该令牌完成VM磁盘访问。即便身份是本地系统，服务或虚拟机账户也能够适用

该基础架构扩展文件服务器角色能够手动建立 Add-ClusterScaleOutFileServerRole -Cluster MyCluster -Infrastructure -Name InfraSOFSName

或者当咱们建立ClusterSet管理群集，成员群集时，将自动建立该角色，此角色是咱们Cluster Set架构的核心

举例来讲，当咱们建立Cluster set管理群集时，会输入一个NamespaceRoot名称，此名称将做为整个ClusterSet里面的总命名空间，当咱们添加成员群集进来时，也会为成员群集自动建立这样的infrastucture角色，可是命令参数就是InfraSOFSName，每一个被添加进来的群集InfraSOFSName都不同，可是在整套ClusterSet体系里面，当咱们在群集中建立虚拟机时，若是但愿虚拟机可以跨群集流动，那么虚拟机的路径必定是\\NamespaceRoot\每一个成员群集的InfraSOFSName名称，所以管理群集上的Namespaceroot扮演的是一个引用做用，不实际存储虚拟机 全部群集的虚拟机想要调用存储都是访问这个总命名空间，再由总命名空间指向各个群集名称，经过这样的跨群集命名空间技术，以实现虚拟机的跨群集迁移。

须要思考的是每一个群集的都是各自的存储，并不是整个ClusterSet使用的是一套存储，若是一套成员群集挂了，虚拟机能够故障转移到成员群集，可是其它群集上面没有到存储的权限，也没办法联机上线虚拟机，所以考虑到存储的跨群集容错，能够在跨群集之间使用存储复制，这样能够彻底作到虚拟机放心的跨群集流动。

虽然是统一的命名空间，但这不是DFSN，是SOFS新的群集命名空间技术，它是一种轻量级引用机制，在此预览版本中新引入的类型为“SimpleReferral”。此引用容许SMB客户端访问成员集群SOFS上托管的目标SMB共享，管理群集NamspaceRoot不参与IO路径，SMB引用将永久缓存在每一个客户端节点上，而且Cluster Sets命名空间基础结构会根据须要动态自动更新这些引用

SOFS说完了，老王认为这是ClusterSet架构中最很差理解的一块，官网的资料对这里没有进行过仔细的说明，若是你们直接去看官网的ClusterSet可能会有点晕，所以老王将这最很差理解的一块拿来和你们掰开揉碎

ClusterSet技术得以实现 一方面是经过SOFS实现全部群集在一个跨群集的命名空间下面流动

另一点是实现了群集与群集之间的管理控制

引入管理群集与成员群集概念

管理群集，负责管理协调各个成员群集资源，各个成员群集向管理群集汇报资源状况，管理群集侦测各个成员群集健康情况，负责运营掌管群集命名空间顶级架构

咱们建立ClusterSet的群集就做为管理群集，除了运营命名空间，每一个管理群集上面还将维护Scaleout Master的群集类型，管理群集经过master角色协调各个成员群集，例如检测各个成员群集健康状态，控制虚拟机的跨群集故障转移，各个成员群集会将自身群集资源汇报给管理群集master角色，以供管理群集断定资源合适群集，同时也将控制管理群集内的故障转移，管理群集一般不实际承载VM，S2D工做负载。

成员群集，Cluster Set中的成员群集一般是运行VM和S2D工做负载的传统超融合群集，多个成员集群参与单个Cluster Set部署，造成更大规模的SDDC结构，成员集群参与故障域和可用性集构造，成员群集使用Scaleout Worker充当群集中惟一的联络人，以根据Master的要求协调本地群集交互，此类交互的示例包括虚拟机放置和群集本地资源清点，每一个成员集群只有一个Scaleout Worker实例

Cluster Set先决条件

1. 各个群集节点必须使用2019 17650及以上版本

2. 每一个群集必须有CSV

3. 建议至少一个管理群集，两个成员群集

4. 为全部节点添加跨群集节点的CIFS与VM委派

5. 设置各节点Hyper-V迁移使用Kerberos

6. 添加管理群集计算机对象BJMGMT至各成员群集节点本地管理员组
   

环境介绍

老王在这里假设的是一个数据中心的场景，有一个SDDC数据中心叫DC01-BJ，里面有三套群集，一套管理，两套成员，实现虚拟机在SDDC内跨成员群集流动

管理群集 

群集名称：BJMGMT Cluster Set名称 : DC01-BJ 群集命名空间:VMFILE

19server1 ：LAN 10.0.0.10 ，Storage 30.0.0.10，CLUS 18.0.0.10

19server2 ：LAN 10.0.0.11 ，Storage 30.0.0.11，CLUS 18.0.0.11

成员群集1

群集名称：HA01     群集InfraSOFSName共享名称：HA01

19server3 ：LAN 10.0.0.12，Storage 30.0.0.12，CLUS 18.0.0.12

19server4：LAN 10.0.0.13 ，Storage 30.0.0.13，CLUS 18.0.0.13

成员群集2

群集名称：HA02    群集InfraSOFSName共享名称：HA02

19server5：LAN 10.0.0.14，Storage 30.0.0.14，CLUS 18.0.0.14

19server6：LAN 10.0.0.15 ，Storage 30.0.0.15，CLUS 18.0.0.15

建立全部群集，并为每一个群集配置CSV，步骤略

建立ClusterSet，管理群集，群集命名空间

New-ClusterSet -Name DC01-BJ -NamespaceRoot VMFILE -CimSession BJMGMT -StaticAddress 10.0.0.88

建立完成后产生ClusterSet VCO角色，自动建立Infrastructure File Server类型横向扩展文件服务器角色，名称为NamespaceRoot名称

自动建立master角色，名称为ClusterSet名称

管理群集更新资源类型

添加各成员群集进入Cluster Set

 Add-ClusterSetMember  - ClusterName HA01 - CimSession DC01-BJ - InfraSOFSName HA01

 Add-ClusterSetMember  - ClusterName HA02 - CimSession DC01-BJ - InfraSOFSName HA02

自动建立Infrastructure File Server类型横向扩展文件服务器角色，名称为InfraSOFSName名称

自动建立ScaleOut Worker角色，无名称

Cluster Set 查看管理

#获取Cluster Set 成员群集状态

get-clustersetmember  - CimSession DC01-BJ

#获取每一个Cluster Set 成员群集状态+每一个群集内成员状态+管理群集状态

get-clusterset -CimSession DC01-BJ | get-cluster | get-clusternode

#获取每一个成员群集节点状态

Get-ClusterSetNode -CimSession DC01-BJ

#集中汇总Cluster Set内管理群集与成员群集的群集日志

Get-ClusterSetLog -ClusterSetCimSession DC01-BJ -IncludeClusterLog -IncludeManagementClusterLog -DestinationFolderPath <path>

Cluster Set搭建完成后，下一步考虑上面的应用，咱们须要虚拟机可以在Cluster Set环境中，跨群集实现虚拟机迁移，故障转移

要实现这一点须要配置四个内容

1.配置各个成员群集Hyper-V主机，使用Kerberos做为迁移协议

2.为各个成员群集内每一个Hyper-V主机，添加跨群集主机的Kerberos委派，CIFS以及VM迁移服务

3.添加管理群集计算机帐号进入各个成员群集本地管理员组，能够手动，使用脚本，或者使用组策略，把全部成员群集放在一个OU下，而后下发组策略

完成步骤后建立虚拟机，虚拟机路径指定为群集命名空间下的成员群集共享

4.在ClusterSet中注册虚拟机，只有被注册的虚拟机才能跨群集迁移，只有使用群集命名空间的虚拟机才能被成功注册

#Register all existing VMs

$ClusterSet="DC01-BJ"

Get-ClusterSetMember -CimSession $ClusterSet | Register-ClusterSetVM -RegisterAll

#跨群集移动VM存储

Move-VMStorage -DestinationStoragePath \\VMFILE\HA02 -Name HQ-SP-DB01

#跨群集移动VM

Move-ClusterSetVM -CimSession DC01-BJ -VMName HQ-SP-DB01 -ClusterName HA02

ClusterSet故障域，可用性集

相信你们都有了解过Azure上面的可用性集功能，用户能够建立一个可用性集，以后凡是被放置在同一个可用性集的虚拟机，都会被放置在不一样的FD，Azure上面记得保证的是不一样机架，如今这个技术拿到了WSFC 2019本地，只不过FD是群集单位，

#建立故障域，一个故障域内能够包括多个成员群集

New-ClusterSetFaultDomain -Name FD1 -FdType Logical -CimSession DC01-BJ -MemberCluster HA01,HA02 -Description "ChangPing Fault Domain"

New-ClusterSetFaultDomain -Name FD2 -FdType Logical -CimSession DC01-BJ  -MemberCluster HA03,HA04 -Description "ChaoYang Fault Domain"

#将故障域加入可用性集DC01-BJ-AS，建立的可用性集将生效于初始放置，计划内维护，计划外故障转移。

New-ClusterSetAvailabilitySet -Name DC01-BJ-AS -FdType Logical -CimSession DC01-BJ -ParticipantName FD1,FD2

#建立虚拟机时指定 -AvailabilitySet参数

最终实现效果将是被放置在同一个可用性集内的虚拟机 始终被放在不一样的FD，当一个FD失去，可用性集虚拟机将故障转移至另外FD

能够看出这是ClusterSet新有的故障域和可用性集功能，它与WSFC 2016的站点感知，故障域功能还不太一致，能够说ClusterSet是更贴近云数据中心环境的，将可用性从群集扩展到逻辑FD，同时能够整合Azure Stack

ClusterSet能够说是老王期待已久的一项技术，从去年年末知道它的消息，就一直盼望它能出来，可一直没有消息，只好本身去摸索，刚好7月10日cluster的technet blog更新了这项技术，老王马上研究，并及时与你们分享，在老王看来这是一项高大上的技术，高大上到通常的企业也许根本用不上。。。 除非是有意构建SDDC的企业，或运营商，可能会对这项技术感兴趣，基本上它的主要功能就是跨群集突破扩展限制，即使是没有SCVMM的状况下也能实现虚拟机跨群集实时迁移，故障转移

在老王看来这项技术对于我来讲，最大的意义在于可以实现虚拟机跨群集的故障转移，经过管理群集上面的Master机制侦听各成员群集状态，而且协调完成应用跨群集的故障转移，这是项不错的革新技术，将微软虚拟化的可用性边界真正向前走了一步

等它正式发布的时候老王认为跨群集故障转移，以及可用性集实现跨FD故障转移必将是一大亮点

对于这项及技术的预测和看法，老王认为目前的版本仍是麻烦一点，对于通常的管理员存在必定的配置门槛，须要仔细理解架构后才能运维，将来我对这个产品的建议

1.管理群集不要浪费，最好可以让管理群集也能承载必定的VM资源

2.目前这项产品的部署管理只能经过PS和WMI，仍是过于麻烦，将来但愿能够经过WAC或者GUI工具进行管理

3.建议可以向下兼容2012R2 2016 SOFS

4.能够直接考虑S2D和ClusterSet的集成，跨多个群集构建S2D存储池

5.建议优化群集命名空间架构

6.优化可用性集架构，确保被放置在同一可用性集的虚拟机始终不在同一个故障域内，除非该故障域崩溃且没有其它故障域可用，则放置相同故障域，提供与Azure Pack或Azure Stack对接接口，实现租户建立可用性集

7.建议优化部署架构，目前ClusterSet限制全部节点必须位于同一AD林

8.建议提供界面上面的负载预估功能，例如我能够建立一个虚拟机，在管理群集上面，可是由管理群集根据各个成员群集的负载去帮我放置，目前这个功能还须要经过PS完成，建议将来整合至SCVMM或WAC