横跨7个版本的OpenStack无感知热升级在360的落地与实践

01

背景

360公司的IaaS服务平台，是基于开源Openstack项目研发的，在发展的数年间已历经了多次版本的更新迭代。2015年，360团队基于Liberty版本自主研发了360公有云（奇云），以及支持集团内部事业部使用的私有云（HULK）。2019年-2020年期间，360团队基于Openstack Stein版本，重新打造了可适配ToB业务场景的IaaS平台360Stack。该产品通过了多项权威资质认证，目前已成为可面向市场进行商业化交付的成熟解决方案。2021年，360虚拟化团队继续将ToB里的虚拟化能力，反哺到公司内的ToC集群，并自研主机Overlay架构以适配公司的大规模业务场景，应用计算存储分离结构，上线更丰富适用的云主机功能，例如弹性伸缩、可抢占实例、弹性裸金属等功能。对比于早期版本，目前最新的Stein版本功能，已有了极大的改进。

自研Openstack Stein版已被应用于北京的2个25G新机房，但是公司内北京、上海、郑州等6大主力机房目前在运行的虚拟化集群，几乎还是Liberty版本，运维着3000多台物理机，规模巨大、管理成本高。如果能够将公司内的L版本升级到S版本，将大大提升服务效率。

1.1 心路历程

整体客观而言，升级工作版本跨度很大，隔了7个版本，按Openstack一年2个版本的迭代速度，相当于隔了3年半。中间版本的表结构差异，功能差异非常大，两拨人马两套代码和数据，中间断层非常严重。要达成统一，大家都默认不可行，默认接受新的用S版本，老机房都用L版本。

但是360虚拟化团队基于使命必达、创新突破的价值观秉持下，我们提出一定要统一，公司底层云底座必须统一架构，并且所有机房必须支持今年上线的新能力。最后在保持统一目标下，大家群策群力，想了多种方案，比如机房迁移，挂公告ceph冷迁移。或者ceph双写热迁移等。

但上述方案对用户影响都比较大，我们提出能不能做到对业务无感知，这对团队的技术要求提出了更大挑战，最后大家几经研究讨论，用表结构对齐，流表补齐，组件定制升级的思路，达成了我们如下的横跨7个版本业务0感知的Openstack热迁移方案。该方案足够通用，理论上支持以后的任意Openstack之间版本热升级，希望能对大家有所帮助。

业界当前基本上IaaS除了一些头部云厂商自研，其他IaaS厂商还是基于Openstack居多，但可能大家都是基于一个版本之后二次开发cherrypick，可能与社区渐行渐远，也有可能一些跟社区跟的比较紧的，持续跟着社区热升级也不会有这种情况。还有一些公司私有云已经没有IaaS，直接用k8s容器推动业务全面容器化，部分特殊vm需求用kubevirt代替等。所以每家公司都有自己的独特背景和经历，做方案的时候除了技术还需要一些勇气，希望能对大家有所借鉴。

1.2 升级后的好处

• 架构统一：应用主机overlay网络架构和存算分离结构；

• 运维统一：从同一个平台运维，底层版本一致，各集群间处理的问题有共性，提高处理效率；

• 功能统一：利于快速推进新功能，且功能增强（包括多规格企业级实例、云硬盘、弹性伸缩、基于主机overlay的VPC网络等）；

那么该如何实现对存量L版集群的平滑升级呢？

02

升级思路探索

背景中提到，2015年，360技术团队基于Liberty版本上进行了自研，其中包含了大量为满足当时网络Overlay架构、云主机生命周期管理等功能的服务特性。自研Stein版本与Liberty旧版相比，不仅有社区代码的变动、自研代码的差异、数据库表结构的变化，最核心的还是自研Stein版采用了主机Overlay网络结构，并采用存算分离的计算架构。这两个版本从各方面来看，都差别巨大。

观察Openstack 这个IaaS平台服务本身，它最根本的依赖元素是各个组件的代码、数据库和消息队列。Openstack社区在每次进行版本升级时，不仅有代码的变动，还会详细描述数据库表结构的创建升级删除操作。所以按社区的这种升级方式来操作，对我们这个现状基本是不可行的。

基于虚拟化团队对Openstack多年的开发经验积累，我们探索出从控制层面的数据库入手，将L版使用的数据库对齐到S版使用的数据库中，使得集群控制面能够平滑升级到S版本。同时对计算节点，进行了软件层面的整体更新。另外，为了保证升级过程现有业务的网络无感知、零中断，我们还增加了网络流表补齐。综上所述，L-S架构热升级包含三方面的升级操作：控制面对齐、网络数据面对齐、软件层面全部更新。

L-S 热升级架构图

2.1 控制面补齐

控制面数据对齐，我们采用数据库导入的方式，分为三个步骤，主要应用于Nova、Cinder、Glance三个组件:

• 先新建临时表；

• 再将L版中的关键数据库表导入临时表，对临时表进行适配修改；

• 最后将临时表导入S版的数据库中；

2.1.1 Nova数据库对齐

下面以nova组件为例，详细讲解其中的步骤。L版到S版nova组件架构上有变动，数据库和数据表也有相应变更，从L版nova数据库53张表(忽略shadow_开头的表)到S版的148张表（包括nova_api中32张+nova_cell0中58张+nova中58张，忽略以shadow_开头的表），数据库表变化很大。虽然有这么多变化，但是我们关心的数据表主要在虚拟机和hypervisor，而hypervisor信息可由nova-compute实时上报，因此只需要关心存量虚拟机以及虚机周边信息的记录。以下列出与虚拟机数据表记录相关的表，其它数据表保持使用S版的。nova_cell0库存储调度失败的虚拟机信息，可忽略,无需进行迁移操作。

步骤一：在L版使用的DB中创建临时数据库migrate_nova_api和migrate_nova，并依据S版数据库创建临时数据表。

新建migrate_nova_api库，按S版表结构新建下面的表	S版本里新增字段使用默认值或进行后期处理，删除字段无需关注。
Flavors	记录Flavor信息。将L版的instance_types表迁移到flavors表，同时表中移除deleted_at、deleted字段
flavor_extra_specs	记录Flavor额外键值信息。将L版的instance_type_extra_specs迁移到flavor_extra_specs，同时表中移除deleted_at、deleted字段，L版instance_type_id字段变为flavor_id字段
key_pairs	无差异，全量导入
instance_mappings	记录instance和cell的映射。先从L的instances表导入数据，之后用脚本填充cell_id信息。