FusionCompute从零到生产：CNA/VRM部署与网络存储避坑指南

第一次接触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-V，CNA虽然能装上，虚拟机运行效率会非常低，甚至直接报错无法启动。装机前一定进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，则建议上双口万兆卡或者更多千兆口。常见的分配方式如下：

这里重点提醒：不要为了省网口把存储流量塞进管理口。存储流量通常是突发且大带宽的，一旦存储压力上来，优先被挤掉的就是管理连接。后果是CNA失联、VRM误报主机离线、HA误触发，整个平台在业务高峰期处于“假死”状态。这种问题现场排查起来非常痛苦，因为重启后一切又恢复正常，等业务流量一上来又复发。

2.3 磁盘RAID与引导模式

CNA节点安装需要一块系统盘，建议SSD，容量至少300GB，RAID1配置双盘冗余。系统盘不要和虚拟机数据盘混在一起，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规划表的重要性

推荐在安装前先把规划表写清楚，哪怕是一个测试环境，也按生产标准来。下面是一份三节点参考规划：

这里有个经验：存储平面的网关，在没有跨网段访问远端存储需求的情况下不要配置。没有网关可以避免一部分意外广播和路由行为对存储网络的影响。但要注意，如果存储阵列同时需要被多个网段的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 交付前逐项自查

部署完毕不要着急说“完成”，建议对照下面这个验收清单逐项过：

验收的时候不要只在界面上点两下就算完。我习惯安排一次主机维护模式演练：把一台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。前期的每一分细致，都会在后期减少一次凌晨进机房的概率。