clussvc 是 Windows 故障转移群集的托管系统服务, 运行于每个群集节点, 是 WSFC 的主服务, 负责群集组件之间的通信, 处理故障转移操作和管理配置等任务, clussvc 也和群集其它组件, 如 RHS,NetFT 组件相协同, 节点的硬件, 群集成员资格, 心跳检测结果, 第三方软件干扰, 将决定节点的群集服务能否正常启动
如下图所示为 clussvc 主服务包括的组件, 可以看到几乎所有的群集组件都寄生于 clussvc 下面, 因此 clussvc 的服务启停至关重要, 一旦 clussvc 服务停止, 则该节点将无法使用群集功能, 如果群集所有节点 clussvc 服务关闭, 则群集将停止对外服务
下图为 Clussvc 在群集架构中扮演的位置, 可以看到, clussvc 负责接收 API 传来的操作, 再将用户的请求传给其它群集组件进行工作, 同时也负责群集内部组件的协同通信, RHS 和 CPrepSrv 的检测也将反馈给 Clussvc
由于 clussvc 作为群集的托管主服务, 因此它比较特殊, 不同的场景会需要不同的启动开关, 启动命令如下 net start clussvc / 启动参数
从 2000 到 2003 时代, clussvc 群集服务的启动参数如下
Fixquorum: 适用于 2000 与 2003 时代, 该开关主要适用于处理, 因为仲裁设备而导致群集服务无法启动的场景, 例如被挂载的群集见证磁盘不稳定, 经常出现脱机情况, 使用 fixquorum 参数启动后可以让群集服务启动, 但是不联机群集仲裁设备, 仅联机群集 IP 和群集名称, 同时关闭日志记录存储到仲裁设备功能, 通过该模式启动后, 群集应用资源和仲裁资源将被脱机, 管理员可以手动联机仲裁资源以观察日志进行诊断
该启动参数最好用于群集只剩下一个节点的场景, 通过该参数启动后, 将在该节点挂载群集数据库, 群集 IP, 群集名称, 便于排错, 如果群集其它节点正在运行, 建议排除仲裁设备问题前, 为其它节点停止群集服务, 以防止抢夺群集 IP, 群集名称
排除问题后重新以正常开关 net start clussvc 启动节点
NoQuorumLogging : 透过该参数启动后群集将关闭日志记录存储到仲裁设备功能, 用于诊断仲裁设备中的仲裁日志和检查点问题, 通常情况下, 该开关仅在一个节点上使用, 主要用于 2003 时代当仲裁设备日志文件或检查点文件损坏, 并且您想手动将这些文件替换为备份副本时使用
需要注意, 通过该参数启动群集有可能引发时间分区问题, 通过 NoQuorumlogging 启动的节点最好不要修改群集信息
在 2008 之前, 群集只有仲裁设备会保存一份群集数据库的最新副本, 各个节点都需要和仲裁盘进行同步, 由仲裁盘复制群集数据库到各节点, 各节点在关机重启后也必须连接到仲裁盘同步下载群集数据库, 如果仲裁盘出现故障, 则群集将无法启动, 因此在 2008 之前, 仲裁磁盘成为了单一故障点, 2008 开始, 群集引入了 paxos 标记的机制, 每个节点本身都可以保存群集数据库最新副本, 如果仲裁设备出现问题, 最快的解决办法, 新加入一个仲裁磁盘, 把旧的替换掉, 仲裁磁盘检测到群集节点的数据库 paxos 标记比较新, 会自动同步新的群集数据库过来
Debug: 在 2003 时代群集日志仅包含群集服务启动后的群集日志, 而不包含群集服务启动过程的日志, 因此, 如果要排除群集服务启动过程的故障, 需要使用 debug 开关执行操作, 切换到 C:\System32\Cluster 目录下, 使用命令提示符执行 clussvc /debug > c:\clusdebug.txt, 则可以将群集服务以 debug 的用途启动, 并将捕捉整个启动过程信息至日志, 主要用于 2003 时代, 因为群集启动账号或系统配置而导致群集服务无法启动问题, 2008 之后群集服务启动日志可在 clusterlog 看到
Debug 参数也支持设置启动诊断日志级别, 方法如下: clussvc / debug loglevel = 3> c:\debug.log
level 0 不记录
level 1 只记录错误
level 2 记录错误和警告
level3 记录所有事件, 包括未写入事件日志的事件
DebugResMon : 用于调试资源监视器进程, 并因此调试由资源监视器加载的资源动态链接库 (DLL), 开发人员可以使用此开关来调试资源监视器进程及其自定义资源 DLL, 在资源监视器进程启动之前, 群集服务进程等待, 并等待消息等待调试器连接到 resmon 进程 X, 其中 X 是资源监视器进程的进程 ID(PID). 群集服务会执行此操作, 以等待由其创建的所有资源监视器进程在用户将调试器附加到资源监视器进程并且资源监视器进程启动后, 群集服务将继续其初始化
用法: Clussvc /debug /debugresmon
ResetQuorumLog : 用于 2000 及 2003 时代, 如果仲裁日志和检查点文件未找到或已损坏, 则可用于根据本地节点的%SystemRoot%\ Cluster \ CLUSDB 注册表配置单元中的信息来创建文件, 适用于仲裁磁盘仲裁日志, 出现损坏的场景, 即使用各节点本地文件注册表创建仲裁日志和检查点文件, 而后使用 fixquorum 方式启动群集, 替换仲裁磁盘
用法: net start clussvc / resetquorumlog, 执行该命令后, MSCS 会自动检测仲裁日志损坏, 自动使用节点本地注册表配置单元重新生成仲裁日志
ResetQuorumLog 与 NoQuorumLogging 不同适用场景
NoQuorumLogging: 有仲裁设备备份, 暂时停掉写入, 然后把已备份的恢复覆盖
ResetQuorumLog: 没有仲裁设备备份, 利用各节点本地注册表重建仲裁日志
两种参数启动群集服务后, 都需使用 net start clussvc 再正常启动一次
NoRepEvtLogging : 适用于 2000 与 2003 , 在 2000 和 2003 时代 cluster log 是群集服务实时产生的, 此参数可以防止事件日志的复制, 如果有大量事件日志条目, 则群集服务将复制这些条目, 并将它们记录到 cluster.log 这可能会导致 cluster.log 快速换行通过该参数可以阻止节点的 cluster log 被复制到其它节点, 减少网络通信带宽, 并且可以把该节点未刷新到 cluster log 的日志转移至本地 log 中
net start clussvc /norepevtlogging 阻止该节点的事件日志复制到其它节点, 但可以正常接收其它节点的信息
clussvc /debug /norepevtlogging > c:\debugnorep.log 将该节点群集服务还未刷新至 cluster log 的日志转移至本地 log
ForceQuorum: 最广为大家熟悉的群集启动参数, 在 2003 时代引入, 2003 时代该参数缩写为 FO,FQ 是 fixquorum,2003 时代的 forcequorum, 主要起到让少数分区提供服务的作用, 和 2008 时代的 forcequorum 有一些区别, 例如 2003 时代北京站点 4 节点, 上海站点 3 节点, 两站点间发生分区, 但是北京已知无法对外提供服务, 因此需强制启动上海站点, 但起点过程需指定上海站点节点名称, 如 net start clussvc / forcequorum / forcequorum node5,node6,node7, 使用该命令起点后, 上海站点将重新启动一个群集, 这个群集的可用所有者列表只有 5 6 7 节点启动上海站点后应手动停止北京各节点群集服务, 防止抢夺资源, 当分区恢复时重新正常启动群集服务
在 2008 时代 WSFC 引入了几个新的参数, PreventQuorum,IgnorePersistentState, 以及发生变化的 ForceQuorum
正如老王在前面文章可以大家提到过的, ForceQuorum 在 2008 时代发生了变化, 引入了 paxos 标记机制, 和之前的作用一样, 帮助群集节点在少数节点的情况下也能强制启动提供服务, 但是却比之前版本方便了许多, 在 2008 中, 我们只需要在少数节点其中一个节点执行 net start clussvc /FQ 即可, 2008 开始 FQ 缩写开始指 forcequorum, 被执行 FQ 的节点自身的群集数据库会被提升为黄金副本, 之后其它所有节点如果希望参与群集, 都必须和 FQ 节点同步群集数据库后, 才可以正常参与进群集, 在 2008 时代, 如果少数方执行 FQ 强制仲裁后, 需要到多数方执行 PQ, 阻止多数方形成群集, 日后分区解除, 多数方将自动与 FQ 方同步最新群集数据库
IPS 参数于 2008R2 引入, ForceQuorum 为 2008 起发生改变, PQ 为 2008R2 引入, 2008 可通过 hotfix 获得
IPS 开关是一个有意思的参数, 类似于 2000 时代的 Fixquorum, 不同的是 fixquorum 仅联机群集 IP 和群集名称, 其它资源一律不联机, 而 IgnorePersistentState 参数可以帮助我们联机群集 IP, 群集名称, 仲裁磁盘, 这些所有核心组组件, 而不联机任何基于群集的应用, 可以帮助管理员先恢复群集正常服务, 再排查基于群集的应用问题
在正常情况下, 群集服务启动时, 默认行为是将所有资源联机 IPS 开关所做的是忽略当前的资源 PersistentState 值, 并将所有内容保持为离线状态
使用该参数后群集整体处于联机状态, 可以对外提供服务, 此开关只会影响群集中的服务和应用程序组
该参数要求群集符合法定人数要求下才可以使用
适用场景
1. 群集各节点资源负载饱满, 导致启动时群集节点崩溃, 可以使用 / IPS 模式启动群集, 先联机一部分群集应用, 进行排错, 排错完成后, 再联机其它群集应用
2. 基于群集的第三方应用导致群集伪挂起, 使用 IPS 参数启动群集后正常启动群集, 检查应用问题, 修复后再联机应用
用法: net start clussvc /ips 或 net start clussvc /ips /fq , 如果在不符合法定仲裁人数运作需添加 fq 参数
2012 开始, 阻止仲裁技术发生了改变, 多数节点一方检测到少数节点一方存在强制仲裁会自动执行阻止仲裁操作, 即确保承认强制仲裁一方为群集, 与其群集数据库同步至最新后, 才会启动自身群集服务, 在之前 2008 时代, 如果遇到强制仲裁的场景下, 大多数时间都需要手动去执行阻止仲裁, 否则会出现群集数据库覆盖等情况, 到了 2012 则会自动帮助我们做这件事
2016 WSFC 开始向最新的技术看齐整合了, 存储副本, 超融合技术, 可以和 Azure 相配合, 实现 WSFC on Azure,Azure witness, 除了这些还改变了群集默认的检测机制, 新导入了瞬断机制, 防止由于瞬时中断而导致群集应用故障转移, 可以设定在指定时间内群集的故障不需要执行故障转移, 如果某时间内发生了某次数的瞬时中断, 则判定节点为检疫隔离状态, 节点处在检疫状态下的时间, 默认为 7200 秒, 在这段时间, 节点将不承载应用, 所有虚拟机被实时迁移走, 其它群集资源被移动走, 如果节点提前恢复可使用 net start clussvc /CQ 或 Start-ClusterNode -CQ , 执行 ClearQuarantine 操作, 把节点手动恢复正常
总结到最新 2016 还剩下的 clussvc 启动参数: FQ,PQ,IPS,CQ
来源: http://www.bubuko.com/infodetail-2515008.html