分布式存储

分布式存储与RustFS

十分钟在自己机器上跑通一个 S3 兼容对象存储（RustFS + Docker）本地联调代码要一个对象存储、给客户做 POC 要演示、边缘小站想垫一层存储底座，都不值得专门为它采购和运维一套分布式集群。一条 docker run 就能在笔记本或一台小服务器上把 RustFS 跑起来，S3 接口直接可用，代码里把 endpoint 指过来就能测。这篇把从拉镜像到用 aws-cli 建桶的完整路径走一遍，并把几个最容易卡住的点讲清楚。

分布式存储与RustFS

在 1Panel 应用商店部署 RustFS：安装、配置与验证步骤装一套对象存储，教程往往一上来就是十几行的 docker run：挂卷、设环境变量、开端口，装完还得自己琢磨凭证和 TLS 的事。如果只是想给备份、图床或者网盘找个存储后端，可以先走一条更省事的路：RustFS 已经上架了 1Panel 的应用商店，安装、升级、日志查看都能在面板里完成。RustFS 是一个开源的分布式对象存储，100% 兼容 S3 协议，采用 Apache 2.0 协议。

分布式存储与RustFS

GPU 在空转等数据？PyTorch 训练集进 RustFS 的三种接法分布式训练里最尴尬的一幕往往是：GPU 算完一批，下一批数据还没从存储拉上来，几十张卡集体空转。把训练集放在对象存储、训练节点按需拉取，能把存储和计算彻底解耦，训练集群扩缩容时存储不用跟着动。很多团队一开始把数据集塞在本地 NVMe，单机训没问题，一上分布式多机就发现数据搬不动、各机看到的还不是同一份；对象存储用同一个 key 空间，所有节点读的是同一份数据，这份一致性是分布式训练的前提。RustFS 是 100% 兼容 S3 的存储，PyTorch、TensorFlow 不用改框架代码，只要把 endp

分布式存储与RustFS

把 LSM 引擎直接架在对象存储上：slatedb 能不能跑在 RustFS 上？RocksDB 这类嵌入式 KV 天生绑定一块本地 SSD，副本和跨区复制都得自己补。slatedb 反过来，把 WAL（写前日志）和 SST（排序字符串表）全部写进 S3 兼容对象存储，本地盘只做缓存。它能不能直接架在 RustFS 上？配置层面能：slatedb 用的是 object_store 那套抽象，官方口径支持任何实现 ObjectStore trait 的存储。但官方 Compatibility 页的测试目标里没有 RustFS，双方集成清单也没互相收录，这个组合没有任何一方背书，该自己测的

分布式存储与RustFS

机器要下线，数据先线上搬家：RustFS 存储池退役实操分布式存储跑几年，总有一批机器要退役：过保的节点、容量更小的旧盘、要合并的机房。难点不在“关掉它”，在于关掉之前那一池数据得有人搬到别处去。RustFS 的存储池退役（pool decommission）就是干这件专门活的：把选定池里的对象迁到剩余活跃池，腾空之后再把它从集群拓扑里摘掉，全程不用你手写迁移脚本。注意退役以池为单位：想换一块小盘、退一台机器，只能把包含它的池整体退役，不能只摘单块盘。它和“删数据”完全不同：退役是先搬后删，保证搬完才下线，不会出现数据半路消失；搬迁阶段在线做，收尾摘池之后需要

分布式存储与RustFS

RustFS 该跟 stable 还是 nightly？两条版本线的分工、风险与回退，一张表说清9 月 16 日装的 1.0.0，10 月 3 日 release 页冒出 1.0.1，同页每个平台还多挂了一个 -latest.zip；另一条线上，每天北京时间 0 点 07 分 CI 会打出一个按日期命名的 nightly 包。跟版本号、跟 latest 别名、跟 nightly，三种跟法对应三种维护姿势。这篇把两条公开版本线各自的分工、升级风险和回退方式讲清，所有时间、文件名与链接都来自 release 页和 CI 配置的实测，结尾给一张决策表。

分布式存储与RustFS

训练集放在 RustFS 上，怎么像本地盘一样快？用 Curvine 加一层 POSIX 缓存把 AI 训练集、模型权重往 RustFS 这类对象存储里一丢，爽的是容量近乎无限、多副本持久化、S3 接口谁都能读。别扭的也是接口：训练框架要的是 POSIX 文件语义，也就是能 open/read/seek、能重命名、能列目录，还要 GPU 跑着跑着就近读到热数据，而不是每次都走网络把对象整块拖回来。对象存储原生没有 POSIX，热读反复拉取也慢，随机 seek 和按 offset 读一块这种操作更是它的弱项，这层 gap 得有人补。典型的训练循环里，每个 epoch 都会把整个数据集从头读一遍；如果

分布式存储与RustFS

指标、日志、链路进同一个桶：GreptimeDB 存算分离解读与 RustFS 接入配置传统可观测性栈是三套系统起手：Prometheus 收指标，Loki 或 Elasticsearch 收日志，Jaeger 或 Tempo 收链路。三套系统三份运维，存储各管各的，想关联着查还要在应用层拼。GreptimeDB 的思路是把指标、日志、链路当成同一类数据：都是带时间戳的表，一个用 Rust 写的列式引擎统一吃下，SQL 查指标之外的一切，PromQL 查指标，长期数据放对象存储上。项目在 GitHub 上是 GreptimeTeam/greptimedb，Apache 2.0 协议，2026

分布式存储与RustFS

RustFS 上生产第一步：从单机到 4 节点多盘集群（MNMD）部署实操单机装 RustFS 是十分钟的事：官方安装脚本一条命令跑完，数据落在 /data/rustfs0 一块盘上。但这条命令装出来的形态叫 SNSD（单节点单磁盘），文档里写明没有冗余，盘坏了数据只能靠备份捞。真正上生产，官方给的是另一套起步形态：MNMD（多节点多磁盘），至少 4 台服务器、每台至少 1 块盘，数据跨服务器跨盘打散。这篇按官方 Linux 部署文档把从单机到 4 节点集群的路径走一遍：三种形态怎么分、集群配置怎么写、12+4 的纠删码布局能丢什么、装完怎么验证。所有命令和配置项都对着官方文档

分布式存储与RustFS

rclone 与 mc mirror：S3 对象存储同步，限速、过滤、断点续传实测对比把一批文件在两个 S3 兼容存储之间搬或者同步，rclone 和 mc 是最常见的两个命令行工具。网上对比文章不少，但多数是抄帮助文档，没真跑过。这篇把两个工具接在同一个 RustFS 上，限速、过滤、增量、断点四组场景逐个实测，数字都是本机跑出来的，复现命令在文末，你可以照着重跑对拍。

Git 基础设施重建：智能体规模开发下的读写解耦原文：GitHub Blog - 《Building Git infrastructure for agent-scale development》（https://github.blog/engineering/architecture-optimization/building-git-infrastructure-for-agent-scale-development/）

啦啦啦啦啦zzzz

一致性哈希本篇文章基于分布式存储的背景，一致性哈希是分布式存储里面的一种技术，用于多个结点之间分布数据，以最大程度减少添加或删除结点时候的数据重组

分布式存储与RustFS

升级 RustFS 二进制不停机：一条一条换，留一条退路一个四节点集群跑了半年没重启过，版本落后两个小版本。升级这件事真正的难点是出了事怎么退回去，把新二进制放上去那一步反而不难。RustFS 官方的二进制升级页给的流程很短，但里面那两条备份命令才是整个流程的核心：备份配置，以及把当前正在跑的那个可执行文件另存一份。少了第二条的升级，等于把回滚路径删掉了。

分布式存储与RustFS

日志目录的预算是 2 GiB：轮转、保留和压缩这三件事一台机器跑到半夜，磁盘告警，第一反应是查谁在写大文件，翻下去发现是 rustfs.log 一个文件占了十几 G。这种事在没配日志目录的部署上很常见。RustFS 的日志行为由可观测性那一组环境变量管。轮转时间、保留份数、总大小预算这三个默认值单独看都合理，合在一起却会互相影响，这也是日志目录最容易悄悄涨满的原因。只是真涨满的时候，往往不是这三条规则漏了。

分布式存储与RustFS

图床搬到自己的对象存储：PicGo 加 S3 插件的完整配置图床是很多人第一次真正用上对象存储的场景：写博客要贴图，截图一多，本地路径、第三方图床的失效链接、配额限制轮番找上门。把图床后端换成自己的 S3 兼容存储，一次配好之后上传是 Ctrl+V 的事，链接在自己手里，不担心哪天服务关停。

分布式存储与RustFS

在 Kubernetes 里跑对象存储的三个方案：Helm、Operator、以及什么时候别用 K8s把对象存储搬进 K8s 的动机通常是"顺便"，反正集群已经在跑，再加一套存储也不差一个 StatefulSet。但存储和 Web 应用在 K8s 里的相处方式完全不同：Web 应用挂了重启没事，存储的 StatefulSet 挂了要考虑 PVC 会不会丢、分布式集群能不能凑够法定人数、重启循环会不会把可用性拖穿。这三件事想不清楚就上，后面每一步都在还债。

分布式存储与RustFS

模型 checkpoint 放对象存储：分片上传、断点续传与残留清理训练跑了一整晚，到第 11 小时进程挂了。此时能救你的只有最近一次成功的 checkpoint。如果 checkpoint 是直接写在本地盘上，机器一挂就跟着没了；放在对象存储上才有跨机恢复的可能。但把 checkpoint 写对象存储这件事本身有讲究：大文件怎么传、断了怎么续、没传完的碎片怎么清，任何一个没处理好都会在真正出事的那个晚上掉链子。

分布式存储与RustFS

用RustFS给Harbor当S3存储后端不少团队的 Kubernetes 边上跑着 Harbor 存镜像，另有一套对象存储存 AI 训练数据，两套存储栈各管各的：Harbor 用本地盘或 NFS 挂 /data，对象存储单独养。结果一边磁盘报警，一边对象存储利用率才三成。其实 Harbor 的 registry 存储原生支持 S3 兼容驱动，只要把后端指到现有对象存储，镜像 blob 就直接落进去，容量、冗余、备份都跟着对象存储走。

分布式存储与RustFS

DPU卸载纠删码与加密：解决AI对象存储的CPU瓶颈一个千卡训练集群跑到半夜，GPU 利用率掉了下来，排查下来是存储节点的 CPU 满了：它在给每一个对象算纠删码、做加密，盘和网络反而有空闲。计算等数据，数据卡在编码上，这是 AI 数据中心里很典型的错位。网卡走到 100G、200G 之后，线速折算过来是每秒十几 GB 的持续流量，纠删码编码、压缩、加密这些计算密集步骤全压在通用 CPU 上，CPU 会先于磁盘成为瓶颈，把这部分重活从 CPU 挪出去是数据面优化的主要方向，目前讨论最多的落点就是 DPU。

分布式存储与RustFS

自托管对象存储的三种 TLS 签发：自签、Let‘s Encrypt、内网 CA 的选择与轮换对象存储装完之后通常先跑 HTTP，等要接进生产才想起证书这件事。三种常见签发路径（自签、Let’s Encrypt、内网 CA）各适配不同场景，选错了不会立刻出问题，但会在轮换那一天集中爆出来。这篇文章把三条路各自怎么配、证书放哪、轮换时容易踩的坑一次说清，示例以 RustFS 为主，关键差异处对照 MinIO 官方文档。