★ FEATURED ARTICLE 简介这份《OpenStack Ceph分布式存储安装测试报告》面向云计算运维工程师、存储架构学习者及OpenStack平台部署人员聚焦开源云平台与分布式存储的集成实践。报告从云计算基础概念切入系统梳理OpenStack组件构成及其与VMware的差异并深入讲解Ceph的架构原理涵盖OSD、MDS、RGW、MON等核心组件、CRUSH数据映射算法、RADOS强一致性与容错机制以及高性能、高可靠、高扩展等优势同时说明在OpenStack中选择Ceph作为后端存储的考量与测试主机规划。资源包内含1个docx文档约876KB结构完整、目录清晰便于按章节查阅。目前已有254人学习适合希望理解OpenStack与Ceph集成方案、掌握分布式存储选型与部署思路的读者参考。1. OpenStack 接 Ceph 做后端存储一份安装测试报告该验什么很多团队搭完 OpenStack 云平台虚拟机根盘还跑在本地 LVM 上一台计算节点挂了上面几十台虚机跟着陪葬。这时候就会想到 Ceph——把分布式存储接进 OpenStack让卷、镜像、快照都落在多副本池里。但真正动手时问题往往不在“装不装得上”而在“装完怎么证明它真的能用、扛得住、掉盘不炸”。这份安装测试报告要回答的就是 OpenStack 与 Ceph 对接后从集群健康、池策略、Cinder/Glance/Nova 三条链路到故障注入验证的完整闭环。适合正在做私有云存储选型、准备把 Ceph 接进现有 OpenStack 环境的一线运维和存储工程师也适合需要交付一份可复现测试记录的团队。2. 装之前先把 Ceph 集群的底子验清楚2.1 为什么先验 Ceph 再碰 OpenStack顺序搞反是血泪经验里最常见的一种。有人 OpenStack 环境已经跑着业务直接往上面叠 Ceph结果 MON 选举抖动、OSD 频繁 down最后分不清是网络问题还是 OpenStack 侧配置问题。正确做法是Ceph 集群独立验收通过后再让 OpenStack 接入。验收 Ceph 集群核心看三件事MON 仲裁是否稳定、OSD 是否全部 up/in、PG 是否 activeclean。这三项不达标后面所有对接都是空中楼阁。常见做法是用ceph -s和ceph osd tree做第一轮体检再用ceph health detail看有没有隐藏告警。# 查看集群整体状态重点看 health、mon 数量、osd up/in、pg 状态 ceph -s # 查看 OSD 分布确认每个 host 上的 OSD 都在 up 状态 ceph osd tree # 有告警时看明细定位到具体 pool 或 osd ceph health detailceph -s输出里health: HEALTH_OK是底线HEALTH_WARN要逐条消掉再往下走。mon: 3 daemons, quorum a,b,c说明仲裁正常少于 3 个 MON 在生产环境属于高风险。osd: 12 up, 12 in表示所有 OSD 在线且被集群接纳。PG 状态必须是activeclean出现undersized、degraded、peering都说明数据分布还没稳定。2.2 建池时把 pg_num 和副本数一次定对Ceph 池的pg_num和size是后面最难改的两个参数。pg_num改起来会触发数据重平衡生产环境动它等于做一次大规模迁移。所以安装阶段就要按预期容量算好。常见估算方式目标 PG 总数控制在每 OSD 100 到 200 个之间。假设 12 个 OSD目标每 OSD 128 个 PG总 PG 数约 1536三副本池的pg_num取接近 2 的幂次比如 512 或 1024。副本数size生产环境至少 3测试环境可以 2但绝不能 1。# 创建给 OpenStack 用的三副本池 ceph osd pool create volumes 512 512 ceph osd pool create images 128 128 ceph osd pool create vms 256 256 # 设置副本数为 3 ceph osd pool set volumes size 3 ceph osd pool set images size 3 ceph osd pool set vms size 3 # 开启应用模式Cinder/Glance 需要 ceph osd pool application enable volumes rbd ceph osd pool application enable images rbd ceph osd pool application enable vms rbdceph osd pool create的两个数字分别是pg_num和pgp_num新集群里通常设成一样。application enable这步容易被漏掉漏了之后ceph -s会报application not enabled告警虽然不影响基本读写但属于必须消掉的配置债。副本数用ceph osd pool get volumes size复查一遍确认生效。2.3 用 rbd 命令做一轮裸存储读写验证在接 OpenStack 之前先用rbd命令直接对池做读写排除 Ceph 自身问题。这一步能提前暴露网络延迟、OSD 性能瓶颈、认证配置错误。# 创建一块 1G 的测试卷 rbd create testpool/testvol --size 1024 # 映射到本地 rbd map testpool/testvol # 写入测试数据 dd if/dev/zero of/dev/rbd0 bs1M count512 oflagdirect # 查看卷信息 rbd info testpool/testvol # 清理 rbd unmap /dev/rbd0 rbd rm testpool/testvoloflagdirect绕过页缓存测的是真实落盘性能。如果这一步dd速度只有几 MB/s说明 OSD 所在磁盘或网络有问题先别急着接 OpenStack。rbd info里重点看size、features、orderfeatures里如果有layering说明支持克隆Cinder 的快照克隆功能依赖它。3. 把 Ceph 接进 OpenStack 的三条链路3.1 Glance 后端切到 Ceph镜像不再占本地盘Glance 默认用本地文件存镜像镜像一多控制节点磁盘就爆。切到 Ceph 后镜像直接存进images池多副本保护还能被 Cinder 克隆加速创建卷。配置在/etc/glance/glance-api.conf[DEFAULT] show_image_direct_url True [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 8show_image_direct_url True是给 Cinder 用的开启后 Cinder 能直接从镜像的 RBD 位置克隆卷省掉一次全量下载。rbd_store_chunk_size 8表示镜像按 8MB 分块大镜像并发上传时这个值影响吞吐常见范围 4 到 8。改完重启glance-api然后传一个镜像验证openstack image create --disk-format qcow2 --container-format bare \ --file cirros.qcow2 --public cirros-ceph # 确认镜像落在 rbd 池里 rbd ls imagesrbd ls images能看到以镜像 UUID 命名的块设备说明 Glance 已经写进 Ceph。如果openstack image list有记录但rbd ls为空多半是stores没配对或者 glance 用户没有池权限。3.2 Cinder 卷后端多后端配置与卷类型绑定Cinder 接 Ceph 是重头戏。生产环境通常配多个后端比如 SSD 池和 HDD 池分开通过卷类型让用户选择。/etc/cinder/cinder.conf关键配置[DEFAULT] enabled_backends ceph-ssd,ceph-hdd [ceph-ssd] volume_driver cinder.volume.drivers.rbd.RBDDriver rbd_pool volumes_ssd rbd_ceph_conf /etc/ceph/ceph.conf rbd_user cinder rbd_secret_uuid libvirt secret uuid rbd_flatten_volume_from_snapshot False volume_backend_name ceph-ssd [ceph-hdd] volume_driver cinder.volume.drivers.rbd.RBDDriver rbd_pool volumes_hdd rbd_ceph_conf /etc/ceph/ceph.conf rbd_user cinder rbd_secret_uuid libvirt secret uuid rbd_flatten_volume_from_snapshot False volume_backend_name ceph-hddrbd_secret_uuid必须和计算节点 libvirt 里配置的 secret 一致否则虚机挂载卷时会失败。rbd_flatten_volume_from_snapshot False保留克隆链创建快照卷更快但要注意克隆链过长会影响性能定期做 flatten 是常见运维动作。配完重启cinder-volume然后建卷类型并绑定后端openstack volume type create ceph-ssd openstack volume type set --property volume_backend_nameceph-ssd ceph-ssd openstack volume type create ceph-hdd openstack volume type set --property volume_backend_nameceph-hdd ceph-hdd建卷时指定类型验证落在对应池openstack volume create --size 10 --type ceph-ssd test-ssd-vol rbd ls volumes_ssd3.3 Nova 临时盘与虚机磁盘libvirt secret 不能漏Nova 本身不直接管 Ceph但虚机挂载 Cinder 卷时libvirt 需要通过 secret 访问 Ceph。每个计算节点都要配。# 生成 secret在控制节点执行一次记录 uuid ceph auth get-key client.cinder /tmp/cinder.key cat /tmp/secret.xml EOF secret ephemeralno privateno uuidxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/uuid usage typeceph nameclient.cinder secret/name /usage /secret EOF virsh secret-define --file /tmp/secret.xml virsh secret-set-value --secret xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx \ --base64 $(cat /tmp/cinder.key)这个 UUID 就是cinder.conf里的rbd_secret_uuid。两边必须完全一致差一个字符虚机就起不来报Unable to access volume。配完在计算节点重启nova-compute然后从卷启动一台虚机验证。4. 安装测试报告里必须覆盖的验证项4.1 功能验证卷、快照、克隆、迁移一份能交付的测试报告功能验证至少覆盖这几项每项记录操作命令和结果验证项操作预期结果卷创建从镜像创建 10G 卷卷状态 availablerbd 池可见卷挂载挂到虚机并格式化虚机内可读写快照对卷打快照快照状态 available克隆从快照创建新卷新卷可独立挂载卷迁移同后端不同主机迁移迁移后数据完整镜像启动从 Ceph 镜像启动虚机虚机正常进入系统每项都要记录耗时。卷创建耗时能反映 Ceph 集群写入延迟克隆耗时能反映是否走了 COW 快速路径。如果克隆一个 10G 卷花了几分钟说明rbd_flatten_volume_from_snapshot配置或克隆链有问题。4.2 性能验证fio 测三副本真实 IOPS功能通了不代表性能能用。用 fio 在虚机内对 Ceph 卷做压测记录 4K 随机写、4K 随机读、1M 顺序写的 IOPS 和延迟。# 4K 随机写 fio --namerandwrite --ioenginelibaio --iodepth32 \ --rwrandwrite --bs4k --direct1 --size2G \ --numjobs4 --runtime60 --group_reporting # 4K 随机读 fio --namerandread --ioenginelibaio --iodepth32 \ --rwrandread --bs4k --direct1 --size2G \ --numjobs4 --runtime60 --group_reportingiodepth32模拟较高并发numjobs4模拟多线程。三副本池的 4K 随机写 IOPS 受网络往返和副本同步影响万兆网下单卷通常能到几千具体看 OSD 介质。如果 IOPS 低得离谱先查ceph osd perf看哪个 OSD 延迟高再查网络是否有丢包。4.3 故障注入拔盘、停 MON、断网这是测试报告里最有价值的部分也是最多人跳过的地方。至少做三项停掉一个 OSD 所在磁盘或systemctl stop ceph-osdN观察ceph -s是否变degraded虚机 IO 是否中断。预期是 IO 短暂抖动后恢复PG 变为activedegraded数据仍在。停掉一个 MON观察集群是否仍能读写。三 MON 集群停一个仲裁仍在业务无感。停两个集群只读或阻塞这是预期行为。断开一个计算节点网络观察该节点上的虚机卷是否可访问。这验证的是客户端侧多路径和重试机制。每项故障注入后记录恢复时间和数据一致性检查结果。恢复后ceph -s必须回到HEALTH_OKPG 回到activeclean。5. 避坑与排查那些让测试报告返工的问题5.1 虚机起不来报 Unable to access volume现象从 Ceph 卷启动虚机虚机卡在启动阶段nova-compute日志报Unable to access volume。原因计算节点 libvirt 的 secret UUID 与cinder.conf里rbd_secret_uuid不一致或者 secret 没设置值。解决在计算节点执行virsh secret-list确认 secret 存在virsh secret-get-value uuid确认有值。对比cinder.conf里的 UUID不一致就重新 define 并 set-value然后重启nova-compute和libvirtd。5.2 卷创建成功但虚机内看不到盘现象openstack volume create成功挂载命令也返回成功但虚机内lsblk看不到新盘。原因虚机需要重启或重新识别 SCSI 总线或者卷挂载到了错误的虚机。解决先openstack server volume list server确认卷挂到了目标虚机。然后在虚机内执行echo - - - /sys/class/scsi_host/host0/scan触发重新扫描。如果还不行检查虚机是否用了 virtio 驱动老内核可能需要重启。5.3 PG 长期 undersized副本数上不去现象ceph -s显示 PGactiveundersized明明设了 size3但实际只有 2 个副本。原因OSD 数量不足或 CRUSH 规则限制了副本分布。比如 3 个 host 各 1 个 OSDsize3 时 CRUSH 可能无法在 3 个 host 上各放一个副本。解决ceph osd tree确认 host 和 OSD 数量。如果 host 数少于副本数要么加 host要么调整 CRUSH 规则允许同 host 多 OSD。生产环境建议 host 数大于等于副本数。5.4 Glance 上传大镜像超时现象上传超过 10G 的镜像时openstack image create卡住或超时。原因glance-api的rbd_store_chunk_size太大或太小或者 Ceph 池 PG 数不足导致写入慢。解决把rbd_store_chunk_size调到 8 或 16重启glance-api。同时检查images池的 PG 数128 个 PG 对大量镜像偏少可以适当增加。上传时用--progress观察进度确认是卡住还是慢。5.5 删除卷后空间不释放现象openstack volume delete成功但ceph df显示池用量没降。原因卷有快照或克隆链RBD 镜像还有子节点引用不能直接删。解决rbd children pool/image查看是否有子镜像。先删子镜像或做 flatten再删父卷。Cinder 侧可以用openstack volume snapshot list确认没有残留快照。6. 让测试报告可复现脚本化验证与基线记录一份测试报告如果只有结论没有过程别人没法复现价值就折半。我一般会把验证步骤脚本化每次环境变更后重跑一遍把结果存档做基线对比。#!/bin/bash # ceph-openstack-check.sh # 用途一键采集 Ceph 与 OpenStack 对接后的关键状态 REPORT/var/log/ceph-openstack-$(date %Y%m%d-%H%M).log { echo Ceph 集群状态 ceph -s ceph health detail ceph osd tree ceph df detail echo 池状态 for pool in volumes images vms; do echo --- $pool --- ceph osd pool get $pool size ceph osd pool get $pool pg_num done echo OpenStack 服务状态 openstack volume service list openstack image list --long | head -20 openstack volume list --all-projects | head -20 echo RBD 卷列表 rbd ls volumes | head -20 rbd ls images | head -20 } $REPORT 21 echo 报告已生成$REPORT这个脚本的价值在于每次变更后跑一次把日志按时间戳存档。出问题时对比变更前后的差异能快速定位是哪一步引入的。比如某次扩容 OSD 后 PG 开始degraded对比前后ceph osd tree就能看出新 OSD 的 CRUSH 位置是否合理。基线记录要包含几个关键数字集群总容量、已用容量、平均 IOPS、平均延迟、PG 总数、每 OSD 的 PG 数。这些数字在后续扩容或调优时是参照系。没有基线调优就是盲调。最后说个习惯我做完任何存储对接都会在测试环境先跑一遍完整的故障注入把恢复时间记下来。生产环境真出故障时心里有底知道大概多久能恢复要不要切流量。这个习惯帮我避免过好几次手忙脚乱。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
