适用场景
- 产品：
ZCF - 组件：
ZStack Cloud - Cloud 版本：
5.3.x - 当前内核：
4.19.90-52.15.v2207.ky10.x86_644.19.90-52.15.v2207.ky10.aarch64- 目标内核：
4.19.90-52.57.v2207.ky10.x86_644.19.90-52.57.v2207.ky10.aarch64- 部署形态：双管理节点
- 触发条件：需要对物理机内核逐台升级，并控制对业务与存储的影响。
问题现象
- 当前内核版本较旧，需要统一提升到
4.19.90-52.57。 - 升级动作涉及物理机重启。
- 若环境为 ZCE-X / 分离部署，存储节点升级期间还需关注数据恢复与 Ceph 健康状态。
判断方法
- 升级前确认平台无异常、待升级主机已迁空。
- 升级后检查主机新内核版本是否正确。
- 若涉及存储节点，检查
ceph -s是否恢复正常再继续下一台。
原因说明
本次变更是针对物理机层的内核升级，不是单个服务热补丁，因此必须通过迁空主机、维护模式、重启和逐节点验证的方式控制影响；而 ZCE-X 环境又要求对存储节点升级过程额外做 Ceph 健康验证。
解决方案
- 执行前准备
- 风险等级：高
- 先登录云平台确认环境无异常。
- 先关闭全局高可用。
- 先备份双管理数据库。
- 升级前先迁移待升级主机上的云主机。
- 平台与主机准备
- 备份数据库：
zstack-ctl dump_mysql --file-name zstack-db-backup-master
zstack-ctl dump_mysql --file-name zstack-db-backup-slave- 预期结果：具备平台侧回退基础。
- 确认待升级物理机上的云主机已迁移空。
- 在目标主机上执行：
virsh list- 预期结果：没有
running的云主机。
- 将物理机置为维护模式。
- 预期结果：防止业务重新调度回目标节点。
- 执行内核升级
- 在其中一个管理节点下载并解压对应架构的内核升级包。
- 预期结果：升级包准备完毕。
- 进入升级目录并执行：
cd upgrade_kernel_bcache/
bash upgrade_kernel.sh <服务器IP>- 将
<服务器IP>替换为目标主机地址。 - 预期结果：目标主机完成内核升级。
- 若环境为分离部署且升级的是存储物理机：
- 先关闭数据恢复。
- 逐台升级并重启。
- 每台重启后等待：
ceph -s恢复正常，再继续下一台。
- 预期结果：存储升级过程中不会因并发重启放大风险。
- 升级完成后重启物理机，使新内核生效。
- 预期结果：节点以新内核启动。
- 系统恢复正常后解除维护模式。
- 检查重启后的内核版本。
- 预期结果：版本已切换到
4.19.90-52.57。
- 确认单台无误后，再依次处理剩余节点。
- 云平台正常后，重新打开全局高可用。
- 预期结果：升级流程收口完成。
验证方法
- 检查目标主机重启后内核版本正确。
- 检查云平台资源连接和业务运行正常。
- 若涉及存储主机，检查
ceph -s每轮都恢复正常。
风险与回滚
- 风险：内核升级需要重启物理机，会直接影响该节点业务连续性。
- 风险：ZCE-X / 存储节点若并发升级，可能影响 Ceph 健康与业务稳定。
- 风险等级：高。
- 回滚：无单独回退命令，执行上应依赖单台验证、维护模式和逐节点推进来控制风险。