企业官网建设流程全解析

采购单报上去之后才被问"容量到底怎么算的"，是存储选型里很尴尬的时刻。这篇文章把对象存储的容量估算拆成磁盘、内存、带宽三个维度，每个维度给公式、给默认值，能溯源的数字全部标注出处，落点用 RustFS 生产模式的默认布局来算。照着填空，方案里的容量那一节就能写出依据。

容量先拆成三本账：标称、格式化后、可用

买来的 100 TiB 硬盘，到应用手里远没有 100 TiB 可用，中间隔着三层折扣。第一层是纠删码：RustFS 生产环境走多节点多磁盘（MNMD）模式，官方部署文档给出的默认布局是 12+4，每个对象拆成 12 个数据分片加 4 个校验分片，分散在不同服务器的不同磁盘上。可用比例的算术很简单：12 ÷ 16 = 75%。反推原始容量，用可用空间除以 0.75，也就是乘 4/3：要提供 100 TiB 可用空间，裸盘至少 133.3 TiB。三副本架构可以对照一下：可用比例 1/3，同样 100 TiB 可用需要 300 TiB 裸盘。副本数和纠删码在空间效率上的差别，拿这个除法自己算就能对上任何一套系统的账。

第二层是文件系统与介质开销。XFS 格式化之后的容量会略小于标称；SSD 还要预留 OP（Over-Provisioning，主控预留空间）提高写入耐久度，官方硬件指南建议预留 20%，一块 7.68 TB 的盘实际可用 6 TB 出头。格式化和挂载参数官方也给了明确口径，照抄即可：

mkfs.xfs -f -L rustfs_disk1 -d su=256k,sw=10 /dev/sdb UUID=xxxx /mnt/disk1 xfs defaults,noatime,nodiratime,logbsize=256k 0 0

第三层是增长预留：官方建议按未来 24 个月的增量做规划，水位红线业界一般定在 70–80%（经验法则），到线就触发扩容流程。三层折扣相乘之后，方案里写的可用容量通常只有裸盘标称的一半左右，报价前把这笔账先算清。

顺带把部署模式的底线列出来。RustFS 的部署模式对比里，SNSD 单节点单磁盘无冗余，只配做开发测试；SNMD 单节点多磁盘，容忍节点内校验盘故障；生产负载要求 MNMD，至少 4 台服务器。规划集群台数时这是硬约束，4 台起步。

盘位还有一个下限算术：12+4 布局每个对象要拆出 16 个分片，官方部署示例是 4 节点 × 4 盘正好 16 块盘，集群总盘位低于这个数，分片就没有地方落。另外官方硬件指南强调"服务器群"模式：所有节点用相同批次、相同固件的硬件，单节点建议 12 个盘位以上的 2U 机型。采购单上的盘位一致性，从这一条起算。

平均对象大小决定元数据规模，这一项最容易漏

字节容量算完，还得算对象数量。对象总数 = 有效数据量 ÷ 平均对象大小，除出来的这个数决定元数据压力。官方硬件配置指南给的经验区间：平均对象大小按 128 KB 到 1 MB 规划，超过 1 亿个对象需要特别优化；单集群活跃存储桶建议不超过 500 个。

做个具体的除法：500 TiB 数据、平均对象 512 KB，对象总数约 10 亿个，已经踩进"需要特别优化"的区间；同样的数据量换成 5 MB 的大文件，对象数只有 1 亿出头。同一个桶装 512 KB 的照片和装 5 MB 的视频，对元数据层是十倍的差距，方案里必须写清这个除数的来源。

平均对象大小还影响盘上 IO 的形态。12+4 布局下每个对象拆 16 片，512 KB 的对象每片只有 32 KB，1 MB 的对象每片 64 KB（算术）。对象越小，同样字节数产生的分片 IO 次数越多，小对象占大头的业务，磁盘这一本账要单独按 IO 次数而不是字节数再算一遍。

对象数量还决定运维操作的代价。S3 的 ListObjects 单页上限 1000 条，这是 AWS 官方 API 文档写死的值，RustFS 兼容 S3，同样遵循。遍历 10 亿个对象就是 100 万次请求，还是除法：对象总数 ÷ 1000 = 列举请求数。做数据巡检、生命周期清理、迁移预演的工具都按这个量级估耗时。给个直观的换算：假设每页请求连网络带处理花 0.1 秒（假设值，看网络和客户端），100 万次请求要跑上一天多，全量盘点类脚本排夜里的维护窗口才有得跑。

还有一个隐性占用：桶开了版本化之后，旧版本不会因为覆盖而立刻释放，S3 语义下所有历史版本都保留到显式删除。写入频繁的桶要按"有效数据 × 修改频率"估算额外占用，清理策略没配之前，这块空间只增不减。RustFS 支持桶版本化，开不开在业务侧定，容量账要把这一项计入。

内存不用拍脑袋，官方文档给了一条线性公式

内存规划最常见的回答是"看情况"，RustFS 的硬件配置指南直接给了一条可计算的公式，按数据总量（TB）线性外推：

基础内存 32 GB 读密集型：32 + 0.8 × 数据TB 写密集型：32 + 1.2 × 数据TB 混合型： 32 + 1.0 × 数据TB

对照表：10 TB 对应读 40 / 写 44 / 混合 42 GB；100 TB 对应 112 / 152 / 132 GB；500 TB 对应 432 / 632 / 532 GB。公式按集群的数据总量算，结果也是集群总内存，除以节点数才是单机配置，别把整套数值配到一台机器上。这是官方文档给出的规划公式，属于经验法则，选型时留出余量，上线后按自己的监控校准。内存用途的分配建议也给了：元数据缓存 60%、读写缓冲区 30%、系统预留 10%。元数据占大头，上一节算出的对象总数直接决定这块的规模。

硬件选型页给出生产底线：内存 64 GB 以上、CPU 2×12 核以上、网络 10 Gbps 以上、SSD 存储、4 节点以上；测试环境最低 1 核 1 GB 就能跑。官方硬件矩阵还给了三档整机配置当定价锚点：基础档 4 节点 × 4 NVMe × 64 GB 内存 × 双 25GbE；生产标准档 8 节点 × 8 NVMe × 256 GB × 双 100GbE；高性能档 16 节点起 × 12 NVMe × 512 GB × 200GbE。拿公式算一笔账：100 TB 的混合负载集群，公式给 132 GB，选型底线给 64 GB 以上，实际配置取两者较大值再留余量，落到 256 GB 档位比较稳。

带宽按最坏的窗口倒推，再和磁盘配比对表

带宽有两个算法，取较大值。第一个是官方给的预留规则：每 TB 有效数据预留 0.5 Gbps 带宽，100 TB 数据配 50 Gbps 专用带宽。第二个按业务窗口倒推，把日增数据摊到写入窗口里：

日增 5 TB ÷ 8 小时窗口 = 5000 GB ÷ 28800 秒 ≈ 174 MB/s ≈ 1.4 Gbps

再乘上纠删码的写放大：12+4 布局下每写入 1 份数据，网络上实际要传 16/12 ≈ 1.33 份，因为 12 个数据分片加 4 个校验分片都要过网络。这笔放大发生在集群内部分片分发环节，业务侧上传的文件不会跟着膨胀。上例 1.4 Gbps 乘 1.33 ≈ 1.9 Gbps，加上读流量和扩容时 rebalance 的余量，对照 0.5 Gbps/TB 的预留规则取大。两笔账摆在一起，网络方案就有依据了。

算出 Gbps 之后要和磁盘配比对表，官方给了这张换算表：

Bit 换 Byte 除以 8，1.25 GB/s 就是 10GbE 的理论上限，实际吞吐会低于这个数，取决于协议栈开销和 CPU。磁盘配超了，网络先成瓶颈；配少了，磁盘在闲着。拓扑侧官方指南也给定了要求：叶脊结构、存储网络物理隔离、双上行链路。延迟指标官方也给了线：节点间 P99 ≤ 2 ms，跨机架 ≤ 5 ms。存储控制器侧照官方指南走：禁用 RAID，全部直通模式，让纠删码自己管冗余。RustFS 生产网络的底线是 10 Gbps 起，S3 API 和控制台分别走 9000、9001 端口，防火墙和交换机侧按这两个端口放行。

速查表

三本账汇总成一张表，可以直接抄进方案：

拿 1 PB 级混合负载集群把这张表从头跑一遍，四个数就都有了：

• 磁盘：要 1024 TiB 可用，除以 0.75 得裸盘 1365 TiB（约 1.5 PB），叠加 20% 水位预留和格式化损耗，采购标称 1.8 PB 上下起步；
• 对象数：按平均 512 KB 除，约 21 亿个，远超 1 亿阈值，方案里要么提高平均对象大小、要么拆多集群，元数据优化单列一章；
• 内存：32 + 1.0 × 1024 ≈ 1056 GB，集群合计约 1 TB，4 节点起步时每台 256 GB 是下限档；
• 带宽：预留规则给 0.5 × 1024 = 512 Gbps，窗口法算出来小得多。差距大的原因在数据冷热：0.5 Gbps/TB 假设全量数据都可能按比例活动，冷归档类集群按窗口倒推就够，热数据集群才需要顶格预留。两类场景用错了规则，要么多花一个数量级的网络钱，要么上量后带宽被打穿。

使用顺序照这张表从上往下：先算可用容量和裸盘数，再除出对象总数看元数据水位，然后套内存公式，最后按窗口和预留规则定网络。容量要扩时不必重建集群，RustFS 走存储池扩容，新池加上去，增量部分按同一套公式重算一遍。

相关入口：RustFS 是 Apache 2.0 许可、Rust 实现的 S3 兼容对象存储，容量规划对应的官方文档章节是安装与部署模式、生产环境硬件配置指南、存储池扩容，源码仓库在 GitHub。文中标注"经验法则"的条目拿去自己环境验证后再定稿，其余数字点到出处核对即可。