s3

AWS SDK对接MinIO踩坑：AWS_REQUEST_CHECKSUM_CALCULATION场景：SpringBoot项目使用AWS Java SDK v2对接MinIO对象存储，升级SDK后遇到上传400问题，梳理相关概念、踩坑原因以及解决方案。

分布式存储与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 官方文档。

分布式存储与RustFS

把现有 S3 工具链直接接到 RustFS：100% 兼容到底覆盖哪些 API一套跑了三年的 S3 工具链，多半长这样：aws-cli 脚本每晚把数据库 dump 推到桶里，mc 负责日常的桶和生命周期管理，rclone 在两个机房之间同步构建产物，应用侧用 AWS SDK 直连。要换掉底层存储的时候，团队问的第一个问题几乎都一样：这些脚本要不要改。

分布式存储与RustFS

AI 训练大文件 Range 读爆炸？RustFS 前面挂一层 Cachey多机训练那头，最舒服的往往是写数据：几十个 worker 把权重和 checkpoint 写进去，落盘、返回 200，吞吐曲线漂亮得能当壁纸。真正卡住训练节奏的常常是读的这一头：同一个 4 GiB 的模型权重，八个 worker 各读各的段，回源次数不是按 worker 数算的，而是按「每个 worker 每碰一次冷页算一次」往上翻。单次延迟都不高，可尾延迟会被拉得不讲道理。

分布式存储与RustFS

GitLab 对接 RustFS 实战：OIDC 控制台 SSO + 制品存储落 S3 对象存储很多团队的代码、CI、制品全在 GitLab 里，身份早就收口到 GitLab 了。可对象存储控制台还得单独开账号：新人入职要记两套密码，离职漏删存储侧的本地账号就是个敞口。与其再养一套身份，不如让存储直接认 GitLab 发下来的身份：GitLab 负责"你是谁"，存储侧的策略负责"你能干什么"。

分布式存储与RustFS

纠删码到底吃掉了多少容量：EC:4、EC:8 的利用率与容错怎么算买了 8 块 16TB 的盘，128TB 裸容量，装出来的桶能用多少？大多数人拿 128 × 0.75 估一个大概就往下走了。但这个 0.75 从哪来、什么时候不成立、坏几块盘真的没事吗，才是决定数据会不会丢的那几件事。

分布式存储与RustFS

对象存储正在吞掉数据湖：RustFS 1.0 GA 与 MinIO AIStor Tables 把 2026 风向说清楚过去十年，搞数据的团队基本是两套系统在并行跑。对象存储（S3 及兼容方案）放图片、日志、模型权重、备份这些非结构化 blob；另一边再养一套独立的元数据和表引擎（Hive Metastore、Delta Lake、Iceberg catalog）去管结构化的表。两套系统意味着两份权限、两份治理、两份账单，还要写一堆把对象路径和表元数据对齐的胶水管道。

知行之桥 S3 端口或归档中配置阿里云 OSS 使用指南本指南将带你一步步完成配置，让知行之桥 S3 端口可以直接对接阿里云对象存储服务（OSS），用于文件的上传和管理。整个过程只需要在两个页面中填写几项信息即可完成，无需编写代码。

分布式存储与RustFS

RustFS 多协议接入全景：S3 之外，Swift/Keystone 与 SFTP/FTPS 怎么选一套对象存储前面如果只开 S3，大多数场景确实够用，但总有那么几个瞬间会卡住：运维想临时丢一个大文件进去、某台老系统只认 SFTP、或者你这套存储要并到既有的 OpenStack 体系里，那边全是 Swift 客户端。这时候常见的做法是再架一层网关，等于多养一个组件、多一处故障点。

分布式存储与RustFS

在 Kubernetes 上用 RustFS Operator 给 Tenant 开 KMS 加密：spec.encryption 实战一套跑在 Kubernetes 里的对象存储，只要开始接业务数据，迟早会碰到加密这个命题：等保、HIPAA、PCI 这类合规框架基本都要求"静态数据加密 + 密钥可审计"。我见过不少团队把数据落进对象存储后才发现，存的是用户上传的证件、病历或合同，没有服务端加密，合规那一关就过不去。

分布式存储与RustFS

RustFS 1.0 GA 前的生产验收清单：从 rc.1 到 GA 该准备什么一支存储团队决定把某类数据从公有云 S3 迁回自建，或者给 AI 训练管线找一块 S3 兼容的本地存储，往往会把 RustFS 放进候选。我最近帮两个团队做选型，他们问的不是"能不能跑"，而是"rc.1 能不能上生产、上线前我该验收什么"。这个问题问得对——候选发布版本和 GA 之间的差距，要靠一份清单去填，而不是靠热度去赌。

分布式存储与RustFS

RustFS 1.0.0-rc.5 发布：GA 前的最后一次大版本打磨一句话定位：RustFS 是面向 AI 时代、从零原生打造的高性能分布式对象存储，100% 兼容 S3 API，Apache 2.0 协议，底层用 Rust 构建，可作为 MinIO 的 drop-in 替代方案。

分布式存储与RustFS

把 RustFS 当 ClickHouse 的 S3 存储盘：冷热分层落对象存储一句话定位：RustFS 是面向 AI 时代、从零原生打造的高性能分布式对象存储，100% 兼容 S3 API，Apache 2.0 协议，可作为 MinIO 的 drop-in 替代方案。