文档中心知识库安全API Explorer
文档中心›KB›ZStone 超融合管理节点重装与恢复KB
文档目录

适用场景

  • 产品：ZCF
  • 组件：ZStack Cloud、ZStone
  • ZStack Cloud 版本：4.8.x
  • ZStone 版本：5.2.x
  • 操作系统：h84r
  • 部署形态：3 节点超融合、双管理节点
  • 触发条件：管理节点因 RAID 卡故障，需要重装系统并恢复管理与存储角色。

问题现象

  • 超融合节点中的一个管理节点发生 RAID 卡故障。
  • 该节点既承担管理节点角色，也关联存储 mon / OSD / 缓存资源。
  • 需要先剥离旧节点，再重装并重新纳管。

判断方法

  1. 确认故障节点需要重装系统恢复。
  2. 重装后确认 Cloud、ZStone、高可用和存储角色全部恢复。
  3. 检查新节点重新加入后平台和存储状态正常。

原因说明

这是由于管理节点 RAID 卡故障导致的恢复场景，因此需要通过完整重装、角色重建和双管理重组来恢复环境。

解决方案

  1. 执行前准备
  • 风险等级：中风险
  • 先关闭平台高可用和存储数据恢复。
  • 先备份 Cloud 与 ZStone 数据库。
  • 在 UI 和存储平台上先清理故障节点相关资源。
  1. 清理故障节点旧资源
  2. 关闭全局高可用开关。
  3. 关闭数据恢复开关。
  4. 备份数据库：
   zstack-ctl dump_mysql
   mysqldump -uroot -p<数据库密码> zstone > /var/lib/zstack/mysql-backup/zstone-backup.sql
  • 预期结果：Cloud 与存储数据库备份完成。
  1. 在 Cloud UI 上移除需要变更的 mon 节点和计算节点。
  • 预期结果：平台侧不再引用故障节点。
  1. 在存储平台移除对应节点的 OSD、缓存分区并删除对应节点。
  • 如 UI 无法删除，可通过 API 强制删除：
  • DELETE /api/v1/block/osd
  • DELETE /api/v1/block/host
  • 预期结果：故障节点的存储资源记录被清理。
  1. 在底层删除故障节点 down 掉的 OSD：
   ceph osd --force purge osd.X
  • 预期结果：残留 OSD 记录被移除。
  1. 在正常节点数据库中删除异常节点授权记录：
   mysql -uroot -p<数据库密码> zstone
   delete from LicenseAppIdVO where hostIp='<故障节点管理IP>';
  • 预期结果：旧节点授权绑定关系被清理。
  1. UI 重新 reload License。
  2. 再次备份数据库。
  • 预期结果：进入重装前的干净状态。
  1. 重装故障节点
  2. 对故障节点重装系统并配置网络。
  • ISO：ZStack-x86_64-DVD-4.8.18-h84r.iso
  • 网络：
  • br_bond0: <管理网网段>
  • br_bond2: <存储网网段>
  • 预期结果：节点基础网络恢复。
  1. 配置服务器时间并写入硬件时间。
  • 预期结果：时间同步正常。
  1. 安装云平台管理服务，并申请临时授权。
  • 预期结果：Cloud 管理能力恢复。
  1. 修改新节点数据库密码：
   zstack-ctl change_mysql_password --root-password <当前数据库_root_密码> --user-name root --new-password <新数据库_root_密码>
  • 预期结果：数据库密码与现网统一。
  1. 修改 zstack.properties。
  • 预期结果：Cloud 配置指向正确环境。
  1. 在故障节点重新安装 ZStone 5.2.x。
  • 配置文件只写故障节点地址。
  • 提示：一定要先安装存储，再去正常节点安装高可用，否则 zstone 数据库可能会被覆盖。
  • 预期结果：故障节点的 ZStone 服务恢复。
  1. 重组双管理与高可用
  2. 在存活管理节点执行高可用安装：
   tar zxvf ZStack-Multinode-HA-Suite.tar.gz
   chmod +x zsha2 zstack-hamoo
   ./zsha2 sample-config > zs-install.config
  • 配置关键项：
  • gateway
  • virtualIp
  • myIp
  • peerIp
  • dbRootPass
  • interface
  • timeServer
  • 预期结果：双管理高可用配置就绪。
  1. 在故障节点按 VIP 重写 ZStone 配置。
  • 从存活管理节点搜索包含各管理 IP/VIP 的配置项，并在故障节点按需改写为 VIP。
  • 预期结果：双管理配置统一。
  1. 重启相关服务：
  • zstone-master
  • zstnmon
  • zstone-ui
  • temporal-history / frontend / matching / worker / web
  • postgresql-9.6.x
  • zstone-prometheus
  • zstone-alertmanager
  • zstone-pushgateway
  • thanos-query
  • thanos-sidecar
  • 预期结果：管理与监控服务恢复。
  1. 恢复纳管
  2. 在存储 UI 添加原节点，并添加缓存盘、数据盘。
  3. 添加 OSD 到存储内，并开启数据恢复。
  4. 在 Cloud 添加对应节点、mon 节点和计算节点。
  5. 最后重新打开高可用开关。
  • 预期结果：故障节点重新纳管完成，环境恢复到双管理状态。

验证方法

  • 检查 Cloud 与 ZStone 数据库恢复正常。
  • 检查故障节点恢复后的网络、时间、授权和管理服务正常。
  • 检查存储 UI 中缓存盘、数据盘、OSD 和 mon 恢复。
  • 检查双管理高可用恢复正常。

风险与回滚

  • 风险：这是管理节点重建 + 存储角色重组，若顺序错误可能影响 Cloud 与 ZStone 数据一致性。
  • 风险：警告若先装高可用再装存储，可能覆盖 zstone 数据库。
  • 风险等级：中。
  • 回滚：重建服务无法回退，若出现问题需要按报错逐项解决，而不是执行标准回滚。
上一篇ZStone 存储节点缓存盘更换下一篇ZStone 超融合节点内存扩容
ZStone 超融合管理节点重装与恢复 | 技术方案 · KB | ZStack 资源中心