WSFC日志分析进阶篇

  在群集日志分析基础篇中，老王为你们介绍了几种群集日志的位置和用途，例如事件管理器系统日志中能够告诉咱们，当群集出现故障时，大致是什么缘由致使的，给出一个方向，应用程序日志里面的FailoverClustering - Manager -Diagnostic日志能够帮助咱们在事件发生后回溯执行过那些操做，FailoverClustering - Operational日志能够帮助咱们了解群集资源，网络检测，安全的基本变化状况是否正常，还有群集管理器中的汇总日志，这些日志，一般状况下能够为咱们指出一些明确的方向，告诉咱们应该去看什么的问题，能够看见一些基本的资源变化信息和操做记录，帮助咱们回溯一部分问题。

   可是在一些状况下，可能出现的问题，在这些日志中并无给出明确的解释，或者咱们认为可能并非事件日志里面所说的问题，咱们仍须要更加详细的信息，这时候咱们就能够去看群集诊断日志，什么是群集诊断日志，简单来讲，群集诊断就是记录群集运行过程当中的全部内部执行过程，你能想到的，资源上线下线迁移，运行情况检测，等等，几乎全部和群集运行有关的东西都会被记录在这个诊断日志中，2012时×××始默认状况能够在事件管理中看到，群集一边运行着，这个事件日志就会不断的更新增加

  

  诊断日志和其它日志最大的不一样就是，其它的群集相关日志也会记录群集的运行情况，资源变化，可是呈如今事件日志中都相对友好一些，基本上不会出现不少底层的语言，让咱们看到基本上就能够看懂，而诊断日志则不一样，在诊断日志中，会把群集中的一些核心组件也呈现出来，例如RHS,RCM,NetFT等核心组件的运做也会呈现出来，所以诊断日志也最为深刻和详细，不管是对于群集作深刻的排错，仍是但愿了解群集内部的运做原理，学会看诊断日志是最佳的选择。

  在看诊断日志的时候，您可能会看到里面有不少群集核心组件的缩写，例以下图这些，初学者若是看不懂缩写的意思，能够复制下来，去网上搜索，而后记下来，这里老王挑选三个我认为比较主要的核心组件来和你们解释

RHS：中文 资源主机子系统，实际运做时会呈现成一个个的系统进程，这个组件干吗的呢，它会根据Resource.dll里面定义的检测规则，以及咱们定义的检测策略，去实时监控各类群集对象的运行情况，例如群集磁盘，群集IP地址，群集网络名称，应用程序，RHS实际检测的时候主要是依据当前已经加载的群集资源对象Resource.dll中两个参数来判断群集资源的存活与否状态，分别是looksalive check，is alive check

顾名思义looksalive check就是说，资源看起来是活着的，所以，在looksalive check过程当中，一般状况下RHS会执行相对来讲简单的检测操做，例如每隔3秒检测群集磁盘是否接受预留请求请求。若是经过looksalive check并不能有效的检测出资源是否存活，RHS还会尝试使用is alive check的方式进行具体的检测，相比较looksalive来讲is alive则会从更加深刻的角度去检测资源的存活状态，例如，is alive对于群集磁盘的检测会实际要求执行一个Dir命令，针对于SQL的检测，会实际执行一个查询来确认SQL群集资源的存活，所以lookalive的检测一般是基本化的，is alive检测一般是完全的深刻的，若是is alive的检测也失败，则RHS会报告资源的状态为失败，而后反馈给RCM组件进行进一步的资源处理

RHS，不管是对于任何的一个群集资源都会去尝试执行looksalive check，is alive check的检测操做，可是针对于不一样的群集资源对象，检测的方法都会不一样，针对于一部分群集默认资源，例如群集IP，群集资源，群集网络名称，RHS会经过加载默认的ClusRes.DLL去进行检测，不一样的群集对象可能会用到不一样的Resource.dll，开发人员能够把本身的程序与WSFC集成，编写本身程序的Resouce.dll融入到群集中

一般状况下，Resource.dll会起到如下两个主要做用，一个起到应用程序与群集之间的代理做用，当咱们在故障群集管理器上面针对于群集对象联机，脱机，启用，禁用等操做时，实际上要求会直接发给资源对应的Resource.dll，再由Resource.dll去通知资源进行状态变化，所以若是要本身编写Resource.dll，首先要确保dll能够对相应的资源对象可以执行管理操做感知

另外Resource.dll还应该明肯定义出，针对于特定资源类型的looksalive check和is alive check的检测方法，当is alive检测失败时候应该返回False参数，RHS收到False参数后会把资源标记为ClusterResourceFailed状态

RHS检测系统会根据全部的定义在群集中的Resource.dll里面的looksalive check和is alive check规则去检测群集资源的存活，一般状况下，若是要把自定义开发的应用与群集化，建议仍是编写好Resource.dll，这样群集能够进行更加深刻的检测，不然只能经过默认ClusRes.DLL去检测应用进程的基本情况

例如微软的SQL和Hyper-V群集化了以后，RHS都会经过它们自身单独的Resource.dll规则去进行检测，SQL Server群集化了以后会在群集中产生特定的SQL服务资源对象，同时也有自身特定的检测方式，RHS能够实际上发出一个真实的查询去is alive检测SQL的存活，Hyper-V群集化了以后也会调用自身特定的Resource.dll，实现能够经过咱们定义的高级策略来检测来宾OS是否蓝屏，来宾OS里面的服务是否存活等等，当根据咱们定义的检测策略和is alive检测，检测到资源当前不存活，过阵子会在RHS中标记资源为失败状态并报告给RCM，而后RCM看到RHS的标记则会根据资源的故障转移策略对资源尝试执行故障转移，重启启动等操做。

在以前2003时代，群集里面全部资源都在一个RHS进程下面托管着，这样子若是当一个资源对象由于检测失败，也会致使其它群集资源一块儿出现崩溃或重启的状况，所以在2008时×××始，微软将一部分群集自身的资源对象，例如，群集IP，群集名称，群集磁盘等能够被群集共享的资源放在一个单独的RHS进程中，咱们在群集中建立的群集应用能够在单独的RHS进程中工做，这样一旦单个群集应用的RHS检测失败或进程出现问题，并不会影响到群集其它资源的工做，能够经过 cluster . res  /prop命令来查看群集资源的全部属性

其中几个和RHS有关的关键参数

MonitorProcessID： 群集资源关联的RHS进程ID，能够经过查看这个参数来判断分析那些群集资源当前处在同一进程中

SeparateMonitor：  指示资源是否已被放置在单独的监视器中（0：否，1：是）

IsAlivePoleInterval：  默认值如图所示，表示它正在使用该特定资源类型的默认设置。

LooksAlivePollInterval：  默认值如图所示，表示它正在使用该特定资源类型的默认设置。

DeadlockTimeout：  资源死锁响应等待时间，默认为五分钟。

2008R2时×××始群集资源已经不是都在同一个RHS进程下面运做，针对于关键群集资源和群集应用实际上已经分开了不一样的进程，来避免由于单个群集应用崩溃而致使其它群集资源崩溃的状况，可是默认状况下大部分群集资源仍在一个共享配置的监视器中运做，当RHS检测到一个群集资源失败或dll崩溃，则会把它放置在一个独立监视器中进行检测，完全防止它影响到其它群集资源，在针对群集进行resource.dll的调试时，你也须要把SeparateMonitor值设置为1，不然会由于调试可能时会让共享监视器中其它资源失败。

#设置群集资源在单独的监视器中工做

(Get-ClusterResource “Resource Name”).SeparateMonitor = 1

例如在2008R2时代的虚拟化群集场景，默认状况下全部虚拟机都在同一个共享监视器下运行，一旦发生单个虚拟机发生资源死锁状况，可能会致使上面全部虚拟机都没法使用，所以能够把出现问题的虚拟机单独放在隔离监视器中运行，在实际使用中，对于隔离监视器的使用须要谨慎，由于有时候启用单独的隔离监视器就会出现单独的RHS进程，每一个进程都要占用CPU和内存资源，所以须要在考虑服务器资源的状况下启用该高级功能。

RCM：Resource Control Manager ，资源控制管理器，顾名思义，这个组件是帮助咱们去管理群集资源的，小到群集磁盘，大到一个群集组，都是经过RCM来帮助咱们进行操做管理，能够说，RHS的功能主要是进行检测，发生问题，而后报告问题，而RCM则是实际作处理的，它会根据咱们对于群集的操做指令，或者RHS检测到的结果，来进行资源的上线，离线，挂起尝试，故障切换等操做

RCM在执行操做的时候会考虑两点，一点是依赖关系，例如咱们要联机上线一个群集组，群集组依赖于群集网络名称，网络名称又依赖于网络IP，所以RCM在处理咱们这个联机请求的时候，会先去尝试构建出依赖关系，而后按照依赖关系逻辑逐步完成资源的联机，例如会先去尝试联机网络IP，网络IP联机以后尝试联机网络名称，最终依赖的资源都已经联机成果，才联机整个群集组。

另一点，当RCM执行操做的时候，默认状况会使用资源定义的故障策略，以及高级策略来进行评估，最终作出合适的操做，例如，当RHS报告群集资源失败，RCM会按照故障转移策略每隔一段时间尝试联机挂起，通过一段时间没法挂起，会把资源置为失败状态，一段时间依然尝试重启启动该资源，若是始终没法重现启动成功，还会尝试把资源移动至其它节点进行尝试，若是都没法成功，会把资源置为失败状态。

由此能够看出，RCM组件主要的做用就是用于执行群集资源的管理操做，以及当群集资源，群集组出现故障时，评估依赖关系，故障策略，高级策略来对资源进行尝试，故障转移，状态确认。

NetFT：NetFT一般指的是Failover Cluster Virtual Adapter，当咱们安装群集以后，在设备管理器里面显示隐藏设备能够看到有这样一个虚拟网络适配器，用ipconfig /all也能够看到这块网卡，可是并无配置IP地址，这个群集虚拟网络适配器的主要做用是帮助咱们构建一个群集中网络通讯的高可用拓扑，例如，咱们群集节点与节点之间要进行心跳检测，每隔一段时间，NetFT就会去帮咱们从新构建这个拓扑，例如节点1和节点2，分别有两块网卡，一块专用于群集网络，一块用于群集网络+管理网络，那么当NetFT检测到若是专用的群集网络不能执行心跳检测，就会动态切换至另一块网卡帮助咱们进行心跳检测，NetFT的功能主要就是帮助管理员自动构建群集先有的通讯拓扑，在最大程度的帮咱们确保群集网络均可以正常的通讯。

介绍了几个重要的理论后，咱们来实际看下群集的诊断日志，到底长什么样子呢，默认状况下在2012时代诊断日志能够在事件管理器中看到，可是因为是实时增加的，看起来不太直观，咱们很难在里面快速找到本身想要的信息，因此除了事件管理器，咱们也能够经过Powershell命令Get-ClusterLog来生成群集的诊断日志，和事件管理器中的诊断日志不一样，当咱们使用Get-Clusterlog获取诊断群集日志时，不管是2008仍是2012，都会把事件管理器，或ETL文件里面的诊断日志合并，而后筛检一部分，去掉无用的信息，只保留下来真正有用的诊断信息，造成一个log文件，便于管理员分析。

默认状况下若是咱们直接在powershell中执行 Get-CluserLog就能够输出群集的诊断日志，打开以后就能够看到，可是，默认状况下2012R2里面诊断日志最大是300MB，一旦超过这个大小，则当日志再出现时，会覆盖掉以前日志，2008时代是100MB的限制

若是直接执行Get-ClusterLog，将会输出从群集开始到如今全部的Log，假设你的群集日志没有达到过300MB，没有发生过覆盖，会生成出全部的log，可是有时候生成这么大的日志会花费一些时间，并且Get-ClusterLog这条命令一旦执行下去，不仅仅是生成当前节点的诊断日志，也会去让其它节点也生成cluster.log到report目录，所以，使用Get-ClusterLog时有一些参数能够配合使用

#日志很少，能够直接运行Get-ClusterLog，会输出从集群创建到如今全部的

Get-ClusterLog

#只但愿输出最后五分钟的日志

Get-Clusterlog -TimeSpan 5

#只但愿指定的节点生成日志

Get-Clusterlog -Node Nodename

#若是在不指定路径的状况下，每次生成都会覆盖Report目录下已有的log，但愿把各个节点的日志统一辈子成到一个目录下，可用利用Destination参数，在目录中会看到带有节点名字的各个log

Get-Clusterlog -Destination path

默认状况下cluster log的日志级别为3，一般状况下Level 3已经足够详细，若是在进行一些诊断的时候，你也能够经过 Set-ClusterLog -Level 5 设置级别为5进行高级诊断,须要注意若是设置Level 5 会致使短期内日志持续飞速增加，建议诊断完成后及时恢复3

下面咱们实际生成一下来看

生成完成的clusterlog默认会存在各节点的Report路径下

打开以后界面以下

这时候你可能须要一个本身用的习惯的日志分析用具

能够看到clusterlog彷佛与咱们其余地方看到的log不太同样，到底应该如何去理解呢，咱们以一个例子来看

进程ID：资源所在的16位RHS进程ID

线程ID：资源16位RHS线程ID

GMT时间：事件发生时的GMT时间，精确至毫秒级别，最初考虑到群集节点可能会是分布在不一样的时区，因此使用了GMT，实际看的时候，东半球须要加上8小时，在2016群集中新增了UseLocalTime 参数，生成clusterlog的时候，若是咱们确认节点都在同一时区可使用UseLocalTime生成本地时间戳记

日志级别：一般有INFO，ERR , WARN，DBG等状态，其中能够在日志分析中跟踪ERR关键字

资源类别：是有那个类别的资源类型和群集组件产生的日志

资源名称：具体的资源名称

说明：对于日志的详细描述

在Cluster.Log中有一些关键的属性，你们在使用Cluster.Log的时候能够主要关注下，而且设置在分析工具中追踪

OnlinePending：资源联机挂起

OfflinePending：资源正在进行脱机

Offline：资源脱机

ProcessingFailure：资源失败

Failed：群集组失败

经过直接在日志分析工具中搜索相应的关键字，就能够看到附近发生的上下文过程

下面咱们以几个实际的案例来看

NetFT组件尝试帮助咱们构建群集网络通讯拓扑，能够看到这里详细的运做过程，发现只会在18网段，10，20网段之间进行尝试创建3343链接，由于咱们设置了30 40网段为存储网络，不参与群集通讯，所以构建拓扑时NetFT不会考虑这两个网络

08R2群集因为当前只有一个节点在运行，群集存储以前一直是失败状态，17:10这个时间节点，我将群集存储恢复联机上线，17:11时间节点，禁用ISCSI目标

生成clusterlog能够看到，10分的时候，RHS继续尝试检测群集磁盘1，发现群集资源1的RES资源已经正常挂载，检测也正常经过，所以RHS将把群集磁盘1状态变成联机的状况报告给RCM，RCM变动群集磁盘状态为联机

11分的时候RHS针对于群集磁盘1的Is Alive检测失败，断定该资源失败，并将失败的状态报告给RCM，RCM变动群集磁盘状态为失败，紧接着RCM会按照故障策略对群集磁盘尝试进行挂起重试操做，在一段时间内一直获得失败的结果，会标记群集磁盘为失败状态，而后隔一段时间后再尝试联机或迁移至其它节点。

第三个实例咱们查看当咱们执行LowerQuorumPriorityNodeID时群集内部发生的动做

时间节点1，群集四个节点，见证磁盘失效，当前群集随机调整去掉一个节点投票

时间节点2 ，使用LowerQuorumPriorityNodeID设置去掉HV04节点的投票

#使用命令输出全部群集节点最后五分钟的目录至统一文件夹

Get-ClusterLog -Destination \\iscsi\clusterlog -TimeSpan 5

打开HV03的日志能够看到，时间节点1，当检测到群集磁盘离线时，仲裁首先挑选去掉节点1的投票，时间节点2咱们手动设置LowerQuorumPriorityNodeID为HV04，群集从新调整动态仲裁，去掉HV04的投票

第四个实例，咱们能够看到，当NetFT构建群集内网络通讯拓扑时，会考虑到网络会子网内仍是跨子网，能够根据状况设计不一样网络环境下的运行情况检测频率，NetFT会按照咱们的定义来构建不一样网络环境运做情况检测的拓扑。

最后一个实例，咱们来模拟下当群集四个节点，坏掉三个节点，且最后两个节点时，投票节点突然被断电，强制启动群集后的阻止仲裁状况

如今群集只剩下HV01节点被强制启动，咱们这时启动下HV04节点

获取群集诊断日志，咱们就看最近20分钟左右的，看看从群集关闭，强制仲裁，再到阻止仲裁到底发生了什么

Get-ClusterLog -Node HV01,HV04 -Destination \\iscsi\clusterlog -TimeSpan 20

咱们先看HV01的日志

能够看到，时间节点一，HV01强制启动了群集服务

紧接着初始化各个群集组件，仲裁组件断定HV01已经初始化完毕，提高HV01的paxos标记为权威，这时应标记为FixQuorum状态，能够看到，虽然不在UI显示了，可是在后台运做的时候仍然会指出当前节点正在强制模式下运行

这时HV04试图上线，但会被阻止，HV01会收到群集环境内有新的加入请求，并告诉我它我是权威的节点，个人paxos标记最高，你应该以个人为准，加入个人分区，同步个人群集数据库

这时咱们再来看看HV04的日志，由于HV04的ID为3，所以在日志中会看到Node 3 也就是HV04

时间节点1，Node3 尝试启动群集服务，可是启动以后被终止，

时间节点2 Node3指出，个人仲裁状态属于阻止状态，我试图加入，我应该先去和那个权威节点同步

时间节点3 Node3收到HV01的响应，以HV01为群集的权威方，按照HV01的paxos标记更新数据库

时间节点4  Node 3已经将群集数据库和HV01保持一致，再次加入群集，正常加入，关闭阻止仲裁模式，而且去掉了NeedsPrevent标记！

  以上老王经过几个简单的实例，来为你们讲解了下应该如何去看cluster log，把鱼竿的用法和基本技巧告诉了你们，若是但愿可以掌握分析技术还须要不断的看log练习才能够，在cluster log里面会真正涉及到不少群集底层组件的详细运做过程，若是你可以把这些底层组件的工做原理都搞清楚，老王相信不管是对于你进行排错，或者学习都会有一个不同的境界。

  在实际的群集排错中呢，老王认为主要仍是经过不断的学习，实验，实战来巩固本身的知识经验，排错时手段占一部分，可是自身的知识和经验积累也要占很大一部分，例如老王遇到群集的问题，个人思路一般是先获取下群集节点投票，见证投票，看看见证资格当前是怎么样的，接着我会去看系统事件中筛选群集部分，看看网络和存储是否有报错，而后跟着本身的经验去分析判断问题

  其实老王感受对于通常的排错，事件管理器系统，应用程序日志中旳群集日志已经能够提供足够明确的信息，事实上微软在2008时代改变群集事件的时候就曾经有个愿景，但愿可让更多的管理员经过看事件管理器就能了解解决一部分问题，到了2012时代事件管理器中的日志确实也达到了微软的愿景，确实不少问题，日志已经提示的很明确

  可是一旦遇到一些问题，事件管理器中给出的提示没法解决，这时咱们仍须要直接看cluster log，来从群集的最底层去了解故障的完全缘由。

  若是是须要进行一个综合性的排错，例如综合排查三个节点的群集错误和虚拟化错误，这时候你能够选择查看群集管理器中的聚合群集事件，来进行一个综合性的排错

  若是是须要进行群集的健康检查，看看还有那些最佳实践没有执行，能够执行群集验证报告，群集验证报告也会提供不少有用，底层的信息。