简介OpenStack Ceph分布式存储安装测试报告以解决方案形式面向云端运维与存储架构设计人员系统梳理了在OpenStack环境中集成Ceph存储的关键技术与实操验证过程。文档先铺垫云计算概念、OpenStack各核心组件及其与VMware的差异再深入解析Ceph的背景、OSD/MDS/RGW/MON等核心组件、CRUSH数据映射算法、RADOS强一致性保障与分布式容错设计帮助读者建立从理论到实践的完整认知。资源为单个docx文档压缩包约876KB内容结构清晰涵盖从基础知识到本地YUM源配置、测试主机规划等后续部署要素。目前已有254人学习适合正在规划云存储选型或准备落地Ceph后端的工程师参考可直接用于理解机制、指导安装测试与后续优化。1. OpenStack 与 Ceph 这套组合到底解决什么问题现在网上 OpenStack 安装教程一抓一大把但多数是连着外网跑的。真正在机房、内网、虚拟机里实操过的人都知道没网时第一步就卡在 yum 源上。这份报告最实用的地方不是它把 Keystone、Nova、Cinder 一个个装完而是它给你一条完全离线的路线本地 YUM 源 手工部署控制节点和计算节点 后端接 Ceph 块存储。适合正在做 openstack 云平台搭建的实验、被 Cinder 后端性能问题折腾的运维也适合想完整过一遍 OpenStack 和 Ceph 组件关系的入门者。落笔先给你结论这套组合是 OpenStack 环境里很常见的分布式存储解决方案报告里明确标记“待测试”的部分恰恰是你在自己环境里最需要先动手验证的。2. 为什么后端要选 Ceph从组件到选型对比2.1 OpenStack 对存储后端的三种诉求镜像、块设备与对象OpenStack 里不是所有存储都归 Cinder 管。Glance 镜像要一个放 qcow2/raw 的仓库Nova 虚拟机的系统盘要能动态挂载Cinder 要提供体积可变的块设备Swift 管对象。Ceph 的 RBD 能当 Glance 后端、Cinder 后端还能让 Nova 直接从 RBD 起虚机一份存储消化三种诉求。这就是为什么架构图里通常把 Ceph 画在 OpenStack 下方、而不是并列在左侧。市面上也有拿 minio 做分布式存储替代者的说法。minio 偏对象存储S3 协议很成熟但块设备接口和 RBD 内核级驱动是两回事。OpenStack 场景选 Ceph 不选 minio不是因为 minio 不好是因为 Cinder 和 Nova 需要的是能承载读写 IO 的块设备不是对象桶。你在 dashboard 里创建一块 20GB 云硬盘底层要的是一个能直接格式化成 ext4 并挂载的设备对象存储的语义在这里绕了一圈又回到性能损耗上没必要。2.2 Ceph 核心组件与 CRUSH读懂 OSD、MON、MDS、RGW 的分工Ceph 的组件分工要分清OSD 管数据实际上盘一个 OSD 对应一块物理磁盘或分区MON 管集群状态保存着一张全局的 cluster mapMDS 只在 CephFS 文件系统场景里需要OpenStack 块存储场景可以不装RGW 提供 S3/Swift 兼容的对象接口Swift 组件如果另立门户也可以不用它。报告第一章把这些组件列全了但实际集成 OpenStack 你只需要 MON 和 OSDMDS 和 RGW 对 cinder 后端不是必须的装了反而增加排查面。CRUSH 算法是 Ceph 分布数据的核心它不用查表通过哈希计算直接决定数据落在哪个 OSD 上。OSD 增加或减少时只有部分 PG 需要重新分布数据迁移范围可控这是 Ceph 敢说线性扩展的底气。强一致性和多副本靠的是 RADOS 层的 PG 主从机制写操作要等副本确认才返回所以副本数直接决定数据安全上限OSD 数量决定性能下限。2.3 OpenStack 与 VMware 的选型什么场景别碰 Ceph报告里有一页 OpenStack 与 VMware 对比。结论不复杂OpenStack 是开源多组件体系适合按需定制、学原理、控制成本VMware 是企业级成熟产品适合已有投资保护和稳定要求极高的环境。对应到存储层vSphere 通常配 VSAN 或传统 FC-SAN管理成本低但闭源出了问题你能做的只有提工单Ceph 的高扩展性、低成本、无单点故障是实打实的代价是部署和调优必须有人懂。我的建议很直接节点少于 3 个、没有专职运维、只有一两块普通机械盘做存储的实验环境不建议硬上 Ceph。这份报告里的组合要 3 个 MON 加若干 OSD 的规模才体现出价值单机甚至双机跑 Ceph副本策略会把可用容量砍掉一半纯属给自己找事。2.4 报告覆盖范围的边界动手前先列一张待办清单报告目录里有两处特别显眼“Neutron 网络节点待测试”和“虚拟化知识介绍待补充”。这意味着网络部分这份报告没有给你完整答案实战中要么用 nova-network 顶上要么单独补 Neutron 的部署。我的做法是复现前按这份报告先把 nova-network 跑通再单独规划 Neutron不要指望一份文档把所有组件都覆盖到。动手前先做三件事第一确认所有节点时间一致后面 NTP 会细讲这是最容易忽略的第二把 YUM 源准备好离线环境这一步没过就别往后走第三把每个组件的数据库密码、服务密码写进一个本地备忘文件后面配置里写错一个字母排查成本翻倍。这几步做好后面的安装过程只是复制粘贴而已。3. 环境准备本地 YUM 源、内核升级与系统初始化3.1 本地 YUM 源是离线部署的基石报告第二章整章讲 YUM 源这是被很多人跳过、却在离线环境里最关键的步骤。思路不复杂在一台能联网的机器上把需要的 rpm 包收集齐全打包传到内网服务器用 createrepo 生成元数据再用 HTTP 发布最后把客户端的 repo 文件指向这台 YUM 服务器。# 在 YUM 服务器上先装 createrepo指向放 rpm 包的目录 yum install -y createrepo mkdir -p /data/openstack-repo/Packages # 把收集到的 rpm 包全部放进 Packages 目录然后生成仓库元数据 createrepo /data/openstack-repocreaterepo 生成的是 repodata 目录客户端 yum 会去读里面的 primary.xml.gz。如果有多个子目录层级记得用--baseurl指正确路径。用 httpd 发布时注意目录权限SELinux 开启状态下 httpd 读不到/data下的文件表现为客户端 yum 报 404这是第一道坑。客户端配置同样简单# /etc/yum.repos.d/openstack-local.repo [openstack-local] nameOpenStack Local Repo baseurlhttp://192.168.1.100/openstack-repo enabled1 gpgcheck0gpgcheck0 在离线环境里是常见做法如果你对安全有要求可以先把 GPG key 导入再改成 1。我一般习惯把 gpgcheck 留着 0把精力放在校验包来源上毕竟离线仓库里放什么包取决于你自己。3.2 系统初始化hosts、环境变量与关闭多余服务报告 3.1 到 3.5 是系统准备。hosts 要写全所有节点的 IP 和主机名OpenStack 组件之间相互解析靠它少一条会在 keystone 认证时报 host 找不到。cat /etc/hosts EOF 192.168.1.101 controller 192.168.1.102 compute 192.168.1.103 ceph-mon1 EOF环境变量主要指向 Python 路径和 PATH报告里单独列了一节。这步看起来啰嗦但老版本 OpenStack 的组件脚本对 Python 路径很敏感环境变量不对服务起来后调用 python 模块会报 ImportError。关闭不必要的系统服务也是常规操作防火墙、NetworkManager 这类服务在实验环境里建议直接停掉并禁用尤其 NetworkManager 和后面手工配置的网桥有冲突。内核升级这步要慎重。老版本 OpenStack 对内核版本有要求通常是为了兼容 libvirt 和 kvm。升级后必须重启重启前确认 hosts、环境变量都写对了不然一次重启把所有配置打回原形。升级完成后用uname -r核对版本号别跳到下个环节才发现内核没换过来。3.3 手工配置网桥注意持久化报告 3.4 是手工配置操作系统网桥这里给 nova-network 做准备。常见做法是把物理网卡桥到 br0br0 持有 IP物理网卡只跑流量不做配置# 把 eth1 桥到 br0注意 NetworkManager 和 network 服务别打架 cat /etc/sysconfig/network-scripts/ifcfg-br0 EOF DEVICEbr0 TYPEBridge ONBOOTyes BOOTPROTOstatic IPADDR192.168.1.101 NETMASK255.255.255.0 EOFBridge 配置翻车率极高一大半是 NetworkManager 和 network 服务同时在管同一块网卡。我一般会把 NetworkManager 停掉再配 bridge配完后systemctl restart network然后立刻ip addr看 br0 有没有真正拿到 IP。在 ifcfg-eth1 里把 BOOTPROTO 和 IPADDR 字段删干净不然重启后 IP 冲突这台节点直接失联。3.4 NTP 时间同步安装前必须做没有后悔药报告 3.6 装 NTP。很多人不理解为什么存储和云平台要时间同步。keystone 的 token 有有效期Ceph 的 MON 之间靠时间戳协调状态差了超过阈值直接报 clock skew。这是那种“所有服务都正常但就是连不上”的玄学问题实际是时间漂移把 token 验证干掉了。yum install -y ntp systemctl start ntpd ntpq -pNTP 服务端指向一个稳定的上游或内网时钟源。Ceph 节点之间尤其要严格同步MON 的时间差超过阈值就开始告警。建议在部署 Ceph 之前先把每台节点的时间确认一遍。谁也不想集群建好了再补 NTP那要清理状态重建纯属自己折腾自己。4. 控制节点与计算节点从 MySQL 到 Nova 的安装顺序4.1 控制节点组件安装顺序为什么不能乱报告第四章的组件顺序是 MySQL → OpenStack 工具 → Qpid → Keystone → Glance → Nova → Dashboard → Cinder。这个顺序背后是依赖关系Keystone 是所有服务认证的入口所以它先装Glance 依赖 Keystone 的 token 验证才能提供 APINova 又要去 Glance 拿镜像Cinder 放最后因为它要等 Nova 的网络和计算服务就绪才能完整测试。Qpid 在今天的新版本里已换成 RabbitMQ但顺序逻辑不变先数据库再消息队列再认证再业务组件。组件作用控制节点计算节点MySQL存各组件的数据库是否Qpid/RabbitMQ组件间消息传递是否Keystone认证与令牌是否Glance镜像管理是否Nova计算服务是是DashboardWeb 控制台是否Cinder块存储服务是是MySQL 安装后要立刻做初始化并设定 root 密码。老版本 OpenStack 常配 MariaDB命令路径略有差别但思路一致# 安装 MySQL 并初始化密码 yum install -y mariadb-server systemctl start mariadb mysql_secure_installation # 为 keystone 建库和授权密码要和你后面 keystone.conf 里一致 mysql -u root -p CREATE DATABASE keystone DEFAULT CHARACTER SET utf8; GRANT ALL PRIVILEGES ON keystone.* TO keystone% IDENTIFIED BY keystone_pass;数据库字符集用 utf8别用默认 latin1。这个坑在 dashboard 显示中文乱码的时候才被想起来。每个组件的库、用户名、密码要统一记到一处后面配置写错一个字母排查成本翻倍。MySQL 的监听地址默认只在本地但计算节点的 nova 也要连数据库的话需要把 bind-address 改成管理网 IP。4.2 Keystone、Glance、Nova 的关键配置段Keystone 安装后要初始化数据库表并设置令牌。老版本常见 UUID token靠数据库存 token 有效期新版本用 fernet免数据库存储。这份报告配置的是 UUID 风格# keystone-manage 初始化数据库 su -s /bin/sh -c keystone-manage db_sync keystone # 创建服务实体和 endpoint openstack service create --name keystone identity openstack endpoint create identity \ --publicurl http://controller:5000/v2.0 \ --internalurl http://controller:5000/v2.0 \ --adminurl http://controller:35357/v2.0endpoint 地址写 controller 主机名还是 IP 取决于你的环境。我建议节点内部引用用主机名、外部访问用 IP否则跨网段访问时 endpoint 对不上。这一点在 dashboard 里点“上传镜像”报 503 时经常被翻出来。Glance 的核心配置在/etc/glance/glance-api.conf认证部分指向 keystone存储后端默认是本地文件。报告 8.3.1 才把它切到 Ceph在那之前先用文件后端把镜像上传流程跑通openstack image create --file cirros.qcow2 cirros-test openstack image list如果这一步能列出镜像说明 keystone 认证链路是通的。后面切 Ceph 后端时只需要改 store 参数不用再排查认证问题。Nova 配置文件比较散nova.conf里要写 database 连接、keystone 认证、my_ip、VNC 地址。计算节点和控制节点各写各的 my_ip这个值写错了虚拟机迁移和 VNC 连接都会出问题。改完配置记得重启服务OpenStack 的配置加载只在服务启动时发生。4.3 计算节点最小安装与常见检查命令计算节点不用装 keystone 和 glance只装 nova-compute、nova-network、cinder。它的 nova.conf 里 controller 地址指向控制节点的管理 IPQpid 地址也一样。装完后第一件事是检查服务有没有起来systemctl status openstack-nova-compute systemctl status openstack-nova-network # 看日志重点看 qpid 连接和数据库连接有没有报错 tail -f /var/log/nova/nova-compute.log常见现象是 nova-compute 起来后马上退出多半是数据库连接串或 keystone 认证地址不通。控制节点上验证nova service-list能列出 compute 节点说明注册成功。如果列表里没有主机先查/etc/nova/nova.conf里的 host 和控制节点的/etc/hosts是否一致。计算节点的 libvirt 也要确认是 kvm 还是 qemu 模式虚机起不来的日志里通常会写。4.4 Dashboard 与 Cinder 的服务验证Dashboard 装上后在浏览器访问控制节点 IP登录用 keystone 里创建的 admin 用户。报告里特意为 dashboard 创建了 stack 用户建议用独立用户而不是 admin 登录操作避免权限过大把控制面搞坏了。Cinder 装完后用cinder list验证 API暂时没有 volume 也不怕只要不报 503 说明服务注册成功。如果你只是要一个能用的 OpenStackopenstack kolla 容器化部署能省掉一大半手工折腾但如果是想学习组件关系和排查逻辑像这份报告一样手工从 yum 装一次是值得的。两条路径我都走过手工装对故障定位的能力提升是容器化给不了的。容器化让你看不清组件之间的连线出问题时只能重启服务先试一轮而手工装过的环境里你能直接定位到哪个配置文件写错了。5. 安装避坑五个翻车率最高的环节这五个坑来自报告里各大章节最容易出问题的位置YUM 源、网桥、认证、消息队列、在线迁移。每一条我都用“现象 → 原因 → 解决”拆开你在自己环境里照着排查就行。5.1 YUM 源 404SELinux 和目录权限的经典组合现象客户端yum install时提示 404yum repolist能看到仓库但拿不到包。原因SELinux 开启时httpd 默认不允许访问/data这类非标准目录或者 Packages 目录里 rpm 文件权限不对apache 用户读不了。解决# 先把 httpd 对 /data 目录放行或者直接临时关闭 SELinux 验证 chcon -R -t httpd_sys_content_t /data/openstack-repo systemctl restart httpd # 客户端验证 yum repolist yum install -y openssh-clients关闭 SELinux 只是临时验证手段正规做法是chcon或semanage fcontext。如果你手上这台机器是生产环境别图省事直接 setenforce 0用 chcon 打标签花不了两分钟。5.2 Bridge 配置重启即失效NetworkManager 抢管理权现象配好 br0 后网络服务正常重启或systemctl restart network后 bridge 没了或者 IP 跑到物理网卡上。原因NetworkManager 和 network 服务同时管同一块网卡NetworkManager 重启时覆盖了 ifcfg-br0 的配置。解决禁用 NetworkManager只用 network 服务systemctl stop NetworkManager systemctl disable NetworkManager # 确保 ifcfg-eth1 里没有 BOOTPROTO 和 IPADDR 的重复定义 vi /etc/sysconfig/network-scripts/ifcfg-eth1 systemctl restart network建议配 bridge 前先备份 eth1 的配置。写 bridge 时把 eth1 的 IP 字段删干净IP 地址只留在 br0 上不然同一块物理 IP 会冲突。5.3 Keystone 认证报错token 配置和 endpoint 不一致现象openstack token issue报 Unauthorized或者 dashboard 能登录但 glance 里看不到镜像。原因八成是 keystone.conf 和各个服务配置文件里的 token 过期时间、算法不一致或者 endpoint 写的是 IP 但从另一台节点访问时用的是主机名解析对不上。解决# 先确认 keystone 自身能不能签发 token openstack --os-auth-url http://controller:35357/v2.0 \ --os-username admin --os-password admin_pass token issue # 再确认其他服务配置里的 auth_url 指向一致 grep -r auth_url /etc/glance/如果 keystone 自己都签不出 token查 keystone 日志里有没有 database connection 失败的记录。这个坑还有一个隐蔽变种数据库连接串里的密码如果有#或这类特殊字符会被配置文件解析吃掉一段服务起来不报错但认证永远失败。5.4 Qpid 连接断开Nova 服务反复重启现象nova-compute 日志里反复出现qpid connection closed服务状态是 starting 或 failed。原因qpid 消息服务的监听地址默认只在回环接口或者认证配置中密码不一致。这个坑在安装顺序上容易被忽略因为 qpid 本身启动不报错。解决# 修改 qpid 配置监听所有接口 vi /etc/qpid/qpidd.conf # 加上 bind0.0.0.0 并设置 authno实验环境常见做法 systemctl restart qpidd # 计算节点也确认 /etc/nova/nova.conf 里的 qpid 主机名和密码一致qpid 版本差异较大部分版本参数名不一样出问题先看qpidd --help确认支持哪些选项别照抄网上的命令。这里的核心是确认计算节点能 TCP 连上控制节点的 qpid 端口用telnet controller 5672试一下最直接。5.5 在线迁移失败两端计算节点配置不一致现象nova live-migration执行后虚机一直停留在 migrating 状态最后迁移失败回滚。原因很多情况下不是网络而是两端计算节点的 libvirt 配置不一致比如 live_migration_uri 用的协议不同、qemu 用户不同或者 nova.conf 里libvirt_cpu_mode有差异。虚机在两台主机间做热迁移CPU 特性、存储路径、网络模型任何一项不匹配都可能中断。解决对齐两台节点的/etc/libvirt/libvirtd.conf和 nova.conf 的 libvirt 段确认迁移 uri 用qemutcp://compute-ip/system然后重启 libvirtdsystemctl restart libvirtd # 检查两端配置差异 diff /etc/libvirt/libvirtd.conf /etc/libvirt/libvirtd.conf.bak文件后端时在线迁移要把镜像内容在节点间传一遍数据量大时迁移时间呈指数增长切到 Ceph RBD 后镜像在共享存储上迁移只传内存状态速度会有质的提升。这正好是第六章要说的内容。6. Ceph 部署与 OpenStack Over Ceph认证配置与后端验证技巧6.1 ceph-deploy 部署与集成参数报告第七章用 ceph-deploy 装 Ceph最小集群一个 MON 加若干 OSD 就能跑但生产至少三个 MON。部署命令本身不复杂# 在主控节点安装并初始化 ceph-deploy new ceph-mon1 ceph-deploy install ceph-mon1 ceph-osd1 ceph-osd2 ceph-deploy mon create-initial ceph-deploy osd create ceph-osd1:/data/osd集成到 OpenStack 的核心是给 glance、cinder、nova 各发一份 cephx key并写在对应配置文件里# glance-api.conf [glance_store] stores rbd rbd_store_pool images rbd_store_user glance rbd_store_ceph_conf /etc/ceph/ceph.conf# cinder.conf [DEFAULT] enabled_backends ceph [ceph] volume_driver cinder.volume.drivers.rbd.RBDDriver rbd_pool volumes rbd_user cinder# nova.conf [libvirt] images_type rbd images_rbd_pool volumes特别注意nova 和 cinder 共用一个 volumes pool 时每个服务用各自的 cephx key别图方便共享 admin key。nova 要能读 glance 的 images poolcinder 要能读写 volumes pool权限粒度分清楚不然起虚机时报 permission denied日志里只写 rbd error排查起来很累。6.2 验证后端是否真实生效一个靠谱的检查习惯报告 8.4 是“测试从 ceph 存储起虚机”上传镜像、创建云硬盘、虚机引导、attach 一整套。我自己的验证习惯是每配完一个服务就回 ceph 侧看一眼对象有没有真的写进去ceph osd pool ls rados -p images ls rados -p volumes ls在 dashboard 上传一个镜像后rados -p images ls能看到 glance 前缀的 rbd 镜像创建一块云硬盘后rados -p volumes ls里出现新块设备。如果界面上显示成功但 pool 里没有新对象说明配置里走的还是文件后端检查 glance-api.conf 的 stores 参数是否生效通常改完要重启 glance-api 并清一遍缓存。这一步比看任何 dashboard 状态都靠谱因为 dashboard 只显示上层 API 的结果不保证数据真的落到了 Ceph。在线迁移的验证也一样nova live-migration之前先确认两台计算节点的 libvirt 配置一致。Ceph RBD 作为共享后端迁移过程不需要拷贝镜像文件只要 target 节点的内核支持 rbd 驱动就能秒迁。我早期用文件后端试过在线迁移镜像在节点间传了十几分钟还卡死切到 RBD 之后同一套操作基本一两分钟完成。把那几行配置核对一遍报错概率大幅下降。把这几步走通你等于验证了整条链路的真实性glance 上传 → cinder 创建卷 → nova 从 RBD 起虚机 → live migration。从那以后我每次搭环境都会强制走一遍“上传镜像 → 起虚机 → 看 pool 对象计数”的流程确认后端没有悄悄退回文件存储。希望帮到你。本文还有配套的精品资源点击获取