手上有一台四盘机器跑了大半年读写都正常什么时候该往上加机器这件事在没有出事之前很难回答出事之后再回答就晚了。RustFS 文档把部署模式划成三条线每条线的容错能力和典型用途都写得很清楚。看完之后你会发现真正卡人的地方在后面得先想清楚自己能接受哪一种故障直接让数据读不出来。三种部署模式划出的三条容错线RustFS 的安装文档里有一张部署模式对比表把节点数、盘数、容错能力和典型用途放在一行里模式节点盘容错典型用途SNSD11无只能靠备份开发、测试、低密度非关键业务SNMD1多块节点内最多 M 块校验盘单机上的中等、非关键业务MNMD4每节点多块跨服务器的盘级与节点级容错生产负载SNSD 那一行写的是None — rely on backups。意思很直接可靠性整个交给了备份。磁盘坏了靠备份恢复主机挂了也靠备份恢复。用它当然可以只是得清楚自己换来了什么。SNMD 强在一点同一个纠删集里坏掉最多 M 块盘照样能重建用不上备份。但它的容错范围只到这一台机器不到这一排机器。电源、主板、网卡、机柜断电任何一项出问题都是同一时间把这个节点上的全部分片一起带走。这一点最容易让人误判。它扛得住盘坏扛不住整机坏可企业内部不少测试环境恰恰拿 SNMD 放准生产数据觉得多盘就等于有生产级可靠性了。真等整机挂掉能兜底的还是那一份备份。SNMD 只适合非关键业务这句话不要打折。四台机器这条线是怎么定下来的MNMD 是官方给出的生产部署模式安装文档对它的最低要求是至少 4 台服务器、每台至少 1 块盘才能安全启动一个分布式对象存储集群。这个 4 不是随便定下来的。需要先把一个数字说清楚124 是系统的默认纠删集布局MNMD 模式并不强制用它换别的宽度也可以。一个对象被切成 12 个数据分片加 4 个校验片、散到不同服务器的不同盘上说的就是默认状态下会出现的样子。官方对这套布局给了两条保证任意一台服务器的故障或维护不影响数据安全最多 4 块盘的损坏也不影响数据安全。两条要合起来看。少提第一条会让人低估校验片的分量服务器不掉、只坏盘的那部分情况靠的就是那 4 个校验片。要 4 台的原因就在那两条保证里一个纠删集里的分片得落到不同机器上才有坏一台还剩三台这回事。机器不够容错域就只剩一个再多盘也堆不回节点级容错。硬件清单页给了一份按压测结果整理的参考矩阵可以作为采购的起点而不必当作承诺档位节点数存储网络CPU内存基础44× NVMe SSD双 25GbE 聚合2× Intel Silver 431016 核64 GB DDR4-3200 ECC生产标准88× NVMe SSD双 100GbE2× AMD EPYC 731332 核256 GB DDR5-4800 ECC高性能1612× NVMe SSD200GbE2× Intel Platinum 8461Y48 核512 GB DDR5-5600 ECC这份清单末尾自己标注了一句内容基于最新的 RustFS 开发版本实际部署要按具体厂商白皮书调参。这类数字给的是建议区间不是 SLA。拿它当参考线、别当验收线采购时能少跑一趟。再看网络和磁盘的配速。文档给了一张对应关系10GbE 大约只喂得动 8 块 7.2K HDD25GbE 约 6 块 SATA SSD100GbE 能让 2 块 Gen4 NVMe 跑满。给 NVMe 配千兆网的部署瓶颈会清清楚楚落在网络那一边磁盘和 CPU 都在旁边闲着。这套比值有个前提按磁盘吞吐上限算。业务如果是海量小对象瓶颈会转到 CPU 和元数据上不再受磁盘带宽约束这时候照这张表配网络就没意义了。上分布式之前要先补齐的三件小事从单机走向多机环境层面的准备比参数配置更容易出问题。MNMD 文档里写明安装前要确保所有节点满足生产检查项下面这三件不做轻则行为异常重则集群起不来。第一件是主机名。RustFS 集群要求各节点主机名相同且连续实现方式只有两条路DNS 里做解析或者写/etc/hosts。文档给的示例是给四个节点依次配node1到node4保证名字连续。第二件是时钟和端口。所有节点要用同一个监听端口时钟也要同步。多节点环境下证书有效期、复制延迟的判断、审计事件的先后顺序全都跟着时钟走。时钟漂移一般不直接报错它表现出来的样子通常是有些请求会莫名失败查起来很费时间。第三件是环境变量的一致性。多节点部署下每个节点都要有一份完全相同的环境文件任何一项差异都可能表现为集群起来了但某些操作失败。RUSTFS_VOLUMES用花括号枚举所有节点和挂载点文档给的四节点四盘示例是RUSTFS_VOLUMEShttp://node{1...4}:9000/data/rustfs{0...3} RUSTFS_ADDRESS:9000 RUSTFS_CONSOLE_ENABLEtrue RUSTFS_CONSOLE_ADDRESS:9001 RUSTFS_OBS_LOGGER_LEVELerror RUSTFS_OBS_LOG_DIRECTORY/var/log/rustfs/访问密钥、秘密密钥和RUSTFS_VOLUMES的取值在所有节点上必须一模一样主机名要和上面那份/etc/hosts对得上。目录也要提前建好并限定属主sudomkdir-p/data/rustfs{0..3}/var/log/rustfs /opt/tlssudochmod-R750/data/rustfs* /var/log/rustfs上面配置块里的{1...4}、{0...3}是 RustFS 自己解析的展开语法不是 shell 的花括号展开。这个文件由 systemd 加载那一层不会替你把花括号拼开最后是服务启动时读原文展开的。别拿 bash 的习惯往这边套也别把花括号写成字面的{1...4}塞进引号。顺带说一个容易看漏的点多节点之间的 RPC 复用的就是 9000 端口没有独立的集群端口。也就是说防火墙上只要开了 9000节点之间就已经互相连通了排查连通性时可以少跳一层。反过来9000 得当成对外端口认真对待控制台那个 9001 只放到可信网络里用不上就直接关掉。参数和拓扑是两件事别只调参数很多人把能不能扛住整机故障理解成纠删码参数问题。RustFS 的 EC 配置页专门写了一条反向提醒M 描述的是单个纠删集内的不可用分片数节点级容错取决于这个纠删集的盘怎么分布到各节点上不要假设EC:4总能扛住四整台节点失效一个节点完全可以放同一个纠删集的多个盘。同一份EC:4四块盘分散在四台机器上和四块盘全塞进一台机器参数一字不差容错能力差一个档次。前者能扛住一台整机掉电后者坏一块盘之后的重建余量就没了。这也是拓扑规划要在定 EC 参数之前做完的原因。参数能改能改的和动不了的还是两回事。调整存储类奇偶校验对已经写进去的对象没有影响每个对象的几何记在自己那份xl.meta里RUSTFS_ERASURE_SET_DRIVE_COUNT不一样池初始化之后就改不了了想把/data{1...4}改成/data{1...8}系统会认为你在重定义这个池直接拒绝启动。要做只能原池不动、另加一个池。带宽和内存这两个数字先算出来硬件清单页给了一组按有效数据量折算的经验值选型阶段用得上网络每 1 TB 有效数据预留 0.5 Gbps 带宽100 TB 数据对应 50 Gbps 专用带宽节点间 P99 延迟建议 ≤ 2ms跨机架 ≤ 5ms内存以data_tb为自变量的经验公式读密集32 data_tb × 0.8、写密集32 data_tb × 1.2、混合32 data_tb × 1.0。按这个表100 TB 混合负载对应 132 GB500 TB 写密集对应 632 GB对象规模平均对象大小建议落在 128 KB 到 1 MB 区间超过 1 亿个对象时文档建议单独做优化评估上面这几条有个共同前提都按有效数据算不是按裸容量。备份归档、副本冗余、未完成的上传都会把实际占用推高照裸容量去配带宽和内存通常会在半年后遇到一次说不清理由的扩容。内存那一行还要打个折。这套公式是按有效数据量线性外推的对象偏大时算得比较准换成海量小对象元数据会吃掉不少内存实际用量明显高于公式结果。小对象为主的场景内存按公式算出来的值往上留一截余量别按公式卡死上限。上线之前文档还建议做一轮 72 小时的压测至少覆盖节点故障切换、网络分区演练以及达到理论值 120% 的突发写压力。这三项里任何一项没跑过就进生产出问题时的第一手材料是缺的。网络分区这一项单独提一句这类演练放测试环境做就够了。生产集群上没有模拟一下这回事手一抖打出真实分区业务那边就是一次实打实的故障。判断清单把上面几节并排看选择的顺序其实很清楚先看能接受的故障类型再看节点数够不够最后才轮到性能和预算。反过来的做法先定预算再倒推拓扑在多数情况下会得到能省则省的结论而这个结论往往在第一次硬盘故障的时候被推翻。回到开头那个问题。给一个可以直接照着走的顺序你的情况建议模式开发、测试、非关键数据有备份SNSD单机承载中等规模非关键业务SNMD生产负载业务不能接受停机MNMD单机 CPU 或内存已经吃紧先凑够 4 台再谈扩容别在单机上一直加盘中间那两档的边界本来就模糊判断依据只有一条这台机器上如果整机挂掉业务能不能扛过去。能扛就留在单机扛不住就得上 MNMD。SNMD 换不来节点级容错这是布局决定的加内存加盘都绕不过去。真正让人吃亏的情形是单机跑得挺好就先不加机器了加到某天数据已经几百 TB再想扩成四节点分布式。这里要把话说死不存在在线原地迁移这回事。已经格式化的单盘部署不能靠追加端点或存储池来扩容启动时直接报UnsupportedSnsdExpansion已经初始化的多盘池驱动器数和集合宽度同样写死了改了就报PoolTopologyMismatch。两条路都指向同一个做法——新建一套部署把数据通过 S3 迁过去。从单机到分布式的那一步实际是另外搭一套再把数据搬过去。回头改的成本远高于起步时多花的两天。决定之前先做一件事在现有集群上跑rc admin info cluster rustfs --json把后端布局、纠删奇偶、盘可用性和池成员这四项看清楚。它报出来的几何跟你脑子里那张图对不上时先查拓扑再回头查参数。