kombu_update

• 1. 总体介绍
  • 1.1. 现状分析
  • 1.2. 变更原因
  • 1.3. 变更后效果
• 2. 系统版本
• 3. 系统测试情况
  • 3.1. 测试内容
  • 3.2. 测试效果
• 4. 变更策略
• 5. 变更步骤
  • 5.1. 变更前准备
    • 5.1.1. 控制节点：
    • 5.1.2. 确保Rabbitmq 集群正常
• 6. 实施过程
  • 6.1. 逐一对个做各个OpenStack节点（管理节点、计算节点）进行升级
  • 6.2. 完成检查
• 7. 回退措施
  • 7.1. 变更回退措施
• 8. 评估影响
  • 8.1. 平台或业务影响
  • 8.2. 影响范围
  • 8.3. 时间计划
  • 8.4. 人员安排

1. 总体介绍

1.1. 现状分析

在网络异常，控制节点故障等情况下，OpenStack 的所有服务会输出大量服务连接消息队列异常，服务无法响应的问题，造成大量的日志占用磁盘，需要在网络恢复或者控制节点rabbitmq-server正常的情况下重启服务才会停止刷新日志的情况。

1.2. 变更原因

经过测试验证，通过升级kombu库可以解决该问题，为了防止项目出现以上情况，故申请升级消息队列来修复该问题。

1.3. 变更后效果

解决了当管理节点出现硬件故障、网络抖动、mq异常时，OpenStack服务会出现异常的问题，包括以下几点：

• 日志快速刷新，短时间内占满根分区，影响服务使用
• 服务状态异常，服务呈现down状态，且服务不可用
• 部分客户业务异常

2. 系统版本

产品	当前版本	升级后版本	备注
Kombu	2.5.16	3.0.23

3. 系统测试情况

3.1. 测试内容

• 检查是否所有OpenStack服务异常

openstack-status

• 检查服务中是否继续有大量日志刷新

• 检查虚拟机和块存储的创建和日常操作
  • 测试创建虚拟机和进行日常操作
  • 测试创建块存储和进行日常操作

3.2. 测试效果

所有OpenStack服务正常，服务中没有大量日志刷新，虚拟机和块存储创建和日常操作正常，则测试通过。

4. 变更策略

• 采用灰度升级方式逐一对各个OpenStack节点（控制节点、计算节点）进行升级，将 python-kombu-2.5.16-1.el7.noarch.rpm 包升级至 python-kombu-3.0.23-1.noarch.rpm ；
• 重启OpenStack服务（glance、nova、cinder、neutron）；
• 检查OpenStack服务是否正常，服务中有无大量日志刷新，并测试创建虚拟机和块存储。

5. 变更步骤

5.1. 变更前准备

5.1.1. 控制节点：

• 对openstack数据库进行备份
• 确保Mysql服务正常

  Mysql>show status like 'wsrep%';

  • 检查 wsrep_incoming_addresses 为 3 台
  • 检查 wsrep_cluster_size 3
  • 检查 wsrep_local_state_comment 状态为 Synced

5.1.2. 确保Rabbitmq 集群正常

```bash
rabbitmqctl cluster_status
```

• 检查 running_nodes 为3个节点
• 检查 partitions 为空[]
• 检查 rabbitmqctl list_queues 无阻塞

6. 实施过程

6.1. 逐一对个做各个OpenStack节点（管理节点、计算节点）进行升级

顺序：

• 控制节点三台节点升级(逐台进行升级)：

yum localinstall python-kombu-3.0.23-1.noarch.rpm

重启openstack 服务（逐个组件进行重启）

openstack-service restart glance
openstack-service restart nova
openstack-service restart cinder 
openstack-service restart neutron
openstack-service restart heat

• 计算节点升级：

yum localinstall python-kombu-3.0.23-1.noarch.rpm

重启openstack 服务（逐个组件进行重启）

openstack-service restart nova
openstack-service restart neutron

6.2. 完成检查

• 检查所有OpenStack服务是否正常
• 检查服务中是否继续有大量日志刷新
• 检查虚拟机和块存储的创建和日常操作

7. 回退措施

7.1. 变更回退措施

以下任意一项不通过，需要回滚：

• 若升级后OpenStack服务异常，则进行回滚；
• 若升级后服务中继续有大量日志刷新，则进行回滚；
• 若升级后创建虚拟机和块存储异常，则进行回滚；

回滚步骤：

• 重启openstack 服务（逐个组件进行重启）

openstack-service restart glance
openstack-service restart nova
openstack-service restart cinder 
openstack-service restart neutron

8. 评估影响

8.1. 平台或业务影响

升级过程中需要重启所有服务（包含 neutron-openvswitch-agent ）会导致虚拟机流表重新刷新，会出现丢包情况，虚拟机会丢3-5个包。

8.2. 影响范围

所有单位，所有业务系统。