自托管的数据多到"一块硬盘/一台机器放不下"时，会有两条路：要么堆更大的单机盘（贵、有单点），要么用多台机器把存储"拼"成一个更大的、能横向扩展的共享存储。前者是"扩大单点"，后者是"分布式文件系统"——把多台机器的磁盘聚合成一个逻辑命名空间，像访问一个目录一样访问"一群盘"，还能跨节点冗余、自动恢复。自托管里最常见、也最容易上手的开源方案是 GlusterFS（而更重的是 Ceph）。这篇讲清分布式存储解决什么、GlusterFS 怎么搭、和 NFS/单机盘怎么选，以及常见坑与边界。
一、分布式文件系统解决什么：把"多台机器的盘"变成"一个大共享存储"
当数据量超过单机盘的舒适区，或你希望"存储不绑死在一台机器"时，分布式文件系统（DFS）把多台节点的本地磁盘聚合成一个统一的逻辑文件系统：应用看到的是一棵目录树、一个挂载点，底层数据分布在不同节点上；配合副本（replica）或纠删码，某台节点坏掉数据不丢、服务不停；容量不够时加节点就能水平扩。这解决的是单机存储的"容量天花板 + 单点风险"——对相册、备份、媒体这类"大而多"的数据尤其有价值。
它和前面聊的 NFS 的区别要分清：NFS 是"一台服务器导出目录，多台挂载共享"——共享没问题，但服务器本身仍是单点、容量也受那台机限制；分布式文件系统是"多台机器共同构成存储池"——既共享、又冗余、又能横向扩。NFS 解决"共享"，DFS 解决"共享 + 冗余 + 扩展"。自托管量级里，多数人先 NFS 就够；数据量大到"单机盘扛不住、怕单点"才上 DFS。
二、GlusterFS 怎么搭：brick 聚合卷 + 副本 + 客户端挂载
GlusterFS 的思路是"卷（volume）"：把各节点的目录（brick）聚合成一个卷，客户端通过 FUSE 或 NFS 协议挂载它。以最常用的"副本卷"为例：你在 3 台节点各留一个 brick，创建一个 `replica 3` 的卷，数据会在 3 个 brick 上各存一份——任一节点挂掉，其余副本照样服务；节点数不够时自动从可用副本补。搭法：每台节点装 glusterfs-server 并加入同一个信任池（peer），然后创建一个卷并挂载到客户端。它是"无中心、无元数据服务器"的架构，运维相对简单。
# 假设 3 台节点：gfs1 gfs2 gfs3（已装 glusterfs-server）
# 1) 每台建一个 brick 目录
mkdir -p /srv/gfs/brick
# 2) 加入信任池（在某台执行，把其他节点加进来）
gluster peer probe gfs2
gluster peer probe gfs3
# 3) 创建副本卷（副本数 3，把三台各一块 brick 聚合）
gluster volume create gvol replica 3 \
gfs1:/srv/gfs/brick gfs2:/srv/gfs/brick gfs3:/srv/gfs/brick
gluster volume start gvol
# 4) 客户端挂载（FUSE）
mount -t glusterfs gfs1:/gvol /mnt/gvol
# 之后 /mnt/gvol 就是"三台机器冗余的一份共享数据"
GlusterFS 的关键认知是"卷是逻辑单位，brick 是物理单位"：扩容量通常是"加卷/加 brick"，改副本数要按官方步骤做（先加 brick 再 rebalance）；副本卷的"写入性能"受最慢节点制约，且修复（self-heal）在网络慢时可能积压。别把"创建卷"当成"配好冗余"——副本生效、自愈能跑、客户端挂载稳定，才算真的用起来。
三、和 NFS/单机盘怎么选：量级、单点容忍与复杂度换什么
选型要按"数据量级 + 对单点的容忍 + 愿付的复杂度"来：数据不大（几百 GB 内）、能接受"共享但单点"→ 单机 + NFS 最省心；数据大（TB 级）、要冗余与横向扩展、愿意维护多节点 → GlusterFS 是自托管友好的中间选择；数据非常大、要强一致与对象/块/文件全场景 → Ceph（功能最全但运维最重，通常超出多数自托管需要）。判断的锚点是"单机盘还够不够、单点能不能接受"——能接受就不上 DFS，复杂度是用来换"容量与冗余"的，不是用来炫耀的。
# 选择参考
# 几百 GB、单机扛得住、只要共享 → NFS/单机 + 备份
# TB 级、要冗余、要横向扩 → GlusterFS（副本卷）
# 超大数据、强一致、多协议 → Ceph（先想清楚运维成本）
# 给 DFS 的数据也要备份/快照：冗余 ≠ 备份，误删/勒索照样要恢复手段
最容易犯的错是把"多副本冗余"当成"备份"：副本保护的是"某台节点坏"，不保护"误删、勒索、逻辑损坏"（那会同步删到所有副本）——DFS 之上仍要快照/备份/异地。另一个是把复杂度误判：多节点 DFS 意味着网络、节点维护、自愈监控都成了日常，不是"加个盘就完事"。
四、常见坑：脑裂与自愈、性能受最慢节点、扩容与 rebalance、监控
GlusterFS 跑起来，四个坑要尤其防。一是"脑裂与自愈"：节点网络分区时，副本可能各自更新产生脑裂（split-brain），自愈（self-heal）处理不了的文件会报错——网络要稳、出现 split-brain 要按文档选"以哪份为准"处理，别瞎删。二是"性能受最慢节点拖累"：副本卷写入要等所有副本，一台慢盘/坏盘会拖慢全局——节点硬件尽量一致、坏盘及时换。三是"扩容与 rebalance"：加 brick/加节点后数据要 rebalance 才会真正分布，而 rebalance 有负载与耗时，别指望"加完立刻均匀"，错峰做。四是"监控"：卷健康、brick 状态、自愈队列、磁盘水位都要纳入监控（配合前面聊的 Prometheus/Grafana），否则"冗余了却不知道某副本已坏"等于裸奔。
# 常用健康检查
gluster volume status gvol # 看各 brick 状态（在线/离线）
gluster volume heal gvol info # 看自愈队列（有哪些文件待修复）
gluster volume info # 看卷与副本配置
# 磁盘水位与性能：配合 node_exporter/Prometheus 盯每台 brick 所在盘
把它当排障 SOP：挂载"打不开/慢"先看卷状态与自愈队列；数据"不一致/脑裂"查网络与 split-brain 处理；容量"到顶"规划加 brick + rebalance。分布式存储的"冗余感"建立在"你清楚每份副本在哪、自愈是否正常"之上，别只看"卷还在"就放心。
五、边界：DFS 管"容量与冗余"，不替代备份、也有运维与强一致代价
分布式存储的边界要认清：它把多台机器的盘聚合成"容量可扩展 + 节点级冗余"的共享存储，但**不替代备份**（误删/勒索/逻辑损坏会波及所有副本，备份仍要独立做）；"最终一致/复制滞后"在部分场景会读到旧数据，强一致需求（数据库主存储）不适合直接放 DFS（数据库类请走 StatefulSet + 专业存储/本地盘）；多节点维护（固件、网络、自愈）是持续成本，规模与收益要算清。对自托管，GlusterFS 适合"媒体/备份/共享大目录"这类"量大、能容忍适度延迟"的数据，不适合"强一致、低延迟"的数据库主存储。
把分布式存储放回自托管整体：它是"数据量越过单机舒适区后"的横向扩展与冗余方案，和单机 + NFS、以及专业存储各管一段。落地要点：数据大到要冗余与扩展再上 GlusterFS——用副本卷把多节点 brick 聚合成一个挂载点，客户端 FUSE/NFS 挂载；先想清"NFS 够不够、单点能不能忍"，别为复杂度而上；防住脑裂与自愈、性能拖尾、扩容 rebalance、缺监控四坑，并给它也配备份/快照；认清它管"容量与冗余"、不替代备份、也不适合强一致的数据库主存储。当你把"共享 + 冗余 + 可扩展"用对量级、管好自愈，自托管的"大而多"数据才算真正有了一个不绑死单机的家。
结语
GlusterFS 分布式文件系统的价值，是把多台机器的磁盘聚合成"一个可挂载的大共享存储"，换来容量可横向扩展与节点级冗余：用副本卷让数据在多个 brick 各存一份，节点坏了数据不丢、服务不停。落地要点：按"量级 + 单点容忍 + 复杂度"决定上不上——NFS 够就不上，数据大到要冗余与扩展再上；用 trust pool + 副本卷 + FUSE/NFS 挂载搭起来，并把副本、自愈、rebalance 纳入监控；防住脑裂自愈、性能被最慢节点拖累、扩容要 rebalance、缺监控四坑；认清它管容量与冗余、不替代备份、也不适合强一致的数据库主存储。当"大而多"的数据有了可扩展、可冗余的家，自托管才不会在数据增长时被单机盘的墙挡住。
