通过微软Hyper-V进行灾难恢复规划

狙神

任何一个参与过灾难恢复训练的人对从无到有重建一个基础设施要经历的痛苦都很熟悉。重装及修复应用程序服务器，让支助性业务重现生机以及数据损坏或者丢失的可能性，一点点的细微差别都可能导致失败。

由于虚拟化可以让您使用已经拥有的系统——在生产中运行并且正常工作的系统，因此消除了建立一个新生产系统的不确定性。

尽管VMware的灾难恢复工具工作得相当好，但如果您部署了Hyper-V，并希望在灾难恢复计划中使用微软的虚拟机？

这也是可能的，如果您采取合适的步骤去实施行动计划。

了解您的灾难恢复方法

灾难恢复计划的第一步是搞清楚您的环境需求。是否您的组织有一个很短的恢复点目标(Recovery Point Objective RPO)——您的数据需要恢复到的恢复点——或者是否您上次的备份能满足RPO的要求？

另外，您的恢复时间目标(Recovery Time Objective RTO) ——重新上线所花费的时间 ——会影响到您对基础设备和专门软件的需求。最有可能的是，您已经将您的应用程序“分层次”为多个恢复类，例如，第一层次为处理重要任务的服务器，可有可无的则为之下的第三层、第四层。

Hyper-V可以在所有的这些场景中得到支持，但这些场景里面的每一个以及它们的花销都是非常不同的。

非关键服务器和冷站(后备站)

让我们从最简单的服务器开始——那些被认为不重要的或者有很长RPO或RTO的服务器。同时也包含一个基于冷站场景的计划，在该场景中，您必须从头开始重建服务器和网络，并会依赖于冷站点恢复位置上的备份。

Hyper-V服务器可以通过一个主机服务器备份或者VM备份来进行恢复。恢复VM备份，除了主机被恢复后，所有的虚拟硬盘(VHD)以及VM设置都会恢复到您之前备份时的样子之外，和正常的机器恢复很类似。所有的VM都必须使用集成服务(Integration Services)，以便可以访问卷影拷贝服务(Volume Shadow Copy Service VSS)，并使虚拟硬盘以一个一致的状态来进行恢复。特定的应用程序，如微软Exchange，因为可能会导致数据库不一致，而不支持这种类型的备份。您可能需要使用可靠的恢复方法来处理这些应用程序。(请注意，即使是在恢复主机，您也需要重新配置您的网络，所以有良好的文件是很必要的)

您的灾难恢复计划需要有一套用于转移备份主机或者VM的有效脚本。确定如何去进行恢复，并在主机启动前确定其存放的位置是很重要的。做完之后才去决定只会导致混乱和恢复的失败。

关键服务器和积极的恢复目标

对于必须开启，而且要保持开启状态的应用程序，在多个地方，转为集群或者故障转移负载平衡，是对要跨地域复制存储的一个解决办法。在存储区域网络(SAN)间复制是为了进行异地存储，这种异地存储可能会成为一个完整的远程数据中心。当灾难发生时，异地存储会用于主机的恢复。

通过使用Hyper-V虚拟机，可以不像标准的物理服务器，使被复制后的存储区域网络中可以包含虚拟硬盘。这样就可以进行故障转移。简单地将复制后的存储区域网络上线，并以很小的数据损失，将其中的虚拟硬盘加到主机配置中。再提醒一下，操作必须要小心，因为这会让某些应用程序处于一个不稳定的状态，并可能会需要进行真正的恢复或者用别的恢复方法来进行处理。

在Hyper-V R2中，可以通过GeoClusters使用集群共享卷(Cluster Shared Volumes CSV)。这让您可以建立一个Hyper-V集群并让其横跨多个位置。虽然这样做的好处是可以进行自动化的故障转移，其缺点是太复杂并且需要特定的硬件。换句话说，您需要用一个服务器和存储区域网络设备匹配的温备份站点(warm site)来做故障转移。这个技术的关键是存储是跨站点复制的。可是再次提醒，微软没有为这个存储问题提供解决方案。幸运的是，SteelEye Technology、EMC以及其它厂商的产品解决了这个问题。

未来的云选项

微软也许会作为支持无站灾难恢复形式代表的Windows Azure，很可能是即将可用的另外一个选择之一。

虽然现在已经可以将虚拟硬盘移到Azure云里，其它的一些问题，例如私有网络和恢复时间仍在发展中。在未来，尽管您可能不能对整个基础设施进行复制，但时间会证明，Windows Azure对像网站和SQL Server数据库这样的数据中心的特定设备是有价值的。

总的来说，尽管微软Hyper-V的灾难恢复解决方案还没有达到VMware的级别，但不要忘了，在VMware的恢复解决方案中也有相当多的脚本。灾难恢复——即使是一个低成本的计划——可以在少量的测试和对您需求很好理解的基础上开发出来。但前提是，要熟悉您可以有哪些选择，因为知道如何管理现有的Hyper-V环境，并基于RTO和RPO目标做出正确的规划对成功的恢复是至关重要的。