企业官网建设流程全解析

简介：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 map；MDS 只在 CephFS 文件系统场景里需要，OpenStack 块存储场景可以不装；RGW 提供 S3/Swift 兼容的对象接口，Swift 组件如果另立门户也可以不用它。报告第一章把这些组件列全了，但实际集成 OpenStack 你只需要 MON 和 OSD，MDS 和 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-repo

createrepo 生成的是 repodata 目录，客户端 yum 会去读里面的 primary.xml.gz。如果有多个子目录层级，记得用--baseurl指正确路径。用 httpd 发布时注意目录权限，SELinux 开启状态下 httpd 读不到/data下的文件，表现为客户端 yum 报 404，这是第一道坑。

客户端配置同样简单：

# /etc/yum.repos.d/openstack-local.repo [openstack-local] name=OpenStack Local Repo baseurl=http://192.168.1.100/openstack-repo enabled=1 gpgcheck=0

gpgcheck=0 在离线环境里是常见做法，如果你对安全有要求，可以先把 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 做准备。常见做法是把物理网卡桥到 br0，br0 持有 IP，物理网卡只跑流量不做配置：

# 把 eth1 桥到 br0，注意 NetworkManager 和 network 服务别打架 cat > /etc/sysconfig/network-scripts/ifcfg-br0 <<EOF DEVICE=br0 TYPE=Bridge ONBOOT=yes BOOTPROTO=static IPADDR=192.168.1.101 NETMASK=255.255.255.0 EOF

Bridge 配置翻车率极高，一大半是 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 -p

NTP 服务端指向一个稳定的上游或内网时钟源。Ceph 节点之间尤其要严格同步，MON 的时间差超过阈值就开始告警。建议在部署 Ceph 之前，先把每台节点的时间确认一遍。谁也不想集群建好了再补 NTP，那要清理状态重建，纯属自己折腾自己。

4. 控制节点与计算节点：从 MySQL 到 Nova 的安装顺序

4.1 控制节点组件安装顺序为什么不能乱

报告第四章的组件顺序是 MySQL → OpenStack 工具 → Qpid → Keystone → Glance → Nova → Dashboard → Cinder。这个顺序背后是依赖关系：Keystone 是所有服务认证的入口，所以它先装；Glance 依赖 Keystone 的 token 验证才能提供 API；Nova 又要去 Glance 拿镜像；Cinder 放最后，因为它要等 Nova 的网络和计算服务就绪才能完整测试。Qpid 在今天的新版本里已换成 RabbitMQ，但顺序逻辑不变：先数据库，再消息队列，再认证，再业务组件。

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.0

endpoint 地址写 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 地址指向控制节点的管理 IP，Qpid 地址也一样。装完后第一件事是检查服务有没有起来：

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 说明服务注册成功。

如果你只是要一个能用的 OpenStack，openstack kolla 容器化部署能省掉一大半手工折腾；但如果是想学习组件关系和排查逻辑，像这份报告一样手工从 yum 装一次是值得的。两条路径我都走过，手工装对故障定位的能力提升是容器化给不了的。容器化让你看不清组件之间的连线，出问题时只能重启服务先试一轮，而手工装过的环境里，你能直接定位到哪个配置文件写错了。

5. 安装避坑：五个翻车率最高的环节

这五个坑来自报告里各大章节最容易出问题的位置：YUM 源、网桥、认证、消息队列、在线迁移。每一条我都用“现象 → 原因 → 解决”拆开，你在自己环境里照着排查就行。

5.1 YUM 源 404：SELinux 和目录权限的经典组合

现象：客户端yum install时提示 404，yum 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 # 加上 bind=0.0.0.0 并设置 auth=no，实验环境常见做法 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 用qemu+tcp://compute-ip/system，然后重启 libvirtd：

systemctl 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 pool，cinder 要能读写 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 对象计数”的流程，确认后端没有悄悄退回文件存储。希望帮到你。

本文还有配套的精品资源，点击获取