OpenStack 云平台中如何进行灾难恢复

IT 基础设施的故障会出现在很多层面上，例如某台服务器或磁盘，甚至整个数据中心在面对灾难事故（例如地震、洪水、断电等）后均可能出现故障。如果由于一些大范围灾难导致整个数据中心故障，我们会使用“灾难恢复”所定义的措施，确保应用可以在备份数据中心内继续运行，同时将可能的中断降至最低。

为保护数据中心内存储的数据，必须在数据中心遇到故障前制定妥善的灾难恢复规划。

环境

假设你有一个主数据中心和一个备份数据中心。每个数据中心都包含使用 OpenStack 云管理的物理和虚拟资源，并通过虚拟机、网络连接（包括私有子网）、区块设备 (Block device) 等资源以集合的方式定义了工作负载，所有这一切都使用标准的 OpenStack 组件（Nova、Neutron、Cinder 等）进行管理。

通常来说，一个工作负载及其所有依存组件都可以使用 Heat Orchestration Template (HOT) 来定义。这样做目的在于对主数据中心内运行的工作负载创建副本，以便在主数据中心遭遇故障后在备份数据中心运行这个工作负载。

解决方案概况

这种方案的主要意图在于，在备份数据中心内为工作负载的 Heat 模板以及所需的全部资源创建副本。Heat 模板包含相关作业的虚拟机，将虚拟机连接在一起的网络拓扑，以及虚拟机所使用的区块设备。在主数据中心遭遇故障之前，恢复所需的全部必要信息在备份数据中心必须处于可用状态。

例如，为了能在备份数据中心运行虚拟机，我们需要准备该虚拟机运行所需的映像。因此除了工作负载的 Heat 模板，还需要存储该作业中虚拟机的映像，并使其在备份数据中心内可用。如果作业同时还包含数据卷，那么我们或者需要偶尔对该数据卷创建快照并将其发送至备份数据中心，或者需要对该卷进行某种形式的远程复制，这样才能在恢复后通过备份数据中心访问该卷中的数据。

这些工作可以通过 Dragon 实现

我们实施了一种名为 Dragon 的框架，管理员可以借助该框架定义能够为工作负载提供保护的工作负载策略。对于每个工作负载策略，管理员可以对各种资源（例如虚拟机、卷）进行分组，并提供统一的保护。每个工作负载策略可独立触发，以执行该工作负载策略所涉及资源的保护操作。

每次触发一条策略后，会生成一个 Heat 模板以记录被保护资源之间的关系，并会针对这些资源执行相关操作（例如创建快照）。所有这些相关内容（Heat 模板、快照等）会存储在一个可被备份数据中心访问的 Swift 对象存储容器中。容器会添加工作负载策略名称和时间戳组成的标签。

一旦主数据中心故障，即可在备份数据中心启动恢复操作。随后将从该工作负载策略的 Swift 容器中提取 Heat 模板和相关数据，并对 Heat 模板进行一些调整，使其可以在备份数据中心内运行，接下来便可在备份数据中心内启动该工作负载。

针对具体的受保护资源，可能需要执行不同的操作。例如，对于虚拟机来说，可能只需要保存克隆后虚拟机的原始映像就够了。在某些情况下，随着时间的流逝，虚拟机映像可能会逐渐进行大量的定制，因此可能就要在执行过定制操作后重新为映像创建快照。对于数据卷，可能需要对卷执行一次创建快照的操作。但对于持续复制的卷，就无需创建快照。

Dragon 可供您为多种类型的资源定义多个操作。管理员可以在受保护的工作负载策略中选择针对每种资源所需执行的操作。例如对于虚拟机，我们提供了一个对克隆后的虚拟机保存原始映像的操作，并提供了一个在策略被触发时为虚拟机的映像创建独立快照的操作。Dragon 框架是可扩展的，因此您可以针对不同资源定义并实施各种新操作。

可以保护哪些类型的工作负载？

在上述解决方案中，我们并不试图保存工作负载的内存状态，而是会假设工作负载可以在无需恢复内存状态的情况下在备份数据中心内重启动并继续运行。对于绝大部分云服务来说，这种假设都是合理的。如果涉及数据卷，并且使用了快照保护操作，随后恢复后的工作负载便可通过数据快照继续运行，但在最新快照创建完成后，针对主数据中心内数据所进行的任何更新均会丢失。如果数据卷可以持续复制到备份站点，即可进一步降低丢失的数据总量。

致谢

该方案的部分工作成果得到了 ORBIT 项目EU Grant ICT FP7-609828 的资助。

阅读英文原文： How disaster recovery works in an OpenStack cloud

感谢陈兴璐对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。