【IT168 专稿】前两部分已经介绍了如何选定适于虚拟化的物理机；根据负载状况的资源分配；将物理资源迁移到虚拟环境下。接下来，我们将转向虚拟架构下的复杂管理，包括对物理和虚拟资源可用性、使用方法和访问的命令管制；灾难恢复方案的部署；后备新虚拟机的预立以及其他自动化操作任务；对数据中心必需的监测和报告。
构建虚拟化平台实战全解析（四）
构建虚拟化平台实战全解析（五）
今天的虚拟化依然非常年轻，有许多不成熟的工具和没有解决的难题，特别是性能分析和故障发现解决方案的空缺，我们会发现实现上述的功能有多么不易。
资源流动性对管理的挑战
IT管理员最大的职责也许就是管理好现有的资源，管理内容有记录物理机的使用、操作并保证系统的可用性，还有评估现有的资源是否满足需要，故障发生时必须迅速做出反应等等。
这些管理操作即使是小规模的服务器环境中已是不轻松，如果换到虚拟架构下将变得更加繁琐复杂。因为有了大量新的问题产生，比如虚拟机高效可控的部署、物理资源合理的分配，还有牵涉到费用分担的问题。
虚拟机易于创立且独立于底层硬件的本性催生了流动运算的思想，使得很难确切知道虚拟机的位置。这导致了所谓的“虚拟机蔓生”（由于灵活性大量创建虚拟机带来的系统复杂性）问题，因此为避免此问题的发生，必须应用虚拟化管理工具建立可靠的保护机制，主要是对系统用户创立虚拟机加以限制，监控系统且上报未使用的资源。
这种方案已经在大部分虚拟平台上得到了应用，不过虽然用户对虚拟底层的访问受到限制，管理员还是无法精确算出虚拟数据中心的效率。
创建完虚拟机后，虚拟机环境的管理员不得不面对将虚拟机置于何处才是最好的问题。前面在资源划分中提到了要根据服务器的负载，将虚拟机合理分配到各服务器，而避免过载或闲赋。这就是管理工具的职责所在了。
微软的Virtual Machine Manager就有一个对现存物理机评分的系统，根据它评定物理服务器的星级，管理程序就能很轻易地为新的虚拟机找到最合适的一个。
但在某些情况下，甚至于虚拟机的创建都不是件容易的事情。比如大型ISP在虚拟化环境下需要在数秒钟内创建成百上千的虚拟机以提供足够多的服务，这个工作的顺利实现非得借助于智能工具不可。在这种特殊情况下，与其花大把金钱换来不够灵活的解决方案，不如自身设计符合需要的解决方案，现在许多公司就是这么做的。
因此，虚拟化供应商也适时推出软件开发包（SDK）以满足用户自身定制的需要。VMware在这方面依靠开放的可编程接口和广泛的支持性，所以在市场上取得了很好的成绩。
最后一个但绝非最小的一个，就是许多IT管理者不得不面对虚拟化环境下新出现的计费问题。在一个中等规模的企业中，也许所有部门机器都已经迁移到了虚拟环境下。由于虚拟环境的高度集中性，各部门使用资源的比率无法区分出。但各部分又都有各自的成本中心，因此对于底层硬件费用的分担比较困难。
即使成本是统一规划的，但在资源的使用控制和配给上，比如谁可以使用物理资源，又能申请多少等，这一点是很难做到的。
这些问题目前看来并不普遍，但相信数年之内必会因为虚拟化的普及而怨声四起。IBM推出的Tivoli中的一个组件Usage and Accounting Manager可以帮助用户解决这个困扰。
更多的问题随着大型公司多个虚拟化平台的采用会愈发凸现。由于各部门享有高度自治，因此在选用的平台难免有差别。所以IT管理员必须要做好同时管理VMware ESX server 和 Xen的准备，具有跨平台的管理工具势在必行。
最流行的方案有IBM, Cassatt, BMC Software, Enomaly 和Scalent的产品，也有一些新的竞争者，如Opsware。
多平台的管理支持意味着IT管理者无需了解创建虚拟机的不同技术和过程。这种管理工具的应用可以有效地管理各平台下的应用程序，甚至于应用程序在各不同平台下的迁移，不过这项功能需要前面提及的专门P2V工具的支持才能实现。
介绍完虚拟化环境下资源管理面临的新问题以及新的解决方案后，接下来的部分将重点介绍虚拟平台的安全性举措——灾难恢复机制的建立，包括数据备份机制、故障转移机制以及集群机制。首先介绍备份机制。
虚拟数据中心的备份方法可以沿袭物理机上的做法，在每个客机OS上安装一个备份软件，它能够把数据、分区甚至整个虚拟硬盘拷贝到其他地方去。
这种方法在物理机上并无瑕疵，然而转到虚拟环境下却难掩问题。由于主机OS中的每个虚拟机是共用同一个I/O通道，因此当它们备份工具的同时运行，即是不可避免地遭遇I/O瓶颈的开始。
为避免此现象的发生，管理程序应该谨慎安排备份计划，合理设置备份间隔时间段，不至于各客机OS备份时间的重叠。
然而又有不幸（我恨“不幸的是”），想一想每个虚拟机要备份的数据至少有3GB，如果再加上一些应用程序之类的，上到10-20GB很是常见，这样一来备份一个虚拟机就得耗费个数小时。如果有个上百台虚拟机需要备份，这种依时有序的备份法如何让人消受的了。
因此主机级的备份方式应运而生，相较客机备份方式，确实是快了许多。虚拟机在主机OS看来不过一个自封装的文件，显示出来无外是电子表格和图像的组合。初学者由此想当然的以为备份过程很简单，但实际却出乎意料的困难重重。
首先，虚拟机文件的访问被某个进程或某个程序所限制，必须用特别的方法才能访问文件，保存状态点快照（通常称之为snapshot），以及进行备份工作。因此备份软件必须先能访问虚拟机文件才能进行下面的步骤，有时文件访问的实现需要借助于主机OS。比如微软在Windows Server 2003中提供了一项名为Volume Shadow Service (VSS)的特性，此项特性能为第三方解决方案调用以实现快照保存。
解决访问的问题后，另一个问题又不期而遇：如何实现备份的实时进行，即备份时并不影响正常客机OS的运行。但快照的保存常常导致虚拟机的停滞和中断，这有可能损坏客机OS的文件系统。尽管如此，实时备份还是有很重要的意义。Vizioncore的esxRanger能将VMware ESX Server平台下的虚拟机自动有效地进行实时备份，因此应用很广泛。
微软即将推出的Virtual Server 2005 SP1打算支持实时备份，但却不考虑在其专业的备份工具Microsoft Backup中添加此项功能。所以可以看出大部分虚拟化厂商推荐采用的备份方法还是挂起或是干脆关闭虚拟机，然后进行备份工作。
虽然这种传统的挂机备份法无法满足高可用性的要求，但在没有更好更成熟的备份方法出来之前，也只能是无奈为之。
撇开实时备份的问题不提，再说说主机级备份依旧会给I/O通道造成压力。为了彻底解决这个I/O瓶颈问题，我们把目光从主机投向存储设备，在那对虚拟机文件的操作并不会直接影响到整个虚拟化平台。
VMware率先推出了采用此种思路的Consolidated Backup(VCB)，但它只能支持ESX Server虚拟化平台，且只能为真正的第三方备份工具起到一个中介作用，本身并不具有备份功能。
这种存储级的备份方案意味着SAN管理软件的应用以及LUNs（Logical Unit Numbers,逻辑单元数量）克隆的调用，虽然在真正意义上消除了I/O瓶颈的影响，但由于存储设备对于LUNs格式识别的限制，导致了备份的很难实现。
存储管理软件负责LUN格式的识别，同时也决定了支持哪种文件系统。如果能识别NTFS格式的LUNs，那么就能备份VMware Server平台上的Windows虚拟机；如果不能识别VMFS格式，则VMware ESX Serve平台上Windows虚拟机的备份则无从谈起。
如果LUN格式不能被识别，或是没有任何增强型的存储管理工具，是不是备份就一筹莫展了呢？好在天无绝人之路，我们还可以整个克隆包含多个虚拟机的LUN，虽然我们可能只是想要备份其中的一个。
下一部分将继续介绍故障转移机制和集群机制，接着会对虚拟机以及整个架构的自动化管理做一些探讨。
