备份机制

    介绍完虚拟化环境下资源管理面临的新问题以及新的解决方案后，接下来的部分将重点介绍虚拟平台的安全性举措——灾难恢复机制的建立，包括数据备份机制、故障转移机制以及集群机制。首先介绍备份机制。

    虚拟数据中心的备份方法可以沿袭物理机上的做法，在每个客机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，虽然我们可能只是想要备份其中的一个。

    下一部分将继续介绍故障转移机制和集群机制，接着会对虚拟机以及整个架构的自动化管理做一些探讨。