Ceph分布式存储实战：核心概念、集群部署与块存储案例

前两天下班前某位运营同事跑过来跟我说业务系统又卡了数据库备份目录快满了得赶紧想办法。我一看那台老存储服务器单块磁盘的容量已经见底RAID5阵列扩容又不敢随便动整个磁盘I/O在高峰期几乎被打满。说白了就是存储不够用扩不动还怕数据丢。那时候我脑子里第一个闪过的方案就是Ceph。这套东西在存储圈子里名声很大几乎搞云平台、搞虚拟化、搞容器的人都绕不开它。Ceph本质上就是一套把普通服务器的磁盘聚合成一个超大存储池的分布式存储系统支持块存储、文件存储和对象存储三种接口部署起来有一定门槛但一旦跑顺了扩展就是加机器的事。这篇文章我就把这几年折腾Ceph的经验整理一下从核心概念到集群部署再到一个完整的块存储使用案例全部揉在一起讲。如果你正要给云平台或者虚拟化环境选一套存储后端或者手里就有那种“量大、又不能停”的存储需求这篇文章应该能帮你少走不少弯路。1. Ceph核心概念拆解先把架构讲透在做任何部署之前我的习惯是先搞明白这东西到底是靠什么机制把数据存下来的。直接上手敲命令当然很快但出了问题就抓瞎了。Ceph的整个设计思路其实不复杂核心就是“去中心化”和“自动数据分布”。1.1 先搞清楚Ceph在一众存储方案里的位置很多刚接触分布式存储的朋友会问Ceph和传统的磁盘阵列、和GlusterFS、和MinIO这些到底有什么不一样。我习惯用一个类比来解释传统磁盘阵列就像你租了一个大型仓库仓库的容积是固定的里面每个货架怎么摆、摆在哪都得你自己操心而Ceph更像是你有了一群小仓库这些小仓库分布在不同的地方你只管把货扔进去系统会自动判断放在哪个仓库还能自动多放几份备份仓库不够了就再租几间。放在技术语境里这句话有几层意思第一Ceph的存储节点和磁盘是普通硬件不需要专用设备第二数据写入时Ceph会通过算法决定数据落在哪些节点的哪些磁盘上而不是人工指定第三默认情况下数据会保存多份副本单个磁盘甚至整个节点的损坏都不会让数据丢失。这种去中心化的架构决定了Ceph天然具备横向扩展能力——想增加容量加机器就行业务不用停。Ceph对外提供的三种接口也是它被广泛应用的关键。块存储RBD是给虚拟机、云主机、数据库这类需要像本地硬盘一样使用的场景文件存储CephFS提供符合POSIX规范的文件系统挂载对象存储RGW提供类似S3的接口适合海量非结构化数据的存取。这篇文章的重点在使用最广泛、也是我实际踩坑最多的块存储也就是RBD。1.2 组成Ceph集群的角色各司其职Ceph集群不是一个大整体而是由多个不同角色的进程协作完成的。理解这些角色部署时候才知道自己配的每一台机器到底在干什么。MONMonitor监控节点这是集群的“指挥中心”负责维护整个集群的集群图谱Cluster Map包括哪些OSD在线、哪些磁盘挂了、PG怎么分布。MON节点需要一半以上达成一致才能形成多数派所以生产环境一般至少部署3个。它不存业务数据但对整个集群的稳定性至关重要。OSD对象存储守护进程这是真正干活的角色。每一块数据磁盘通常对应一个OSD进程负责数据的读写、副本复制、数据恢复等。集群里所有数据都以对象的形式分散存储在OSD上所以OSD的数量直接决定了集群的容量和并行性能。MGR管理器监控和管理OSD、PG、客户端的状态为外部监控系统提供接口。通俗讲它是集群的“仪表盘和秘书”Ceph Dashboard的很多数据就是MGR提供的。MDS元数据服务器只在用CephFS文件存储时才需要它负责管理和缓存文件系统的元数据比如目录结构、文件名。块存储场景下这个角色可以不用部署。如果还用仓库来类比MON是仓管员办公室OSD是各个货架MGR是监控摄像头加报表系统MDS则是货物清单管理员。各个角色通过网络通信、协同工作任何一个角色出问题集群的健康状态都会反映出来。1.3 数据落盘的完整过程PG与CRUSH算法很多人第一次看ceph -s的时候会被一堆缩写搞晕比如PG、CRUSH、Pool这些概念是理解Ceph工作流程的关键。数据写入Ceph时不是直接写到一个磁盘上的。客户端调用接口后数据先被切分成多个对象Object每个对象有唯一的ID标识。然后这些对象会被组合进一个个逻辑分组Ceph里叫归置组Placement Group简称PG。再通过CRUSH算法将每个PG映射到一组具体的OSD上。这个过程可以类比成你要把一本书的每一页拆散先分到几十个信封里再通过一个固定算法决定每个信封寄给哪几个不同的人这些人各保存一份副本。所以创建一个存储池Pool的时候最关键的两个参数就是PG数量和副本数。PG数量决定了数据在整个集群中的分布粒度太少会导致单个PG压力巨大太多则会增加系统的调度开销。副本数决定了数据冗余程度默认一般是双副本或三副本。后续我会讲具体怎么算这个数字。了解了这些其实你已经掌握了Ceph最核心的底层逻辑后面无论是部署还是排障都是在跟这些概念打交道。2. 部署Ceph集群实操细节决定成败部署一套Ceph集群整体流程不复杂但每一步都埋着坑。我部署过几次之后最大的体会是环境准备花了30%的时间部署命令只花10%的时间剩下60%都在处理和网络、系统参数、权限相关的问题。下面我按最常用、也最稳妥的方式逐步展开。2.1 节点规划与环境准备首先说节点规划。我比较推荐的最小生产集群是3节点每个节点既是MON也是OSD同时额外部署MGR。这样既保证了MON的多数派可用又降低了硬件成本。如果条件允许每个节点再额外加一块独立的系统盘和数据盘业务数据盘和操作系统的IO互不相扰这才是最理想的配置。需要说明的是这里讨论的是在物理机或虚拟机集群上手动部署的常见套路。我最近帮朋友公司搭的就是一套3台物理机的环境每台机器2颗CPU、64GB内存、4块SSD做数据盘、1块SATA盘做系统盘。以下是这类节点的建议配置节点角色数量建议配置要求注意事项MONMGR≥3个2核4GB即可无需大容量磁盘生产环境别少于3个避免脑裂OSD按容量需求数据盘尽量独立避免与系统盘混用单盘容量过大时恢复时间会延长网络业务/集群分离万兆网卡起步业务网和存储网隔离网络带宽直接决定集群性能上限系统层面Ubuntu 20.04或CentOS/Rocky 8都可以跑Ceph新版Ceph如Quincy、Reef对内核版本有要求建议内核在5.x以上另外所有节点的主机名hostname和/etc/hosts解析必须做好因为Ceph节点间是通过主机名通信的依赖IP解析会在出问题时非常难排查。时钟同步NTP/Chrony也是必须项MON节点之间时钟偏移过大会直接导致集群异常。2.2 系统参数调优别忽略这一步很多初学者直接装了Ceph就开始添加OSD结果跑了一段时间发现性能很差甚至数据均衡老是异常回头才意识到系统底层都没有调好。这里有几个关键的操作关闭防火墙和SELinux或者在Ceph端口规则上放行。很多诡异的客户端连接失败、OSD之间通信异常跟防火墙脱不了干系。生产环境建议放行Ceph通信端口或者用专门的规则总之别让SELinux在背后捣乱。修改内核参数比如vm.swappiness建议设为10以下减少缓存交换vm.max_map_count适当调大防止文件映射数量不够net.core.rmem_default、net.core.wmem_default等网络缓冲区参数也需要调大以支撑万兆网络的大数据包传输。数据磁盘建议使用独立的文件系统并挂载为OSD专用磁盘调度器设置为SPN或类似模式提升随机IO性能固态盘和机械盘不要混在同一个池里会严重拉低整体性能。这些参数看起来琐碎但它们的价值会在压力测试的时候凸显。我见过一套没有调整这些参数的集群同样硬件条件跑出来的随机写性能差了将近一倍调完之后才勉强达到预期。如果你不想花几小时排查老老实实把这些前置工作做完再动手。2.3 部署流程与关键命令实录接下来是核心部署环节。现在官方推荐的部署工具是cephadm它基于容器方式管理Ceph组件部署和升级都比较方便。以一套5.x版本的Ceph为例大致流程如下在第一个节点安装cephadmcurl --silent --remote-name --location https://download.ceph.com/rpm-5.0.0/el8/RPMS/noarch/cephadm chmod x cephadm ./cephadm add-repo --release quincy ./cephadm install使用cephadm bootstrap初始化monitor这一步会自动部署MON和MGRcephadm bootstrap --mon-ip 192.168.10.11 --cluster-network 192.168.20.0/24其中--mon-ip是第1个MON节点的管理IP--cluster-network是专用的集群通信网段。如果你没有规划独立的集群组网这一步可以省略但我不建议在生产环境这样做集群数据同步流量会对业务网络产生较大压力。将其他节点加入集群cephadm add-host node2 192.168.10.12 cephadm add-host node3 192.168.10.13在所有节点上添加OSD。这一步会根据每个节点的磁盘信息把未使用的磁盘逐个加入ceph orch apply osd --all-available-devices执行完后用ceph -s查看集群状态。如果看到HEALTH_OK就说明基础集群已经搭起来了。2.4 初始化后的健康检查以及那些防不胜防的坑集群搭起来不代表万事大吉初始化后的检查非常关键。第一是确认MON数量ceph mon dump可以看到第二是确认所有OSD都处于up和in状态ceph osd tree很直观第三是检查PG的分布情况看有没有出现严重不均的情况。正常的集群输出里应该没有红色告警各OSD的PG数量相差不大。我在这里把常见部署问题列一下给各位做个速查问题现象常见原因解决办法MON之间无法形成quorum时钟不同步、主机名解析失败检查NTP状态检查/etc/hosts和主机名OSD启动后频繁报up then down磁盘写满、网络通信异常检查磁盘空间集群网络是否通bootstrap时拉取镜像失败网络限制导致无法下载容器镜像配置镜像仓库加速或导出/导入离线镜像cephadm add-host无法连接SSH免密环境未配置好确保各节点间能通过SSH密钥互相访问尤其要提一句SSH免密这一步很多新手会漏。虽然cephadm自带公钥分发机制但使用辅助功能时仍然依赖SSH连通性。真实环境里我遇到过add-host之后CEPH集群的其他节点无法自动化加入ttl的BUG排查很久才发现是SSH互信有问题。先把链路通了再谈下一步这话在任何分布式系统部署里都适用。3. 块存储案例从创建池到客户端挂载集群就绪后就该看真正能用的东西了。Ceph最常见的应用场景之一就是把集群作为云平台比如某开源云平台的统一存储后端通过RBD协议把虚拟机的系统盘和数据盘放在Ceph里。这样做的好处是虚拟机调度到任何一台宿主机都能挂载同一份数据。下面是完整的操作过程。3.1 梳理块存储的核心使用场景在开源云平台或者虚拟化环境里块存储几乎是必备的模块。虚拟机实例需要系统盘数据库需要数据盘这些都需要块存储接口。Ceph RBD的优势在于它天然支持稀疏分配——也就是创建一个大容量镜像时并不立即占用物理空间只有数据真正写入时才占用。这在很多传统存储阵列上是做不到的也让Ceph在容量利用率上非常有吸引力。同时RBD支持快照、克隆、在线扩容等高级功能虚拟机可以通过rbd resize在线扩展磁盘大小整个过程不需要停止业务。这些能力对于存储管理员来说都是刚需。所以我每次给用户讲解Ceph都喜欢用RBD作为第一个案例因为它是用得最多、最直观、也最能展示分布式存储价值的接口。3.2 创建存储池PG数量和副本数的计算在Ceph里存储池Pool是逻辑隔离的单位。先创建池才能在池里创建RBD镜像。ceph osd pool create ssd-pool 128 128 replicated其中128是PG数量128是PGP数量用于数据分布的归置组数量通常和PG数保持一致。replicated表示副本模式。如果你有EC纠删码的需求可以改成erasure模式但这在块存储场景里相对少见这里不展开。PG数量的选择是一门学问。太少了单个PG承载的数据过多数据均衡性差太多了PG调度开销大。通常的建议是每个OSD承载大约50到100个PG总PG数 OSD总数 × 副本数 × 50~100 / 副本数。举个例子一套12块OSD盘、副本数3的集群总PG数可以按12 × 100 1200左右估算再分配到每个池中。当然实际还要看池的数量和数据量适合对象的数可以先用公式估算后续根据监控数据调整。创建完池以后可以设置应用类型让Ceph知道这个池是给RBD用的ceph osd pool application enable ssd-pool rbd3.3 创建RBD镜像并映射到客户端池创建好后就可以创建RBD镜像了。比如创建一个10GB大小的镜像命令如下rbd create --pool ssd-pool --size 10240 rbd-image-01命令里的大小单位是MB所以10GB写成10240。创建完成后可以使用rbd info ssd-pool/rbd-image-01查看镜像属性确认是否正常。要在客户端挂载客户端需要安装ceph-common包并获取集群的admin密钥。然后执行rbd map ssd-pool/rbd-image-01rbd map成功后系统里会出现一个类似/dev/rbd0的设备。这一步如果报了权限或者功能异常通常跟RBD镜像的feature有关。新版RBD默认开启了exclusive-lock、object-map、fast-diff等特性某些内核版本不支持建议在创建镜像或映射时禁用不必要的特性比如加上--image-feature layering。映射后就可以像操作本地磁盘一样对它进行分区、格式化和挂载mkfs.xfs /dev/rbd0 mkdir /mnt/ceph-data mount /dev/rbd0 /mnt/ceph-data3.4 让业务真正用起来注意挂载参数与权限到这里块存储已经下发到指定路径且可以写入文件。但在真实的生产环境中我更关注几个细节很多人往往忽略挂载参数XFS文件系统挂载时建议加上noatime减少不必要的元数据写入如果业务需要掉电保护可以适当调整日志参数。Ceph本身自带多副本所以在大多数场景下文件系统层的RAID功能不需要开启反而会重复占用存储空间。开机自动挂载客户机一般都有多个RBD设备建议通过UUID方式配置/etc/fstab要保证设备挂载顺序稳定。如果rbd map设备号不固定极有可能挂载错设备酿成数据错乱事故。我吃过这个亏后来就老老实实改成UUID。多客户端访问RBD设备默认同一时刻只允许一个客户端写入如果要实现多客户端同时读写需要配合共享文件系统模式比如cephfs或支持共享的集群文件系统。就虚拟机场景来说默认的单个客户端访问模型是足够安全的。3.5 快照管理与克隆回滚生产中最重要的功能之一就是快照。Ceph RBD的快照创建非常迅捷一条命令即可rbd snap create ssd-pool/rbd-image-01snap-20250101 rbd snap ls ssd-pool/rbd-image-01快照可以用于快速恢复误删文件或数据库回滚。要删除此快照使用rbd snap rm如果需要基于快照创建新镜像做业务验证或临时扩容可以用rbd clone完成灵活派生。rbd snap protect ssd-pool/rbd-image-01snap-20250101 rbd clone ssd-pool/rbd-image-01snap-20250101 ssd-pool/clone-volume-01快照和clone功能的组合非常适合开发测试场景——比如需要给多个研发同事各自分配一个干净的测试环境直接从基础镜像克隆出多个副本秒级完成也不会占用额外大量空间原理是Copy-on-Write。实际运维里快照不是越多越好。快照过多会占用大量元数据空间恢复时会变慢而且如果一个镜像有几千个快照性能会有明显下降。建议按备份策略定期清理保留最近N份即可。4. 常见故障定位与性能优化Ceph部署和业务配置搞定之后真正的挑战才刚刚开始——运维。再稳定的集群也会在某个深夜给你一个告警。下面是我积累的几个高频故障和性能优化方向都是实打实的经验。4.1 PG状态异常认识正常与异常的边界ceph -s如果显示的不是HEALTH_ERR但也并非完全健康通常跟PG状态异常有关。我们先认识几个PG状态的含义状态含义处理建议activeclean健康状态数据均衡且完整无需处理degraded有副本数据不完整如某个OSD宕机检查OSD状态待其恢复后自动恢复peeringPG在查找存活OSD并同步状态通常短暂存在长时间卡在该状态需检查MONstaleOSD与MON失联PG状态无法更新检查网络OSD进程是否存活undersized副本数不足可能由OSD故障导致尽快恢复失效节点避免数据风险看到degraded不要慌如果只是单个OSD挂了等它重新上线数据会自动恢复。但要注意PG长时间处于inactive或peering状态这往往意味着MON和OSD之间的心跳出问题或者网络严重丢包。此时优先检查节点负载和网络监控。4.2 OSD故障替换流程要稳妥OSD故障是存储集群最常见的事故。一块盘坏了Ceph会自动把数据分散到其他OSD上但这期间性能会受影响数据安全性也会降至最低。我处理的套路是确认故障盘ceph osd tree查看OSD状态结合dmesg和硬盘告警确认物理盘是否损坏。将故障OSD标记为out暂时停止参与数据分布ceph osd out osd.5确认该OSD上的PG已经迁移到其他节点数据均衡完成后再执行ceph orch osd rm osd.5 --zap如果磁盘是好的只是进程异常可以尝试重启OSD容器如果确实损坏更换物理盘后重新使用cephadm添加OSD。这里有一个重要提醒不要在数据没迁移完成前就去删除OSD的信息。否则可能造成数据不可恢复。替换磁盘前最好先对磁盘信息做完整记录避免误改其他正常盘的标识。生产环境里我曾经看到过同事在慌乱中反挂磁盘导致一台正常OSD被删除扩容顺便变成缩容的尴尬情况。4.3 性能优化的切入方向部署完成之后性能优化是绕不开的话题。Ceph的性能取决于硬件、网络和配置的联动网络是最大的瓶颈集群网络建议万兆起步并且要使用独立的集群网段。如果业务流量和集群复制流量共用网络数据恢复和正常业务会互相拖累。有条件可以做bond并开启网卡的TSO/GRO。磁盘类型决定下限全SSD集群的随机IO能力远高于HDD集群但成本高。可以按不同磁盘类型划分不同存储池比如把热数据放在SSD池冷数据放在HDD池然后按业务需求选择不同池。OSD配置每块盘单独挂载目录避免多盘共享同一个文件系统对于块存储建议开启bluestore存储后端它比旧版filestore性能好很多。当前新版本默认就是bluestore。客户端参数虚拟机使用RBD时调整queue depth和io scheduler为none能有效降低虚拟化层的IO延迟。性能测试的话用fio或Ceph自带的rbd bench-write和rbd bench-read最直观。我通常先跑一轮4K随机读写和一轮1M顺序读写分别观察IOPS和带宽数据结合监控看瓶颈是出在磁盘还是网络还是CPU上。4.4 安全与权限配置端到端的最小控制最后说一个容易被忽视的方面——权限。Ceph默认开启了Cephx认证客户端必须拥有key才能访问集群。这本身没问题问题在于不少管理员图省事直接把client.admin密钥分发到所有机器这等于把集群管理权限公开了。合理方式是每个业务模块单独创建客户端用户并配置最小权限ceph auth get-or-create client.cinder \ mon allow r \ osd allow class-read object_prefix rbd_children, allow rwx poolssd-pool创建完之后把这个keyring文件拷贝到对应客户端机器上并在ceph.conf里指定该用户的权限信息。这样即使某台机器被攻破攻击者能拿到的最多是那一个池的访问权而不是整个集群的管理权限。另外Ceph Dashboard的账号密码也别忘了改默认设置开启双因素认证避免管理面裸奔。结尾一些个人体会与建议大概是因为我前几年吃过太多亏现在回过头看Ceph最需要重视的不是部署命令本身而是对集群机制的理解和对细节的把控。真正遇到故障能帮你解决问题的不是某一条命令而是你知道数据是什么状态、它会从什么路径恢复、什么情况下绝对不能乱操作。那套集群跑到现在快一年了中间换过系统盘、加过两个新节点业务几乎没停过。印象最深的还是刚上线时我做了一次全量压力测试发现某个节点网络抖动一次导致整个集群的写延迟瞬间拉高从哪儿开始查还不是先从网络和时钟下手。所以我的建议非常简单部署前留出时间做好规划和系统调优部署后第一时间配置好监控告警不要省压测。这种存储系统平时不声不响出问题时都是大问题——趁早有准备比到时候手忙脚乱强得多。