第一次接触FusionCompute的人十有八九会把它当成普通虚拟机软件下载ISO、装完、开虚拟机、完事。真到了生产环境你会发现面对的是三台及以上物理服务器、一台共享存储和一套完整网络设备任何一个环节没规划好后面都想拆了重来。我印象最深的一次CNA装得很快VRM部署也顺利结果新建虚拟机怎么都ping不通网关最后查到物理交换机端口上没放通对应VLAN故障根本不在虚拟化层。这篇文章把我从零规划到部署FusionCompute的完整思路写清楚从组件选型、硬件检查、存储规划到网络划分、CNA安装、VRM部署和集群创建最后附上一份验收清单和现场排查经验。网络部分是重点会讲几种文档里不写、但现场最容易踩的坑。适合刚接手虚拟化平台的运维同学也适合准备独立做FusionCompute实施项目的朋友参考。1. FusionCompute组件选型CNA与VRM的角色以及实验与生产环境的部署差异1.1 CNA和VRM到底是什么关系FusionCompute的管理架构里有两个核心角色CNA和VRM。很多新手被这两个缩写绕晕其实把它们类比成小区里的“楼”和“物业中心”就很好理解。CNA全称Computing Node Agent运行在物理服务器上是承载虚拟机的基础单元。它负责把CPU、内存、磁盘、网卡这些物理资源抽象成虚拟资源同时上报状态、执行VRM下发的指令。一台物理服务器装好CNA之后才能在上面创建和运行虚拟机。VRM全称Virtual Resource Manager是整个平台的管理中枢提供Web管理界面和API接口负责集群调度、HA故障切换、资源热迁移、虚拟机生命周期管理这些逻辑层面的功能。VRM本身通常也以虚拟机形式运行在CNA节点上相当于物业中心也设在小区楼栋里。实际操作中你平时登录的是VRM管理界面在界面上看到的是集群、主机、虚拟机、存储、网络这些对象而CNA负责在底层落实这些配置。两者缺一不可一台CNA节点上如果VRM出问题界面就登不进去但上面的虚拟机仍然在跑只是暂时无法管理。1.2 实验环境和生产环境的部署模式差异FusionCompute支持多种部署方式规划阶段就要想清楚需求别抱着“先装一台试试以后再加”的心态。虽然平台支持后续扩容但网络、存储这些底层结构如果一开始图省事后面扩容时会牵连一堆配置。我的建议如下纯实验环境一台物理服务器即可。装一个CNA再在这台CNA上以虚拟机方式部署一个VRM单台就能跑通整个管理流程。但缺点是这台服务器重启后管理面和业务面一起中断无法模拟故障切换也不能验证HA等高级特性。生产小规模3节点起步至少3台CNA节点部署2个VRM虚拟机分别放在两台不同的CNA上形成主备关系。这样单台CNA宕机时VRM还能继续管理集群另一台节点上的虚拟机通过HA机制自动拉起。中大规模根据业务量规划计算节点数量VRM依旧主备部署存储建议使用独立存储阵列或分布式存储网络侧按三个平面独立规划。这里有个容易被忽略的点VRM虚拟机本身也消耗资源。很多人在规划时只算业务虚拟机的资源需求忘了给VRM预留内存和CPU。VRM主备两个实例建议各预留至少4GB内存、2个vCPU中大型环境建议8GB以上否则管理面在高负载下会出现明显的卡顿。2. 服务器侧从头查一遍BIOS开关、网卡数量和磁盘配置2.1 CPU虚拟化开关和内存策略安装CNA之前有两件最基础但最容易被跳过的事打开CPU的虚拟化开关以及确认内存运行模式。现在主流的x86服务器都支持硬件辅助虚拟化很多机器出厂时默认开启但也有一些品牌机型默认关闭。如果没开启VT-x/AMD-VCNA虽然能装上虚拟机运行效率会非常低甚至直接报错无法启动。装机前一定进BIOS在CPU配置项里确认“Intel Virtualization Technology”或“SVM Mode”处于开启状态。还有一个细节服务器BIOS里的电源管理和C-State选项。虚拟化场景中CPU的动态降频和深度休眠可能导致虚拟机出现延迟抖动尤其是跑数据库或对时延敏感的业务。生产环境建议把电源策略设置为“性能模式”或“最大性能”关闭不必要的C-State深度节能选项。这个操作在FusionCompute界面里没法调必须在BIOS层完成。内存方面CNA节点上内存容量决定虚拟机密度硬件层面要注意内存通道数和DDR频率。如果服务器支持镜像模式建议开启内存镜像或Rank Sparing虽然会损失一部分可用容量但能避免单条内存故障导致整个物理机宕机。虚拟化平台里内存错误导致宿主机挂掉的案例远比CPU故障多。2.2 网卡数量决定网络方案的灵活度CNA节点需要承载管理、存储、业务三种流量网口数量不足会直接逼你做一些无奈的复用而这种复用恰恰是大多数网络故障的根源。我建议一台CNA至少配备4个千兆以上网口如果规划万兆业务或者存储走iSCSI则建议上双口万兆卡或者更多千兆口。常见的分配方式如下物理网口用途链路聚合方式说明eth0 / eth1管理平面主备或LACP承载CNA管理IP、VRM管理IP、内外通信eth2 / eth3存储平面LACP推荐承载iSCSI/NFS等存储流量eth4 / eth5业务平面LACP承载虚拟机业务流量可根据需要分多个VLAN板载管理口带外管理不参与业务用于iBMC/iLO远程管理这里重点提醒不要为了省网口把存储流量塞进管理口。存储流量通常是突发且大带宽的一旦存储压力上来优先被挤掉的就是管理连接。后果是CNA失联、VRM误报主机离线、HA误触发整个平台在业务高峰期处于“假死”状态。这种问题现场排查起来非常痛苦因为重启后一切又恢复正常等业务流量一上来又复发。2.3 磁盘RAID与引导模式CNA节点安装需要一块系统盘建议SSD容量至少300GBRAID1配置双盘冗余。系统盘不要和虚拟机数据盘混在一起CNA系统和业务虚拟机磁盘在故障场景下应该互不影响。独立RAID卡建议开启写缓存并配备电池或超级电容避免异常掉电导致写缓存数据丢失。现在很多服务器默认UEFI引导CNA镜像大部分情况下能识别但老旧的RAID卡或HBA卡在UEFI模式下可能出现找不到引导设备的问题。如果安装时发现识别不到硬盘先检查BIOS引导模式是不是Legacy。另一点是RAID卡的直通模式JBOD和RAID模式之间的区别新机器默认JBOD也可以但如果是老机器进RAID阵列卡配置界面上先建好阵列再装系统不然系统装到一半会因为识别不稳定而异常中断。主机命名也是个值得提前统一的事。生产环境建议按机房-机架-位置-角色的规则命名比如BJ_RA12_CNA01而不是用默认的“localhost”或乱码主机名。命名整理清楚后后续添加主机、维护故障节点、回收资源时能少很多混乱。3. 存储规划到底在规划什么数据存储、多路径和容量预留3.1 外置存储与本地虚拟化存储的区别FusionCompute里的存储指的不是物理磁盘本身而是给虚拟机提供磁盘空间的数据存储Datastore。数据存储的来源有两类外置存储和本地虚拟化存储。外置存储是传统的SAN/iSCSI/NFS方案所有CNA节点通过存储网络访问同一批LUN。优势是共享能力强虚拟机可以跨主机热迁移因为后端数据统一存放在存储阵列上。生产环境绝大多数都走这条路。本地虚拟化存储指的是把CNA节点本地盘组织成存储资源池多个节点的磁盘聚合起来形成分布式存储数据副本存放在不同节点上实现类似分布式存储的效果。好处是部署简单、不需要额外买存储设备适合对成本敏感或边缘机房场景。缺点是需要额外考虑网络带宽和节点故障域对部署和运维要求更高。我的建议很简单一个集群的若干CNA节点要么统一走外置存储要么统一走本地虚拟化存储不要混用。混用会导致虚拟机HA和迁移行为不一致有些虚拟机能在主机间漂移有些漂不动后续排障非常头疼。3.2 多路径与LUN划分存储网络规划里最容易被低估的是多路径。很多实施项目只连了一根光纤或一根网线阵列重新映射、交换机重新配置或者链路瞬时抖动时存储连接直接中断。虚拟机还在运行但它的磁盘后端I/O全部失败轻则卡死重则导致虚拟机文件系统损坏。配置多路径的标准做法是每个存储卷至少经过两条物理链路在存储侧和计算侧都配置好多路径软件FusionCompute会识别同一LUN的多个路径聚合带宽并自动切换。iSCSI场景下每个CNA节点上的两个存储口最好分别连接两台不同的存储交换机这样单一交换机故障才不会影响存储访问。LUN划分的数量和大小也有讲究。我不建议只给一个巨大的LUN塞满所有虚拟机也不建议把每个虚拟机单独划分LUN。合理的做法是按业务类型拆分系统盘LUN、数据库LUN、备份LUN各分不同卷容量和IOPS特性可以分别规划。比如数据库卷放到高性能SSD上备份卷放到大容量机械盘上同一套虚拟化平台兼顾性能和成本。3.3 容量预留的计算方式存储容量规划经常出现两个极端规划太满上线没多久空间告急扩容要停机加盘加LUN规划太松预算浪费存储上囤了一大堆闲置空间管理层看到的是资源利用率低。我习惯按这个口径估算业务虚机全量磁盘需求 × 1.3 系统盘和虚拟化平台自用空间。1.3的系数里0.1是给快照和回收站预留的缓冲0.2是给后续扩容充电。举个例子规划8台虚拟机每台系统盘100GB、数据盘500GB总容量是4.8TB算上预留后存储池至少建到6.3TB以上。数据存储的命名也要规范。我看到过不少环境的存储名称是默认的“datastore1”“datastore20”一旦挂载了多台存储阵列完全分不清哪个是哪个。建议命名带上用途和阵列标识例如SAN1_DB01、SAN1_BACKUP这样在FusionCompute界面里一眼能看出存储的归属和用途。4. 网络规划避坑指南三个平面独立IP/VLAN的分配思路与物理交换机匹配4.1 管理、存储、业务三个平面各管什么FusionCompute网络规划里最核心的动作就是把流量按照功能划分为管理平面、存储平面和业务平面。这个划分不是纸上谈兵它直接关系到后期平台运行的稳定性和排障效率。管理平面承载CNA管理IP、VRM管理地址、节点间内部通信。所有运维人员远程登录、界面操作的流量都走这里。存储平面承载CNA到存储阵列之间的流量例如iSCSI或NFS。要求高带宽、低延迟、稳定可靠。业务平面承载虚拟机对外服务的流量。不同业务可以按VLAN隔离网络策略在虚拟交换机层面实现。三个平面必须用独立的网段和VLAN隔离物理上最好使用独立的网卡条件受限时也要至少保证VLAN隔离和优先级QoS配置。如果管理平面和业务平面混在一个二层网络里虚拟机里的广播报文、异常流量会直接影响管理通道VRM和CNA之间的心跳出现延迟后平台可能误判主机故障并触发非必要的HA迁移。4.2 一张IP与VLAN规划表的重要性推荐在安装前先把规划表写清楚哪怕是一个测试环境也按生产标准来。下面是一份三节点参考规划平面VLAN网段网关使用对象备注管理平面VLAN 10110.10.1.0/2410.10.1.1CNA1-310.10.1.11-13VRM主备10.10.1.21-22管理口需配网关时设置网关存储平面VLAN 10210.10.2.0/24按需CNA存储口10.10.2.11-13存储阵列10.10.2.100-101iSCSI网络可不开网关业务平面VLAN 201-210172.16.x.0/24对应网关虚拟机业务地址每个业务一个VLAN带外管理独立192.168.1.0/24192.168.1.1iBMC/iLO管理口不走业务网络这里有个经验存储平面的网关在没有跨网段访问远端存储需求的情况下不要配置。没有网关可以避免一部分意外广播和路由行为对存储网络的影响。但要注意如果存储阵列同时需要被多个网段的CNA访问那么存储网关还是得配这时就要在防火墙上做好访问控制。还有一点是管理平面的网关CNA/VRM的管理IP需要被运维终端访问如果运维终端和平台管理网不在同一个网段管理IP就必须配置可用的网关。很多人在这里漏配网关导致远程无法访问只能到机房控制台操作。4.3 物理交换机端口模式和VLAN放通的坑这一节是全文最想强调的部分。FusionCompute配置虚拟机的VLAN网络时虚拟交换机上的VLAN ID要和物理交换机上的VLAN配置完全对应。但很多实施现场把精力全放在FusionCompute界面里物理交换机端口从来没检查过。常见故障有两种。第一CNA业务口连的是物理交换机access端口端口PVID是默认VLAN 1而虚拟交换机上配置的是VLAN 201两边不匹配虚拟机完全无法通信。第二物理交换机端口是trunk模式但trunk列表没有放通VLAN 201同样不通。正确的做法是承载CNA节点上行链路的物理交换机端口设为trunk模式并把业务规划涉及的所有VLAN都加入放通列表如果是单业务VLAN的简单场景也可以配置access模式并把PVID改成对应的业务VLAN。这个动作必须在安装前管理和业务网卡接线阶段就做好部署完成后用虚拟机跨VLAN通信或ping网关来验证。注意这里说的是物理交换机不是FusionCompute虚拟交换机。平台界面里建再多的VLAN网络物理链路不配合一切都是白搭。我排障时习惯先确认二层物理连通性再往虚拟化层深挖顺序反了会浪费大量时间。4.4 上行链路绑定模式的选择FusionCompute里把多块物理网卡绑成一个上行链路池子时需要选择绑定模式。常见的是主备模式和负载分担模式。主备模式配置简单、不依赖交换机聚合协议切换时会有短暂的链路中断负载分担模式能充分利用多链路带宽但要求交换机做端口聚合LACP或静态聚合两边配置不匹配会出现MAC地址漂移告警严重时直接断流。不同平面建议采用不同策略管理平面主备模式即可管理流量本身不大保证链路冗余是第一位。存储平面如果iSCSI流量大建议负载分担模式并且配合交换机的端口聚合否则多块网卡里只有一块在跑带宽没有提升。业务平面负载分担优先前提是物理交换机与服务器侧绑定模式匹配。有个细节容易忽略不要把不同速率、不同型号的网卡绑在一个链路聚合组里。比如一块千兆一块万兆绑定负载分担流量分发可能不均匀还会产生大量包乱序问题。建议同型号同速率端口组队绑定。4.5 时钟同步和带外管理网络规划里还有一个容易遗漏的环节就是带外管理网络。服务器上的iBMC/iLO口应该接入一个独立的带外管理网段不参与FusionCompute业务避免业务故障时运维无法远程进入服务器。同时虚拟化环境里NTP时钟同步非常重要。VRM和CNA之间通信、HA心跳、日志时间戳都依赖统一的时间。如果CNA时间偏差过大VRM可能会认为主机失联触发误判。建议在三台CNA和VRM上都配置统一NTP服务器安装完平台后第一件事就是检查时间同步状态。5. CNA节点安装实战从挂载ISO到登录管理面5.1 安装介质和引导准备FusionCompute的安装镜像分为CNA镜像和VRM镜像两部分部署时一般先从CNA镜像开始。镜像通常是ISO文件可以通过服务器的带外管理口挂载也可以做成U盘引导盘。生产环境的服务器一般都支持IPMI远程挂载ISO把ISO文件上传到带外管理界面挂到虚拟光驱上远程就可以开始安装。挂载完成后重启服务器进入BIOS启动菜单选择从虚拟光驱或U盘引导。如果服务器开机后直接跳过了安装界面可以进BIOS调整启动顺序或者用快捷键临时选择启动项。这一步做过很多次之后你会发现CNA的安装流程本身很快更多时间耗在等待服务器自检和镜像加载上。5.2 安装过程中的关键参数CNA安装启动后安装界面会引导你选择角色这一步要选“CNA节点”或者对应的计算节点类型。接下来的关键参数有几个主机名按照之前的规划填写例如PK_CNA01。管理平面IP地址填写CNA管理IP例如10.10.1.11。子网掩码对应管理网段例如255.255.255.0。网关地址网络可达时填写例如10.10.1.1。root用户密码务必设置强密码并妥善记录后续在VRM里添加主机时要用它来认证。这几个参数看似简单但多数配置错误的案例都发生在这里最常见的就是管理IP的网段规划冲突。一个CNA的管理IP如果已经被人占用VRM添加主机时就会报错或者出现IP冲突。所以安装前建议做一次IP地址台账登记避免IP被别人临时借用。安装过程中系统会提示选择安装目标磁盘。这里要注意CNA的系统盘安装目标一定要选择之前规划的RAID1系统盘不要误选成数据盘或已经被划成存储池的盘。系统盘会被自动分区并安装引导如果误装到数据盘后面可能把原数据盘分区表冲掉。5.3 安装完成后的第一轮验证CNA安装完成后会重启重启后系统进入命令行或管理界面。第一轮验证我一般做四件事在服务器本机查看管理口IP是否成功获取确认ip地址配置与规划一致。ping管理网关确认管理平面的二层物理链路正常。ping同网段的另一台CNA或VRM确认主机间可达。如果能通过浏览器访问CNA的管理页面说明CNA管理服务已经正常运行如果页面打不开检查下防火墙或管理服务状态。CNA装好后先不要急着部署VRM。务必先确认这台主机的管理面稳定再继续下一步。管理面不稳定直接部署VRM大概率会出现VRM安装超时或主备配置失败。6. 部署VRM、建立集群并打通网络业务通道6.1 部署VRM前的资源确认VRM本质上是一台预置的虚拟机部署它是为了获取统一的管理入口。部署前要确认第一台CNA节点的资源余量CPU核数、内存大小、本地磁盘空间。如果CNA上已经跑了一些虚拟机资源被占得差不多VRM部署就会显得很吃力。生产环境建议把VRM主备两台虚拟机分别放在两台不同的CNA节点上。原因很简单如果两个VRM都放在同一台CNA上这台CNA一旦宕机VRM主备同时失效整个平台管理面直接瘫痪业务面也无法调度。VRM的规格需要提前预估。小规模测试环境可以给2个vCPU和4GB内存生产环境建议4个vCPU和8GB内存主备配置一致。如果环境规模较大还需要进一步上调。6.2 VRM部署过程和访问接口VRM的部署入口通常从CNA节点的管理界面或专门的部署向导触发。部署向导中需要填写VRM管理平面IP、VRM主备节点的归属主机、VRM的虚拟资源规格等信息。不同小版本的向导名称可能略有差异但逻辑是相通的指定VRM01、VRM02放在哪台CNA上分配IP和资源确认后系统会自动创建VRM虚拟机并完成启动。VRM部署完成后浏览器访问VRM管理平面IP地址会看到FusionCompute的登录界面。默认的管理账号通常是vrmadmin密码在部署向导阶段设置。登录管理界面后可以看到集群、主机、存储还没有配置接下来需要创建集群并加入CNA节点。这里提醒一下VRM本身也有备份和版本升级的需求。安装完成后把VRM的配置文件导出备份留一份存档。后面如果平台版本升级或出现配置误操作至少能靠备份恢复。6.3 创建集群并添加CNA主机FusionCompute管理界面的“集群”模块是资源调度的基本单位。创建集群时要设置资源调度策略负载均衡或手动和HA策略。测试环境可以用手动策略生产环境建议开启自动均衡和HA。选择是否启用HA要谨慎HA依赖于存储共享和网络心跳底层条件不具备时开启HA反而会在网络抖动时触发误迁移。创建完集群后把CNA主机添加进来。添加时需要提供CNA的root账号密码VRM会通过管理网络与CNA建立连接。添加成功后主机状态变为“正常”管理界面上可以看到主机的CPU、内存、存储信息。6.4 创建网络资源池与分布式交换机主机添加完成后还不能马上创建虚拟机。必须先配置网络资源池把CNA节点上的物理网卡纳入虚拟化网络管理。在FusionCompute里创建网络资源池时需要选择上行链路即CNA的哪几块物理网卡承担业务流量。这一步与前面的网卡规划对应把业务网卡绑定到网络资源池里并选择绑定模式。绑定完成后创建分布式交换机或虚拟交换机在交换机上划分VLAN网络。业务规划中有多少VLAN就创建多少个对应网络。创建完成后创建虚拟机时选择对应的网络即可。到这个阶段才可以说FusionCompute的核心骨架搭完了。6.5 第一台测试虚拟机的验证路径正式迁移业务之前先在平台上创建一台测试虚拟机验证整条链路是否通畅。测试虚拟机分配的内核数量不要太大默认的1C2G即可。创建完成后启动虚拟机打开控制台验证以下几步操作系统能否正常安装。虚拟机IP能否从DHCP获取或手动设置。虚拟机能否ping通同VLAN网关。如果规划了跨VLAN测试另一VLAN的虚拟机能否互通。测试虚拟机能否访问外部网络如果需要的话。测试过程里发现网络不通优先检查物理交换机端口VLAN放通情况再回头看FusionCompute虚拟交换机配置。顺序错乱的排障会非常低效。7. 部署完成后的验收清单和典型故障排查思路7.1 交付前逐项自查部署完毕不要着急说“完成”建议对照下面这个验收清单逐项过检查项预期结果检查方法VRM管理界面用浏览器能正常登录访问VRM管理IP用vrmadmin账号登录集群与主机集群内主机状态正常无告警管理界面查看主机状态VRM主备主用VRM正常备用VRM待命查看管理节点状态主备角色明确存储挂载数据存储可见且容量正确管理界面查看存储资源网络资源池上行链路已建VLAN网络已创建查看网络资源池和网络列表时钟同步各节点时间一致无NTP告警管理界面节点时间和NTP源比对虚拟机基本功能测试虚拟机启动正常网络连通创建测试机ping网关和业务地址备份策略VRM配置文件已备份导出VRM配置并保存验收的时候不要只在界面上点两下就算完。我习惯安排一次主机维护模式演练把一台CNA置为维护模式观察上面的虚拟机是否能正常迁移出去VRM是否仍然稳定。这种演练虽然看起来“麻烦”但比正式业务跑起来后再发现支撑能力不足要划算得多。7.2 三个高频故障的排查链路第一个高频故障虚拟机起来后网卡有IP但同网段不通。先看FusionCompute虚拟交换机上该网络绑定的物理上行链路是否工作正常再看物理交换机对应端口有没有放通VLAN。确认VLAN放通后还不行再看CNA的绑定模式与交换机聚合模式是否一致。排查的每一步都要做验证而不是只改配置不测试。第二个高频故障CNA主机在管理界面上显示离线或断断续续。优先查管理网络的稳定性看交换机跟该管理口之间的链路有没有up/down记录。管理口绑定的主备模式如果出现频繁切换也会造成短时离线告警这时要检查备用口的链路质量。另一个常见原因是NTP不同步主备VRM和CNA时间偏差过大心跳超时被误判离线。时间不同步导致的误判在日志里经常有蛛丝马迹看到大量超时或丢失提示时先对表。第三个高频故障存储性能骤然下降批量虚拟机卡顿。先看存储多路径是否健全某条路径挂掉以后流量全部挤到另一条上性能必然下降。再看存储网络的交换机端口是否有丢包或错包光纤或网线历史告警。最后看存储阵列本身的IO延迟和队列深度判断瓶颈到底在计算侧还是存储侧不要一上来就甩锅给FusionCompute。7.3 日常运维的几个习惯平台上线后日常维护比部署更考验耐心。我的几个习惯可以分享给你每个月导出一次VRM配置备份放到独立的备份服务器上不要存在CNA本地磁盘。每个季度检查一次存储多路径状态和交换机端口告警及时发现链路隐患。版本升级前先把升级影响范围和相关兼容性文档读清楚小版本之间也不要跳过避免跨多个版本直接升级带来的兼容性问题。证书快到期前提前处理VRM和CNA管理界面的证书过期会导致登录异常这是很多人踩过但很少提前预防的坑。FusionCompute这个平台本身没太多神秘感它的大部分故障都发生在周边依赖项上物理网络的VLAN放通、存储多路径、NTP同步、资源预留。把地基打牢虚拟化层反而最省心。我后来再做这类项目时都是先把网络规划表打印出来确认物理交换机放通对应VLAN再开始装第一台CNA。前期的每一分细致都会在后期减少一次凌晨进机房的概率。