CephFS用了一阵子我越发觉得存储池这套设计才是整个文件系统的灵魂。很多人问我CephFS挂载不了、性能拉胯、扩容失败最后排查下来问题往往不在服务器而在存储池的规划上尤其体现在pg_num、副本策略和命名上。今天我就以Rocky 9.6 Ceph 17.2.9这套组合为例把CephFS存储池的细节掰开揉碎讲一遍重点说说命名规范和那些坑。如果你正在搭Ceph集群、想给Kubernetes或虚拟化环境提供共享文件存储或者已经上Ceph但对pool的划分一头雾水这篇文章可以直接帮你少走两个月的弯路。我会从架构角色、规划思路、实操命令到故障排查完整走一遍尽量口语化让你能照着做。1. 先把CephFS存储池的角色搞清楚1.1 CephFS架构里的两类存储池CephFS挂在RADOS之上靠的是Libcephfs和MDS组件。MDS不保存数据本身它只维护元数据比如文件目录结构、权限信息、文件长度、时间戳这些。真正的数据块还是落在RADOS对象里。这套设计决定了CephFS必须有两类存储池元数据池metadata pool和数据池data pool。元数据池存放的是MDS生成的元数据对象这些对象通常很小但数量极大而且要求低延迟。数据池存放的是实际文件内容可能被切分成多个对象每个对象的大小可以通过data_pool和max_file_size等参数联动决定。你可以把元数据池看作是一本书的目录索引数据池看成书的具体章节内容。索引页坏了整本书读不了章节页丢了顶多缺部分内容。所以在规划时元数据池和数据池不能共用一个池至少不应该在同一个池里裸跑。这里有个常见误解有人觉得文件不大干脆只建一个pool然后CephFS的 metadata pool 和 data pool 都指向它。这样短时间没事但一旦目录文件数上去了MDS产生大量小对象和用户数据对象互相争抢OSD的资源最终会出现元数据操作卡顿、目录ls延迟暴涨。我见过不少生产事故是从“共用一个池”开始的。1.2 为什么命名规范会影响运维体验存储池命名看起来是小事实际是运维里最容易后悔的决定。Ceph集群里除了CephFS还可能有RGW对象网关、RBD块设备等业务。如果不同业务都用同一个命名维度比如pool1、pool2、pool3三个月后再看ceph osd pool ls detail你根本分不清哪个池属于CephFS哪个池属于块存储。而且CephFS创建时会把FS名字作为前缀生成一部分内部结构。创建ceph fs new cephfs metadata_pool data_pool时MDS会用cephfs作为文件系统标识。如果pool命名和FS名对不上排障时非常痛苦得靠ceph fs get才能确认关联关系。我自己的习惯是用三段式命名业务标识-存储类型-角色。比如cephfs-prod-metadatacephfs-prod-data1cephfs-prod-data2这样ceph osd pool ls输出一眼能看清哪个池给CephFS的哪个FS用数据池有几个分片。更关键的是后续要建多个CephFS实例时不会出现pool metadata被两个FS抢用的情况。这在多租户场景下尤其重要。生产环境还有个边界情况如果Ceph集群同时给OpenStack的cinder用RBD pool最好命名为images、volumes、backups这类带业务语义的。总之命名规范不是装样子而是把信息编码到名称里遇到事故时能第一眼判断边界。这是我在多次故障里学到的教训。2. Rocky 9.6 Ceph 17.2.9环境下的存储池初始规划2.1 环境概览与版本差异Rocky 9.6作为RHEL 9系的发行版内核和用户态软件都比较新。Ceph 17.2.9是Quincy系列的最新补丁版本之一自带文件系统默认支持fscrypt、多FS等特性。这个版本在ceph fs命令体验上比Nautilus时代好很多比如自动按pool的application标签识别FS。但是Rocky 9.6默认内核不一定带完整的ceph模块尤其在一些需要最新cephfs特性的场景下建议内核保持在官方或ELRepo更新的版本。我在测试机上装了Rocky 9.6最初内核版本为5.14挂载CephFS并没有问题但要启用fscrypt或者alt_name这类新特性时还是需要确认内核支持。Ceph 17.2.9本身提供了ceph-fuse如果不依赖内核模块可以直接用fuse挂载避开内核兼容问题。创建存储池之前最好先确认集群状态ceph -s ceph osd tree ceph versions我见过有人急着建pool结果OSD还没完全up导致数据池的健康状态一直处于PG_AVAILABILITY告警。所以在初始化阶段先把Monitor集群、OSD状态搞定再动手。2.2 命名规范建议从cluster到pool的一把尺子我把命名规范化分成三层集群层级、业务层级、池角色层级。三层加在一起每一个pool的全名都像一个坐标。集群层级可以用环境缩写比如prod、test、backup。业务层级可以是cephfs、rbd、rgw。池角色层级可以是metadata、data、ecdata。所有字符建议小写用连字符-分隔不要用下划线。prod-cephfs-metadataprod-cephfs-data-replicatedprod-cephfs-data-erasure这里的>ceph osd pool create prod-cephfs-metadata 64 64数据池示例ceph osd pool create prod-cephfs-data 128 128这里64和128分别代表pg_num和pgp_num。在Ceph 17里pgp_num概念仍然存在但实际作用已经弱化自动伸缩时会根据规则调整。大多数情况下保持两个值一致即可不必像老帖子说的那样先 pg_num 再 pgp_num 逐步更新。创建完成后立刻给pool打上应用标签ceph osd pool application enable prod-cephfs-metadata cephfs ceph osd pool application enable prod-cephfs-data cephfs这一步非常关键。如果没有设置cephfsapplication标签Ceph会发出application not enabled on pool的告警而且后续ceph fs new会提示pool是否合适。虽然可以通过ceph osd pool application set补上但最好在创建后马上做。还有个细节pool创建时的crush_rule默认是replicated_rule如果你要指定不同的CRUSH规则可以在命令里加--crush-rule。比如存在单独的SSD规则ceph osd pool create prod-cephfs-metadata 64 64 replica_rule_ssd元数据池用SSD数据池用HDD这种分层设计能显著提升目录操作性能。我测试过在混合盘集群里metadata pool使用SSD后create和rename延迟能降一半以上。3.2 设置application标签与自动扩容创建完pool除了app标签需要检查pg autoscaler是否开启。Ceph 17默认开启了pg_autoscaler但每个pool有自己的pg_autoscale_mode默认是warn。也就是说它会给你建议但不自动调整pg_num。如果想让集群在容量增长时自动调整PG数量可以改成onceph osd pool set prod-cephfs-data pg_autoscale_mode on ceph osd pool set prod-cephfs-metadata pg_autoscale_mode on但我个人的习惯是warn模式因为自动调整PG数量可能引发大规模数据迁移在业务高峰期折腾你。我会定期看ceph osd pool autoscale-status然后手动选择低峰期调整。这个选择看你对业务窗口的把握没有绝对标准。同时设置 pool 的配额或者属性比如给元数据池设置接近无上限的target_size_bytes没必要。Ceph的配额是作用于FS而非poolas of 17.2ceph fs quota是在挂载路径上设置的不是pool属性。3.3 创建CephFS并挂载验证创建文件系统ceph fs new prod-cephfs-k8s prod-cephfs-metadata prod-cephfs-data如果命令报错通常是因为pool已经有其他FS引用或者app标签没设好。确认后可以查看ceph fs ls ceph fs get prod-cephfs-k8s然后创建客户端用户并授权。我给个常见的权限设置ceph auth get-or-create client.k8s mon allow r mds allow rw fsprod-cephfs-k8s osd allow rw poolprod-cephfs-data, allow rw poolprod-cephfs-metadata -o /etc/ceph/ceph.client.k8s.keyring挂载时有两种方式内核挂载和fuse挂载。内核挂载mount -t ceph 10.0.0.1:6789,10.0.0.2:6789:/ /mnt/cephfs -o namek8s,secretfile/etc/ceph/ceph.client.k8s.secretfuse挂载ceph-fuse -m 10.0.0.1:6789 /mnt/cephfs --id k8s如果一切正常df -h /mnt/cephfs能看到容量且没有报错。这里的:/表示整个FS根目录。如果想只挂载子目录路径写:/subdir。挂载验证建议做三件事创建文件、创建目录、删除文件。然后检查MDS日志和ceph daemon mds.name dump_metrics确认有没有IO错误。4. 核心参数详解pg_num、CRUSH、EC与副本模式4.1 pg_num 的选择逻辑PGPlacement Group是数据分布的基本单位。同一个存储池的数据会按照对象名哈希均匀分布到不同PG每个PG落到一组OSD上。PG数量太少会导致单个PG承载对象过多OSD负载不均衡PG数量太多会消耗大量内存和CPU尤其在OSD数量不多时切换效率变差。官方建议是每个OSD大约50到100个PG。比如集群总共有9个OSD3副本期望每OSD 100个PG则总PG数不能超过900对单个数据池来说可以分走总PG数的一半。这个建议在Ceph 17里会差点偏移因为autoscaler会给出更细的算法但作为初始设计参考仍然有效。我在这个环境里通常这样估算可分配PG总数 ≈ OSD数量 × 每个OSD的PG目标数假设9个OSD每个OSD约50个PG更保守总PG数约450。数据池分配128个PG元数据池分配64个PG合计192个PG占用约43%余量留给RBD或RGW池。如果OSD数量增长到18个PG配额可以翻倍通过ceph osd pool set调整。一个重要原则不要频繁调PG数量。每次调整都会触发数据rebalance大量对象重新分布可能影响IO。调整前务必确认集群健康状态为HEALTH_OK最好选择业务低峰。4.2 CRUSH map 与失败域CRUSH算法决定PG内的副本或纠删码分片分布在哪些OSD上。默认replicated_rule会把不同的副本分散到不同host上以避免物理机宕机导致数据全丢。CephFS元数据池尤其依赖失败域。如果所有OSD都在同一台物理机上MDS数据一旦机器宕机整个FS瘫痪。生产环境建议把失败域设为host甚至机架级别这取决于你的硬件分布。查看当前ruleceph osd crush rule ls ceph osd crush rule dump我推荐给CephFS起一个专用规则。比如全部OSD在host上分布可以创建名为cephfs-rule的规则ceph osd crush rule create-replicated cephfs-rule default host然后在创建pool时指定这个rule。这样后续如果RBD或者RGW使用其他规则互不影响。这个环节容易被忽略但一旦你加了新OSD或者调整了机架布局就会体会到CRUSH规则清晰的好处。我见过有人把数据池和OSD池共用一套rule结果所有副本都挤在同一个host上直接导致某个物理节点宕机后多个PG进入降级状态。4.3 纠删码 vs 副本什么适合CephFS纠删码Erasure Code可以节省存储空间但CPU开销和IO延迟比副本更高。CephFS数据池支持EC但在Ceph 17中EC池的写路径通过BlueStore的bluestore compression等机制性能和副本相比仍有差距尤其是小文件。我给的配置建议元数据池必须副本。数据池如果业务以视频、备份大文件为主可以用EC 21或42节省约40%到50%空间。如果业务以小文件读写为主比如Web服务、代码目录不要用EC直接用3副本更省心。如果要创建EC数据池给CephFS需要先创建EC profileceph osd erasure-code-profile set cephfs-profile k4 m2 crush-failure-domainhost ceph osd pool create prod-cephfs-ecdata 128 128 erasure cephfs-profile ceph osd pool application enable prod-cephfs-ecdata cephfs然后在ceph fs new时把EC池作为数据池或者在已有FS上添加附加数据池。需要注意CephFS对EC池要求默认对象大小和条带大小匹配可能涉及ceph fs set fs max_file_size或对象大小调整配置不当会出现写入报错。5. 常见问题与排查技巧实录5.1 命名后患pool名与FS名不一致我遇到过一个典型场景集群里已经有一个FS叫cephfs_a但元数据池叫pool_meta数据池叫pool_data。维护人员离职后新来的运维看到一堆pool根本不知道哪个对应哪个。更麻烦的是如果要扩第二个FS发现pool_meta已经被MDS占用无法复用。排查方法ceph fs ls ceph fs get cephfs_a输出里会明确写data_pool_id和metadata_pool_id。然后用ceph osd pool get查看名称。虽然能查出来但日常操作还是很别扭。所以我的建议是新建FS之前先列一下现有pool命名尽量避免用没有语义的短名称。已经踩坑的同学可以考虑建一个新的规范pool把数据迁移过去再移除旧pool而不是硬着头皮一直用不规范名字。5.2 PG数量调整引发的rebalance风暴手动调pg_num时如果一次性调得过大比如从64跳到256Ceph会产生大量PG split操作同时数据迁移量巨大。我的经验是每次调整不要超过当前值的一倍例如从64调到128等所有PG状态变为activeclean再调到256。观察PG迁移状态ceph -s ceph pg stat ceph osd pool autoscale-status如果rebalance对线上IO影响严重可以临时降低osd_max_backfills和osd_recovery_max_active参数限制后台恢复流量。例如ceph tell mon.* injectargs --osd-max-backfills 1 ceph tell mon.* injectargs --osd-recovery-max-active 2完成后记得恢复默认值。5.3 元数据池变胖CephFS元数据池如果存放了大量日志文件、快照对象或历史版本可能不断增长。常见原因是没有定期清理快照或MDS日志参数设置不当导致日志对象堆积。查看MDS日志用量ceph fs status ceph daemon mds.name dump_metrics | grep -i journal通过ceph fs set fs max_mds等调优或者配置mds log max segments来限制日志大小。如果元数据池确实已经占用了过多空间迁移元数据是比较复杂的不建议随意rados -p pool rm会删除文件系统数据。5.4 挂载超时与内核版本兼容Rocky 9.6默认内核挂载CephFS时可能出现mount error: no such device或超时。少数发行版内核的Ceph模块可能没有加载或者缺少ceph.ko。排查顺序lsmod | grep ceph modprobe ceph dmesg | grep -i ceph如果内核不支持直接用fuse挂载是最快的路径dnf install ceph-fuse -y ceph-fuse -m 10.0.0.1:6789 /mnt/cephfs --id k8s -o nonempty另外挂载时不要忘了secretfile权限chmod 600很重要否则报keyring not found或认证失败。如果你发现ls -l /mnt/cephfs卡住多半是MDS到OSD通信有问题检查网络和OSD状态而不是反复重启挂载。6. 几个提高CephFS可用性的进阶建议6.1 多活跃MDS与负载均衡Ceph 17支持多活MDS你可以设置max_mds大于1让多个MDS实例共同分担元数据请求。对于文件数量多、目录并发高的场景这能明显提升吞吐。ceph fs set prod-cephfs-k8s max_mds 2 ceph fs status但要注意MDS数量不宜超过元数据池所在节点的CPU能力。增加MDS不会自动把单个目录请求分片目录热点还是会导致单MDS瓶颈。6.2 客户端缓存参数调优内核挂载CephFS时可以通过mount参数控制客户端缓存大小如rsize、wsize、readdir_max_bytes。在大量小文件读写时适当调大wsize能减少网络往返。在主要大文件顺序读的环境调大rsize有一定收益。fuse挂载的缓存行为与内核挂载不同可以通过/etc/ceph/ceph.conf里的client_cache_size、client_oc_size等选项控制。别迷信参数最好结合fio测试来确认效果。6.3 备份与快照CephFS自带快照功能需要先启用allow_new_snapshotsceph fs set prod-cephfs-k8s allow_new_snapshots true然后可以在挂载目录里创建.snap目录来生成快照。这个功能非常适合防止误删但要注意快照会占用元数据池和数据池空间别无限量保留。我的做法是每天一个快照保留三天同时通过RBD块备份或文件同步到异地。7. 最后的实操心得这套Rocky 9.6 Ceph 17.2.9 CephFS的组合我前前后后折腾了大约两周最大的感受是存储池规划决定了CephFS的天花板。命名规范看着不起眼等集群业务多起来它就是你救命的工具。我后来专门写了一个脚本定期把ceph fs dump里的FS名、pool id、pool名打印成对照表防止人员变动后信息断层。如果你刚开始接触CephFS建议先在测试环境多建几个pool和FS试过错误选项后你才会理解为什么application标签和pg_autoscale_mode那么重要。动手永远比看文档记忆深刻。另外一个容易忽视的细节ceph osd pool create后立刻ceph osd pool application enable。很多人漏了这步之后虽然也能用但集群日志会一直报错看着很闹心。养成习惯就好。最后CephFS主要适合大量小文件共享存储的场景但如果你的应用对目录树操作非常密集仍然要关注MDS的性能。存储池再合理硬件瓶颈依然无法完全消除只能通过合理规划把瓶颈后移。