拓冰网站定制 
简介这份《OpenStack Ceph分布式存储安装测试报告》面向云计算运维工程师、存储架构学习者及OpenStack平台部署人员聚焦开源云平台与分布式存储的集成实践。报告从云计算基础概念切入系统梳理OpenStack组件构成及其与VMware的差异并深入讲解Ceph的架构原理包括OSD、MDS、RGW、MON等核心组件、CRUSH数据映射算法、RADOS强一致性与容错机制以及高性能、高可靠、高扩展等优势同时说明在OpenStack中选择Ceph作为后端存储的考量与本次测试的主机规划。资源包内含1个docx文档约876KB结构完整、目录清晰便于按章节查阅。目前已有254人学习适合希望理解OpenStack与Ceph集成逻辑、掌握部署前知识储备与测试思路的读者参考。1. OpenStack 接 Ceph为什么测试报告比安装本身更值钱很多人搭 OpenStack 私有云第一步想的是把虚拟机跑起来第二步才想起存储。等到卷创建卡住、实例迁移失败、快照回滚丢数据才回头翻 Ceph 集群的状态。我见过太多环境ceph -s显示 HEALTH_OK但 Nova 创建卷就是超时Glance 上传镜像就是 500。问题不在 Ceph 本身而在 OpenStack 各组件和 Ceph 之间的对接参数、认证方式、池规划没有经过系统性验证。这份安装测试报告要解决的就是把「装完能跑」推进到「跑得稳、测得全、出了问题知道看哪里」。它适合正在用 Packstack 或手动方式搭 OpenStack 云平台、准备把后端存储从本地 LVM 切到 Ceph 的运维和开发人员。下面按实际落地顺序把安装、对接、测试、排坑串成一条可复现的路径。2. 装 Ceph 集群前必须定死的四个参数2.1 为什么先定 PG 数和副本数而不是先装包Ceph 集群的性能和可靠性在装包之前就被两个参数锁死了副本数size和归置组数量pg_num。副本数决定一份数据存几份生产环境常见做法是 3 副本测试环境为了省资源可以设 2但设 1 就失去了分布式存储的意义。PG 数决定数据分片的粒度设少了会导致数据分布不均、单 OSD 过载设多了会消耗大量内存和 CPU。我一般按公式估算PG总数 (OSD总数 × 100) / 副本数然后向上取到最接近的 2 的幂。比如 6 个 OSD、3 副本算出来是 200向上取 256。这个值在集群建好后调整代价很高所以要在创建池之前定下来。另一个容易忽略的是mon_osd_full_ratio和mon_osd_nearfull_ratio。默认 full 是 0.95nearfull 是 0.85。测试环境磁盘小写满 85% 就开始告警写满 95% 直接拒绝写入Nova 创建卷会直接失败。我一般把 nearfull 调到 0.8full 调到 0.9留出足够的缓冲空间给恢复和重平衡。2.2 用 ceph-deploy 或手动方式跑通最小集群下面以三节点为例每台机器一块数据盘/dev/sdb系统盘/dev/sda。先在所有节点装好基础依赖然后在 admin 节点执行部署。这里用常见的ceph-deploy方式适合测试环境快速拉起。# 在所有节点执行安装依赖并配置时间同步 yum install -y epel-release yum install -y ceph ceph-radosgw chrony systemctl enable --now chronyd # 在 admin 节点执行创建集群目录并初始化 mon mkdir -p /etc/ceph cd /etc/ceph ceph-deploy new node1 node2 node3 # 修改 ceph.conf写入网络段和副本数 cat /etc/ceph/ceph.conf EOF public network 192.168.1.0/24 cluster network 192.168.1.0/24 osd pool default size 3 osd pool default min size 2 osd pool default pg num 256 osd pool default pgp num 256 EOF # 安装 ceph 到所有节点 ceph-deploy install node1 node2 node3 # 初始化 mon 并收集密钥 ceph-deploy mon create-initial ceph-deploy admin node1 node2 node3 # 部署 mgrLuminous 之后必须 ceph-deploy mgr create node1 # 添加 OSD每台机器一块数据盘 ceph-deploy osd create --data /dev/sdb node1 ceph-deploy osd create --data /dev/sdb node2 ceph-deploy osd create --data /dev/sdb node3这段脚本的关键点public network和cluster network在测试环境可以共用同一网段但生产环境建议分开避免客户端流量和副本复制流量互相干扰。osd pool default size 3表示默认三副本min size 2表示至少两份在线才允许写入。PG 数设 256 是给后续创建的池用的默认值实际创建池时还可以单独指定。装完后用ceph -s检查状态正常应该看到HEALTH_OK三个 mon 组成 quorumOSD 全部 up 且 in。如果看到HEALTH_WARN提示pools have too few placement groups说明 PG 数偏少需要调整。如果提示clock skew检查 chrony 是否同步。2.3 创建 OpenStack 专用池并做权限隔离Ceph 集群跑起来后不要直接用默认的rbd池给 OpenStack 用。常见做法是按组件分池Glance 存镜像、Cinder 存卷、Nova 存临时盘如果启用、Cinder Backup 存备份。每个池单独设 PG 数和副本数便于监控和调优。# 创建各组件专用池 ceph osd pool create volumes 256 256 ceph osd pool create images 128 128 ceph osd pool create backups 128 128 ceph osd pool create vms 128 128 # 启用 rbd 应用模式 ceph osd pool application enable volumes rbd ceph osd pool application enable images rbd ceph osd pool application enable backups rbd ceph osd pool application enable vms rbd # 创建 OpenStack 专用用户并授权 ceph auth get-or-create client.cinder mon allow r \ osd allow class-read object_prefix rbd_children, allow rwx poolvolumes, allow rwx poolvms, allow rx poolimages \ -o /etc/ceph/ceph.client.cinder.keyring ceph auth get-or-create client.glance mon allow r \ osd allow class-read object_prefix rbd_children, allow rwx poolimages \ -o /etc/ceph/ceph.client.glance.keyring ceph auth get-or-create client.cinder-backup mon allow r \ osd allow class-read object_prefix rbd_children, allow rwx poolbackups \ -o /etc/ceph/ceph.client.cinder-backup.keyring权限隔离的意义在于Glance 只能读写 images 池即使凭证泄露也动不了 volumes 池的数据。object_prefix rbd_children是 RBD 克隆操作必需的权限少了它快照克隆会失败。创建完 keyring 文件后需要拷贝到对应组件的节点上并确保权限是 640、属主是 ceph 或对应服务用户。3. 把 Ceph 接进 OpenStackGlance、Cinder、Nova 三处配置3.1 Glance 后端切到 Ceph 的配置与验证Glance 默认用本地文件存镜像切到 Ceph 后镜像直接以 RBD 形式存进 images 池多个 Glance 节点共享同一份存储不用再同步文件。配置改在/etc/glance/glance-api.conf。[glance_store] stores rbd default_store rbd rbd_store_pool images rbd_store_user glance rbd_store_ceph_conf /etc/ceph/ceph.conf rbd_store_chunk_size 8rbd_store_chunk_size 8表示镜像按 8MB 分块这个值影响上传大镜像时的并发效率测试环境用默认 8 即可生产环境如果镜像普遍超过 10GB可以调到 16 或 32。改完重启openstack-glance-api然后上传一个镜像验证。# 上传测试镜像 openstack image create --disk-format qcow2 --container-format bare \ --file cirros-0.5.2-x86_64-disk.img test-image # 在 Ceph 侧确认镜像已写入 rbd -p images ls如果rbd ls能看到镜像对应的块设备说明 Glance 对接成功。如果上传报 500先看/var/log/glance/api.log常见原因是 keyring 文件路径不对或权限不足。注意 Glance 节点上/etc/ceph/下必须有ceph.conf和ceph.client.glance.keyring且 glance 用户可读。3.2 Cinder 多后端配置与卷类型绑定Cinder 对接 Ceph 稍微复杂因为涉及卷类型和调度。配置在/etc/cinder/cinder.conf。[DEFAULT] enabled_backends ceph-volumes [ceph-volumes] volume_driver cinder.volume.drivers.rbd.RBDDriver rbd_pool volumes rbd_ceph_conf /etc/ceph/ceph.conf rbd_user cinder rbd_secret_uuid 通过 ceph auth get-key 生成的 uuid rbd_flatten_volume_from_snapshot false rbd_max_clone_depth 5 rbd_store_chunk_size 4rbd_secret_uuid不是随便填的需要先生成一个 UUID然后把 Cinder 用户的 key 写进 libvirt 的 secret 里这样 Nova 才能通过 libvirt 访问 Ceph 卷。步骤是# 生成 UUID UUID$(uuidgen) echo $UUID # 获取 cinder 用户的 key ceph auth get-key client.cinder # 在 Nova 计算节点上创建 libvirt secret cat /tmp/secret.xml EOF secret ephemeralno privateno uuid$UUID/uuid usage typeceph nameclient.cinder secret/name /usage /secret EOF virsh secret-define --file /tmp/secret.xml virsh secret-set-value --secret $UUID --base64 $(ceph auth get-key client.cinder)rbd_max_clone_depth 5控制从快照克隆卷的最大深度超过这个深度会触发 flatten 操作把克隆卷变成独立卷。设太小会导致频繁 flatten 影响性能设太大则克隆链过长删除卷时回收慢。测试环境 5 层够用。rbd_flatten_volume_from_snapshot false表示从快照创建卷时不立即扁平化保留克隆关系节省空间。配置完成后重启openstack-cinder-volume创建卷类型并绑定后端。openstack volume type create ceph-volumes openstack volume type set --property volume_backend_nameceph-volumes ceph-volumes openstack volume create --size 10 --type ceph-volumes test-volume创建成功后用rbd -p volumes ls应该能看到volume-uuid的块设备。如果卷一直卡在 creating看/var/log/cinder/volume.log常见原因是rbd_secret_uuid和 libvirt secret 不匹配或者 cinder 用户没有 volumes 池的写入权限。3.3 Nova 临时盘与镜像缓存对接 CephNova 对接 Ceph 有两个层面一是实例的临时盘ephemeral直接存 Ceph二是从 Glance 拉镜像时走 Ceph 克隆避免全量拷贝。配置在计算节点的/etc/nova/nova.conf。[libvirt] images_type rbd images_rbd_pool vms images_rbd_ceph_conf /etc/ceph/ceph.conf rbd_user cinder rbd_secret_uuid 同上images_type rbd表示实例磁盘用 RBDimages_rbd_pool vms指定临时盘池。这样创建实例时如果镜像在 Ceph 里Nova 会直接从镜像克隆一个卷给实例用速度比从文件拷贝快很多。注意rbd_user和rbd_secret_uuid要和 Cinder 保持一致因为 libvirt 用的是同一个 secret。改完重启openstack-nova-compute然后创建一个实例验证。如果实例卡在 spawning看/var/log/nova/nova-compute.log常见错误是rbd: failed to open pool说明计算节点上没有对应的 keyring 或 ceph.conf 路径不对。4. 安装测试报告里最容易翻车的五个点4.1 现象ceph -s健康但 OpenStack 创建卷超时原因通常是 Ceph 集群健康但 OpenStack 组件用的 keyring 权限不够或者rbd_secret_uuid没配。Ceph 的HEALTH_OK只反映集群自身状态不反映客户端认证是否通过。解决方法是先在 Ceph 节点上用rbd -p volumes --id cinder ls手动验证 cinder 用户能否访问池如果这条命令报权限错误说明 auth 配置有问题重新执行ceph auth get-or-create并确认 keyring 文件已分发到所有相关节点。4.2 现象Glance 上传镜像成功但实例启动失败镜像在 images 池里但计算节点上的 Nova 没有权限读 images 池。Nova 的rbd_user如果设成 cinder而 cinder 用户只有 volumes 和 vms 的权限没有 images 的读权限克隆就会失败。解决方法是给 cinder 用户加上allow rx poolimages或者单独给 Nova 配一个能读 images 的用户。我一般直接在 cinder 的 auth 里加上 images 的读权限省得维护两套凭证。4.3 现象Cinder 卷创建后容量显示为 0 或远小于申请值这是 Ceph 的rbd_default_features和 Cinder 的rbd_store_chunk_size不匹配导致的。Ceph 默认开启layering、exclusive-lock、object-map、fast-diff等特性如果 Cinder 驱动版本较老可能不识别某些特性导致卷元数据异常。解决方法是检查/etc/ceph/ceph.conf里的rbd_default_features测试环境可以临时设为 1仅 layering确认问题后再逐步开启。另外确认rbd_store_chunk_size在 Cinder 和 Glance 里保持一致不一致会导致镜像和卷的块大小不同影响克隆效率。4.4 现象删除实例后 Ceph 池空间不释放Nova 删除实例时如果rbd_flatten_volume_from_snapshot设成了 true克隆卷会变成独立卷删除实例后卷被删掉空间应该释放。但如果设成 false克隆链还在删除实例只是删掉了最上层的卷底层快照和镜像还占着空间。解决方法是定期用rbd du -p vms查看实际占用对不再使用的克隆链执行rbd flatten或直接删除底层快照。测试环境可以设rbd_flatten_volume_from_snapshot true牺牲一点创建速度换取空间回收的确定性。4.5 现象三副本集群写入性能远低于预期先检查ceph osd perf看各 OSD 的延迟如果某个 OSD 的 apply/commit 延迟明显高于其他可能是那块盘有问题。再检查网络cluster network如果和public network共用副本复制流量会挤占客户端流量。测试环境可以用iperf测一下节点间带宽如果只有百兆三副本写入会非常慢。解决方法是把cluster network分到独立的万兆网段或者至少做网卡绑定。另外确认osd journal是否放在了 SSD 上机械盘做 journal 会拖慢整体写入。5. 用 rados bench 和 fio 给测试报告补上硬数据安装测试报告如果只写「安装成功、功能正常」说服力不够。我一般会补两组数据Ceph 层面的rados bench和 OpenStack 卷层面的fio。rados bench直接测池的写入和读取带宽不经过 OpenStack能反映存储底座的真实能力。# 写测试4 个并发总共写 200 秒对象大小 4MB rados bench -p volumes 200 write --no-cleanup -b 4096 -t 4 # 顺序读测试 rados bench -p volumes 200 seq -t 4 # 清理测试数据 rados -p volumes cleanup-b 4096表示对象大小 4MB-t 4表示 4 个线程。测试结果里重点看Bandwidth和Average Latency。三副本、万兆网、SSD journal 的环境写带宽通常在 200-400 MB/s延迟在 10-20ms。如果写带宽只有几十 MB/s先查网络和 journal。fio则在挂载到实例的卷上跑测的是端到端性能。# 在实例内对数据盘跑 4K 随机写 fio --namerandwrite --ioenginelibaio --iodepth32 \ --rwrandwrite --bs4k --direct1 --size1G \ --numjobs4 --runtime60 --group_reportingiodepth32模拟高并发direct1绕过页缓存。4K 随机写的 IOPS 是衡量云盘性能的关键指标Ceph 三副本环境下单卷 4K 随机写能到 3000-5000 IOPS 算正常。如果低于 1000检查rbd_cache是否开启以及 OSD 的osd_op_threads是否够用。把这两组数据写进报告比只写「安装成功」有说服力得多。我习惯在报告里附上测试时间、集群规模、网络配置和关键参数这样别人复现时能直接对照。踩过的坑是rados bench的--no-cleanup会留下测试数据跑完一定要cleanup否则池空间被占满后续创建卷会失败。这个坑我翻过两次希望帮到你。本文还有配套的精品资源点击获取 OpenStack 对接 Ceph 存储：安装测试报告与性能验证实战
简介这份《OpenStack Ceph分布式存储安装测试报告》面向云计算运维工程师、存储架构学习者及OpenStack平台部署人员聚焦开源云平台与分布式存储的集成实践。报告从云计算基础概念切入系统梳理OpenStack组件构成及其与VMware的差异并深入讲解Ceph的架构原理包括OSD、MDS、RGW、MON等核心组件、CRUSH数据映射算法、RADOS强一致性与容错机制以及高性能、高可靠、高扩展等优势同时说明在OpenStack中选择Ceph作为后端存储的考量与本次测试的主机规划。资源包内含1个docx文档约876KB结构完整、目录清晰便于按章节查阅。目前已有254人学习适合希望理解OpenStack与Ceph集成逻辑、掌握部署前知识储备与测试思路的读者参考。1. OpenStack 接 Ceph为什么测试报告比安装本身更值钱很多人搭 OpenStack 私有云第一步想的是把虚拟机跑起来第二步才想起存储。等到卷创建卡住、实例迁移失败、快照回滚丢数据才回头翻 Ceph 集群的状态。我见过太多环境ceph -s显示 HEALTH_OK但 Nova 创建卷就是超时Glance 上传镜像就是 500。问题不在 Ceph 本身而在 OpenStack 各组件和 Ceph 之间的对接参数、认证方式、池规划没有经过系统性验证。这份安装测试报告要解决的就是把「装完能跑」推进到「跑得稳、测得全、出了问题知道看哪里」。它适合正在用 Packstack 或手动方式搭 OpenStack 云平台、准备把后端存储从本地 LVM 切到 Ceph 的运维和开发人员。下面按实际落地顺序把安装、对接、测试、排坑串成一条可复现的路径。2. 装 Ceph 集群前必须定死的四个参数2.1 为什么先定 PG 数和副本数而不是先装包Ceph 集群的性能和可靠性在装包之前就被两个参数锁死了副本数size和归置组数量pg_num。副本数决定一份数据存几份生产环境常见做法是 3 副本测试环境为了省资源可以设 2但设 1 就失去了分布式存储的意义。PG 数决定数据分片的粒度设少了会导致数据分布不均、单 OSD 过载设多了会消耗大量内存和 CPU。我一般按公式估算PG总数 (OSD总数 × 100) / 副本数然后向上取到最接近的 2 的幂。比如 6 个 OSD、3 副本算出来是 200向上取 256。这个值在集群建好后调整代价很高所以要在创建池之前定下来。另一个容易忽略的是mon_osd_full_ratio和mon_osd_nearfull_ratio。默认 full 是 0.95nearfull 是 0.85。测试环境磁盘小写满 85% 就开始告警写满 95% 直接拒绝写入Nova 创建卷会直接失败。我一般把 nearfull 调到 0.8full 调到 0.9留出足够的缓冲空间给恢复和重平衡。2.2 用 ceph-deploy 或手动方式跑通最小集群下面以三节点为例每台机器一块数据盘/dev/sdb系统盘/dev/sda。先在所有节点装好基础依赖然后在 admin 节点执行部署。这里用常见的ceph-deploy方式适合测试环境快速拉起。# 在所有节点执行安装依赖并配置时间同步 yum install -y epel-release yum install -y ceph ceph-radosgw chrony systemctl enable --now chronyd # 在 admin 节点执行创建集群目录并初始化 mon mkdir -p /etc/ceph cd /etc/ceph ceph-deploy new node1 node2 node3 # 修改 ceph.conf写入网络段和副本数 cat /etc/ceph/ceph.conf EOF public network 192.168.1.0/24 cluster network 192.168.1.0/24 osd pool default size 3 osd pool default min size 2 osd pool default pg num 256 osd pool default pgp num 256 EOF # 安装 ceph 到所有节点 ceph-deploy install node1 node2 node3 # 初始化 mon 并收集密钥 ceph-deploy mon create-initial ceph-deploy admin node1 node2 node3 # 部署 mgrLuminous 之后必须 ceph-deploy mgr create node1 # 添加 OSD每台机器一块数据盘 ceph-deploy osd create --data /dev/sdb node1 ceph-deploy osd create --data /dev/sdb node2 ceph-deploy osd create --data /dev/sdb node3这段脚本的关键点public network和cluster network在测试环境可以共用同一网段但生产环境建议分开避免客户端流量和副本复制流量互相干扰。osd pool default size 3表示默认三副本min size 2表示至少两份在线才允许写入。PG 数设 256 是给后续创建的池用的默认值实际创建池时还可以单独指定。装完后用ceph -s检查状态正常应该看到HEALTH_OK三个 mon 组成 quorumOSD 全部 up 且 in。如果看到HEALTH_WARN提示pools have too few placement groups说明 PG 数偏少需要调整。如果提示clock skew检查 chrony 是否同步。2.3 创建 OpenStack 专用池并做权限隔离Ceph 集群跑起来后不要直接用默认的rbd池给 OpenStack 用。常见做法是按组件分池Glance 存镜像、Cinder 存卷、Nova 存临时盘如果启用、Cinder Backup 存备份。每个池单独设 PG 数和副本数便于监控和调优。# 创建各组件专用池 ceph osd pool create volumes 256 256 ceph osd pool create images 128 128 ceph osd pool create backups 128 128 ceph osd pool create vms 128 128 # 启用 rbd 应用模式 ceph osd pool application enable volumes rbd ceph osd pool application enable images rbd ceph osd pool application enable backups rbd ceph osd pool application enable vms rbd # 创建 OpenStack 专用用户并授权 ceph auth get-or-create client.cinder mon allow r \ osd allow class-read object_prefix rbd_children, allow rwx poolvolumes, allow rwx poolvms, allow rx poolimages \ -o /etc/ceph/ceph.client.cinder.keyring ceph auth get-or-create client.glance mon allow r \ osd allow class-read object_prefix rbd_children, allow rwx poolimages \ -o /etc/ceph/ceph.client.glance.keyring ceph auth get-or-create client.cinder-backup mon allow r \ osd allow class-read object_prefix rbd_children, allow rwx poolbackups \ -o /etc/ceph/ceph.client.cinder-backup.keyring权限隔离的意义在于Glance 只能读写 images 池即使凭证泄露也动不了 volumes 池的数据。object_prefix rbd_children是 RBD 克隆操作必需的权限少了它快照克隆会失败。创建完 keyring 文件后需要拷贝到对应组件的节点上并确保权限是 640、属主是 ceph 或对应服务用户。3. 把 Ceph 接进 OpenStackGlance、Cinder、Nova 三处配置3.1 Glance 后端切到 Ceph 的配置与验证Glance 默认用本地文件存镜像切到 Ceph 后镜像直接以 RBD 形式存进 images 池多个 Glance 节点共享同一份存储不用再同步文件。配置改在/etc/glance/glance-api.conf。[glance_store] stores rbd default_store rbd rbd_store_pool images rbd_store_user glance rbd_store_ceph_conf /etc/ceph/ceph.conf rbd_store_chunk_size 8rbd_store_chunk_size 8表示镜像按 8MB 分块这个值影响上传大镜像时的并发效率测试环境用默认 8 即可生产环境如果镜像普遍超过 10GB可以调到 16 或 32。改完重启openstack-glance-api然后上传一个镜像验证。# 上传测试镜像 openstack image create --disk-format qcow2 --container-format bare \ --file cirros-0.5.2-x86_64-disk.img test-image # 在 Ceph 侧确认镜像已写入 rbd -p images ls如果rbd ls能看到镜像对应的块设备说明 Glance 对接成功。如果上传报 500先看/var/log/glance/api.log常见原因是 keyring 文件路径不对或权限不足。注意 Glance 节点上/etc/ceph/下必须有ceph.conf和ceph.client.glance.keyring且 glance 用户可读。3.2 Cinder 多后端配置与卷类型绑定Cinder 对接 Ceph 稍微复杂因为涉及卷类型和调度。配置在/etc/cinder/cinder.conf。[DEFAULT] enabled_backends ceph-volumes [ceph-volumes] volume_driver cinder.volume.drivers.rbd.RBDDriver rbd_pool volumes rbd_ceph_conf /etc/ceph/ceph.conf rbd_user cinder rbd_secret_uuid 通过 ceph auth get-key 生成的 uuid rbd_flatten_volume_from_snapshot false rbd_max_clone_depth 5 rbd_store_chunk_size 4rbd_secret_uuid不是随便填的需要先生成一个 UUID然后把 Cinder 用户的 key 写进 libvirt 的 secret 里这样 Nova 才能通过 libvirt 访问 Ceph 卷。步骤是# 生成 UUID UUID$(uuidgen) echo $UUID # 获取 cinder 用户的 key ceph auth get-key client.cinder # 在 Nova 计算节点上创建 libvirt secret cat /tmp/secret.xml EOF secret ephemeralno privateno uuid$UUID/uuid usage typeceph nameclient.cinder secret/name /usage /secret EOF virsh secret-define --file /tmp/secret.xml virsh secret-set-value --secret $UUID --base64 $(ceph auth get-key client.cinder)rbd_max_clone_depth 5控制从快照克隆卷的最大深度超过这个深度会触发 flatten 操作把克隆卷变成独立卷。设太小会导致频繁 flatten 影响性能设太大则克隆链过长删除卷时回收慢。测试环境 5 层够用。rbd_flatten_volume_from_snapshot false表示从快照创建卷时不立即扁平化保留克隆关系节省空间。配置完成后重启openstack-cinder-volume创建卷类型并绑定后端。openstack volume type create ceph-volumes openstack volume type set --property volume_backend_nameceph-volumes ceph-volumes openstack volume create --size 10 --type ceph-volumes test-volume创建成功后用rbd -p volumes ls应该能看到volume-uuid的块设备。如果卷一直卡在 creating看/var/log/cinder/volume.log常见原因是rbd_secret_uuid和 libvirt secret 不匹配或者 cinder 用户没有 volumes 池的写入权限。3.3 Nova 临时盘与镜像缓存对接 CephNova 对接 Ceph 有两个层面一是实例的临时盘ephemeral直接存 Ceph二是从 Glance 拉镜像时走 Ceph 克隆避免全量拷贝。配置在计算节点的/etc/nova/nova.conf。[libvirt] images_type rbd images_rbd_pool vms images_rbd_ceph_conf /etc/ceph/ceph.conf rbd_user cinder rbd_secret_uuid 同上images_type rbd表示实例磁盘用 RBDimages_rbd_pool vms指定临时盘池。这样创建实例时如果镜像在 Ceph 里Nova 会直接从镜像克隆一个卷给实例用速度比从文件拷贝快很多。注意rbd_user和rbd_secret_uuid要和 Cinder 保持一致因为 libvirt 用的是同一个 secret。改完重启openstack-nova-compute然后创建一个实例验证。如果实例卡在 spawning看/var/log/nova/nova-compute.log常见错误是rbd: failed to open pool说明计算节点上没有对应的 keyring 或 ceph.conf 路径不对。4. 安装测试报告里最容易翻车的五个点4.1 现象ceph -s健康但 OpenStack 创建卷超时原因通常是 Ceph 集群健康但 OpenStack 组件用的 keyring 权限不够或者rbd_secret_uuid没配。Ceph 的HEALTH_OK只反映集群自身状态不反映客户端认证是否通过。解决方法是先在 Ceph 节点上用rbd -p volumes --id cinder ls手动验证 cinder 用户能否访问池如果这条命令报权限错误说明 auth 配置有问题重新执行ceph auth get-or-create并确认 keyring 文件已分发到所有相关节点。4.2 现象Glance 上传镜像成功但实例启动失败镜像在 images 池里但计算节点上的 Nova 没有权限读 images 池。Nova 的rbd_user如果设成 cinder而 cinder 用户只有 volumes 和 vms 的权限没有 images 的读权限克隆就会失败。解决方法是给 cinder 用户加上allow rx poolimages或者单独给 Nova 配一个能读 images 的用户。我一般直接在 cinder 的 auth 里加上 images 的读权限省得维护两套凭证。4.3 现象Cinder 卷创建后容量显示为 0 或远小于申请值这是 Ceph 的rbd_default_features和 Cinder 的rbd_store_chunk_size不匹配导致的。Ceph 默认开启layering、exclusive-lock、object-map、fast-diff等特性如果 Cinder 驱动版本较老可能不识别某些特性导致卷元数据异常。解决方法是检查/etc/ceph/ceph.conf里的rbd_default_features测试环境可以临时设为 1仅 layering确认问题后再逐步开启。另外确认rbd_store_chunk_size在 Cinder 和 Glance 里保持一致不一致会导致镜像和卷的块大小不同影响克隆效率。4.4 现象删除实例后 Ceph 池空间不释放Nova 删除实例时如果rbd_flatten_volume_from_snapshot设成了 true克隆卷会变成独立卷删除实例后卷被删掉空间应该释放。但如果设成 false克隆链还在删除实例只是删掉了最上层的卷底层快照和镜像还占着空间。解决方法是定期用rbd du -p vms查看实际占用对不再使用的克隆链执行rbd flatten或直接删除底层快照。测试环境可以设rbd_flatten_volume_from_snapshot true牺牲一点创建速度换取空间回收的确定性。4.5 现象三副本集群写入性能远低于预期先检查ceph osd perf看各 OSD 的延迟如果某个 OSD 的 apply/commit 延迟明显高于其他可能是那块盘有问题。再检查网络cluster network如果和public network共用副本复制流量会挤占客户端流量。测试环境可以用iperf测一下节点间带宽如果只有百兆三副本写入会非常慢。解决方法是把cluster network分到独立的万兆网段或者至少做网卡绑定。另外确认osd journal是否放在了 SSD 上机械盘做 journal 会拖慢整体写入。5. 用 rados bench 和 fio 给测试报告补上硬数据安装测试报告如果只写「安装成功、功能正常」说服力不够。我一般会补两组数据Ceph 层面的rados bench和 OpenStack 卷层面的fio。rados bench直接测池的写入和读取带宽不经过 OpenStack能反映存储底座的真实能力。# 写测试4 个并发总共写 200 秒对象大小 4MB rados bench -p volumes 200 write --no-cleanup -b 4096 -t 4 # 顺序读测试 rados bench -p volumes 200 seq -t 4 # 清理测试数据 rados -p volumes cleanup-b 4096表示对象大小 4MB-t 4表示 4 个线程。测试结果里重点看Bandwidth和Average Latency。三副本、万兆网、SSD journal 的环境写带宽通常在 200-400 MB/s延迟在 10-20ms。如果写带宽只有几十 MB/s先查网络和 journal。fio则在挂载到实例的卷上跑测的是端到端性能。# 在实例内对数据盘跑 4K 随机写 fio --namerandwrite --ioenginelibaio --iodepth32 \ --rwrandwrite --bs4k --direct1 --size1G \ --numjobs4 --runtime60 --group_reportingiodepth32模拟高并发direct1绕过页缓存。4K 随机写的 IOPS 是衡量云盘性能的关键指标Ceph 三副本环境下单卷 4K 随机写能到 3000-5000 IOPS 算正常。如果低于 1000检查rbd_cache是否开启以及 OSD 的osd_op_threads是否够用。把这两组数据写进报告比只写「安装成功」有说服力得多。我习惯在报告里附上测试时间、集群规模、网络配置和关键参数这样别人复现时能直接对照。踩过的坑是rados bench的--no-cleanup会留下测试数据跑完一定要cleanup否则池空间被占满后续创建卷会失败。这个坑我翻过两次希望帮到你。本文还有配套的精品资源点击获取