即使虚拟化逐步成熟,高可用性HA仍然是集群里最难懂的组件之一。服务器集群能启动高可用性,它是一个hypervisor功能,当虚拟机崩溃时能限制宕机时间。VMware vSphere、Microsoft Hyper-V and Citrix XenServer都提供了高可用性功能,减轻虚拟架构中的灾难恢复任务。
太多的人在没有理解高可用性的情况下实施虚拟化项目。更糟的是,管理员在服务器集群实施期间忽视高可用性,导致现在发现它从解决问题的方案变成需要解决的问题。
事实上,高可用性能解决一些列问题。它就是一个简单的服务,无论你使用何种hypervisor,在主机发生故障后重新启动虚拟机。持续的可用性是个理想目标,但是虚拟机仍然经历一些宕机。
高可用性通常与热迁移相关,如XenMotion、vMotion,但实际上不是,我曾见过在第一次主机发生故障后,服务器集群里出现大量问题,由于混淆了这两个概念。
高可用性技术越来越智能,但是要注意下面的问题可能使你的服务器集群崩溃。
DNS如何影响高可用性
与VMware HA结合,域名服务器(DNS)分辨率会成为严重的问题。要允许服务器集群节点相互通信,VMware对DNS分辨率担负重要责任。通常,这不是问题。但如今很多的IT人员已经习惯DNS是个服务的概念,不需要进行管理。
这种不干预政策的部分原因在于Windows的动态DNS功能。许多管理员没有像以前那样花心思对待DNS,因为动态DNS现在自动执行多数任务。但是VMware服务器没有使用动态DNS.
如果在服务器集群中使用VMware HA,确保你的管理网络IP地址和相关的主机名都进入到DNS.在进行变更或添加附件到虚拟环境中时,需要进行手动操作与维护。如果DNS没有正确配置,VMware会出现明显的提示说明,但是如果发现得太晚就容易忽略这个提示。
#p#
多站点服务器集群中的DNS分辨率
DNS分辨率问题也会影响多站点Hyper-V集群。Hyper-V的Windows Failover Clustering服务现在能跨子网。在某些方面,这种架构很好,因为你不再需要使用复杂的网络技术跨不同的地点管理。但另一方面,故障转移到第二个站点的虚拟机通常需要处理新的子网。
从服务器方面来说这不是大问题,但对于客户端就造成问题。客户端配置的是存活时间值,决定缓存DNS报道需要多久。故障转移后这些报道就过时了。在物理的灾难恢复中,通常不是问题,因为你可能需要处理更多重要的问题,如“数据中心正在崩溃!”但在虚拟架构中,当虚拟机偶然迁移到另一个可替换站点时就会出现问题。
高可用性问题不专门出现在Hyper-V集群中。在不同的子网启动虚拟机的灾难恢复的服务器集群都会经历类似的问题。
#p#
故障恢复命令的重要性
DNS问题凸显了服务器集群管理中故障恢复命令重要性这个事实。一些服务器集群组织故障恢复命令比其他的好。例如VMware HA让服务器集群自己处理故障恢复命令。其他的如Hyper-V,管理员手动决定发生故障后虚拟机往哪迁移。
你不想看到的是虚拟机移到不合适的服务器集群节点,如移到多站点集群的另一端,或者超载的节点。特别注意你的故障恢复命令,确保平衡集群负载。
#p#
发生主机隔离该怎么做?
当服务器集群主机仍然在线时就会出现主机隔离,但它已不能与其他节点通信。主机隔离的问题在于隔离的主机仍然运行虚拟机。在VMware HA隔离事件中,这些虚拟机通常运行在不同的虚拟交换机上,不会受到隔离的影响。集群可能想将这些虚拟机故障恢复到隔离区之外,但是如果一台隔离的主机缺少虚拟机的磁盘文件就不能实现。
有几种方式修复这个问题。很明显,将隔离的主机重新召回来在线是最佳方案。但是如果不能这样做,你需要关闭虚拟机,让存活的集群节点能故障转移这些虚拟机。注意高科用性解决方案的隔离响应设置,确定哪个设置能满足你的特别需求。在主机发生隔离时,许多功能允许你选择继续运行或者关闭虚拟机。
高可用性是虚拟架构中的有用组件,但是不能在服务器集群中绕开重要的设置来管理让人兴奋的负载均衡功能。否则,就会出现许多棘手的问题。
【编辑推荐】