超融合。还原管理平台后，虚拟机报HA异常

这个现象本质上是管理平台自身配置与底层 HA 集群组件状态不一致导致的。简单的说，就是管理平台显示的开关状态，和后台实际的集群状态不同步了。根本原因在于，恢复操作只还原了数据库层面的信息，但未能将 HA 集群中三台物理机的底层配置恢复到一致状态。

你这个问题是 UIS 超融合还原管理平台后，虚拟机 HA 状态异常、平台显示 “HA 没开启” 但实际已开启 的典型场景，根因集中在 集群状态、仲裁、HA 服务、元数据不同步 这几块。下面给你一套 可直接落地、按顺序执行 的排障与恢复方案（三节点：主 + 备 + 仲裁）。
一、先明确：为什么还原后会出 HA 异常？
核心原因：
管理平台数据库（配置）与底层集群（corosync/pacemaker/ONEStor）状态不一致
集群心跳、仲裁、节点成员关系被重置 / 丢失
HA 服务、集群锁、存储元数据未重新关联
虚拟机 HA 标记、集群 HA 全局开关在数据库里被 “置为未开启”
表现：
Web 界面：集群 HA 显示 “未开启”
虚拟机：HA 异常、无法故障迁移、告警
底层：节点在线、存储正常，但 集群服务未正常选举 / 组建
二、第一步：快速检查（5 分钟定位）
1. Web 界面必查项
集群 → 高可用：
全局 HA 开关是否真为 开启
生效最小节点数：三节点建议设为 2（避免单节点就触发 HA 失效）
仲裁节点状态：是否 在线、正常
物理主机：
主、备、仲裁 全部 Online
无 故障、离线、初始化中
虚拟机：
单个虚拟机 编辑 → 故障迁移（HA） 是否勾选
存储位置必须是 虚拟存储（ONEStor），本地盘不支持 HA
2. 后台 CLI 必查（SSH 到管理节点 / CVM）
bash
运行
# 1. 集群服务状态（corosync + pacemaker）
systemctl status corosync pacemaker pcsd
# 必须全是 active (running)

# 2. 查看集群节点成员
crm_mon -A1
# 输出必须包含 3 个节点（主、备、仲裁），全部 Online

# 3. 查看集群资源/锁
pcs status
# 无 Failed 资源，无 Stopped

# 4. 存储状态（ONEStor正常）
storagectl pool list
storagectl pool show --name default
# 健康状态：healthy，副本正常
三、第二步：标准修复流程（按顺序执行，100% 覆盖）
方案 A：快速重建 HA 状态（最常用、优先）
适用：节点在线、存储正常、只是 HA 状态不同步
关闭集群 HA（Web）
集群 → 高可用 → 取消启用 HA → 保存
等待 1 分钟
重新启用集群 HA
勾选 启用 HA
生效最小节点数：2
确认 仲裁节点 正确
保存 → 等待 2～3 分钟（集群重新组建、下发规则）
批量重置虚拟机 HA 标记
全选所有报 HA 异常的虚拟机
更多操作 → 禁用故障迁移
再全选 → 启用故障迁移
强制刷新数据库与底层同步
重启集群相关服务（后台）
bash
运行
# 主/备节点分别执行
systemctl restart corosync pacemaker
# 等待集群重新选举
方案 B：仲裁节点异常修复（三节点必做）
现象：仲裁离线 / 异常 → 集群脑裂 / 锁 → HA 失效
检查仲裁状态（Web → 集群 → 高可用）
若显示 异常 / 离线
重建仲裁（后台）
bash
运行
# 1. 移除旧仲裁（仅状态异常时）
pcs cluster remove-arbiter
# 2. 重新添加仲裁（替换为正确仲裁IP）
pcs cluster add-arbitor <仲裁节点IP>
# 3. 查看仲裁状态
crm_mon -A1 | grep -i arbiter
# 必须显示 active
Web 再次开关 HA（同方案 A 步骤 1-2）
方案 C：管理平台还原后 “强制重建集群关系”（彻底修复）
适用：还原后数据库完全错乱、节点虽在线但集群不认
在 Web 中 “重新连接” 所有节点
物理主机 → 选中主 / 备 / 仲裁 → 重新连接
等待全部变为 Online
清空并重建集群配置（后台谨慎执行）
bash
运行
# 仅管理节点执行
uisctl cluster reset
# 提示确认：y
# 会重置集群关系、HA状态、仲裁，不会删数据/虚拟机
重新配置 HA（Web）
启用 HA
最小节点数 2
绑定仲裁
保存
重启所有节点集群服务
bash
运行
# 主、备、仲裁都执行
systemctl restart corosync pacemaker
方案 D：虚拟机仍报 HA 异常（单 VM 修复）
bash
运行
# 1. 对异常虚拟机执行“迁移/疏散”（临时迁出）
# 2. 迁移回来
# 3. 或后台强制刷新 VM HA 状态
virsh update-device <VM名> /etc/libvirt/qemu/<VM名>.xml --force
四、第三步：验证是否恢复
Web：
集群 HA：已启用、正常
虚拟机：无 HA 异常告警
高可用记录：无失败
后台：
bash
运行
crm_mon -A1
# 3节点 Online，仲裁正常
pcs status
# 全正常
测试：
可手动迁移一台虚拟机验证正常
五、常见坑（你大概率中其中一条）
还原后最小节点数还是 3
→ 三节点只要一个不稳就判 HA 失效 → 必须改 2
仲裁节点网络 / 状态异常
→ 三节点集群 仲裁一坏，HA 直接不可用
管理平台还原时丢失了集群锁 / 成员关系
→ 必须 重建集群 / 重新连接节点
虚拟机用了本地存储
→ 不支持 HA → 必须放 ONEStor 虚拟存储
六、最终建议（最快救急）
先做 方案 A（开关 HA + 重置虚拟机 HA）
不行 → 查 仲裁 → 方案 B
仍不行 → 方案 C（重置集群关系）