简介面向云平台运维工程师、架构师及分布式存储选型人员的OpenStack与Ceph集成安装测试报告重点解决OpenStack后端存储选型与实践验证问题。报告从云计算概念和OpenStack基础讲起对比了OpenStack与VMware的适用场景随后深入Ceph架构涵盖OSD、MDS、RGW、MON等关键组件以及CRUSH数据分布、RADOS强一致性、容错与高可用设计并总结Ceph在性能、可靠性、扩展性上的优势。安装测试部分给出测试主机规划、本地YUM源配置等具体步骤便于读者照着搭建环境并验证。资源为1个docx文档压缩包大小876KB按知识模块与章节渐进组织目录清晰。目前已有254人学习无论初次接触还是已有OpenStack基础的读者都能从中获得集成部署参考、架构理解要点与潜在排错思路。1. 为什么 OpenStack 后台直接挂 Ceph值得你照着做一遍搞 OpenStack 到最后十有八九卡在存储上。我用本地磁盘做过 nova 的后端虚拟机一重启实例直接变成“错误”状态连镜像都找不回来。把 Ceph 挂进来之后同样的操作虚拟机在任意计算节点之间漂移都没问题镜像、卷、虚拟机全部落在分布式存储上。这份标题为“OpenStack Ceph分布式存储安装测试报告”的文档本质上就是一次完整的选型和验证过程先解决“能不能用”再回答“怎么配置才可靠”。适合正在搭云平台、被本地盘存储搞怕了、或者想把手动部署升级成 Kolla-Ansible 编排的人。Ceph 和 OpenStack 是生产环境中搭档最多的组合没有之一值得照着复现一遍。2. 部署前的选择题Kolla-Ansible 还是手动组件安装Ceph 版本和网络怎么定2.1 一键编排选 Kolla-Ansible为什么它不是“黑匣子”很多人一听自动化部署就皱眉觉得“出了问题不知道去哪查”。我最早也是手动装 OpenStack装到 neutron 就崩崩完还不知道是数据库问题还是消息队列问题。后来换成 Kolla-Ansible 才明白它不是一个黑匣子而是把容器化的 OpenStack 服务编排起来的工具。每个服务跑在独立的容器里日志就在/var/lib/docker/containers下面排查路径比手动装还要清晰。常见做法是两台物理机起步一台跑 kolla-ansible 控制节点一台跑计算节点。Ceph 集群可以用独立的机器也可以和控制节点共用测试环境共用完全足够。Kolla-Ansible 的核心思路是用 Ansible 的 playbook 把 glance、cinder、nova、neutron 等服务的容器拉起来再通过/etc/kolla/globals.yml统一配置。# 安装 kolla-ansible 依赖Python 3.8 环境 pip install kolla-ansible12.0.0 # 生成配置文件目录 mkdir -p /etc/kolla cp -r /usr/local/share/kolla-ansible/etc_examples/kolla/* /etc/kolla/ # 生成密码文件 kolla-genpwd生成密码文件这一步很关键。kolla-genpwd会随机生成所有服务的数据库密码、keystone 密码、rabbitmq 密码生成之后要妥善保管。后续如果有节点要重新加入密码不一致会直接导致服务认证失败而且报错信息往往看不出来是密码问题。Kolla-Ansible 对新手最友好的地方在于它自带kolla-ansible check命令部署前会检查系统环境是否满足要求。这里提醒一句如果主机名解析出了问题后面所有服务都会互相找不到而报错看起来像网络不通。所以部署 OpenStack 之前先把/etc/hosts写对节点间双向 ping 通。2.2 版本搭配与网络规划踩过最深的坑是二层网络Kolla-Ansible 支持的 OpenStack 版本建议直接选当前主流的稳定版系列避免选太老的版本导致 Ceph 客户端的兼容性出问题。Ceph 这边同理选一个成熟的大版本和 OpenStack 云平台的配套关系查好再动手。网络规划是这份测试报告里最值得花时间的地方。我一般会把网络拆成三层管理网络、存储网络和租户网络。管理网络承载 SSH 和 OpenStack 内部 API 调用存储网络专门跑 Ceph 的副本同步流量租户网络留给虚拟机用。如果只有一张网卡所有流量挤在一起Ceph 同步数据时会把 OpenStack 的 API 请求延迟打高。提示存储网络建议用独立 VLAN 或独立网卡Ceph 的 OSD 之间的数据同步流量非常大和业务流量混在一起会让监控曲线直接起飞。2.3 硬件清单和系统准备把环境预检当成部署的一部分测试环境不需要生产级的盘位规划但有几项不能省所有节点至少 16GB 内存系统盘单独一块 SSDCeph 的 OSD 数据盘至少两块。CPU 虚拟化功能要在 BIOS 里打开否则 nova 计算节点启动虚拟机时会报“KVM is not available”之类的错误。# 检查 CPU 是否支持虚拟化 egrep -c (vmx|svm) /proc/cpuinfo # 检查内核模块 lsmod | grep kvm # 设置主机名和时区所有节点都执行 hostnamectl set-hostname node1 timedatectl set-timezone Asia/Shanghai系统准备阶段还要处理一个容易忽略的点关掉 NetworkManager 或者把它改成不托管要用的网卡。Kolla-Ansible 部署的 OpenStack 网络节点要管理 VLAN 和网桥NetworkManager 可能会自动把网卡状态改掉。常见做法是在/etc/NetworkManager/NetworkManager.conf里加[keyfile]\nunmanaged-devicesinterface-name:eth1;interface-name:eth2然后重启 NetworkManager。3. 用 cephadm 部署 Ceph 集群最小命令集与 OSD 调优参数3.1 cephadm 引导一个单集群三条命令跑起来的逻辑Ceph 的部署方式经历了 ceph-deploy、ceph-ansible 到现在的 cephadm。cephadm 用容器方式管理整个集群配合 bootstrap 命令能在几分钟内拉起一个最小的集群。底层逻辑是先在一个节点上生成集群的 mon 和 mgr再通过ceph orch命令把其他节点加进来。# 安装 cephadm下载官方脚本并安装 curl -s https://raw.githubusercontent.com/ceph/ceph/main/src/cephadm/cephadm /usr/local/bin/cephadm chmod x /usr/local/bin/cephadm cephadm add-repo --release quincy cephadm install # 在第一个节点上引导集群指定管理 IP cephadm bootstrap --mon-ip 192.168.10.10 --cluster-network 192.168.20.0/24 # 把计算节点加入集群 ssh-copy-id -f -i /etc/ceph/ceph.pub root192.168.10.11 ceph orch host add node2 192.168.10.11--cluster-network这个参数值得特别说明。它指定的是 Ceph 内部数据同步的网段和--mon-ip所在的管理网段分离。如果测试环境只有一个网段这个参数可以省略但生产环境建议必须有。ceph orch host add是把新节点纳入集群管理之后可以用ceph orch apply osd或直接在节点上ceph orch device zap来准备 OSD。引导完成后Ceph 会生成一个/etc/ceph/ceph.conf和一个ceph.client.admin.keyring这两个文件是后续 OpenStack 对接的关键。SSH 到其他节点时要确认能以 root 身份免密登录cephadm 会往各节点推送容器镜像和配置。3.2 OSD 创建时的 I/O 调优参数别照抄默认值很多人在创建 OSD 的时候直接让 cephadm 接管所有可用磁盘这个操作在测试环境没问题但到了生产环境会很难做精细调整。我一般会先确认磁盘的状态再指定数据盘加入 OSD。# 查看磁盘状态 ceph orch device ls # 在 node2 上把 /dev/sdb 和 /dev/sdc 加入为 OSD ceph orch daemon add osd node2:/dev/sdb ceph orch daemon add osd node2:/dev/sdc # 查看 OSD 树 ceph osd tree默认的 OSD 创建方式不会自动帮你做 block.db 和 block.wal 的分离。如果是 SSD 做系统盘、机械盘做数据盘的常见配置最好把 OSD 的block.db和block.wal放在 SSD 上。ceph orch apply osd支持--db-devices参数可以指定 SSD 列表。# 指定 SSD 作为 block.db 和 block.wal 的设备数据盘放 HDD ceph orch apply osd -i osd_spec.yaml对应的osd_spec.yaml内容service_type: osd service_id: default_drive_group placement: hosts: - node2 data_devices: paths: - /dev/sdb - /dev/sdc db_devices: paths: - /dev/nvme0n1不分离 WAL 和 DB 的后果在测试里还不明显一旦并发写入上来单块机械盘的 I/O 会成为整个 OpenStack 存储链路的瓶颈。生产环境见过延迟从 10 毫秒飙升到 300 毫秒的案例重启 OSD 之后恢复但过几天又打满根因就是 WAL 和设备同盘竞争。3.3 验证一个“活的”Cephceph -s 和 osdmap 导出检查部署完成后不要急着接 OpenStack。先做一轮 Ceph 自检确认集群是 HEALTH_OK。测试报告里最怕出现集群状态是 HEALTH_WARN 就往下走的情况后面 OpenStack 的报错会很难排查。# 查看集群状态 ceph -s # 查看 OSD 的详细状态 ceph osd status # 导出 osdmap确认 map 版本和 OSD 数量 ceph osd getmap -o /tmp/osdmap.bin ceph osd dumpceph osd getmap导出的 osdmap 是一个二进制文件可以保存下来用于后续的故障分析。比如 OSD 挂了之后通过对比不同时间点的 osdmap 能看到 OSD 的up和in状态变化。还有一句经验ceph -s里如果看到slow requests的数字在涨说明集群有性能问题这时候去查网络丢包比去查磁盘坏道更高效。注意HEALTH_WARN不等于集群不可用但对接 OpenStack 之前至少要确认 PG 状态不是degraded或peering。如果出现PG_AVAILABILITY告警卷创建会非常慢甚至超时。4. OpenStack 对接 Ceph镜像、卷和虚拟机的三条链路4.1 创建 Ceph pools 和 client keyring权限边界想清楚Ceph 对接 OpenStack 需要三个 poolimages镜橡、volumes块存储卷、vmsnova 临时存储。在 Ceph 里创建 pool 之前要先把 osd 的数量确认好。pool 的pg_num不是一个可以随便填的数字它决定了数据分布粒度。# 创建三个 pool ceph osd pool create images 32 ceph osd pool create volumes 32 ceph osd pool create vms 32 # 查看 pool 状态 ceph osd pool ls detailpg_num的建议值是PG 数 (OSD 数 × 100) / 副本数。比如 3 个 OSD、双副本PG 数可以设为 128。测试环境 OSD 少32 够用但要记得 PG 数设置之后虽然可以调整调整期间集群会进行大规模的数据迁移所以一开始就别设得太小。接着创建 OpenStack 专用的 client 用户并赋予三个 pool 的读写权限# 创建 client.openstack 用户权限限定在三个 pool ceph auth get-or-create client.openstack \ mon allow profile osd \ osd allow rwx poolimages, allow rwx poolvolumes, allow rwx poolvms \ -o /etc/ceph/ceph.client.openstack.keyring # 查看 keyring 内容的格式 cat /etc/ceph/ceph.client.openstack.keyring权限边界一定要最小化。如果你后续要接 cinder-backup需要额外给cephfs或rbd的权限但普通 OpenStack 对接不需要给mgr的权限。client.openstack这个 keyring 要复制到所有运行 glance-api、cinder-volume、nova-compute 的节点上放错位置或者权限不对服务起来之后会报PermissionError或No such file or directory而且这个错在服务日志里往往被吞掉。4.2 三种对接配置对比glance/cinder/nova 的配置文件怎么写OpenStack 的镜像、卷、虚拟机和 Ceph 的对接方式不同但都依赖同一个 keyring。配置文件分布在各自服务的容器或系统目录中Kolla-Ansible 部署的场景下集中在/etc/kolla/config/下覆盖。Glance 对接 Ceph 的配置项# /etc/kolla/config/glance/glance-api.conf [DEFAULT] show_multiple_locations True [glance_store] stores rbd default_store rbd rbd_store_pool images rbd_store_user openstack rbd_store_ceph_conf /etc/ceph/ceph.conf rbd_store_chunk_size 8rbd_store_chunk_size 8表示镜像分块大小 8MB这个值在多数场景下是合理的。如果镜像文件特别大可以考虑调大这个值如果小文件特别多调小反而更灵活。但一般不建议动默认 8 够用。Cinder 对接 Ceph 的配置# /etc/kolla/config/cinder/cinder.conf [DEFAULT] enabled_backends ceph [ceph] volume_driver cinder.volume.drivers.rbd.RBDDriver rbd_pool volumes rbd_ceph_conf /etc/ceph/ceph.conf rbd_flatten_volume_from_snapshot False rbd_max_clone_depth 5 rbd_store_chunk_size 8 rados_connect_timeout -1注意rbd_flatten_volume_from_snapshot这个参数。它控制从快照创建卷时是否要把数据铺平。设置为False意味着使用 COW写时复制节省空间但后续对卷的持续写入会造成额外的性能开销。测试阶段可以保持默认生产环境建议根据实际快照使用频率来调。Nova 对接 Ceph 的配置# /etc/kolla/config/nova/nova-compute.conf [libvirt] images_type rbd images_rbd_pool vms images_rbd_ceph_conf /etc/ceph/ceph.conf images_rbd_flatten false images_rbd_admin_keyring /etc/ceph/ceph.client.openstack.keyringimages_type rbd让 nova-compute 直接通过 librbd 和 Ceph 通信虚拟机的临时磁盘落在 Ceph 上。这样虚拟机的磁盘读写绕过 copy-on-write 到本地文件系统的中转而且在计算节点宕机时虚拟机可以直接在另一台节点上启动这才是把 Ceph 接进 OpenStack 的核心价值。4.3 创建测试卷和启动虚拟机怎么判断对接成功还是假成功配置完之后不要急着创建虚拟机。先用命令行把三条链路逐个验证这样可以明确问题出在哪一个环节。# 用 glance 上传测试镜像 source /etc/kolla/admin-openrc.sh glance image-create --name cirros-test \ --disk-format qcow2 \ --container-format bare \ --file /tmp/cirros.img # 查看镜像状态是否 active glance image-list # 用 cinder 创建一块 1GB 的卷 cinder create --name test-vol 1 # 查看卷状态 cinder list镜像上传之后在 Ceph 侧确认imagespool 有数据但要注意镜像是分块上传的如果 glance 的配置里show_multiple_locations没开可能看不到 URL 信息这不算错误。卷创建之后去 Ceph 侧确认# 查看 Ceph 里的卷镜像 rbd ls volumes rbd info volumes/volume-xxxxrbd info会显示卷的大小、格式、对象大小等详细信息。看到 volume 的格式是2就说明 Ceph 侧已经创建成功。接下来启动虚拟机# 从镜像启动虚拟机挂载 test-vol 卷 nova boot --flavor m1.tiny \ --image cirros-test \ --block-device-mapping vdatest-vol::0 \ test-vm启动之后 30 秒左右在 Ceph 侧看vmspool会出现新的 rbd 镜像这就是虚拟机的系统盘。如果vmspool 里没有新镜像出现检查 nova-compute 日志里有没有rbd create相关的报错最常见的坑是/etc/ceph/ceph.client.openstack.keyring的属主或权限不对容器里的 nova-compute 用户读不了这个文件。5. 测试报告核心结论与故障排查那些看起来像“灵异事件”的问题5.1 功能测试与重启测试测试矩阵怎么设计才有说服力一份合格的安装测试报告不能只写“部署成功”四个字。要把测试分成功能测试和可靠性测试两个维度。功能测试包含镜像上传与下载、卷创建与删除、虚拟机冷迁移、快照创建与回滚、从快照创建新卷。可靠性测试包含Ceph OSD 宕机恢复测试、计算节点重启验证虚拟机自动恢复、控制节点网络闪断测试。# 可靠性测试示例手动停止一个 OSD观察集群状态变化 systemctl stop ceph-osd0 ceph -s sleep 60 ceph -s systemctl start ceph-osd0测试过程中记录ceph -s的输出变化能从degraded到activeclean的状态迁移时间判断集群的健康程度。另外做虚拟机冷迁移测试时要注意nova 的冷迁移操作会把虚拟机磁盘在计算节点间复制如果 Ceph 配置的是 RBD 后端冷迁移不会走本地磁盘复制而是直接修改虚拟机的调度位置这是验证 Ceph 后端是否接对的一个隐藏指标。5.2 /etc/hosts 不一致导致 mon 节点反复 flapping现象ceph -s显示 mon map 状态正常但集群间歇性报mon is down或clock skew。原因集群所有节点的/etc/hosts不一致有的节点配了短主机名映射有的没配。Ceph 的 mon 之间需要通过主机名互相通信解析失败时 mon 进程以为自己失联了反复选举。解决统一所有节点的/etc/hosts把每个节点的 IP、短主机名、完整主机名一行写全。改完重启 ceph-mon 容器或进程。这个坑在容器化部署里更隐蔽因为容器内有自己的/etc/hosts需要检查镜像的 hostname 是否匹配宿主机名。5.3 OSD 的 block.db 和 block.wal 没分离延迟直接翻倍现象ceph -s显示OSD_SLOW_PING告警ceph osd perf查看 OSD 提交延迟达到几百毫秒。原因所有 OSD 的 WAL 和 DB 都放在同一块机械盘上写入时 WAL 和数据盘竞争 I/O。解决OSD 创建时通过db_devices指定 SSD。如果已经建好的 OSD 没分离需要把数据迁出再重建 OSD。过程比较麻烦所以建议在安装阶段就把 SSD 规划好。5.4 cephx keyring 放错位置cinder-volume 起不来现象cinder-volume 容器不断重启日志里出现rados_connect_timeout超时或者PermissionError。原因cinder-volume 容器内部Ceph 客户端需要读取 keyring 文件来获取client.openstack的密钥。Kolla-Ansible 的 cinder 容器默认把 keyring 放在/etc/ceph下宿主机如果只把 keyring 复制到了/etc/kolla/config/cinder而没同步到/etc/ceph容器起来后找不到文件。解决把 keyring 同时放到/etc/kolla/config/cinder/和/etc/ceph/下并且在ceph.conf里显式指定keyring /etc/ceph/ceph.client.openstack.keyring。修改后逐个重启 glance-api、cinder-volume、cinder-scheduler 容器。5.5 系统时间和 NTP 没对齐ceph -s 显示 HEALTH_WARN 但无从下手现象ceph -s出现CLOCK_SKEW告警mon 之间延迟波动。原因Ceph 的 mon 和 OSD 对时间同步要求很高默认阈值是 50 毫秒左右。节点之间没有配 NTP或者 NTP 服务器地址不通。解决用 chrony 做时间同步服务端选控制节点其他节点指向它。排错思路是先看timedatectl确认时钟源再chronyc sources -v看同步状态。测试时可以把mon clock drift allowed和mon clock drift warn backoff调大临时掩盖问题但长期必须解决时间同步。6. 性能摸底与后续优化基准测试怎么做才不会自欺欺人性能测试是安装测试报告里最容易“翻车”的部分。很多人拿 Ceph 自带的rados bench测完就写结论但实际上rados bench测的是底层 RADOS 的带宽不是 OpenStack 虚拟机里实际的存储性能。我建议做两层测试第一层用rados bench摸 Ceph 集群底第二层在 OpenStack 虚拟机上用fio测真实 I/O。# 在 Ceph 侧做 60 秒 4MB 顺序写测试 rados bench -p volumes 60 write --max-objects 1000 --no-cleanup # 在虚拟机上安装 fio 后测 4K 随机写 fio --filename/dev/vdb --direct1 --rwrandwrite \ --bs4k --size1G --numjobs4 --runtime60 --group_reporting # 用 dd 做一次最简单的读写摸底 dd if/dev/zero of/tmp/testfile bs1M count1024 oflagdirect测试时先把vmspool 清干净避免其他 I/O 干扰结果。另外虚拟机里的fio数据要记录iops和latency两个指标仅看吞吐量会掩盖随机读写的短板。Ceph 的 RBD 默认块大小是 4MB虚拟机的块 I/O 会经过 librbd 的缓存和 PG 分布4K 随机写的性能通常比顺序写低一个数量级这个结果不用慌重点是看延迟分布。性能优化方向可以从 Ceph 侧参数入手调整rbd cache大小、打开rbd cache writethrough until flush、调大bluestore block size。OpenStack 侧可以对cinder.conf的rbd_max_clone_depth做调整减少快照链深度导致的读放放大。我自己的习惯是在测试报告最后附一张性能数据表记录 Ceph 侧顺序读、顺序写、随机读、随机写四组数据再在虚拟机里测同样四组。对比两组数据能判断出损耗主要发生在网络传输还是 OpenStack 存储驱动。如果虚拟机的随机写性能低于 Ceph 侧 30% 以上优先检查计算节点的网络配置和nova-compute的libvirt缓存设置。最终的经验是Ceph 和 OpenStack 的对接部署脚本跑通只是开始真正花时间的是把存储链路调顺。每一层都有可以优化的空间但从底层往上层逐层排查是最高效的顺序。希望这份安装测试报告里的踩坑记录能帮你把 Ceph 这个“分布式存储黑匣子”彻底打开少走点弯路——希望帮到你。本文还有配套的精品资源点击获取