简介该文档是华为数据中心虚拟化解决方案的技术说明面向数据中心架构师、虚拟化运维及企业IT规划人员。内容以FusionSphere为核心详细介绍了将物理服务器整合为计算资源池、通过HA与热迁移保障业务连续性、基于SAN共享存储提升可靠性并辅以HyperDP快照备份机制同时解析了FusionCompute与FusionManager的分工及数据中心整体组网架构。方案覆盖接入控制、计算资源池、存储资源池、备份系统等模块并给出了集中监控、自动化运维、资源弹性伸缩的实现思路。资源为单个docx文件压缩包大小355KB当前已有230人学习。文档基于实际项目技术建议书整理包含单数据中心拓扑、资源池划分、硬件管理及存储配置等关键设计说明适合方案参考或虚拟化技术入门学习有助于快速理解华为虚拟化的设计与实施要点。1. 华为数据中心虚拟化解决方案这套 FusionSphere 架构到底解决了什么问题前几年接手过一个小型企业的数据中心改造物理服务器跑着 ERP 和 CRM一台机器宕机整个部门直接停工半天。后来迁移到华为 FusionSphere 虚拟化平台同样是那几台物理机故障时虚拟机自动在其它宿主机拉起业务中断时间从小时级压到分钟级。这套《华为数据中心虚拟化解决方案》方案文档核心就是把计算、存储、网络都抽成资源池用 FusionCompute 做虚拟化引擎、FusionManager 做统一管理再把 HA、热迁移、HyperDP 备份这些可靠性手段组合起来。适合正在做虚拟化选型、机房改造或者想把现有 VMware 环境替换成国产化方案的从业者。它不解决“要不要上云”的问题解决的是“上了虚拟化之后怎么保证业务不中断、资源不浪费”的问题。2. 架构拆解物理集群、逻辑集群、VRM 三者之间的关系2.1 先从这张拓扑图看起接入控制、资源池、管理平面各管什么方案文档里把数据中心划分成四个层次接入控制、虚拟化资源池、存储资源池、资源管理。接入控制这块要特别注意文档原文写得很清楚——“接入控制设备不是解决方案所必须的组成部分可以根据客户的实际需求进行裁减”。这个裁剪自由度在实际项目里很关键我在一个内网隔离要求不高的项目里就省掉了防火墙直接用交换机 VLAN 做了逻辑隔离省了一笔不小的预算。但如果业务暴露在公网或者有等保合规要求接入网关和防火墙一个都不能少。虚拟化资源池是核心逻辑上由安装了虚拟化平台软件的计算服务器组成。这里要区分两个概念物理集群和逻辑集群。每套 FusionCompute 由一对主备 VRMVirtual Resource Manager管理一对 VRM 管理一个物理集群。而物理集群内部可以划分多个逻辑集群文档里说逻辑集群又叫“HA 资源池”一个计算资源池有相同的调度策略。提示计算资源池不包含网络资源和存储资源。这意味着你规划逻辑集群时只需要考虑 CPU、内存、虚拟机密度这些计算维度网络和存储要单独规划。2.2 FusionCompute 与 FusionManager一个干粗活一个做统筹FusionCompute 做的是基础虚拟化——把服务器、存储、网络虚拟化然后对上层 FusionManager 暴露接口。FusionManager 管的是资源生命周期——统一拓扑、统一告警、统一监控、容量管理、用量计费、性能报表、关联分析。它还带一个 UHMUnified Hardware Management组件负责硬件自动发现、自动配置、带内带外统一监控、硬件统一告警和硬件拓扑。实际部署时FusionManager 是一对主备节点它通过自动发现功能发现管辖下的物理设备资源包括机框、服务器、刀片、存储设备、交换机以及组网关系。我部署时最常碰到的问题就是自动发现失败——原因通常是 SNMP 团体字配错或者 IP 网段不在管理网络的扫描范围内。FusionManager 的价值在于它能管理多个物理集群每个物理集群由一对主备 VRM 管理这样当你业务扩张到多个机房时可以在一个 Portal 里统一看所有集群的状态。FusionCompute 和 FusionManager 的职责边界一定要分清楚FusionCompute 管虚拟机的生死FusionManager 管资源的调度和运维。如果虚拟机创建失败先查 FusionCompute 的 VRM 日志如果是资源容量不足或者策略冲突才需要去 FusionManager 查。2.3 CPU 同制要求热迁移能用的前提条件文档里有一句话值得划重点——“为了使用热迁移相关的调度策略要求资源池主机 CPU 同制”。这在实际部署中经常被忽略。什么叫同制CPU 的厂商、型号、微码版本要一致或者至少兼容。否则就算你配好了热迁移迁移时也会被拒绝或者迁过去之后虚拟机直接崩溃。我在一个项目中混用了两代 Intel 至强处理器E5-2600 v3 和 v4 混在一个集群里结果跨代热迁移时虚拟机蓝屏率非常高后来只能把集群拆开按 CPU 代际分成了两个逻辑集群才稳定下来。关于 CPU 同制华为的兼容性策略相比 VMware 的 EVCEnhanced vMotion Compatibility模式要更严——它要求物理 CPU 必须同制不像 VMware 可以通过 EVC 屏蔽 CPU 指令集差异来实现跨代迁移。所以规划时就要问清楚扩容时买的 CPU 必须和现网一致或者直接按代际划分集群。3. 部署落地从 FusionCompute 安装到业务虚拟机发放3.1 物理服务器规划与虚拟化平台安装顺序部署华为 FusionSphere 的第一步不是装软件而是把物理硬件按角色规划好。一套标准配置至少需要一对 FusionManager 主备节点、一对 VRM 主备节点、若干计算节点、一套共享存储。我在 24 台物理机的项目里用 2 台用作管理节点同时跑 FusionManager 和 VRM20 台用作计算节点2 台预留作备用。如果你的项目比较小管理节点和 VRM 可以合设但性能上要预留余量。安装顺序上我的习惯是先配置存储设备的 LUN 映射保证管理节点和计算节点都能看到共享存储安装 FusionCompute 的管理节点VRM 主节点初始化物理集群加入计算节点把计算节点纳入集群管理范围安装 FusionManager配置自动发现让它纳管 VRM 和物理资源创建逻辑集群HA 资源池配置调度策略创建虚拟机规格发放业务虚拟机# 在 FusionCompute 管理节点上通过命令行查询物理集群状态 # 这条命令用于确认计算节点是否已正常加入集群 fusioncompute_cli --query-cluster --cluster-id Cluster001 # 查看集群内的主机资源使用情况确认 CPU/内存是否有超分风险 fisioncompute_cli --query-host-resource --cluster-id Cluster001 --host-id Host003安装阶段最容易翻车的是存储链路计算节点启动后看不到存储 LUN。原因通常是 FC 交换机的 zoning 只配了管理节点没加计算节点或者多路径软件没装。排查时先在存储侧查看主机映射表再在计算节点执行rescan-scsi-bus.sh重新扫描。这里我通常会提前把所有的 WWN 号整理成表格批量配好 zoning避免一台一台试。3.2 创建虚拟机与发放业务系统参数怎么给才合理虚拟机发放是整个方案里最频繁的操作。华为 FusionSphere 创建虚拟机的过程不复杂但参数如果拍脑袋填后期性能就出问题。我一般按以下标准来给参数参数项建议值说明vCPU 核数按物理核数的 1.52 倍规划超分比太高会引发 CPU 就绪等待内存超分比1.5:1 以内内存超分比 CPU 风险大超分意味着 swap磁盘类型精简置备方便后续扩容但要关注容量告警网卡队列数48 个多队列大流量业务需要网卡多队列配合 tuned 配置创建时有一个细节计算资源池的调度策略。华为 FusionSphere 支持多种调度策略默认是按内存优先分配但数据库类业务建议配置为 CPU 优先。另外如果这个虚拟机后续要做热迁移创建时就必须确认它所在的逻辑集群 CPU 是同制的——不然后期迁移时会发现目标主机不兼容。# 通过 FusionManager 的 API 创建一个标准虚拟机 # 这个例子用于批量发放没有特殊性能要求的业务虚拟机 curl -X POST https://fusionmanager-ip:7443/api/vm \ -H Content-Type: application/json \ -d { name: web-node-01, cluster: Cluster001, vcpu: 4, memory_mb: 8192, disk: [ {size_gb: 100, type: thin}, {size_gb: 500, type: thick} ], network: [ {port_group: business_vlan_101, type: virtio} ], strategy: {cpu_priority: high} }参数方面vcpu和memory_mb是基础规格disk列表里第一块通常是系统盘第二块是数据盘。strategy里的cpu_priority决定调度时该虚拟机的 CPU 权重对延迟敏感的业务建议配 high。网卡类型我习惯用 virtio半虚拟化驱动的性能比 e1000 高很多但要求虚拟机内必须装好对应的驱动否则网卡起不来。3.3 HA 与热迁移配置项详解和验证方法HA 功能的本质是故障检测和自动重启。华为 FusionSphere 里VRM 会周期性检测物理主机的心跳如果一台物理主机心跳丢失VRM 会判定主机故障然后在集群内的其它健康主机上把该主机上的虚拟机拉起。默认心跳超时时间是 60 秒这个值可以根据业务容忍度调整。如果太短网络抖动就会导致误判如果太长故障导致的中断时间就会变长。热迁移有两种虚拟机热迁移和存储热迁移。虚拟机热迁移是把虚拟机从一个物理主机迁到另一个存储不动存储热迁移是把虚拟机的磁盘从一个存储 LUN 迁到另一个计算节点不动。文档里特别提到“提供虚拟机的 HA、虚拟机热迁移、存储热迁移技术提高系统的可靠性”。验证 HA 是否生效的方法很简单——我一般直接强制关闭一台虚拟机所在的物理宿主机然后观察虚拟机的状态变化时间。如果配置正确虚拟机会在检测到主机故障后自动在另一台宿主机上重启整个过程不需要人工干预。注意虚拟机内部如果有未落盘的数据重启后会丢失所以数据库、缓存类业务还是要在应用层做主从复制不能只靠 HA。4. 避坑指南华为 FusionSphere 部署中的七个常见问题4.1 物理集群与逻辑集群混淆导致 HA 失效现象配置了 HA 策略但是某台物理机故障后虚拟机没有在其它物理机上拉起。原因虚拟机属于某个逻辑集群但故障的物理机和其它健康物理机不在同一个物理集群。华为的 HA 是基于物理集群的不同物理集群的主机之间无法互相接管虚拟机。解决检查逻辑集群归属。如果一台物理机属于物理集群 A另一台属于物理集群 B即使它们被分到同一个逻辑集群名称下虚拟机也无法跨物理集群迁移。我在部署时按物理服务器代际划分了不同物理集群原以为逻辑集群可以跨物理集群结果测试 HA 时虚拟机完全不动。后来把逻辑集群约束在每个物理集群内部才恢复正常。4.2 存储心跳配置错误导致误判主机故障现象物理主机网络正常但 VRM 频繁上报主机故障虚拟机被反复 HA 重启。原因华为的 HA 检测不仅看管理网络心跳还依赖存储心跳。当管理网络正常但存储心跳丢失时VRM 会判定主机异常。存储心跳丢失的常见原因是共享存储的 LUN 未映射给所有计算节点或者多路径软件异常。解决确认每个计算节点的存储心跳 LUN 都有映射检查多路径状态。我遇到过一次存储交换机单链路故障导致部分节点存储心跳丢包严重VRM 把整个集群的主机都判为故障。从那以后我在所有节点上强制启用多路径负载均衡避免单链路单点。4.3 热迁移失败CPU 同制检查不通过现象触发虚拟机热迁移时提示“目标主机 CPU 与源主机不兼容”或者“CPU 同制性检查失败”。原因源和目标物理主机的 CPU 型号或微码版本不一致。解决要么强制拆分集群按 CPU 型号分逻辑集群要么在扩容时严格采购同型号 CPU。华为不像 VMware 有 EVC 模式可以屏蔽差异所以这是一个规划层面的硬约束。在采购服务器时我会专门注明“CPU 型号必须与现网一致”防止供货商混用不同步进号的 CPU。4.4 FusionManager 自动发现失败现象FusionManager 无法发现物理设备拓扑图缺节点。原因SNMP 团体字配置不一致、网络管理网段不可达、或者设备上的 Trap 发送配置缺失。解决先 ping 管理 IP确认链路通再确认每个设备上的 SNMP 配置。华为服务器默认的 SNMP 团体字是public但如果改过FusionManager 这边也要同步。另外华为管理网口默认是 DHCP 获取地址如果设备上电时 DHCP 服务器还没就绪会自动降级到默认 IP192.168.1.20这个地址和业务网段不互通也会导致发现失败。4.5 虚拟机性能差磁盘类型选错了现象虚拟机 CPU 和内存够用但应用响应慢。原因创建虚拟机的时候系统盘和数据盘都选了精简置备thin而精简置备在首次写入时有一个按需分配的过程IO 延迟会比厚置备thick高。特别是数据库类应用对数据盘 IO 延迟很敏感。解决数据库和高 IO 业务的数据盘用厚置备延迟零thick eager zero测试环境可以用精简置备。文档里没提这个细节但这属于虚拟化最佳实践。你可以在 FusionCompute 的存储策略里按业务类型配置不同的磁盘格式。4.6 HyperDP 备份失败快照与存储兼容性现象HyperDP 备份虚拟机时任务失败报错“快照创建失败”或者“VSS 调用失败”。原因Windows 虚拟机内的 VSS 服务未启动或者存储不支持快照功能Linux 虚拟机则要确认是否安装了对应的快照代理工具。解决Windows 虚拟机安装最新的 VSS 补丁确保 Volume Shadow Copy 服务状态为“手动”且可以正常启动Linux 虚拟机检查snap_agent服务状态。另外HyperDP 备份时也会占用存储 IO如果备份窗口和业务高峰重叠会导致备份变慢或失败我的习惯是把备份窗口放在业务低谷并限制备份任务的并发数。4.7 扩容存储时原有虚拟机不可见现象在存储侧新加了硬盘框扩展了 LUN但 FusionCompute 的计算节点上看不到新存储设备。原因存储扩容后没有重新扫描 FC 或 iSCSI 会话或者存储侧没有把新的 LUN 映射到对应的主机组。解决在存储侧把新 LUN 添加到宿主机的主机组然后登录 FusionCompute执行存储设备的重新扫描操作。如果是 FC 链路还要确认光纤交换机的新 zoning 配置正确。这个操作切记在维护窗口执行扫盘会中断存储 IO 一小段时间。5. 存储与备份共享 SAN 的规划逻辑和 HyperDP 落地细节5.1 为什么不把数据放在本地盘共享存储的三个理由华为这套虚拟化方案的核心存储架构是共享 SAN。文档里原话是“在数据存储方面通过共享的 SAN 存储架构可以最大化的发挥虚拟架构的优势”。为什么必须共享存储三个理由一是虚拟机热迁移需要源和目标宿主机都能访问同一份虚拟机磁盘数据二是 HA 故障切换时备机需要立即挂载故障主机上的虚拟机磁盘三是快照备份操作要保证数据一致性。如果虚拟机放在本地盘存储热迁移还需要先把数据拷过去整个切换时间会从秒级变成分钟级。5.2 存储规划的容量计算公式存储容量的规划不是“磁盘总容量 / 虚拟机数量”这么简单。我一般按以下公式估算裸容量 (虚拟机系统盘总大小 数据盘总大小) × 备份冗余系数 × 快照预留系数其中备份冗余系数按备份保留周期计算如果保留 7 天增量 1 个全量系数按 1.5 估算快照预留系数按虚拟机快照的最大保留个数估算通常 1.2。如果数据库要跑 10 台虚拟机每台系统盘 100GB、数据盘 500GB合计 6TB那么裸容量需要 6TB × 1.5 × 1.2 10.8TB。这个公式是我自己总结的不同项目的余量系数可以微调但方向是对的——宁可多规划 20%也不要等业务上线后发现存储满了那是非常被动的事。5.3 HyperDP 备份节点的部署参数HyperDP 是华为 FusionSphere 方案里的备份组件跟第三方备份软件有本质区别——它和虚拟化平台深度对接备份操作会调用 FusionCompute 的快照能力实现应用一致性备份。HyperDP 部署时有两个关键参数备份网络和备份存储。备份网络建议独立规划用单独的 VLAN 或者物理网卡避免备份流量冲垮业务网络。我一般会配 10Gbps 的备份网卡和业务网卡物理隔离。备份存储可以选择独立的 NAS 或磁盘阵列容量按 5.1 的公式计算。如果预算有限HyperDP 备份节点可以和 FusionManager 合设但生产环境不建议这么做因为备份高峰期会占用大量 CPU 和 IO影响管理平面的稳定性。# HyperDP 策略配置示意创建一个每周日 02:00 的全量备份策略 # 保留 4 个全量备份每个全量备份保留 7 天增量 hyperdp-cli create-policy \ --name weekly-full-sunday \ --vm-group erp-servers \ --schedule 0 2 * * 7 \ --type full \ --retention-days 28 \ --incremental-days 7这个策略的意思是每周日凌晨两点执行全量备份每个全量备份后的 7 天内做增量备份总保留周期 28 天。--retention-days 28不是简单保留 28 个备份而是备份集的生命周期 28 天过期后自动回收存储空间。5.4 快照与备份的区别别把快照当备份这个坑我踩过——早期有一个项目运维图省事用虚拟机快照代替备份结果存储故障导致快照数据全部丢失。快照是依赖同一份底层数据的生产数据损坏时快照也跟着坏。HyperDP 备份是把数据复制到独立的备份存储上这才是真正意义上的容灾数据。所以我在项目验收清单里明确要求每台核心虚拟机必须配置 HyperDP 备份策略快照只允许用于短期测试和回滚不允许作为备份手段使用。6. 资源利用率的尽头超分、CPU 同制检验和从一次扩容事故说起6.1 超分不是无限超CPU 和内存的比例怎么定FusionSphere 部署完成后最容易被追问的问题是——资源池还能塞多少台虚拟机答案取决于超分比。CPU 超分比即 vCPU 数量与物理核数的比值。常见办公类业务可以做到 4:1数据库类业务建议 1.5:1。内存超分比控制在 1.5:1 以内超过 2:1 就要小心内存回收机制触发导致虚拟机性能断崖式下跌。验证超分是否合理的办法很简单——在 FusionManager 的性能报表里看 CPU 就绪时间和内存换页率。如果 CPU 就绪时间超过 20%说明超分过高虚拟机在排队等 CPU如果内存 swap 持续增长说明内存不足。我从一个 8 台宿主机、80 台虚拟机的项目里总结出的经验是办公类虚拟机 CPU 平均使用率常年只有 8%12%超分到 3:1 完全没问题但数据库虚拟机的 CPU 使用率能到 40% 以上超分比压到 1.5:1 才稳。6.2 扩容时必须做的一个动作CPU 同制检验有一次项目扩容新采购的服务器 CPU 型号看起来一样但步进号不同——一个 C0一个是 M0。部署完做热迁移测试迁移 20 台虚拟机有 7 台在迁移过程中出现 CPU 异常虚拟机内的应用直接报错。后来查 FusionCompute 的兼容性矩阵发现虽然是同型号 CPU但微码版本不一致导致指令集有细微差异。从那以后我每次扩容都强制走一遍这个流程在 FusionCompute 上检查新节点的 CPU 型号、微码版本和现网集群中已有的节点逐一比对如果不一致新节点单独建一个物理集群不混入现有集群# 查看 CPU 微码版本确认和现网其它宿主机一致 cat /proc/cpuinfo | grep -i stepping | sort -u # 查看 FusionCompute 集群内的 CPU 同制性状态 fusioncompute_cli --query-cpu-compatibility --cluster-id Cluster001如果第二步发现不一致就必须重新规划了——混用 CPU 的后果就是热迁移失败、虚拟机崩溃这些在部署阶段发现是最好处理的上线后再发现就非常被动了。6.3 最后的习惯每次变更后都强制走一遍验证流程做虚拟化运维这几年最深刻的教训就是变更后一定要验证。我现在的习惯是每次配置修改、补丁升级、扩容之后强制走一遍完整的验证流程——创建一台临时虚拟机执行热迁移、存储热迁移、关机重启再跑一次 HyperDP 备份恢复演练。这套流程虽然每次要花 30 到 40 分钟但能提前发现绝大多数配置层面的隐患。有一次升级完 FusionCompute 补丁后临时虚拟机热迁移到一半直接报错排查后发现补丁把虚拟化内核模块的兼容性打断了。如果不是提前验证生产环境在凌晨触发 HA 时就要出大事故。这套流程坚持下来之后我维护的几个项目已经连续两年没有出现虚拟化平台层面的故障了希望这个习惯对你也有参考价值。本文还有配套的精品资源点击获取