Ceph 生产环境搭建 | 第 6 天：OSD 存储节点部署：BlueStore 配置与磁盘管理

第 6/20 天

引言：为什么 OSD 是 Ceph 存储的核心

在 Ceph 分布式存储集群中，OSD（Object Storage Daemon，对象存储守护进程）是真正承载数据读写的工作节点。Monitor 维护集群拓扑，Manager 提供管理与扩展能力，而所有用户数据的持久化、副本复制、纠删码计算、故障恢复都由 OSD 完成。一个 Ceph 集群的数据平面，本质上就是一群 OSD 的集合。

本篇是「Ceph 生产环境搭建」系列的第六篇。前几篇我们完成了 Ubuntu 系统准备、Cephadm 集群引导、Monitor 与 Manager 节点部署。从今天起，集群正式进入”存储容量”建设阶段——我们将基于 Ceph Squid（v19）在 Ubuntu 24.04 LTS 上，使用 BlueStore 存储引擎部署 OSD 节点，并深入讲解磁盘分区规划、BlueStore 分层设备（DB/WAL/Block）、cephadm 的 OSD Spec 自动化管理以及生产环境的踩坑要点。

BlueStore 是自 Ceph Luminous 起的默认对象存储引擎，它绕过传统文件系统直接管理裸块设备，在元数据效率、写入延迟、空间利用率上全面超越旧的 FileStore。掌握 BlueStore 的部署与调优，是构建生产级 Ceph 集群的必经之路。

架构与原理：BlueStore 的设计哲学

BlueStore 整体架构

BlueStore 是 Ceph 自研的对象存储引擎，其核心设计理念是直接管理裸块设备，避免在 ext4/XFS 等通用文件系统上叠加一层抽象带来的性能损耗与元数据冗余。BlueStore 内部包含三个关键子系统：

组件	作用	存储介质
Block（主体数据区）	存储对象数据本体，RBD/CephFS/RGW 的实际数据块	HDD / SSD / NVMe
DB（RocksDB 元数据）	存放对象元数据（omap）、BlueStore 内部元数据、扩展属性	优先 NVMe/SSD
WAL（预写日志）	RocksDB 与 BlueStore 的 Write-Ahead Log，确保写持久性	优先 NVMe/SSD
BlueFS	一套极简只追加文件系统，承载 RocksDB 的 .sst/LOG/MANIFEST 文件	与 DB/WAL 同设备

数据写入路径可以这样理解：当客户端写入一个对象时，数据先以 blob 形式直接落盘到 Block 设备（大块直写），而该对象的大小、位置、校验、omap 等元数据则通过 RocksDB 写入 DB 设备。RocksDB 自身的写操作会先记入 WAL，再由 MemTable 刷盘形成 .sst 文件，这些 .sst 存放在 BlueFS 管理的区域。

分层设备模型

BlueStore 支持将 Block、DB、WAL 分别放置到不同设备，这是生产环境最关键的规划决策之一：

单设备模式（all-in-one）：DB/WAL 与数据共用一块磁盘。RocksDB 元数据写入与数据写入共享 I/O 带宽，适合小规模或全 NVMe 场景。
DB+WAL 分离模式：DB 与 WAL 放在一块高速 NVMe 上，数据块放在大容量 HDD 上。这是 HDD 集群的主流生产配置，显著提升元数据查询与小写性能。
三设备分离模式：Block、DB、WAL 各自独立设备。WAL 对延迟极敏感，单独放到最高速的 NVMe 可榨取极限性能，但运维复杂度上升，多用于对延迟要求苛刻的场景。

数据放置与校验

BlueStore 将对象切分为若干 blob，每个 blob 又分成若干 shard 并计算校验和（默认 crc32c）。读取时会校验 shard 的完整性，一旦发现数据损坏即可借助副本或纠删码从其他 OSD 恢复。这种自校验机制是 BlueStore 对静默数据腐（silent data corruption）的重要防护。

部署实战：从磁盘识别到 OSD 上线

环境准备：磁盘识别与清理

部署 OSD 前，必须确保目标磁盘是一块”干净”的裸设备——没有残留分区表、LVM 元数据或文件系统签名。先用 ceph-volume 自带的 inventory 工具扫描可用设备：

💻 代码示例

# 在任意 mgr 节点上列出所有 OSD 可用设备及其健康状态

ceph cephadm enter –name mgr.$(hostname) — ceph-volume inventory

# 直接查看块设备拓扑（示例输出会标注磁盘型号、 rotational、大小）

lsblk -o NAME,SIZE,TYPE,ROTA,MODEL,SERIAL,TRAN,REV,MOUNTPOINTS

# 确认设备未被文件系统占用

lsblk -f

# 预期：目标数据盘的 FSTYPE 列为空，MOUNTPOINTS 也为空

# 若磁盘存在历史分区或 LVM 残留，需要彻底擦除

# 警告：以下命令会清除目标磁盘所有数据，务必确认设备名！

sgdisk –zap-all /dev/sdb

# 同步清除 udev 残留与 LVM metadata

dd if=/dev/zero of=/dev/sdb bs=1M count=100 oflag=direct,dsync

partprobe /dev/sdb

# 若历史上有 ceph LVM，还需清理对应 VG

# vgdisplay | grep -i ceph -> 确认无 ceph 相关 VG 残留

生产环境注意：sgdisk --zap-all 会抹除 GPT/MBR 分区表，但不会覆写磁盘内容；对涉及下线、二次复用的磁盘，建议增加 blkdiscard 或安全擦除（对 SSD 执行 blkdiscard /dev/sdb 触发 TRIM，恢复写入性能）。

编写 OSD Spec：声明式自动化部署

Cephadm 使用”OSD Spec”（也称 Drive Group）以声明式方式描述如何把磁盘组合成 OSD。下面这份 YAML 是一个典型的 HDD + NVMe 分层生产配置：12 块 HDD 做数据盘，2 做元数据加速。

💻 代码示例

# /tmp/osd-spec.yaml —— 声明式 OSD 部署规格

service_type: osd

service_id: hdd_nvm_mix

placement:

host_pattern: 'osd-*' # 在所有 osd-* 开头的主机上生效

data_devices:

rotational: 1 # 选择机械盘（rotational=1）

model: ST4000NM0035 # 可选：按型号精确匹配，保证只采用指定批次

db_devices:

rotational: 0 # 选择非机械盘作为 DB 设备

size: 200GB:1TB # DB 设备容量区间 200GB~1TB

wal_devices:

rotational: 0 # WAL 也可独立指定，此处与 DB 同类设备

model: INTEL_SSDPE2KX # 指定企业级 NVMe

# 不指定 db_size 时，cephadm 会自动按数据盘比例计算

# 生产推荐：每块 HDD 配置 40~80GB DB 空间

encrypted: false # 是否启用 LUKS 全盘加密

关键参数说明：

data_devices / db_devices / wal_devices：分别匹配数据、元数据、WAL 设备。匹配条件支持 rotational、size、model、vendor、all 等。
db_size：显式指定每个 OSD 的 DB 区大小，单位字节或带单位（如 80GB）。不指定则自动计算（默认约为数据盘的 4%，上限 100GB）。
encrypted: true：启用 LUKS 磁盘加密，满足合规要求，但有微小性能损耗。
placement.host_pattern：限定在哪些主机生效，避免误占用管理节点磁盘。

应用 Spec 并部署 OSD

将 spec 提交给 Cephadm 编排器，它会在所有匹配主机上自动创建 OSD：

💻 代码示例

# 应用 OSD Spec（文件路径用 @ 前缀告诉 cephadm 读取本地文件）

ceph orch apply -i /tmp/osd-spec.yaml

# 观察部署进度：cephadm 会逐台主机执行 ceph-volume

ceph orch osd ls

# 输出示例：

# HOST OSD PTYPE PV_NAME SIZE DEVICE DB WAL

# osd-01 0 hdd /dev/sdb1 3.6T sdb sdc sdd

# osd-01 1 hdd /dev/sdc1 3.6T sdc sdc sdd

# 也可查看单台主机的部署详情

ceph cephadm enter –name mgr.$(hostname) — ceph-volume lvm list

# 单台主机如果想"干扫一遍"再看怎么规划：

ceph orch daemon add osd –local '["osd-01"]'

'data_devices.rotational=1 db_devices.rotational=0'

踩坑提示：ceph orch apply 是幂等操作。修改 spec 后重新 apply，cephadm 只会创建新增的 OSD，不会删除已有 OSD。要移除 OSD 必须显式执行 ceph osd destroy 或 ceph orch osd rm <id>。

验证 OSD 状态与集群健康

部署完成后，需要逐项确认 OSD 是否正常加入 CRUSH、副本数是否满足要求：

💻 代码示例

# 查看 OSD 拓扑（含 CRUSH 层级、设备类型、状态）

ceph osd tree

# 期望输出：每个 OSD 状态为 up，weight 非 0

# 查看 OSD 详细列表与所在主机

ceph osd ls-tree default

# 检查集群整体健康与可用空间

ceph -s

# 关注：HEALTH_OK、PG 状态全为 active+clean、可用空间已增长

# 查看每块 OSD 的设备信息（确认 DB/WAL 落在 NVMe）

ceph osd metadata osd.0 | grep -E 'bluestore_bdev|bluefs_db|bluefs_wal'

# 查看 BlueStore 内部使用率与 DB 占用

ceph daemon osd.0 perf dump | grep -A5 bluefs

ceph osd df | head -20

BlueStore 配置参数调优

通过 ceph config set 在集群全局调整 BlueStore 行为。下面是几个生产常用的关键参数：

💻 代码示例

# 1) 关闭 BlueStore 缓冲 I/O：让 RocksDB 走同步直写，避免元数据丢失风险

ceph config set osd bluestore_buffered_io false

# 2) 设置 BlueStore 缓存大小（默认 1GB，HDD 集群建议调大以提升读命中率）

ceph config set osd bluestore_cache_size 3221225472 # 3GB

# 3) 启用 BlueStore blob 压缩（适合冷数据），算法 lz4 平衡速度与压缩率

ceph config set osd bluestore_compression_algorithm lz4

ceph config set osd bluestore_compression_min_blob_size 8192 # 8KB 起压缩

ceph config set osd bluestore_compression_required_ratio 0.85

# 4) RocksDB 配置：调大 block cache，减少元数据查询的读放大

ceph config set osd bluestore_rocksdb_options write_buffer_size=67108864,max_write_buffer_number=4

# 5) 将 DB 与 WAL 完全合并到同一设备（生产默认行为，无需额外开销）

ceph config set osd bluefs_shared_log "true"

# 6) 查看某 OSD 当前生效的所有 BlueStore 配置

ceph config dump | grep bluestore

参数解读：

参数	含义	生产建议
`bluestore_buffered_io`	是否启用缓冲 I/O（RocksDB 走 page cache）	关闭（false），保证元数据持久性
`bluestore_cache_size`	BlueStore 元数据/数据缓存	HDD 集群 2~4GB；SSD 1~2GB
`bluestore_compression_algorithm`	blob 压缩算法	lz4（速度优先）；zstd（压缩率优先）
`bluestore_compression_min_blob_size`	触发压缩的最小 blob	8KB~16KB，避免小对象压缩开销
`bluefs_shared_log`	DB 与 WAL 共享同设备	默认 true，简化部署

手动部署单块 OSD（高级场景）

当自动 spec 无法满足精细化需求（如临时在一台主机加一块特定磁盘），可手动用 ceph-volume 部署：

💻 代码示例

# 进入目标 OSD 主机的容器上下文

ceph cephadm enter –name mgr.$(hostname)

# 手动部署：DB/WAL 分层，明确指定 LVM 卷名

ceph-volume lvm create

–data /dev/sdb

–block.db /dev/nvme0n1

–block.wal /dev/nvme0n1p1

–dmcrypt

–osd-id 2

–osd-fsid $(uuidgen)

# 退出容器后回到主机，让 cephadm 接管

exit

ceph orch apply osd spec –dry-run # 仅打印将要变更的 OSD，不真正改动

生产环境注意事项与踩坑提示

DB 大小规划：DB 空间一旦确定便难以无损扩展。生产建议按”每 TB 数据 10~20GB DB”分配；若 RocksDB 超过 DB 区会”溢出”到慢速数据盘（BlueFS spillover），元数据查询延迟剧增，集群性能急剧劣化——这是 Ceph 生产事故的高频原因。
WAL 不必单独设备：在现代 NVMe 上，WAL 与 DB 放同设备已足够（bluefs_shared_log=true）。三设备分离带来的延迟收益有限，却增加了 3 倍的故障面与运维复杂度，非延迟敏感场景不建议。
避免 OSD 全部集中在单台主机：单主机挂掉的 blast radius 会触发 PG 重平衡风暴。CRUSH 应保证 host 级故障域，跨机柜部署时启用 root → row → rack → host → osd 多级结构（详见第 7 天 CRUSH Map）。
磁盘型号一致性：同一 CRUSH bucket 内尽量使用同型号同批次磁盘。混用不同转速/接口的盘会导致 PG 性能木桶效应，最慢的 OSD 拖累整个 pool。
不要在生产用 FileStore：FileStore 已在 Reef/Squid 进入弃用状态。新部署一律 BlueStore；存量 FileStore OSD 应在维护窗口迁移。
ceph-volume 与 cephadm 的边界：cephadm 编排器底层就是调用 ceph-volume，二者不能在同一 OSD 上交叉操作。手动物理销毁 OSD 后必须重启 cephadm agent 或重新 apply spec，避免状态不一致。

常见问题

Q1：OSD 创建后一直 down，日志显示 “failed to read osd superblock”？

常见原因是磁盘上残留旧分区或 BlueFS 元数据损坏。先 ceph osd destroy <id> --yes-i-really-mean-it，再到对应主机 sgdisk --zap-all + blkdiscard，最后重新 apply spec。

Q2：怎么判断 DB 是否已经溢出到数据盘？

执行 ceph daemon osd.<id> perf dump | grep bluefs_bytes_written_slow，若该值非零且持续增长，说明已发生 spillover。应优先扩容 DB 或排查是否元数据过多（如单 pool 内对象数极多）。

Q3：所有数据盘都是 NVMe，还需要分 DB 设备吗？

不需要。全 NVMe 集群建议 all-in-one 单设备模式，让 BlueStore 直接管理整块 NVMe，性能与运维效率最佳。只在大容量 HDD + 少量 NVMe 的混合场景才需要分层。

总结

本篇围绕 OSD 节点部署，从 BlueStore 的分层设备模型、数据写入路径到 cephadm 声明式 OSD Spec 的实战应用，系统讲解了在 Ubuntu 24.04 LTS 上部署 Ceph Squid v19 存储平面的完整流程。核心要点：① BlueStore 的 Block/DB/WAL 三段式布局；② DB 大小要一次性规划到位避免 spillover；③ 优先使用 cephadm OSD Spec 实现批量声明式部署，减少手动物理操作；④ 生产环境关闭 bluestore_buffered_io、合理设置缓存与压缩参数。

OSD 全部上线、集群有了真正的存储容量后，下一步就要解决”数据该写到哪块盘、副本如何分散、故障域如何隔离”——这正是 CRUSH Map 的核心命题。

下期预告

第 7 天：CRUSH Map 架构解析与故障域规划 —— 我们将深入 CRUSH 算法的工作原理，解析 default CRUSH tree 的层级结构，实战自定义 root/rack/host 故障域，并讲解 rule 与 crush class 如何让数据按介质类型智能分布。这决定了集群在硬件故障时的数据安全性，是 Ceph 生产环境最关键的一环。