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

2018-07-12_140027.png

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

2018-07-12_140441.png

自动创建master角色,名称为ClusterSet名称

2018-07-12_140457.png

管理群集更新资源类型

2018-07-12_142155.png


添加各成员群集进入Cluster Set


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

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

2018-07-12_154801.png


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

2018-07-12_154119.png

自动创建ScaleOut Worker角色,无名称

2018-07-12_154230.png


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作为迁移协议

2018-07-12_162716.png

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

2018-07-12_172144.png

3.添加管理群集计算机账号进入各个成员群集本地管理员组,可以手动,使用脚本,或者使用组策略,把所有成员群集放在一个OU下,然后下发组策略

2018-07-12_162037.png


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

2018-07-12_164155.png

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