WSFC2016 故障域站点感知

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

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

   以CloudStack为例，在CloudStack中，针对于资源架构，咱们能够手动来定义架构模型，从最上层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.新增跨站点心跳检测参数

  故障域和站点感知支持WSFC传统同域部署，工做组部署与同林多域部署

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

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

#配置多主站点感知

对于devtestdtc首选站点为beijing

对于MikeWang首选站点为beijing

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

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

对于devtest1dtc首选站点为shanghai

(Get-ClusterGroup -Name devtestdtc1).PreferredSite = Shanghai

当前devtestdtc Mikewang在HV01运行，devtestdtc1在HV04运行

停机HV01，devtestdtc Mikewang转移至北京同站点HV02

停机HV04，devtestdtc转移至上海同站点HV03

针对于站点感知或应用多主首选站点感知，建议配置应用的故障回复属性，这样当检测到首选站点，或本地站点可用时，会回到原来站点运行