灾难恢复方案：虚拟化可帮忙

虚拟化彻底改变了我们在数据中心部署应用的方式，并延伸到了灾难恢复。

以前，配置过程要花几周甚至几个月的时间，如今却转变为几分钟内搞定的自动化任务。虚拟化具备一些能提供敏捷性、灵活性和更好弹性的特点，包括snapshots（快照）、vMotion和HA/FT（高可用性/容错性）。

与此同时，灾难恢复也转变了。在物理服务器环境下，意外中断的恢复过程需要失效备援到主要环境或完全相同的硬件和操作系统的复制，以还原备份。

据称，虚拟化能废除上述恢复过程的很多步骤，使灾难恢复的部署变的更容易更简单。但是能简化到什么程度呢？

本文中，我们会调查灾难恢复计划和配置过程的每一步，以及虚拟化可以帮助简化到什么程度？

物理 PK. 虚拟

服务器虚拟化是一个很棒的工具，能够加强和简化应用部署的工作量。硬件使用不足——典型是单一应用对应一个操作系统实例，把物理资产集中成更高效的封装时，虚拟化为服务器提供隔离性和管理效益。

虚拟服务器综合了代表物理磁盘的虚拟磁盘文件，处理器、存储器和其他附件的配置信息。这使得虚拟服务器——或者虚拟机器（VM）——非常轻便，也允许虚拟 化提供一些能力，诸如高可用性（在出现硬件故障时将VM移到另一台服务器上）和容错性（如果硬件出问题，运行能掌管服务的VM重映像），而无需大量附加硬 件或者复杂的配置。

将VM看成一套文件的能力意味着备份和恢复也一样简化了。运行VM的硬件各种各样（无限制），管理程序因此承担了翻译物理地址到虚拟设备上的任务。这表示VM和封装在它内部的工作量比以往更加轻便。

灾难恢复计划和执行

我们来看看典型灾难复原方案的关键元素，以及看清虚拟化技术可以在哪里帮上忙。

灾难恢复计划的第一步，是查看商业需求，以及将应用与服务水平目标匹配。在灾难恢复领域，测量标准是复原时间目标（RTO）和修复点目标（RPO）。

RTO指定应用在服务必须恢复前可以忍受的总故障时间。任务严苛的应用有很低的，甚至为零的RTO（表示服务必须一直连续）。

RPO描述了应用可以忍受的数据损失总量。该指标有可能为零（比如，没有数据损失）或者以分钟或小时来衡量。一些无核app（比如那些用来报告的）可能可以忍受的RPO为24小时，尤其是数据可以从别的来源产生时。

此时，与技术的选择没有关系。开展商业影响/风险分析是基于人们对商业需求的评估。然而，随着我们在灾难复原计划过程中更进一步，我们会发现技术选择出现了。接下来的问题，变成了虚拟化到底能在哪里帮助灾难复原。

灾难恢复风险评估

下一步，灾难恢复计划过程要获取从影响分析中得到的服务要求，并且提出风险评估。

对于每个应用或者系统，我们可以将RTO/RPO要求对应到可能的风险，评估那些风险的可能性，并开始为每项风险制定出减轻和修复策略。下面的表格展示了一些例子：

此时此刻，我们可以看到，要在物理和虚拟基础设施中做出选择。

第一个例子显示，基于物理硬件的集群解决方案如何用来履行服务要求的。尽管不能接受数据损失，应用可以忍受高达30分钟的中断。

可用以下两种方式实现。一种是失效备援的镜像物理设施，价格不菲。另一种是拥有高可用性的虚拟设施，比如VMware HA。该功能可使在备用硬件上的应用自动重启，运用共享存储基础框架以确保RPO为零。

第二个例子展示了一个企业的网站需要24*7小时不停机。这种情况下，应用以静态数据为基础，在一个或者更多的访问同一数据池的网络服务器实例上实现。如果任一服务器停止，负载均衡软件会重定向通信路线到一个新服务器上。

虚拟化通过单独的VM提供网络服务器实例，就可以应用在上述场景中。如果一种硬件故障总是发生，新的网络服务器就可以从模板中部署并加入到负载均衡列表中，而无需更多复杂的HA或者集群软件。该方案在跨地域的场景中也可以实现。

第三个例子凸显了传统应用如何被传统的或者基于VM的备份所保护。相比使用物理基础架构，虚拟方案提供更快的备份和还原能力。

建立灾难恢复方案

现在，我们已经识别了应用和量化了相应的风险。我们开始完整制定出减轻和修复场景，作为应用和基础设施设计的一部分。与纯粹的物理服务器运行相比，虚拟化提供了一些独特的性质，可以帮助达到业务连续性。包括：

基于模板化的应用工作负荷，有能力在几分钟内加速|VM实例。

通过容错性和高可用性的应用恢复，可以消除对复杂修复措施的需要，包括在大城市。

VM失效备援的一体化和自动化可适用于偏远地区，使用工具有VMware’s Site Recovery Manager。

硬件抽象化允许VM在不同的硬件平台上修复。与生产现场相比较，硬件平台可能是高低不一的规格或者混合的。

VM/服务器备份基于来自下面存储器的文件映象复制。

失效备援与应用的集成，通过使用基于主机的工具，避免崩溃一致性副本和应用恢复的更高可能性。

通过工具，比如vMotion，避免灾难。

所有这些特征允许应用以比典型物理服务器更高效的方式在基础设施上部署。

测试和验证

设计之后，需要测试和验证灾难复原计划。是否使用虚拟基础架构，方案必须包括验证应用有能力在灾难复原模式运行，并且以每个系统服务水平目标（RPO/RTO）的形式恢复正常运行。

虚拟化不能避免测试（和确认基础设施每一部分配置正确），但它可以使测试过程实现起来更简单。比如，提出在灾难复原现场的VM，测试功能和数据完整性，而 保持VM的隔离性，以避免与正运转的生产现场一起崩溃。无需影响灾难恢复过程就可实现。反之，对物理服务器的测试会让生产服务处于危险中，直到测试结束。

总结

虚拟化以更高效和简单的方式，提供了大量执行灾难复原的机会。然而，正如我们所看到的，基于商业需求，它不能代替深思熟虑、详细说明的综合灾难复原方案。 随着技术持续进化，灾难复原方案需要回顾和更新，以反映当前的虚拟化能力，从而变成一份“活的”文档，以确保不间断的业务持续性。