Neutron升级规划

云计算 专栏收录该内容
40 篇文章 0 订阅

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

升级规划

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

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

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

滚动升级 Rolling upgrade

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

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

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

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

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

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

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

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

服务器升级

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

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

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

  1. neutron-db-manage upgrade --expand
  2. 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升级(每个节点)顺序如下:

  1. 首先,L2 agents (openvswitch, linuxbridge, sr-iov).
  2. 其次, 所有其它 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验证。升级场景为以下步骤:

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

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

此场景并不验证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端点必须关闭的时间。
  • 0
    点赞
  • 0
    评论
  • 1
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

相关推荐
©️2020 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值