解决Hyper-V高可用集群服务和网络问题

申请免费试用、咨询电话：400-8352-114

这个系列包含四个部分，主要讨论如何提高Hyper-V高可用集群的性能。第一部分阐述了固件、驱动、补丁和更新对虚拟主机集群稳定性的影响；第二、第三部分，我给出了在解决Hyper-V集群故障时的一些个人经验，这些经验有助于提高虚拟集群的稳定性。这里，在第四部分，我讨论一些复杂的网络问题并解释何时、怎样结束Hyper-V高可用集群服务。

Hyper-V网络问题1：虚拟机重启后，IP地址重复或者自动寻找私有IP(APIPA)

这个问题发生在Hyper-V集群节点突发性丢失私有/公共网络或者FC链路之后，同时，该问题还会触发虚拟机在其他的主机上重新启动。当看到很多的虚拟机都在试图寻找一个替代主机时，我发现那简直是一团糟。

在很多情况下，虚拟机将会试图在存活的节点上重新启动，然后迁移到另外一个节点直到虚拟机再次重启。其结果是，如果虚拟机运行Windows 2003或XP，该虚拟机就会重新启动并报告“网络上的IP地址重复”；如果是Windows 2008或Vista，就会获得一个APIPA地址……除了网络问题，所有其他的虚拟机功能应该工作正常。遗憾的是，”修复”或者”禁用-再启动”虚拟机网卡没有什么效果。手工启动几次受影响的虚拟机则可以搞定。

有个小技巧：作为一种更快的方式，可以打开Hyper-V Manager，双击虚拟机，然后选择“关机”。系统将会关闭，不过虚拟机会立即重启，因为它是高可用集群的一部分。

这个问题是因为在不恰当的时间、不正确的完成集群中虚拟机配置而导致。根据我的观察，当集成的组件没有匹配安装在主机上的Hyper-V版本时，这种情况就会出现。

因此，假如你的环境中包含Windows 2008 SP2的Hyper-V主机和具有Hyper-V的集成组件的虚拟机，在集成组件升级后，这些问题就会发生。不过，假如这些问题在你升级集成组件之前发生，那就相对简单，手工重启受到影响的虚拟机就应该可以解决问题。

Hyper-V网络问题2：关机之后还可以ping通虚拟机

很多情况下，就像我们刚才所提到的，重启可以解决虚拟机的网络问题。同样，当Hyper-V集群主机出现不可预料的故障、虚拟机被迫在其他的节点上重启，我曾见过系统完全重启，同时报告它们都可以正常的ping通。

但是，如果再深入检查就会发现，除了能够ping通，无法通过其他的远程管理进程(例如，远程桌面协议(RDP),eventvwr，全局名称协议等等)访问虚拟机。也无法从虚拟机ping出去。更奇怪的是，就算你完全关闭了虚拟机，还是可以ping通它。

为了解决这个问题，请使用Failover Cluster Manager或者SCVMM关闭虚拟机集群。在Hyper-V manager中关闭虚拟机集群会引起集群重启虚拟机的高可用性回应。

当你目睹Failover Cluster Manager显示虚拟机已经关掉却还能ping通的时候，你会很诧异。根据我的经验，这种情形是由于为虚拟机配置了传统的网络适配器引起。

要修复这个问题会有一点棘手，需要使用Failover Cluster Manager和Hyper-V Manager，以下是操作步骤：

1. 当遇到集群中节点失效时，很可能有必要在每个节点上重启Hyper-V Management Service以刷新真正的虚拟机状态，同时使用Hyper-V Manager工具。

然后，在Failover Cluster Manager中，右键单击受影响的虚拟机的“配置”，再选择“关闭”。

2. 关闭之后，通过Hyper-V Manager远程ping该虚拟机检查其状态。你会发现，它在Hyper-V Manager中的状态是关闭的，但是可以ping通。

3. 使用Failover Cluster Manager将该虚拟机移动到集群中其他的节点上，然后执行第2步。请注意，当每个虚拟机都移动完成之后，它们在Hyper-V Manager中的状态将会改变为“运行”，尽管它们在Failover Cluster Manager中的状态依然是关闭的。

4. 要解决这个问题，在Hyper-V Manager中右键单击虚拟机，然后选择“Turn Off”。这个时候，虚拟机的状态会显示为关闭，同时也无法再ping通。

5. 重启虚拟机。它就会恢复到全功能状态。

要消除这个问题，需要限制虚拟机使用传统的网络适配器，它通过主机分区路由流量。

结束Hyper-V高可用集群服务

有时，对一个响应迟钝的虚拟集群节点而言，我感到自己真拿它没办法。无论是驱动问题，卷影复制服务(Volume Shadow Copy Service)垮掉或者其他未知的问题，在很多情况下，我不得不拿出“锤子”将节点上的高可用集群服务“杀掉”。当节点上有多个处于未知状态的虚拟机负载时，“杀掉”该服务需要勇气，但对于集群的整体稳定性来说，很有必要。

不过，在采取这种极端的操作之前，了解其后果非常重要。当你“杀掉”高可用集群服务时，该服务会为集群中的剩余节点创建一个高可用的回应。故障节点上的虚拟机会被重新分布到其他的节点并重启，就像刚刚经历一次断电。根据我们的经验，Failover Cluster Manager现在将会派上用场，将会重启故障节点。在将虚拟机移动回去之前，请仔细检查事件记录和其他的监控记录。

再次重申，在“杀掉”高可用集群服务之前，你应该搞清楚每个选项。

举几个例子，比如，Hyper-V已经完全无法对外界的集群管理工具做出响应。集群工具的管理功能——比如cluster.exe命令或者任何图形化用户接口(GUI)形式的管理工具(比如，Failover Cluster Manager, SCVMM, Hyper-V Manager等) ——已经无法使用或者不能响应。尽管如此，一些虚拟机的正常运行，而另外一些则不是。

如果出现这种情况，在你“杀掉”高可用集群服务之前，你应该检查以下项目：

使用cluster.exe命令查询受影响的节点。对GUI中不响应的节点来说，要查询虚拟机的状态，这个工具可能仍然只具备有限的功能。从查询的反馈中，有问题的虚拟机集群资源会引导你找到真正的原因。 使用某个产品，比如Pskill或者Taskkill。在《Hyper-V虚拟机配置文件，虚拟机状态有关的集群问题》这篇文章中，我描述了如何找到某个特定虚拟机的VMWP.exe进程并杀死它。如果能够从cluster.exe命令的输出中找到虚拟机卡壳的任何信息，那将有助于终结一个有问题的虚拟机而不是“杀掉“高可用集群服务。 试着从一次崩溃中保存虚拟机的工作负载。你可能无法访问集群主机，但是你可以通过RDP或者其他的远程管理进程访问客户端OS。从高可用集群中手动关闭虚拟机只会使该虚拟机从别的地方再重新启动，因此，聪明的做法是，关闭应用程序，看上去就像经历了一次硬关机。　　问题总会遇到，你可能不得不杀掉高可用集群服务从而重新获得控制权。我曾经成功的使用Pskill和Taskkill杀掉了高可用集群服务。

Taskkill /s CLUSTERNODENAME /IM clussvc.exe

PsKill \CLUSTERNODENAME clussvc.exe

（请注意：“杀掉“高可用集群服务之后，以前遇到的一些问题可能会重现：比如IP地址重复，或者APIPA，虚拟机重启之后或者关闭之后仍然可以ping通。）

这个系列虽然列出了很多Hyper-V集群的问题，可是，我依然认为虚拟主机集群的优势远大于其弊端。这些问题并不是经常出现，但它们一旦发生，总会让人发疯和抓狂。

最后，这些问题指出了Hyper-V以及其他的虚拟化产品的发展时期不可避免的困境。随着更多的用户采用虚拟化技术、更广泛的利用虚拟化技术，会出现更多的问题——比如，在这个系列中提到的这些问题。