遗留 nova-network 到 OpenStack Networking (neutron)

OpenStack 中存在两种网络模型。第一种称为遗留网络 (nova-network),它是一个嵌入在 Compute 项目 (nova) 中的子进程。该模型存在一些限制,例如创建复杂的网络拓扑、将其后端实现扩展到特定供应商的技术以及提供项目特定的网络元素。这些限制是 OpenStack Networking (neutron) 模型被创建的主要原因。

本节描述了将基于遗留网络模型的云迁移到 OpenStack Networking 模型的过程。此过程需要对计算和网络进行额外的更改,以支持迁移。本文档描述了整体过程以及 Networking 和 Compute 中所需的功能。

目前的设计过程是一种最小可行迁移,目标是弃用并最终删除遗留网络。Compute 和 Networking 团队都认为,从遗留网络到 OpenStack Networking (neutron) 的一键迁移过程不是在未来弃用和删除遗留网络的必要要求。本节包括一个过程和工具,旨在解决简单的用例迁移。

鼓励用户使用这些工具,测试它们,提供反馈,然后扩展功能集以适应他们自己的部署;那些不参与此过程,打算等待更适合其用例的路径的部署者,很可能会失望。

影响和限制

从遗留 nova-network 网络服务到 OpenStack Networking (neutron) 的迁移过程对云的运行状态有一些限制和影响。了解这些限制和影响对于决定此过程是否适合您的云和所有用户至关重要。

管理影响

Networking REST API 在迁移完成后之前仅为只读的。在迁移期间,Networking REST API 仅对 nova-api 可读写,并且 Networking 的更改只能通过 nova-api 允许。

Compute REST API 在整个过程中可用,尽管在数据库迁移期间有一段时间会变为只读。Networking REST API 需要向 nova-api 暴露所有必要的细节,以便重建先前存储在遗留网络数据库中的信息。

Compute 需要在数据模型中进行每个 hypervisor 的“has_transitioned”布尔值更改,用于在迁移过程中使用。过程完成后不再需要此标志。

操作影响

为了支持广泛的部署选项,此处描述的迁移过程需要对 hypervisor 进行滚动重启。特定 hypervisor 重启的速率和时间由操作员控制。

迁移可以暂停,甚至长时间暂停(例如,在测试或调查问题时),一些 hypervisor 使用遗留网络,而另一些 hypervisor 使用 Networking,并且 Compute API 仍然完全可用。在此阶段的迁移期间,可以使单个 hypervisor 回滚到遗留网络,但这需要额外的重启。

为了支持最广泛的部署者需求,此处描述的过程易于自动化,但尚未自动化。部署者应预计需要执行多个手动步骤或编写一些简单的脚本才能执行此迁移。

性能影响

在迁移期间,nova-network API 调用将通过额外的内部转换到 Networking 调用。与迁移前或迁移后的 API 相比,这将具有不同的且可能较差的性能特征。

迁移过程概述

  1. 以预期的最终配置启动 neutron-server,但 REST API 仅允许 nova-api 可读写。

  2. 使 Compute REST API 变为只读。

  3. 运行一个 DB 转储/恢复工具,该工具创建 Networking 数据结构,以表示当前的遗留网络配置。

  4. 启用一个 nova-api 代理,该代理通过 Networking REST API 从 Networking 信息重新创建内部 Compute 对象。

  5. 使 Compute REST API 变为可读写。这意味着遗留网络 DB 现在未被使用,新的更改现在存储在 Networking DB 中,并且无法在没有丢失这些新更改的情况下从此处回滚。

注意

此时,Networking DB 是事实的来源,但 nova-api 是唯一的公共可读写 API。

接下来,您需要迁移每个 hypervisor。为此,请按照以下步骤操作

  1. 禁用 hypervisor。如果支持,现在是进行实时迁移或撤离计算节点的好时机。

  2. 禁用 nova-compute。

  3. 启用 Networking agent。

  4. 在 Compute hypervisor 数据库/配置中设置“has_transitioned”标志。

  5. 重新启动 hypervisor(或如果可用,运行“智能”实时转换工具)。

  6. 重新启用 hypervisor。

此时,所有计算节点都已迁移,但它们仍然使用 nova-api API 和 Compute 网关。最后,通过以下步骤启用 OpenStack Networking

  1. 启动 Networking (l3) 节点。新的路由器将具有与旧 Compute 网关相同的 MAC+IP,因此可以进行某种立即切换,但对于 NAT 等有状态连接问题而言。

  2. 使 Networking API 可读写并禁用遗留网络。

迁移完成!