如何建立故障恢复体系及配置集群

日期: 2008-08-10 作者:Alessandro Perilli翻译:涂凡才 来源:TechTarget中国 英文

虚拟数据中心的高可用性(HA)是一个多层次的任务,它涉及到在线备份(live backup)、故障恢复功能或集群等等。在本系列的上部分中,我们已经谈到了虚拟机备份。在本文中,TechTarget中国的特约虚拟化专家Alessandro Perilli将探讨如何在虚拟环境下配置集群(cluster),建立故障恢复体系(failover structure)。   虚拟化的高可用性有两个层面。

我们既可以在子机层操作,依赖OS和应用灾难恢复能力;也可以在主机层操作,从而面对一系列新的问题。   在子机层执行HA配置的过程几乎与在物理机环境下一样,需要解决一些技术问题。例如,为每个虚拟网络接口设置静态……

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

电子邮件地址不会被公开。 必填项已用*标注

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。

虚拟数据中心的高可用性(HA)是一个多层次的任务,它涉及到在线备份(live backup)、故障恢复功能或集群等等。在本系列的上部分中,我们已经谈到了虚拟机备份。在本文中,TechTarget中国的特约虚拟化专家Alessandro Perilli将探讨如何在虚拟环境下配置集群(cluster),建立故障恢复体系(failover structure)。

  虚拟化的高可用性有两个层面。我们既可以在子机层操作,依赖OS和应用灾难恢复能力;也可以在主机层操作,从而面对一系列新的问题。

  在子机层执行HA配置的过程几乎与在物理机环境下一样,需要解决一些技术问题。例如,为每个虚拟网络接口设置静态MAC地址。此外,还需要突破一些限制因素,这些限制因素取决于所选的虚拟化平台和HA软件。不过,虚拟集群创建基本上都是可以完成的,甚至可以创建混合式(mixed)虚拟集群。在混合式虚拟集群中,有一个或多个节点是虚拟机,其它节点则均为物理机。

  主机的高可用性更有必要性,不过也更加复杂。在这样的情况下,以故障恢复为例,运行于主机中的虚拟机必须被复制到另一台主机,而且要保持持续性同步,复制虚拟磁盘和虚拟内存修改。这个操作与在线备份有同样的问题,而且还更加复杂,需要尽可能快、尽可能多地重复进行此操作。

  这样,Vizioncore再一次成为了主角。它有esxReplicator,能够将正在运行的虚拟机从一台VMware Server复制到另一台VMware Server,而且不需要集中存储设备。不幸的是,这款产品不能处理网络修改(network modification),而执行故障恢复时需要用到网络修改,所以我们只能手动切换出错主机和冷备份(cold standby)主机。

  VMware自身也提供了一个更加强大的解决方案,推出了ESX Server 3和VirtualCenter 2,这是一个基于VMotion的故障恢复选项。VMware HA不像Vizioncore esxReplicator,它可以自动重启出错主机中的虚拟机。不过很遗憾,VMware HA在配置方面非常费力。它必须要有VirtualCenter和VMotion,而且虚拟机必须存储于光纤通道SAN环境,否则它就无法工作。

  其它高可用性方法

  另一方面,P2V迁移工具可以帮助我们执行P2V迁移。因此,我们可以配置P2V迁移工具,以便复制虚拟机到其它主机。

  在这种情况下,PlateSpin是一个比较好的选择。它提供了Windows操作系统的动态迁移功能(live migration)。此外,还可以利用这个技术进行灾难恢复。然而不幸的是,PlateSpin跟Vizioncore一样,也不能处理故障恢复的每个方面,所以我们还得手动干预。

  使用故障恢复固然是个不错的方法,但是最可取的HA配置方法毫无疑问当属集群。在集群中,多台主机担当共享虚拟机的一个执行前端。如果其中一个主机出错,不会造成服务中断。因为还有其它主机可以正常工作,虚拟机总是可用。

  利用虚拟化平台的自身功能或第三方解决方案,我们可以在主机层执行集群。

  例如,在Microsoft Virtual Server中,Windows是主机操作系统,微软允许通过Cluster Service执行虚拟化物理节点集群。

  相反,VMwareESX Server没有这样的功能。不过,它有一些外部解决方案可以完成这个任务,如Symantec Veritas Cluster Service。最近EMC公司发布了Rainfinity,这让我们看到了希望,有一天RainWall技术终将可以用于执行ESX集群。

  目前,虚拟化集群解决方案还远不够成熟,在采用之前一定要进行严格的测试。
  
  更多难点

  故障恢复和集群配置的结构也十分复杂。虚拟机在主机之间迁移时,它们可能有不同生产厂家的CPU服务,这些CPU可能比较相似,但并不相同。而且,现有的虚拟化平台仍然无法实时处理动态迁移过程中的这些差异。

  同样,如果各个可用主机的配置不同,虚拟机的虚拟磁盘分配(例如,一台虚拟机有4个虚拟CPU)可能无法得到满足,从而无法执行迁移。

  这种情况不久还可能变得更糟糕,这取决于生产商如何支持准虚拟化(paravirtualization)。这种方法需要新一代的CPU才能运行主操作系统。如果虚拟化平台不能同时运行普通的二进制译码(binary translation)和准虚拟化,或者不能准确地在两者之间进行切换,那么我们就不能混合使用新老物理服务器。换句话说,我们每次购买新配件后就必须翻新全部硬件基础设施,或者谨慎地考虑如何集合主机,从而获取高可用性。

  最后一点也很重要,我们必须允许可信存储设施访问,这显然是最关键的一步。这一步通常是由称作多路径(multipathing)的软件完成的。当主机有两个或更多HBA(主机总线适配器)以访问多个SAN时,存储管理软件能够动态选择可用连接,而不会选择出错连接。

  在驱动层安装软件有一定的局限性。根据你所选的虚拟化平台不同,你可能不能安装驱动。例如,VMware ESX Server现有的架构就不允许存储商安装它们自己的驱动,而VMware自己提供的驱动又不支持动态多路径。

  在选择托管解决方案(hosted solution)时,如VMware Server或Microsoft Virtual Server,你的判断依据是操作系统,而不是是否支持OEM(原始设备制造商)的驱动,因为OEM的驱动始终是被支持的。

相关推荐