适用场景

• 产品：ZCF
• 组件：ZCE-X、Cloud
• ZCE-X 版本：5.2.x
• 对接云平台版本：ZStack Cloud 4.4.x
• 涉及平台版本：ZStackCube 2.2.x 升级至 2.4.x
• 当前版本：
• ZStackCube 2.2.x
• ZCE-X 5.2.x
• Cloud 4.4.x
• qemu 4.2.x
• libvirt 4.9.x
• 目标版本：
• ZStackCube 2.4.x
• ZCE-X 5.2.x
• qemu 6.2.x
• libvirt 8.0.x
• 操作系统：C76
• 部署形态：1 个集群、10 台物理机、1 个主存储
• 触发条件：当前文件存储存在写入慢问题，且后续存储升到 V6 前需要先完成 5.2.x 过渡升级。

问题现象

• 当前环境版本较老。
• 文件存储存在写入慢问题。
• 平台、虚拟化组件、存储均需要协同升级。

判断方法

1. 升级前确认平台、Ceph、etcd、ES、postgres 同步、主机资源和免密状态正常。
2. 平台升级后检查管理节点、主机、主存储、镜像服务器和云主机状态正常。
3. 存储升级后检查 ceph -s、xms-cli -v、xdc、xmsd、docker ps 和界面模块正常。

原因说明

根因之一是当前文件存储存在写入慢问题，而存储侧建议后续升到 V6；但当前版本不支持直接升级到 V6，因此需要先把平台和存储提升到当前支持的过渡版本，再为后续继续升级打基础。

解决方案

1. 执行前准备

• 风险等级：高风险
• 平台上资源进入维护模式，并关闭云主机全局高可用。
• 平台升级前使用 pre_upgrade_self_check 做自检。
• 停止所有备份任务。
• 备份双管理数据库，并备份 zstack-upgrade 脚本。
• 若要做 qemu 升级，需先在备份服务器清理可能运行中的 qemu-nbd。

2. 灰度升级云平台到 2.4.x
3. 使用 pre_upgrade_self_check 做环境检查。

• 预期结果：识别跨版本升级风险点。

2. 关闭全局高可用，并申请 1 台非核心业务物理机用于优先重连校验。
3. 双管理上传 ISO、升级包、HA 组件、bin，并校验 md5 与 zsha2 commit。
4. 修改 /etc/my.cnf：

   wait_timeout=28800
   interactive_timeout=28800

然后重启 mariadb.service。

5. 双管理分别备份数据库：

   zstack-ctl dump_mysql --file-name mn1
   zstack-ctl dump_mysql --file-name mn2
   cp /usr/local/bin/zstack-upgrade /root/zstack-upgrade-bk

6. 更新源：

   bash zstack-upgrade -r Cube-x86_64-DVD-2.4.17-c76-Enterprise-upgrade-241024.iso

7. 查询 VIP 节点：

   zsha2 status

8. 解压 HA 包并赋权：

   tar zxvf ZStack-Cube-Multinode-HA-Suite-2.4.17.tar.gz
   chmod +x zsha2 zstack-hamon

9. 停止 MN 服务并升级 HA：

   zsha2 stop-node
   ./zsha2 upgrade-ha -gencfg=true

10. 灰度升级云平台：

    zsha2 upgrade-mn -grayscale -yes xx.bin

11. 升级完成后检查：

    zstack-ctl status
    zsha2 status

12. 登录 UI 检查资源状态，并优先重连非核心业务物理机。
13. 检查 Agent 版本：

    zstack-cli QueryAgentVersion

14. Ceph 存储侧检查：

• ceph -s
• 防火墙状态
• 物理机到 Ceph 网络连通性
• 心跳卷访问

15. 无异常后依次重连其他物理机。
16. 关闭灰度变量并开启全局高可用。

• 预期结果：平台升级完成。

3. 升级 qemu / libvirt / glib2 组件
4. 升级前关闭所有备份任务；如有运行中的备份进程，在备份服务器执行：

   pkill qemu-nbd

2. 单台物理机先升级：

• qemu-storage-daemon
• qemu-kvm
• glib2
• libvirt

3. 单台验证无异常后再升级其他物理机。
4. 用 QueryLongJob 查询进度。
5. 升级完成后，云主机需要重启或迁移以加载新 qemu。
6. 用以下命令查看 VM qemu 版本：

   virsh qemu-monitor-command $VMuuid --hmp info version

• 预期结果：虚拟化组件升级完成。

4. 离线升级 ZCE-X 到 5.2.x
5. 升级前确认：

• ceph -s 健康
• etcd 健康
• ES 状态 green
• SSH 免密正常
• 系统盘空间充足
• /opt/sds 权限为 755
• umask=0022
• postgres 同步正常
• 历史告警已清理
• 集群版本已确认

2. 用 xms-manage db list 找到主数据库节点。
3. 下载并解压升级包到主数据库节点。
4. 执行：

   ./upgrade.sh

5. 若需要跳过 ceph 状态检查：

   ./upgrade.sh --nc

6. 若升级中断：

   ./upgrade.sh --continue

7. 若 Prometheus 端口冲突，则修改 zstack.properties 中 Prometheus.exporterPort 后重启 MN 服务。

• 预期结果：存储升级到 5.2.x。

5. 升级后检查与收尾
6. 检查：

   ceph -s
   xms-cli -v
   systemctl status xdc
   systemctl status xmsd
   docker ps

并检查界面中的块存储、文件存储、资源管理、监控管理等模块。

2. 重新启用 ceph 集群内物理机和云主机，并开启全局高可用。
3. 使用巡检脚本做环境健康巡检。

• 预期结果：整套平台、虚拟化组件与存储升级后恢复健康。

验证方法

• 检查管理服务、Ceph 集群和存储池健康。
• 检查平台资源和业务云主机状态正常。
• 检查 xms-cli -v、qemu、libvirt 版本达到目标值。
• 检查巡检结果中无关键告警。

风险与回滚

• 风险：平台升级期间管理节点不可访问，组件升级对兼容性影响较大。
• 风险：qemu / libvirt 升级后云主机需迁移或重启生效，且 qemu 版本不能回滚。
• 风险：存储升级原则上不回退，若中断应先分析原因并继续 ./upgrade.sh --continue。
• 风险等级：高。
• 回滚：仅对云平台提供完整双管理回退方案；存储与 qemu 不建议贸然回退。