rbd的操作

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

📘 Ceph RBD 存储管理详细教程

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

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

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

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

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

核心机制：TRIM/UNMAP

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

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

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

核心机制：Snaptrim

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

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

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

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

✔ RBD 镜像创建、查看、扩容、缩容、删除
✔ RBD 映射（挂载到客户端）与取消映射
✔ 文件删除机制说明（RBD 内部文件≠RBD 对象删除）
✔ 快照创建、回滚、保护/取消保护、克隆、删除
✔ 镜像迁移、镜像复制（简单提一下）

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

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

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

🧿三、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 常见错误排查

🧿十、删除整个 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/rbd0mount/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 命令来“自动化”，否则不会有任何快照产生。

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

真正的区别：

一个关键点：

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

所以快照不等同于备份。

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

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

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

编辑 crontab：

crontab-e

加入：

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

自动删除超过 7 天快照：

03* * * rbd snap purge rbd/data --older-than 7d

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

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

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

1.RBD 镜像复制（RBD Mirroring）

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

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

例如：

rbdexportrbd/data data_backup_2025-01-01.img

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

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

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

快照主要用于：

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

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

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

📌自动快照脚本（带保留策略）
📌RBD 真正备份方案（export + S3/minio + mirroring）
📌快照 + 克隆依赖关系图（可视化）

你想继续哪一部分？