简介：OpenStack与Ceph的集成是企业构建云平台时重点关注的存储方案之一。这份安装测试报告面向云平台运维、架构设计与存储选型人员，定位为可落地的工程参考资料。文档从云计算基础、OpenStack组件与VMware对比、Ceph架构与核心组件入手，解释CRUSH映射、RADOS强一致性与容错机制，让读者能在动手部署前建立清晰认知；再结合本地YUM源配置与主机规划说明，展示从环境准备到安装测试的完整路径。报告为docx格式，共1个文件，包体876KB，结构清晰、便于阅读和复制关键配置思路。已有254人学习浏览，适合希望打通OpenStack计算节点与Ceph后端存储、降低单点故障风险并提升扩展能力的实施与运维人员参考，也可作为内部技术分享或选型评估的补充材料。

1. 一份安装测试报告背后：OpenStack 与 Ceph 到底在解决什么

不少人第一次拿到「OpenStack Ceph分布式存储安装测试报告.docx」这类文档，心里最大的疑惑是：OpenStack 是云计算管理平台，Ceph 是分布式存储，这两者为什么要放到一起测？答案其实很直接——OpenStack 本身不存数据，它的虚拟机磁盘、镜像、块设备都需要一个后端存储来承载，而 Ceph 几乎是这个位置最主流、也是生产环境里验证过最多次的选择。这篇笔记我按照自己实际做过的一套 OpenStack 云平台搭建流程，把 Ceph 的安装、接入和测试拆开讲清楚：新手照着能跑通最小环境，熟手可以直接拿去对照自己的部署参数和排错思路。

2. 先想清楚再用：Ceph 在 OpenStack 里扛下哪四类存储职责

2.1 块存储、镜像、临时磁盘与共享文件：Ceph 的四个角色

OpenStack 本身是“无状态”的，控制节点上的数据库、消息队列可以本地化，但真正给用户用的数据面必须落到外部存储。Ceph 在 OpenStack 生态里通常同时承担四个角色，这也是安装测试报告里必须分别覆盖的四条验证链路。

第一条是 Cinder 块存储。用户创建云硬盘时，Cinder 通过 RBD 协议在 Ceph 里建一个块设备，挂载到虚拟机后就是一个独立磁盘。这个场景对延迟最敏感，因为云硬盘的每次读写都直接转化为 Ceph 的 RADOS 对象操作。第二条是 Glance 镜像存储。上传的 QCOW2 镜像文件被拆成对象存进 Ceph 的镜像池，创建虚拟机时 Nova 会直接从 Ceph 克隆镜像到临时盘，省去了镜像下载和格式转换，这也是 Ceph 方案比本地存储方案更顺滑的地方。

第三条是 Nova 临时磁盘。OpenStack 默认把实例的系统盘放在计算节点的本地磁盘上，但用 Ceph 做 ephemeral backend 之后，虚拟机系统盘也落到 Ceph 里，换来的是 live migration 可以跨节点秒级完成。第四条是 Manila 共享文件系统，用 CephFS 提供服务，适合多个虚拟机并发读写同一份数据的场景。

我在测试报告里习惯把四条链路分开记录，因为它们的性能特征完全不同：块存储看单卷 IOPS 和延迟，镜像存储看并发克隆速度，临时盘看批量创建虚拟机的吞吐，共享文件系统看元数据操作的延迟。混在一起测出来的数据没有任何参考价值。

2.2 为什么不是本地盘也不是 MinIO：选型边界与替代关系

有人会问：我用计算节点自带的 NVMe 本地盘，或者用 MinIO 这类对象存储，能替代 Ceph 吗？这个问题的答案取决于你站在哪一层看。

本地盘的性能确实优于 Ceph，尤其是单卷 IOPS 可以轻松做到十万以上，而 Ceph 三副本下同样硬件大概只能到两三万。但本地盘的代价是管理和调度成本——虚拟机漂移到另一台机器时数据要跟着迁移，快照、克隆、远程备份全都要自己实现。换到 Ceph 之后，Cinder 的快照、克隆、加密都是现成能力，运维只需要管好 OSD 和 PG，不需要关心某块盘属于谁。

MinIO 则是另一条路线：它是纯对象存储，S3 接口非常成熟，安装和运维也简单。但在 OpenStack 生态里，MinIO 只能替代 Swift 的对象存储服务，接不了 Cinder 块设备，也接不了 Glance 镜像——不是不能接，是接入方式非常别扭，需要额外的网关层把 S3 转成 RBD，性能和可靠性都要打折。所以 MinIO 不是 Ceph 的替代者，更像是 Ceph 的补充者，在需要 S3 兼容接口给外部应用使用时才引入。这也是为什么绝大多数 OpenStack 生产部署最终都收敛到 Ceph：一个存储集群同时喂饱块、镜像、临时盘和文件系统四张嘴，运维口径统一，故障域也更好规划。

3. 用 Kolla-Ansible 与 Cephadm 拉起环境：最小可用部署流程

3.1 前置条件与网络规划：3 个管理面 2 个数据面

整个 OpenStack 云平台搭建里，最容易在后期翻车的不是软件安装，而是网络规划。我吃过一次亏：刚开始做测试环境时把 Ceph 的 public network 和管理网络混在一个网段，结果 OSD 之间的数据同步直接占满了业务带宽，虚拟机网络延迟飙到几百毫秒。

这里我遵循的规划原则是：至少划分三个管理面——OpenStack 控制面、Ceph public 网络、Ceph cluster 网络，外加两个数据面——虚拟机业务网络和存储后端网络。控制面承载 API 请求和数据库连接，Ceph public 网络承载客户端读写，Ceph cluster 网络专门跑 OSD 之间的数据复制和心跳，业务网络走 Neutron 的 Overlay，存储后端网络走硬件交换机做独立 VLAN。

在测试环境里可以适当合并，但 public 和 cluster 必须分开。因为 Ceph 的 cluster 网络数据量极大，副本数的每一次写放大都会经过这里，只要和业务网混在一起，IO 稍微高一点就能把你整个云平台拖垮。我一般用 10Gbps 网卡做存储后端，至少两个网口绑定，管理面 1Gbps 就够。

硬件方面，三台物理机是最低配置：一台跑 Kolla-Ansible 部署的控制节点兼任 Ceph Monitor，两台做计算节点兼任 OSD 存储节点。每台机器至少 64GB 内存、4 核以上 CPU，测试数据的存储盘用独立的 SSD 或 NVMe，不要用系统盘。内存紧张时 Ceph 会疯狂交换，这是新手最容易忽略的配置瓶颈。

3.2 用 cephadm 部署 Ceph 集群：命令与初始化参数

Ceph 的部署工具演进过很多轮，从 ceph-ansible 到 cephadm，现在官方主推 cephadm。我建议直接放弃旧工具，因为 cephadm 用容器方式管理整个集群，升级和回滚都简单得多。以下是我在测试环境里的完整初始化流程。

先准备一个管理节点，安装 cephadm 工具并拉起第一个 Monitor：

# 下载 cephadm 并授权执行 curl --silent --remote-name --location https://github.com/ceph/ceph/raw/v17.2.6/src/cephadm/cephadm chmod +x cephadm # 把 cephadm 安装到系统目录 sudo ./cephadm add-repo --release quincy sudo ./cephadm install # bootstrap 创建第一个 monitor 和 manager sudo cephadm bootstrap \ --mon-ip 192.168.10.10 \ --cluster-network 192.168.20.0/24 \ --ssh-user root \ --skip-pull \ --initial-dashboard-password ChangeMe123 # 确认集群基本状态 sudo ceph -s

这段命令有几个参数值得展开。--cluster-network指定 OSD 之间的数据同步网段，前面说过的独立存储后端网络就是在这里生效的。--skip-pull在离线环境或镜像源不稳定的情况下很重要，否则 bootstrap 会因为拉取容器镜像失败而中止。--initial-dashboard-password设置了 Ceph Dashboard 的初始密码，后续可以通过ceph dashboard set-*命令修改。

bootstrap 完成后，把另外两台机器加进集群作为 OSD 节点：

# 在管理节点向新节点同步密钥并添加 host sudo ceph cephadm get-pub-key > ~/ceph.pub ssh-copy-id -f -i ~/ceph.pub root@192.168.10.11 ssh-copy-id -f -i ~/ceph.pub root@192.168.10.12 sudo ceph orch host add node1 192.168.10.11 sudo ceph orch host add node2 192.168.10.12 # 让 cephadm 自动发现并部署 OSD（按设备路径过滤，避免系统盘被误用） sudo ceph orch apply osd --all-available-devices \ --filter-out /dev/sda # 查看 OSD 部署进度 sudo ceph orch ps sudo ceph -s

这里最关键的是--filter-out /dev/sda。默认情况下--all-available-devices会把所有没有分区的裸设备都当成 OSD，如果不加过滤条件，系统盘会被格式化掉，数据直接归零。后面ceph orch ps用来观察服务状态，如果某个 OSD 部署失败，要看ceph orch osd status或者journalctl -u ceph-osd@*的日志。

接下来创建存储池。OpenStack 需要至少三个池：镜像池、卷池、虚拟机临时盘池：

# 创建三个 pool，分别设置 PG 数 sudo ceph osd pool create volumes 128 sudo ceph osd pool create images 128 sudo ceph osd pool create vms 128 # 为 RBD 应用开启 layering 特性，支持快照和克隆 sudo ceph osd pool application enable volumes rbd sudo ceph osd pool application enable images rbd sudo ceph osd pool application enable vms rbd # 给 RBD 设置默认特性（去掉不支持旧内核的 exclusive-lock 等） sudo ceph config set global rbd_default_features 61

PG 数的设置是这里面的一个常见坑。128 个 PG 对于 3 个 OSD 的测试环境来说偏大，但考虑到后续可能扩容，这个数字是合理的。计算 PG 的通用公式是：PG数 = 副本数 × 数据总量(GB) ÷ 期望单PG数据量(GB)，单 PG 容量控制在 50GB 到 100GB 之间比较稳妥。值得注意是rbd_default_features 61这个参数，61 是只开启 layering、striping、exclusive-lock、object-map 这几个特性的十进制值，避免开启 fast-diff 和 deep-flatten 导致内核 RBD 模块无法加载。生产环境如果用的内核版本较新，可以调成61或者直接使用ceph osd pool set逐项调整。

3.3 把 Ceph 挂进 Kolla-Ansible 的 OpenStack：关键配置项

Ceph 集群就绪后，我开始部署 OpenStack。现在的部署方式里，Kolla-Ansible 属于容器化部署的事实标准，一条命令就能拉起全套服务，后续升级也比较干净。以下面的/etc/kolla/globals.yml片段为准：

# kolla 配置文件：指定部署节点与网络 kolla_base_distro: "ubuntu" kolla_install_type: "source" openstack_release: "zed" # 存储后端统一指向 ceph enable_cinder: "yes" enable_cinder_backend_rbd: "yes" enable_glance_backend_ceph: "yes" enable_manila_backend_cephfs: "yes" # rbd 连接信息 cinder_backend_ceph: enabled: True pool: "volumes" auth_username: "cinder" auth_uuid: "1e0e8e64-c4dc-4d9e-8f10-9b1b62b99e0e" ceph_conf: "/etc/ceph/ceph.conf" rbd_store_chunk_size: 4194304 rados_connect_timeout: 5 # glance 镜像存储 glance_backend_ceph: pool: "images" auth_username: "glance" auth_uuid: "4a3f2f0f-8e50-4c4f-b1c4-1e1c9c0f8bfe"

auth_uuid是 Ceph 里为 OpenStack 各服务创建的 client keyring 的 cap 标识。在部署之前，需要在 Ceph 里先给 cinder、glance、nova、manila 各自创建认证用户并分配池权限：

# 创建 cinder 用户并只授予 volumes 池的权限 sudo ceph auth get-or-create client.cinder \ mon 'allow r' \ osd 'allow rwx pool=volumes, allow rwx pool=vms' # 创建 glance 用户，授予 images 池的权限 sudo ceph auth get-or-create client.glance \ mon 'allow r' \ osd 'allow rwx pool=images'

Kolla 的容器在启动时会把 Ceph 的 keyring 挂载到容器内部，所以ceph.conf和 keyring 文件必须放在 Kolla 节点的/etc/kolla/config/ceph/目录下。很多人在这一步踩坑：容器起来后报access denied，检查 Ceph 权限没问题，最后发现是 Kolla 没有读到 keyring，因为ceph.client.cinder.keyring的文件名不对。Kolla 默认查找的文件名格式是ceph.client.<用户名>.keyring，必须严格按这个规则命名。

全部配置写完后，执行部署：

# 生成密码文件 kolla-genpwd # 检查配置 kolla-ansible prechecks # 部署 openstack（首次部署时拉镜像较久，可加 -v 看日志） kolla-ansible deploy # 生成 openrc 环境变量文件 kolla-ansible post-deploy

这里有个测试环境常用的技巧：如果只想测试存储链路，可以先用enable_nova_backend_ceph: "yes"打开 Nova 临时盘后端。注意 Nova 的临时盘池就是前面创建的vms池，并且 Nova 的 RBD 用户权限需要同时覆盖vms池和volumes池，否则虚拟机创建时冷迁移会失败。

4. 把安装测试报告做厚：功能、性能与数据面全链路验证

4.1 功能验证：从 Glance 镜像到 Cinder 卷的完整链路

部署完成之后，真正能看出系统是否健康的不是ceph -s，而是 OpenStack 侧的一条完整业务链路。我的测试报告第一步永远是从镜像上传开始，因为这条链路串联了 Glance、Cinder、Nova 和 Ceph 四个组件。

source /etc/kolla/admin-openrc.sh # 上传测试镜像（这里用 cirros 小镜像，测试环境足够） openstack image create \ --disk-format qcow2 \ --container-format bare \ --file /opt/cirros-0.6.1-x86_64-disk.img \ cirros-test # 基于镜像创建云硬盘，验证 Cinder 后端 openstack volume create \ --size 10 \ --image cirros-test \ --bootable \ test-volume # 创建虚拟机并把云硬盘挂载上去 openstack server create \ --flavor m1.small \ --image cirros-test \ --volume test-volume \ --network test-net \ test-server openstack server add volume test-server test-volume

这个流程跑通之后，我还会专门做一次冷迁移和快照恢复测试。OpenStack 里的冷迁移会把虚拟机磁盘整体复制到另一台计算节点，如果 Nova 临时盘后端是 Ceph，系统盘本身就是 RBD 设备，迁移只是修改映射关系，不需要数据复制，所以应该在几秒内完成。如果这个步骤卡住，多半是nova-compute和 Ceph 之间的认证配置有问题，或者计算节点无法访问 Ceph 的 public 网络。

镜像上传后可以顺手检查 Ceph 侧的对象分布情况，用于后续写入测试报告的状态部分：

# 查看 images 池中实际生成了哪些对象 rados -p images ls | head -20 # 查看某个 rbd 镜像的快照和磁盘使用 rbd -p images snap ls cirros-test rbd -p volumes du test-volume

4.2 性能基线：rados bench、rbd bench 与 fio 怎么组合

功能链路没问题后，性能测试才有意义。我在测试报告里会分三层做性能基线：Ceph 原生层、RBD 块设备层、虚拟机内文件系统层。三层数据合在一起才能定位瓶颈。

Ceph 原生层用rados bench测 RADOS 对象的写入和读取吞吐：

# 从客户端节点写 1GB 数据，4MB 对象大小，持续 120 秒 rados bench -p volumes 120 write --object-size 4M --block-size 4M --no-cleanup # 换读模式 rados bench -p volumes 120 seq --object-size 4M --block-size 4M # 测随机读（4KB 小对象，贴近数据库场景） rados bench -p volumes 120 rand --object-size 4K --block-size 4K

RBD 层用rbd bench-write测试块设备在 Ceph 里的裸写性能：

# 创建一个测试用 rbd 卷 rbd -p volumes create bench-vol --size 8G # 顺序写 4MB 块，测吞吐 rbd bench-write -p volumes bench-vol \ --io-size 4194304 \ --io-threads 16 \ --io-total 2G \ --io-pattern seq # 随机写 4KB 块，测 IOPS rbd bench-write -p volumes bench-vol \ --io-size 4096 \ --io-threads 32 \ --io-total 512M \ --io-pattern rand

虚拟机内部跑fio才是用户最终感知到的性能，也是最接近生产场景的指标：

# 在虚拟机内部安装 fio，设置好挂载点后执行： fio --name=randwrite \ --rw=randwrite \ --bs=4k \ --size=2G \ --iodepth=32 \ --numjobs=4 \ --ioengine=libaio \ --direct=1 \ --runtime=120 \ --time_based \ --group_reporting

三层数据放在一张表里对照，能暴露出一个非常典型的问题：如果 RADOS 层吞吐正常，虚拟机内 fio 性能直线下降，问题几乎一定出在 QEMU 的缓存策略或网络虚化开销上；如果 RBD 层和 RADOS 层都差，才需要怀疑 OSD 数量、副本模式或者网络带宽。这也是我坚持三层都测的原因——只测虚拟机内数据，出了问题根本不知道往哪查。

4.3 报告里必须有的一张参数表：IOPS、带宽、时延的合理区间

测试报告文档里如果没有一张可以对照的基准表，数据就只是数字。我整理了一张针对三节点测试环境的经验表，硬件配置是单节点 8 核 CPU、32GB 内存、两块 NVMe SSD 做 OSD，万兆网络连接：

这张表的参考价值在于：如果测试数据低于下限很多，或者高于上限很多，都应该停下来检查。低于下限是性能有隐患，高于上限通常是测试参数没设对，比如 fio 开了缓存或没加direct=1，测出来的数据是内存速度，不是存储速度。报告里我会附带每个测试命令的实际参数，避免三个月后回看文档时已经忘了数据是怎么得来的。

5. 避坑清单：部署与测试里最常见的 5 个翻车现场

5.1 PG 数设错导致集群状态不均衡

现象：部署完成几天后ceph -s显示PG_AVAILABILITY告警，部分 PG 长时间处于degraded状态，数据迁移速度极慢。

原因：我在创建 pool 时没有按 OSD 数量计算 PG 数，直接用了默认值。测试环境里 3 个 OSD，如果 PG 数只有 8，每个 OSD 承担的数据重分布压力会非常大，而且 Ceph 的负载均衡算法在这种小规模集群里反应很迟钝。

解决：先把目标 pool 的 PG 数调大，ceph osd pool set volumes pg_num 128，等集群重新平衡后再调pgp_num。注意不要一次调太多，最好分阶段，避免 OSD 同时做大量迁移。正确的计算方式是：先把期望的 PG 总数算出来，再用pg_num = 期望总数 ÷ 副本数分配到每个池。

5.2 Kolla 容器访问 Ceph 报权限认证失败

现象：openstack volume create能成功，但openstack server create时 Nova 日志报error connecting to ceph cluster: Access denied。

原因：Kolla 容器内部没有正确挂载 Ceph 的 keyring。Kolla 的 RBD 支持依赖/etc/kolla/config/ceph/目录下的ceph.client.cinder.keyring，文件名带不带client前缀、keyring 里有没有对应用户的key，都会导致认证失败。

解决：确认三件事。第一，ceph auth get client.cinder能拿到 key；第二，在 Kolla 控制节点上把 keyring 内容保存为/etc/kolla/config/ceph/ceph.client.cinder.keyring；第三，ceph.conf里auth_supported = cephx必须保留。全部确认后重新执行kolla-ansible reconfigure，不要用deploy，否则会重建全部容器浪费不少时间。

5.3 磁盘性能测试结果受虚拟机缓存影响而失真

现象：虚拟机内 fio 测出的读性能高达数万 MB/s，远超物理硬件极限。

原因：QEMU 默认的 virtio-blk 缓存策略允许部分数据落在宿主机 page cache 里，fio 没加direct=1时读取直接命中内存，测的是缓存速度。另一个常见原因是 fio 的ioengine=psync在虚拟化环境里会退化，本身就无法充分发挥块设备性能。

解决：fio 必须加direct=1绕过宿主机缓存，IO 引擎换成libaio或io_uring。如果想在测试报告中给出合理数据，还要同时记录宿主机侧的iostat -x 1和 Ceph 侧的ceph osd perf输出，双端对照才能证明数据真的落到了 OSD。

5.4 节点时间不同步引发 Ceph Monitor 崩溃

现象：ceph -s显示clock skew告警，Monitor 之间频繁切换 leader，严重时ceph mon status直接报错。

原因：Ceph 对节点间时钟偏移非常敏感，超过mon-clock-skew-max阈值（默认 0.05 秒）就会触发安全机制。测试环境物理机通常没有配置统一的 NTP 源，加上 Kolla 容器内的时钟和宿主机又有一层隔离，时间偏差很容易超标。

解决：所有节点统一配置 chrony，时间源指向同一条 NTP 服务器，并验证chronyc sources -v输出正常。在部署 Ceph 之前必须先做这一步，因为 Monitor 和 OSD 起来之后再加时间同步，集群已经产生的偏差可能引发不可预期的故障。

5.5 多架构镜像测试时 QEMU 模拟器拖垮 IO

现象：在 x86 计算节点上用 QEMU 部署 ARM 架构虚拟机时，镜像创建成功但内部 IO 性能极低，CPU 占用率飙高。

原因：Nova 调度默认没有感知镜像架构，直接把 ARM 镜像调度到 x86 节点上跑，QEMU 用软件模拟整个指令集，CPU 消耗数倍增长，存储路径也被拖慢。

解决：测试报告里需要增加多架构验证页面时，我会先确认镜像属性hw_architecture是否正确标注，然后在 Nova 的 flavor 里配置os_architecture为x86_64或aarch64，并在创建虚拟机的命令里用--property architecture=aarch64明确绑定。更稳妥的做法是在计算节点上给 qemu 配置modprobe kvm并确认/dev/kvm存在，没有 KVM 硬件虚拟化支持时不要做多架构虚拟机测试，数据没有参考价值。

6. 让报告可复现：把验证命令沉淀成一套巡检脚本

安装测试报告最大的问题是做完一次就丢，等过了两个月集群出问题，再想对同样参数做对照测试，环境已经变得面目全非。我现在每完成一轮测试，会顺手把验证命令沉淀成一个可重复执行的脚本，挂到 cron 或者 GitLab CI 里定时跑。这个脚本不需要很复杂，但要把上面所有关键检查项自动化和数字化。

以下是我测试环境里维护的一个极简版本：

#!/bin/bash # openstack-ceph-healthcheck.sh # 用法: ./openstack-ceph-healthcheck.sh source /etc/kolla/admin-openrc.sh export CEPH_CONF=/etc/ceph/ceph.conf # 输出时间戳，便于后续对账 echo "===== $(date +%F-%T) health check start =====" # 1. Ceph 集群状态 ceph -s | tee -a health_report.log # 2. OpenStack 服务状态 openstack service list -f value | awk '$3 != "UP" {print "SERVICE DOWN:", $0}' >> health_report.log # 3. Cinder 卷和 Nova 实例数变化 openstack volume list --all-projects -f value | wc -l >> health_report.log openstack server list --all-projects -f value | wc -l >> health_report.log # 4. RBD 完整性检查（缺失对象会直接报错） rbd -p volumes ls | while read vol; do rbd info -p volumes "$vol" >/dev/null 2>&1 || echo "RBD broken: $vol" >> health_report.log done

这段脚本看起来简单，但它覆盖了四个关键维度：基础设施健康状态、OpenStack 控制面服务状态、资源总量变化趋势、RBD 设备的可读性。我把 stdout 和 stderr 都追加到同一个日志文件，每天定时跑一次，三个月后翻日志就能一眼看出某段时间的性能骤降是否伴随了服务重启或 PG 状态变化。

巡检脚本跑完后，我还会额外做一个手动操作：把一个 1GB 的临时卷从实例 A 卸载，挂到实例 B 上，然后对比两次的volume attach时间。这个操作没法完全自动化，但它能验证 Cinder 的卷管理数据库、Nova 的挂载状态、Ceph 的锁机制三者之间是否协调一致，是安装测试报告里最接近真实运维动作的验证手段。

这套习惯帮我避开了很多次线上事故。现在每次做完测试，我会先问自己三个问题：这个数据在三天后还能不能重新生成？这个参数遇到故障时有没有告警可查？这个操作能不能用一条命令回滚？如果答案都是肯定的，这份安装测试报告才算真正完成了它的使命。Ceph 和 OpenStack 的复杂度不会因为一份文档而降低，但有了可复现的脚本，至少能让下一次排查站在上一次的完整数据之上。希望这些方法能帮你在做 OpenStack 云平台搭建和 Ceph 接入时省下一些毫无必要的排查时间。

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