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信息。
Aggregates	无差异，全量导入
aggregate_hosts	无差异，全量导入
aggregate_metadata	无差异，全量导入
request_specs	这个表在L版里不存在，通过额外的脚本对虚机进行补齐，否则在S版里做不了迁移，重装等操作。
新建migrate_nova_api库，按S版表结构新建下面的表
Instances	记录虚机信息。
instance_extra	无差异，全量导入
instance_metadata	无差异，全量导入
instance_system_metadata	无差异，全量导入
block_device_mapping	uuid自动生成，其它字段置空
自动同步的表
instance_info_caches	虚拟机网络信息：自动从neutron同步

步骤二：使用MySQL内部insert into ...select from语句将L版原数据记录导入到临时数据库中；比如下面的例子。

insert into migrate_nova_api.flavors(`created_at`,`updated_at`,`name`,`id`,`memory_mb`,`vcpus`,`swap`,`vcpu_weight`,`flavorid`,`rxtx_factor`,`root_gb`,`ephemeral_gb`,`disabled`,`is_public`)  select  `created_at`,`updated_at`,`name`,`id`,`memory_mb`,`vcpus`,`swap`,`vcpu_weight`,`flavorid`,`rxtx_factor`,`root_gb`,`ephemeral_gb`,`disabled`,`is_public`  from instance_types where  deleted=0;

步骤三：通过shell脚本更改临时数据库中的某些字段，比如，由于不对Keystone进行升级，要将L版DB中的project和user信息替换成S版集群中的project和user，另外，需要补齐cellid和availability_zone等信息。

步骤四：使用mysqldump命令将临时数据库表导出后，使用mysql命令将导出的临时数据表导入到S版数据库，要求S版数据库在导入前无杂乱数据，以便于把老数据按id序号完全导入。

2.1.2 Glance数据库对齐

原理和nova数据库一样，这里列出实际操作的数据表。

新增migrate_glance库，按S版表结构新建下面的表

image_locations

image_properties

images

对glance数据库的补充更改：images表的owner字段，image_properties表的owner_id 和user_id字段修改为新keystone里的项目信息。

另外，在S版里，我们使用了镜像多后端，所以在导入到S版数据库里后，对image的location在metadata里添加了backend的属性。

2.1.3 Cinder数据库对齐

原理和nova数据库一样，这里列出实际操作的数据表。

新增migrate_cinder库，按S版表结构新建下面的表

volumes

volume_glance_metadata

volume_metadata

volume_attachment

volume_admin_metadata

snapshots

snapshot_metadata

对cinder数据库的补充更改：更改volumes表和snapshots表的user_id和project_id。

在S版环境中，存储是多Ceph集群多Ceph Pool模式的，对于sata这种volume_type，会对应多个不同pool，因此会对应到多个cinder_volume服务。在迁移cinder数据库的过程中，对L版集群的pool匹配对应S版的cinder-volume服务，更新对应volumes的host， service_uuid, volume_type，availability_zone等信息。

2.2 网络数据面对齐

网络方面和计算的数据同步方案有些差异，一方面是我们对原生L版本的网络改动比较大，因为当时是基于网络overlay的思路去重构的虚拟化网络架构，对数据库表修改比较多，另一方面网络的数据主要是围绕port构建的，而我们通过命令构建port是很方便的。

基于如上两点，网络部分数据的同步采用如下思路：提取L版本关键信息，根据这些关键信息通过命令将port构建出来。这样做的好处是不必将大量精力耗费在L版本与S版本数据库表的差异上。

• 首先提取L版本关键信息。其中包含agent、security group、network、subnet、port信息。注意这里agent信息比较特殊，因为neutron server没有创建的接口，所以需要将这些信息通过sql命令导入新版数据库，这点和之前的nova数据库对齐有些类似。如果agent信息没有对齐，会导致后面创建port时binding failed，所以这一步是必须的。另外这里说的关键信息是必须要保持一致的信息，比如id、network segment 、subnetcidr、subnet dns_server、subnetgateway_ip、port ip、port mac、port device_id等；

• 其次根据收集到的信息。在新版控制节点依次创建security group、network、subnet、port信息。注意由于网络的转发面（比如tap口）会用到port id信息，因此我们需要保证port id与之前L版本的id一致，因此创建port时需要指定id，但原生openstack并不满足这一需求，因此需要改下代码，关键代码在neutron_lib/api/attributes.py:AttributeInfo，感兴趣的同学可以了解下；

• 最后再做下检查，确保两边数据库信息一致；

2.3 软件层面全部更新

L、S版本分别使用 Puppet和 Kolla ansible 进行配置管理，Puppet 与 kolla ansible 并列社区核心项目：

• Puppet 基于c /s 架构，周边生态基于完善基础设施，如 pip rpm image仓库、git仓库、代码审核平台等。Puppet 对虚拟化集群中 file、service、package 进行原子化管理。Puppet属于后期爆发类，对于部署能力较弱；

• Kolla ansible 采用容器方式去管理 Openstack 控制服务，前期部署比较轻便上手，对于后期的原子化和定制化较弱；

通过团队对配置管理的理解和实践，最终选择 Kolla ansible 部署新控制节点，其次通过开发新模块对现有L版本计算节点进行配置升级管理。计算节点主要包含了网络和计算控制服务，通过角色拆分，可将其分为如下升级单元：

• 配置管理模块。将公共配置参数以集群为单位纳入目录中，如升级列表、集群公共配置参数、软件包版本，每套集群一套配置，并push至Git仓库管理。

• 升级前进行基础环境预热。卸载旧版本Python 基础库与Puppet 配置管理Agent，备份控制服务旧配置，准备完成后对当前环境检测是否达到升级标准。

• 计算、网络升级模块。主流程为优先停止服务，卸载软件包，更新软件包，下发配置，其中计算模块优先启动nova-compute，而网络控制服务在结束其它流程完成后再进行灰度单节点，主要由于升级ovs-agent会下发新流表，会有大规模断网风险。

• 存储升级模块。更新存储软件包，并在计算节点更新ceph 配置文件。

• Libvirtd升级模块。计算节点libvirtd 升级后自动刷新服务，保证服务能否正常管理kvm 虚拟机。

• 最后到网络模块控制层面灰度升级。

从更新基础软件包开始，最后灰度启动网络控制服务，在这期间为保证在升级过程中某一个服务出现问题时，团队可以快速定位到升级阶段问题，并根据当前细分模块进行优先级前后顺序排位，保证升级流程的可控和连贯。

03

升级过程和方法

经过对测试集群进行的L-S的升级验证，团队把升级前、升级中、升级后的各项步骤整理成自动化脚本。随着对线上集群的升级，不断总结各个集群的不同点，以及发生的问题点，同时对脚本进行不断地优化。在2个月的时间内，完成了方案制定、脚本编写，最后到6个主力集群的全部升级。

3.1 升级想要达到的效果

L版计算节点现状	升级到S版后
内核: 3.10.0-693  操作系统: CentOS 7.4.1708  ovs版本: 2.5.5  qemu版本: 2.6.0  libvirt版本:3.9.0 librbd1版本：0.94.5.11-1 网络：  vlan模式 存储:  多ceph集群	内核: 3.10.0-693  操作系统: CentOS 7.4.1708  ovs版本: 2.11.0  qemu版本: 2.12  libvirt版本:4.5.0 librbd1版本：12.2.13-1 网络：  vlan模式 存储:  多ceph集群 （glance和cinder需适配多ceph）

• 有存量虚机的计算节点依然对接原始连接的ceph集群，同时支持cinder创建卷的方式，作为共享型物理机，可创建新虚机；

• 对存量虚机可进行：重启，停止，创建自定义镜像，热迁移，冷迁移，重装，挂载卷，卸载卷，调整配置；

• 无虚机的计算节点可以完全部署容器化的S版服务，作为企业级物理机；

• glance服务对接已有的ceph集群，承载老镜像，能够创建新镜像，支持镜像多后端；

• cinder服务，对接已有的ceph集群，支持从老镜像上创建云盘启动的虚机，支持存储多后端；

3.2 升级前的准备

3.2.1 部署S版新控制节点

1. 提前在L集群创建两台测试机；

2. 收集L版集群计算，存储，镜像，网络相关信息；

3. 根据收集到的信息，准备控制节点（也部署成计算用于后期验证）；

• 准备S版本的DB，LVS+域名解析，提前把控制节点的对应端口加到对应VIP端口；

• 确定keystone地址，region_name；

• 获取老ceph集群信息，准备ceph.conf；

• 在待升级集群中选择两台空机器部署S版控制节点，包括rabbitmq，nova-api，nova-conductor，nova-scheduler，placement-api，neutron-server，neutron-dhcp-agent，neutron-metadata-agent，neutron-openvswitch-agent，glance-api，cinder-api，cinder-volume等控制服务；

• 新cinder服务对接老的多ceph集群；

• 新glance服务对接老的多ceph集群；

4. 检查控制节点服务是否部署正常；

• 检查nova，neutron，glance，cinder的配置文件

• 服务是否正常

3.3 升级中

3.3.1 导入计算，网络，存储，镜像数据

1.  导镜像数据: 将glance镜像信息导入到stein版glance里；

2.  导计算数据：将L版的flavor，aggregate等信息导入nova_api表，将instances表等依赖信息导入nova表，生成request_specs数据表；

3.  导存储数据：导cinder的volume信息；

4.  命令行方式准备网络数据：创建network/subnet/port等依赖信息，因为DHCP使用的IP地址与老的相同，因此将老的DHCP端口down掉，测试虚机DHCP依然正常后，进行后续步骤；

3.3.2 升级老计算节点

1. 根据收集的老计算节点连接存储pool和ceph.conf的信息来准备nova.conf、neutron.conf等配置文件；

2. 老计算节点前期准备：停止ovs-cleanup服务，获取当前nova、neutron、qemu、libvirt、ceph等版本信息，用以判断升级；

3. 准备rpm包目录，分步骤升级，过程中一直执行虚机存活检测脚本，记录断网时间；

• nova包+ovs包，涉及服务nova-compute

• neutron包+neutron_lib包，涉及服务neutron-openvswitch-agent，neutron-l3-agent，neutron-metadata-agent

• qemu和libvirt包

• ceph client包和librbd包

• 灰度启动neutron agent 服务

4.  重启控制节点服务，检查控制服务的配置；

• # docker exec -it -u root nova_api bash 之后执行 # nova-manage cell_v2 discover_hosts

• docker restart placement_api; docker restart nova_scheduler; dockerrestart nova_conductor

3.4 升级后

3.4.1 功能检测

1. 检测：老虚机网络正常，物理机上报状态正常；

2. L的测试虚机检测：

1）ifdown eth0;ifup eth0是否正常

2）curl 169.254.169.254；

3. 功能检测（测试脚本：重启、停止、创建自定义镜像、挂载卷、卸载卷、热迁移、冷迁移、调整配置、重装、可创建新虚机到老物理机上）；

3.4.2 新集群补充初始化信息

1. 新建套餐，物理机打trait，新建网络QoS；

2. 网络打tag，加上az名字；

3. 和公司内的ultron平台对接；

4. 等集群全部升级完成后，删除L的endpoint；

04

升级中遇到的各种突发问题

4.1 计算侧问题

4.1.1 调度问题

• 调度Filter变化

对于L版本的紧耦合存储方式，计算节点和存储集群是一对一的关系，而代码升级后，原有用于存储池过滤的自研PoolFilter，用于aggregate过滤的自研TagFilter已不存在，需要使用新版本里的自研的AggregateInstanceMetadataFilter过滤器来负责存量虚拟机 metadata和aggregate metadata的匹配。因此需要将虚拟机记录的元数据从pool=xxx改为aggregate_instance_metadata:pool=xxx，使得可以与aggregate的metadata里记录的pool信息进行比较。信息一致，则表示该存量虚机可以调度到指定的aggregate里，存储池还是原有的存储池。对于新建虚机，由于计算节点和存储集群是存算分离结构，套餐内不带aggregate信息，而且是boot from volume云盘启动模式，计算不需要关心属于ceph 哪个pool集群；

• 调度不出主机

执行热迁移时，报错“Filter AvailabilityZoneFilter returned 0 hosts”。分析：导完aggregate等数据后，如果不重启nova-scheduler，nova-scheduler未感知到DB里的az等信息导致调度失败，因此要重启nova相关服务。处理方法：在数据库数据准备完成后，将控制节点所有服务重启一遍；

• scheduler配置调整

placement里没有分配记录，所以placement里认为数据没有被分配，所以这里要在scheduler上加上scheduler里增加 CoreFilter,DiskFilter,RamFilter；

4.1.2 Aggregate划分问题

• 原有粒度划分太小，若考虑CPU兼容性，会导致迁移域太小。

后续创建云盘启动的虚机，不做强制关联，因为热迁移的流程中：nova-conductor每次调度一台宿主机后，会检查CPU兼容性，如果不兼容则继续调度，这样的好处是不需要把宿主机划成小aggregate，提高灵活性；同时也能支持跨机型的冷迁移。

4.1.3 多后端支持

• 多后端支持：由于S代码应用了多后端逻辑，需要在nova-compute在创建自定义镜像时，设置镜像的后端元数据。

4.1.4 qemu升级后的兼容问题

• 升级后win2k16和win2k12强制重启失败，报错“unsupported e1000e hardware”

原因分析：在qemu2.6.0里，hypervisor为windows选择的vif model是virtio, 升级到qemu2.12.0后win2k16和win2k12，win2k8选择的是e1000e，而在openstacknova的代码里kvm指定的validnetwork_model没有e1000e，所以产生”Requestedhardware 'e1000e' is not supported by the 'kvm' virt driver:UnsupportedHardware: Requested hardware 'e1000e' is not supported by the 'kvm'virt driver“报错

解决方法：

• 方法一：修改nova/virt/libvirt/vif.py 增加 network_model.VIF_MODEL_E1000E, 重启openstack-nova-compute；

• 方法二：更改win2k12和win2k16，win2k8镜像属性 设置 hw_vif_model=virtio， 后续新建虚机不再使用e1000e；存量虚机在instance_system_metadata里添加image_hw_vif_model=virtio；

4.2 存储侧问题

4.2.1 Ceph client版本与Ceph server版本配合问题

L版集群使用的Ceph版本是较老的cephHammer 0.94.5.11版本，S版集群使用的是Ceph luminous 12.2.13-1.el7版本，升级L版本到S版本后，我们希望用Ceph 12.2.13的client版本，librbd1 也是用12.2.13版本去连接老的0.94.5.11的ceph集群。

在过程中，发现ceph的0.94.5.11和12.2.13的feature支持不一致。如果不修改rbd_default_features会导致虚机挂载卷失败，为老虚机创建镜像，会报错不能clone。

解决方法：在ceph.conf配置文件里设置

[client] rbd_default_features=13

备注：13 = layering + exclusive-lock + object-map= 1+2+4+8, 详细features说明可查询ceph官网。

4.2.2 访问rbd是否开启认证

由于L版老集群和S版新集群在Ceph集群的认证方面，使用的密钥不一致，会强制重启失败问题，挂新volume失败，但实际上，Ceph集群是没有开启认证的，不需要ceph auth的配置。

解决方法：不配置rbd_user和secret_uuid

4.3 网络侧问题

在L-S架构热升级中，最困难的点在于：如何保证在线业务零感知。在线业务数量庞大，备份复杂；业务特点不相同，无法在一个时间点能进行割接通知。在这种压力催动下，团队从最开始的重启物理机的方案，演进为无需重启物理机。从预计断网10分钟，到实际仅丢包1~3个，到流表补齐方案的丢包为0。

在对郑州、上海、北京6个机房的架构升级中，4个机房无感知，仅有2个机房的少量业务由于历史网络结构问题，受到影响。下面就总结一下常见的几个问题。

4.3.1 安全组问题，qvo口和tap口并存导致网络中断

由于历史原因，老机房存在部分虚机的tap口连接到br-int（早期没有绑定安全组，不需要qbr桥），而部分虚机的tap口连接到qbr桥，因此底层虚拟化网络结构不统一。而升级到S版本后，集群默认虚机的tap口连接到qbr桥（默认绑定安全组，且用iptables规则实现），这导致控制层面与实际的转发层面不统一，会导致部分虚拟机网络不通。

因此针对这种机房，除了数据库信息的同步外，还要关注转发面网络结构，针对虚机直连br-int的虚拟机，修改数据表ml2_port_bindings中的vif_details字段中ovs_hybrid_plug的值为false，这相当于告诉控制节点，该虚机不需要qbr桥。

4.3.2 Ovs-cleanup服务问题

由于历史原因，老机房计算节点默认部署了neutron-ovs-cleanup服务，且该服务通过systemd进行管理，在启动和停止的时候会被激活执行，导致ovs port被全部删除，进而导致该节点上的虚拟机断网。而我们升级过程中由于会升级python基础库，neutron-ovs-cleanup服务会被停止，导致该服务被激活执行，进而导致断网。

因此针对这种情况，需要在升级前将neutron-ovs-cleanup服务关闭但不触发执行操作。我们通过修改systemd中该服务的ExecStop动作即可。

4.3.3 并发60台升级，流表下发慢，断网15~60s

我们升级过程可以分为两阶段，包括升级前的准备和升级。

• 升级前的准备是指新控制节点的搭建、数据库信息的同步、计算节点配置的更新（比如更新nova、neutron的配置文件，关闭ovscleanup功能等），这些操作对计算节点的转发面不影响。

• 真正升级时，需要升级计算节点的基础库，更新版本并重启nova、neutron服务，这一步由于涉及到转发面流表的更新，在更新过程中可能会有流量中断，让用户感知到。

因此我们要缩短流表更新完成的时间，让用户无感知。

计算节点网络服务升级时（重启ovs agent）会去控制节点拉取必要的数据，用以下发流表。由于我们机房的计算节点规模相对较多，我们实测并发升级60台节点时，会有断网15——60s，只升级一台节点的话也会有十几秒中的断流，这是不可接受的。

我们采取的方案是预下发流表，即在升级前下发高优先级流表，走normal转发。升级过程中，虽然会更新流表，但由于优先级低不会被匹配到，因此还走normal转发。等到升级完成后，再将该流表删除，让新版的流表生效。该方法实测是有效果的，可以做到对用户无感知，实现Openstack版本热升级。

4.4 操作部署问题

4.4.1 操作系统小版本问题

由于L 版本计算节点通过rpm 包方式安装，配置文件由puppet 管理，且L版本中基础库版本与社区中基础库存在差异化，我们把当前控制服务源代码统一做成rpm包方式，做到一次性预热和升级基础库，由于环境参差不齐，抽取多样本环境进行兼容型安装、卸载、启动测试，并总结了一套当前需要卸载和安装的软件列表作为基础，基本兼容Centos7 系列小版本计算节点升级，以减少人为升级过程中带来的流程上时间的复杂度。

4.4.2 升级模块原子化

由于升级系统较多，所以通过角色拆分，将其分为如下升级单元，保证升级过程中出现问题时，能够快速停止操作进行排查。

基础环境预热	升级列表，集群全局变量输入，变更软件包准备，备份配置文件，卸载旧版本 Python 基础库，传入新仓库
计算模块	停止服务，卸载软件包，更新软件包，下发配置，启动服务
网络模块	停止服务，卸载软件包，更新软件包，下发配置
存储模块	更新软件包，下发配置
虚拟机管理模块	更新软件包
网络控制层面灰度	降级并发数量，按个数启动ovs agent
虚拟机断网丢包率统计	网络启动后，开始并发Ping 包，升级结束后统计宿主机上每台虚拟机的丢包数量

4.4.3 大并发升级问题

• 同时进行60台计算节点的软件包和neutron服务升级，业务侧收到较多报警。并发升级首先会造成控制层面突然大量的消息同步，流表更新不及时，导致大量虚机网络中断，而这些虚机可能属于一个LVS下的，进一步造成VIP down掉。

• 解决方法：先完成升级软件包，然后再进行串行发布，串行发布以物理机为维度，一台上的虚机都通后，再进行下一台，即使业务的VIP下某个RS有问题，也不影响VIP。

4.4.4 控制节点部署问题

在将控制节点从2节点扩容为4节点，控制节点上的rabbitmq集群不正常，导致neutron-ovs-agent重启后与neutron-server不能正常交互。

解决方法：在rabbitmq容器中手动删除/var/lib/rabbitmq/mnesia文件夹，reconfig重建集群。早期部署新控制节点时，需选择合适机型配置，包括CPU、内存、磁盘、网卡等的考虑，避免中途扩容带来问题。对申请的数据库DB、LVS等，需考虑IDC、光纤、机房等问题，避免时延过高。

05

总结与展望

经过2个月的时间，虚拟化团队由最初的方案制定、脚本编写，到郑州、上海、北京6个主力机房的架构升级，4个机房无感知，仅有2个机房的少量业务由于历史网络结构问题，受到影响。整体过程可控、故障问题可快速修复，为公司IaaS底层架构实现了架构统一、运维统一、功能统一，非常有利于后续基础云的基座角色。

未来，我们还将继续在多集群融合，多cell水平扩展等方面继续探索，目的是达到IaaS平台的更易管理，规模更大，更稳定健壮。

最后也希望360虚拟化团队能持续贡献具有参考价值的干货文章，不发水文。如有对IaaS研发感兴趣的仁人志士，也欢迎发送简历。简历直投地址：wangbaoping@360.cn