简介这份PDF文档面向具备一定存储架构经验的云服务管理人员及开源分布式存储爱好者系统讲解Ceph块存储的部署与应用。内容以三节点实验集群为背景在Ubuntu 18.04环境下完成RBD池创建、块设备镜像管理、镜像映射至Linux块设备、格式化挂载及集群健康检查等完整流程并给出具体命令示范帮助读者掌握搭建稳定Ceph集群的能力为虚拟化环境提供高效块存储方案。资源包共1个PDF文件大小约286KB内容紧凑、步骤清晰适合按章节对照实操。目前已有70人学习。读者可从中获得从集群规划、存储池与镜像操作到映射读写、状态监控的完整操作链路并理解基础部署方式与后续参数调整、高级特性研究的衔接思路适合作为Ceph块存储入门的实战参考。1. CEPH 块存储到底解决什么问题从三副本到 RBD 的落地判断很多团队第一次接触 CEPH都是被“统一分布式存储”这句话吸引进来的一套集群同时提供块、文件、对象三种接口看起来能把机房里的存储孤岛一次性收编。但真正落地时绝大多数业务只需要其中一种——块存储。虚拟机要盘、数据库要盘、K8s 的 PVC 要盘这些场景要的是 RBDRADOS Block Device而不是 CEPHFS 或 RGW。所以这篇实战指南只聚焦一件事把 CEPH 的块存储从零部署起来接到真实业务上并且知道它在什么边界内可靠、什么情况下会翻车。CEPH 块存储的核心价值在于数据以固定大小对象的形式打散到整个集群通过 CRUSH 算法决定落盘位置靠多副本或纠删码保证冗余靠 PGPlacement Group做归置单元。你不需要 RAID 卡不需要双控阵列一台普通 x86 服务器加几块盘就能组成一个可横向扩展的存储池。代价是网络要求高、调优参数多、故障域规划不好会埋雷。适合有 3 台以上同构服务器、能接受运维复杂度的团队如果只有两台机器或者对延迟极度敏感的交易库我一般会劝退直接上本地 NVMe 或传统阵列更省心。2. 部署前的硬件与拓扑决策别让第一块盘就选错2.1 节点角色与最小规模CEPH 集群里节点分三类角色MONMonitor维护集群地图、MGRManager提供监控和管理接口、OSDObject Storage Daemon真正存数据的进程。生产环境最小可用规模是 3 台物理机每台同时跑 MON MGR OSD。为什么是 3 台因为 MON 需要多数派仲裁3 个 MON 允许挂 1 个2 个 MON 挂 1 个就整个集群只读。少于 3 台不是不能跑而是没有容错余量只适合实验室。网络方面我强烈建议至少两张网卡一张 public network 跑客户端和 MON/MGR 通信一张 cluster network 跑 OSD 之间的数据复制。如果只有一张网复制流量和业务流量抢带宽延迟抖动会非常明显。万兆起步25G 更好。千兆网跑 CEPH 块存储在并发写入场景下基本等于自残。2.2 磁盘选型HDD、SSD 还是 NVMe块存储对 IOPS 敏感尤其是数据库和虚拟机场景。常见做法是OSD 数据盘用 SSD 或 NVMeWAL/DB 单独放在更快的 NVMe 上。如果预算有限可以用 HDD 做容量池、SSD 做缓存池但不要指望 HDD 池能扛住随机写。盘类型适用场景单 OSD 建议备注HDD 7200转冷数据、备份、大容量块4TB~16TB随机 IOPS 低必须配 SSD 做 DBSATA SSD通用虚拟机、中等负载1TB~4TB性价比高注意 DWPDNVMe数据库、高并发块存储1TB~8TB延迟低但要注意散热和 PCIe 通道注意不要用 RAID 卡把多块盘做成 RAID0 再给 CEPHCEPH 自己管副本RAID 只会增加故障域和写放大。直通模式HBA/JBOD才是正确姿势。2.3 操作系统与基础环境准备我一般用 Ubuntu 22.04 LTS 或 CentOS Stream 9。部署前每台机器要做的事设置主机名、配置 hosts 解析、关闭 swap、调整内核参数、同步时间。下面是一段可复用的初始化脚本在每台节点上执行。# 设置主机名按节点角色命名例如 ceph-node1 hostnamectl set-hostname ceph-node1 # 写入 hosts三台互相解析 cat /etc/hosts EOF 192.168.10.11 ceph-node1 192.168.10.12 ceph-node2 192.168.10.13 ceph-node3 EOF # 关闭 swapCEPH OSD 对内存延迟敏感 swapoff -a sed -i /swap/s/^/#/ /etc/fstab # 调整内核参数增大文件句柄和网络缓冲区 cat /etc/sysctl.conf EOF fs.file-max 1048576 net.core.rmem_max 16777216 net.core.wmem_max 16777216 net.ipv4.tcp_rmem 4096 87380 16777216 net.ipv4.tcp_wmem 4096 65536 16777216 vm.swappiness 0 EOF sysctl -p # 时间同步CEPH 对时钟偏移敏感 apt install -y chrony systemctl enable --now chrony这段脚本做了四件事主机名和 hosts 保证节点间能按名字通信关闭 swap 避免 OSD 进程被换出导致心跳超时内核参数提升网络吞吐和文件句柄上限chrony 保证 MON 仲裁不受时钟漂移影响。参数里vm.swappiness0是血泪经验默认值 60 会让 OSD 在内存压力下频繁换页表现为集群间歇性卡顿。3. 用 cephadm 部署集群从引导到 OSD 上线3.1 安装 cephadm 与引导第一个 MON从 Nautilus 之后官方主推 cephadm 部署方式基于容器运行所有守护进程。相比老旧的 ceph-deploycephadm 的升级、扩缩容、证书管理都更顺。下面在第一台节点上操作。# 安装 cephadm以 Ubuntu 22.04 为例 apt update apt install -y cephadm # 引导集群指定第一台 MON 的 IP 和网段 cephadm bootstrap \ --mon-ip 192.168.10.11 \ --initial-dashboard-user admin \ --initial-dashboard-password Ceph2024 \ --dashboard-password-noupdate # 引导完成后会输出 dashboard 地址和 ceph 命令的使用方式 # 把 admin 密钥拷贝出来后续节点需要 ceph config generate-minimal-conf /etc/ceph/ceph.conf--mon-ip必须是第一台节点的固定 IP不能写 127.0.0.1。--initial-dashboard-password设置 Web 控制台密码生产环境务必改掉默认值。引导成功后当前节点会自动跑起一个 MON 和一个 MGR。用ceph -s能看到集群状态此时 HEALTH 会提示MON_DISK_LOW或OSD_COUNT之类的告警属于正常因为还没加 OSD。3.2 把其他节点加入集群在第二、第三台节点上安装 cephadm然后回到第一台执行加入命令。cephadm 通过 SSH 分发公钥和配置。# 在第一台节点上把公钥推给其他节点 ssh-copy-id rootceph-node2 ssh-copy-id rootceph-node3 # 添加节点到集群 ceph orch host add ceph-node2 192.168.10.12 ceph orch host add ceph-node3 192.168.10.13 # 给节点打标签方便按角色调度 ceph orch host label add ceph-node1 mon,mgr,osd ceph orch host label add ceph-node2 mon,mgr,osd ceph orch host label add ceph-node3 mon,mgr,osd # 查看节点列表 ceph orch host ls加入节点后cephadm 会自动在新节点上部署 MON 和 MGR如果标签匹配。用ceph orch ps可以看到所有守护进程状态。如果某个节点一直显示offline先检查 SSH 是否免密、防火墙是否放行 6789/3300/6800-7300 端口。3.3 添加 OSD让磁盘真正开始存数据OSD 是 CEPH 的存储单元一块盘对应一个 OSD。cephadm 支持自动发现可用磁盘并批量创建。# 查看所有节点上可用的磁盘 ceph orch device ls # 自动创建 OSD只使用未挂载、无分区的裸盘 ceph orch apply osd --all-available-devices # 或者手动指定某块盘创建 OSD ceph orch daemon add osd ceph-node1:/dev/sdb # 查看 OSD 树和状态 ceph osd tree ceph osd df--all-available-devices会扫描所有节点上满足条件的盘自动创建 OSD。条件是盘没有被挂载、没有分区、没有文件系统。如果你有系统盘和数据盘混在一起务必先确认盘符否则可能把系统盘吃掉。我一般会先lsblk人工核对一遍再执行自动创建。ceph osd df能看到每个 OSD 的容量、使用率和 PG 分布如果某个 OSD 使用率明显高于其他说明 CRUSH 权重没调好。3.4 创建块存储池与 RBD 镜像OSD 上线后默认会有一个rbd池但生产环境我建议按业务单独建池方便做配额和权限隔离。# 创建三副本池pg_num 根据 OSD 数量调整 ceph osd pool create k8s-pool 128 128 # 设置副本数为 3 ceph osd pool set k8s-pool size 3 ceph osd pool set k8s-pool min_size 2 # 启用 RBD 应用模式 ceph osd pool application enable k8s-pool rbd # 创建 RBD 镜像大小 100G rbd create k8s-pool/vm-disk-01 --size 100G # 查看镜像信息 rbd info k8s-pool/vm-disk-01pg_num的设置有个经验公式(OSD 总数 * 100) / 副本数然后向上取到 2 的幂。比如 12 个 OSD、三副本就是 400取 512。PG 太少会导致数据分布不均太多会增加 MON 内存开销。min_size 2表示至少两个副本在线才允许写入避免脑裂时数据不一致。创建完镜像后可以用rbd map映射成块设备格式化后挂载使用。4. 块存储接入业务RBD 映射、K8s PVC 与性能验证4.1 在物理机上映射 RBD 块设备最直接的用法是把 RBD 镜像映射成本地块设备然后格式化挂载。# 映射镜像到本地内核模块会自动加载 rbd map k8s-pool/vm-disk-01 # 查看映射结果通常为 /dev/rbd0 rbd showmapped # 格式化并挂载 mkfs.xfs /dev/rbd0 mkdir -p /mnt/rbd-data mount /dev/rbd0 /mnt/rbd-data # 写入测试数据 dd if/dev/zero of/mnt/rbd-data/testfile bs1M count1024 oflagdirectoflagdirect绕过页缓存测的是真实落盘性能。如果顺序写只有几十 MB/s先查网络是不是千兆再查 OSD 是否都在同一块盘上。rbd map依赖内核 RBD 模块如果报modprobe: module rbd not found需要安装linux-modules-extra或对应内核包。4.2 对接 KubernetesStorageClass 与 PVCK8s 场景下CEPH RBD 通过 CSI 驱动接入。常见做法是部署ceph-csi然后创建 StorageClass。apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: ceph-rbd provisioner: rbd.csi.ceph.com parameters: clusterID: ceph-cluster pool: k8s-pool imageFeatures: layering csi.storage.k8s.io/provisioner-secret-name: ceph-secret csi.storage.k8s.io/provisioner-secret-namespace: ceph-csi csi.storage.k8s.io/node-stage-secret-name: ceph-secret csi.storage.k8s.io/node-stage-secret-namespace: ceph-csi reclaimPolicy: Delete allowVolumeExpansion: trueclusterID要和 ceph-csi 配置里的一致pool填前面创建的池名。allowVolumeExpansion: true允许在线扩容 PVC但底层 RBD 镜像扩容后还需要在 Pod 内扩展文件系统。创建 PVC 后如果一直 Pending先看 ceph-csi 的 provisioner pod 日志常见原因是 secret 里的 key 权限不对或者 pool 没有启用 rbd 应用。4.3 用 fio 验证块存储真实性能部署完不测性能等于没部署。我一般用 fio 做三组测试4K 随机写、4K 随机读、1M 顺序写。# 4K 随机写模拟数据库负载 fio --namerandwrite --ioenginelibaio --direct1 \ --bs4k --size2G --numjobs4 --rwrandwrite \ --runtime60 --group_reporting --filename/mnt/rbd-data/fio-test # 4K 随机读 fio --namerandread --ioenginelibaio --direct1 \ --bs4k --size2G --numjobs4 --rwrandread \ --runtime60 --group_reporting --filename/mnt/rbd-data/fio-test # 1M 顺序写 fio --nameseqwrite --ioenginelibaio --direct1 \ --bs1M --size4G --numjobs1 --rwwrite \ --runtime60 --group_reporting --filename/mnt/rbd-data/fio-test重点看iops和lat延迟。三副本 SSD 池4K 随机写通常能到几千到上万 IOPS延迟在几毫秒以内。如果 IOPS 只有几百检查numjobs是否太小、网络是否丢包、OSD 是否用了 HDD。--direct1必须加否则测的是缓存。测试完记得删除测试文件避免占满池。5. 避坑与排查CEPH 块存储最常见的五个翻车现场5.1 HEALTH_ERR: PG 一直 activeundersizeddegraded现象ceph -s显示 PG 状态异常写入变慢甚至阻塞。原因某个 OSD 掉线副本数不足PG 处于降级状态。如果min_size设成 2而只剩 1 个副本写入会被拒绝。解决先ceph osd tree找到 down 的 OSD检查磁盘是否故障、进程是否崩溃。如果是临时重启等 OSD 重新上线后 PG 会自动恢复。如果磁盘彻底坏了用ceph osd out id把它踢出集群等数据回填完再更换磁盘。5.2 OSD 创建后使用率严重不均现象ceph osd df里某些 OSD 使用率 80%另一些只有 20%。原因CRUSH 权重默认按磁盘容量算但如果盘的实际可用空间和标称差距大或者 PG 数太少分布就会倾斜。解决先确认pg_num是否足够按公式重新计算并调整。如果 PG 数没问题用ceph osd reweight手动微调权重把高使用率的 OSD 权重调低。调整后数据会重新平衡但这个过程会占用网络带宽建议在业务低峰期做。5.3 RBD 映射后写入速度极慢现象dd测试只有几十 MB/s但网络和磁盘看起来都正常。原因常见有三种——客户端没启用rbd cache、OSD 的journal和data在同一块慢盘上、网络走了千兆。解决在ceph.conf的[client]段加rbd cache true和rbd cache writethrough until flush true。检查 OSD 是否把 DB/WAL 放在 NVMe 上如果没有考虑重建 OSD 并指定--data和--db设备。网络用iperf3实测带宽低于 900Mbps 就换万兆。5.4 MON 仲裁失败导致集群只读现象ceph -s卡住提示monclient: hunting for new mon。原因3 个 MON 挂了 2 个或者 MON 之间网络不通、时钟偏移过大。解决先恢复网络和时钟同步然后逐个重启 MON 进程。如果 MON 数据损坏需要用ceph-mon --extract-monmap从健康 MON 上恢复。预防措施MON 节点不要和 OSD 混部在高负载机器上时钟同步必须严格。5.5 K8s PVC 扩容后 Pod 内空间没变现象PVC 改了大小kubectl get pvc显示新容量但 Pod 里df -h还是旧值。原因CSI 只扩容了 RBD 镜像文件系统没有扩展。解决进入 Pod 执行resize2fsext4或xfs_growfsxfs。如果是 xfs必须挂载点在线才能扩。更省事的做法是在 StorageClass 里配置csi.storage.k8s.io/fstype: ext4并确保 CSI 驱动支持在线扩容。6. 进阶技巧用 crush rule 把块存储池钉在指定故障域集群规模上去之后默认的 CRUSH 规则会把副本撒到所有 OSD 上。但块存储往往有冷热分层需求数据库池要全 SSD备份池可以混 HDD。这时候就要自定义 CRUSH rule把池绑定到指定设备类。# 给 SSD 和 HDD 分别打上设备类 ceph osd crush set-device-class ssd osd.0 osd.1 osd.2 ceph osd crush set-device-class hdd osd.3 osd.4 osd.5 # 创建针对 SSD 的 crush rule ceph osd crush rule create-replicated ssd-rule default host ssd # 把池应用到该规则 ceph osd pool set k8s-pool crush_rule ssd-rule # 验证池的 CRUSH 规则 ceph osd pool get k8s-pool crush_rulecreate-replicated的参数依次是规则名、根default、故障域类型host、设备类ssd。故障域选host表示同一主机的 OSD 不会同时持有同一 PG 的两个副本这是生产环境的最低要求。如果机房有多排机架可以把故障域提升到rack但需要先定义 bucket 层级。验证方法用ceph osd upmap或ceph pg map pgid查看某个 PG 的副本落在哪些 OSD 上确认都在 SSD 设备类里。如果发现副本跑到了 HDD说明规则没生效检查池是否真的绑定了ssd-rule以及 OSD 的设备类是否打对。我自己的习惯是任何池创建后先ceph osd pool get pool all把参数全部打印一遍确认size、min_size、crush_rule、pg_num四个值符合预期再接入业务。这个动作花不了一分钟但能避免后面半夜被叫起来处理数据分布问题。希望帮到你。本文还有配套的精品资源点击获取