WSFC2016 站点感知与健康服务

以前老王曾经写过一篇文章简单探讨过WSFC 2016的故障域以及站点感知功能，可是随着继续深刻的应用和使用，老王发现站点感知这个概念在WSFC 2016体系里面贯穿到了不少功能，所以决定再写一篇，主要与你们探讨在ReallyWorld中应该如何思考站点感知，故障域，以及WSFC 2016健康服务功能

# 1. 初谈WSFC 2016故障域

故障域一般来讲，只有当咱们做为交付SLA，或享用SLA的时候会听到这个概念，例如，当咱们购买了某云厂商的云服务，它们会保证不少个9，但前提是咱们要把云服务里面的多个应用虚拟机放在不一样的故障域，对于使用者来讲，一般状况下云厂商会告诉你，放在不一样的故障域，您的虚拟机就会被放在不一样的机架，永远不会被一块儿维护，一块儿出现故障的概率很低等等。

若是做为交付方，咱们则须要在后台设定故障域这套policy，故障域不是一项固定的技术，它应该是一个规范，引入故障域规范后，管理员就应该知道，不该该同时对一个用户全部故障域的机器一同作维护，技术层面会经过群集系统或VIM系统确保不一样故障域资源 始终被放在不一样机架或机柜上，实现到这一步才算是逻辑定义+物理实现，至于物理能不能实现，仍是取决于基础架构对于故障域的感知，WSFC2016中支持逻辑定义Chassis，rack，site三种故障域级别。

目前可以真正实现故障域感知的只有S2D功能，S2D一旦感知到WSFC配置了Chassis或rack故障域级别，会始终确保extent多个副本撒到不一样Chassis或rack

# 2.再谈站点感知与故障域

站点感知的主要做用老王认为有七

1. 故障转移规则：当配置站点感知后，应用会首先尝试在同一站点的节点进行故障转移，反相关性和可用全部者配置会盖过站点感知
   

2. 排水维护规则：应用会首先尝试在同一站点的节点进行排水，反相关性和可用全部者配置会盖过站点感知

3. 站点特定心跳：只有为群集配置了站点感知功能后，咱们才能够配置站点心跳检测频率

4. 站点票数修剪：配置了站点感知功能后，咱们能够配置首选站点功能，被选中首选站点的节点在50/50中会获胜，非首选站点自动去掉一票

5. 层次首选站点：能够配置群集级别首选站点，实现非首选站点票数修剪，也能够配置群集组级别首选站点，实现多主首选

6. 存储站点亲和：配置站点感知后，默认状况下虚拟机会寻找CSV所在的站点，站点感知逻辑认为虚拟机和CSV在同一站点帮助提升效率，经过配置存储首选站点能够始终确保虚拟机和CSV位于同站点，若是虚拟机发现当前和CSV不在同一站点，将在一分钟后移至

7. 延伸群集配置：当咱们配置延伸群集时，实际上一个延伸群集是两块，一块是群集上面的应用，一块是通过复制自动故障转移的存储，虽然存储能够作到自动跨站点故障转移，可是延伸群集存储复制是不考虑多站点问题的，它不懂，只知道复制磁盘内容到指定节点，以及和群集联动，可是咱们须要为应用考虑多站点故障转移的问题，默认状况下应用会转移至全部可用节点，可能虚拟机会转移到远程站点，可是实际上这时候提供存储的仍是主站点，这时主站点访问效率就会下降，所以延伸群集最佳实践仍是配合上站点感知功能，实现底层的存储故障转移，也实现应用最佳可用性，实现应用默认在本地故障转移，默认始终和本地存储在一块儿

   
   

当咱们思考一个跨站点的群集架构时，除了网络，存储，仲裁那些该考虑的点，另一点须要考虑的就是群集的放置策略，不少时候若是忽略了群集放置策略就会致使额外的停机时间，若是利用好了群集放置策略又能解决不少复杂问题

站点感知，说穿了，老王认为它和S2D故障域感知是两回事，站点故障感知实现的是在群集中定义出站点架构，让故障转移，排水，心跳，仲裁执行时能够多出来一个参考项目，将咱们脑壳里面的多站点架构经过软件定义出来显示，而且让群集组件参照它去进行工做。

站点感知定义是WSFC2016实现出来的方法，其中有的功能咱们在之前的旧版本也能够实现，例如应用首先在本地站点故障转移，之前咱们是定义首选全部者，站点票数修建，之前咱们是定义LowerQuorumPriorityNodeID，WSFC 2016站点故障感知的新方法与以往不一样的是，把这些群集里面不一样的功能，经过一个站点感知功能给串了起来，这是它的厉害之处，同时站点感知支持经过PS批量配置，管理起来比2016以前旧方案方便，总之，你们须要慢慢的去接受这个概念，并试着应用它，让多站点群集架构更加完善。

# 3.终谈故障域与健康服务

经过总结，老王认为在WSFC2016中，故障域的定义，主要有三层用途

1.配合S2D这等应用实现故障域感知 (我但愿将来能够有愈来愈多像S2D这样能够实现故障域感知的应用)

2.配合WSFC实现站点感知，以此控制站点内站点间，故障转移，排水维护，心跳检测，仲裁执行

3.配合健康服务实现定位排错

当咱们在powershell里面建立的一个个故障域，其实就是一个个逻辑定义文本，若是没有S2D,WSFC这些可以感知到它们的组件，它们就只是一个普通的Text，不会起到做用，只有有可以感知到它们的组件，定义的故障域级别才能物理实现做用

理清这个概念后咱们再来看下健康服务功能，以前老王讲WSFC 2016系列的时候把它漏掉了，特意补上

基本上你们能够把它理解为一个WSFC自身的监控功能，经过健康服务能够帮助咱们关注某一个群集应用，群集组件的性能收集，工做状态，对它不一样层级的运行状态进行事件报告。

目前健康服务还只能for S2D，当咱们在群集中启用S2D后，默认就开启了健康服务功能，健康服务会平常监控S2D的运做，收集它的性能报告，不一样于通常的事件日志，老王认为健康服务所收集的日志，显示出来很是友好实在，管理员一目了然。

例如这些

当咱们须要使用健康服务 监视S2D时，输入如下命令便可

Get-StorageSubSystem *Cluster* | Debug-StorageSubSystem

参数字段

• 严重性

• 问题实用描述

• 推荐解决问题下一个步骤

• 它的物理位置 若是有定义故障域，按照嵌套关系显示出来当前故障警报在那个站点下的那个机架上的那个机柜那台服务器

• 资源的说明，若是有定义故障域，也将按照嵌套关系显示
  

区别于通常的监控软件，老王为何说它友好呢，是由于它的错误显示的很明确，能够直接告诉你网线掉了，那块网卡，那个服务器失去链接了，或是那块磁盘掉了

如图所示，有一个关键级别的日志，提示hv01失联，下面location和description按照嵌套关系自动显示出所在位置或地址

Get-StorageSubSystem *Cluster* | Debug-StorageSubSystem这条命令仅在群集开启S2D后才能够运行

默认状况下此命令的执行显示的是会影响到S2D群集总体运做的日志，这些故障大多数和硬件或配置有关

也能够运行

Get-Volume -FileSystemLabel <Label> | Debug-Volume  

Get-FileShare -Name <Name> | Debug-FileShare  

这将返回 仅影响到指定文件共享或卷层级的故障日志，这些故障一般和容量规划或复原功能配置有关

健康服务除了监控故障日志，另一个点是性能收集，收集S2D运做过程当中一些实用的性能参数，如CPU利用率，IOP，容量。

执行命令Get-StorageSubSystem *Cluster* | Get-StorageHealthReport显示S2D总体性能报告

显示指定秒间隔内的S2D性能报告

Get-StorageSubSystem Cluster* | Get-StorageHealthReport -Count <Count>  

显示S2D某一共享或卷的性能报告

Get-Volume -FileSystemLabel <Label> | Get-StorageHealthReport -Count <Count>  

Get-StorageNode -Name <Name> | Get-StorageHealthReport -Count <Count>

另一项功能，健康服务功能也能够用于监控S2D运做过程当中正在执行的重要做业

Get-StorageHealthAction  

若是当前S2D正在执行如下操做，将显示

即将失败的、 失去链接或无响应物理磁盘

当前存储池正在更换物理磁盘

还原完整复原数据

从新平衡存储池

基本上健康服务目前主要实现这三项功能，微软但愿经过健康服务功能帮助群集管理员提升监控运维效率，采用实用的监控日志和性能指标，监控日志能够和故障域功能相整合，当发生错误时能够自动嵌套故障域关系，帮助管理员定位问题位置，目前该功能仅限用于S2D，老王但愿将来愈来愈多的群集功能能够支持监控服务。

本文老王主要和你们探讨了下概念，如须要实做，请参考老王另一篇博客 WSFC2016 故障域站点感知