1. 从物理服务器到虚拟化资源池FusionCompute到底在做什么很多人第一次接触FusionCompute看到计算虚拟化这几个字脑子里浮现的就是把一台服务器切成好几台虚拟机。这个理解不算错但太浅了。如果只是切分那和普通的桌面虚拟化软件有什么区别FusionCompute真正解决的问题是把一堆物理服务器变成一个统一的、可调度、可弹性伸缩的计算资源池让上层业务不再关心自己跑在哪台机器上。我在实际项目中见过太多这样的情况一台物理服务器CPU利用率长期在10%以下内存倒是快满了旁边另一台机器CPU跑得冒烟内存却空着一大半。这种资源错配在传统物理部署模式下几乎无解因为业务和硬件是绑死的。FusionCompute要做的就是打破这种绑定关系把CPU、内存这些计算资源从具体的物理设备上抽出来变成可以按需分配的资源池。这个抽的过程核心依赖两个东西Hypervisor层和资源调度层。Hypervisor负责在单台物理机上创建和管理虚拟机FusionCompute用的是基于Xen深度定制的虚拟化引擎后来版本也支持KVM架构。资源调度层则负责跨物理机的资源分配、迁移和负载均衡。两者配合才能实现从单机虚拟化到集群虚拟化的跨越。适合读这篇内容的人大概分三类一是刚接触云计算基础设施、需要理解计算虚拟化基本原理的运维新人二是正在做私有云规划、需要评估FusionCompute能力的架构师三是已经用上了FusionCompute但对其内部机制一知半解的工程师。不管你是哪一类接下来的内容都会从实际操作的视角把计算虚拟化这件事拆开讲清楚。2. 计算虚拟化的底层逻辑CPU和内存是怎么被骗过去的2.1 CPU虚拟化的三种实现路径与FusionCompute的选择CPU虚拟化的核心难题在于x86架构的CPU最初设计时并没有考虑过要同时运行多个操作系统。有些指令在特权模式下执行虚拟机里的操作系统以为自己有最高权限实际上它只是宿主机上的一个进程。怎么处理这些特权指令历史上出现了三种方案。第一种是全虚拟化通过二进制翻译技术在运行时动态扫描并替换掉虚拟机发出的特权指令。这种方式不需要修改Guest OS兼容性最好但性能损耗较大。第二种是半虚拟化需要修改Guest OS内核让虚拟机里的操作系统主动配合把特权操作通过Hypercall交给Hypervisor处理。性能好但要求操作系统开源可改。第三种是硬件辅助虚拟化Intel的VT-x和AMD的AMD-V直接在CPU硬件层面增加了新的指令集和运行模式让Hypervisor可以高效地拦截和处理特权指令。FusionCompute主要走的是硬件辅助虚拟化路线同时结合了半虚拟化的优化手段。在实际部署中你需要在物理服务器的BIOS里确认VT-x或AMD-V已经开启。这个看似简单的步骤我见过至少三次因为BIOS里虚拟化技术没开导致安装失败的情况。不同品牌的服务器这个选项的位置和叫法还不一样有的叫Intel Virtualization Technology有的叫VT-x有的藏在Advanced CPU Configuration里面。注意安装FusionCompute之前务必进BIOS确认虚拟化技术已启用。如果装完才发现没开需要关机重启进BIOS修改已经配置好的虚拟机虽然不会丢但整个主机需要重新进入维护模式影响业务连续性。2.2 内存虚拟化的地址转换与开销控制内存虚拟化比CPU虚拟化更复杂。物理机上操作系统通过页表把虚拟地址转换成物理地址。到了虚拟化环境多了一层Guest OS的虚拟地址要先转成Guest物理地址再转成Host物理地址最后才是真正的机器物理地址。这个多出来的转换层如果全靠软件模拟性能会惨不忍睹。硬件辅助的EPTIntel和NPTAMD技术解决了这个问题让地址转换在硬件层面完成大幅降低了开销。FusionCompute在支持这些技术的CPU上会自动启用你不需要手动配置。但有一个参数值得关注内存超分配比率。内存超分配的意思是你给虚拟机分配的内存总和可以超过物理机实际内存。比如物理机有128GB内存你可以给10台虚拟机各分配16GB加起来160GB。这能提高内存利用率但前提是这些虚拟机不会同时用满自己的内存。如果同时用满Hypervisor就要通过交换Swap把部分内存页写到磁盘上性能会急剧下降。我的经验是生产环境内存超分配比率控制在1.2到1.5之间比较稳妥。超过1.5一旦业务高峰期集中访问磁盘I/O会成为瓶颈。测试环境可以放宽到2.0甚至更高但也要监控Swap使用率。2.3 虚拟机监控器在资源分配中的实际角色Hypervisor不只是做地址转换和指令拦截它还负责虚拟机的生命周期管理、设备模拟、资源限额控制。FusionCompute的Hypervisor层对每台虚拟机的CPU和内存使用都有精细的控制策略。CPU方面你可以设置预留、限额和份额。预留是保证给虚拟机的最低CPU资源限额是上限份额决定资源竞争时的分配权重。举个例子两台虚拟机都设置了2000MHz的预留但物理机只剩1500MHz可用这时候份额就起作用了——份额高的那台会优先获得资源。内存方面除了预留和限额还有内存复用技术。FusionCompute支持内存页共享和内存气泡。页共享是把多台虚拟机中相同内容的内存页合并成一份比如多台Windows虚拟机都加载了同样的系统文件这些文件在内存里只存一份。内存气泡则是Hypervisor动态回收虚拟机暂时不用的内存分配给其他需要的虚拟机。这些技术听起来很美好但实际使用中要注意内存页共享对异构环境效果有限如果每台虚拟机的业务数据都不一样共享率会很低。内存气泡则要求虚拟机里安装Tools工具否则Hypervisor无法感知哪些内存页是空闲的。3. 从零搭建一个可用的计算资源池操作路径与关键决策3.1 集群规划为什么不能把所有主机塞进一个集群FusionCompute里集群是资源调度的基本单位。同一集群内的物理主机可以互相迁移虚拟机共享存储和网络资源。但集群不是越大越好。我见过一个项目把二十多台物理主机全放在一个集群里结果一次网络抖动导致集群内多台主机心跳超时触发了大规模虚拟机迁移存储带宽瞬间被打满业务中断了将近十分钟。后来复盘问题就出在集群规模过大故障域没有隔离。合理的做法是按业务类型或硬件规格划分集群。比如生产业务一个集群测试业务一个集群或者同代CPU的机器放一个集群不同代的放不同集群。因为虚拟机迁移有一个硬性要求目标主机的CPU特性必须兼容源主机。如果集群里混了不同代的CPU迁移时可能会因为指令集不兼容而失败。集群规模建议控制在8到16台物理主机之间。超过16台可以考虑再拆一个集群。这个数字不是绝对的但超过之后集群内的心跳流量、元数据同步开销都会明显上升。3.2 主机添加过程中的网络与存储预检查添加物理主机到FusionCompute集群看起来只是填个IP和密码的事但背后有一堆预检查项。我整理了一个实际项目中总结的检查清单检查项要求常见问题管理网连通性主机管理口与FusionCompute管理节点互通IP冲突、VLAN配置错误业务网连通性业务网口与虚拟机网络互通网卡绑定模式不一致存储网连通性存储网口与存储设备互通多路径配置缺失时间同步主机与管理节点时间差小于5分钟NTP未配置或不可达DNS解析主机名可正向反向解析未配置DNS或hosts文件硬件兼容性CPU、网卡、存储适配器在兼容列表内使用了未认证的网卡型号时间同步这一项特别容易被忽略。FusionCompute的集群心跳和证书验证都依赖时间一致性如果主机时间和管理节点差太多添加主机会直接失败报错信息还不一定明确指出是时间问题。我建议在添加主机之前先在每台主机上配置好NTP确保时间偏差在秒级以内。存储方面如果用的是FC SAN需要提前在主机上配置多路径软件确保每条路径都能看到LUN。如果用的是iSCSI要确认iSCSI发起端的IQN已经添加到存储设备的访问控制列表里。这些准备工作做在前面添加主机时能省掉大量排查时间。3.3 虚拟机模板制作一次做对后面省事模板是批量部署虚拟机的基础。一个好的模板能让你后面创建几十台虚拟机时只需要改改IP和主机名。一个糟糕的模板会让你每台虚拟机都要手动修修补补。制作模板时有几个关键点必须处理好。首先是磁盘对齐Windows虚拟机的系统盘分区偏移量要设置为1024KB或2048KB否则存储性能会下降。FusionCompute在创建虚拟磁盘时会自动处理对齐但如果你是从物理机迁移过来的或者手动分区就要注意这一点。其次是Tools安装。FusionCompute Tools提供了半虚拟化驱动能显著提升网卡和磁盘性能。不装Tools的虚拟机网卡走的是模拟的e1000模式性能差一大截。装完Tools后网卡会变成半虚拟化的virtio模式磁盘也会启用半虚拟化驱动。然后是系统优化。关闭不必要的服务、禁用休眠、调整页面文件大小、清理系统日志。这些操作在模板里做一次后面所有虚拟机都受益。我通常会写一个PowerShell脚本放在模板里首次启动时自动执行这些优化。提示模板制作完成后先不要急着转换成模板。用这个虚拟机克隆一台测试机验证网络、存储、Tools、系统优化都正常再转模板。我吃过这个亏模板转完才发现网卡驱动有问题几十台虚拟机全部要重做。4. 虚拟机迁移与资源调度那些文档里不会写的细节4.1 热迁移的带宽计算与网络规划热迁移Live Migration是FusionCompute的核心能力之一能在虚拟机不停机的情况下把它从一台主机移到另一台。原理是把虚拟机的内存页先整体复制到目标主机然后增量复制变化的内存页最后短暂暂停虚拟机复制最后一点变化完成切换。这个过程对网络带宽有要求。假设虚拟机有16GB内存迁移网络是千兆网理论带宽125MB/s实际有效带宽可能只有80-100MB/s。第一次全量复制16GB需要大约160到200秒。如果虚拟机内存变化很快增量复制可能永远追不上迁移就会一直不完成。我的经验是迁移网络至少用万兆。如果虚拟机内存超过32GB或者业务内存变化频繁最好用万兆绑定或者更高速的网络。另外迁移网络和管理网络最好分开避免迁移流量把管理网络打满导致管理节点失联。FusionCompute里可以设置迁移网络在集群的配置里指定用于迁移的网口。如果有多块网卡建议做绑定既增加带宽又提供冗余。4.2 DRS动态资源调度的阈值设置与误判处理DRS动态资源调度会根据集群内主机的负载情况自动把虚拟机从负载高的主机迁移到负载低的主机。听起来很智能但阈值设置不好会适得其反。FusionCompute的DRS可以设置保守、中等、激进三个级别。保守级别下只有主机负载差异非常大时才触发迁移激进级别下稍微有点不均衡就会迁移。我建议生产环境用保守或中等测试环境可以用激进。为什么因为每次迁移都有成本。迁移过程中虚拟机的内存要复制网络要切换存储要重新建立连接。如果频繁迁移不仅消耗资源还可能因为迁移过程中的短暂性能下降影响业务。还有一个容易被忽略的点DRS的误判。有些虚拟机CPU使用率高但那是正常的业务负载不是资源不足。DRS如果只看CPU使用率可能会把这些虚拟机迁来迁去反而影响性能。FusionCompute支持基于CPU和内存的综合判断你可以调整两者的权重。对于CPU密集型业务把CPU权重调高对于内存密集型业务把内存权重调高。4.3 迁移失败后的排查链路迁移失败是运维中常见的问题但排查起来往往没有头绪。我总结了一个排查顺序从最常见的原因开始检查CPU兼容性。源主机和目标主机的CPU型号是否兼容如果集群里混了不同代的CPU迁移可能因为指令集不兼容而失败。可以在集群设置里启用CPU兼容模式但会损失一些CPU特性。检查网络连通性。迁移网络是否互通源主机和目标主机的迁移网口是否在同一个VLAN防火墙是否放行了迁移端口检查存储可见性。如果虚拟机磁盘在共享存储上目标主机是否能访问该存储如果存储不可见迁移会失败。检查目标主机资源。目标主机是否有足够的CPU和内存预留如果目标主机资源不足迁移会被拒绝。检查虚拟机状态。虚拟机是否有快照有快照的虚拟机迁移可能失败。虚拟机是否挂载了ISO挂载ISO的虚拟机迁移也可能出问题。查看任务日志。FusionCompute的任务中心会记录迁移失败的详细原因但有时候错误信息比较笼统。这时候可以登录到源主机和目标主机查看/var/log下的相关日志。这个排查顺序是我踩了多次坑之后总结出来的按这个顺序走大部分迁移问题都能定位到。5. 性能调优与日常运维中的实战经验5.1 CPU就绪时间与内存气球驱动的监控要点虚拟机性能好不好不能只看CPU使用率。有两个指标更值得关注CPU就绪时间和内存气球驱动。CPU就绪时间Ready Time表示虚拟机想要运行但物理CPU没空搭理它的时间比例。如果这个值超过10%说明物理CPU资源紧张虚拟机在排队等CPU。这时候你看到虚拟机CPU使用率可能不高但业务就是卡。解决方法是减少主机上的虚拟机数量或者给虚拟机增加CPU预留。内存气球驱动Balloon Driver是Hypervisor回收虚拟机空闲内存的机制。如果气球驱动回收的内存过多虚拟机可能会开始使用Swap性能急剧下降。监控气球驱动的大小如果持续增长说明物理内存不足需要考虑增加内存或减少虚拟机数量。FusionCompute的性能监控里可以查看这些指标。我建议在集群级别设置告警阈值CPU就绪时间超过5%告警气球驱动超过虚拟机内存的10%告警。5.2 快照使用不当引发的存储性能雪崩快照是虚拟机运维中很方便的功能但滥用快照会导致严重的性能问题。快照的原理是写时复制创建快照后原来的磁盘数据被标记为只读新的写入写到快照文件里。如果快照链很长读一个数据块可能要遍历多个快照文件延迟会成倍增加。我见过一个案例某台虚拟机做了十几个快照快照链长达十几层结果这台虚拟机的磁盘IO延迟从正常的几毫秒飙升到几百毫秒业务几乎不可用。删除快照时又因为快照链太长合并过程花了几个小时。我的建议是快照只用于短期保护比如系统升级前做一个快照升级完成后确认没问题就删除。不要用快照做长期备份长期备份应该用备份软件。快照链深度不要超过3层超过3层就要考虑合并。5.3 虚拟机资源规格的常见配置误区给虚拟机分配资源时有几个常见的误区。第一个误区是CPU越多越好。实际上如果虚拟机里的应用不是多线程优化的分配再多CPU也用不上。而且分配的vCPU越多Hypervisor的调度开销越大。对于单线程应用1到2个vCPU就够了。对于多线程应用vCPU数量不要超过物理核心数。第二个误区是内存越大越好。内存分配多了不仅浪费资源还可能因为内存超分配导致Swap。合理的内存大小应该根据应用的实际需求来定可以通过监控工具观察一段时间的内存使用情况再确定分配多少。第三个误区是磁盘越大越好。磁盘大小影响的是存储容量但磁盘的性能取决于存储后端的IOPS和带宽。给虚拟机分配一个很大的磁盘但存储后端性能跟不上磁盘再大也没用。对于IO密集型应用应该把虚拟磁盘放在高性能存储上比如SSD存储池。5.4 集群扩容时的兼容性检查清单集群扩容也就是往现有集群里加新主机看起来简单但兼容性问题不少。我整理了一个扩容前的检查清单CPU兼容性新主机的CPU型号是否与集群内现有主机兼容如果不兼容需要考虑新建集群或者启用CPU兼容模式。Hypervisor版本新主机的FusionCompute版本是否与集群一致版本不一致可能导致迁移失败。网络配置新主机的管理网、业务网、存储网、迁移网配置是否与现有主机一致VLAN、MTU、绑定模式都要对齐。存储配置新主机是否能访问集群使用的所有存储多路径配置是否一致时间同步新主机的时间是否与管理节点同步证书新主机的证书是否有效是否与管理节点信任关系正常这些检查项看起来琐碎但每一项出问题都可能导致扩容失败或者后续迁移异常。我习惯在扩容前把这些检查项做成表格逐项确认后再操作。6. 计算虚拟化在实际业务场景中的取舍6.1 数据库类业务虚拟化的性能边界数据库能不能跑在虚拟机上这个问题争论了很多年。我的答案是能但有条件。对于OLTP数据库IOPS和延迟是关键。虚拟化层会带来一定的IO开销但如果存储后端性能足够这个开销可以控制在可接受范围内。关键是要用半虚拟化驱动并且把数据库的磁盘放在高性能存储池上。另外数据库虚拟机的内存不要超分配确保内存预留充足。对于OLAP数据库CPU和内存带宽是关键。虚拟化层对CPU的损耗相对较小但内存带宽可能成为瓶颈。如果物理机内存带宽不足多台数据库虚拟机同时跑性能会互相影响。我的经验是核心交易数据库如果性能要求极高可以考虑物理部署非核心数据库、报表数据库、开发测试数据库跑在虚拟化环境完全没问题。关键是做好性能测试确认虚拟化后的性能满足业务要求。6.2 高并发Web服务的资源调度策略Web服务的特点是并发高、单次请求处理时间短、CPU和内存使用波动大。对于这类业务虚拟化环境的资源调度策略要特别注意。CPU方面建议设置合理的CPU份额而不是预留。份额可以在资源竞争时提供优先级但不会像预留那样锁定资源。如果给Web虚拟机设置了大量CPU预留物理CPU资源会被浪费。内存方面Web服务通常有较大的内存缓存需求但缓存是可以被回收的。可以适当超分配内存但要监控气球驱动和Swap使用情况。网络方面Web服务对网络延迟敏感。建议使用SR-IOV或半虚拟化网卡减少网络开销。如果物理网卡支持SR-IOV可以把虚拟功能直接分配给虚拟机绕过Hypervisor的网络栈大幅降低延迟。6.3 虚拟机密度与性能之间的平衡点一台物理主机上跑多少台虚拟机合适这个问题没有标准答案取决于业务类型和性能要求。对于轻量级业务比如内部OA、文件服务器一台双路服务器跑20到30台虚拟机是可行的。对于中等负载业务比如Web应用、中间件10到15台比较合适。对于重负载业务比如数据库、大数据处理可能只能跑3到5台。判断密度是否合适不能只看CPU和内存使用率还要看CPU就绪时间、内存气球驱动、存储延迟这些指标。如果这些指标都在健康范围内说明密度还可以如果开始出现告警说明密度过高了。我通常会在集群里保留20%到30%的余量用于应对突发负载和虚拟机迁移。如果集群资源使用率长期超过80%就应该考虑扩容了。6.4 从传统架构迁移到虚拟化的常见障碍把现有物理机上的业务迁移到虚拟机技术上可以用P2V物理到虚拟工具但实际过程中有不少障碍。第一个障碍是驱动兼容性。物理机上的存储驱动、网卡驱动可能和虚拟化环境不兼容。迁移前需要确认虚拟化环境支持这些驱动或者提前在物理机上安装虚拟化环境的驱动。第二个障碍是授权问题。有些商业软件绑定物理硬件信息迁移到虚拟机后授权失效。这种情况需要提前和软件供应商确认授权政策。第三个障碍是性能预期。物理机上跑得好好的业务迁移到虚拟机后可能因为资源竞争导致性能下降。迁移前要做性能评估迁移后要做性能验证。第四个障碍是网络配置。物理机的网络配置可能比较复杂比如多网卡绑定、VLAN trunk、策略路由。迁移到虚拟机后这些配置需要在虚拟化层面重新实现。我的建议是迁移前先做小规模试点选一两个非核心业务迁移验证整个流程和性能表现再逐步扩大范围。不要一次性把所有业务都迁过去风险太大。7. 写在最后一些个人体会FusionCompute的计算虚拟化表面上看是把物理资源抽象成虚拟资源但真正用好它需要理解底层机制、掌握调优方法、积累排错经验。我刚开始接触的时候也觉得只要会创建虚拟机就行了后来才发现创建虚拟机只是最基础的一步真正的功夫在资源规划、性能调优和故障处理上。有一个习惯我坚持了很多年每次做完一个项目都会把遇到的坑和解决方法记下来。比如某次迁移失败是因为CPU兼容性某次性能下降是因为快照链太长某次集群告警是因为内存超分配比率过高。这些记录后来成了我排查问题的第一手资料比任何官方文档都管用。如果你刚开始接触FusionCompute我的建议是先在测试环境里把各种功能都试一遍包括创建虚拟机、迁移、快照、DRS、HA。测试环境里踩坑总比生产环境里踩坑好。等对各项功能都熟悉了再在生产环境里操作心里就有底了。计算虚拟化这个领域技术更新很快新版本不断推出新功能。保持学习保持实践才能不掉队。