我负责多个大型 Hyper-V 故障转移群集。我偶尔会看到这样的问题:虚拟机的“ISALIVE:0”检查会失败(通过 vmclusres.dll 库),资源托管子系统会终止,从而导致多台机器瘫痪。
关于这里实际发生的情况,互联网上存在多条相互矛盾的信息。一些消息来源表明,故障转移集群将尝试将首先未通过健康检查的资源隔离到其自己的进程中(表明这可以保护在同一 RHS 下运行的其他资源)。
这绝对不会发生在完全修补的 Windows 2016 Hyper-V 集群上。似乎发生的情况是,发生故障的 RHS 被终止,从而杀死在同一进程下运行的所有计算。日志提到有问题的虚拟机资源被隔离,但我实际上看不到发生这种情况的证据(在该资源的属性中),但即使确实发生了这种情况,默认配置仍会导致一个资源有效地造成中断。
我可以稍微增加对这种行为总结的可信度,但我会强迫资源在他们自己独立的监视器中运行。如果我在实验室里这样做,我会站起来:
Get-ClusterResource -Name "*Virtual Machine blah*"
foreach ($resource in $cluster_resources) {$resource.SeparateMonitor}
... 我看到它们都使用默认设置,即不在单独的监视器中运行。很好。
如果我将它们全部设置为在各自的监视器中运行:
foreach ($resource in $cluster_resources) {$resource.SeparateMonitor = 1}
...并计算 RHS 进程,没有区别。正如您所预料的那样,如果我现在重新启动计算,我会突然发现许多 RHS 进程弹出,每个虚拟机一个。
因此,这表明资源无法在 RHS 父进程运行或开启时神奇地在它们之间切换,因此当单个资源出现问题时,开箱即用的配置确实可以关闭整个节点。有人能告诉我我是否正确吗?
另外,尝试回到原始问题背后的原因。有谁知道我可以在哪里获得有关 vmclusres.dll 库的 ISALIVE 检查的信息实际上正在做什么?没有任何信息表明哪种检查失败了,是 VM 状态检查,还是某种 IC 通信检查等。VM 没有在客户机内部转储,只是“失败”并导致中断,这有点可怕。我从一些研究中得知 ISALIVE 检查是五分钟的检查,应该是运行的两项检查中更深入的检查,但我找不到任何文档说明它实际上在检查什么,因此我无法反向工作。