虚拟化平台高可用、备份与迁移实战

虚拟化平台承载大量业务后，宿主机、共享存储、管理面和网络都成为共同故障域。高可用不能替代备份，快照不能替代备份，迁移成功也不等于业务正常。本文以 VMware vSphere、Microsoft Hyper-V 和 Proxmox VE 的共性为主，说明容量、高可用、备份、升级和跨平台迁移方法。

一、先画出故障域

管理面：vCenter / SCVMM / PVE Cluster
计算面：宿主机、CPU、内存、NUMA
网络面：管理、业务、迁移、存储、备份
存储面：SAN/NAS/Ceph/本地盘
保护面：快照、备份、复制、异地灾备

需要评估：

  • 单宿主机故障；
  • 单交换机/上联故障；
  • 单存储控制器或存储池故障；
  • 管理平台不可用；
  • 集群仲裁丢失；
  • 机柜、供电或机房故障；
  • 管理员误删除与勒索攻击。

二、容量按N+1或N+2计算

集群正常时平均利用率很低，不代表故障时有余量。按失去一台或两台最大宿主机后，剩余资源仍能承载关键虚拟机计算。

容量模型包含：

  • CPU 超分比与实际峰值；
  • 内存预留、气球、交换与 NUMA；
  • HA 重启预留；
  • 存储容量、IOPS、吞吐和延迟；
  • 备份窗口与快照增量；
  • 迁移和维护时的临时双份空间；
  • 未来增长与采购周期。

不要只看 vCPU 总数。CPU Ready、Co-Stop、NUMA 跨节点和内存交换更能反映虚拟机是否真正得到资源。

三、集群高可用

HA 通常在宿主机故障后于其他节点重启虚拟机，它不是无中断。业务仍需自身集群、负载均衡和数据复制。

检查：

  • 管理与心跳网络冗余；
  • 仲裁和见证位置；
  • 共享存储访问；
  • Admission Control；
  • 虚拟机启动顺序和依赖；
  • 亲和/反亲和规则；
  • 故障后 DNS、IP、许可证和外部依赖；
  • HA 事件是否真正触发业务恢复。

关键双机应用应使用反亲和，避免两个副本运行在同一宿主机或机柜。

四、虚拟机快照的边界

快照保存某个时间点后的变化块，长期保留会增加存储占用、元数据复杂度、备份时间和合并风险。

原则：

  • 仅短期用于变更保护；
  • 设置自动到期；
  • 监控快照大小和链深；
  • 数据库使用应用一致性机制；
  • 合并前确认存储空间和 I/O 余量；
  • 不把快照当作独立备份；
  • 高 I/O 虚拟机在业务低峰处理。

快照与原虚拟机位于同一存储，存储损坏时会一起丢失。

五、备份架构

采用 3-2-1 或更强策略：至少三份数据、两种介质、一份异地或离线。关键备份增加不可变、隔离账号和多因素认证。

备份记录：

  • 虚拟机配置；
  • 虚拟磁盘；
  • CBT/RCT 等增量状态；
  • 应用一致性与 VSS；
  • 保留周期；
  • 加密与密钥；
  • 恢复点校验；
  • 恢复演练。

备份“成功”不能证明可恢复。应自动启动隔离恢复副本，验证文件系统、服务、数据库和业务接口。

六、复制与灾备

存储复制、虚拟机复制和应用复制各有边界：

  • 存储复制可能同步逻辑损坏；
  • 虚拟机复制提供机器级恢复，但应用一致性需额外设计；
  • 应用复制最理解数据语义，但部署复杂。

灾备方案必须包含网络映射、DNS、证书、IP、路由、防火墙、外部依赖和回切。只验证“虚拟机能开机”远远不够。

七、网络设计

管理、迁移、存储、业务和备份流量应逻辑隔离，并根据吞吐决定是否物理隔离。

检查：

  • vSwitch/分布式交换机配置；
  • VLAN、MTU 和上联 Trunk；
  • bond/teaming/LACP；
  • 双交换机冗余；
  • MAC 学习与安全策略；
  • SR-IOV/直通对迁移和 HA 的限制；
  • 迁移流量是否挤占存储和业务。

端到端 Jumbo Frame 必须所有设备一致，不能只改宿主机。

八、存储设计

虚拟化存储的平均延迟可能掩盖单 LUN、单 datastore、单 OSD 或单磁盘组热点。

监控：

  • 前端与后端延迟；
  • IOPS 和吞吐；
  • 队列深度；
  • 路径状态；
  • 容量和精简置备超分；
  • 快照/克隆占用；
  • 存储重建；
  • 缓存和控制器状态。

精简置备提高利用率，也可能让多个层级同时超分。必须知道 guest、虚拟磁盘、datastore、LUN 和存储池各层真实空间。

九、NUMA与虚拟机规格

大型虚拟机不一定更快。vCPU 或内存跨 NUMA 节点会增加访问延迟，超大虚拟机也更难调度和迁移。

优化：

  • 从真实利用率确定 vCPU；
  • 关注 CPU Ready/等待；
  • 大型数据库理解 vNUMA；
  • 避免长期内存 balloon/swap；
  • 不把资源预留和限制随意混用；
  • 调整后用应用指标验证。

十、时间同步

宿主机和虚拟机均需可靠时间源。域成员 Windows 通常遵循域层次；Linux 使用 Chrony/NTP。避免宿主机工具同步与客户机 NTP 同时反复校时。

时间错误会影响 Kerberos、证书、数据库、日志关联和集群仲裁。

十一、维护与滚动升级

宿主机维护流程：

  1. 检查集群健康、容量和备份；
  2. 确认无异常快照和失败任务；
  3. 迁移或停止虚拟机；
  4. 进入维护模式；
  5. 升级固件、驱动、Hypervisor；
  6. 重启并检查硬件；
  7. 退出维护；
  8. 迁回少量工作负载观察；
  9. 再处理下一节点。

固件、网卡/HBA 驱动和 Hypervisor 版本需要遵循兼容矩阵。

十二、VMware专项

关注：

  • vCenter、ESXi 和硬件兼容；
  • HA/DRS 和 Admission Control；
  • vMotion、Storage vMotion；
  • datastore 延迟和路径；
  • vSphere Distributed Switch 备份；
  • Content Library 与模板；
  • 证书和 SSO；
  • 生命周期管理；
  • 第三方备份的 VADP/CBT 状态。

迁出 VMware 时先盘点 VMware Tools、虚拟硬件版本、磁盘控制器、网络和快照链。

十三、Hyper-V专项

关注：

  • Failover Clustering；
  • CSV、SMB3 或 SAN；
  • Live Migration；
  • Replica；
  • VSS/RCT 备份；
  • SET/虚拟交换机；
  • Cluster-Aware Updating；
  • 动态内存与 NUMA；
  • 检查点类型和合并。

域、DNS 和时间是 Hyper-V 集群稳定的重要基础依赖。

十四、Proxmox VE专项

关注：

  • Corosync 低延迟网络和 quorum；
  • QDevice；
  • PVE Cluster 配置；
  • Ceph 或共享存储；
  • HA Group；
  • Live Migration；
  • Proxmox Backup Server；
  • ZFS ARC、快照与复制；
  • 节点版本和升级顺序。

不要在失去 quorum 时随意修改 expected votes 强行恢复，先确认节点和数据的真实状态，避免分区双写。

十五、跨平台迁移方法

迁移前资产发现：

  • OS 和启动方式 BIOS/UEFI；
  • 磁盘格式、控制器和分区；
  • 网卡、VLAN、IP 和 MAC 依赖；
  • 驱动和 Guest Tools；
  • 快照、直通和加密；
  • 许可证绑定；
  • RPO/RTO 和停机窗口；
  • 应用依赖与业务验证人。

流程：

  1. 按应用分组，不按虚拟机孤立迁移；
  2. 先迁测试和低风险业务；
  3. 转换磁盘并安装目标驱动；
  4. 隔离启动，避免 IP 冲突；
  5. 验证系统、服务、性能和时间；
  6. 增量同步或安排停机切换；
  7. 更新网络、DNS、监控和备份；
  8. 保留回退窗口；
  9. 确认后再退役源虚拟机。

十六、迁移失败常见原因

  • 源虚拟机有快照链或磁盘错误；
  • 目标缺少存储/网卡驱动；
  • UEFI、Secure Boot 或磁盘控制器不同；
  • Windows 激活和设备变化；
  • Linux initramfs 未包含目标驱动；
  • IP、MAC、路由或防火墙未更新；
  • 数据库在复制期间持续写入；
  • 目标 CPU 指令集不兼容；
  • 应用许可证绑定硬件标识。

十七、性能基线

迁移和升级前后比较：

  • 应用 P95/P99；
  • VM CPU Ready、Co-Stop、内存交换；
  • 宿主机 CPU、NUMA 和功耗；
  • 虚拟磁盘延迟、IOPS、吞吐；
  • 网络丢包和吞吐；
  • 存储后端延迟；
  • 备份窗口；
  • 迁移时间。

只比较“CPU 使用率”无法判断虚拟化性能是否退化。

十八、安全治理

  • 管理平台独立账号与 MFA；
  • 管理网络不直接暴露互联网；
  • 角色最小权限；
  • API 和服务账号定期轮换；
  • 模板和 ISO 来源可信；
  • 宿主机及时修补；
  • 禁止业务管理员任意挂载宿主机设备；
  • 备份平台与生产身份隔离；
  • 审计控制台、快照、克隆、导出和删除操作。

管理平台被攻破等同于大量服务器被攻破，应采用高权限管理工作站和独立备份。

十九、监控清单

  • 集群、仲裁、HA 和管理面；
  • 宿主机硬件、温度、内存、网卡/HBA；
  • CPU Ready、NUMA、内存 balloon/swap；
  • 数据存储容量、延迟、路径和重建；
  • 虚拟交换机、上联和丢包；
  • 快照年龄、大小和链深；
  • 备份成功、复制延迟和恢复验证；
  • 证书、许可证和版本兼容；
  • 孤立虚拟机、废弃磁盘和资源浪费；
  • 关键业务的端到端探测。

二十、上线检查清单

  • [ ] 故障域、仲裁和管理依赖已记录；
  • [ ] 按失去最大节点后的容量进行规划；
  • [ ] 关键副本有反亲和和应用级高可用；
  • [ ] 管理、业务、存储、迁移和备份网络可控；
  • [ ] 快照短期使用并有自动过期；
  • [ ] 备份不可变、异地且通过恢复演练；
  • [ ] 宿主机升级按兼容矩阵滚动进行；
  • [ ] 管理账号、网络和备份身份隔离；
  • [ ] 迁移按应用依赖分组并保留回退；
  • [ ] 灾备演练覆盖网络、DNS、证书和数据一致性。

二十一、结语

虚拟化把服务器集中管理，也把风险集中到了管理面、共享网络和存储。可靠的平台必须把 HA、备份、复制和业务高可用分清，持续验证容量和故障域，并用真实恢复演练证明系统能够在宿主机、存储甚至机房故障后继续运行。

参考资料

Copyright © yan-jian.com 2023 - 2026 · Powered by GitBook更新时间： 2026-10-28 21:12:06

results matching ""

    No results matching ""