rbd的操作

好的，我将为您总结一个详细的 Ceph RBD 存储管理教程，涵盖了从创建到删除的完整生命周期，并附带所有必要的命令，重点讲解文件删除和快照删除的底层机制。

---

📘 Ceph RBD 存储管理详细教程

本教程假设您的 Ceph 集群已部署并正常运行，且客户端已配置好 Ceph 配置文件和密钥环。

阶段一：RBD 存储池和镜像的创建与配置

步骤	描述	命令示例 (在 Ceph 集群管理节点执行)	备注
1. 存储池创建	创建一个新的存储池用于 RBD 数据。	ceph osd pool create rbd_data 64 64	64 64 是 PG 数量，应根据集群大小调整。
2. 初始化 RBD	在新创建的 Pool 上启用 RBD 功能。	rbd pool init rbd_data	必须执行，否则该 Pool 无法存放 RBD 镜像。
3. 镜像创建	创建一个 100GB 的 RBD 镜像。	rbd create rbd_data/web_disk --size 100G	命名规范：<pool_name>/<image_name>
4. 镜像查看	查看已创建的镜像列表。	rbd ls rbd_data
5. 镜像信息	查看特定镜像的详细信息。	rbd info rbd_data/web_disk

阶段二：客户端使用 RBD 镜像

步骤	描述	命令示例 (在客户端节点执行)	备注
1. 映射 (Map)	将 RBD 镜像映射到客户端作为块设备。	sudo rbd map rbd_data/web_disk	通常会映射为 /dev/rbd0 等。
2. 格式化	对新映射的块设备创建文件系统。	sudo mkfs.ext4 -F /dev/rbd0	生产环境推荐 XFS 或 Btrfs。
3. 挂载	创建挂载点并挂载文件系统。	sudo mkdir /mnt/data sudo mount /dev/rbd0 /mnt/data
4. 使用	验证读写权限。	sudo touch /mnt/data/test.file

---

🔄 文件删除与空间回收机制

文件删除（如 rm 命令）是客户端文件系统层面的操作，它与底层 Ceph OSD 的空间释放是解耦 的，需要 TRIM/UNMAP 命令才能桥接。

核心机制：TRIM/UNMAP

• 客户端操作： 客户端文件系统只标记数据块为可用 ，并不通知 Ceph 释放空间。
• 空间释放： 只有当客户端向 RBD 驱动发送 TRIM/UNMAP 命令后，Ceph OSDs 才会删除底层的 RADOS 对象，从而释放物理空间。

场景	描述	客户端操作命令	结果
即时释放	挂载时使用 discard 选项。 文件一删除，UNMAP 命令就立即发送。	sudo mount -o discard /dev/rbd0 /mnt/data	缺点： 频繁发送 UNMAP 可能增加 I/O 延迟。
延迟释放	默认推荐设置。 文件删除不立即释放空间。	sudo mount /dev/rbd0 /mnt/data (不带 discard)	优点： 避免频繁的性能开销。
手动回收	批量执行 fstrim 命令，手动回收所有未使用的空间。	sudo fstrim -v /mnt/data	最佳实践： 定期在低负载时段运行此命令。

---

📸 快照的创建、删除与异步回收

快照是 RBD 的核心功能，用于数据保护和克隆。它的删除机制是系统强制的异步回收。

核心机制：Snaptrim

• 快照创建： 使用写时复制 (CoW) 机制，创建快照后，旧数据块会被保留。
• 快照删除： 删除快照时，Ceph 不会立即删除它引用的所有数据块。
• 异步修剪 (Snaptrim)： Ceph 在后台 运行 snaptrim 任务，缓慢地、异步地找出并删除那些不再被任何其他快照或活动镜像引用的数据块，从而避免阻塞前台 I/O。

步骤	描述	命令示例 (在 Ceph 集群管理节点执行)
1. 创建快照	为镜像创建一个名为 20251211 的快照。	rbd snap create rbd_data/web_disk@20251211
2. 查看快照	查看特定镜像的所有快照。	rbd snap ls rbd_data/web_disk
3. 快照回滚	将活动镜像的数据回滚到快照状态。	rbd snap rollback rbd_data/web_disk@20251211
4. 删除快照	删除快照，触发 Snaptrim 异步回收。	rbd snap rm rbd_data/web_disk@20251211
5. 检查回收进度	检查 OSDs 的快照修剪任务。	ceph status

---

阶段三：结束使用和镜像删除

步骤	描述	命令示例	备注
1. 卸载 (Unmount)	在客户端卸载文件系统。	sudo umount /mnt/data
2. 取消映射 (Unmap)	在客户端移除块设备。	sudo rbd unmap /dev/rbd0	必须先卸载再取消映射。
3. 彻底删除镜像	在 Ceph 集群管理节点删除 RBD 镜像。	rbd rm rbd_data/web_disk	如果镜像有快照，需要先删除所有快照。
4. 彻底删除存储池	删除整个存储池（不推荐，除非确认所有数据已迁移）。	ceph osd pool delete rbd_data rbd_data --yes-i-really-really-mean-it	极度危险，请谨慎操作！

---

您是否想尝试运行一些命令，或者对快照克隆 (Cloning) 的高级用法感兴趣呢？

下面给你整理一份 超详细、结构清晰、带命令示例 的 Ceph RBD 存储教程，包括：

✔ RBD 镜像创建、查看、扩容、缩容、删除

✔ RBD 映射（挂载到客户端）与取消映射

✔ 文件删除机制说明（RBD 内部文件≠RBD 对象删除）

✔ 快照创建、回滚、保护/取消保护、克隆、删除

✔ 镜像迁移、镜像复制（简单提一下）

内容偏 完整教程 + 实战命令，适合你目前正在重新部署 Ceph 的情境。

---

🎯 一、RBD 基础概念（让你彻底明白在做什么）

概念	说明
RBD（RADOS Block Device）	使用 Ceph 提供的分布式块存储，像磁盘一样使用，可格式化、挂载、存文件
pool	RBD 镜像所在的存储池，如 rbd、mypool
image（镜像）	RBD 创建出的虚拟磁盘，例如 rbd create foo --size 1G
snapshot（快照）	镜像的只读瞬时副本
clone（克隆）	从快照创建的新镜像
flatten（扁平化）	解除 clone 对快照的依赖

---

🧱 二、RBD 常用命令总览（速查表）

功能	命令示例
创建镜像	rbd create pool/img --size 10G
查看镜像	rbd ls pool
删除镜像	rbd rm pool/img
扩容	rbd resize pool/img --size 20G
缩容	❌ 不支持直接缩容
创建快照	rbd snap create pool/img@snap1
删除快照	rbd snap rm pool/img@snap1
回滚快照	rbd snap rollback pool/img@snap1
映射镜像	rbd map pool/img
取消映射	rbd unmap /dev/rbdX

---

🧿 三、RBD 镜像管理

✅ 1. 创建 RBD 镜像

rbd create pool_name/image_name --size 10G

示例：

rbd create rbd/data01 --size 20G

---

✅ 2. 查看镜像

列出池内镜像：

rbd ls rbd

查看镜像详细信息：

rbd info rbd/data01

---

✅ 3. 扩容（支持在线扩容）

rbd resize rbd/data01 --size 30G

---

❌ 4. 缩容（不支持）

RBD 不支持直接缩小磁盘。如果必须缩小：

1. 创建新镜像
2. rsync 或 dd 拷贝数据
3. 删除旧镜像

---

✅ 5. 删除镜像

rbd rm rbd/data01

前提：

• 镜像无快照
• 镜像未被 map
• 无克隆引用

若提示快照依赖，先取消保护并删除快照。

---

🧿 四、RBD 镜像挂载（客户端使用）

✅ 1. 映射（map）到本地作为块设备

rbd map rbd/data01

输出类似：

/dev/rbd0

---

✅ 2. 对镜像做文件系统格式化

mkfs.ext4 /dev/rbd0

---

✅ 3. 挂载

mount /dev/rbd0 /mnt/cephdisk

---

❌ 4. 取消挂载 + 取消映射

umount /mnt/cephdisk
rbd unmap /dev/rbd0

---

🔥 五、文件删除机制说明（你必须理解）

❗ 当你删除镜像里的文件，例如：

rm -rf /mnt/cephdisk/bigfile.bin

RBD 并不会立即释放空间！

原因：

• RBD 底层是 object 存储
• 文件系统删除文件 → 仅删除 inode 和元数据
• 真正的空间回收需 fstrim（discard）

✔ 使用 fstrim 释放空间：

fstrim /mnt/cephdisk

如果启用 discard：

mount -o discard /dev/rbd0 /mnt/cephdisk

即可实时释放空间。

---

🧿 六、RBD 快照管理（非常重要）

✅ 1. 创建快照

rbd snap create rbd/data01@snap1

---

✅ 2. 查看快照

rbd snap ls rbd/data01

---

🚫 3. 删除快照（必须先取消保护）

（1）若未保护：

rbd snap rm rbd/data01@snap1

（2）若已保护：

rbd snap unprotect rbd/data01@snap1
rbd snap rm rbd/data01@snap1

---

🔄 4. 快照回滚（镜像恢复到旧状态）

rbd snap rollback rbd/data01@snap1

注意：

• 回滚会覆盖当前所有数据
• 慎用！

---

🧿 七、从快照克隆镜像

如果你需要做模板镜像：

1. 保护快照

rbd snap protect rbd/data01@snap1

2. 创建克隆

rbd clone rbd/data01@snap1 rbd/clone01

3. 扁平化（让 clone 脱离父镜像）

rbd flatten rbd/clone01

否则 clone 删除不了父镜像。

---

🧿 八、RBD 镜像复制（简单提一下）

rbd mirror pool enable rbd pool
rbd mirror image enable rbd/data01

---

🧿 九、RBD 常见错误排查

错误	原因	解决
image has snapshots	镜像有快照	取消保护 → 删除快照
image is mapped	正在使用	先 unmap
has child	被 clone 依赖	flatten 克隆或删除克隆
删除文件但池占用不下降	未 trim	fstrim 或开启 discard

---

🧿 十、删除整个 pool（慎用！）

ceph osd pool delete rbd rbd --yes-i-really-really-mean-it

---

🎉 如果你需要，我还可以给你：

📌 图示梳理：RBD 结构、依赖关系图

📌 常见作业脚本：自动创建/删除 RBD 镜像脚本

📌 如何完全删除并重建 Ceph 集群（含 cephadm）

---

如果你想把这些写成 博客 or PDF 教程，我可以帮你进一步排版！

那我直接用图 + 文字把 RBD 的数据流给你掰开了讲一遍，尽量贴近 Ceph 底层实现。你可以把下面的 mermaid 图直接丢到支持 mermaid 的地方（比如 Typora、一些博客平台）预览。

---

一、RBD I/O 总体数据流图（从应用到 OSD）

先看一个「从应用写数据到 OSD」的完整链路图：

flowchart LR subgraph ClientNode[客户端节点] A[应用/文件系统\n(ext4/xfs)] B[/RBD 块设备\n/dev/rbdX/] C[librbd] A <-- 读写块数据 --> B B <-- ioctl/内核调用 --> C end subgraph CephCluster[Ceph 集群] C --> D[librados\n(用户态客户端库)] D -->|获取 Monitor Map / OSD Map / PG Map| MON[MON 集群\nMonitor] D -->|获取集群状态/告警/统计| MGR[MGR 守护进程\nManager] D -->|根据 CRUSH 规则\n计算对象落在哪些 PG/OSD| CR[CRUSH 算法] CR -->|得到: PG X -> OSD.1(Primary), OSD.2, OSD.3| P[Primary OSD] subgraph OSDs[OSD 节点（数据实际存放处）] P --> R1[Replica OSD 1] P --> R2[Replica OSD 2] subgraph PrimaryOSD[Primary OSD 内部] P --> Q[接收 RADOS 对象写请求\n(obj_000001, offset, length)] Q --> W[WAL/DB(RocksDB)\n元数据、KV 索引] W --> BS[BlueStore 数据区\n(物理块设备/分区)] end end end %% 读流程（虚线） A -. 读请求 .-> B -.-> C -.-> D -.-> CR -.-> P -.-> BS -.-> A

🔍 图中每一层是什么意思？

1️⃣ 客户端侧（ClientNode）

• 应用/文件系统（A）

  • 对 /dev/rbdX 做普通的读写、rm、cp 等操作。
  • 对它来说，RBD 就是一块"本地磁盘"。

• RBD 块设备（B：/dev/rbdX）

  • 这是内核 RBD 模块暴露出来的块设备节点。

  • 文件系统挂载在这里：

    mkfs.ext4 /dev/rbd0
    mount /dev/rbd0 /mnt/cephdisk

• librbd（C）

  • 负责把"块读写"切分成对 RBD 对象（object）的操作：

    • 比如 image 逻辑 offset 0~4MB → 落到 rbd_data.00000000
    • offset 4~8MB → rbd_data.00000001

  • 还会处理：

    • 条带（striping）
    • 快照逻辑
    • 克隆依赖关系
    • cache 等

---

2️⃣ librados 与 Ceph 集群元数据（D、MON、MGR）

• librados（D）：

  • 一切对对象的读写都要先经过 librados。

  • 它知道：

    • 当前有哪些 Pool
    • 每个 Pool 里有哪些 PG
    • 每个 PG 的 Primary/Replica 分布在哪些 OSD 上

• MON（Monitor 集群）

  • 存放：

    • 集群配置
    • OSD Map、MON Map、PG Map 等

  • librados 会先从 MON 获取这些 Map，之后在一段时间内直接使用本地缓存的 map。

• MGR（Manager）

  • 提供：

    • 统计信息、性能监控
    • Dashboard
    • 一些模块化功能（Prometheus、balancer 等）

  • 对 I/O 数据流不是绝对必经，但参与整体管理。

---

3️⃣ CRUSH 算法选路（CR）

• CRUSH 干的事情就是：

  给我一个 Pool 和一个对象 ID，我要算出它应该落在哪个 PG，再落到哪些 OSD 上。

• RBD 的一个对象名类似：

  • rbd_data.10f8a9b0.0000000000000001

• librados 会把：

  • (pool, object_name) → 映射为：

    • PG：比如 1.5a（Pool ID 1, PG ID 0x5a）
    • OSD 列表：[osd.1 (primary), osd.3, osd.7]

---

4️⃣ OSD 内部数据流（Primary OSD + Replica）

可以再用一个单独图把 单个 OSD 内部画一下：

flowchart LR C1[来自客户端的对象写请求\n(obj_name, offset, data)] --> H[Primary OSD 进程] H --> L1[检查 PG 状态\n是否 active+clean] L1 --> J1[写入 WAL/DB(RocksDB)\n记录元数据/事务] J1 --> B1[写入 BlueStore 数据区\n(后端可能是裸盘/LVM/分区)] H --> Rep1[并行转发写请求到\nReplica OSD 1] H --> Rep2[并行转发写请求到\nReplica OSD 2] Rep1 --> J2[Replica OSD 1 写 WAL/DB + BlueStore] Rep2 --> J3[Replica OSD 2 写 WAL/DB + BlueStore] J2 --> Ack1[Replica 1 ACK 给 Primary] J3 --> Ack2[Replica 2 ACK 给 Primary] Ack1 --> Final[Primary 收齐 ACK 后\n向客户端(librados)应答] Ack2 --> Final

流程说明：

1. 客户端（librados）把对象写请求发给 Primary OSD；

2. Primary OSD：

   • 检查 PG 是否处于 active+clean；
   • 把本次写入操作记录在 WAL/DB（RocksDB）中；
   • 把实际数据写入 BlueStore 的数据盘；

3. Primary 同时把写请求转发给所有 Replica OSD；

4. 每个 Replica OSD 同样写 WAL/DB + BlueStore 后，给 Primary 返回 ACK；

5. Primary 收到所有 Replica 的 ACK 后，才向客户端返回"写成功"。

---

二、RBD 镜像到对象的映射图（条带/对象粒度）

再画一个「RBD 镜像 → 对象 → PG → OSD」的结构图，便于你在脑中立体化这个关系：

flowchart LR subgraph RBDImage[RBD 镜像: rbd/data01 (10 GiB)] I1[逻辑偏移 0~4MB] I2[逻辑偏移 4~8MB] I3[逻辑偏移 8~12MB] I4[...] end I1 --> O1[rbd_data.00000000] I2 --> O2[rbd_data.00000001] I3 --> O3[rbd_data.00000002] I4 --> O4[rbd_data.00000003...] O1 --> PG1[PG 1.5a] O2 --> PG2[PG 1.7f] O3 --> PG3[PG 1.21] O4 --> PG4[...] PG1 -->|Primary| P1[osd.1] PG1 -->|Replica| R11[osd.3] PG1 -->|Replica| R12[osd.7] PG2 -->|Primary| P2[osd.4] PG2 -->|Replica| R21[osd.9] PG2 -->|Replica| R22[osd.10] PG3 -->|Primary| P3[osd.2] PG3 -->|Replica| R31[osd.5] PG3 -->|Replica| R32[osd.8]

要点：

• RBD 镜像被切分为很多对象（Object），默认 4MB 一块（可配置 rbd_default_features / rbd_default_order）。

• 每个对象：

  • 属于某个 Pool；
  • 通过 CRUSH 规则，映射到某个 PG；
  • 再由 PG 映射到一组 OSD（Primary + N 个 Replica）。

---

三、结合"删除文件 / 快照 / 回滚"再理解一次数据流

1️⃣ 删除文件（rm）

• 你在文件系统里执行：

  rm -rf /mnt/cephdisk/largefile.bin

• 真正发生的是：

  • 文件系统只是删掉 inode + 目录项；
  • RBD 对象本身仍然存在，只是部分块被标记为"未使用"；
  • 空间不会立刻返还给集群 → 需要 fstrim 或挂载 discard 才会发出 discards，底层对象才可能被裁剪或认为空间可重用。

2️⃣ 快照（snap）

• 创建快照：

  rbd snap create rbd/data01@snap1

• 数据流逻辑：

  • 快照时，不会立刻复制所有对象；
  • 只是记录一个"当下对象版本的引用"，之后写入新数据时采用 写时复制（COW）；
  • 新写数据对象会写到新的 Object / New version，老的 Object 仍然被快照引用。

3️⃣ 快照回滚（rollback）

• 当你执行：

  rbd snap rollback rbd/data01@snap1

• 流程：

  • librbd 会把当前镜像上所有"被修改的对象"重写为快照时对应的对象版本；
  • 这会触发大量写请求到 Primary OSD → Replica；
  • 实际数据流还是"普通写路径"，只是数据来源是旧版本对象（快照）而已。

---

四、如果你想写进博客/报告，可以这样组织结构

建议你在博客中按这个结构写：

1. 从一个简单例子入手：

   • "应用往 /dev/rbd0 写入一个文件时，Ceph 在底下做了什么？"

2. 画出第一张：客户端 → librbd → librados → MON/MGR → CRUSH → OSD 的数据流图；

3. 细化：单个 Primary OSD 内部的写入流程（WAL/DB + BlueStore）；

4. 画出 RBD 镜像 → 对象 → PG → OSD 的映射图；

5. 用删除文件 / 快照 / 回滚的场景，串一遍"RBD 逻辑层"和"Ceph 物理层"的对应关系；

6. 最后可以加一小节：RBD 与 RADOS GW / CephFS 的对比，为什么 RBD 更适合块存储场景（虚机、数据库）。

---

如果你愿意，我还可以帮你：

• 把这几张图配合文字整理成一篇完整 Markdown 博客；
• 或者再画一张 "集群部署视角" 的结构图：Client、Gateway、Cephadm、MON、MGR、OSD、MDS 等全部串起来。
  不会。RBD 快照本身不会自动备份，也不会自动创建，需要你手动创建，或自己配置脚本/定时任务才会自动化。

这是很多人第一次使用 Ceph RBD 时的常见误解，我给你从"概念层面"和"实际工程"两个层面讲清楚：

---

✅ 一、快照不是自动备份（Snapshot ≠ Backup）

RBD 快照具备"保存当下磁盘状态"的能力，但：

❗ 快照不会自动创建

你必须手动执行：

rbd snap create pool/image@snap1

或自己写 cron + rbd 命令来"自动化"，否则不会有任何快照产生。

---

❗ 二、快照不是备份，它并不保存全量数据副本

真正的区别：

项目	快照 Snapshot	备份 Backup
是否自动创建	❌ 不会自动	✔ 可自动化
数据是否完全独立保存	❌ 依赖原镜像	✔ 保存为独立副本
如果镜像坏了（如 pool 损坏）	❌ 快照也一起完蛋	✔ 备份仍然安全
作用	保存时间点，可快速回滚/克隆	灾难恢复（DR）、长期保存

一个关键点：

快照依赖原始 RBD 镜像和对象，一旦底层对象损坏快照也无法恢复。

所以快照不等同于备份。

---

🧠 三、快照能不能当"自动备份"？可以，但需要你自己实现

你可以写一个自动创建快照的任务，例如：

示例（每天凌晨 2 点自动快照）

编辑 crontab：

crontab -e

加入：

0 2 * * * rbd snap create rbd/data@auto-`date +\%Y-\%m-\%d`

自动删除超过 7 天快照：

0 3 * * * rbd snap purge rbd/data --older-than 7d

这样才能做到所谓的"自动备份效果"。

---

🔥 四、Ceph 里真正的"自动备份"方式是什么？

你的场景如果需要"真正备份+跨机房容灾"，那应该用：

1. RBD 镜像复制（RBD Mirroring）

• 可以把一个 pool 的镜像自动复制到另一个集群（异地双活 / 灾备）。
• 这才是 Ceph 官方提供的"自动备份"机制。

2. rbd export / import（手动或脚本备份）

例如：

rbd export rbd/data data_backup_2025-01-01.img

这才会生成一个真正独立的备份文件。

---

❗ 五、结论（你必须记住）

RBD 快照不是自动备份，也不会自动产生，需要你手动或脚本执行。
它也不能替代真正的备份，因为它依赖原镜像对象。

快照主要用于：

• 快速回滚
• 快速克隆
• 节省空间
• 系统升级前留一个安全点

不能用于灾备和长期数据保护。

---

如果你愿意，我可以继续帮你写：

📌 自动快照脚本（带保留策略）

📌 RBD 真正备份方案（export + S3/minio + mirroring）

📌 快照 + 克隆依赖关系图（可视化）

你想继续哪一部分？