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

一、背景

360公司的IaaS服务平台是基于开源Openstack研发的，历经了多次版本的迭代。2015年，360基于Liberty版本自研了公有云和支撑集团内部使用的私有云。2019年-2020年期间，360重新在Openstack Stein版本的基础上自研，打造适配ToB场景的IaaS平台360Stack，目前已发展成为可面向市场正式商业交付的成熟产品。2021年，360虚拟化团队自研主机Overlay架构适配公司的大规模场景，应用计算存储分离结构，也在持续上线更丰富的云主机功能，如弹性伸缩、可抢占实例、弹性裸金属等。最新的Stein版本功能，与早期版本相比已经有了极大的改进。目前自研Openstack Stein版已被应用于北京的两个25G新机房，但是正在公司北京、上海、郑州等六大主力机房中运行的虚拟化集群，几乎都还是Liberty版本。管理着3000多台物理机，规模巨大且运维成本高。如果能够将公司内的L版本升级到S版本，好处是显而易见的。

1.1 心路历程

整体客观而言，升级工作版本跨度很大，隔了7个版本，按Openstack一年2个版本的迭代速度，相当于隔了3年半。中间版本的表结构差异、功能差异非常大，两拨人马、两套代码和数据，中间断层非常严重。要达成统一，大家都默认不可行，默认接受新的用S版本，老机房都用L版本。但是360虚拟化团队基于使命必达、创新突破的价值观秉持下，我们提出一定要统一，公司底层云底座必须统一架构，并且所有机房必须支持今年上线的新能力。最后在保持统一目标下，大家群策群力，想了多种方案，比如机房迁移、挂公告ceph冷迁移、ceph双写热迁移等等。但上述方案对用户影响都比较大，我们提出能不能做到对业务无感知，这对团队的技术要求提出了更大挑战。最后大家几经研究讨论，用表结构对齐、流表补齐、组件定制升级的思路，达成了如下的横跨7个版本业务无感知的Openstack热迁移方案。该方案足够通用，理论上支持以后的任意Openstack之间版本热升级，希望能对大家有所帮助。当前IaaS业界基本上除了一些头部云厂商自研，其他IaaS厂商还是基于Openstack居多，但可能大家都是基于一个版本之后二次开发cherrypick，可能与社区渐行渐远，也有可能一些跟社区跟的比较紧的。持续跟着社区热升级也不会有这种情况。还有一些公司私有云已经没有IaaS，直接用k8s容器推动业务全面容器化，部分特殊VM需求用Kubevirt代替等。所以每家公司都有自己的独特背景和经历，做方案的时候除了技术还需要一些勇气，希望能对大家有所借鉴。

1.2 升级带来的好处

架构统一：应用主机overlay网络架构和存算分离结构；
运维统一：从同一个平台运维，底层版本一致，各集群间处理的问题有共性，提高处理效率；
功能统一：利于快速推进新功能上线，且功能增强（例如多规格企业级实例、云硬盘、弹性伸缩、基于主机overlay的VPC网络等）；

那如何对存量L版集群进行平滑升级呢？

二、升级思路探索

360在2015年基于Liberty版本进行自研，其中包含了大量为满足当时网络Overlay架构，云主机生命周期管理的功能特性，自研Stein版本与Liberty旧版相比，其中不仅有社区代码的变动，自研代码的差异，数据库表结构的变化，最核心的还有自研Stein版采用了主机Overlay网络结构，并采用存算分离的计算架构，这两个版本在各方面来看，差别巨大。从Openstack 这个IaaS平台服务本身看，它最根本的依赖元素是各个组件的代码、数据库和消息队列。Openstack社区在升级每个版本的时候，不仅有代码的变动，还会详细描述数据库表结构的创建升级删除操作。所以按社区的这种升级方式来操作，对目前这个现状基本是不可行的。基于虚拟化团队对Openstack多年的开发经验积累，我们探索出从控制层面的数据库入手，将L版使用的数据库对齐到S版使用的数据库中，使得集群控制面能够平滑升级到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 虚拟机；
最后到网络模块控制层面灰度升级；

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

三、升级过程和方法

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

3.1 升级要达到的效果

L版计算节点现状	升级到S版后
内核: 3.10.0-693 操作系统: CentOS 7.4.1708 ovs版本: 2.5.5 qemu版本: 2.6.0 libvirt版本:3.9.0librbd1版本：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.0librbd1版本：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；

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

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“报错解决方法：

第1种：修改nova/virt/libvirt/vif.py 增加network_model.VIF_MODEL_E1000E, 重启openstack-nova-compute
第2种：更改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架构热升级中，最困难的点在于：如何保证在线业务0感知。在线业务数量庞大，备份复杂。业务特点不相同，无法在一个时间点能进行割接通知。在这种压力催动下，从最开始的重启物理机的方案，演进为无需重启物理机。从预计断网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，光纤，机房等问题，避免时延过高。

五、总结与展望

虚拟化团队在2个月的时间内，完成了方案制定、脚本编写，到郑州，上海，北京6个主力机房的架构升级，4个机房无感知，仅有2个机房的少量业务由于历史网络结构问题，受到影响。整体过程可控，故障问题可快速修复，为公司IaaS底层架构做到了架构统一、运维统一、功能统一，非常有利于后续基础云的基座角色。未来，我们还将继续在多集群融合、多cell水平扩展等方面继续探索，目的是达到IaaS平台的更易管理、规模更大、更稳定健壮。