对象存储

【minio】#5 | MinIO 分布式部署 + HTTPS 部署生产环境推荐：多磁盘、多主机分布式集群，支持数据分片、故障容错。集群节点：架构说明：2 台机器，每台挂载 2 块磁盘，总共 4 块盘组成分布式集群。支持后期动态扩容。

【minio】#1 | 简介与安装简介：MinIO 第一课复习笔记，包含对象存储概念、S3 协议介绍、MinIO 特性、许可证坑点、Docker 一键部署实战，适合后端开发学习。

【minio】#2 | Web 控制台操作重要：对象锁定只能在创建 Bucket 的时候开启，创建完成后无法修改适用行业：金融、医疗，强制保存日志、合同，防止数据篡改删除

梦想不只是梦与想

对象存储服务器vs数据库图片可以存进普通数据库，但代价极高，几乎没人这么做。原因不是“技术上做不到”，而是数据库的设计目标与图片的存储需求根本不匹配。

分布式存储与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

MinIO 官方 Docker 镜像被移除：依赖它的项目该怎么办9 月 11 日前后，不少人的 CI 在 docker pull minio/minio 这一步红了。

分布式存储与RustFS

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

制造工厂海量生产数据统一存储管理方案与实践在制造业的数字化转型浪潮中，许多工厂都经历过这样的现实困境：产线高速运转，高清摄像头每秒都在生成海量的图像与视频数据，但后端的存储系统却成了“拦路虎”。传统的文件服务器在数据量突破千万级时，响应速度急剧下降，工程师想要调取一个月前的某批次产品质检图，往往需要等待数分钟甚至更久。这种延迟不仅拖慢了生产节奏，更让基于大数据的质量追溯和 AI 模型训练变得举步维艰。当非结构化数据的规模膨胀到亿级甚至十亿级文件时，继续依赖旧有的 NAS（网络附属存储）架构，无论在性能、可靠性还是扩展性上，都难以满足现代智能制造的

分布式存储与RustFS

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