WSFC 2019 Cluster Set探索

标签：官网   发布   sof   its   tcl   隐藏   改变   包括   配置   

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机制侦听各成员群集状态，并且协调完成应用跨群集的故障转移，这是项不错的革新技术，将微软虚拟化的可用性边界真正向前走了一步，在目前的版本中根据老王的尝试实时迁移一个虚拟机没有问题，但是故障转移有时还不太稳定，应该还再等两个版本才能成熟起来，和当初Honolulu一样，忍不到它真正成熟，我就想来看它的样子

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

对于这项及技术的预测和见解，老王认为还是麻烦了一点，对于一般的管理员存在一定的配置门槛，需要仔细理解架构后才能运维，未来我对这个产品的建议

1.管理群集不要浪费，最好能够让管理群集也能承载一定的VM资源，目前这项产品的部署管理只能通过PS和WMI，还是过于麻烦，未来希望可以通过WAC或者GUI工具进行管理

2.建议能够向下兼容2012R2 2016 SOFS

3.可以直接考虑S2D和ClusterSet的集成，跨多个群集构建S2D存储池

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

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

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

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

WSFC 2019 Cluster Set探索

标签：官网   发布   sof   its   tcl   隐藏   改变   包括   配置   

原文地址：http://blog.51cto.com/wzde2012/2141066