★ FEATURED ARTICLE 简介OpenStack与Ceph的分布式存储集成是当前云基础架构中的热门实践这份安装测试报告正是一份面向云计算运维工程师与OpenStack部署实施人员的完整参考文档。文件包仅含1个docx文档大小876KB但内容组织完整既有云计算与OpenStack的基础概念也梳理了Ceph的组件、CRUSH映射机制、强一致性与容错能力并与VMware方案做了对比可帮助读者快速建立技术坐标系。报告还针对在OpenStack中选择Ceph作为后端存储的考量、测试主机规划以及本地YUM源配置进行了说明展现出从理论到落地的完整路径。概念部分细致解释了什么是云计算、OpenStack核心组件以及Ceph的RADOS对象存储基础对OSD、MON、MDS、RGW等角色也有明确说明测试准备环节可操作性强。目前已有254人学习下载适合需要系统了解Ceph集成原理、准备实验环境或进行方案选型的技术人员。1. OpenStack 集成 Ceph 分布式存储一份能直接照着搭的安装测试报告去年我帮一个客户搭私有云计算节点本地盘吃紧打算上一套 Ceph 做统一存储后端。当时网上搜到的博客大多是「OpenStack 装到一半」或者「Ceph 单节点演示」真正把控制节点、计算节点、Ceph 集群和 Over Ceph 配置整条链路走完的极少。最后是翻到一份 OpenStack Ceph 分布式存储安装测试报告才把环境跑通——从本地 YUM 源、keystone/glance/nova/cinder 逐组件安装到 ceph-deploy 建集群再到让虚机跑在 RBD 上每一步都有对应操作和验证方法。这份资源适合三类人做 OpenStack 课程设计的学生、企业里做存储选型验证的运维、以及想搞明白「Ceph 到底怎么接进 OpenStack」的云计算从业者。它不解决架构设计问题但能让你少走两周弯路。2. 环境准备主机规划、本地 YUM 源与操作系统基线2.1 主机规划三个角色的 IP、内存与磁盘分配任何 OpenStack 部署翻车十有八九是规划阶段埋的雷。报告里的测试环境是典型的三类节点控制节点、计算节点、Ceph 存储节点。控制节点要跑 MySQL、keystone、glance、nova、cinder、dashboard 这一整套服务内存建议 8G 起步否则 MySQL 和 nova-api 同时启动时 swap 会疯狂抖动。计算节点主要跑 nova-compute 和虚拟机的 vCPU/内存CPU 核数和内存按需分配但要注意网卡——nova-network 和虚拟机流量共用物理网卡时千兆口很容易成为瓶颈。Ceph 节点是这份报告重点关照的对象每个节点至少要有一块独立的系统盘和数据盘数据盘不分区直接给 OSD 用这是我反复强调的一点千万别把 OSD 放在和系统同一个分区上后面扩容和故障替换都难受。IP 规划我一般习惯把管理网、存储网、业务网分开就算测试环境只有两三个网段也要预留出来。报告里的环境用了独立的存储网段承载 Ceph 的 public network 和 cluster network这个设计在测试阶段也许看不出差别但等到 OSD 做数据同步的时候存储流量和业务流量抢带宽的场景会让你很被动。集群规模不大的情况下这三类节点可以合并部署但报告里是分开的这更接近生产环境的形态复现价值也更高。节点角色建议配置关键服务备注控制节点4C8G100G 系统盘MySQL、keystone、glance、nova、cinder、dashboard数据库和消息队列都在这计算节点8C16G100G 系统盘nova-compute、nova-network虚机实例盘默认落在本地接 Ceph 后改为 RBDCeph 节点 ×34C8G100G 系统盘 1T 数据盘 ×Nceph-mon、ceph-osd数据盘不分区直接给 OSD2.2 本地 YUM 源createrepo 建仓库与客户端指向没有外网的环境里YUM 源是第一个卡点也是这份报告做得比较扎实的部分。它把 CentOS 基础包、OpenStack 相关 RPM 包和依赖包全部下载到一台服务器上用 createrepo 工具生成仓库元数据再通过 HTTP 发布。这个方法看起来朴素但非常实用——测试环境装到一半因为某个依赖包拉不下来而中断是最浪费时间的翻车方式。先装 createrepo 并创建仓库。下载好的 RPM 包按目录归类比如base、openstack、ceph分别放然后在每个目录下执行 createrepo 生成元数据# 安装 createrepo 工具 yum install -y createrepo httpd # 创建 RPM 包存放目录按组件分类 mkdir -p /var/www/html/yum/base mkdir -p /var/www/html/yum/openstack mkdir -p /var/www/html/yum/ceph # 把提前下载好的 RPM 包拷贝进对应目录后执行仓库初始化 createrepo --update /var/www/html/yum/base createrepo --update /var/www/html/yum/openstack createrepo --update /var/www/html/yum/ceph # 启动 httpd 并设置开机自启 systemctl start httpd systemctl enable httpd--update参数很关键它会在已有仓库基础上增量更新元数据而不是重建。如果有新增的 RPM 包放进目录只需再跑一次带--update的 createrepo 就行。做完这一步用浏览器访问http://YUM服务器IP/yum/能看到目录列表就说明发布成功。客户端配置指向这个本地源。在/etc/yum.repos.d/下新建一个local.repo把原有的网络源临时禁用避免装到一半 source 漂移cat /etc/yum.repos.d/local.repo EOF [base] nameLocal Base Repository baseurlhttp://192.168.1.10/yum/base enabled1 gpgcheck0 [openstack] nameOpenStack Repository baseurlhttp://192.168.1.10/yum/openstack enabled1 gpgcheck0 [ceph] nameCeph Repository baseurlhttp://192.168.1.10/yum/ceph enabled1 gpgcheck0 EOF # 清理缓存并验证仓库可用性 yum clean all yum repolistgpgcheck0在离线环境是常规操作因为你要么没有对应的 GPG 公钥要么下载时已经校验过完整性。最后一条yum repolist一定要执行它能确认三个 repo 都识别到了而且能看到每个仓库的包数量包数量为 0 基本就是路径问题或 createrepo 没跑成功。2.3 操作系统基线hosts、内核、网桥与 NTP系统层面有几项基础工作顺序不要乱。第一是/etc/hostsOpenStack 组件之间的通信大量依赖主机名hosts 解析配置错误会引发各种诡异问题最典型的就是 keystone 认证超时日志里全是Connection refused但 IP 明明能 ping 通。添加集群内所有节点的映射cat /etc/hosts EOF 192.168.1.10 controller 192.168.1.11 compute1 192.168.1.12 ceph1 192.168.1.13 ceph2 192.168.1.14 ceph3 EOF第二是网桥配置。OpenStack 实例要通过网桥接入网络报告里手工配置 Linux 网桥的步骤比直接调用 neutron 或 nova-network 自动创建要稳得多。测试环境里最常见的做法是修改网络脚本# 备份原有配置 cp /etc/sysconfig/network-scripts/ifcfg-eth0 /etc/sysconfig/network-scripts/ifcfg-eth0.bak cp /etc/sysconfig/network-scripts/ifcfg-br0 /etc/sysconfig/network-scripts/ifcfg-br0.bak # eth0 只负责物理链路不配置 IP cat /etc/sysconfig/network-scripts/ifcfg-eth0 EOF DEVICEeth0 TYPEEthernet BOOTPROTOnone ONBOOTyes BRIDGEbr0 EOF # br0 继承原来的 IP 配置 cat /etc/sysconfig/network-scripts/ifcfg-br0 EOF DEVICEbr0 TYPEBridge BOOTPROTOstatic IPADDR192.168.1.11 NETMASK255.255.255.0 GATEWAY192.168.1.1 ONBOOTyes EOF systemctl restart network注意 eth0 的BRIDGEbr0这行它告诉内核把 eth0 交给 br0 管理。配置完成后用brctl show查看留意到 br0 的 interfaces 列表里有 eth0 才算成功。这是个排查必查项很多时候 nova-network 起不来不是因为服务本身而是网桥没建好。第三是 NTP 时间同步。Ceph 的 MON 节点对时钟漂移极度敏感OSD 之间的心跳依赖时间戳时间不同步直接导致 MON 判定 OSD down。ntpdate一次性同步只能救急必须配置 cron 定期同步或启用 ntpd 服务。这一点在避坑章节会细说这里按下不表。3. 控制节点与计算节点组件安装顺序决定排错成本3.1 控制节点数据库、消息中间件与认证服务的启动顺序控制节点的服务安装顺序是有讲究的。MySQL 先装因为 keystone、glance、nova、cinder 都要建数据库接着是消息中间件报告里用的是 Qpid早期 OpenStack 版本Icehouse 前后的默认选择现在主流是 RabbitMQ但组件间解耦的思路完全一致然后才是 keystone——它一旦就绪后续所有组件都可以通过 keystone 做认证注册。MySQL 初始化这里有个细节OpenStack 各组件创建的数据库账号建议密码统一管理但权限按库隔离# 安装并启动 MySQL yum install -y mysql mysql-server systemctl start mysqld # 初始化并设置 root 密码 mysql_secure_installation # 创建各组件数据库和账号 mysql -uroot -p EOF CREATE DATABASE keystone DEFAULT CHARACTER SET utf8; CREATE DATABASE glance DEFAULT CHARACTER SET utf8; CREATE DATABASE nova DEFAULT CHARACTER SET utf8; CREATE DATABASE cinder DEFAULT CHARACTER SET utf8; GRANT ALL PRIVILEGES ON keystone.* TO keystonelocalhost IDENTIFIED BY keystone_pass; GRANT ALL PRIVILEGES ON keystone.* TO keystone% IDENTIFIED BY keystone_pass; GRANT ALL PRIVILEGES ON glance.* TO glancelocalhost IDENTIFIED BY glance_pass; GRANT ALL PRIVILEGES ON glance.* TO glance% IDENTIFIED BY glance_pass; GRANT ALL PRIVILEGES ON nova.* TO novalocalhost IDENTIFIED BY nova_pass; GRANT ALL PRIVILEGES ON nova.* TO nova% IDENTIFIED BY nova_pass; GRANT ALL PRIVILEGES ON cinder.* TO cinderlocalhost IDENTIFIED BY cinder_pass; GRANT ALL PRIVILEGES ON cinder.* TO cinder% IDENTIFIED BY cinder_pass; FLUSH PRIVILEGES; EOF%这个主机通配符容易被忽略它解决的是控制节点和计算节点从远程连接数据库时的授权问题。只授权localhost计算节点的 nova-compute 就没法连数据库这又是一个典型的「本地好好的、一跨节点就失败」的坑。keystone 安装配置的关键点在于连接 MySQL 和初始化数据库表然后设置 token。早期版本用 UUID token每请求一次就要查数据库校验后来引入 Fernet 才免掉了这个开销。报告里的keystone-manage db_sync执行后要确认没有 ERROR 输出然后配置令牌过期时间和签发方式# 安装 keystone yum install -y openstack-keystone python-keystoneclient # 修改 /etc/keystone/keystone.conf 中的数据库连接 # 关键参数connection mysql://keystone:keystone_passcontroller/keystone # 以及 [token] 段下的 provider keystone.token.providers.uuid.Provider # 初始化数据库 keystone-manage db_sync # 配置令牌 keystone-manage pki_setup --keystone-user keystone --keystone-group keystonedb_sync是把 keystone 的模型同步到 MySQL它在 OpenStack 各组件里是通用操作glance、nova、cinder 都要执行一遍。如果db_sync报错优先检查 MySQL 连接串里的密码是否和授权时的密码一致——这是最常见的低级错误。3.2 glance 与 cinder镜像服务和块存储服务为什么必须先于 novaglance 排在 nova 前面是因为 nova 创建虚机时需要从 glance 拉取镜像nova-compute 会调用 glance API 获取镜像元数据和数据流。glance 本身也要先经过 keystone 认证配置glance-api.conf里的认证地址时要写 keystone 的服务地址而不是 localhost——虽然测试环境可能都在同一台机器上但规范起见还是显式写 controller 主机名。cinder 也一样它依赖 keystone 认证、glance 做镜像服务最终还要对接后端的存储。cinder 放在组件安装的末尾并不是它不重要而是它前后依赖最多。配置 cinder 时有个参数容易踩坑——glance_api_version老版本默认是 1但 glance 的 v2 API 才是现在的主流。如果 cinder 通过 v1 API 连 glance 失败创建云硬盘时从镜像拷贝数据就会报错。安装并验证 glance 服务# 安装 glance yum install -y openstack-glance python-glanceclient # 初始化数据库 su -s /bin/sh -c glance-manage db_sync glance # 启动服务 systemctl start openstack-glance-api openstack-glance-registry systemctl enable openstack-glance-api openstack-glance-registry # 验证上传一张测试镜像能显示 active 状态即为成功 glance image-create --name cirros --file cirros-0.3.4-x86_64-disk.img \ --disk-format qcow2 --container-format bare --visibility public注意db_sync要以 glance 用户身份执行直接用 root 会有文件属主不一致的问题到时候 glance 进程写不了/var/lib/glance下的文件表现就是镜像上传后状态一直是 saving 而不是 active。这个问题在避坑章节还会再提。3.3 计算节点nova-compute 与 nova-network 的联动计算节点的安装重点是 nova-compute 和 nova-network。nova-compute 负责管理虚机的生命周期nova-network 则是早期 OpenStack 的默认网络方案通过 Linux 网桥和 iptables 规则实现 NAT 和安全组功能。报告里 Neutron 标注了「待测试」说明当时网络方案还停留在 nova-network 阶段——新项目直接用 Neutron 没问题但从控制节点的注册逻辑来看两者对 nova 来说都是「网络服务」nova 只关心如何调用网络接口。计算节点上 nova.conf 的配置核心就是注册信息和服务地址# 编辑 /etc/nova/nova.conf核心参数如下 # [database] connection mysql://nova:nova_passcontroller/nova # [keystone_authtoken] auth_uri http://controller:5000/v2.0 # [DEFAULT] my_ip 192.168.1.11 # [DEFAULT] vncserver_listen 0.0.0.0 # [DEFAULT] vncserver_proxyclient_address 192.168.1.11 # [DEFAULT] network_manager nova.network.manager.FlatDHCPManager # [DEFAULT] fixed_range 10.0.0.0/24 # [DEFAULT] flat_network_bridge br100 systemctl start openstack-nova-compute openstack-nova-network systemctl enable openstack-nova-compute openstack-nova-networkflat_network_bridge br100是 nova-network 的核心——虚机的 tap 设备都会桥接到 br100 上。如果这个网桥没有提前创建好nova-network 会尝试自己创建但有时会因为权限问题失败所以建议在配置网络时就手工建好。fixed_range定义虚机网段不要和物理网段冲突这是经验之谈冲突的话虚机网络会变得非常混乱。4. 部署 Ceph 集群ceph-deploy 建集群与 CRUSH 数据分布原理4.1 ceph-deploy 初始化集群mon、osd 的创建顺序Ceph 的安装分两条路线老版本用 ceph-deploy新版本推荐 cephadm。报告用的 ceph-deploy 虽然现在不再是首选但对理解 Ceph 的组件装配过程非常有帮助——它一条命令做完的事情恰恰是要搞清楚的底层逻辑先建 MON再建 OSD最后才是 pool 和客户端认证。ceph-deploy 的操作流程非常固定照着走基本不会错# 安装 ceph-deploy 工具在管理节点上执行 yum install -y ceph-deploy # 创建集群配置目录 mkdir /etc/ceph cd /etc/ceph # 初始化集群指定 MON 节点 ceph-deploy new ceph1 ceph2 ceph3 # 安装 ceph 软件包到所有节点 ceph-deploy install ceph1 ceph2 ceph3 # 初始化 MON 并收集密钥 ceph-deploy mon create-initial # 创建 OSD指向数据盘 ceph-deploy osd create ceph1:/dev/sdb ceph2:/dev/sdb ceph3:/dev/sdb # 同步配置和密钥到所有节点 ceph-deploy admin ceph1 ceph2 ceph3 # 检查集群状态 ceph -smon create-initial会生成一组密钥文件包括ceph.client.admin.keyring和ceph.bootstrap-osd.keyring前者是管理员操作集群的钥匙后者是 OSD 加入集群时用来自动注册的凭证。ceph-deploy admin的作用就是把 admin keyring 分发到各节点没有这一步节点上执行ceph命令会提示无法连接或认证失败。OSD 创建的两个关键点是磁盘必须是没有分区和文件系统的裸盘ceph-deploy osd create会自动完成分区、格式化和数据目录初始化如果磁盘之前用过要先用ceph-deploy disk zap清空直接复用带数据的分区会导致文件系统识别失败。4.2 CRUSH 映射与数据分布为什么副本数等于 2 也要注意 min sizeCeph 的数据分布靠 CRUSH 算法它和一致性哈希的区别在于CRUSH 不查表而是根据集群拓扑机架、主机、OSD 层级和规则直接计算出数据落在哪些 OSD 上。所以 CRUSH 没有中心化的元数据服务也就没有单点瓶颈。报告里对 CRUSH 的描述比较简略但实操时有两个参数绕不开size和min_size。size是副本数默认 3测试环境磁盘有限可以改成 2min_size是「降级但不停止服务」的最低副本数比如size2, min_size1意味着只有一个副本存活时集群还能继续提供读写但数据安全性已经降级了。# 创建存储池用于 OpenStack 的镜像、卷和虚机 ceph osd pool create volumes 128 ceph osd pool create images 128 ceph osd pool create vms 128 # 设置副本数为 2测试环境生产环境建议保持 3 ceph osd pool set volumes size 2 ceph osd pool set images size 2 ceph osd pool set vms size 2 # 设置 min_size ceph osd pool set volumes min_size 1 ceph osd pool set images min_size 1 ceph osd pool set vms min_size 1Pool 的 PG 数量设置是门玄学但有大致的经验公式PG 总数 (OSD 总数 × 100) / 副本数然后取最接近的 2 的幂次。3 个 OSD、副本 2 的情况下128 个 PG 是合理的选择。PG 太少会导致单个 PG 内数据过多、均衡度差太多则会增加 OSD 的内存开销和心跳负担。很多人纠结为什么 OpenStack 里要分 volumes、images、vms 三个 pool——这是职责隔离镜像和虚机的数据特点不同分开后可以独立设置配额、快照策略和 QoS。cinder 后端存储用 volumesglance 存镜像用 imagesnova 的虚机磁盘用 vms各有各的活。4.3 性能优化ssd journal、网络与内核参数Ceph 的性能瓶颈通常不在 CPU 和内存而在磁盘 IO 和网络。报告里的性能优化涉及两个方向一是北斗日志和数据的分离二是网络参数的调整。在有 SSD 的环境里把 OSD 的 journal日志盘放在 SSD 上能大幅提升写入性能。Ceph 的写路径是「先写 journal再写数据盘」journal 落盘后客户端就能收到 ACK所以 journal 的速度直接决定写延迟# 在 ceph.conf 中配置 OSD 参数 cat /etc/ceph/ceph.conf EOF [global] osd journal size 10240 osd max open files 131072 osd op threads 8 [osd] osd heartbeat grace 30 osd heartbeat interval 10 EOF # 同步配置到所有节点 ceph-deploy --overwrite-conf config push ceph1 ceph2 ceph3osd journal size单位是 MB设 10240MB 即 10G。journal 太小时高并发写入会频繁刷盘性能断崖式下跌。osd max open files影响同时打开的文件句柄数过低会导致 OSD 在压力下报Too many open files。osd heartbeat grace是 OSD 被 MON 判定为 down 的宽限时间网络抖动频繁的环境里适当调大可以减少误判。网络层面的调优集中在 TCP 缓冲区上Ceph 的数据传输走 TCP默认的读写缓冲区不一定能跑满万兆网卡# 修改 /etc/sysctl.conf提高网络吞吐 net.core.rmem_max 134217728 net.core.wmem_max 134217728 net.ipv4.tcp_rmem 4096 87380 134217728 net.ipv4.tcp_wmem 4096 65536 134217728 net.ipv4.tcp_sack 1 sysctl -p调完后用ceph -s观察osd perf的延迟数据以及ceph osd tree看数据分布是否均匀。如果某个 OSD 的写入延迟明显高于其他节点大概率是它的 journal 落在了和数据盘同一块 HDD 上——这就回到前面说的规划问题每个 OSD 节点最好单独准备一块 SSD 做 journal。5. 避坑记录OpenStack 和 Ceph 集成的四个高发问题5.1 现象ceph -s 显示 HEALTH_WARNOSD 状态为 down现象集群跑着跑着ceph -s提示HEALTH_WARN查看ceph osd tree发现有 OSD 是 down 状态但系统ps查看进程还在。原因OSD 进程正常但 MON 收不到它的心跳超过osd heartbeat grace时间后判定为 down。最常见的触发因素是时钟漂移其次是网络抖动导致心跳包丢失。Ceph 的 MON 之间和 OSD 之间对时间敏感节点间时间差超过 50ms 就会在ceph health里报CLOCK_SKEW。解决先同步时间再观察。配置 ntpdate 定时任务或启用 ntpd 服务Ceph 官方推荐所有节点使用同一台 NTP 服务器。如果时间正常检查存储网是否拥塞适当调大osd heartbeat grace。我自己遇到过一次是 Ceph 节点上的防火墙拦截了半开连接导致心跳包偶发丢失关掉 firewalld 后恢复。5.2 现象glance 上传镜像后状态一直是 saving现象执行glance image-create后镜像状态长时间停在saving最终报错或卡死。原因这个坑在纯 OpenStack 环境里不常见但接上 Ceph 后概率大增。glance 把镜像数据写到 Ceph 的 images pool如果 pool 不存在或者 glance 进程没有该 pool 的读写权限数据写入就会挂在半路。解决确认 images pool 存在用ceph osd pool ls检查再确认 glance 的 ceph 认证配置正确。检查/etc/glance/glance-api.conf里的rbd_store_pool参数并确保 client.glance 的 keyring 在 glance 进程可读的路径下# 检查 pool ceph osd pool ls | grep images # 给 glance 用户授权 images pool ceph auth caps client.glance mon allow r osd allow class-read object_prefix rbd_children, allow rwx poolimages5.3 现象cinder 创建云硬盘失败日志报 rbd 权限错误现象通过 dashboard 或命令行创建云硬盘时状态直接变为errorcinder-volume 日志里出现error connecting to the cluster或Permission denied。原因cinder 后端配置的 RBD 用户没有 volumes pool 的访问权限。cinder 不同于 glance它通过配置的rbd_user来连接 Ceph如果这个用户的 keyring 没有被 cephx 认证放行连接直接被拒。解决确认 cinder.conf 中rbd_user cinder且在 Ceph 中创建了 cinder 用户并授权然后重启 cinder-volume 服务# 创建 cinder 用户并授权 volumes pool ceph auth get-or-create client.cinder mon allow r osd allow class-read object_prefix rbd_children, allow rwx poolvolumes # 将 keyring 分发到控制节点 ceph auth get client.cinder -o /etc/ceph/ceph.client.cinder.keyring # 重启 cinder-volume systemctl restart openstack-cinder-volume5.4 现象nova live-migration 卡在 migrating 状态现象执行nova live-migration instance后虚机状态一直停留在 migrating目标节点上没有任何变化。原因在线迁移要保证源和目标节点的虚机磁盘内容一致这要求虚机磁盘放在共享存储上。接 Ceph 后虚机磁盘在 RBD 里理论上天然支持迁移但 nova-compute 需要知道「磁盘在 Ceph 上不需要本地拷贝」。如果 nova.conf 里没配置正确的libvirt和rbd参数nova 会尝试走本地文件拷贝的路径当然永久卡住。解决检查 nova.conf 中计算节点的 rbd 配置是否完整尤其镜像和虚机池的设置# /etc/nova/nova.conf 中 [libvirt] 段的核心参数 # [libvirt] images_type rbd # [libvirt] images_rbd_pool vms # [libvirt] images_rbd_ceph_conf /etc/ceph/ceph.conf # [libvirt] images_rbd_glance_pool_name images # [libvirt] rbd_user nova # [libvirt] rbd_secret_uuid uuidimages_type rbd这行决定了 nova-compute 把虚机磁盘放在 RBD 而不是本地它是热迁移能否进行的前提条件。6. 端到端验证从镜像上传到在线迁移的一次完整闭环测试6.1 镜像、云硬盘、虚机的贯通验证环境搭好之后报告里最后做了一次端到端验证这条链路完整走通才算真正交付上传镜像 → 创建云硬盘 → 从云硬盘引导虚机 → 把另一块云硬盘 attach 给虚机。首先是上传测试镜像然后基于镜像创建云硬盘# 上传镜像 glance image-create --name cirros --file cirros-0.3.4-x86_64-disk.img \ --disk-format qcow2 --container-format bare --visibility public # 查看镜像状态确认 active glance image-list # 创建 5G 云硬盘source 指定镜像 ID cinder create --image image-id --display-name boot-volume 5 # 查看卷状态确认 available cinder list从云硬盘引导虚机是 OpenStack 接 Ceph 后最常见的场景用nova boot的--block-device-mapping参数nova boot --flavor m1.small \ --block-device-mapping vdavolume-id:::0 \ --nic net-idnet-id \ ceph-test-instancevdavolume-id:::0的最后一位数字 0 表示从该卷引导如果写成 1 则会尝试先查镜像再挂卷。这一步正确后虚机起在 Ceph 的 vms pool 里数据落盘路径完全走 RBD。6.2 在线迁移的验证方法与 libvirt 配置最后验证在线迁移先在控制节点检查迁移功能所需配置然后执行迁移# 检查虚机当前所在计算节点 nova show ceph-test-instance | grep OS-EXT-SRV-ATTR:host # 执行在线迁移 nova live-migration ceph-test-instance compute2 # 等待迁移完成后再次检查宿主机 nova show ceph-test-instance | grep OS-EXT-SRV-ATTR:host迁移期间可以在另一个终端用watch ceph -s观察 RBD 层的 IOPS 变化。如果看到osd op rate明显上升但虚机服务没中断说明迁移流量确实走的是 Ceph 而不是本地磁盘拷贝。从那以后我每次验收 OpenStack 存储后端都会强制走一遍「镜像上传 → 创建卷 → 从卷起虚机 → 在线迁移」的完整闭环四步全通才算存储接入成功。这个习惯帮我挡掉过不少「配置看着没问题、一跑就露馅」的部署交付希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
三大根因与排查指南)
的一些常见问题)
