WSFC2016 故障域站点感知

Posted 2020-10-06

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了WSFC2016 故障域站点感知相关的知识，希望对你有一定的参考价值。

很高兴和大家介绍另外一项WSFC2016的酷炫技术，即故障域功能

与之类似的技术有CloudStack，Openastack等

以CloudStack为例，在ClusterStack中，针对于资源架构，我们可以手动来定义架构模型，从最上层Region，Zone，Pod，Cluster，再到最底层的Host，通过规划这样一套架构模型，我们可以在云管理软件上面定义出云资源池底层的架构，实现既能够对于用户屏蔽技术细节，也能够让云管理软件按照架构模型运转

其中最上层，最大的架构为 Region，也就是地域了，例如，我们在使用阿里云，Azure，AWS的时候创建虚拟机，都只需要选择一个区域就好了，对应到后台就是这个概念，Region的概念是地域，不同Region，则应该意味着不同地域，如果说用户把两台虚拟机部署在两个不同的Region，那么它们同时出现故障的几率会很低

其次是Zone，CloudStack中，Zone主要是指数据中心，我们说一个Zone，就是说一个数据中心，一个数据中心里面可能有多个Pod，即机架，不同机架可能使用不同的网络架构设施，一个机架上面有可能有多个Cluster，一个Cluster上面又可能有多个Host，同一个Zone内共用一个二级存储。

定义这样的架构后，对于用户来说，用户不需要知道太多，它们只需要知道，我们要部署到离我们访问地方比较近的Region，如果我的不同虚拟机放在不同Region，会被放置在不同的，很远的地方，不会同时发生故障，这样就够了

一些云平台例如Azure，可以让用户选择不同的可用性集，对应的概念，就是这里的机架，如果选择虚拟机在不同的可用性集，意味着虚拟机会被放置在不同的Pod，微软也叫做Rack，如果部署了可用性集后Azure才可以保证SLA在99.95%

一套云管理系统，对于资源管理员来说，管理员主要关注的是持续保证租户资源的SLA，置备多种高可用方案，灾备方案，等等，这里我们主要讨论的是高可用方案，在高可用方案里面，通常在云计算业内，人们会谈到故障域

什么是故障域呢，例如，我一个节点坏了，上面虚拟机可以漂到其它节点，这时候节点是一个故障域，单个节点故障了，我们部署了群集系统，会故障转移，并不会影响SLA

默认情况下大多数云管理平台的failover级别都是Cluster内的节点级别，理想情况下，老王认为，所有已定义的Region，zone，pod，Cluster都是应该可以感知的，例如，如果群集里面一个节点坏了，我可以把虚拟机先迁移到Cluster内其它节点，如果不行，再迁移到同Pod上面其它群集，如果不行再迁移到Zone里面的不同Pod，如果不行再迁移到不同Zone，甚至最后整个Zone瘫痪，还可以转移到其它Region恢复运行，如果真的可以做到这样就太强大了，真正实现了云计算持续可用的目的

不过在现实情况下，根据老王的观察，我们软件的定义的这些Region，zone，pod，Cluster，一部分是用来看的，一部分是用来用的，假设Region，zone，pod这些东西没有和云资源故障系统达成感应，那么是不会有老王上面说的效果的，可能最多就是，我们可以集中针对同一个Pod里面的Cluster或Host进行policy设置，可以让一个Zone中心里面的所有Pod，Cluster使用相同的共享二级存储，或者通过报告集中输出下报告之类的。

实务上通常一些云计算厂商会实现Region级别，Pod级别，Cluster级别的故障域感知，例如Cluster失效，会恢复到其它Region继续运行，或是Cluster维护，由Pod上面其它Cluster暂时负责服务。

这里老王说了这么多，是希望把故障域这样的一个概念带给大家，这个概念是相通的，不光在微软WSFC 2016会有，在Cloudstack，Openstack等其它云平台管理软件中也会有，老王认为这项功能在云平台管理，或者大型数据中心，大型托管数据中心里面会很常见，是项规范管理的好功能。

这项技术把它叫做软件定义故障域也好，故障域也好，举个例子，什么是故障域呢

比如我们知道，租户的虚拟机在HV01节点，Cluster01上面运行，Cluster 01在Pod01上面，Pod01在Zone01，Zone01在Region北京运行，之前是在脑子里知道，现在我们可以通过软件定义在管理系统中

如果HV01节点Host级别坏了，由于Cluster自动实现主机级别故障域，节点会转移到其它节点上面运行，注意，只要是通过可以正常进行故障转移的系统构成的cluster，那么默认物理上就已经实现为了主机故障域

如果Cluster坏了呢，那么Cluster就是一个故障域，Cluster上面会有很多台虚拟机，也会随之跟着停机，如果没有置备跨Cluster的转移机制，这里就会产生宕机时间。

如果Pod级别坏了，那么Pod就是一个故障域，Pod上面会有很多Cluster，Cluster里面又会有很多应用，所有全部停机。

如果Zone级别坏了，那么整个Zone就是一个故障域

如果Region级别坏了，那么整个Region就是一个故障域

大家可以看出，越大的级别坏了，影响到的越多，所以对于架构人员来说，如果你作为一个云提供商或者大型托管数据中心提供商，那么首先您应该针对于每个故障域级别强化可靠性，尽量做好灾难恢复机制，什么级别的故障域出现故障，需要如何恢复处理，其次，应该想办法实现用户云资源的跨故障域转移，例如当前在Cluster运作，如果Cluster坏了，能否转移到其它Pod，或其它Zone继续运行，实现后建议用户在不同的可感应故障域上面部署资源。

故障域级别，通常这种东西，是管理员心里有数，或者写在合同上面的东西，我们通过一些云平台软件或管理软件，无非就是实现故障域，在电脑界面上面可见，可出集中管理，出报表，出架构视图

但是更重要的，我们是要实现故障域的感知，确保用户选择到不同故障域的相同资源不会同时出现故障，确保故障域发生可以跨故障域感知，让用户虚拟机正常情况在同Region下面的群集节点运行，如果同Region出现故障，可以直接让虚拟机跨Region迁移继续运行，因此故障域的定义大体会有以下功能

1.实现软件层面的故障域架构，便于记录查看，便于与物理架构对应

2.实现云管理策略按照故障域架构分配策略

2.实现故障域感知，确保用户选择到不同故障域的相同资源不会同时出现故障

3.实现跨故障域感知，在发生故障时能够让资源跨不同级别故障域进行转移

4.通过故障域功能，可以提高同一故障域内，存储，网络，计算资源的粘性性能，确保同一故障域内的存储和计算资源可以很快的工作。

要实现故障域，主要工作应该分为两步，1.逻辑定义 2.具体实现

逻辑定义，即是我们先定义出来，故障域数据，先在软件层面创建出来，让后把资源加进来，这样看起来我们有了故障域了，但其实只是看着好看，如果云平台支持，可以做一些报表或策略控制

具体实现，既真正实现故障域的功能，让用户不同作用域的资源不会同时宕机，让低级别故障域不可用，用户资源还可以跨故障域迁移到更高的级别，具体实现这个步骤呢，一部分我们可以依赖于技术手段，如果技术手段不到位，我们也可以依赖于手动，或者说，人脑把

定义了故障域不是说了几个字那么简单，管理员做维护的时候，是要心里有数的，例如，不能同一时间对所有故障域做维护吧，一定要先维护好一个故障域，再维护另外一个，如果技术手段不行，不能做到跨故障域级别故障转移，那么真的一个故障域级别坏了，管理员是需要手段把用户资源弄走再到另外故障域恢复的。

所以说故障域，不光是软件上面的定义和技术实现，更多的也是要求管理员维护的时候有故障域这样的一个思路，如果用户资源在不同故障域，我应该怎么维护，不同的故障域级别坏了，我应该关注那些内容，参照什么流程恢复，如何跨故障域级别恢复，等等，软件技术层面实现之后，更多的是维护流程

Ok，上面看了很多通用性的概念，下面我们就来看下微软WSFC 2016在故障域上面交出的答卷把

在WSFC 2016中微软针对于故障域，开通了个四个级别，分别是Site，Rack，Chassis，Node，其中Node是群集安装后默认就有，站点，机架，机箱，我们可以自行创建，自行构建它们之间的嵌套级别，并且针对于每个故障域级别都可以做详细的说明，便于查看，让我很感到惊喜的是WSFC 2016中的故障域并不只是说说而已，而是真的WSFC本身就可以帮助我们实现故障域感知的功能，目前老王观察看到 Site，Rack，Chassis这三种故障域级别都有各自生效的场景

例如，同一个Site上面的Node，默认情况会在Site内执行故障转移，如果Site所有群集节点不可用，再转移至不同Site，随之又有很多Site故障域级别的粘合性优化，可以配置群集级别的首选Site，应用级别的首选Site，同一个Site虚拟机会使用同一个Site的存储，如果存储移动到其它Site，则虚拟机也跟着移动，等等，本文后面我也将主要介绍WSFC 2016 Site级别的故障域感知。

还有一种场景，即Storage Direct Spaces，这项技术相信很多关注微软技术的朋友已经测过了，类似于VSAN，可以将每个节点肚子里面存储贡献出来形成一个存储池，再基于这个存储池构建存储空间，CSV，SOFS，最终交付给应用，在SDS的场景下，当我们写入数据给SDS存储空间，数据是会被撒在不同节点的，配置了双向镜像，三向镜像，双重校验的等容错技术后，数据会被撒多份，届时在容错技术容许的情况下，可以允许指定的节点数坏掉，然后新加节点恢复，或磁盘坏掉，新加磁盘恢复，所以，默认情况下SDS就已经有了磁盘级别故障域，节点级别故障域

我们也可以把SDS技术和WSFC 2016故障域新功能结合起来，在开启SDS功能前，我们针对于节点构建Rack或Chassis级别的故障域，届时SDS执行容错时，将按照拓扑进行操作，例如会保证数据始终洒在不同Rack或不同chassis节点上面，这样即便是一个Rack或一个chassis故障，也不会影响SDS，注意，如果希望实现这项功能，建议最好在SDS开启之前就规划好故障域级别，否则SDS建好之后在规划，需要重新移除节点，再加入到故障域。

WSFC 2016故障域群集配置命令：

Get-ClusterFaultDomain：获取群集故障域架构，可以从群集级别，或任意故障域级别

Set-ClusterFaultDomain：移动资源所属故障域，配置故障域相关参数

New-ClusterFaultDomain：创建群集故障域，可以选择Site，Rack，Chassis级别的故障域

Remove-ClusterFaultDomain：删除故障域

实验示例：

#创建北京站点和上海站点

New-ClusterFaultDomain -Type Site -Name "Beijing" -Description "Primary Site"

New-ClusterFaultDomain -Type Site -Name "Shanghai" -Description "Secondary Site"

#创建北京站点数据中心Rack和上海站点数据中心Rack

New-ClusterFaultDomain -Type Rack -Name "Rack Beijing1" -Location "Fumadasha 17, Room 501"

New-ClusterFaultDomain -Type Rack -Name "Rack Shanghai1" -Location "TaiDidash 14, Room 203"

#创建北京Rack上面的两个机箱，上海Rack上面的两个机箱

New-ClusterFaultDomain -Type Chassis -Name "Chassis 01"-Location "Rack Beijing01 Ontop"

New-ClusterFaultDomain -Type Chassis -Name "Chassis 02"-Location "Rack Beijing01 Under"

New-ClusterFaultDomain -Type Chassis -Name "Chassis 03"-Location "Rack Shanghai01 Ontop"

New-ClusterFaultDomain -Type Chassis -Name "Chassis 04"-Location "Rack Shanghai01 Under"

需要注意，这里每个故障域Name都将是唯一的

#添加服务器进入机箱

Set-ClusterFaultDomain -Name "HV01" -Parent "Chassis 01"

Set-ClusterFaultDomain -Name "HV02" -Parent "Chassis 02"

Set-ClusterFaultDomain -Name "HV03" -Parent "Chassis 03"

Set-ClusterFaultDomain -Name "HV04" -Parent "Chassis 04"

#构建机箱机架站点依赖关系

Set-ClusterFaultDomain -Name "Chassis 01" -Parent "Rack Beijing1"

Set-ClusterFaultDomain -Name "Chassis 02" -Parent "Rack Beijing1"

Set-ClusterFaultDomain -Name "Chassis 03" -Parent "Rack Shanghai1"

Set-ClusterFaultDomain -Name "Chassis 04" -Parent "Rack Shanghai1"

Set-ClusterFaultDomain -Name "Rack Beijing1" -Parent "Beijing"

Set-ClusterFaultDomain -Name "Rack Shanghai1" -Parent "Shanghai"

#获取故障域拓扑

Get-ClusterFaultDomain

#获取故障域完整信息

Get-ClusterFaultDomain | ft name,type,parentname,childrennames,Location,description -autosize

还可以把，在这里大家可以看到，老王之前定义的所有故障域，以及嵌套关系，还有位置信息和说明信息，这两个也是新属性，主要用于对故障域做标注使用，便于排错或者查找，可以看到，从城市级别，到数据中心大厦级别，到屋子级别，机架级别，甚至定义到机架上面机箱的位置。您也可以在站点Location的位置输入城市+数据中心信息，Location和description信息也可以后期Set去改，这里有很多种玩法，大家可以自己去发掘，关键是准确，有意义，明了即可。

#获取单一故障域拓扑

#获取某一级别故障域拓扑

#删除故障域

如果要删除一个故障域，要求下面没有子资源，例如我们要删除Chassis 01，但是下面有HV01节点，我们就需要先移除HV01出去

#移除要被删除故障域下面资源

Set-ClusterFaultDomain -Name "HV01" -Parent ""

#删除故障域

除了可以使用Poweshell配置群集故障域，还可以导出xml进行配置，编辑完成后再导入xml

#导出故障域架构xml

Get-ClusterFaultDomain | Out-File <Path>

使用工具完成XML后，需要使用以下命令再把XML上传回去生效

$xml = Get-Content <Path> | Out-String

Set-ClusterFaultDomainXML -XML $xml

以上，老王简单为大家介绍了下WSFC2016中新增的故障域功能，以及配置办法，但是到目前为止我们只是逻辑创建出了故障域，可以看到，可以和物理对应，但是有没有生效呢，还没有，因为故障域的生效，取决于云管理平台，或WSFC能感应到什么程度

在常规设计中，故障域通常是在云平台管理系统中定义的，故障域会运作在云基础架构的整体架构上，而WSFC则是反其道而行之，在群集的级别上面定义Site，Rack，Chassis，这样不论是Site，Rack，Chassis都需要在群集的框架内运行，这也是微软的架构和其它厂商不同之处。

其中老王认为，对于故障域站点感知，WSFC做的还算不错，我们定义了站点故障域，把节点放入站点故障域下面后能够实现

站点感知：设置好了站点后，我们可以让群集节点每次故障转移或维护模式，都先在站点内进行角色转移，如果本站点无正常节点可转移，再转移至其它站点，在以前的版本中是没有这项技术的，以前版本中如果我们希望实现类似的需求，是通过设置应用的首选所有者来实现，2016则把站点感知带到群集中

存储站点感知：群集中的虚拟机，将会follow同站点内的CSV，假设CSV迁移到其它站点，一分钟后，虚拟机发现，CSV迁移到其它站点，那么虚拟机也会实时迁移过去，配置站点感知后，会确认首选站点始终直接访问存储，如果存储移动，则虚拟机也跟随移动。

群集组站点感知：我们也可以配置应用的站点感知，例如设置SQL实例1的首选站点为beijing，SQL实例2的首选站点为shanghai，这样可以实现一种多主运行应用的场景，让SQL1故障转移首先在beijing站点内，SQL2故障转移首先在shanghai站点内。

首选站点：配置了站点感知之后，我们首先要选择出首选站点，首选站点可以确保，当群集出现50/50投票时，动态仲裁始终去掉非首选站点的投票，让首选站点运作，没错，这替代LowerQuorumPriorityNodeID，在群集冷启动时，虚拟机也会优先在首选站点启动

它们的优先级顺序如下

存储站点感知>群集组站点感知>首选站点感知

除了这些信息外，站点感知功能随之增加了新的跨站点心跳检测机制，我们将在下一篇博客中进行介绍

OK，下面开始实验验证

清空所有故障域配置

实验环境

群集当前基于CSV跑了一台虚拟机，两个dtc，都运作在北京站点HV01

故障域配置如下

实现验证站点感知，在未配置首选所有者情况下，三个群集应用运作于HV01，归属于同一站点故障域beijing

手动停止节点HV01群集服务，应用自动首先迁移至同站点内HV02

打开clusterlog查看

这里我们虽然成功了，但是也有一定几率的情况下，我们达不到这样的效果，在2016中，当我们构建了站点故障域后，群集再次进行故障转移时，传统群集角色会直接在本站点内向尝试进行故障转移，而基于CSV的虚拟机则并不一定，原因是CSV是可以漂移的，可能现在CSV主控制点在HV04，但是虚拟机在HV01，这也是可以跑的

如果CSV的主控节点和虚拟机就在同一个节点，那么当节点宕机时，有可能CSV会去其它站点，假设CSV去了其它站点的节点，那么虚拟机也会跟着follow过去

如果CSV的主控节点和HV01不在一个Site，那么当HV01故障转移时，虚拟机会follow CSV所在的site，CSV在哪，虚拟机就去哪，确保虚拟机可以获得最好的性能，而忽略站点内感知的功能，因此存储感知的优先级也最高

如果虚拟机当前是开机状态，则每个一分钟会检测，我和CSV是否在同一个Site，如果不在同一个Site，我要实时迁移过去，如果虚拟机时关机状态则不会检测，但是故障转移或维护时，会先去找CSV所在站点，在群集日志中可以看到

接下来就要进入另外的一项技术，即首选站点功能，首选站点配置级别，可以是在群集级别，存储级别，群集组级别，这里我们首先要配置的就是存储级别，我们手动来规定确保CSV和站点的粘性，例如CSV01 始终follow 北京站点，CSV02始终follow上海站点

这样北京站点的虚拟机始终就找北京站点的CSV01，CSV01也始终会在北京站点，虚拟机故障转移或维护也始终会先在北京站点，因为CSV已经被固定，如果CSV出现维护操作或失败操作也可以第一时间回到北京站点，配置在同一个站点的CSV会在节点内执行负载分布

#获取CSV的群集组名称

Get-ClusterSharedVolume | Get-ClusterGroup

CSV也是群集组 Really？

#基于获取到的CSV群集组名称，配置到首选站点

（Get-ClusterGroup -name CSVClusterGroupName）.PreferredSite =“beijing”

OK，现在我们就可以放心了，虚拟机会始终follow CSV，CSV也始终follow 本地站点，这样确保了虚拟机发生故障，在本地站点有可用节点，一定会先迁移到本地站点。

下面我们再配置群集级别的首选站点，配置群集级别首选站点的目的无非是发生50 50分时让群集始终确保首选站点可以获胜。

#查看群集当前节点投票与见证投票

直接禁用仲裁磁盘，模拟群集仲裁失效，50 50分成情况下，动态仲裁自动选择一个节点去掉投票数

可以看到默认情况下，群集自动去掉了上海站点的投票

我们如果手动指定首先站点，例如，我们手动指定上海为首选站点，那么当下次再发生五五分成的时候，动态仲裁将始终去掉北京站点节点的投票

ClusterLog

存储见证在的时候完整投票数

见证失效的临时投票数，随后立刻会被动态仲裁随机去掉投票

默认下动态仲裁去掉HV03投票

手动修改后去掉HV01投票

以上为首选站点在群集级别配置后的效果之一，看起来2012R2 LowerQuorumPriorityNodeID并没太大差别

#配置群集级别首选站点回到北京

(Get-Cluster).PreferredSite = Beijing

看过了存储级别的站点感知，以及首选站点替代LowerQuorumPriorityNodeID的新功能，最后我们来看下主菜，即应用程序的多主站点感知

在看应用程序多主站点感知，老王还是想为大家看下群集级别站点感知的效果，当前我们已经配置了存储站点感知，因此可以发挥出完整的效果

时间节点1

所有应用和虚拟机运行于北京站点HV01

手动停止HV01群集服务，CSV迁移同站点其它节点，所有角色迁移同站点内其它节点

再次停止HV02群集服务，失去整个Beijing站点，所有应用跨站点故障域迁移到Shanghai

至此就是故障域站点感知的效果了，对于了解故障域概念，但是不了解微软WSFC的人来说，这可能很炫，应用感知到故障域，并且优先在故障域内转移，同一站点故障域内虚拟机可以获得存储最好的性能，如果同级别站点故障域不可用，可以跨故障域转移至新故障域站点继续运行，看起来很不错，但是内行看门道，其实呢，只不过是包上来一层新的概念，我们通过原来的首选所有者技术也可以实现类似的效果，只不过通过新的方式配置，看起来更加专业些，便于故障域概念的落地。

相对于站点感知功能，老王更看重的是另一大块，即首选站点感知，首先站点感知里面包括群集级别，老王更看重存储级别的首选站点感知，可以和站点感知功能融合，确保同站点内虚拟机始终访问同站点的存储，让CSV存储和虚拟机始终在同一个站点，同站点始终获取最好的性能，这是以前版本没有的

梳理下WSFC 2016针对于故障域新增的新功能

1.故障域定义：全新，支持站点感知，SDS感知

2.站点感知：代替首选所有者

3.首选站点感知：替代LowerQuorumPriorityNodeID

4.应用多主首选站点感知：代替首选所有者

5.CSV存储首选站点感知：存储follow站点，VMfollow存储

6.新增跨站点心跳检测参数

作为微软本地端产品首次尝试引入故障域属性，老王认为微软做的已经还可以，期望未来可以不断完善，在老王看来，故障域其实可以更上一个级别，例如我们可以在SCVMM的级别定义故障域，从站点，数据中心，机架，机箱，群集，Host，这样从上向下做的话也许会更好，因为现阶段从下向上定义，毕竟群集的规模受限，如果是在VMM级别，则我们不必受限于单个群集的规模，甚至可以针对站点，或机架，机箱，数据中心，配置不同的故障转移策略，网络策略，存储策略，那样就更好了，希望这项功能能够得到不断的完善，越来越多的本地端产品，或群集上层应用可以更好的和故障域协同。

最后，应用多主首选站点感知，我们可以配置在群集组的级别，配置不同的群集组选择不同的首选站点，这样不同的群集组就都会在各自的首选站点中先执行故障转移，如果首选站点无可用节点，再转移至其它站点，这样在一定程度上，可以减少跨站点转移的成本，确保每个站点的资源都得到合理的利用，不会本站点还有节点就转移到跨站点，一定程度上可以减少宕机时间，提高应用运行的时间。

#配置多主站点感知

对于devtestdtc首选站点为beijing

对于MikeWang首选站点为beijing

(Get-ClusterGroup -Name devtestdtc).PreferredSite = Beijing

(Get-ClusterGroup -Name MikeWang).PreferredSite = Beijing