简介：面向云计算运维、存储工程师与架构师的安装测试报告，完整呈现OpenStack与Ceph分布式存储集成的部署验证过程。报告从云计算基础、OpenStack组件与VMware对比讲起，重点剖析Ceph的OSD/MDS/RGW/MON组件、CRUSH映射机制、强一致性与容错设计，并结合本地YUM源配置、主机规划等实操章节，给出从环境准备到测试落地的全流程参考。资源为单个docx文档，压缩包约876KB，共1个文件，内容结构清晰，目录涵盖基础知识、Ceph架构、OpenStack选择Ceph的考量及安装配置与测试章节，适合作为学习笔记或实施前调研资料。目前已有254人学习，报告既有助于快速理解两大技术融合原理，也为后续部署和调优提供了可复用的思路与检查要点。

1. 拿到的不是一份报告，而是一套部署与验证方法

拿到《OpenStack Ceph分布式存储安装测试报告》这类文档，很多人的第一反应是直奔安装步骤，把报告里的环境参数抄成自己的，再照着跑一遍容量测试就完事。我建议你反过来：先读它的测试场景设计和失败记录，因为真正的项目风险不在“能不能装完”，而在“装完之后怎么证明它能用、什么时候不能用”。这套组合解决的是OpenStack云平台的后端存储问题——Glance镜像、Cinder云硬盘、Nova临时盘都落到Ceph分布式存储上，适合私有云交付、存储选型对比和虚拟化团队做容量规划的人参考。反直觉的一点是：默认参数装出来的Ceph在OpenStack里表面能建卷，一旦多节点并发跑起来，性能可能掉一半以上——原因不在Ceph本身，而是测试报告里那些绕开了并发和异常场景的验证步骤。

2. 云平台后端为什么绕不开Ceph：角色拆解与Kolla选型对比

2.1 Ceph在OpenStack里到底扮演什么角色

OpenStack云平台里，存储不是一个组件的事，而是三个组件各吃一块：Glance存镜像文件，Cinder提供云硬盘块设备，Nova创建实例时需要的临时系统盘也来自后端存储。这三类数据有一个共同特点——它们都是块语义，需要支持挂载、格式化、快照、克隆。Ceph的RBD（RADOS Block Device）天生就是做这个的，它把一个个块设备切成对象分散到整个集群里，靠多副本保证数据不丢。

如果用本地存储做Cinder后端，最直接的问题是：一台计算节点宕掉，落在它本地磁盘上的云硬盘全部不可用，连救援的余地都没有。Ceph让每个块设备的数据至少存三份（测试环境常用size=3），分布在不同的物理节点上，单台OSD宕机不影响卷的读写；快照和克隆能力对测试环境、开发环境的回滚尤其方便，十几秒就能克隆出一个完整的云硬盘。所以OpenStack云平台搭建走到生产这一步，Ceph几乎是默认选型。

有人会问，MinIO不是分布式存储的替代者吗，为什么不用它？这里要分清角色。MinIO做的是对象存储，走S3接口，适合存备份、日志、静态文件；但OpenStack云端硬盘要的是块设备语义——把一个卷挂到虚拟机里格式化、跑数据库、做文件系统fsync，对象存储的接口层绕不过去，延迟和语义都对不上。NFS也常被拿来对比，但在多客户端并发读写同一个镜像、大量小IO场景下，NFS的锁机制和缓存一致性很容易翻车。结论是：Ceph负责块，MinIO负责对象，各管一段，不是替代关系。

2.2 手工部署Ceph + OpenStack与Kolla-Ansible集成：我为什么选后者

部署OpenStack和Ceph的组合，业内常见做法是两条路线。第一条是手工路线：先用cephadm单独部署一套Ceph集群，再在每个OpenStack控制节点上安装ceph-common，手工配置keyring，修改cinder.conf、glance.conf、nova.conf里的rbd连接参数。这条路线的好处是Ceph集群可以独立维护、独立升级；坏处是版本组合太多，Ceph和OpenStack任何一个版本错位都会掉进兼容性黑匣子——qemu的rbd驱动、libvirt的rbd特性、宿主机内核模块，任何一个不匹配，轻则挂载失败，重则集群性能异常，排错时你根本不知道问题出在OpenStack侧还是Ceph侧。

第二条路线是Kolla-Ansible集成部署。openstack kolla这个项目把OpenStack所有服务容器化，部署时只要在globals.yml里打开enable_ceph，它会在storage组节点上自动部署Ceph集群，同时把cinder、glance、nova三个组件的后端指向Ceph，keyring和ceph.conf由部署框架统一生成并挂载进对应容器。版本匹配由容器镜像锁死，升级也是整体走kolla-ansible upgrade，少了一整类“版本不对”的坑。

我一般会这样选：如果团队已经有专职Ceph运维、存量Ceph集群必须复用，走手工路线；如果是从零开始搭OpenStack云平台，没有太多存储运维人力，Kolla-Ansible集成方式明显划算。下面这张对比表是我在做选型时常用的判断依据：

Kolla集成方式的关键变量就是enable_ceph、glance_backend_ceph、cinder_backend_ceph这几个开关。下面的章节我把从网络规划到验证命令的完整路径拆开写，照着操作就能落一套可测试的环境。

3. 用Kolla-Ansible装OpenStack和Ceph：从网络规划到验证命令

3.1 部署前网络与磁盘的准备

Kolla-Ansible对网络的要求不复杂，但容易被低估。至少需要两类网络：管理/API网络用于部署机到所有节点的通信，存储网络用于Ceph集群内部的数据复制和心跳。如果条件紧张，可以合并，但后果在重负载时会很明显——Ceph的OSD之间复制流量和OpenStack的API流量抢带宽，监控曲线会出现奇怪的抖动。为一份安装测试报告的可信度着想，存储网单独用万兆交换机是值得的。

磁盘规划按节点角色分开：

一个关键原则：Ceph的OSD数据盘必须是整块裸盘，不要提前分区，不要格式化，Kolla部署时ceph容器会直接接管整块设备。如果你把系统盘和数据盘放在同一块物理盘上，部署时大概率会在precheck阶段被拦下来。另外，storage组节点的内存建议不低于16GB，因为OSD的内存占用会随PG数量增长；测试环境如果只有8GB，建议把osd_memory_target调低，否则OOM会找上门。

3.2 用Kolla-Ansible跑通最小集成的完整命令

部署机建议用Ubuntu 22.04或CentOS Stream 9，Python 3.10以上即可。先在部署机上准备虚拟环境，避免污染系统Python：

# 创建 Python 虚拟环境并安装 kolla-ansible python3 -m venv /opt/kolla-venv source /opt/kolla-venv/bin/activate pip install -U pip pip install kolla-ansible==15.3.0 # 安装系统依赖并生成 kolla 配置目录 kolla-ansible install-deps mkdir -p /etc/kolla cp -r /opt/kolla-venv/share/kolla-ansible/etc_examples/kolla/* /etc/kolla/

这里把kolla-ansible版本固定在15.3.0，对应OpenStack Zed版本，容器镜像源默认从Docker Hub拉取。如果你的部署机访问镜像仓库慢，提前配置好镜像加速器再执行后续步骤。install-deps会安装ansible、docker等基础组件，部署机的ansible版本必须与kolla-ansible要求的范围匹配，不要手动升级ansible到最新版。

接下来编辑globals.yml中与Ceph相关的关键项：

# /etc/kolla/globals.yml 关键片段 openstack_release: "zed" kolla_base_distro: "ubuntu" network_interface: "eth0" neutron_external_interface: "eth1" # Ceph 后端三件套，打开后 cinder/glance/nova 都会指向 Ceph enable_ceph: "yes" glance_backend_ceph: "yes" cinder_backend_ceph: "yes" nova_backend_ceph: "yes" # 测试环境没有备份需求时关掉 cinder-backup，省一份资源 enable_cinder_backup: "no"

enable_ceph置为yes后，Kolla会在storage组上自动部署mon、mgr、osd容器，并自动创建client.openstack这个Ceph认证用户，keyring生成后挂载到所有需要访问Ceph的OpenStack服务容器里。glance_backend_ceph控制Glance镜像后端，cinder_backend_ceph控制Cinder卷后端，nova_backend_ceph控制Nova临时盘。这三个开关只要有一个没打开，对应组件就会走默认的本地存储逻辑，测试报告里的“全链路走Ceph”就不成立。

然后准备多节点清单。Kolla-Ansible自带的multinode样例文件结构如下：

# /etc/kolla/multinode [control] 192.168.20.11 ansible_user=root 192.168.20.12 ansible_user=root 192.168.20.13 ansible_user=root [compute] 192.168.20.21 ansible_user=root 192.168.20.22 ansible_user=root [storage] 192.168.20.31 ansible_user=root 192.168.20.32 ansible_user=root 192.168.20.33 ansible_user=root [network:children] control [monitoring:children] control

storage组在Kolla里专门承载Ceph相关容器，也就是OSD和monitor所在节点。注意control组和storage组建议物理分开，不要用同一批节点既跑控制服务又跑OSD，否则Ceph的IO波动会直接影响MySQL、RabbitMQ这些核心服务的响应时间。清单准备好后，依次执行：

# 三步走：初始化节点 -> 预检查 -> 部署 kolla-ansible -i /etc/kolla/multinode bootstrap-servers kolla-ansible -i /etc/kolla/multinode precheck kolla-ansible -i /etc/kolla/multinode deploy

bootstrap-servers会在所有节点安装容器运行时并配置基础环境；precheck会检查磁盘、网络连通性、Python版本、端口占用，发现问题会直接报出来，不要跳过这一步硬着头皮deploy。deploy是整个部署中最耗时的一步，取决于节点数量和镜像拉取速度，一般30到60分钟。部署完成后执行post-deploy生成OpenStack管理账号的凭证文件：

kolla-ansible -i /etc/kolla/multinode post-deploy

这条命令会在/etc/kolla目录下生成admin-openrc.sh，后续所有openstack命令都需要先source这个文件。

3.3 验证Ceph与OpenStack链路是否真的打通

部署完成不等于链路通，必须从两个方向验证。先看Ceph集群状态：

# 在任意 storage 节点执行，或进入 ceph-mon 容器 ceph -s

正常状态是HEALTH_OK，三个mon都处于Active状态，OSD数量与磁盘数量一致，PG状态没有active+clean以外的异常。然后验证OpenStack侧的认证和组件状态：

# 在部署机加载管理员凭证 source /etc/kolla/admin-openrc.sh openstack service list

能看到cinder、glance、nova、neutron等服务都处于registered状态。接着做一次端到端的存储验证：

# 创建云硬盘，指定 ceph-volume 类型 openstack volume create --size 10 --type ceph-volume test-vol # 在 Ceph 侧确认卷是否真的落池 rbd -p volumes ls

如果rbd输出里出现volume开头的块设备名，说明Cinder已经把创建卷的请求真正落到Ceph的volumes池。这里有一个常见问题：当cinder_backend_ceph为yes时，Kolla默认创建的卷类型名是ceph-volume，如果创建卷时不指定--type，可能落到默认的本地存储后端报错。测试报告里记录这一步时，要把“指定卷类型”作为标准操作写进去，否则别人复现时会在第一步就被拦。

4. OpenStack Ceph存储测试怎么做：从RBD裸性能到云硬盘全链路

4.1 RBD裸性能：用rados bench先测存储底子

在进OpenStack之前，先对Ceph集群本身做一轮性能摸底。rados bench是Ceph自带的基准工具，直接打RADOS层，绕过OpenStack和qemu，得到的是Ceph集群最原始的吞吐能力。常见做法是先写后读：

# 对 volumes 池做 120 秒写测试，保留数据供后续读测试使用 rados bench -p volumes 120 write --no-cleanup # 顺序读与随机读各跑 120 秒 rados bench -p volumes 120 seq rados bench -p volumes 120 rand

-p参数指定测试池，120是测试时长秒数。--no-cleanup表示写完后不清理对象，否则后续的读测试没有数据可读。写测试的输出会直接显示MB/s和IOPS，这就是集群的裸性能下限。要注意的是：这个数值已经包含了多副本写放大——三副本时实际物理写入量是逻辑写入量的三倍，记录测试报告时必须标注“副本数=3”，不然换个人用两副本集群复现时会对不上数据。rados bench跑完，基本就能判断OSD配置和网络有没有明显瓶颈。

4.2 rbd bench与虚拟机内fio：找出损耗发生在哪一层

rados bench测的是OSD层，接下来用rbd bench测指定卷，再用fio在虚拟机内测全链路。这两个数据之间的差值就是qemu、virtio和宿主机内核带来的损耗：

# 对刚才创建的卷做块层基准，16 线程写 1GB 数据 rbd bench --io-type write --io-size 4K --io-threads 16 --io-total 1G volumes/test-vol # 在云主机内部用 fio 测端到端随机写，绕过 page cache fio --name=randwrite --rw=randwrite --bs=4k --size=2G --numjobs=4 \ --runtime=120 --time_based --group_reporting --direct=1

rbd bench直接对volumes池里的test-vol块设备打IO，不经过OpenStack，用来确认单个卷的性能瓶颈是否在Ceph侧。fio的直通参数是关键：direct=1绕过宿主机page cache，避免写入先落内存缓存导致数值虚高；numjobs=4模拟四个进程同时写一块卷，接近真实数据库场景；bs=4k是典型的OLTP随机写块大小。fio跑完会输出平均IOPS和延迟分布，把rbd bench和fio结果放一起对比，如果fio的随机写IOPS只有rbd bench的30%到40%，损耗在虚拟化层；如果两者都低，问题更可能在Ceph集群本身。

在qemu部署多架构虚拟机的场景下，这一步尤其值得记录：在x86宿主机上用qemu模拟ARM或RISC-V架构时，rbd客户端跑在qemu用户态进程里，CPU架构翻译的开销直接反映在存储延迟上。我在实际测试中见过同一块卷，x86原生实例4K随机写延迟0.8ms，qemu模拟ARM实例直接到2.5ms——不是Ceph的问题，是qemu的CPU模拟瓶颈。这类数据如果不单独标注架构，会让后续选型误判Ceph性能。所以多架构相关的测试数据，在报告里单独开一行指标，不要混进统一基线。

4.3 并发与故障注入：测试报告里最有价值的部分

单卷性能测试只能证明“能跑”，证明不了“扛得住”。安装测试报告里最有说服力的部分是并发和异常场景。我这里给出一个我在测试环境常用的操作序列，按顺序执行并记录观察结果：

1. 并发创建卷：用脚本一次性提交30个10GB卷创建请求，观察Cinder API的响应时间变化和Ceph端PG状态的抖动情况；
2. 并发启动云主机：同时启动30台云主机，让Nova在vms池批量创建临时盘，记录从请求到实例可用的时间；
3. 拔盘故障注入：在测试环境拔掉一个OSD的数据盘，观察ceph -s里PG状态从degraded回到active+clean的时长。

我一般记录三个核心指标：故障恢复耗时、故障期间新卷创建的平均排队时延、monitor有没有发生切主。这三个数据同时稳定，才说明集群具备基本的自愈能力。只贴带宽图、不贴故障恢复数据的报告，在真正选型时很难让人放心。

5. OpenStack+Ceph部署避坑实录：五个现象背后的根因

5.1 云硬盘创建一直ERROR：Keyring同步不完整

现象：openstack volume create提交后，卷状态卡在ERROR，cinder-volume日志报rbd error: Operation not permitted或RBD image not found。

原因：Kolla生成的client.openstack keyring没有同步到cinder-volume容器，或者/etc/kolla/ceph/目录下keyring文件的权限不是root:root且0640。Kolla对容器内挂载的keyring文件权限校验很严格，手工cp一份过去常常因为权限字段不对导致容器内读取失败。这个坑在手工部署Ceph和OpenStack时几乎人人都会遇到，Kolla集成部署偶尔也会因为手工改动配置触发。

解决：先检查/etc/kolla/ceph/ceph.client.openstack.keyring是否存在、权限是否正确。不存在就重新执行kolla-ansible reconfigure -t cinder，让部署框架重新生成并挂载keyring；然后podman restart cinder_volume。不要手工去容器里复制文件，Kolla会在下次reconfigure时按模板覆盖重写。

5.2 Glance上传镜像报权限错误：认证用户缺池权限

现象：openstack image create --file centos.qcow2上传镜像返回500，glance-api日志出现rbd error: EACCES或Error reading rbd。

原因：client.openstack这个Ceph认证用户缺少对images池的写入权限。常见诱因是有人手动调整过Ceph的auth caps，或者镜像池创建后PG状态未完成就开始了上传测试。

解决：用ceph auth caps补齐权限，把三个核心池都授权进去：

ceph auth caps client.openstack mon 'allow r' osd 'allow rwx pool=images, allow rwx pool=volumes, allow rwx pool=vms'

改完权限后重启glance-api容器。强调一下，重启动作不能省，Ceph的权限变更不会热生效到已连接的客户端。

5.3 OSD写入倾斜，一块数据盘先写满

现象：ceph -s显示集群状态正常，但某个OSD的used空间是其他节点的两倍以上，整体写入速度明显下滑，个别OSD响应时间飙高。

原因：OSD权重和磁盘实际容量不匹配，或者新加OSD后没有做权重校正。CRUSH算法分配PG时偏向权重高的OSD，如果一块4TB盘和一块800GB盘权重一样，大容量盘会被分到更多PG，但容量小的盘先满，拖慢整个集群的恢复和写入。

解决：临时用ceph osd reweight-by-utilization 80把使用率超过80%的OSD降权，等数据平衡后再处理长期方案。生产环境不要直接用reweight命令暴力调整，逐个OSD处理，避免引发大规模数据平衡风暴。测试环境可以直接重建OSD来验证这个坑的现象和恢复过程。

注意：reweight-by-utilization只能缓解倾斜，根因是OSD规格不一致。正式环境应当在扩容时保证同组OSD容量一致，权重交给Ceph自动计算，不要手工乱改权重。

5.4 网络抖动导致monitor频繁切主

现象：ceph -s里monmap的leader偶尔变动，客户端写延迟从几毫秒突然跳到几百毫秒，fio的测试结果跑三次三个样。

原因：存储网络没有独立，public网络和cluster网络共用千兆链路。Ceph的monitor心跳默认每5秒一次，网络拥塞导致心跳丢包，monitor选举被反复打断，整个集群的写入路径跟着不稳定。

解决：把cluster网络单独接到存储交换机上。Kolla部署环境下，如果Ceph使用独立存储网，需要在globals.yml里配置ceph_cluster_network指向专网网段，同时确保storage节点的第二块网卡接入该网段。这个坑的记录价值很高——网络规划对性能测试结果的影响，常常比OSD数量更明显。

5.5 内核RBD驱动特性不兼容导致挂载失败

现象：云主机启动后块设备无法识别，或者qemu直接报unsupported feature；宿主机dmesg里出现rbd: unknown feature提示。

原因：宿主机内核的rbd模块不支持新版Ceph默认开启的部分特性，比如exclusive-lock、object-map、fast-diff、deep-flatten。Kolla的qemu rbd客户端会向集群声明支持这些特性，但宿主机内核模块版本太老时，直连rbd设备就会失败。

解决：测试环境最快的修复方案是在ceph.conf的[client]段追加一行rbd default features = 13，然后重启所有使用rbd的客户端容器。13这个值是exclusive-lock、object-map、fast-diff、deep-flatten的组合数值，兼容Luminous及之后的大多数环境。生产环境不要图省事修改默认特性值，优先升级宿主机内核到支持新特性的版本。这点必须写进测试报告，否则后续环境复现时会在挂载环节卡住。

6. 让测试报告能拍板的四个记录习惯

版本和环境上下文写死。我会在报告的第一页放一张表，列出Ceph版本、OpenStack版本、内核版本、Kolla镜像tag、存储网络类型、数据盘型号。没有这组信息，所有性能数据都是孤立的——别人复现不了，你自己三个月后也看不懂当时为什么数值长这样。

原始数据不少于结论数据。测试报告里既要有汇总表，也要保留至少一份完整的fio输出、rados bench原始输出。汇总表可以被美化，原始输出不会。决策者争论数据时，直接翻原始日志比解释口径更有效。

失败记录单独立章。云硬盘创建ERROR、monitor切主、OSD倾斜，这些内容在第五章里每条都是现象、原因、解决三段式。别人照做时遇到同类问题，翻到对应段落就能定位，这比把成功流程抄十遍有价值得多。

参数明细和变更记录放在附录。测试过程中改过的每个参数——rbd default features、osd_memory_target、Ceph pool的size值——都按时间线记录下来。我自己最深的教训是：一次性能测试数据异常，查了半天最后发现是前一天有人把volumes池的副本数从3改成了2。如果当时有参数变更记录，十分钟就能定位。这个习惯后来成了我的固定流程，每次测试前拍一张当前环境的参数快照，测试完再拍一张，两张对比就是参数变更记录。

希望这些方法和踩坑记录帮到你——不管你是准备验收一套OpenStack+Ceph环境，还是正在写自己的安装测试报告，把测试场景和失败记录写到能复现的程度，这套方案才算真正交付完成。

本文还有配套的精品资源，点击获取