群集节点监视
如果把群集资源比作鸡蛋，那么群集节点就好比装鸡蛋的篮子，篮子的完整性决定了鸡蛋的安全。首先，群集节点需要判断自身是否存活，因此群集节点之间会定期通过心跳信号来评估所有节点的健康状况。群集的可用性目标取决于所提供服务的需求，不同服务等级的应用对故障恢复时间和健康检测的严格程度要求各不相同。同样，高可用性服务对节点故障的检测和恢复速度要求更高，而低可用性服务对故障恢复时间的容忍度较大。因此，Windows Server群集初始设置了两种不同严格程度的默认检测策略：
严格监控（Aggressive Monitoring）：提供最快的检测和恢复策略，确保最高的可用性。群集对故障的容忍度较低，即使是短暂的故障也会避免，导致群集节点出现短暂网络故障时，群集会将该节点上的应用迁移到正常节点。宽松监控（Relaxed Monitoring）：提供相对宽松的检查策略，群集对故障的容忍度较高，允许短暂的群集节点故障。严格监控和宽松监控是相对的，可以通过两个具体参数来衡量，一个是心跳频率（Delay），另一个是心跳失败阈值（Threshold）。
心跳间隔（Delay）：定义节点之间发送心跳检测信号的时间间隔，单位为秒。心跳失败阈值（Threshold）：定义在群集采取恢复行动之前能够容忍的心跳失败次数，比如心跳检测失败一次，群集不会立即采取恢复措施，而是继续发送下一个心跳检测信号，直到达到设定次数。Windows Server不同版本的群集默认心跳频率和心跳失败阈值汇总如下：
SameSubnetDelay1 秒1 秒2 秒SameSubnetThreshold5 次心跳10 次心跳120 次心跳CrossSubnetDelay1 秒1 秒4 秒CrossSubnetThreshold5 次心跳20 次心跳120 次心跳CrossSiteDelayN/A1 秒4 秒CrossSiteThresholdN/A20 次心跳120 次心跳
可以使用命令PS C:>Get-Cluster |fl *Subnet*查询跨子网和相同子网的心跳间隔和尝试阈值，命令输出的结果的心跳间隔单位为毫秒，结果如下示例所示。
| PS C:> Get-Cluster |fl subnet ||——————————-|| CrossSubnetDealy | 1000 || CrossSubnetThreshold | 20 || PlumbAllCrossSubnetRoutes | 0 || SameSubnetDelay | 1000 || SameSubnetThreshold | 10 |
调整心跳检测
严格的检查手段适用于一些高服务等级要求的应用，这些群集通常在一个高速连接的子网内。由于Windows Server群集支持节点跨子网和站点部署，在群集节点相隔数公里且连接不稳定的子网里，可以考虑稍微宽松的设置。同样，随着服务器硬件冗余程度的提高和操作系统的成熟，服务器节点的可用性已经非常可靠，整体故障几率大大降低，在这种情况下可以根据实际情况将检测策略调整得宽松一些。
可以使用如下PowerShell命令调整相同子网的心跳间隔，如下示例所示，将心跳间隔时间调整为2秒：
| PS C:> (get-cluster).SameSubnetDelay=2000 |
使用如下PowerShell命令调整相同子网的心跳失败阈值，如下示例所示，将心跳失败阈值设置为20次：
| PS C:> (get-cluster).SameSubnetThreshold=20 |
群集资源监视
除了要保证装鸡蛋的篮子的完整和可靠性，鸡蛋自身也会因各种因素变坏。因此，群集除了要监视群集节点的健康状态，还需要监控构成群集及应用的资源健康状况。群集通常包含若干资源和资源组，群集运行并处理不同的资源，有时候群集资源发生故障，虽然可以通过群集事件进行分析，但对于深入的问题，必须通过分析DUMP日志这个“黑匣子”才能找到根本原因。如果对群集资源故障了解不够深入，解决起来会无从下手，但作为维护人员，需要为群集资源故障分析留一道门，这道门通往更加深入的资源监视通道，这道监视通道将帮助我们获取深入故障分析报告，将故障分析报告提交给微软，让微软帮助定位问题所在。那么群集是如何检测群集资源并向系统报告事件的呢？接下来我们将带着这个疑问介绍群集的资源管理系统以及工作方式。
资源主机子系统
群集资源主机子系统（Resources Host Subsystem-RHS）负责监视群集资源，一个群集化的应用是以资源组形式存在的。群集可以运行多个资源，这些资源同时被群集监视系统监控，群集监视系统除了RHS，还有资源控制管理器（Resource Control Manager，简称为RCM），RCM和RHS协调工作以完成群集资源的监视和操作，如图1所示。RHS和RCM都是群集服务的一部分，主要职责是监视群集资源的状态。
资源控制管理器
具体来说，RCM具有两个关键职责：一个是为群集服务执行故障转移机制和策略，另一个是建立和维护每个资源的依赖关系。以高可用文件服务器为例说明，群集文件服务器资源和磁盘以及访问名称、访问IP地址处于同一个资源组的依赖关系树，这个依赖关系树由RCM维护，如图2所示。RCM维持单个资源和资源组的在线、离线、失败、在线挂起、离线挂起等各种状态，并负责资源组的移动、故障转移的操作。
造点AI
夸克 · 造点AI
325 查看详情
资源监视器检测
为了保证群集应用正常工作，RHS时刻监视着资源情况并定期检查群集资源的健康状态。每个不同的资源的检查频率略有不同，检查频率由不同的群集资源DLL定义。RHS采用IsAlive和LooksAlive两个探测器进行周期性资源健康检测，LooksAlives检查比较粗糙，但检查频率较高，默认情况下每5秒钟进行一次检查，而IsAlive检查更为仔细，但检查频率较低，默认情况下每60秒检查一次。LooksAlives不停检查资源健康情况，一旦资源返回失败结果给LooksAlive，考虑到资源会出现“假死”状态，这时候，RHS会立即启用更全面的检查并调用IsAlive检查资源是否真正出现问题。
在检测到群集资源故障后，RHS便会等待资源响应，如果在既定时间内没有响应，则会按照策略执行恢复操作。由于RHS只能判断资源不响应但不能判断具体发生了什么故障，唯一的办法就是通过重启RHS进程尝试恢复资源。这个等待时间在群集资源的DeadLockTimeout属性里定义，等待一次为300000毫秒，也就是5分钟，可以使用PowerShell命令查看和修改DeadLockTimeout值。
使用以下PowerShell命令查看群集资源的RHS等待时间。下面以Hyper-V群集（配置了群集复制代理角色）为例，命令输出的结果如下。
| PS C:> Get-ClusterResource |ft Name, ResourceType, DeadlockTimeOut ||——————————————————————|| Name | ResourceType | DeadLockTimeout ||———————–|————————|—————–|| Cluster IP Address | IP Address | 300000 || Cluster Name | Network Name | 300000 || File Share Witness | File Share Witness | 300000 || Cluster-HRB | Network Name | 300000 || IP Address 192.168.1.5 | IP Address | 300000 || Hyper-V Replica Broker Cluster-HRB | Virtual Machine Replication Broker | 300000 |
要修改某个群集资源的DeadlockTimeout时间可以参考如下命令，这个命令修改类型为Network Name的DeadlockTimeout为10分钟。
| PS C:> (Get-ClusterResourceType “Network Name”).DeadlockTimeout = 1000000 |
虽然可以任意定义DeadlockTimeout时间，但不建议将这个值改成比5分钟更大，试想IsAlive和LookAlive检查时间往往在几百毫秒内完成，而DeadlockTimeout的时间为5分钟，已经大大超出了IsAlive和LookAlive检查时间。
除此以外，群集为了做到准确监控，默认启用了一层保护机制，当群集发送结束RHS指令时，不会立即重启RHS进程，而是等待4次DeadlockTimeout时间（20分钟），如果资源仍然没有响应才采取结束RHS进程的措施。如果RHS进程在等待4次（20分钟）资源仍未响应，群集判断服务器可能出现严重的问题，进而强制重启群集节点。
最重要的是，RHS产生Windows错误报告给群集系统并把错误写入DUMP文件，因为不同应用的群集涉及的群集资源也是千变万化的，一般出现严重的问题需要进一步的分析，笔者曾经遇到群集节点发生I/O Request Packet队列过多导致服务器使用Bugcheck自动重启的情况，最后通过分析DUMP发现了问题的根本原因，因此说，RHS打开了一扇通往深入分析群集的门。
资源监视器调整
群集将资源DLL加载到资源主机监控进程（RHS.exe），RHS进程是循环使用的。早期的设计里，默认情况下所有的资源在一个RHS进程里运行，这种情况的问题是如果一个资源故障，那么整个RHS进程和所有由这个RHS加载的资源都会出现故障。考虑到这种设计的不足，在后期Windows Server群集里做了改良，重要的资源都加载到各自独立的RHS进程里。但是仍然有可能不同的群集资源加载到了同一个RHS进程里，如果多个资源共享一个RHS进程，那么某个资源出现故障时，群集会重启RHS进程，这样其他加载到RHS进程的正常资源也会跟着重启。
为了避免这类问题发生，可以酌情为不同的资源分配独立的资源监视器RHS进程。在群集资源里，有一个属性代表着使用独立还是共享的RHS进程，这个属性是SeparateMonitor。这个属性定义为0或者1，0和1代表False和True，定义为0，代表群集资源使用共享的RHS进程，定义为1，代表群集资源使用独立的RHS进程。
可以使用Get-ClusterResource查看哪些资源使用独立的RHS进程监控。下面以两个SQL Server数据库群集为例，运行如下命令查看RHS监视器情况。
| PS C:> Get-ClusterResource | ft name, SeparateMonitor, MonitorProcessID ||————————————————————————-|| Name | SeparateMonitor | MonitorProcessID ||———————–|—————–|——————|| Cluster Disk 1 | False | 3144 || Cluster Disk 2 | False | 3144 || Cluster IP Address | False | 3020 || Cluster Name | False | 3020 || File Share Witness | False | 3020 || SQL IP Address 1(MSSQLSERVER） | False | 3020 || SQL IP Address 2（Test） | False | 3020 || SQL Network Name（MSSQLSERVER） | False | 3020 || SQL Network Name（Test） | False | 3020 || SQL Server | True | 3188 || SQL Server（Test） | True | 3224 || SQL Server Agent | True | 3272 || SQL Server Agent（Test） | True | 3308 |
可以使用Get-ClusterResource修改资源使用独立的RHS进程监控。下面以数据库群集磁盘资源为例，将群集磁盘Cluster Disk1设置为使用独立的监视器，运行如下命令设置Cluster Disk 1使用独立的RHS监视器。
| PS C:> (Get-ClusterResource “Cluster Disk 1”).SeparateMonitor = 1 |
再次运行如下命令查看群集资源监视器情况。
Cluster Disk 1TrueCluster Disk 2FalseCluster IP AddressFalseCluster NameFalseFile Share WitnessFalseSQL IP Address 1(MSSQLSERVER）FalseSQL IP Address 2（Test）FalseSQL Network Name（MSSQLSERVER）FalseSQL Network Name（Test）FalseSQL ServerTrueSQL Server（Test）TrueSQL Server AgentTrueSQL Server Agent（Test）True
要注意的是，如果群集资源过多的情况下启用为每个资源配置独立的RHS进程，将会导致系统里同时运行多个RHS进程，因此会过多开销系统内存和CPU资源。而且群集已经可以把有问题的资源隔离加载到独立的RHS进程，从而避免有问题的资源影响到其他健康的资源，通常建议为群集资源保持默认设置。
以上就是Windows Server群集节点和资源监视的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/436299.html
微信扫一扫 
支付宝扫一扫 
