尧图网页设计 
简介一份面向云服务管理与存储架构运维人员的Ceph块存储实战指南聚焦分布式存储中RBD块设备的部署与应用。内容基于三节点实验集群在Ubuntu 18.04环境下完成数据池创建、块设备镜像生成并演示将镜像映射为Linux块设备、执行mkfs格式化、挂载及读写验证同时涵盖集群健康状况与映射状态的检查方法。文中围绕存储池、镜像、映射、监控等核心指令展开特别适合具备一定存储基础、希望在虚拟化或生产环境中落地Ceph方案的技术人员使用。资源为单一PDF文档约286KB以精简的实验步骤和命令输出呈现完整操作流程便于本地查阅或对照实验。已有70人学习下载虽体量不大但胜在步骤清晰、重点集中。读者可从中获得一条从集群规划、RBD池创建、镜像生成到系统挂载使用的贯通路径并了解rbd map、rbd showmapped、mkfs.ext4、mount、df等关键命令的实际用法为后续研究快照、克隆等高级特性或调整大规模生产参数提供可复用的操作基础。1. Ceph 块存储系统部署为什么自己做而不是买一套存储选型这件事到后期基本是在算空间和运维成本的账。CEPH 块存储系统这几年在公有云上几乎是隐形的真正落到自建机房它反而是团队绕不开的默认答案。这篇内容不停在「装完集群、Dashboard 变绿」而是把 CEPH 块存储系统的部署与应用串成一条能走通的闭环集群组件怎么理解、网络与磁盘怎么规划、cephadm 怎么初始化、RBD 映像怎么挂到主机和虚拟机、上线前哪几组参数必须调。适合两类人刚接手存储的运维想在一周内把三节点测试集群跑起来另一类是开发人员需要弄清数据为什么落在某几块盘上以及为什么某些 IO 会比其他 IO 慢。读之前不需要使用 CEPH 的经验但最好熟悉 Linux 分区、网卡聚合和常用文件系统操作。2. 块存储、RBD 与 Ceph 核心组件的对应关系2.1 四个核心组件里块存储真正需要的是哪两个Ceph 集群常被概括成四个组件MonitorMON、OSD、MDS、RGW。MON 维护集群映射、选举主节点并负责认证客户端读写数据之前必须先联系 MONOSD 负责把副本保存到物理盘上是容量与吞吐的主力MDS 只服务于 CephFS 文件系统RGW 对外提供 S3 兼容的对象存储接口。把组件的职责边界先划清楚后面规划资源才不会被「全组件都要部署」的惯性带偏。组件是否必需主要职责常见部署数量MON必需维护集群映射、选举主节点、提供认证3 或 5OSD必需保存数据副本、响应客户端读写三节点各 1 个以上MDSRBD 不需要管理 CephFS 元数据块存储场景可不部署RGWRBD 不需要提供对象存储网关块存储场景可不部署只靠 MON OSD 这一结论直接影响规划思路不需要为 MDS 预留内存不需要开 RGW 缓存集群资源可以全部压到 OSD 上。生产环境 MON 建议部署奇数个并分散在不同故障域OSD 数量决定总容量与冗余能力。例如 9 块 8TB 盘、副本数 3 的集群总空间是 9×872TB扣除副本后可用容量约 24TB还要再预留 10% 给 PG 迁移和后台均衡实际可用在 20TB 出头。忘记这 10% 余量的集群会在容量接近 85% 时出现明显 IO 抖动这是许多存储事故的起点。2.2 RBD 是把分布式存储伪装成一块普通磁盘RADOS Block DeviceRBD是 Ceph 的块存储接口。它把多个 OSD 上的对象抽象成一个连续块设备客户端通过内核模块 rbd 或用户态 librbd 访问看到的就是「一块硬盘」。RBD 和本地盘最大的差异是数据被切碎后散落在多台机器上每次读写都要经过网络因此网络质量对延迟的影响往往超过磁盘本身的顺序写速度。理解这一点对调参帮助很大客户端与 OSD、OSD 与 OSD 之间的带宽决定块设备吞吐上限从万兆降到千兆顺序 IO 可能下跌 80% 以上。RBD 默认关闭写回缓存写操作要等副本全部落盘才返回这是它在掉电后仍能保证不丢数据的根本原因也是机械盘上随机写延迟偏高的来源。看到 RBD IO 慢先不要怀疑磁盘健康先查网络队列和网卡中断是否均匀分配。2.3 PG、副本策略与 CRUSH 决定数据到底在哪块盘RBD 映像在 Ceph 内部不连续存储而是按对象大小切成对象再由 CRUSH 算法把每个对象映射到一组 OSD。放置组 PG 是对象到 OSD 之间的中间聚合层它让对象不需要单独记录位置只要知道属于哪个 PG、PG 落在哪些 OSD 上就能定位数据。副本数由 pool 的 size 和 min_size 控制size3 表示三副本min_size2 表示最少两副本在线才能接受写入。ceph osd pool create rbd 128 128 replicated ceph osd pool set rbd size 3 ceph osd pool set rbd min_size 2第一行创建名为 rbd、PG 数为 128 的复制型存储池第三、四行把副本策略设为三副本并允许两副本时保持写入。PG 数不能拍脑袋单节点实验环境用 32三节点每节点三块盘的测试集群取 128生产建议把 PG 数设为 OSD 总数与每 OSD 期望 PG 数的乘积再就近靠 2 的幂。PG 太多会让 OSD 内存占用升高太少则数据分布不均某些盘可能比其他盘多出 30% 负载。存储池准备好以后数据最终落盘由 CRUSH 规则决定。规则按主机、机架、机房划分故障域副本会尽量分开例如三副本默认拒绝把三个副本都放到同一台物理机上。部署时如果用了错误的 CRUSH 规则会看到集群状态健康但某台机器故障时所有 PG 同时失去副本这是比容量估算更隐蔽的风险。3. 用 cephadm 从头部署三节点 Ceph 集群3.1 部署前的网络、磁盘与内核参数规划Ceph 部署失败的最大来源不在命令难度而在前置规划。生产环境建议公共网络与集群网络分离公共网络承载客户端到 MON/OSD 的读写集群网络承载 OSD 之间的副本同步、数据再均衡和心跳两者用独立网卡万兆起步。三节点测试环境至少要把 IP 分开再把cluster_network指向独立网段否则副本流量会挤占客户端 IO 带宽表现就是 RBD 吞吐正常但延迟飘高。规划项建议值说明系统盘100GB 以上安装操作系统与容器运行时OSD 数据盘每 OSD 独立整盘不分区避免与系统共享 IO公共网络万兆客户端挂载、Dashboard 访问集群网络万兆副本同步、恢复、心跳内存每 OSD 4GB 以上MON 单独 2GBOSD 尽量多于 4GB内核参数vm.swappiness10降低 swap 造成 IO 抖动cephadm 以容器方式拉起 MON、OSD、MGR 等守护进程宿主机只需要 Docker 或 Podman。没有外网镜像源的内网机房提前把 cephadm 所需的容器镜像导出到内部 registry再在 bootstrap 时指向内部仓库就是日常说的离线安装测试环境里能省掉大量拉取超时等待。还有一个容易被忽略的参数osd_memory_target默认随总内存自动收敛多 OSD 场景要确认它不会超过主机物理内存一半否则多个 OSD 挤在一台机器上会互相抢缓存延迟反而上升。3.2 cephadm bootstrap 初始化集群的最小命令序列先在每台主机写清 /etc/hosts配好 SSH 免密然后选中第一个节点执行 bootstrap。下面命令以 root 身份运行会在当前节点创建 MON、MGR 和辅助组件并输出 Dashboard 访问地址和初始密码。cephadm bootstrap --mon-ip 192.168.1.10 --cluster-network 192.168.2.0/24 ceph orch host add node1 192.168.1.10 ceph orch host add node2 192.168.1.11 ceph orch host add node3 192.168.1.12 ceph orch apply mon node1,node2,node3--mon-ip指定当前节点对外提供 MON 服务的 IP--cluster-network把副本流量引到独立网段。后面四条命令把另外两个节点加进集群并把 MON 扩展到三台。bootstrap 完成后先执行ceph -s看到HEALTH_OK再继续否则后续所有操作都会在一个异常集群上反复报错排查成本远比停下来修复高。OSD 加入有两种方式人工指定磁盘或用过滤器批量识别。三节点测试环境人工指定更可控我一般会这么做ceph orch apply osd all-available-devices --unmanagedtrue ceph orch device zap node1 /dev/sdb --force ceph orch device zap node2 /dev/sdb --force ceph orch daemon add osd node1:/dev/sdb ceph orch daemon add osd node2:/dev/sdb ceph orch daemon add osd node3:/dev/sdb--unmanagedtrue让 cephadm 只识别磁盘不自动创建防止它把系统盘或还在使用的数据盘当成空盘加进集群。device zap会擦除整个磁盘并重写分区表执行前必须核对主机名和盘符这个操作不可逆。每台机器只放一个 OSD 时副本会跨主机分布单机故障后的数据恢复依赖剩余两台主机的带宽因此生产环境不要用双节点至少三节点起步。3.3 创建块存储专属存储池并验证副本策略集群健康后创建块存储池并固定副本策略。pool 名、PG 数、副本数这三个参数是后续所有 RBD 操作的前提一旦改错客户端挂载会立即报集群不健康。ceph osd pool create rbd 128 128 rbd pool init rbd ceph osd pool set rbd size 3 ceph osd pool set rbd min_size 2 ceph osd pool application enable rbd rbdrbd pool init在池内生成 rbd 元数据对象没有这一步之后创建 RBD 映像会报 pool 未初始化application enable rbd rbd告知集群这个 pool 承载 RBD 设备让 Dashboard 能识别其类型。创建完成后用ceph osd pool ls detail检查 size、min_size 和 pg_num确认 PG 状态为activeclean。如果长时间处于creating或peering先确认所有 OSD 的时钟偏移再查集群网络是否存在丢包这两个原因占了 PG 卡住的大多数情况。4. 把 RBD 映像挂进主机、虚拟机和容器4.1 创建 RBD 映像并用内核模块映射成块设备块存储池就绪后第一步创建映像并映射到客户端主机。以下命令在客户端执行使用集群管理员 keyring 认证。rbd create image1 --size 10240 --pool rbd rbd feature disable rbd/image1 object-map fast-diff deep-flatten rbd map rbd/image1 mkfs.xfs /dev/rbd0 mkdir /data mount /dev/rbd0 /data--size单位是 MB10240 表示 10GB。第二行关闭与旧内核存在兼容问题的三个 feature这是内核模块映射时最常见的失败原因。rbd map成功后客户端会出现 /dev/rbd0后面就是普通块设备流程mkfs.xfs、mount、挂载使用。若 map 报 Permission denied把集群节点的/etc/ceph/ceph.client.admin.keyring复制到客户端并确认文件权限为 600。命令作用常用参数rbd create创建映像--sizeMB、--pool、--image-featurerbd map内核映射默认读取 /etc/ceph 配置rbd snap create创建快照pool/imagesnap命名rbd clone生成可写副本指定源快照与目标名内核映射方案适合裸金属业务或容器主机。容器场景里客户端主机的 rbd 模块如果加载不出来可以退一步通过 rbd-nbd 访问性能低于内核模块但可用性更好所以能切内核优先切内核。4.2 在 KVM 环境中把 RBD 作为虚拟磁盘裸金属主机用内核虚拟化环境更推荐让 QEMU 直接通过 librbd 访问 RBDIO 路径不经过宿主机文件系统性能与稳定性都更好。libvirt 虚拟机 XML 中把 disk type 设为 network、protocol 设为 rbd或在运行中执行virsh attach-disk vm1 rbd:rbd/image1 /dev/vda --driver qemu --targetbus virtio这条命令把rbd:rbd/image1作为 virtio 磁盘挂给虚拟机源地址写法是rbd:pool名称/映像名称。生产环境建议把 MON 地址写全例如rbd:rbd/image1:mon_host192.168.1.10:6789,192.168.1.11:6789否则客户端只连一个 MON该节点重启时重连时间会明显变长。宿主机需要提前安装qemu-block-rbd对应的 librbd 组件否则 libvirt 报 driver 不存在。本地文件虚拟磁盘的快照把镜像写入同一目录管理零散、故障恢复也麻烦RBD 把快照、克隆都放在集群侧容量调度以 pool 为边界扩容时不需要迁移虚拟机文件这是私有云把 Ceph 块存储系统当作 KVM 默认后端的原因之一。4.3 快照、克隆与回滚的日常维护RBD 快照是时间点级别的只读镜像升级系统或安装软件前打一个快照出事快速回退。快照本身不占容量只有写新数据产生差异时才累积空间占用。rbd snap create rbd/image1pre-upgrade rbd snap protect rbd/image1pre-upgrade rbd clone rbd/image1pre-upgrade rbd/image1-temp rbd flatten rbd/image1-tempsnap protect将快照置于保护状态因为 clone 要求源快照不可删除rbd clone基于快照生成可写副本rbd flatten去掉副本与快照的依赖让数据独立落盘。非保护快照可以直接用rbd snap rm删除受保护快照必须先用rbd snap unprotect解除保护。执行rbd snap rollback前最好先卸载对应设备滚回旧快照会覆盖当前写入数据虚拟机场景里先停机再操作避免文件系统不一致。5. Ceph 上线前必调的参数与一次典型卡顿排查5.1 客户端缓存与恢复流量的取舍RBD 内核模块默认关闭写回缓存数据库场景下安全但测试和一般应用场景延迟偏高。打开缓存echo 1 /sys/module/rbd/parameters/rbd_cache ceph config set osd osd_max_backfills 2 ceph config set osd osd_recovery_max_active 3第一行打开内核模块写缓存把顺序写延迟压低一个量级代价是主机掉电可能丢少量未落盘数据。第二、三行控制坏盘后的恢复速度osd_max_backfills调大恢复快但会挤占业务 IO生产环境保持在 2 或 3 更稳。更稳妥的做法是用定时任务在业务低峰期调高恢复参数白天恢复为 0避免大半夜被恢复任务拖垮整条链路。5.2 用 prometheus 指标判断瓶颈在哪一端Ceph 自带 prometheus exporter开启 mgr prometheus 模块后从 9283 端口抓取数据配合 prometheus 监控部署与 Grafana很快能看到节点级延迟与 PG 状态。重点看ceph_pg_degraded与ceph_osd_utilization两个指标前者非零先处理 PG不要调客户端参数后者超过 0.85 说明容量接近上限需要扩充 OSD 而不是排查延迟。ceph_rbd_read_latency偏高但前两个指标正常问题多半在网络或客户端优先排查网卡多队列与中断绑定。5.3 卡在 activeundersized 时的单步验证PG 状态出现activeundersized说明副本数不足。按顺序执行ceph osd tree ceph pg dump | grep stuck ceph osd safe-to-destroy osd_idceph osd tree定位掉线 OSDceph pg dump | grep stuck输出长时间卡住的 PG把 pgid 与失败 OSD 对上最后一条命令判断下线盘是否能直接移除。返回 safe 就换盘返回 not safe 说明该 OSD 上仍有数据未完成复制等集群补完副本后再操作。整个过程不需要重启客户端集群会自动进入恢复流程期间 IO 抖动属于正常现象先核对 OSD 日志确认是硬件故障还是网络抖动再决定是否人工介入。本文还有配套的精品资源点击获取 Ceph块存储系统部署实战：从集群搭建到RBD挂载与调优
简介一份面向云服务管理与存储架构运维人员的Ceph块存储实战指南聚焦分布式存储中RBD块设备的部署与应用。内容基于三节点实验集群在Ubuntu 18.04环境下完成数据池创建、块设备镜像生成并演示将镜像映射为Linux块设备、执行mkfs格式化、挂载及读写验证同时涵盖集群健康状况与映射状态的检查方法。文中围绕存储池、镜像、映射、监控等核心指令展开特别适合具备一定存储基础、希望在虚拟化或生产环境中落地Ceph方案的技术人员使用。资源为单一PDF文档约286KB以精简的实验步骤和命令输出呈现完整操作流程便于本地查阅或对照实验。已有70人学习下载虽体量不大但胜在步骤清晰、重点集中。读者可从中获得一条从集群规划、RBD池创建、镜像生成到系统挂载使用的贯通路径并了解rbd map、rbd showmapped、mkfs.ext4、mount、df等关键命令的实际用法为后续研究快照、克隆等高级特性或调整大规模生产参数提供可复用的操作基础。1. Ceph 块存储系统部署为什么自己做而不是买一套存储选型这件事到后期基本是在算空间和运维成本的账。CEPH 块存储系统这几年在公有云上几乎是隐形的真正落到自建机房它反而是团队绕不开的默认答案。这篇内容不停在「装完集群、Dashboard 变绿」而是把 CEPH 块存储系统的部署与应用串成一条能走通的闭环集群组件怎么理解、网络与磁盘怎么规划、cephadm 怎么初始化、RBD 映像怎么挂到主机和虚拟机、上线前哪几组参数必须调。适合两类人刚接手存储的运维想在一周内把三节点测试集群跑起来另一类是开发人员需要弄清数据为什么落在某几块盘上以及为什么某些 IO 会比其他 IO 慢。读之前不需要使用 CEPH 的经验但最好熟悉 Linux 分区、网卡聚合和常用文件系统操作。2. 块存储、RBD 与 Ceph 核心组件的对应关系2.1 四个核心组件里块存储真正需要的是哪两个Ceph 集群常被概括成四个组件MonitorMON、OSD、MDS、RGW。MON 维护集群映射、选举主节点并负责认证客户端读写数据之前必须先联系 MONOSD 负责把副本保存到物理盘上是容量与吞吐的主力MDS 只服务于 CephFS 文件系统RGW 对外提供 S3 兼容的对象存储接口。把组件的职责边界先划清楚后面规划资源才不会被「全组件都要部署」的惯性带偏。组件是否必需主要职责常见部署数量MON必需维护集群映射、选举主节点、提供认证3 或 5OSD必需保存数据副本、响应客户端读写三节点各 1 个以上MDSRBD 不需要管理 CephFS 元数据块存储场景可不部署RGWRBD 不需要提供对象存储网关块存储场景可不部署只靠 MON OSD 这一结论直接影响规划思路不需要为 MDS 预留内存不需要开 RGW 缓存集群资源可以全部压到 OSD 上。生产环境 MON 建议部署奇数个并分散在不同故障域OSD 数量决定总容量与冗余能力。例如 9 块 8TB 盘、副本数 3 的集群总空间是 9×872TB扣除副本后可用容量约 24TB还要再预留 10% 给 PG 迁移和后台均衡实际可用在 20TB 出头。忘记这 10% 余量的集群会在容量接近 85% 时出现明显 IO 抖动这是许多存储事故的起点。2.2 RBD 是把分布式存储伪装成一块普通磁盘RADOS Block DeviceRBD是 Ceph 的块存储接口。它把多个 OSD 上的对象抽象成一个连续块设备客户端通过内核模块 rbd 或用户态 librbd 访问看到的就是「一块硬盘」。RBD 和本地盘最大的差异是数据被切碎后散落在多台机器上每次读写都要经过网络因此网络质量对延迟的影响往往超过磁盘本身的顺序写速度。理解这一点对调参帮助很大客户端与 OSD、OSD 与 OSD 之间的带宽决定块设备吞吐上限从万兆降到千兆顺序 IO 可能下跌 80% 以上。RBD 默认关闭写回缓存写操作要等副本全部落盘才返回这是它在掉电后仍能保证不丢数据的根本原因也是机械盘上随机写延迟偏高的来源。看到 RBD IO 慢先不要怀疑磁盘健康先查网络队列和网卡中断是否均匀分配。2.3 PG、副本策略与 CRUSH 决定数据到底在哪块盘RBD 映像在 Ceph 内部不连续存储而是按对象大小切成对象再由 CRUSH 算法把每个对象映射到一组 OSD。放置组 PG 是对象到 OSD 之间的中间聚合层它让对象不需要单独记录位置只要知道属于哪个 PG、PG 落在哪些 OSD 上就能定位数据。副本数由 pool 的 size 和 min_size 控制size3 表示三副本min_size2 表示最少两副本在线才能接受写入。ceph osd pool create rbd 128 128 replicated ceph osd pool set rbd size 3 ceph osd pool set rbd min_size 2第一行创建名为 rbd、PG 数为 128 的复制型存储池第三、四行把副本策略设为三副本并允许两副本时保持写入。PG 数不能拍脑袋单节点实验环境用 32三节点每节点三块盘的测试集群取 128生产建议把 PG 数设为 OSD 总数与每 OSD 期望 PG 数的乘积再就近靠 2 的幂。PG 太多会让 OSD 内存占用升高太少则数据分布不均某些盘可能比其他盘多出 30% 负载。存储池准备好以后数据最终落盘由 CRUSH 规则决定。规则按主机、机架、机房划分故障域副本会尽量分开例如三副本默认拒绝把三个副本都放到同一台物理机上。部署时如果用了错误的 CRUSH 规则会看到集群状态健康但某台机器故障时所有 PG 同时失去副本这是比容量估算更隐蔽的风险。3. 用 cephadm 从头部署三节点 Ceph 集群3.1 部署前的网络、磁盘与内核参数规划Ceph 部署失败的最大来源不在命令难度而在前置规划。生产环境建议公共网络与集群网络分离公共网络承载客户端到 MON/OSD 的读写集群网络承载 OSD 之间的副本同步、数据再均衡和心跳两者用独立网卡万兆起步。三节点测试环境至少要把 IP 分开再把cluster_network指向独立网段否则副本流量会挤占客户端 IO 带宽表现就是 RBD 吞吐正常但延迟飘高。规划项建议值说明系统盘100GB 以上安装操作系统与容器运行时OSD 数据盘每 OSD 独立整盘不分区避免与系统共享 IO公共网络万兆客户端挂载、Dashboard 访问集群网络万兆副本同步、恢复、心跳内存每 OSD 4GB 以上MON 单独 2GBOSD 尽量多于 4GB内核参数vm.swappiness10降低 swap 造成 IO 抖动cephadm 以容器方式拉起 MON、OSD、MGR 等守护进程宿主机只需要 Docker 或 Podman。没有外网镜像源的内网机房提前把 cephadm 所需的容器镜像导出到内部 registry再在 bootstrap 时指向内部仓库就是日常说的离线安装测试环境里能省掉大量拉取超时等待。还有一个容易被忽略的参数osd_memory_target默认随总内存自动收敛多 OSD 场景要确认它不会超过主机物理内存一半否则多个 OSD 挤在一台机器上会互相抢缓存延迟反而上升。3.2 cephadm bootstrap 初始化集群的最小命令序列先在每台主机写清 /etc/hosts配好 SSH 免密然后选中第一个节点执行 bootstrap。下面命令以 root 身份运行会在当前节点创建 MON、MGR 和辅助组件并输出 Dashboard 访问地址和初始密码。cephadm bootstrap --mon-ip 192.168.1.10 --cluster-network 192.168.2.0/24 ceph orch host add node1 192.168.1.10 ceph orch host add node2 192.168.1.11 ceph orch host add node3 192.168.1.12 ceph orch apply mon node1,node2,node3--mon-ip指定当前节点对外提供 MON 服务的 IP--cluster-network把副本流量引到独立网段。后面四条命令把另外两个节点加进集群并把 MON 扩展到三台。bootstrap 完成后先执行ceph -s看到HEALTH_OK再继续否则后续所有操作都会在一个异常集群上反复报错排查成本远比停下来修复高。OSD 加入有两种方式人工指定磁盘或用过滤器批量识别。三节点测试环境人工指定更可控我一般会这么做ceph orch apply osd all-available-devices --unmanagedtrue ceph orch device zap node1 /dev/sdb --force ceph orch device zap node2 /dev/sdb --force ceph orch daemon add osd node1:/dev/sdb ceph orch daemon add osd node2:/dev/sdb ceph orch daemon add osd node3:/dev/sdb--unmanagedtrue让 cephadm 只识别磁盘不自动创建防止它把系统盘或还在使用的数据盘当成空盘加进集群。device zap会擦除整个磁盘并重写分区表执行前必须核对主机名和盘符这个操作不可逆。每台机器只放一个 OSD 时副本会跨主机分布单机故障后的数据恢复依赖剩余两台主机的带宽因此生产环境不要用双节点至少三节点起步。3.3 创建块存储专属存储池并验证副本策略集群健康后创建块存储池并固定副本策略。pool 名、PG 数、副本数这三个参数是后续所有 RBD 操作的前提一旦改错客户端挂载会立即报集群不健康。ceph osd pool create rbd 128 128 rbd pool init rbd ceph osd pool set rbd size 3 ceph osd pool set rbd min_size 2 ceph osd pool application enable rbd rbdrbd pool init在池内生成 rbd 元数据对象没有这一步之后创建 RBD 映像会报 pool 未初始化application enable rbd rbd告知集群这个 pool 承载 RBD 设备让 Dashboard 能识别其类型。创建完成后用ceph osd pool ls detail检查 size、min_size 和 pg_num确认 PG 状态为activeclean。如果长时间处于creating或peering先确认所有 OSD 的时钟偏移再查集群网络是否存在丢包这两个原因占了 PG 卡住的大多数情况。4. 把 RBD 映像挂进主机、虚拟机和容器4.1 创建 RBD 映像并用内核模块映射成块设备块存储池就绪后第一步创建映像并映射到客户端主机。以下命令在客户端执行使用集群管理员 keyring 认证。rbd create image1 --size 10240 --pool rbd rbd feature disable rbd/image1 object-map fast-diff deep-flatten rbd map rbd/image1 mkfs.xfs /dev/rbd0 mkdir /data mount /dev/rbd0 /data--size单位是 MB10240 表示 10GB。第二行关闭与旧内核存在兼容问题的三个 feature这是内核模块映射时最常见的失败原因。rbd map成功后客户端会出现 /dev/rbd0后面就是普通块设备流程mkfs.xfs、mount、挂载使用。若 map 报 Permission denied把集群节点的/etc/ceph/ceph.client.admin.keyring复制到客户端并确认文件权限为 600。命令作用常用参数rbd create创建映像--sizeMB、--pool、--image-featurerbd map内核映射默认读取 /etc/ceph 配置rbd snap create创建快照pool/imagesnap命名rbd clone生成可写副本指定源快照与目标名内核映射方案适合裸金属业务或容器主机。容器场景里客户端主机的 rbd 模块如果加载不出来可以退一步通过 rbd-nbd 访问性能低于内核模块但可用性更好所以能切内核优先切内核。4.2 在 KVM 环境中把 RBD 作为虚拟磁盘裸金属主机用内核虚拟化环境更推荐让 QEMU 直接通过 librbd 访问 RBDIO 路径不经过宿主机文件系统性能与稳定性都更好。libvirt 虚拟机 XML 中把 disk type 设为 network、protocol 设为 rbd或在运行中执行virsh attach-disk vm1 rbd:rbd/image1 /dev/vda --driver qemu --targetbus virtio这条命令把rbd:rbd/image1作为 virtio 磁盘挂给虚拟机源地址写法是rbd:pool名称/映像名称。生产环境建议把 MON 地址写全例如rbd:rbd/image1:mon_host192.168.1.10:6789,192.168.1.11:6789否则客户端只连一个 MON该节点重启时重连时间会明显变长。宿主机需要提前安装qemu-block-rbd对应的 librbd 组件否则 libvirt 报 driver 不存在。本地文件虚拟磁盘的快照把镜像写入同一目录管理零散、故障恢复也麻烦RBD 把快照、克隆都放在集群侧容量调度以 pool 为边界扩容时不需要迁移虚拟机文件这是私有云把 Ceph 块存储系统当作 KVM 默认后端的原因之一。4.3 快照、克隆与回滚的日常维护RBD 快照是时间点级别的只读镜像升级系统或安装软件前打一个快照出事快速回退。快照本身不占容量只有写新数据产生差异时才累积空间占用。rbd snap create rbd/image1pre-upgrade rbd snap protect rbd/image1pre-upgrade rbd clone rbd/image1pre-upgrade rbd/image1-temp rbd flatten rbd/image1-tempsnap protect将快照置于保护状态因为 clone 要求源快照不可删除rbd clone基于快照生成可写副本rbd flatten去掉副本与快照的依赖让数据独立落盘。非保护快照可以直接用rbd snap rm删除受保护快照必须先用rbd snap unprotect解除保护。执行rbd snap rollback前最好先卸载对应设备滚回旧快照会覆盖当前写入数据虚拟机场景里先停机再操作避免文件系统不一致。5. Ceph 上线前必调的参数与一次典型卡顿排查5.1 客户端缓存与恢复流量的取舍RBD 内核模块默认关闭写回缓存数据库场景下安全但测试和一般应用场景延迟偏高。打开缓存echo 1 /sys/module/rbd/parameters/rbd_cache ceph config set osd osd_max_backfills 2 ceph config set osd osd_recovery_max_active 3第一行打开内核模块写缓存把顺序写延迟压低一个量级代价是主机掉电可能丢少量未落盘数据。第二、三行控制坏盘后的恢复速度osd_max_backfills调大恢复快但会挤占业务 IO生产环境保持在 2 或 3 更稳。更稳妥的做法是用定时任务在业务低峰期调高恢复参数白天恢复为 0避免大半夜被恢复任务拖垮整条链路。5.2 用 prometheus 指标判断瓶颈在哪一端Ceph 自带 prometheus exporter开启 mgr prometheus 模块后从 9283 端口抓取数据配合 prometheus 监控部署与 Grafana很快能看到节点级延迟与 PG 状态。重点看ceph_pg_degraded与ceph_osd_utilization两个指标前者非零先处理 PG不要调客户端参数后者超过 0.85 说明容量接近上限需要扩充 OSD 而不是排查延迟。ceph_rbd_read_latency偏高但前两个指标正常问题多半在网络或客户端优先排查网卡多队列与中断绑定。5.3 卡在 activeundersized 时的单步验证PG 状态出现activeundersized说明副本数不足。按顺序执行ceph osd tree ceph pg dump | grep stuck ceph osd safe-to-destroy osd_idceph osd tree定位掉线 OSDceph pg dump | grep stuck输出长时间卡住的 PG把 pgid 与失败 OSD 对上最后一条命令判断下线盘是否能直接移除。返回 safe 就换盘返回 not safe 说明该 OSD 上仍有数据未完成复制等集群补完副本后再操作。整个过程不需要重启客户端集群会自动进入恢复流程期间 IO 抖动属于正常现象先核对 OSD 日志确认是硬件故障还是网络抖动再决定是否人工介入。本文还有配套的精品资源点击获取