Neutron升级规划

本文主要是介绍Neutron升级规划，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

本文档的大部分内容讨论通过Neutron agents实现的升级相关考虑。期望于每个Neutron插件提供其自身的特定于后端选择的升级讨论文档。例如，OVN不使用Neutron agent，但是确实有本地控制器运行在每个计算节点。OVS支持滚动升级，但是，关于如何工作的文档应包含在networking-ovn（OVN Neutron插件）中。

升级规划

Neutron支持两种通用的升级场景:

关闭所有的服务，升级代码，之后重启所有服务.
基于运营者的服务窗口，逐渐的升级服务.

后者时升级OpenStack云的首选，因为其允许更细的控制和更少的服务关闭时间。此场景通过称为“滚动升级”。

滚动升级 Rolling upgrade

滚动升级意味着在某段时间内，不同代码版本的服务在同时允许，并在云中交互。这对软件施加了多个限制.

老版本服务应当能与新服务通信.
老版本服务不应要求数据库具有老的schema (否则要求新schema的新版本服务将不能工作).

更多关于OpenStack滚动升级的信息可参考：https://governance.openstack.org/tc/reference/tags/assert_supports-rolling-upgrade.html.

Neutron通过以下方式实现这些要求:

如果Neutron后端使用Neutron agents，Neutron服务端具有向后兼容的代码处理老版本消息负荷。
隔离访问数据库的当个服务 (neutron-server).

简化起见，总是假设服务升级的顺序如下所示:

首先，所有的 neutron-servers 进行升级.
之后，如果可行，升级Neutron agents.

此方法允许我们在agent一侧避免向后兼容的代码，并和其它支持滚动升级的OpenStack project保持一致(特别的, Nova)。

服务器升级

Neutron-server是非常靠前的应升级到新版本代码的组件。它也是唯一的依赖于新的数据库schema的组件。其它组件通过AMQP与云通信，并不依赖与特定的数据库状态。

数据库升级是通过alembic迁移链实现的。

数据库升级分为两个部分:

neutron-db-manage upgrade --expand
neutron-db-manage upgrade --contract

每个部分代表一个独立的alembic分支.

前一个步骤可在老的neutron-server代码运行时执行。后一个步骤要求”所有“的neutron-server实例处于关闭状态。一旦完成，neutron-servers可被重新启动。

注:
neutron-server实例的完全关闭可跳过，此依赖于是否存在挂起的未应用到数据库的contract脚本:
$ neutron-db-manage has_offline_migrations
此命令将返回是否存在挂起的contract脚本信息。.

Agents 升级

注:
如果云不使用AMQP agents为实例提供网络服务，本节不应用。此情况下，其它后端应用特定的升级指令。

一旦带有新的数据库schema和新代码的neutron-server重新启动，到了升级Neutron agents的时刻.

注意与此同时，neutron-server应能够处理云中老版本agents发送的AMQP消息。

推荐的agent升级（每个节点）顺序如下:

首先，L2 agents (openvswitch, linuxbridge, sr-iov).
其次, 所有其它 agents (L3, DHCP, Metadata, …).

agent升级顺序的原因是L2 agent通常负责连线port到其它使用的agent，所以，最好先允许其完成工作，之后继续其它的agent，这些agent将使用已经根据需要配置好的port。

每个network/compute节点可使用其自身的升级安排，独立于其它的节点。

AMQP 考虑

既然总是假设neutron-server组件在其它agent之前升级，仅前者需要处理新旧两个RPC版本。

意味着不需要代码处理属于agent的UnsupportedVersion oslo.messaging异常。

通知Notifications

对于neutron-server发给监听agent的通知，需要特殊的考虑以支持滚动升级。在此情况下，一个新的控制器发送新的负荷到老的agent上。

在我们有了适当的RPC版本固定功能，于升级过程中强制旧的负载格式（类似在其它project中的实现，如Nova）之前，我们让agents抵抗作为服务器通知中一部分的未知参数。这是通过不断地捕获那些未知的带有关键字的参数，并在agent端忽略它们；以及不在服务器端强制新的RPC入口点版本。

此方式并不理想，因为它使得RPC API不严格。这就是为什么将来应为通知考虑其它的方式。

接口签名

RPC接口由其名称、版本及其接受的参数（named）定义。没有严格的保证参数用于期待的类型或意义，因为它们被串行化了。

消息内容版本化

为了滚动升级提供更好的兼容性保证，RPC接口也应定义特定的可接受的参数格式。在OpenStack世界中，它通常使用slo.versionedobjects实现，并依赖于库为通过AMQP传递的参数定义串行化格式。

注意，Neutron还没有为其RPC接口采用oslo.versionedobjects库（QoS特性已采用）。

网络后端backends

后端软件升级不应导致任何数据平面的中断。意味着，例如，Open vSwitch L2 agent不应重置流或者重连ports；Neutron L3 agent不应删除老版本agent留下的命名空间；Neutron DHCP agent不应请求立即的DHCP租约更新；等待。

同样的考虑应用于不依赖agents的建立。意味着，比如，OpenDaylight 或 OVN 控制器不应在升级过程中断开数据平面的连通性。

升级测试

Grenade 是OpenStack设计来验证升级场景的project。

当前，仅离线（非滚动）升级场景可在Neutron gate验证。升级场景为以下步骤:

老的云使用最新的稳定发布代码建立
停止所有的服务
代码更新到要检视的补丁版本
如果需要，应用新的数据库迁移脚本
启动所有服务
使用暴力测试子集验证新的云

此场景验证在一个循环中没有配置选项名称被修改。更通用的，它验证新的云能够使用老云的配置文件运行。它也验证数据库迁移脚本是否可执行。

此场景并不验证AMQP版本兼容性。

其它projects（如Nova）具有称为“partial” Grenade工作，其中一些服务可运行老版本代码。这样的工作在Neutron gate中也需要来验证project的滚动升级。目前为止，依赖于代码检视者在补丁中发现兼容性问题。

另一个测试中的洞属于拆分迁移脚本分支。假设老版本云在从新版云扩展迁移脚本之后，可成功的运行并应用与其数据库，但是没有在gate中验证。

审阅指南

有几个升级相关的点应该由审阅者跟踪。

先说重点，对审阅者的一般建议：确保新代码不违反 global OpenStack deprecation policy 设置的要求.

现在具体来说:

配置选项:
- 不应不等待废弃周期而从代码树中删除选项（目前是一个开发周期长度），并且如果使用废弃的选项应提示废弃信息。
- 选项值不应在版本之间改变意义.
数据平面:
- agent重启不应打断数据平面（无Open vSwitch 端口重置；无网络命名空间删除；无设备名称改变）.
RPC 版本化:
- 在所有代理都有机会升级之前，不应删除任何RPC主版本号（意味着，在处理老版本客户端的兼容代码被从代码树移除之前，至少需要一个发布周期）。
- 不应在AMQP接口的agent侧添加兼容代码.
- 服务端代码应能处理所有之前版本的agents，直到接口的主版本号删除。
- RPC接口的参数不应修改意义，或者名称.
- 添加到RPC接口的新参数不应是强制的。这意味着该服务器应能处理旧的请求，而不需要新指定的参数。另外，如果参数未传递，应保留在添加参数之前的老的行为。
- 对于服务器初始的通知，最小客户端版本至少一个周期的后才能更改。
数据库迁移:
- 迁移代码应按要求分成两个分支（contract、expand）。neutron-server运行时不能安全执行的代码应添加到expand分支。
- 如果可能，contract迁移应尽量最小化或避免，以减少在数据库升级期间，API端点必须关闭的时间。