刚接手一套测试环境时老板给的预算是“零”机器是机房淘汰的几台x86服务器存储阵列自然是别想了。当时手里正好有台自建的Linux NAS于是把FusionCompute对接自建NAS存储这套方案完整跑了一遍。整个过程说难也难说简单也简单——核心就是搞清楚FusionCompute怎么把NFS共享当成数据存储用以及这中间牵扯的权限、网络、协议、可靠性问题。这篇就把我的实操过程、踩坑记录和排查思路完整写出来给准备用NAS给FusionCompute当“仓库”的同行做个参考。如果你对FusionCompute的存储接入方式不熟可以先理解成一句话虚拟机的虚拟磁盘最终要落在一个地方本地硬盘、SAN上的LUN、或者NAS上的共享目录都可以区别只是“谁来提供存储”以及“用什么协议访问”。自建NAS通常走NFS协议这是FusionCompute原生支持的对接方式之一。很多新手第一次搞会被“挂载失败”“权限不足”“存储状态异常”搞得焦头烂额其实问题基本不在FusionCompute侧而是在NAS侧没伺候好NFS。1. 先把需求想清楚为什么用NAS而不是SAN/DAS1.1 三种存储架构的适用边界FusionCompute的存储接入方式不是随便选的先要理清DAS、SAN、NAS三种架构在虚拟化场景里的区别。DAS就是服务器本地磁盘性能最直接但只有单台主机能访问集群场景下没办法共享虚拟机迁移也就无从谈起。SAN通过FC或iSCSI提供块设备多台计算节点可以同时访问同一个LUN性能和扩展性都好但要买存储阵列运维门槛也跟着上来。NAS是通过NFS或CIFS协议提供文件级共享多台主机访问同一个目录配置简单成本低但性能上限受限于网络和文件协议本身的开销。从FusionCompute的角度看SAN的LUN被当作块设备由FusionCompute自己格式化成文件系统再存放虚拟磁盘NAS则是直接把虚拟磁盘文件放在NFS共享目录里计算节点像读写普通文件一样操作这些镜像文件。这两种方式各有取舍但对自建NAS来说路线基本只有NFS一条。1.2 什么场景适合自建NAS我自己的判断标准很简单如果这套FusionCompute是跑测试、开发、培训或者灾备演练的自建NAS完全够用如果打算承载核心生产数据库、高并发业务那还是把预算花在正经存储上。原因在于NAS的瓶颈非常明显——随机IOPS和延迟机械盘组阵列的4K随机读写在虚拟化密集场景下很难看多台虚拟机同时抢I/O时表现更差。如果环境里只有一两台CNA虚拟机数量不多自建NAS的性价比极高。群晖这类成品NAS也可以接但我更推荐Linux自建因为权限控制、NFS版本、导出参数这些细节在Linux上可控性更强。飞牛NAS、绿联NAS这类新兴系统我没少玩界面友好但NFS导出的定制能力参差不齐正式对接前一定要确认能否关闭root_squash这个点直接决定FusionCompute能不能往共享里写数据。1.3 对“便宜方案”要有清醒预期自建NAS最诱人的地方是便宜最坑的地方也恰恰是便宜。便宜意味着硬件余量小、没有硬件冗余NAS一旦重启或断电上面挂着的所有虚拟机会集体“冻住”严重时数据存储直接异常。所以做这个方案心态上就得把它定位成“灵活但需要精心运维”的存储而不是买回来装上就能一劳永逸的东西。后期的网络规划、权限配置、监控备份一样都不能省。2. 规划不到位后面全白干存储侧与网络侧准备2.1 NAS宿主机与磁盘规划我的NAS宿主机是一台旧服务器双路Xeon内存32GB两块万兆网卡系统盘是两块SSD组RAID1数据盘四块机械盘组RAID5再加一块SATA SSD做bcache缓存。这个配置跑十来台虚拟机做测试没有任何问题。如果你手上只有一台普通PC也完全可以跑但内存建议至少8GB以上否则Linux的page cache不够NFS读写的性能会明显下滑。磁盘规划上有个容易被忽视的点不要把系统目录和数据共享目录放在同一个分区。很多新手把共享目录直接建在根分区下NAS系统日志一膨胀或者包管理刷更新根分区满了之后NFS导出目录也跟着读写异常FusionCompute那边虚拟机直接卡住。数据目录建议单独划一个分区或者至少绑到单独挂载的磁盘上。文件系统用ext4或者XFS都行追求快照和压缩能力可以上ZFS但FusionCompute只要NFS语义完整就能用不要为了“高级功能”把简单方案复杂化。2.2 存储网络隔离、聚合与MTUFusionCompute对接NAS网络是第一道关。我强烈建议单独划一个存储VLAN不要让业务流量和存储流量混在一起。业务流量一旦有广播风暴或者大流量下载NFS的延迟会直线飙升虚拟机表现就是“鼠标转圈、SSH卡顿”。存储网段规划可以这样设计网络平面网段示例用途管理网络192.168.1.0/24FusionCompute管理面、CNA管理IP业务网络192.168.2.0/24虚拟机业务流量存储网络192.168.10.0/24NAS与CNA之间的NFS流量NAS宿主机和CNA的存储口都接到这个独立的VLAN里。只有一块网卡时也要打VLAN标签物理隔离但可靠性就别指望太多。有两块以上网卡就做bondingNAS侧和CNA侧要选择一致的bond模式。我这边用的是active-backup配置简单故障切换靠交换机感知不到但至少避免了单点网卡故障。MTU这个坑我必须单独拿出来说。NFS大包传输对MTU非常敏感如果NAS和CNA都在同一个二层网络且交换机支持可以开9000巨型帧顺序吞吐明显上升。但如果中间有任何一段链路MTU还是1500开了9000反而会导致分片和丢包NFS写入有时会卡到超时。最稳妥的做法是要么整条链路全部9000要么全部保持1500不要两边不一致。弄完之后用ping -M do -s 8972之类的命令两端实测一下确认没有分片再放心用。2.3 共享目录的权限设计NFS导出权限是整个对接过程中最容易出错的地方。FusionCompute的CNA在挂载NFS共享时默认是以root身份去读写镜像文件的。这就意味着NFS导出参数里必须有关键的一笔no_root_squash。如果不加这个参数Linux NFS默认的root_squash会把远程root映射成nobody权限被压到普通用户FusionCompute在共享里创建虚拟磁盘文件时会直接报权限不足。这个坑我见过太多人踩。共享目录本身的属主不需要刻意设置成什么特殊用户root就行因为no_root_squash开了之后远程root依然有root权限。如果出于安全考虑不愿意全量开no_root_squash也要至少保证共享导出给CNA网段时开启这个选项。另外导出权限只给需要访问的网段不要顺手写一个0.0.0.0/0更不要把整个办公室网段都放进来。存储网段和数据本身一样重要。3. Linux侧NFS服务搭建与验证3.1 安装与配置NFS服务Debian/Ubuntu和CentOS/RHEL的安装包不一样但思路完全一样。以Ubuntu为例apt update apt install -y nfs-kernel-server systemctl enable --now nfs-serverCentOS上对应的是yum install -y nfs-utils systemctl enable --now nfs-server然后创建共享目录并编辑导出文件mkdir -p /data/fusioncompute vim /etc/exports在exports里写入/data/fusioncompute 192.168.10.0/24(rw,sync,no_root_squash,no_subtree_check)这里有几个参数要解释一下。rw表示读写必须的。sync表示NFS服务器要等数据真正写到磁盘后才返回成功对虚拟化存储可靠性很重要建议保留后面如果追求测试环境性能也可以改async但断电丢数据的风险要自己认。no_root_squash上面说过了FusionCompute能不能写全靠它。no_subtree_check可以减少部分目录操作时的开销对性能有帮助但某些老版本NFS可能不支持按需选择即可。如果有多个CNA网段需要访问可以写成多行或者在一行里用空格分隔多个网段但要注意每个网段的括号必须紧跟在其地址后面比如/data/fusioncompute 192.168.10.0/24(rw,sync,no_root_squash,no_subtree_check) 192.168.20.0/24(rw,sync,no_root_squash,no_subtree_check)这个格式如果写错exportfs会直接报错或者只有一个网段生效。3.2 启动、导出与本地验证配置好之后重新导出exportfs -rav systemctl restart nfs-server showmount -e 127.0.0.1showmount能看到导出的目录就说明NFS服务本身正常。接下来本地挂载测试一下root写权限是否真的生效mkdir -p /mnt/nfstest mount -t nfs 127.0.0.1:/data/fusioncompute /mnt/nfstest touch /mnt/nfstest/root_write_test ls -l /mnt/nfstest/ umount /mnt/nfstest这个测试的意义在于如果连root都写不了FusionCompute那边必然挂不上。很多教程让你直接在CNA上挂载测其实在NAS本机先测一遍能排除掉网络因素定位问题更快。挂载测试结束记得umount避免后续干扰CNA上的挂载。3.3 防火墙与端口固定NFS服务不只是2049端口一件事。除了nfs本身还有rpcbind111、mountd通常动态端口、lockd、statd等协同服务。如果你的NAS开了防火墙只放行2049是不够的FusionCompute扫描共享时很可能超时。最省事的做法是存储网段上直接信任内部环境防火墙放行NFS相关服务即可firewall-cmd --permanent --add-servicenfs firewall-cmd --permanent --add-servicerpc-bind firewall-cmd --permanent --add-servicemountd firewall-cmd --reload但动态端口始终是个隐患我更推荐把mountd端口固定下来。不同发行版配置方式不同Ubuntu可以编辑 /etc/default/nfs-kernel-serverCentOS/RHEL可以在 /etc/nfs.conf 的 [mountd] 段设置 port40001。固定后需要重启rpcbind和nfs-server再用rpcinfo -p确认端口列表里有固定后的mountd端口。这样一来后续如果CNA侧要按端口放行就不会被动态端口坑到。3.4 容量与协议版本的确认共享目录建好后用df -h /data/fusioncompute确认容量正常最好再执行一次stat -f /data/fusioncompute看看inode资源是否充足。虚拟磁盘文件动辄几十GB但inode耗尽会导致文件创建失败这种问题用df看不出来磁盘空间明明有剩余却报“no space left on device”查NFS日志才能发现是inode满了。关于NFS协议版本FusionCompute不同版本对NFS v3和v4的支持情况有差异。我的经验是如果环境里没有特殊需求尽量让NFS服务同时支持v3和v4这样FusionCompute侧兼容性最好。某些很老的RHEL/CentOS版本可能默认关掉了NFSv3需要确认。网络上传出很多关于NFSv4的idmap映射问题在v4配置不当的情况下会出现文件属主变nobody的怪象。排查这类问题先rpcinfo -p看版本列表再决定要不要强制用v3。4. FusionCompute对接实操从添加数据存储到创建虚拟机4.1 添加前在CNA上的检查NAS侧搞定了别急着去FusionCompute界面点添加先到CNA上做一轮连通性检查。SSH登录CNACNA默认的运维账号不同版本可能有差异但我一般会使用root或者被授权的管理员账号加SSH key执行ping 192.168.10.10 -c 4 rpcinfo -p 192.168.10.10 | grep nfs showmount -e 192.168.10.10ping能通说明网络没问题rpcinfo能看到nfs和mountd等服务showmount能看到导出路径说明NFS协议栈没问题。如果showmount正常但FusionCompute还是扫不到多半是防火墙或者CNA到NAS的某个中间网络设备拦截了。然后检查一下CNA上是否已经挂载过这个共享。之前手动测试留下的挂载点或者之前失败操作残留的挂载都会干扰界面添加数据存储mount | grep fusioncompute有残留就umount确保一个干净状态。FusionCompute添加数据存储时如果发现该共享已被占用会直接报错。4.2 界面添加NAS数据存储的完整流程登录FusionCompute进入资源池或者存储管理页面不同版本入口名字略有差别但套路一致。大致步骤是进入“存储”或“数据存储”管理页面点击“添加数据存储”存储类型选择NAS填写NAS服务器IP以及导出路径例如 /data/fusioncompute选择要挂载该数据存储的CNA主机提交后等待状态变为正常。添加成功后数据存储列表里能看到容量和剩余空间对应的CNA主机的状态也会变成正常。如果状态一直是“异常”或者“正在扫描”说明底层NFS访问有问题回到前面的检查步骤去排。这里我要提醒一点同一个NFS共享不要重复添加到多个不同的数据存储条目里更不要一部分CNA挂共享A、另一部分CNA挂共享B然后指望它们能互通。FusionCompute对数据存储的识别以共享路径为维度路径不一致在后续虚拟机迁移、克隆时会出现各种奇怪问题。4.3 路径和IP填写的细节坑填写导出路径时必须以 / 开头不能带协议前缀也不要漏掉最后一级目录。比如NFS导出了 /data/fusioncompute就填 /data/fusioncompute不要填成 data/fusioncompute 或者 //data/fusioncompute。这个细节写错了界面会提示找不到共享路径。如果NAS有多个导出目录确保填的路径和 /etc/exports 里完全一致包括大小写和斜杠。NFS导出路径是精确匹配的多一个字母都不行。showmount -e 的输出就是最权威的参考直接照着填。4.4 创建虚拟机与磁盘操作注意事项数据存储添加成功后创建虚拟机时就可以把虚拟磁盘放在这个NAS数据存储上。虚拟磁盘在NAS上表现为一个大文件常见格式是qcow2。系统装完后如果想手动备份虚拟机最稳妥的方式是先把虚拟机关机再在NAS上直接拷贝对应的镜像文件。开机状态下直接拷贝qcow2文件是非常危险的因为文件一直在被写入拷贝出来的镜像大概率不可用。快照功能在NFS存储上也能用但我个人的建议是尽量少用。FusionCompute的快照功能会生成内部快照链合并快照时I/O压力集中在NFS共享上如果网络本身有抖动快照合并失败会造成虚拟磁盘异常。测试环境里偶尔用用可以生产环境别把快照当备份。另外千万不要在NAS上用qemu-img等工具直接修改正在被FusionCompute使用的虚拟磁盘文件。一旦双方状态对不上轻则虚拟机启动失败重则镜像损坏这种错误属于“自己把自己坑死”的类型。5. 性能测试与调优方案5.1 用fio先测NAS裸性能对接完成不代表一头扎进去就完事性能摸底一定要做。先在NAS本机跑一遍fio看看这台NAS的磁盘能力底子如何。安装fio后执行fio --filename/data/fusioncompute/fio_test --rwrandrw --rwmixread70 --bs4k --size4G --numjobs4 --runtime60 --time_based --group_reporting --namerand_test这个命令测的是70%读、30%写的4K随机混合场景比较接近虚拟机日常I/O形态。跑出来的IOPS如果只有几十到一百多那基本可以确认瓶颈在机械盘阵列本身后续再怎么调网络意义都不大。再跑一个顺序读测试fio --filename/data/fusioncompute/fio_seq --rwread --bs1M --size8G --runtime30 --time_based --group_reporting --nameseq_read顺序读的MB/s高不代表虚拟机性能好虚拟化环境更看重随机IOPS和延迟这两个数据心里要有数。测完记得把测试文件删掉避免占着共享空间。5.2 测网络与虚拟机内性能接下来在CNA和NAS之间跑iperf3验证存储网络有没有问题。NAS端开服务iperf3 -sCNA端发流量iperf3 -c 192.168.10.10 -P 4 -t 60如果吞吐量远低于网卡标称值一是检查MTU是否一致二是检查交换机端口协商模式三是看bond模式配置有没有生效。我遇到过一次CNA网卡协商成了百兆NFS怎么调都慢最后才发现是网线质量不行。网络验证通过后再去虚拟机内部跑一轮fio和NAS裸性能对比。如果虚拟机内性能远低于NAS裸性能重点查CNA到NAS之间的网络路径。如果接近说明NAS就是瓶颈接下来要么加强NAS硬件要么接受这个性能天花板。5.3 调整思路哪些能调哪些别乱调NFS导出参数里有一个常见的“性能作弊器”是async。改成async后NFS服务器不必等数据落盘就返回写成功写入延迟和吞吐都会明显改善但代价是断电时数据可能丢失甚至文件系统损坏。FusionCompute底层是虚拟化存储稳定性远大于性能除非是纯粹跑性能测试尝鲜否则我不建议开async。测试环境真想开也要先想清楚风险。更稳的提升路径是加缓存。NAS的内存放在越多越好Linux会把剩余内存自动用作page cache对NFS读操作帮助很大。写操作密集的话可以考虑给NAS加SSD缓存设备无论是bcache还是ZFS的SLOG都能明显改善随机写性能。条件允许就上万兆网卡NFS的网络瓶颈在千兆网卡下非常明显多台虚拟机并发时尤其突出。FusionCompute内部挂载NFS时的挂载参数不在我们直接控制范围里一般情况下不需要去改CNA的/etc/fstab加什么rsize、wsize。网上很多教程让你手动在CNA上挂载并写fstab这是典型的误导。FusionCompute有自己管理挂载的机制手动在fstab里加挂载反而会造成重复挂载、状态紊乱。6. 高频问题与排查实录6.1 问题速查表对接过程中出问题并不可怕可怕的是不知道该从哪查起。下面是我整理的高频问题速查表基本覆盖了常见故障现象可能原因排查与解决FusionCompute扫描不到NAS共享防火墙动态端口未放行、NFS服务未启动、导出路径写错showmount -e检查导出列表放行2049/rpcbind/mountd端口核对导出路径添加数据存储提示权限错误root_squash未关闭、目录属主不对在exports里加no_root_squash重跑exportfs -rav本地touch验证CNA挂载时提示Network is unreachable存储网VLAN/IP没连通、路由缺失ping检查确认CNA存储口IP是否在同一个VLAN检查交换机配置虚拟机创建后无法启动提示找不到镜像多CNA共享路径不一致统一所有CNA访问同一个NAS IP和导出路径不要混用虚拟机运行中卡IONAS日志出现连接重置网络丢包、MTU不一致、bond链路异常iperf3压测ping大包测试检查网卡协商和交换机丢包统计NAS重启后数据存储异常NFS断开后未自动恢复确认CNA能重新挂载在FusionCompute里手动重置数据存储前提是相关虚拟机已关机数据存储容量显示0或异常共享目录挂载的是空盘、权限无法stat检查NAS文件系统是否挂载正常df和stat确认权限快照合并慢或者失败文件锁异常、网络波动、剩余空间不足减少频繁快照确保共享剩余空间充足必要时关机后合并6.2 排查三板斧遇到NFS对接问题我的排查套路固定三步。第一步到CNA上手动挂载并读写。这一步能一次性排除掉FusionCompute界面层的问题把故障范围缩小到网络、NFS协议、权限三个层面mkdir -p /tmp/nfstest mount -t nfs 192.168.10.10:/data/fusioncompute /tmp/nfstest dd if/dev/zero of/tmp/nfstest/test.img bs1M count128 convfdatasync umount /tmp/nfstest这条命令能成功意味着CNA到NAS的网络通、NFS协议正常、root写权限OK。第二步看内核日志。CNA上执行dmesg | grep -i nfs能看到NFS挂载和读写过程中的报错信息比如超时、权限拒绝、协议版本不匹配。NAS侧看 /var/log/messages 或者系统日志里的rpc.mountd、nfsd相关记录很多问题的真实原因藏在NAS侧日志里。第三步查NFS统计。NAS上执行nfsstat -s和nfsiostat可以看服务端各方法的调用次数和错误数。如果read/write成功率不高网络抖动或者客户端重传的问题会在这里暴露出来。6.3 一个翻车实录我记得有一次FusionCompute添加数据存储一直报“挂载失败”CNA上手动挂载也报“Operation not permitted”。当时我先怀疑root_squash没关但检查exports文件发现no_root_squash明明加了。后来在NAS上用rpcinfo -p一看mountd端口是动态的防火墙只放行了2049mountd的端口被防火墙拦住了。固定mountd端口并放行后问题立刻消失。这类问题的迷惑性在于showmount -e 能正常看到导出目录因为showmount走的是rpcbind端口但真正mount时客户端需要访问mountdmountd被防火墙挡住就会报权限错误。很多人看到“Operation not permitted”就直接去折腾权限方向完全错了。7. 让自建NAS更稳安全加固与运维习惯7.1 网络层面的最小化暴露NFS协议没有加密一旦被不该访问的人访问到虚拟磁盘文件等于裸奔。所以网络隔离必须做彻底。存储网段只允许CNA和相关管理设备接入防火墙规则只放行CNA网段访问2049、rpcbind和固定后的mountd端口其他人一律挡掉。千万不要图省事把NFS服务暴露到办公网或者更广的网络范围。公网访问更是想都不要想。虚拟机的磁盘文件都在NFS上等于家里所有值钱东西放在一辆没有锁的三轮车上被拖走只是时间问题。人为制造这种风险毫无意义。7.2 数据可靠性的底线可靠性方面我认为至少有四件事不能省一是UPS。NAS没接UPS市电一晃或者机房断电正在写入NFS的虚拟机文件大概率损坏这不是数据丢失的问题是直接起不来的问题。二是磁盘冗余机械盘必须RAID或者ZFS阵列单盘跑虚拟化存储就是赌运气。三是定期巡检SMART磁盘自检、ZFS scrub、文件系统检查都要排进计划。四是备份NAS上的虚拟磁盘文件不是备份只是数据的“唯一副本”定期把关键虚拟机关机后rsync到另一台机器或者备份服务器才算真正有备份。rsync -avP --delete /data/fusioncompute/ 192.168.20.20:/backup/fusioncompute/这条命令建议放在虚拟机关机的维护窗口跑直接跑运行中虚拟机的qcow2文件没有任何意义拷出来的镜像大概率是坏的。7.3 多CNA场景的锁与一致性如果FusionCompute有多台CNA同时访问同一个NAS共享文件锁的可靠性就非常关键。Linux原生的NFS导出对锁的支持比较可靠但前提是NAS上跑的确实是标准NFS服务不是拿Samba把某个SMB目录再导出成NFS的野路子。我见过有人在一台成品NAS上搞了两层协议转换最后虚拟机迁移时锁冲突各种诡异故障查了三天才定位到是共享本身的问题。多CNA之间还必须做NTP时间同步。NFS协议对文件锁的依赖以及FusionCompute对虚拟机状态的管理都需要各节点时间基本一致。CNA和NAS的时间差太多文件锁和日志都会乱套。我自己在实际维护中最大的体会是FusionCompute对接自建NAS这套方案价值在于“灵活”先决条件是不要把它当成真正的生产存储来赌。权限、网络、备份都规范好之后它跑测试集群、研发环境、灾备演练都非常顺手。最后再分享一个小习惯每次改NAS配置之前先记录一下当前FusionCompute数据存储的UUID和挂载情况一旦调整了exports或重启NFS服务先在NAS和CNA两端各做一次连通性测试再回界面确认数据存储正常能省掉很多半夜翻日志的时间。