OpenStack灾难恢复：专业知识是应对未知的最佳盟友

Mark Do 7 小时前暂无评论阅读 56 次

有些支持案例是常规操作，但有些则会将你带离既定路径，进入一片只有深厚开源专业知识才能指引前方的未知领域。本系列聚焦Canonical支持团队如何应对意外情况：那些标准手册无法覆盖的场景，支持工程师需与客户实时协作寻找解决方案。

某客户的OpenStack生产环境在夜间突然从完全正常运行转为无法分配、扩展或管理任何资源。

发生了什么

OpenStack并非单一软件，而是一个协调架构，由管理计算、网络、身份、存储等核心基础设施组件的服务组成，这些服务依赖一个共享数据库，该数据库记录着云的当前状态：哪些资源在运行、位置及配置方式。

在例行操作中，一个针对控制平面下数据库集群的操作，让 operators 管理云、分配资源、迁移或扩展的能力在几秒内消失。

支持案例当天即被开启。

第一个问题：备份

团队首先提出的问题是：最后一次备份是什么时候做的？是否曾验证过恢复过程？现有备份已足够陈旧，无法反映云环境的当前状态——虚拟机已迁移、资源已重新分配、凭据也已轮换。

直接恢复备份可能导致控制平面描述一个不再存在的云环境，这排除了最简单的路径，只能选择更难的方案：围绕实时运行的工作负载重建控制平面，同时不中断这些工作负载。

这值得注意，因为即使在成熟的运营中，这也是一个常见漏洞。备份计划仅能确认数据正在被捕获，却无法保证恢复过程有效，或恢复后的状态在需要时仍与实际一致。两者必须同步验证，验证频率需与环境的实际变化速度相匹配。

未崩溃的部分

在采取任何操作前，指定的支持工程师检查了仍在运行的部分，发现实际上没有任何资源宕机。没有工作负载丢失，业务持续运行。丢失的只是管理云的能力：无法新增分配、迁移或扩展。

OpenStack的架构有一个值得理解的特性：控制平面管理云的状态，数据平面负责实际工作（计算、网络、存储）。这些层设计上解耦，正是为了让管理基础设施的故障不会导致依赖它的工作负载中断。这是OpenStack能用于大规模生产环境的关键优势之一，而此次案例中，这一优势发挥了作用。

这一保证只有在你了解其存在并懂得如何利用它来制定恢复策略时才有用。早期识别这一点，让这场开放式危机在第一小时内转变为一个范围明确的、可解决的工程问题。

恢复过程

确认现有工作负载安全后，团队开始重建控制平面。由于从头重建数据库属于罕见边缘案例，标准恢复文档仅覆盖损坏或降级状态。因此，工程师为该特定场景开发并验证了一套新流程：重建数据库集群，按控制顺序恢复可用数据，然后逐一将每个OpenStack服务重新连接到新数据库。

最后一部分是主要工作。每个服务与数据库的关联关系需单独重新建立，备份状态与云实际状态之间的差距需手动调和——包括虚拟机运行良好但数据库因信息过时报告其已停止或出错的情况。

Canonical工程师与客户团队经过数天的紧密持续协作，最终云环境完全恢复运行，零工作负载丢失。

案例的启示

从该案例中，有两点值得借鉴。

备份验证需与备份计划同等严谨。这并非假设性漏洞。Cockroach Labs的《2025年韧性状况调查》显示，62%的组织未进行定期备份恢复练习，71%未进行任何故障转移测试，尽管几乎所有组织都在纸上运行某种形式的韧性测试。此外，Acronis 2026年第一季度在其灾难恢复平台上的数据显示，85%的恢复服务器完全关闭了RPO（恢复点目标）监控，意味着没有自动检查备份是否足够新到有用，仅18%的备份规则配置为每月测试。

模式是一致的：有备份政策的组织很常见，但证明该政策在实际条件下有效则不然。这种差距往往在需要时才显现，这正是为什么测试过的、定时执行的端到端恢复流程应与RTO（恢复时间目标）和RPO目标一起出现在韧性清单上，而非被视为备份任务显示绿色后的理所当然。

在如此互联的系统中，架构知识是恢复得以实现的基础。知道OpenStack的控制平面与数据平面分离，是制定恢复策略的前提。早期认识到这一点，将危机转变为可解决的问题，正是专业知识发挥作用的地方。

关注微信号：智享开源 ，及时了解更新信息。

原文链接：https://ubuntu.com//blog/support-restores-openstack