1. 为什么把 OpenStack 和 Ceph 放在一起谈如果你正在搭建一套私有云环境大概率绕不开两个名字OpenStack 和 Ceph。前者负责计算、网络、身份认证这些云的操作系统层面的事后者负责把一堆普通服务器的本地硬盘聚合成一个统一的分布式存储池。单独部署其中任何一个都不算太难但把两者对接起来让虚拟机的镜像、云盘、快照都落在 Ceph 上这一步才是真正考验功力的地方。我前后搭过几套不同规模的环境从三节点的小集群到十几节点的准生产环境都折腾过。踩过的坑包括但不限于Ceph 集群健康状态反复横跳、Glance 上传镜像卡死、虚拟机挂载云盘后 IO 性能惨不忍睹、重启后服务起不来等等。这些问题单独看都不复杂但叠在一起排查起来非常折磨人。这篇内容适合两类人一类是刚接触私有云、想动手搭一套能跑起来的环境的运维新手另一类是用过 OpenStack 或 Ceph 其中之一、但没做过两者对接的工程师。我会从整体设计思路讲起把核心组件的对接原理、关键配置、参数计算、实操步骤和排查经验都摊开说清楚。你照着做至少能少走我当年走过的一半弯路。需要提前说明的是下面涉及的所有主机名、IP、密码都是示例实际部署时你要替换成自己的规划。另外这套方案基于常见的三节点超融合思路计算和存储复用同一批物理机如果你有独立的存储节点思路一致只是角色分配不同。2. 整体架构设计与方案选型思路2.1 为什么选择超融合三节点起步很多人一上来就想搞分离部署三台做计算、三台做存储。想法没错但对实验环境或者中小规模场景来说六台机器的成本和管理复杂度都偏高。超融合的思路是把计算角色和存储角色压在同一批物理机上三台机器既跑 Nova、Neutron又跑 Ceph 的 OSD 和 MON。这么做的核心考量是成本和控制面简化。三节点是 Ceph 能保证数据可靠性的一个心理底线——副本数设为 3 时任意一台挂了数据依然完整可读。如果只有两台副本数只能设 2一旦一台故障剩下的数据就处于无冗余的危险状态重建过程中再挂一台就全没了。所以三节点是能玩和敢用之间的分水岭。当然超融合也有代价。计算和存储抢同一份 CPU、内存、磁盘 IO高峰期会互相影响。我的经验是如果只是做实验、跑测试三节点超融合完全够用如果要上生产建议至少把存储节点独立出来或者把 OSD 所在的磁盘和系统盘、计算用的本地盘彻底分开。2.2 网络平面划分是成败关键这一块我要重点讲因为太多人栽在网络规划上。OpenStack 和 Ceph 对网络的需求完全不同混在一起会出大问题。我的建议是至少划分三个网络平面网络平面用途典型网段带宽要求管理网API 通信、SSH、MON 心跳192.168.10.0/24千兆即可存储网后端OSD 数据复制、恢复192.168.20.0/24万兆强烈推荐业务网前端虚拟机流量、外部访问192.168.30.0/24千兆起步为什么存储网要单独拉因为 Ceph 的副本复制、数据恢复会产生巨大的东西向流量。如果和业务网混在一起一台 OSD 故障触发全量恢复时业务网的虚拟机网络会被直接打满用户感知就是云平台卡死了。我见过一个案例就是因为没做网络隔离一次磁盘故障导致整个集群业务中断了半小时。存储网用万兆不是奢侈是刚需。千兆网络下Ceph 的写入延迟会高到让你怀疑人生尤其是三副本同步写的时候网络成了绝对瓶颈。如果预算实在有限至少保证存储网是独立物理网卡别和管理网共用。2.3 存储后端选型为什么是 Ceph 而不是 LVM 或 NFSOpenStack 支持多种存储后端简单点的有 LVM、NFS复杂点的有 Ceph、GlusterFS。为什么大家最终都往 Ceph 上靠LVM 的问题是不支持多节点共享虚拟机一迁移本地盘的数据就带不走云平台最核心的动态迁移能力直接废掉。NFS 倒是共享了但单点性能瓶颈明显而且没有真正的分布式冗余存储服务器一挂全完。Ceph 的优势在于一套集群同时提供块存储RBD、对象存储RADOS Gateway、文件存储CephFS三种接口OpenStack 的 Cinder云盘、Glance镜像、Nova临时盘都能对接同一套后端。数据自动分片、自动复制、自动恢复节点故障对上层几乎透明。虽然运维复杂度高一些但换来的是真正的弹性。提示如果你的环境只有一两台机器别硬上 Ceph用 LVM 或本地盘先跑起来等规模上来了再迁移。Ceph 的最小可用规模就是三节点低于这个数没有意义。3. 部署前的准备工作与核心参数计算3.1 硬件与系统基线要求在动手之前先把硬件和系统基线确认清楚不然后面全是坑。CPU 方面每个节点至少 8 核推荐 16 核以上。Ceph 的 OSD 进程、OpenStack 的各种服务都是吃 CPU 的大户核数不够会明显卡顿。内存方面每个节点 64GB 是起步128GB 更舒服。这里有个经验公式每 1TB 的 OSD 裸容量大约需要 1GB 内存给 Ceph 做缓存和元数据管理。如果你单节点挂了 4 块 4TB 盘那就是 16TB光 Ceph 就要吃掉 16GB 内存再加上 OpenStack 服务64GB 其实挺紧张的。磁盘布局是重点。我的建议是系统盘2 块 SSD 做 RAID1装操作系统数据盘至少 4 块大容量盘HDD 或 SSD每块盘单独做 OSD不做 RAID日志盘可选但强烈推荐1-2 块 SSD 专门放 OSD 的 journal/WAL能极大提升写入性能为什么数据盘不做 RAID因为 Ceph 自己就是靠副本机制保证冗余的你再做 RAID 就是冗余套冗余浪费空间还增加复杂度。Ceph 要的是能直接看到每一块裸盘。操作系统我一般用较新的稳定版 Linux 发行版内核版本要足够新对 Ceph 的支持才好。时间同步必须配好所有节点时间偏差不能超过 0.05 秒否则 MON 之间会各种报错。用 chrony 或 systemd-timesyncd 都行关键是确保chronyc sources显示同步正常。3.2 关键参数计算PG 数量到底怎么定PGPlacement Group数量是 Ceph 里最容易被搞错、又最影响性能的参数。PG 是数据分布的逻辑单元太多会导致 MON 负担过重太少会导致数据分布不均。业界有个经典公式PG总数 (OSD总数 × 100) / 副本数然后向上取到最接近的 2 的幂次。举个例子假设你有 3 个节点每个节点 4 块 OSD总共 12 个 OSD副本数设为 3PG总数 (12 × 100) / 3 400向上取到 2 的幂次就是 512。这个 512 是整个集群的 PG 总数具体到每个存储池pool还要再分配。对于 OpenStack 场景通常有这么几个池imagesGlance 镜像、volumesCinder 云盘、vmsNova 临时盘、backups备份。假设你规划 4 个池那每个池大约分 512/4 128 个 PG取 2 的幂次就是 128。实际操作中我一般用ceph osd pool autoscale-status来看自动调节的建议新版本 Ceph 的 pg_autoscaler 模块能帮你自动算比手算靠谱。但你要理解背后的逻辑不然自动调节出问题时你都不知道从哪查。注意PG 数量一旦设定后期调整需要做 PG 分裂或合并虽然 Ceph 支持在线操作但会触发大量数据迁移生产环境尽量一次算准。3.3 主机名与 hosts 解析规划这一步看似简单但主机名解析不通是新手最常见的翻车点。Ceph 和 OpenStack 都极度依赖主机名能正确解析到 IP。我的规划示例主机名管理网 IP存储网 IP角色node1192.168.10.11192.168.20.11控制计算存储node2192.168.10.12192.168.20.12控制计算存储node3192.168.10.13192.168.20.13控制计算存储每台机器的/etc/hosts都要写全这三行并且hostnamectl set-hostname设置的主机名要和这里一致。我踩过的坑是某台机器主机名带了大写或者下划线导致 Ceph 认证失败排查了半天才发现是命名不规范。主机名只用小写字母、数字和连字符别用下划线。4. Ceph 集群部署实操全流程4.1 部署工具选择cephadm 还是传统方式早期大家用 ceph-deploy后来官方主推 cephadm基于容器。我的建议是新环境直接用 cephadm它是官方长期维护的方向把 MON、MGR、OSD 都跑在容器里升级和扩缩容都更干净。cephadm 的前提是每台机器要有容器运行时podman 或 docker。我一般用 podman和系统集成更好。安装步骤大致是# 在每个节点上安装 podman 和 cephadm sudo apt update sudo apt install -y podman cephadm # 在第一个节点上引导集群 sudo cephadm bootstrap --mon-ip 192.168.10.11bootstrap 完成后它会生成一个ceph.conf和一个ceph.client.admin.keyring还会告诉你如何把其他节点加进来。默认会启动一个 MON 和一个 MGRDashboard 也会起来。这里有个细节bootstrap 默认用的是管理网 IP但存储网才是数据复制的主力。所以引导完成后要手动把存储网配置进去让 OSD 之间的复制走存储网。4.2 把其他节点加入集群在第一个节点上执行# 获取加入集群需要的公钥和命令 ceph orch host add node2 192.168.10.12 ceph orch host add node3 192.168.10.13如果节点之间还没配 SSH 互信cephadm 会提示你先拷贝公钥。我一般提前在所有节点之间做好 root 的 SSH 免密省得中途卡住。加入后用ceph orch host ls确认三个节点都在列表里状态正常。这时候 MON 还只有一个为了高可用要再补两个 MONceph orch apply mon --placementnode1,node2,node3MON 数量保持奇数1、3、5这是 Paxos 算法的要求偶数会导致选举僵持。三节点环境就配三个 MON正好。4.3 添加 OSD 并规划 journal 布局OSD 是真正存数据的地方。添加 OSD 前先用lsblk确认每块数据盘的设备名比如/dev/sdb、/dev/sdc等。# 查看可用设备 ceph orch device ls # 批量添加 OSD ceph orch apply osd --all-available-devices--all-available-devices会自动把所有可用的裸盘做成 OSD。但生产环境我更推荐手动指定因为要控制 journal 的位置ceph orch daemon add osd node1:/dev/sdb关于 journal新版本叫 DB/WAL如果你有独立 SSD强烈建议把 DB 和 WAL 放在 SSD 上数据盘用 HDD。这样写入时元数据和日志先落 SSD性能提升非常明显。配置方式是在添加 OSD 时用--data-devices和--db-devices分别指定。我实测过同样 4 块 HDDjournal 放 HDD 上时随机写 IOPS 大概几百放 SSD 上能到几千差距是数量级的。对于跑虚拟机的场景这个提升直接决定了云盘好不好用。4.4 创建 OpenStack 需要的存储池Ceph 集群起来后要为 OpenStack 创建专用的池。我一般建这几个# 镜像池 ceph osd pool create images 128 128 # 云盘池 ceph osd pool create volumes 128 128 # 虚拟机临时盘池 ceph osd pool create vms 128 128 # 备份池 ceph osd pool create backups 64 64 # 启用 RBD 应用 ceph osd pool application enable images rbd ceph osd pool application enable volumes rbd ceph osd pool application enable vms rbd ceph osd pool application enable backups rbd创建完记得设置副本数ceph osd pool set volumes size 3 ceph osd pool set volumes min_size 2size 3是三副本min_size 2表示至少要有 2 个副本可用才允许写入。这个 min_size 很关键设成 1 的话只剩一个副本时还能写但数据就危险了设成 2 是安全和可用的平衡点。5. OpenStack 与 Ceph 对接的核心配置5.1 创建对接用的认证用户OpenStack 各组件访问 Ceph 需要认证。我一般给每个组件建独立用户方便权限隔离和问题定位# 为 Glance 创建用户 ceph auth get-or-create client.glance mon allow r osd allow class-read object_prefix rbd_children, allow rwx poolimages # 为 Cinder 创建用户 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 # 为 Nova 创建用户 ceph auth get-or-create client.nova mon allow r osd allow class-read object_prefix rbd_children, allow rwx poolvms, allow rx poolimages注意权限的粒度。Glance 只需要 images 池的读写Cinder 需要 volumes 和 vms 池还要能读 images克隆镜像用Nova 主要用 vms 池。权限给多了是安全隐患给少了功能会报错这个平衡要把握好。创建完把 keyring 导出到各节点的/etc/ceph/目录下文件名要和用户对应比如ceph.client.glance.keyring。5.2 Glance 对接 Ceph 后端Glance 是镜像服务把镜像存到 Ceph 能实现多节点共享虚拟机在任何节点都能快速启动。编辑/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。这个值影响镜像上传和读取的效率8MB 是个比较通用的选择太小会增加元数据开销太大对小镜像浪费。配置完重启 glance-api 服务。验证方法是上传一个镜像然后到 Ceph 里看rbd -p images ls能看到镜像对应的 RBD 卷就说明对接成功了。5.3 Cinder 对接 Ceph 后端Cinder 是云盘服务对接 Ceph 后云盘就变成了分布式的 RBD 卷支持在线迁移和快照。编辑/etc/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 4 rados_connect_timeout -1 rbd_user cinder rbd_secret_uuid 你的secret_uuid这里有几个参数值得说。rbd_max_clone_depth 5控制克隆链的最大深度从快照创建云盘时会形成克隆链太深会影响性能5 层是个经验值。rbd_flatten_volume_from_snapshot false表示不自动扁平化保留克隆关系节省空间但如果克隆链太长可以改成 true 来扁平化。rbd_secret_uuid是给 libvirt 用的让计算节点能通过这个 UUID 拿到访问 Ceph 的密钥。这个 UUID 要和各计算节点上 libvirt 的 secret 配置一致。5.4 Nova 对接 Ceph 临时盘Nova 的临时盘ephemeral默认存在计算节点的本地盘虚拟机一迁移数据就丢了。对接 Ceph 后临时盘也变成 RBD 卷迁移就无损了。编辑/etc/nova/nova.conf[libvirt] images_type rbd images_rbd_pool vms images_rbd_ceph_conf /etc/ceph/ceph.conf rbd_user nova rbd_secret_uuid 你的secret_uuid配置完重启 nova-compute。注意这个改动只影响新建的虚拟机已有的虚拟机临时盘还在本地。5.5 libvirt secret 配置上面提到的rbd_secret_uuid需要在每个计算节点上配置 libvirt secret否则虚拟机启动时会因为拿不到 Ceph 密钥而失败。先生成一个 UUIDuuidgen然后在每个计算节点上创建 secret 文件内容包含这个 UUID 和 base64 编码的 Ceph 密钥# 获取 cinder 用户的密钥 ceph auth get-key client.cinder # 创建 secret xml cat secret.xml EOF secret ephemeralno privateno uuid你的UUID/uuid usage typeceph nameclient.cinder secret/name /usage /secret EOF virsh secret-define secret.xml virsh secret-set-value --secret 你的UUID --base64 $(ceph auth get-key client.cinder)这一步是新手最容易漏的漏了之后虚拟机就是起不来报错信息还特别隐晦往往只提示无法访问存储。6. 常见问题排查与避坑经验实录6.1 Ceph 健康状态异常速查Ceph 的ceph -s输出是排查的第一入口。下面这张表是我整理的常见状态和对应处理健康状态常见原因排查方向HEALTH_WARN: clock skew节点时间不同步检查 chrony/ntp 同步状态HEALTH_WARN: near full osdOSD 使用率超 85%扩容或清理数据HEALTH_ERR: pg degraded有 OSD 掉线检查 OSD 进程和磁盘HEALTH_WARN: slow ops磁盘或网络瓶颈查 iostat 和网络流量HEALTH_ERR: mon downMON 节点故障检查 MON 服务和网络我遇到最多的是 clock skew尤其是虚拟机里跑 Ceph 的时候宿主机时间一漂移Ceph 就报警。解决办法是确保所有节点都指向同一个时间源并且定期检查。6.2 镜像上传卡死或超时Glance 上传镜像到 Ceph 时卡住通常有几个原因。一是rbd_store_chunk_size设置不合理太大导致单次写入超时二是 Ceph 集群本身处于 degraded 状态写入被阻塞三是网络问题尤其是存储网不通。排查顺序先ceph -s看集群健康再ceph osd pool stats images看池的 IO 情况最后检查 Glance 日志/var/log/glance/api.log里的具体报错。我遇到过一次是存储网网卡协商成了百兆导致大镜像上传极慢换网线就好了。6.3 虚拟机启动报存储访问错误这个问题的根源八成在 libvirt secret 上。检查步骤# 查看 secret 列表 virsh secret-list # 确认 secret 值是否正确 virsh secret-get-value 你的UUID如果 secret 不存在或值不对重新按 5.5 节的步骤配置。另外要确认计算节点上的/etc/ceph/ceph.client.cinder.keyring存在且权限正确一般 600属主是 cinder 或 root。6.4 云盘 IO 性能差如果虚拟机云盘 IO 慢先别急着怪 Ceph按这个顺序排查确认 journal 是否在 SSD 上这是影响最大的因素检查存储网带宽是否跑满用iftop或sar -n DEV看确认副本数三副本的写延迟天然比两副本高检查 OSD 是否分布均匀ceph osd df看各 OSD 使用率我有个实测数据同样硬件journal 从 HDD 换到 SSD4K 随机写 IOPS 从 300 提升到 4000 多云盘体验完全是两个档次。所以如果预算允许SSD 做 journal 是性价比最高的优化。6.5 重启后服务起不来集群重启后Ceph 和 OpenStack 的启动顺序有讲究。Ceph 要先于 OpenStack 起来否则 OpenStack 服务连不上存储会报错。我的做法是配置 systemd 依赖或者干脆写个启动脚本先等ceph -s显示 HEALTH_OK再启动 OpenStack 各服务。另外 MON 的启动需要 quorum如果三个 MON 同时重启要确保它们能互相通信网络没起来之前 MON 是起不来的。提示生产环境重启前先ceph osd set noout避免重启期间数据被判定为异常而触发大规模恢复。重启完成后再ceph osd unset noout。7. 性能调优与日常运维要点7.1 几个立竿见影的调优参数Ceph 的默认配置偏保守针对 OpenStack 场景我一般会调整这几个参数[osd] osd_memory_target 4294967296 osd_op_num_threads_per_shard 2 [client] rbd_cache true rbd_cache_size 134217728 rbd_cache_max_dirty 100663296osd_memory_target控制每个 OSD 能用多少内存默认值偏小适当调大能提升缓存命中率。rbd_cache开启客户端缓存对读多写少的场景提升明显。但要注意缓存开启后如果节点异常断电未刷盘的数据可能丢失对数据一致性要求极高的场景要谨慎。7.2 日常巡检该看什么我每天会花五分钟看这几个指标ceph -s整体健康状态ceph osd df各 OSD 使用率超过 80% 就要警惕ceph osd perf各 OSD 的延迟突然升高的要关注ceph pg statPG 状态有没有 stuck 的OpenStack 侧主要看openstack volume service list和openstack compute service list确认各服务状态是 up 而不是 down。7.3 扩容的正确姿势集群容量不够时加节点或加盘都行。加盘最简单新盘插上后ceph orch daemon add osd就行Ceph 会自动做数据再平衡。但要注意再平衡会消耗大量网络和磁盘 IO最好在业务低峰期做并且用ceph osd set norebalance控制节奏。加节点的话先把新节点加入集群再添加 OSD。新节点的硬件配置最好和现有节点接近否则数据分布会不均。8. 写在最后的一点个人体会这套 OpenStack 加 Ceph 的组合我前后搭了不下十次每次都会遇到新问题。最大的感受是网络规划和磁盘布局决定了这套环境的上限后期再怎么调优都很难突破前期规划的瓶颈。所以如果你正准备动手宁可多花两天把网络和磁盘规划清楚也别急着敲命令。另外Ceph 是个慢热的系统刚装完可能各种警告跑一段时间数据平衡了反而稳定。遇到 HEALTH_WARN 先别慌看清楚是哪个 PG、哪个 OSD 的问题大部分情况等它自己恢复就行。真正需要干预的往往是硬件故障或者配置错误。最后分享一个小技巧搭建阶段一定要养成看日志的习惯/var/log/ceph/和/var/log/glance/、/var/log/cinder/这几个目录出问题时第一时间去翻比在网上瞎搜效率高得多。日志里的报错信息往往直接指向根因只是很多人懒得看。