分布式存储入门 —— Ceph / HDFS / 对象存储

数据中心规模上去之后，单机 RAID 和 SAN 都扛不住——主流转向分布式存储。本文讲三类主流分布式存储（HDFS、Ceph、对象存储）的核心机制，以及它们和传统集中式存储的本质差别。

为什么需要分布式存储

传统 SAN：

1
2
3
4
2-4 个控制器 + 一个机柜的盘 = 一个孤岛
扩容靠加柜，性能瓶颈在控制器
单点故障域大
2-10 PB 是单台 SAN 上限

分布式存储：

1
2
3
N 台普通服务器 + 每台几十颗盘
N 越大容量越大、性能越高、容错越强
线性扩展到 EB 级
graph TB
  subgraph 传统SAN
    C1[控制器 1]
    C2[控制器 2]
    C1 --- D1[盘 × 100]
    C2 --- D1
  end
  subgraph 分布式
    N1[节点 1<br/>盘 × 24]
    N2[节点 2<br/>盘 × 24]
    N3[节点 3<br/>盘 × 24]
    NX[... × 数十/数百]
    N1 -.- N2 -.- N3 -.- NX
  end

分布式存储的三大核心问题

graph TB
  P1[数据放哪里?<br/>分片 / 哈希 / 一致性哈希]
  P2[一份还是多份?<br/>多副本 / 纠删码]
  P3[出错怎么办?<br/>心跳 / 选主 / 一致性]

每个分布式存储系统都在用自己的方式回答这三个问题。

数据放置：三种思路

1. 主从 + 元数据服务器（HDFS 风格）

1
2
NameNode 知道：每个文件块放在哪几个 DataNode 上
Client 先问 NameNode → 得到位置 → 直接和 DataNode 读写

优点：策略灵活
缺点：NameNode 是潜在瓶颈（HDFS 后期 federation / HA）

2. 算法决定位置（Ceph 风格）

1
2
对象 → 哈希到 PG（placement group）→ CRUSH 算法决定 PG 在哪些 OSD
没有"中心元数据"，每个客户端按算法自行计算

优点：无中心、无瓶颈
缺点：调整布局规则要全集群配合

3. 一致性哈希 / Ring（对象存储风格）

1
2
3
对象 key 哈希到环上
找环上下一个 N 个节点 = 副本位置
节点增减时只影响相邻

优点：扩展简单
缺点：故障域控制不如 CRUSH 精细

冗余：副本 vs 纠删码

多副本（Replication）

1
2
一份原始 + N-1 份副本
3 副本是默认，最常见
容量利用 1/N（3 副本 = 33%）
容错 任意 N-1 节点
写性能 N 份写入
重建成本 直接复制，最快

纠删码（Erasure Coding，EC）

源自 Reed-Solomon 编码，原理类似 RAID 6 的扩展：

1
2
3
4
5
EC(K+M)：
  K = 数据块数（典型 4 / 6 / 8 / 10）
  M = 校验块数（典型 2 / 3 / 4）
  K+M 块分散到不同节点
  任意 K 块就能恢复全部数据

例 EC(8+4)：

1
2
3
4
8 数据块 + 4 校验块 = 12 个块
任意 4 块丢失都能重建
容量利用 = 8/12 = 67%（比 3 副本的 33% 高一倍）
重建代价 = 读 8 块 + 计算
3 副本 EC(8+4)
容量利用 33% 67%
容错 2 4
写性能 写 3 份 写 12 份（小 IO 严重放大）
重建成本 复制 1 份 读 8 块 + 计算
适合 热数据 冷数据 / 大块

EC 把 33% 的容量利用率拉到 67-80%，对超大规模数据中心是真金白银。

代价：

  • 小写性能差（不能把单个 4K 写映射到 12 块）
  • 重建消耗带宽
  • 计算开销（CPU 或专用硬件）

行业普遍做法：热数据用 3 副本，冷数据用 EC——按温度分层。

HDFS：Hadoop 时代的”先驱”

graph TB
  subgraph CLIENT
    HC[HDFS Client]
  end
  subgraph META
    NN[NameNode<br/>元数据]
    SN[Secondary NN<br/>checkpoint]
  end
  subgraph DATA
    DN1[DataNode 1<br/>本地盘]
    DN2[DataNode 2]
    DN3[DataNode 3]
    DNX[...]
  end
  HC -- "1. 询问位置" --> NN
  HC -- "2. 直接读写" --> DN1
  HC --> DN2
  HC --> DN3
  DN1 -- "心跳 / 块报告" --> NN
  DN2 -.- NN
  DN3 -.- NN

特点：

  • 块大小 128 MB 起（适合大文件、批处理）
  • 追加写 + 一次写多次读（不支持随机写）
  • 3 副本为默认（机架感知）
  • 大数据生态原生（HDFS + Yarn + MapReduce/Spark）

适用：批量分析、Hive/Spark 数据湖、AI 训练大数据集。

不适用：小文件多、随机写、低延迟。

待补充：HDFS 在你公司的实际使用情况，以及是否已迁移到对象存储。

Ceph：通用分布式存储的”瑞士军刀”

graph TB
  subgraph CEPH["Ceph 集群"]
    MON[Monitor × 3-7<br/>集群状态]
    MGR[Manager<br/>监控/可视]
    MDS[MDS<br/>仅 CephFS 用]
    
    OSD1[OSD 1<br/>1 盘 1 OSD]
    OSD2[OSD 2]
    OSDx[... × N]
  end
  C1[RBD<br/>块] -. RADOS .-> CEPH
  C2[CephFS<br/>文件] -. RADOS .-> CEPH
  C3[RGW<br/>S3 / Swift] -. RADOS .-> CEPH

Ceph 用一套底层（RADOS）支持三种接口：

接口 用法 应用
RBD 块设备 虚拟化、容器持久卷
CephFS POSIX 文件系统 文件共享
RGW S3 / Swift 对象 对象存储

CRUSH 算法是 Ceph 的精髓——没有中心元数据，客户端按规则自己算位置：

1
2
3
对象 → hash → PG（placement group）
PG → CRUSH 规则 → OSD 列表
客户端拿到列表后直接读写

CRUSH 规则可以表达”分布到不同机架 / 不同机房 / 不同电源域”——故障域设计非常灵活。

Ceph 的痛点：

  • 学习曲线陡（架构复杂、参数多）
  • 写延迟相对高（RBD 数百微秒级）
  • 大集群运维需要专门团队

但作为开源、统一、灵活的方案，Ceph 在私有云、超算、混合云非常普遍。

对象存储：S3 引爆的标准

S3（Amazon Simple Storage Service）2006 年推出，对象存储成了云时代的”事实标准”。

1
2
3
4
对象 = key + value + metadata
key 是字符串路径（"folder/sub/object.bin"）
value 是字节流（任意大小）
metadata 是键值对

特点：

  • HTTP/HTTPS 协议 —— 跨网络访问
  • 扁平命名空间（没有真正的”目录”，只是 key 前缀）
  • 不可修改（要改就重新上传整对象）
  • 强 / 最终一致性 —— S3 现在是强一致
  • EB 级容量 —— 每桶可装无限多对象

API 几个核心动词：

1
2
3
4
PUT /bucket/object        上传
GET /bucket/object        下载
DELETE /bucket/object     删除
LIST /bucket?prefix=...   列举

兼容 S3 API 的实现：

1
2
3
4
公有云：AWS S3, 阿里 OSS, 腾讯 COS, Azure Blob (S3 兼容)
开源：Ceph RGW, MinIO, SeaweedFS
专用：Backblaze B2, Wasabi, Cloudflare R2
国内商业：浪潮、华为 OBS、深信服等

应用场景：

  • 数据湖底座（Iceberg、Hudi、Delta Lake 都跑在 S3 上）
  • AI 训练数据集
  • 备份和归档
  • CDN 源站
  • 容器镜像仓库后端

对象存储是当前数据中心存储的事实底座。

三类对比

HDFS Ceph S3 对象
接口 HDFS API / WebHDFS RBD / CephFS / S3 S3 / Swift
文件特性 大文件、追加写 块/文件/对象 不可改对象
元数据 中心 NameNode 算法（CRUSH） 哈希环 / 平面
默认冗余 3 副本 3 副本 / EC EC（云上）/ 副本（私有）
强一致 写时一致 强一致 S3 强一致 / 自建按选
典型容量 PB PB EB
主战场 大数据分析 私有云 云原生数据

CAP 与一致性取舍

分布式存储不能同时满足：

graph TB
  C[Consistency 一致性]
  A[Availability 可用性]
  P[Partition tolerance 分区容错]
  Note["在网络分区时，<br/>只能保证 C 或 A 之一"]
  C --- Note
  A --- Note
  P --- Note

实际取舍：

系统 取向 说明
HDFS CP 强一致，写期间不可写其他副本
Ceph CP 强一致
早期 S3 AP 最终一致
现 S3（2020+） CP 已切换到强一致
Cassandra/Dynamo AP（可调） 最终一致或 quorum 强一致
etcd / ZooKeeper CP 选主 + 共识

数据持久性 (Durability)

云对象存储常宣传 “11 个 9 的持久性”：

1
2
99.999999999% (11 个 9)
≈ 1000 万对象一年期望损失 < 1 个

实现方式：

  1. 多副本 / EC：通常 3 数据中心 × EC(10+4) 跨可用区
  2. 持续 scrubbing：后台扫描发现并修复 silent corruption
  3. 版本控制 + WORM：防止误删

性能数字直觉

1
2
3
4
5
6
本地 NVMe SSD 4K 随机读：~10 μs
本地 SAN（FC32G）：~100-200 μs
NVMe-oF / RDMA：~100-150 μs
Ceph RBD 4K 读：~300-500 μs
HDFS 大块读：~MB 级聚合
S3 GET 单对象：~30-100 ms（HTTP 层延迟）

待补充：你公司分布式存储的实测延迟数字。

一些工具命令

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# Ceph 集群
sudo ceph -s
sudo ceph osd tree
sudo ceph df

# RBD 创建块设备
sudo rbd create mypool/myimage --size 100G
sudo rbd map mypool/myimage
mkfs.ext4 /dev/rbd0
mount /dev/rbd0 /mnt

# HDFS
hdfs dfs -ls /
hdfs dfs -put localfile /hdfs/path
hdfs dfsadmin -report

# S3 (aws cli / s3cmd / mc)
aws s3 ls s3://my-bucket/
aws s3 cp file.bin s3://my-bucket/path/

# MinIO 部署单机
docker run -p 9000:9000 -p 9001:9001 \
    -v /data:/data minio/minio server /data --console-address ":9001"

AI 大模型训练的 Checkpoint 存储模式

分布式存储在 AI 训练场景里有一套独特的使用模式，和传统大数据分析（HDFS + Spark）或虚拟化存储（Ceph RBD）有本质区别。

AI 集群存储的三层架构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
AI 训练集群存储层次（典型方案）：

  Layer 0：节点本地 NVMe SSD（每台训练机 4-8 块 PCIe 5.0 NVMe）
    用途：最近 2-3 个 checkpoint 暂存、训练数据本地缓存
    容量：16-64 TB/节点
    带宽：40-100 GB/s/节点（PCIe 5.0 x8 盘）

  Layer 1：集群高性能并行文件系统（Lustre / GPFS / BeeGFS）
    用途：checkpoint 持久化、梯度聚合中间结果
    容量：数 PB
    带宽：数 TB/s 聚合（取决于 OSS 数量）

  Layer 2：对象存储（S3 / OSS / Ceph RGW）
    用途：训练数据集、长期 checkpoint 归档、模型权重发布
    容量：数十至数百 PB
    带宽：10-100 GB/s（HTTP 层）

Checkpoint 的写入模式：同步 vs 异步

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
同步 checkpoint（传统方式）：
  1. 停止训练（GPU idle）
  2. 从 GPU HBM 复制到 CPU DRAM
  3. 从 CPU DRAM 写入并行文件系统
  4. 写入完成后恢复训练

  问题：大模型权重 + 优化器状态 ~1 TB → 写入时间分钟级 → GPU 空转

异步 checkpoint（现代方式）：
  1. GPU HBM → CPU DRAM（快，几秒）
  2. 恢复训练（GPU 继续跑）
  3. CPU DRAM → 文件系统（后台写，和训练并行）

  前提：CPU DRAM 足够大（能放下整个 checkpoint）
  现实：每节点 1-2 TB DDR5（Grace Vera CPU 可达 1.5 TB LPDDR5X）

这就是 2026 年 CPU 内存容量暴增（从 512 GB 向 1-2 TB 迈进）的重要驱动力之一——异步 checkpoint 需要 CPU DRAM 作为缓冲层。

NCCL Checkpoint 与分布式一致性

大规模训练中 checkpoint 不是”单机写文件”那么简单——数千 GPU 需要同步保存状态，任何一个节点落后都会导致恢复时的不一致：

1
2
3
4
5
6
7
8
9
10
11
12
13
NCCL Checkpoint 流程（ZeRO Stage 3 为例）：

  Step 1：AllReduce barrier（所有 rank 到达同一步数）
  Step 2：每个 rank 把自己分片的参数写入本地存储
    → distributed checkpoint：rank 0 写 shard_0，rank 1 写 shard_1 ...
    → 总写入量 = 完整模型大小（但分摊到所有节点）
  Step 3：写入完成后再次 barrier（确认全部落盘）
  Step 4：更新 checkpoint 索引文件（原子操作）

  恢复流程：
  Step 1：读取索引文件，确认 checkpoint 完整性
  Step 2：每个 rank 并行读取自己的 shard
  Step 3：AllGather 验证（可选）

分布式 checkpoint 的好处：

  • 写入时间从 O(总模型大小 / 单节点带宽) → O(总模型大小 / 集群总带宽)
  • 4096 GPU 集群并行写 1 TB checkpoint，每节点只写 ~250 MB → 秒级完成

AI 集群中 Lustre 的实际部署

Lustre 是目前 AI 训练集群最常用的高性能并行文件系统（HPC 领域用了 20 年）：

1
2
3
4
5
6
7
8
9
10
11
Lustre 架构：
  MGS（Management Server）：集群配置，1 台即可
  MDS（Metadata Server）：文件名/目录树，1-N 台
  OSS（Object Storage Server）：数据存储，数十至数百台
  OST（Object Storage Target）：每个 OSS 挂载的存储设备

典型 AI 集群 Lustre 规模：
  OSS 数量：16-64 台
  每台 OSS：8-24 块 NVMe SSD（PCIe 5.0）
  聚合带宽：1-10 TB/s（实测）
  典型延迟：100-500 us（比本地 NVMe 高 10x）

Lustre 在 AI 训练中的使用模式：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
训练数据读取：
  数据集存 Lustre → 每个训练节点并发读
  Lustre 聚合带宽需 > GPU 数量 × 每 GPU 数据消耗速率
  如：4096 A100 × 10 GB/s/GPU = 40 TB/s（Lustre 难以满足）
  实践：数据预处理 + 本地 NVMe 缓存（Data Staging）

Checkpoint 写入：
  Lustre 是这里的主力
  聚合写带宽 1 TB/s → 1 TB checkpoint 约 1 秒（异步模式）
  Lustre 的 striping（条带化）让大文件分散到所有 OST

模型权重加载（训练启动）：
  一次性读取，Lustre 够用
  但 4096 GPU 同时读同一文件 → 需要合理 stripe 和缓存策略

国内 AI 大厂的存储实践

1
2
3
4
5
6
7
8
9
10
11
12
13
14
字节跳动（ByteDance）：
  自研 ByteNAS / ByteFS，基于 HDFS 改造 + NVMe 缓存层
  训练数据走对象存储（ByteCS），checkpoint 走专用高性能层

阿里云：
  训练集群用 CPFS（Cloud Parallel File Storage，Lustre 兼容）
  数据集存 OSS，通过 CPFS 加速访问层提供缓存

腾讯：
  Tencent CHDFS（POSIX 兼容对象存储）+ GooseFS 缓存加速

华为 Atlas 集群：
  Euleros + OceanStor 并行文件系统
  国产化全栈，与昇腾 NPU 深度集成

国内分布式存储格局

类别 代表
互联网自研 字节 ByteCS、阿里盘古、腾讯 YottaStore、京东 JFS
公有云对象存储 阿里 OSS、腾讯 COS、华为 OBS、火山引擎 TOS
开源 + 商业支持 XSky、SmartX、深信服、青云、易捷行云
传统厂商 华为 FusionStorage、浪潮 AS13000

待补充：你公司在用的分布式存储方案。

小结

  • 分布式存储的三大问题：放置 / 冗余 / 容错
  • 多副本简单粗暴，纠删码（EC）省容量但写有放大
  • HDFS 适合大文件批处理，Ceph 是统一池子，S3 对象是云原生底座
  • CAP 不可同时满足，强一致 vs 最终一致是常见取舍
  • 11 个 9 的持久性靠跨域多副本 + 持续 scrubbing
  • 数据中心存储正在向”本地 NVMe + 分布式 EB 池”两极分化

下一篇是第四章最后一篇——存储选型实战与小结。

内容深度由贤狼赫萝于 2026-06-15 增补，引用来源：SemiAnalysis CPUs are Back 2026、TrendForce DRAM笔记、Broadcom技术访谈。