对预算有限的中小企业来说，建设一套可横向扩展的文件存储通常面临两难：商业NAS的扩展能力有限，高可用方案授权又贵；云盘按容量长期订阅，成本也不低。开源分布式存储在软件授权上几乎不花钱，但需要团队投入一定学习成本。本文会把范围限定在一个现实目标：用普通x86服务器、空闲硬盘和开源软件，搭建一组容量可扩、能承受单节点故障的NAS。方案重点不是追求Ceph级别的统一存储能力，而是让文件共享、部门协作、备份归档等场景在可控复杂度下稳定运行。
一、先厘清需求：开源分布式NAS不是单一产品
很多人把分布式文件存储和开源NAS当成同一个东西，但在开源生态里并没有一个统一产品叫开源分布式NAS。常见开源组件包括GlusterFS、MinIO、Ceph、SeaweedFS，以及更接近成品NAS系统的TrueNAS SCALE和OpenMediaVault。它们提供的接口、数据组织方式和运维复杂度差别很大。如果一开始没有按业务需求选型，后面越运维越痛苦。
如果团队只有少量并发客户端，主要场景是通过Windows映射网络驱动器存放Office文件、设计稿、部门共享目录，GlusterFS复制卷或TrueNAS SCALE更合适。GlusterFS的优点是无中心元数据节点，挂载简单，支持复制和纠删码；缺点是大量小文件性能一般，不适合需要复杂ACL和文件锁的应用。MinIO强在S3接口，适合备份、日志归档、对象存储，但把它当文件服务器会别扭，SMB和NFS支持需要额外网关，权限模型也不是传统目录权限。Ceph功能最全，但运维涉及OSD、MON、MDS多个组件，中小企业没有专职存储工程师不建议在生产环境单独维护。选择时建议先问三个问题：主要访问协议是SMB或NFS还是S3？单目录文件数量是否超过百万？一年内容量会增长多少？
结论可以简化：传统意义上的共享盘用GlusterFS；对象存储服务用MinIO；如果只想要一台服务器开箱即用，TrueNAS SCALE加ZFS阵列比强行分布式更稳。分布式不是目的，高可用和容量扩展才是。
二、低成本搭建GlusterFS复制卷实例
硬件层面不必采购品牌存储服务器。三台淘汰的机架服务器或高配工作站即可作为初始节点。每台至少两块硬盘，一块装系统，一块独立数据盘建议格式化为XFS。如果预算允许，为三台节点配置千兆以上有线网络，客户端与存储节点之间最好也是千兆或万兆。对于小型办公场景，三台节点配置8GB到16GB内存、四核CPU通常够用；但如果目录里大量小文件，内存和SSD会直接影响性能表现。
软件准备阶段，假设三台主机名分别为node1、node2、node3，操作系统安装Ubuntu Server LTS。先在三台机器上安装GlusterFS服务端，并启动glusterd。命令如下：
sudo apt update sudo apt install -y glusterfs-server sudo systemctl enable --now glusterd
然后从node1将另外两台加入信任池：
sudo gluster peer probe node2 sudo gluster peer probe node3 sudo gluster peer status
创建卷时需要指定数据目录brick。常规三副本卷每台节点各存一份完整数据，容错一台宕机；如果希望节省磁盘空间，可以使用2副本加仲裁的结构，第三台只保存元数据不保存完整文件。下面命令创建三副本卷：
sudo mkdir -p /data/brick1 sudo gluster volume create gv0 replica 3 node1:/data/brick1 node2:/data/brick1 node3:/data/brick1 force sudo gluster volume start gv0
若采用2副本加仲裁，则需要提前在第三台建仲裁目录，并使用replica 2 arbiter 1参数。仲裁节点磁盘占用极小，适合只有两台高性能服务器加一台迷你机的场景。
客户端挂载时，Linux客户端需要安装glusterfs-client后执行mount，并进行写入测试：
sudo apt install -y glusterfs-client sudo mkdir -p /mnt/nas sudo mount -t glusterfs node1:/gv0 /mnt/nas sudo dd if=/dev/zero of=/mnt/nas/testfile bs=1M count=100
Windows客户端可通过SMB共享访问。在Linux节点上安装Samba，把/mnt/nas共享出去。简单配置如下：
[global]
workgroup = WORKGROUP
server string = NAS
security = user
map to guest = never
[share]
path = /mnt/nas
browseable = yes
writable = yes
valid users = @staff
create mask = 0664
directory mask = 0775
在Windows资源管理器地址栏输入 \\node1\share 即可映射网络驱动器。注意如果直接使用GlusterFS原生命令挂载到多个客户端，需要控制好POSIX权限，避免同一目录被不同用户误写。
三、日常运维重点：健康巡检、备份与扩容
集群上线后最需要关注的是卷健康状态和自愈情况。GlusterFS复制卷在节点短暂离线后，重新上线会触发自愈，但自愈不一定总能自动完成。建议每周检查：
sudo gluster volume status gv0 sudo gluster volume heal gv0 info sudo gluster volume heal gv0 info split-brain
其中第三个命令专门用来查看裂脑文件。裂脑指网络分区期间同一文件在多个节点出现不同写入版本，系统无法自动判断以哪一份为准。裂脑数量不为零时，必须手动处理并保留正确副本。不要等到用户反馈文件内容不对才想起来查，那时候可能已经扩散到多个目录。
监控方面，至少应采集节点CPU、内存、磁盘使用率、网络吞吐和卷在线状态。可以使用Prometheus搭配gluster_exporter，将异常状态接入告警。磁盘使用率建议控制在80%以下，因为GlusterFS在brick接近写满时会出现写入失败或性能明显下降。容量不足时优先扩容而不是删旧数据。增加节点后，需要执行add-brick和rebalance：
sudo gluster volume add-brick gv0 replica 3 node4:/data/brick1 force sudo gluster volume rebalance gv0 start sudo gluster volume rebalance gv0 status
重新平衡会大量读取和迁移数据，可能影响在线业务，建议在非工作时间进行，并提前备份关键数据。
备份永远不能省。分布式复制卷解决的是硬件故障下的可用性，不解决误删除、勒索软件、人为覆盖等问题。至少要保留一份离线或异地备份。中小企业可以用rsync或restic把关键目录同步到移动硬盘、第二台NAS或对象存储。如果使用MinIO作为备份目标，可以通过rclone定期同步，并开启版本控制，这样即使源端文件被误改也可以从版本历史恢复。
四、常见问题与注意事项
第一类高频问题是性能。小文件读写慢是GlusterFS的常见短板。原因在于文件元数据需要在多个节点间协调，网络延迟被放大。优化方向包括使用SSD做brick、万兆网络、调整客户端缓存参数，以及从应用层合并小文件后再写入。若场景主要是几十万个小于100KB的文档，建议先测试真实负载，必要时改用对象存储或ZFS本地阵列。
第二类问题是两节点集群。两个节点直接组复制卷非常危险，因为一旦网络断开，双方都可能继续接受写入，产生脑裂且没有仲裁方。低成本方案要么三节点，要么两台数据节点加一个轻量仲裁节点。仲裁节点不需要大硬盘，但必须独立于两台数据节点，否则仲裁失效。
第三类问题是权限和协议混淆。GlusterFS本身提供POSIX文件系统语义，SMB共享则引入Samba的用户映射和锁机制。如果Windows客户端频繁编辑同一文件，需要确保Samba配置正确，不能在多台Samba服务器上同时暴露同一个GlusterFS卷而没有共享锁协调。另一个常见错误是直接把MinIO当作NAS用，MinIO没有本地文件锁和传统目录权限，部分应用直接读取S3挂载目录会出问题。因此对象存储和文件共享要分开规划。
最后提醒，任何开源存储上线前都要做一次故障演练：手工断开一台节点电源，观察另一台能否继续提供读写；恢复后检查自愈是否完成；模拟网络分区查看是否出现裂脑。没有演练的高可用只是纸面高可用。规模不大的团队建议维护一份简单运维手册，记录卷名、brick路径、节点IP、备份计划和恢复步骤，避免人员变动后无人能接手。
整体来说，中小企业用开源方案搭建分布式NAS是可行的，前提是选择匹配业务的方案，而不是盲目追求Ceph等功能最全的项目。用三台普通设备加GlusterFS复制卷，可以以较低成本获得单节点故障下仍可用的共享存储；再配合Samba、监控和独立备份，能够覆盖多数办公协作场景。真正需要投入的不是软件授权费，而是对卷状态、自愈和备份的持续关注。