CephFS 与 RBD 安装部署及验证从裸磁盘到块存储和文件系统的完整实操大概三个月前我接到一个需求给一套业务系统搭建底层统一存储底座既要提供可挂载的 POSIX 文件系统跑日志、做归档又要提供块存储给虚拟机做系统盘和数据盘。技术选型绕不开 Ceph具体落地上就是 CephFS 和 RBD 两件事。网上讲 RBD 部署的文章不少讲 CephFS 的也不少但把两者放在同一套集群里从零部署、一直做到端到端验证的完整流程能一站式讲清楚的并不多。这篇文章就把这次实操完整记录下来包含集群规划、组件安装、RBD 创建与映射、CephFS 创建与挂载、数据完整性验证、踩坑实录适合刚接触 Ceph 的运维新手也适合想系统梳理一遍部署流程的同行参考。1. 部署方案设计与集群规划1.1 为什么把 CephFS 和 RBD 放在同一套集群Ceph 本身是一套统一的分布式存储系统底层数据面由 OSDObject Storage Daemon负责持久化对象数据RBDRADOS Block Device和 CephFS 都构建在这层对象存储之上。就好比一栋楼的地基、给排水和电路都是同一套基础设施不同住户买不同的户型图——RBD 是面对块设备的“现浇户型”CephFS 是面对文件的“精装户型”。把两者放在同一套集群里最大的好处是物理资源池化、运维口径统一。你不需要为文件存储单独部署一套集群、为块存储再单独部署一套集群只需要在同一个 RADOS 层划分不同的存储池Pool用不同的数据面组件MDS 服务 CephFSlibrbd 服务 RBD去承载各自协议。从副本策略、故障域、性能调优的角度看管理一套集群的成本远低于管理两套集群。实践中常见做法是RBD 池配置较高的 PG 数量和高性能存储介质NVMe/SSD承载数据库、虚拟机磁盘CephFS 池配置中低延迟的存储池承载日志、媒体文件、大数据作业的中间结果。两者隔离在同一套物理集群上扩展时一起加 OSD 即可。1.2 集群架构与版本选型本次部署用了三台物理机/虚拟机组成的集群角色规划如下节点角色配置说明ceph-node1mon, mgr, osd, mds系统盘 50GB数据盘 3 块 1TBceph-node2mon, mgr, osd, mds系统盘 50GB数据盘 3 块 1TBceph-node3mon, mgr, osd, mds系统盘 50GB数据盘 3 块 1TB注本次为验证环境所以 MON/MGR/MDS/OSD 混部在同一批节点上。生产环境建议 MON 独立部署或至少分散在不同机柜 / 故障域MDS 建议配置 standby 保证可用性。版本选型上我选择了Ceph Quincy17.2.x。相比 Octopus15.2.x和 Pacific16.2.xQuincy 在 NFS 导出、RBD 性能、CephFS 快照与性能诊断方面均有不少改进且发布已有一段时间软件源与社区反馈都比较稳定。如果你所在的团队还在用 Pacific本文绝大部分命令同样适用但部分新特性如cephfs top会不可用。操作系统使用 CentOS 7.9内核 3.10 或升级后的 5.4 LTS 内核。这里要特别强调一个点RBD 内核模块对内核版本比较敏感如果你要用内核态挂载 RBDrbd device mapCentOS 7 自带内核里的 RBD 模块较老建议升级到 5.4 或 4.19 的长期维护内核如果不愿意动内核走rbd-nbd方式挂载也是稳定方案后面会详细讲。1.3 关键组件职责梳理部署 CephFS 和 RBD本质上需要四类守护进程协同工作MONMonitor维护集群 Map 状态MON Map、OSD Map、PG Map、MGR Map 等是整个集群的“大脑”。MON 挂了、集群就没有可用状态可用了。MGRManager承担监控、状态展示、均衡、编排等辅助职责。Quincy 中大量命令如ceph df、ceph osd pool ls依赖 MGR 提供数据。OSDObject Storage Daemon存储数据的核心组件通常一个磁盘对应一个 OSD。数据以对象形式存在于 OSD 上通过 CRUSH 算法决定放置位置和冗余方式。MDSMetadata ServerCephFS 专属组件保存文件系统的元数据目录结构、文件名、权限、时间戳等并管理元数据的缓存和一致性。MDS 不保存文件内容本身只保存“地图”和“索引”。RBD 不需要单独的守护进程它是客户端通过librbd与 RADOS 集群直接交互将块设备拆分成对象默认对象大小 4MB存储到对应 pool 中。因此验证 RBD 是否需要单独部署服务端组件不需要但需要确认内核或 librbd 客户端的支持。2. 基础环境准备与 Ceph 集群搭建2.1 系统初始化与环境检查开始部署前先做一轮系统基础配置。这步容易被赶进度的人跳过但后面很多“怪问题”都源于基础环境没准备好。主机名与 hosts 解析三台机器设置固定主机名并确保/etc/hosts中互相能解析到 IP。Ceph 集群内部通信大量依赖主机名不能只靠 IP。时间同步Ceph 对时钟偏差极其敏感MON 之间的时钟偏差超过阈值默认 0.05 秒会直接导致时钟不同步告警。建议统一配置 chrony 或 ntpd指向公司内网时间服务器。内核参数vm.swappiness调整为 10 以内避免系统过多交换内存页导致 Ceph 性能抖动net.ipv4.tcp_tw_reuse打开net.core.somaxconn调大避免高并发下的网络连接排队。防火墙与 SELinux测试环境直接关闭生产环境建议按端口策略放行。Ceph OSD 通信端口通常使用 6800-7300 范围MON 使用 6789 端口。做完这些用hostnamectl、chronyc tracking等命令快速确认状态再进入下一步。2.2 使用 cephadm 部署集群二〇二二年之后的 Ceph 版本官方主推的部署工具是cephadm。它基于容器方式运行各守护进程通过cephadm bootstrap引导首个 MON然后通过ceph orch流程化管理主机、OSD、MDS 等组件。相比老牌的 ceph-ansible 或手动 rpm 安装cephadm 在部署体验和组件管理上更现代。安装基本依赖和 cephadmyum install -y python3 python3-pip curl --silent --remote-name --location https://github.com/ceph/ceph/raw/quincy/src/cephadm/cephadm chmod x cephadm ./cephadm add-repo --release quincy ./cephadm install然后在首个节点上执行 bootstrap。bootstrap 会生成/etc/ceph/ceph.conf和ceph.client.admin.keyring同时生成一个外网访问用的 dashboard 地址。cephadm bootstrap --mon-ip 10.10.1.11 --cluster-network 10.10.2.0/24 --public-network 10.10.1.0/24参数说明--mon-ip指定第一个 MON 的 IP--cluster-network指 OSD 之间数据复制、心跳等内部通信使用的网络段--public-network指客户端访问集群使用的网络段。生产环境强烈建议将客户端网络和集群网络分离避免副本复制流量与业务读写流量互相挤占带宽。bootstrap 完成后把另外两个节点加进集群cephadm shell -- ceph orch host add ceph-node2 10.10.1.12 cephadm shell -- ceph orch host add ceph-node3 10.10.1.13再在每台节点上执行ceph cephadm get-pub-key /root/.ssh/ceph.pub并把公钥加入对端节点authorized_keys接着用ceph orch apply osd --all-available-devices自动发现并激活所有未使用的磁盘作为 OSD。我用lsblk确认三块数据盘已经就位执行上述命令后通过ceph -s观察集群状态等待所有 OSD 完成 up 和 in。正常情况下应当看到类似这样的输出cluster: id: 7c3c1b1b-xxxx health: HEALTH_OK services: mon: 3 daemons, quorum ceph-node1,ceph-node2,ceph-node3 mgr: 2 daemons active osd: 9 osds: 9 up, 9 in看到HEALTH_OK且 9 个 OSD 全部 inup说明集群底座已经建好。此时先别急着创建 pool先做一轮延迟和容量预估。2.3 存储池规划与 PG 数量计算PGPlacement Group是 RADOS 层的逻辑分片它决定数据在 OSD 间的分布粒度。PG 数量设置过多会消耗大量内存和 CPU设置过少则容易导致数据分布不均。经验公式是单 OSD 的 PG 数建议在 50~100 之间。本次 9 个 OSD规划为 2 副本存储池那么总 PG 数大约可以取 512。若分为两个池RBD 池 256 个 PGCephFS 的 data 池 256 个 PG整体压力可控。实际创建命令cephadm shell -- ceph osd pool create rbd_pool 256 256 replicated cephadm shell -- ceph osd pool create cephfs_data 256 256 replicated cephadm shell -- ceph osd pool create cephfs_meta 32 32 replicated注意cephfs_meta存放文件系统元数据PG 不需要太大16~64 即可但建议放到独立池中因为元数据的读写模式与小文件 IO 类似与大文件的顺序读写特性差别很大分池后可以差异化调优。CephFS 的 data pool 默认是副本池。如果你想用纠删码EC池承载 CephFS 数据需要额外配置 EC profile且 EC 池对文件系统的写性能通常有一些影响本次验证环境直接用副本池可靠性更简单直接。3. RBD 块设备部署与验证3.1 创建块设备镜像RBD 的使用流程很好理解在 pool 中创建一个块设备镜像然后在客户端映射为本地块设备格式化后就能像普通磁盘一样使用。使用rbd create创建镜像cephadm shell -- rbd create --pool rbd_pool --size 20G test-image这里有几个参数需要特别关注--size镜像的逻辑容量大小可以后续扩容rbd resize但不能随意缩减除非先清理数据。--image-featureRBD 有很多特性layering、exclusive-lock、object-map、fast-diff、deep-flatten、journaling 等。默认 enable 的特性组合在较新内核上均支持但如果你遇到挂载时报feature set mismatch就要检查内核 RBD 模块是否支持这些特性。--image-formatv2 是默认且必要的v1 是老格式不支持克隆、分层等能力。查看镜像信息cephadm shell -- rbd info --pool rbd_pool test-image输出会显示镜像大小、对象大小、特性列表、block_name_prefix 等信息。block_name_prefix决定了这些对象在 RADOS 层的命名前缀排障时经常需要用rados ls对比对象数量来确认数据确实写入到了 OSD 上。3.2 客户端映射内核态 rbd 与 rbd-nbd 两种方案映射就是将 RBD 镜像变成系统中的块设备。Linux 客户端有两种方式方案一内核态 rbd 模块rbd device map --pool rbd_pool --image test-image执行后lsblk可以看到类似/dev/rbd0的设备。这种方式走内核的 RBD 驱动性能较高、IO 路径短但对内核版本有要求。建议内核 5.4 以上再考虑这种方式如果你在 CentOS 7 默认 3.10 内核上直接 map非常容易遇到创建块设备时报rbd: sysfs write failed或failed to create rbd device的问题原因就是旧内核模块缺少对新特性的支持。方案二rbd-nbd 用户态映射rbd-nbd map --pool rbd_pool --image test-imagerbd-nbd 通过内核 NBD 设备把 RBD 镜像暴露为块设备。它不依赖内核 RBD 模块的版本只要 NBD 模块可用即可CentOS 7 默认已加载。稳定性更好、特性兼容性更高代价是相比内核态 RBD 有一层额外的 NBD 协议转换极端高吞吐场景下延迟略增大约 5%~10%但对常规负载完全无感。我在本次验证中先尝试了内核态 rbd map升级内核后一切正常。如果你不想动内核直接用 rbd-nbd 是稳妥的选择。两种方式互斥同一镜像不能同时被两种方式映射容易引发数据不一致问题切换方式前务必先 unmap。3.3 格式化、挂载与文件读写验证映射出/dev/rbd0后完全按本地磁盘来做mkfs.xfs /dev/rbd0 mkdir -p /mnt/rbd-test mount /dev/rbd0 /mnt/rbd-test df -h /mnt/rbd-testXFS 是 Ceph 文档推荐的本地文件系统性能和扩展性优于 ext4生产环境优先选 XFS。写文件验证数据完整性我习惯用ddsha256sum组合做两次对比dd if/dev/urandom of/mnt/rbd-test/testfile bs1M count1024 sha256sum /mnt/rbd-test/testfile /tmp/before_checksum sync # 模拟重新挂载或故障切换 umount /mnt/rbd-test rbd device unmap --pool rbd_pool --image test-image rbd device map --pool rbd_pool --image test-image mount /dev/rbd0 /mnt/rbd-test sha256sum /mnt/rbd-test/testfile /tmp/after_checksum cat /tmp/before_checksum /tmp/after_checksum两侧哈希一致说明数据经过 RADOS 层从客户端写入、重新映射读取全链路正常。这一步不要省略曾经我见过一个环境 map 正常、mkfs 正常、写入也“成功”但读取时 CRC 报错最后排查发现是交换机丢包导致 scrubbing 异常这种隐藏问题只有靠校验和才能暴露。3.4 RBD 快照与克隆验证RBD 的杀手级功能是快照和克隆对镜像打快照后可以从快照快速克隆出新镜像秒级创建一台临时云盘或测试盘。创建快照并克隆cephadm shell -- rbd snap create --pool rbd_pool --image test-image --snap snap-clean cephadm shell -- rbd snap protect --pool rbd_pool --image test-image --snap snap-clean cephadm shell -- rbd clone --pool rbd_pool --image test-image --snap snap-clean --dest-pool rbd_pool --dest-image clone-imagesnap protect和unprotect用来保护快照防止其被意外删除这里在克隆前必须 protect。克隆出来的镜像默认依赖父镜像快照如果你要让克隆镜像完全独立需要执行rbd flatten将数据完整复制到克隆镜像自己的对象中。注意 flatten 会消耗一定的容量和 IO。验证克隆镜像的可读性cephadm shell -- rbd info --pool rbd_pool clone-image看到parent字段说明它还是 COW 克隆状态执行 flatten 后再查看parent 字段消失说明已独立。4. CephFS 文件系统部署与验证4.1 部署 MDS 与创建文件系统在 CephFS 中MDS 是必须的元数据服务进程。在 cephadm 管理的集群中部署 MDS 非常简单cephadm shell -- ceph orch apply mds cephfs-test --placement3这条命令会在集群中启动 3 个 MDS 实例注意它只是启动了进程供后续分配文件系统并不会自动创建一个可用的 CephFS。创建文件系统需要明确指定 data pool 和 metadata poolcephadm shell -- ceph fs new cephfs-test cephfs_meta cephfs_data参数顺序是ceph fs new fs_name metadata_pool data_pool写反了会导致元数据池和数据池错位这是新手最常踩的坑之一。创建后用ceph fs ls确认状态cephadm shell -- ceph fs ls name: cephfs-test, metadata pool: cephfs_meta, data pools: [cephfs_data ]执行ceph fs status可以查看 MDS 的运行状态正常会出现up:active的 MDS 列表。如果需要给 CephFS 扩容数据池可以通过ceph fs add_data_pool动态增加Ceph 支持多数据池文件系统可以做冷热数据分池。4.2 内核态挂载 CephFSCephFS 的挂载方式同样有两种内核态驱动ceph-fuse与mount.ceph和用户态驱动ceph-fuse。内核态驱动的 IO 路径更短、性能更好生产环境优先。内核态挂载命令mkdir -p /mnt/cephfs mount -t ceph ceph-node1:6789,ceph-node2:6789,ceph-node3:6789:/ /mnt/cephfs \ -o nameadmin,secretXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXname和secret来自/etc/ceph/ceph.client.admin.keyring。注意这里的 secret 是 key 字段的值不需要带key前缀。也可以写成 secretfile 的方式避免把密钥直接暴露在命令行历史里。如果你获取密钥不方便用ceph-fuse更省心ceph-fuse -m ceph-node1:6789,ceph-node2:6789,ceph-node3:6789 /mnt/cephfs它会默认从/etc/ceph/ceph.conf读取集群配置和 keyring。用户态挂载的好处是不依赖内核模块版本适合老内核环境或需要细粒度权限控制的场景缺点是吞吐性能和元数据操作延迟略高我实测大概有 10%~15% 的性能差距。4.3 CephFS 目录结构与权限验证挂载成功后ls -l /mnt/cephfs会看到根目录下有一个初始的丢失找回目录。我们创建一个完整的目录树来模拟业务使用mkdir -p /mnt/cephfs/appdata/{logs,archive,tmp} echo hello cephfs /mnt/cephfs/appdata/logs/access.log cat /mnt/cephfs/appdata/logs/access.log用ceph fs subvolumegroup和ceph fs subvolume可以做更精细的租户隔离和配额管理这就是 CephFS 支持多租户文件服务的核心机制。创建子卷组并设置容量配额cephadm shell -- ceph fs subvolumegroup create cephfs-test group1 cephadm shell -- ceph fs subvolume create cephfs-test vol1 group1 --size 10G cephadm shell -- ceph fs subvolume ls cephfs-test group1配额大小在创建时指定后可以调整这是 CephFS 做文件服务时非常有用的能力。RBD 没有文件级配额的概念只能限制整个池的使用量相当于“硬盘大小”的约束粒度而 CephFS 的子卷配额相当于“目录大小”的约束两者结合使用能满足不同业务需求。4.4 文件系统快照验证CephFS 从 Pacific 版本开始支持原生文件系统快照通过.snap目录的形式访问。这是 CephFS 一个常被忽略但非常有价值的功能。默认快照功能不自动启用需要手动开启cephadm shell -- ceph fs snapshot enable cephfs-test启用后在文件系统任何目录下创建快照mkdir /mnt/cephfs/appdata/snapshot-test echo important data /mnt/cephfs/appdata/snapshot-test/data.txt mkdir /mnt/cephfs/appdata/snapshot-test/.snap/backup-2024-01-01 # 此时 .snap/backup-2024-01-01 目录即具备一个快照视图 rm -rf /mnt/cephfs/appdata/snapshot-test/data.txt ls /mnt/cephfs/appdata/snapshot-test/.snap/backup-2024-01-01/你会看到data.txt仍然存在于快照目录中。这个能力对应用自身的备份恢复、防误删非常实用不需要额外部署备份代理直接通过.snap访问历史版本即可。5. 常见问题与排查技巧实录5.1 集群健康状态异常排查部署完成后不是终点运行过程中你会遇到各种各样的健康状态告警。最常遇到的几种PG_AVAILABILITY告警某些 PG 处于 peering 或 degraded 状态通常由 OSD 重启、网络抖动或过大负载引发。查看ceph health detail定位到具体 PG再用ceph pg map pgid查看 PG 落在哪些 OSD 上进一步检查对应 OSD 的状态和日志。PG_DEGRADED长期不恢复可能原因是对应 OSD 上的数据副本不可用比如一块磁盘彻底损坏。先观察ceph osd tree确认 OSD 是否为 down再通过ceph orch ps查看 OSD 容器是否被反复重启。时钟偏差告警ceph health detail会直接提示MON_CLOCK_SKEW。调整 ntp/chrony 配置后通常等待几个时钟同步周期即可恢复。排查顺序我建议固定为先看ceph -s再看ceph health detail最后定位到具体 OSD/MDS 日志。不要一上来就抓日志否则容易淹没在大量 INFO 信息里。5.2 MDS 状态 standby 或 failed 的处理CephFS 的 MDS 出现异常时ceph fs status会看到up:standby-replay或standby状态严重时 MDS 进程可能反复重启。常见原因和操作如下元数据池容量不足或 PG 处于 degradedMDS 写元数据超时文件系统的目录结构损坏MDS 启动时 replay journal 失败客户端异常挂载后不释放MDS 等待客户端回话超时基本处理思路确认底层存储池健康数据面是基础再重启 MDS 服务cephadm shell -- ceph orch restart mds.cephfs-test如果 MDS 始终无法进入 active可以尝试ceph fs reset强制重置文件系统状态。但这条命令非常激进务必确认业务可停机后再执行否则容易造成元数据不一致。5.3 RBD 映射后文件系统无法挂载的原因这是块设备场景下“经典翻车现场”rbd device map成功了、分区看到了、但mount报错。可能原因有两类内核不支持 RBD 镜像的特性组合。表现为 map 成功但后续 IO 阻塞或dmesg报unknown feature。检查rbd info --pool rbd_pool test-image里的 features 字段临时可以用rbd feature disable关闭部分特性如object-map、fast-diff但建议优先升级内核。快照或克隆后的映射状态不对。特别是有多个客户端同时对同一镜像进行 map 时会触发 exclusive-lock 冲突。客户端 A 的 map 会让客户端 B 的设备变成只读或丢失锁。此时客户端 B 上dmesg会看到lost lock相关日志需要正确配置 lock 策略或使用rbd device unmap清理会话。5.4 性能验证与观测工具使用部署完成不代表交付完成我习惯做一轮基础性能压测至少确认顺序写、顺序读、4K 随机读写这几个维度的数据符合预期。测试工具用fiofio -filename/mnt/rbd-test/fiofile -direct1 -iodepth32 -ioenginelibaio -rwwrite -bs4M -size4G -numjobs4 -runtime60 -group_reporting fio -filename/mnt/rbd-test/fiofile -direct1 -iodepth32 -ioenginelibaio -rwread -bs4M -size4G -numjobs4 -runtime60 -group_reportingCephFS 挂载点也做同样测试。注意-direct1必须开否则数据被页缓存吃掉测出来的是主机内存性能而不是存储性能。对于 RBD还需要确认 fio 打到的是/dev/rbd0而不是宿主机的文件系统缓存路径。观测工具方面ceph osd perf可以查看各 OSD 的提交延迟和 apply 延迟ceph pg stat看 PG 的读写状态cephadm shell -- ceph insights能分析潜在风险项。如果延迟指标异常偏高比如 OSD 提交延迟超过 100ms优先怀疑磁盘本身性能或网络队头阻塞。5.5 高可用与故障切换验证最后一步我强烈建议做一次破坏性演练。把某个 OSD 服务停掉、把某个 MON 节点断网、重启一个 MDS 实例确认集群能自愈。这不仅是“形式上验证”更是在真实故障来临前的排雷。我用ceph orch stop osd.X停掉一个 OSD 容器观察ceph -s中 PG 状态从 degraded 逐步恢复到 activeclean确认数据面自愈能力。再重启 ceph-node1 的 MON 服务确认剩余 MON 仍然组成 quorum节点恢复后 MON 能自动加入。破坏性演练建议至少做两轮一轮在业务低峰期做单点故障一轮在业务高峰期观察集群是否出现性能抖动。很多集群“平时正常、流量一来就出问题”只有通过真实故障演练才能暴露出来。总结与个人经验分享这套 RBD 和 CephFS 混合部署方案我从规划到交付用了大约两个周末就完成了核心部分后续花了一周时间做性能调优和故障演练。整体感受是Ceph 的逻辑清晰、命令体系统一部署门槛其实不高真正考验经验的是理解数据如何流动、故障如何影响业务。RBD 适合对延迟和 IO 路径敏感的负载数据库、虚拟化CephFS 适合需要目录树、多租户配额、文件快照的负载日志、归档、大数据。两者在共享底层资源池的同时在 pool 层做好隔离、在权限层做好分配是生产环境比较推荐的组合。最后分享一个细节不要在生产环境省掉ceph health detail的巡检脚本尤其是 PG 状态、MON 时钟、OSD 空间这三项。很多“突然的大故障”其实在几周前ceph health detail里已经给了提示只是没人看。把巡检命令做成定时任务输出到日志或告警系统能帮你提前发现 80% 的隐患。这套集群目前运行稳定后续我计划再做 CephFS 配额告警和大文件对象分布优化等有了新的结果再回来补充。