通过Windows Server 2012提高虚拟化环境下的高可用性

 

虚拟化环境高可用简述

通常情况下，在虚拟化环境中服务器会提供一种基础的高可用环境，即在各物理主机节点之间构建集群，然后对需要保护的虚拟机的启用高可用；但是这种高可用环境一般只能检测物理环境的故障，例如物理主机宕机等，并且恢复的操作方式是将故障物理主机上的虚拟机选择另外一台可用的集群物理节点启动，好一些的集群策略通常还会加入对选择启动节点的“资源尺寸”进行测量，并采用优化的方式在集群内的剩余节点启动等方式。无论怎样，该方法针对的只是物理资源监控而非虚拟机资源；因此有些虚拟化厂商提供了可以通过在VM中插入插件的方式，并通过虚拟化层与该插件的“心跳”确定VM的存活状态，进而实现对虚拟机的监控；例如，如果虚拟化层发现该受检测的虚拟机无法连接，那么将采用尝试在该物理节点重启虚拟机的方式意图恢复该VM及其上的应用，但这种方式局限性也很明显，因为虚拟层监控的是VM而不是应用本身。如果该应用还可以正常对外提供服务，但由于VM插件故障造成无法通信造成虚拟化尝试以损失该应用的状态的方法重启VM，这个代价是相当不可以接受的。

所以有些虚拟化厂商通常提供以下两种替代方案：

• 通过API方式扩展对VM内部应用的监控并实现与虚拟化层控制策略的调用
• 在VM之间实现对共享存储的连接，并实现客户机集群Guest Cluster。

说到客户机集群Guest Cluster和主机集群Host Cluster，这里不妨做个简单的比较来看看两种集群方式的优缺点：

 

	主机集群 Host Cluster	客户机集群 Guest Cluster
操作系统状态
虚拟机移动性
应用程序监控和控制
应用程序在虚拟机间的移动性
备用资源开销
额外的存储配置 （为虚拟机分配存储）

 

从上表中可以看到，虽然主机集群方式可以节省备用节点的资源，节省为虚拟机单独分配存储的管理成本；但是由于缺乏对虚拟机内部资源监控，还是很少被一些关键应用所采用。而客户机集群方式构建较为复杂，尤其是存储层面，而且还会有冗余物理资源的浪费情况。

 

那么有没有一种相对两全其美的方案呢？

在即将推出的Windows Server 2012中，给出了一个良好的答案。针对主机集群方式提供了Failover Cluster的虚拟机监控功能，允许虚拟化层监控运行在虚拟机内部的应用健康状态，并可以根据此状态进行故障恢复操作。

具有这个功能后，在虚拟机内运行的应用，无论是SQL Server，Exchange，Lync或是IIS，只要健康状态出现问题，都可以通过与虚拟化层通信的通道触发相应的故障恢复操作。

也正是因为这个非常有意义的功能，本文将提供较为详细的步骤和构建方式描述Windows Server 2012下的虚拟化环境下如何通过Failover Cluster实现该功能。

 

配置虚拟机监控的前提条件

在配置虚拟机监控之前，必须先通过“故障转移群集管理器”进行如下一些关键配置：

• 配置VM上的客户机操作系统
  
  • 客户机操作系统必须是运行Windows Server 2012的虚拟机
  • 客户机操作系统和运行虚拟机的Windows Server 2012主机是相同的域或建立了主机域的信任关系的域成员。
• 给管理客户机的集群管理员赋权
  
  • 运行故障转移群集管理器的管理员必须是在客户机VM的本地管理员组的成员。（当然我们在试验中可以采用域管理员来完成）
• 在客户机启用虚拟机监控防火墙策略
  
  • 打开Windows防火墙配置界面
  • 打开客户机的虚拟机监控
  • 选择“允许一个应用程序或功能通过Windows防火墙”

当然我也很建议采用Powershell完成上述工作，要知道我是很喜欢命令行的，哈。方法很简单，打开Powershell界面，运行Set-NetFirewallRule  -DisplayGroup "Virtual Machine Monitoring" -Enabled True。

 

在故障转移集群完成配置虚拟机监控

如果你做过一次一定不会觉得这个配置很麻烦，呵呵。只需要在故障转移集群中完成几个操作即可：

• 在故障转移集群的控制台，在角色目录下右键点击需要在主机集群中监控的虚拟机
• 在更多操作中选择配置监控选项
• 之后就可以通过服务下拉列表选择需要通过Failover Cluster监控的服务或应用了。
• 拿一个正在运行的服务作测试，这里我们选择Print Spooler服务。( 服务列表是从进程列表里面拿到的名称，当然通过Powershell修改是最方便的方式  Add-ClusterVMMonitoredItem –VirtualMachine GuestVM1 -Service spooler )

 

虚拟机监控的工作方式和测试流程

我们首先来看一下Windows下服务的恢复方式，见下图

可以看到在第一次服务失败和第二次服务失败时，系统对服务自身采用的恢复方法默认是重新启动；第三项则是系统不采用任何操作，因此将恢复方式交给了外部主机集群的监控操作处理。

 

现在我们来模拟一下第一，第二次的应用故障，通过命令行 Get-Process spoolsv | Stop-Process, 可以在服务器管理器观察到第一二次停止进程，服务会自动进行重启恢复。但是当我们第三次模拟故障时，可以看到VM自动重新启动了。

回到故障转移集群，我们可以观察到此时触发了一个事件错误ID 1250

• 如果我们使用微软的System Center Operation Manger（SCOM）的话，我们可以利用这个错误ID在激发System Center Service Manger/Ochestrator等客户化恢复流程。
• 而如果通过故障转移集群控制台观察虚拟机运行状态的话，可以看到虚拟机的状态为应用程序关键状态。
• 可以通过Powershell获得该虚拟机的资源信息 Get-ClusterResource “GuestVM1” | fl StatusInformation
  

虚拟机在Failover Cluster中的故障恢复策略为：

• 尝试在集群中的同一个物理节点中重启该故障虚拟机
• 如果仍然出现应用关键错误，则尝试在集群中的另外一个节点中尝试启动该虚拟机。

关于虚拟机监控的故障转移策略，可以通过虚拟机设置中的配置来设置：

 

上述实验在我的测试环境中测试完成，感觉还是很不错的；作为客户机环境的集群有益的补充，相信Windows Server 2012的该功能将在企业级数据中心的“云”环境中大展拳脚。

转载于:https://blog.51cto.com/3387405/981916