上一部分介绍了虚拟环境对资源管理带来的新挑战，以及灾难恢复之一的备份机制，接下继续介绍其他两项机制。另外，在后面还有对虚拟机配置自动化和架构自动化的介绍。

　　故障转移和集群机制

　　很明显，数据中心的高可用性（HA ,high availability） 仅仅依靠虚拟机备份是远远不够的。正如传统环境下要建立故障转移机制甚至于创建服务器集群以保万一。相比而言，虚拟环境下的服务的高可用性有更多的实现机会：我们既可以在客机层依赖OS和灾难恢复程序，又可更近一层地在主机层安排保障措施。

　　在客机层进行HA的配置与物理环境下的操作基本一致，但一些技术细节还是要注意一下，比如为每个虚拟网络接口设置一个静态MAC地址，还要考虑到各虚拟平台以及选用的HA软件的一些局限性。

　　HA措施之一是故障转移的建立，即是将一台物理主机上运行中的虚拟机同步连续地拷贝到另一台主机上，因此虚拟硬盘和虚拟内存中的数据即被备份了起来。一旦其中的一台主机出现故障，那么服务可以转移到另一台主机上而不至中断。

　　故障转移机制的运行和我们前面讨论过的实时备份面临着同样的问题，但它的优点似乎更加吸引人，这方面的产品也层出不穷。Vizioncore再次走在了前面，其esxReplicator能够将VMware ESX Server下运行中的虚拟机从一台拷贝到另一台主机。可惜的是它无法自动配置故障转移所需的网络参数，所以当故障发生时，还需要手工配置才能实现真正意义上的故障转移。

　　VMware结合ESX Server 3 -VirtualCenter 2的故障转移方案基于VMotion技术，因此显得更加灵活。与esxReplicator不同，VMware HA在发生故障时，它能自动重启故障主机上的虚拟机。不过实现的代价也是相当昂贵的：VirtualCenter和VMotion；需要有光纤通道的SAN。

　　还有一种方案，就是我们前面提到的P2V工具，利用其中的V2V功能，我们可以将虚拟机数据从一台主机迁移复制到另一台上。在这PlateSpin当然是最佳选择，提供的windows虚拟机实时迁移的效果不错。

　　故障转移机制虽然常用，但HA最好的措施是建立集群化。多个物理或虚拟服务器集结为一个整体共同承载所有虚拟机的运行，这样即使其中一台主机或一个节点出现问题，却并不影响整体服务的可用性。

　　这种主机级集群可以由虚拟平台的固有特性来实现，也可采用第三方解决方案。以微软的Virtual Server为例，它通过自身的Cluster Service就可以将物理节点集群化。与之对应的ESX Server则借助第三方的方案，如赛门铁克的Veritas Cluster Service以实现集群化。不过随着EMC公司对Rainfinity的收购，ESX Server有望用上自有的Rainwall集群技术。 但无论如何努力，今日虚拟化的集群方案还远远称不上成熟，因此建议用户在真正采用前一定要经过严格的测试。

　　不管是故障转移机制还是集群的建立，都面临着构架不同带来的复杂性。比如虚拟机在不同主机上的实时迁移，不同主机如果采用不同厂商的CPU，那么当前的虚拟平台因为还无法处理这种架构上的差异而导致迁移的失败。同样的问题广泛存在于不同的硬件设置、虚拟机以及虚拟硬件分配，这些情况的差别都有可能使得迁移失败。

　　以后的情况看起来并不会好转，这要看厂商对未来的超虚拟化（paravirtualization）的支持程度了。众所周知，超虚拟化需要以新一代CPU的支持，这种CPU特别设置了一个ring级别以运行主机操作系统，大大提高了效率。但如果到时虚拟化平台无法支持二进制转化（二进制程序在不同CPU间相互转化的技术）以及超虚拟化，或者无法做到两者的有机结合，这些都会使得新旧物理主机无法混合使用，用户将不得不承受硬件更新带来的巨大损失。

　　虽然最后提起，但存储设备的可靠访问应该是HA中最重要的一个环节。多块HBA（Host Bus Adaptor 主机总线适配卡，连接服务器内部I/O通道与存储系统I/O通道的设备）连接的SAN有项被称为“多路径”的技术，其中的存储管理软件能动态地选择有效链接，以保持存储设备的高可用性。

　　但这种需要驱动支持的管理软件却要受到虚拟平台的限制，比如当前的VMware ESX Server，它就不容许在该平台下安装存储厂商提供的驱动，因此也就无法实现动态多路径功能。但如果换成VMware Server或Microsoft Virtual Server这种依赖操作系统的平台，那么OEM驱动的安装自然一帆风顺，功能的实现自然顺理成章。

　　完成了虚拟化的灾难恢复机制的介绍，接下来的内容则为架构自动化的优势和需求，然后就是市场上一些虚拟机自动化配置工具的介绍。

　　虚拟机的蔓生现象

　　最开始，服务器虚拟化的目的是为了控制数量增多、日益蔓延的服务器，使之成为一个整体而降低成本。但有些用户在使用后反而产生了相反的结果。

　　由于在虚拟数据中心创建一台新服务器的成本大大降低，以往需要花费数周甚至数月的事情如今仅需几小时甚至几分钟。唯一的限制仅在于物理资源的可用以及微软的授权价格，不过后一条如果是大公司的话根本不成问题，通常这些公司都与微软有大批量授权协议。

　　新服务器前所未有的快捷、多层架构建立的容易这些都让IT管理者感到幸福，对应用程序的安全隔离和测试这些传统环境下很难采取的措施都被首先考虑实施了，但与之同时的是IT管理者对所拥有物理资源的过高估计。

　　大公司对于部门需要新资源的要求向来不吝啬，但对于虚拟化下资源的分配使用有一套完整的规范制度，IT管理者有义务跟踪调查资源的使用情况，以确认使用者的身份以及资源的是否真正利用起来。

　　但对于小公司，可能就没有相关的资源使用制度，也可能不具备这样的操作技能，虚拟化的采用仅仅可能只是为了提高系统运行速度。短期内，不受限制的创建虚拟机可能对系统影响不大。但长此以往，虚拟机蔓生的现象对系统造成了沉重的负担，甚至可能超出了资源能承受的范围。

　　当然这也不无原因：首先，可能是新虚拟机创立者对系统整体框架没有大致的了解，不知道物理主机究竟能承载多少虚拟机，也不知道多少的负载才是最合适的，因此就造成了这种麻木地扩建；另一方面，也可能是管理者为了实现高合并率的规划，而不得不做出性能上的牺牲。

　　虚拟机的创建虽然简单，但我们应该要看到创建背后的问题。如果不注意，就可能会产生虚拟机蔓生现象；如果不注意，就会给数据中心带来安全的隐患。

　　自动化操作的需求

　　数据中心规模的扩大，面临的最大问题是如何放置众多的虚拟机，正如前面多次提到，在给定的物理资源下，该如何将虚拟机正确分配到各物理机，以求性能达到最优化。

　　选择虚拟机的加载主机的标准是看主机的空闲资源和当前负载状况。这种虚拟机分配如果完全人工操作，工作量将是不可想象的，因此就有了性能规划工具的引入。

　　而数据中心每天都在重复着这种平衡负载的虚拟机分配工作，一来是操作很耗时；二来，现在的虚拟环境处于一种流体状态，虚拟机不断地根据负载在主机间流动。因此现在看起来追求的最佳化分配仅仅是个相对的概念，瞬息万变的环境让人很难真正找到一个最佳点。

　　另一个问题就是在大型的虚拟底层构造中，需要根据用户具体要求对部署的虚拟机进行定制。

　　当前的部署总是局限在结构功能单一的虚拟机，这不可能满足所有用户的要求。大型的电子商务网站的虚拟机就需要多层次的配置，前端的web服务器，后台的数据库，还有自动监控负载和效率、处理客端的服务器。

　　所以，统一的底层虚拟构造应该进行细化，可以根据需要建立特殊的网络拓扑、访问认证机制等。不管是IT管理员还是公司用户，都应该记住改变默认的设定，进行用户专用化改造以适应具体需要。

　　初现的市场

　　由于虚拟机自动配置工具面临的前面提到的种种困难，因此市场上的产品并不是很多。

　　Akimbi的产品Slingshot在市场很有竞争力，VMware在2006年收购了该公司，并有意进一步开发Slingshot，集成到ESX Server和VirtualCenter产品中去。这对于熟悉了VMware环境的用户来说，还是有相当的吸引力的，毕竟还是熟悉的环境，但增加了更有用的功能。

　　另一方面，IT管理员还是希望所用的虚拟机配置工具能够跨平台，这样创立的虚拟测试台能够在相同硬件条件下、不同虚拟平台上同时进行应用程序测试工作，大大缩短了时间。

　　Surgient的产品(VQMS/VTMS/VMDS)和VMLogix的LabManager在这方面脱颖而出，皆能同时支持VMware和微软平台，不久的将来Xen也会在支持之列。

　　以上的产品都主要是用于应用程序测试，因此也被称为“虚拟实验室管理”。当然虚拟机自动配置工具还有其他很多性能，比如多层次部署、增强型设置克隆的定制、物理资源的规划等。