简介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 root192.168.10.11 ssh-copy-id -f -i ~/ceph.pub root192.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 61PG 数的设置是这里面的一个常见坑。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-1e1c9c0f8bfeauth_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 poolvolumes, allow rwx poolvms # 创建 glance 用户授予 images 池的权限 sudo ceph auth get-or-create client.glance \ mon allow r \ osd allow rwx poolimagesKolla 的容器在启动时会把 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-volume4.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 4KRBD 层用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 --namerandwrite \ --rwrandwrite \ --bs4k \ --size2G \ --iodepth32 \ --numjobs4 \ --ioenginelibaio \ --direct1 \ --runtime120 \ --time_based \ --group_reporting三层数据放在一张表里对照能暴露出一个非常典型的问题如果 RADOS 层吞吐正常虚拟机内 fio 性能直线下降问题几乎一定出在 QEMU 的缓存策略或网络虚化开销上如果 RBD 层和 RADOS 层都差才需要怀疑 OSD 数量、副本模式或者网络带宽。这也是我坚持三层都测的原因——只测虚拟机内数据出了问题根本不知道往哪查。4.3 报告里必须有的一张参数表IOPS、带宽、时延的合理区间测试报告文档里如果没有一张可以对照的基准表数据就只是数字。我整理了一张针对三节点测试环境的经验表硬件配置是单节点 8 核 CPU、32GB 内存、两块 NVMe SSD 做 OSD万兆网络连接测试层级测试模式期望区间说明RADOS4M 顺序写800MB/s - 1200MB/s三副本下写放大带宽会低于单盘极限RADOS4K 随机读15000 - 30000 IOPS内存足够时 OSD 缓存命中率高波动大RBD4M 顺序写600MB/s - 1000MB/s受 QEMU 层和网络协议栈影响RBD4K 随机写8000 - 15000 IOPS如果低于 5000检查副本和网络虚拟机内 fio4K 随机写3000 - 8000 IOPS受虚拟化开销影响数值会明显下降这张表的参考价值在于如果测试数据低于下限很多或者高于上限很多都应该停下来检查。低于下限是性能有隐患高于上限通常是测试参数没设对比如 fio 开了缓存或没加direct1测出来的数据是内存速度不是存储速度。报告里我会附带每个测试命令的实际参数避免三个月后回看文档时已经忘了数据是怎么得来的。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 没加direct1时读取直接命中内存测的是缓存速度。另一个常见原因是 fio 的ioenginepsync在虚拟化环境里会退化本身就无法充分发挥块设备性能。解决fio 必须加direct1绕过宿主机缓存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 architectureaarch64明确绑定。更稳妥的做法是在计算节点上给 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 21 || 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 接入时省下一些毫无必要的排查时间。本文还有配套的精品资源点击获取