JMeter吞吐量控制器原理与混合场景建模实战
2026/10/13 1:19:43
前两天下班前，某位运营同事跑过来跟我说，业务系统又卡了，数据库备份目录快满了，得赶紧想办法。我一看那台老存储服务器，单块磁盘的容量已经见底，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集群不是一个大整体，而是由多个不同角色的进程协作完成的。理解这些角色，部署时候才知道自己配的每一台机器到底在干什么。
- MON（Monitor）监控节点：这是集群的“指挥中心”，负责维护整个集群的集群图谱（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盘做系统盘。以下是这类节点的建议配置：
| 节点角色 | 数量建议 | 配置要求 | 注意事项 |
|---|---|---|---|
| MON+MGR | ≥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为例，大致流程如下：
- 在第一个节点安装
cephadm：
curl --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和MGR：
cephadm 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-01@snap-20250101 rbd snap ls ssd-pool/rbd-image-01快照可以用于快速恢复误删文件或数据库回滚。要删除此快照，使用rbd snap rm；如果需要基于快照创建新镜像做业务验证或临时扩容，可以用rbd clone完成灵活派生。
rbd snap protect ssd-pool/rbd-image-01@snap-20250101 rbd clone ssd-pool/rbd-image-01@snap-20250101 ssd-pool/clone-volume-01快照和clone功能的组合，非常适合开发测试场景——比如需要给多个研发同事各自分配一个干净的测试环境，直接从基础镜像克隆出多个副本，秒级完成，也不会占用额外大量空间，原理是Copy-on-Write。
实际运维里，快照不是越多越好。快照过多会占用大量元数据空间，恢复时会变慢，而且如果一个镜像有几千个快照，性能会有明显下降。建议按备份策略定期清理，保留最近N份即可。
4. 常见故障定位与性能优化
Ceph部署和业务配置搞定之后，真正的挑战才刚刚开始——运维。再稳定的集群，也会在某个深夜给你一个告警。下面是我积累的几个高频故障和性能优化方向，都是实打实的经验。
4.1 PG状态异常，认识正常与异常的边界
ceph -s如果显示的不是HEALTH_ERR但也并非完全健康，通常跟PG状态异常有关。我们先认识几个PG状态的含义：
| 状态 | 含义 | 处理建议 |
|---|---|---|
| active+clean | 健康状态，数据均衡且完整 | 无需处理 |
| degraded | 有副本数据不完整，如某个OSD宕机 | 检查OSD状态，待其恢复后自动恢复 |
| peering | PG在查找存活OSD并同步状态 | 通常短暂存在，长时间卡在该状态需检查MON |
| stale | OSD与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 pool=ssd-pool'创建完之后，把这个keyring文件拷贝到对应客户端机器上，并在ceph.conf里指定该用户的权限信息。这样即使某台机器被攻破，攻击者能拿到的最多是那一个池的访问权，而不是整个集群的管理权限。
另外，Ceph Dashboard的账号密码也别忘了改默认设置，开启双因素认证，避免管理面裸奔。
结尾：一些个人体会与建议
大概是因为我前几年吃过太多亏，现在回过头看，Ceph最需要重视的不是部署命令本身，而是对集群机制的理解和对细节的把控。真正遇到故障，能帮你解决问题的不是某一条命令，而是你知道数据是什么状态、它会从什么路径恢复、什么情况下绝对不能乱操作。那套集群跑到现在快一年了，中间换过系统盘、加过两个新节点，业务几乎没停过。印象最深的还是刚上线时，我做了一次全量压力测试，发现某个节点网络抖动一次，导致整个集群的写延迟瞬间拉高，从哪儿开始查？还不是先从网络和时钟下手。所以我的建议非常简单：部署前留出时间做好规划和系统调优，部署后第一时间配置好监控告警，不要省压测。这种存储系统，平时不声不响，出问题时都是大问题——趁早有准备，比到时候手忙脚乱强得多。