三节点OpenStack超融合部署指南：从原理到排障

简介：OpenStack超融合系统用户手册是一份围绕HCS1000 G1系列超融合系统展开的操作指南，目标读者是数据中心运维人员、云计算平台管理员，以及刚接触OpenStack的入门用户。手册从最基础的登录/退出和密码管理讲起，包含账号密码修改、忘记密码找回、资源配额的查看与申请流程；随后进入一键VPC功能，指导用户快速创建隔离网络、自定义网络拓扑和安全策略，并随时查看VPC状态；在虚拟机部分，详细列出创建、启动、停止、迁移和删除等生命周期操作；存储部分则覆盖块存储与对象存储的卷管理、容量扩展及备份策略；网络管理涉及路由器、子网和安全组配置；此外还包括资源实时监控与告警、自动化部署与故障恢复，以及强密码、防火墙规则等安全合规建议。资源包内仅含1个docx文档，约2.58MB，目录按系统简介、VPC、虚拟机、存储、网络等模块组织，方便对照查阅。已有317人学习下载，适合作为超融合环境下OpenStack平台的操作备查手册和团队培训参考资料。

1. OpenStack超融合系统到底是什么：三台物理机怎么撑起一套私有云

OpenStack 超融合系统并不是 OpenStack 项目手册里的官方名词，而是厂商把控制节点、计算节点和存储节点合并到同一批物理机之后形成的交付形态。你拿到这份 .docx 用户手册，多半是团队刚采购或准备自建私有云，手头只有几台服务器，却想同时跑出虚拟机、块存储和对象存储。超融合解决的正是这个矛盾：用副本代替 RAID 卡兜底，把 SAN 存储换成软件定义存储，让控制、计算、存储三类角色共享 CPU 与磁盘。适合谁？适合不想单独养存储阵列、又需要快速交付云主机的中小团队，也适合做 OpenStack 云平台搭建验证的技术人员。这篇笔记按三节点起步来写，覆盖部署、初始化、备份和排障，并把手册里普遍写得很含蓄的坑单独拉出来。

2. 为什么三节点超融合能交付虚拟机：控制合设与 Ceph 存储的关键关系

2.1 控制平面与数据平面：先搞懂控制节点要扛多少东西

OpenStack 本质是一组无状态 API 服务加上一堆有状态后端：keystone 负责认证，nova 负责计算，neutron 负责网络，cinder 负责块存储，glance 负责镜像。超融合架构里，这几类角色不再分机器部署，而是把控制组件集中到一台或两台机器上。

三节点场景最常见的布局是 1 控 2 算：第 1 台跑控制平面全部服务，第 2、3 台跑 nova-compute 与分布式存储 OSD。控制节点上要同时跑 mariadb、rabbitmq、keystone、nova-api、nova-scheduler、nova-conductor、neutron-server、cinder-api、glance-api 以及 horizon，这些进程平时 CPU 占用不高，但 API 请求一多，最先撑不住的不是计算资源，而是数据库连接和消息队列堆积。

所以控制节点的内存规划要比计算节点更宽裕。我一般建议控制节点 64G 起步，计算存储节点 128G 起步，因为每台节点上跑多个 OSD 时，page cache 会吃掉大量内存。如果控制节点内存只有 16G，你创建一个云主机时还不觉得有什么，一旦批量创建 30 台虚拟机，nova-scheduler 调度、cinder 建卷、neutron 分配网段同时涌进来，mariadb 的连接数会先被打满，表现为创建任务卡在 BUILD 状态不更新。

2.2 Ceph 在超融合里的角色：glance、cinder 与 nova 共用一个存储池

超融合与传统 OpenStack 最大的区别在存储底座。传统架构里，镜像放 NFS 或集中式存储，虚拟机磁盘放本地 RAID，块设备走 SAN；超融合则用 Ceph 把这三种数据统一到一套分布式存储里。

Ceph 提供 RBD 块设备，glance 把镜像文件写入 images 池，cinder 把卷放在 volumes 池，nova 创建云主机时如果需要临时盘，也可以直接写在 vms 池。三个池共用同一批 OSD，但池之间通过 pg 数量、副本数独立管理。这套设计带来的好处是，计算节点本身不需要大容量本地盘，所有数据都能在节点间漂移；代价是网络压力翻倍，因为每次写数据都要把副本复制到其他节点。

这里有个新手常忽略的容量账。Ceph 默认三副本，一份数据写三份，一个 10T 的集群可用空间只有 3.3T 左右。不少人在采购时按原始容量算存储，上线一个月后发现空间告急才回来改副本数。超融合场景下，三副本是保证数据可靠性的底线，两副本通常只允许在测试环境用。你可以通过 CRUSH map 调整规则，但生产环境不建议为了容量牺牲副本数。

2.3 硬件选型的容量账：按副本数算一遍你真正可用的空间

三节点超融合的硬件选型，重点不在品牌而在参数匹配。管理网千兆即可，业务网和存储网最好 25G 起，存储网络用万兆是底线，否则多节点同时写盘时，网络会成为整条链路的瓶颈。

组件配置参考如下表，按三节点、每节点 4 块 4T SATA 盘加 2 块 480G SSD 来举例：

容量计算公式可以写为：

可用容量 = 单盘容量 x 盘数 x 节点数 x (1 / 副本数) x (1 - 预留余量)

预留余量通常取 0.1，用于重均衡和故障域切换。按上表三节点 12 块 4T 盘计算，原始容量约 48T，三副本后折到 16T，再扣 10% 预留，实际可用约 14.4T。这笔账必须在采购前算清楚，否则后续扩容要加盘，导致整个集群的 CRUSH map 重新调整，操作成本很高。

3. 用 PackStack 搭建 OpenStack 云平台的最小路径：从应答文件到第一台云主机

3.1 部署前必须完成的网络规划与主机名解析

基于 PackStack 安装 OpenStack 是社区里最常见的快速部署方式，适合实验室验证和小规模交付。它本质上是把各个 OpenStack 组件的服务编排成一批 Puppet 配置，自动去装包、改配置、初始化数据库。注意 PackStack 不是生产环境高可用方案的替代品，它默认生成的架构是单控制节点。

部署前要先把网络分区定死。每个节点至少两张网卡，一张走管理网络，承载 SSH、API、数据库和消息队列流量；另一张走业务网络，承载云主机流量。如果条件允许，存储流量单独拆一张 25G 网卡，不要跟业务网络混跑。混跑的问题当时不明显，但只要你开始做快照或批量创建卷，存储流量瞬间占满带宽，业务虚机就会出现卡顿。

主机名解析是另一个容易踩的地方。OpenStack 各组件间通信频繁走主机名，而不是 IP。我在所有节点上都会配好 /etc/hosts，把三台机器的主机名和 IP 都写进去，并且保证 hostname -f、hostname -s 的输出与 hosts 一致。不要依赖 DNS 服务器，因为 OpenStack 服务启动时查询 DNS 失败，会表现为服务起来了但互相连不上。

3.2 生成应答文件并调整参数：交给 PackStack 之前先想清楚这几项

PackStack 的典型操作是先让工具给你生成一份应答文件，然后人工改关键项。生成命令如下：

# 在规划为控制节点的机器上执行，生成应答文件 packstack --gen-answer-file=/root/answers.txt

生成的 answers.txt 有几百行，不要全改，只需要关注几类字段：计算节点列表、网络节点列表、Ceph 安装开关、Cinder 后端类型。我把最小三节点超融合场景下的关键修改项列出来：

# 应答文件关键参数说明，字段在不同版本里小有差异 CONFIG_COMPUTE_HOSTS=192.168.1.11,192.168.1.12,192.168.1.13 # 三个节点既当计算节点，也准备作为超融合存储节点的一部分 CONFIG_NETWORK_HOSTS=192.168.1.11 # 网络代理服务集中在控制节点，避免多节点竞争 DHCP 地址池 CONFIG_CEPH_INSTALL=y # 启用 Ceph，才能让 glance/cinder/nova 使用 RBD 后端 CONFIG_CINDER_BACKEND=ceph # 明确 Cinder 后端走 Ceph 驱动

这里 CONFIG_COMPUTE_HOSTS 填三台节点，意味着每台都安装 nova-compute；CONFIG_NETWORK_HOSTS 只填控制节点，是为了避免 neutron 的 DHCP 和 L3 服务在多个节点上冲突。Ceph 安装开关打开后，PackStack 会一并完成 Ceph 监控节点和 OSD 的初始化。

改完后执行安装：

# 按应答文件安装，时间较长，建议用 nohup 或 tmux 保持会话 packstack --answer-file=/root/answers.txt 2>&1 | tee /root/packstack.log

执行过程中不要手动去 apt/yum 其他包。日志文件里出现 “ID: ... SUCCESS” 字样说明对应步骤完成，如果出现 FAIL，直接去查日志中标注的模块名。PackStack 的幂等性做得一般，失败后直接重跑常常会撞上残留的数据库或配置，更可靠的做法是看日志定位具体失败的组件，卸载该组件的包再继续。

3.3 云主机创建五连：镜像、网络、子网、虚拟机、数据卷

安装完成后，会生成一个 /root/keystonerc_admin 文件。source 它之后，命令行就能直接调用 OpenStack API。创建第一台云主机的路线通常是镜像、网络、子网、虚拟机、数据卷五步：

# 加载管理员环境变量 source /root/keystonerc_admin # 上传一个小体积测试镜像，qcow2 格式最省空间 openstack image create --file ./cirros.qcow2 --disk-format qcow2 \ --container-format bare --public cirros # 创建 Flat 类型的物理网络，physnet1 对应业务网卡名称 openstack network create --provider-network-type flat \ --provider-physical-network physnet1 flat-net # 给网络划分一个子网，DNS 按实际环境填 openstack subnet create --network flat-net --subnet-range 10.10.0.0/24 \ --dns-nameserver 114.114.114.114 --gateway 10.10.0.1 flat-subnet # 创建云主机，使用 2C4G 规格，固定到 flat-net openstack server create --flavor m1.small --image cirros \ --network flat-net test-vm # 创建一块 10G 数据卷，并挂载到云主机上 openstack volume create --size 10 test-vol openstack server add volume test-vm test-vol

这段操作的逻辑是先把镜像注册进 glance，然后让 neutron 准备好二层网络，最后通过 nova 调度把虚拟机制造出来。挂卷这一步验证了 Ceph 后端是否真正生效，如果卷创建后一直卡在 creating，说明 cinder-volume 到 Ceph 的认证或网络不通，需要回到 cinder.conf 检查 rbd 相关配置。

打开 Dashboard 之后，用 admin 账号登录，能看到镜像、网络和云主机的状态。如果这三个界面都能正常显示数据，说明这套最小超融合已经具备交付云主机的基本能力。

4. 日常备份与故障恢复顺序：控制节点挂了先救这三样

4.1 数据库层的五库逻辑备份：直接决定你能不能恢复

OpenStack 超融合系统里最脆弱的不是计算进程，而是数据库。keystone、nova、neutron、cinder、glance 各有一套数据库，里面存着用户、项目、镜像元数据、虚拟网卡和卷信息。节点宕机后，服务可以重装，但这些数据库丢了，整个平台等于失忆。

我习惯每天做一次逻辑备份，用 mysqldump 导 SQL 文件，而不是直接拷贝数据目录。物理拷贝虽然快，但需要停库或使用文件系统快照，在控制节点上做不到不停机。逻辑备份命令如下：

# 循环备份五个核心库，密码由环境变量 MYSQL_PWD 提供 for db in keystone nova neutron cinder glance; do mysqldump --single-transaction --set-gtid-purged=OFF \ --databases "$db" > "/backup/$(date +%F)-${db}.sql" done

--single-transaction 参数保证备份期间不锁表，控制节点可以继续对外服务；--set-gtid-purged=OFF 是为了让 SQL 文件在任意 MySQL/MariaDB 实例上都能导入恢复，不会携带源库的 GTID 历史。

备份文件至少要保留 7 天，并复制到控制节点以外的位置。只备份在控制节点本地，节点磁盘故障时备份也会一起消失，这就失去了备份意义。

4.2 配置与密钥资产：别等 erlang cookie 丢了才后悔

OpenStack 各组件间的认证除了 Keystone 的 token，还有一堆本地密钥和配置：rabbitmq 的 erlang cookie、nova 的 /etc/nova/nova.conf、neutron 的 /etc/neutron/neutron.conf、Ceph 的 /etc/ceph/ceph.client.admin.keyring。

这些文件不占空间，但重建成本极高。erlang cookie 不一致会导致 rabbitmq 集群节点互相拒绝连接，而重新生成 cookie 需要重启整个消息队列，并重建所有镜像队列。Ceph 的 admin keyring 一旦丢失，ceph 命令都无法执行，只能通过 mon 节点手动恢复权限。

备份命令并不复杂：

# 打包所有关键配置文件，按日期归档 tar czf /backup/$(date +%F)-openstack-conf.tar.gz \ /etc/keystone /etc/glance /etc/nova /etc/neutron /etc/cinder \ /etc/ceph /var/lib/rabbitmq/.erlang.cookie

这包文件配合 4.1 的数据库备份，足以在一台全新的控制节点上把整个控制平面恢复回来。恢复顺序是先装好基础包，再解压配置，导入数据库，最后逐个启动服务。不要先把服务拉起来再改配置，那样会有很多互相等待的报错。

4.3 节点宕机后的恢复观察：先用 ceph -s 判断存储自愈状态

超融合环境里，计算节点宕机后，系统会自动把虚拟机调度到其他节点，但前提是底层存储状态健康。节点恢复开机后，不要急着起虚拟机，先在任意节点执行：

# 查看 Ceph 集群整体健康状态 ceph -s

关注输出里的 health 字段和 pgs 状态。正常情况 HEALTH_OK，如果有 PG 处于 peering 或 degraded，说明数据正在自愈，这时候创建的虚拟机盘可能会卡在等待状态。等所有 PG 回到 active+clean 再批量启动云主机才是可靠的做法。

这套观察方法也适用于控制节点重启后的场景。控制节点上的 mon 和 OSD 如果不在线，Ceph 集群多数情况下还能继续对外服务，但一旦超过一半 mon 失联，就会出现 quorum 丢失，所有读写都会被挂起。遇到这种情况，先检查三个 mon 进程是否都活着，再看端口 6789 和 3300 能不能互通，时间同步服务是否异常。

5. OpenStack 超融合最容易翻车的 5 个错误操作：现象、原因与解决

5.1 虚拟机制建失败，状态卡在 ERROR

现象：创建云主机后，状态一直是 ERROR，点进详情看不到任何 IP。

原因：最常见的是 nova-compute 无法连接 libvirt。要么是 CPU 虚拟化没开，要么是 /etc/libvirt/libvirtd.conf 的监听配置不对，也有可能是 qemu-system-x86 包没装。

解决：先在计算节点执行 virt-host-validate 看虚拟化是否就绪，然后检查 /var/log/nova/nova-compute.log 里是否有 “Cannot connect to libvirt” 字样。如果宿主机的 BIOS 里虚拟化功能没开，任何 OpenStack 配置都无法绕过，必须重启机器进 BIOS 开启 Intel VT 或 AMD SVM。

5.2 Ceph 的 PG 一直 peering，块存储不可用

现象：ceph -s 显示 HEALTH_WARN，大量 PG 状态是 peering 或 inactive，创建云主机时卷无法挂载。

原因：多数情况和网络抖动、时钟漂移有关。Ceph 对节点间时间偏差要求很严，偏差超过阈值，OSD 之间的心跳和日志会持续告警；另外防火墙只放开了管理网口，没有放行 6789/3300 端口也会导致 PG 无法完成 peering。

解决：在每台节点上配置 chrony 指向同一时间源，然后确认防火墙放行 Ceph 的端口。如果 PG 已经处于异常状态超过 10 分钟，可以考虑重启对应 OSD 进程，注意不要同时重启多个 OSD，防止集群长时间不可用。

5.3 控制节点重启后消息队列无法拉起

现象：控制节点断电重启后，rabbitmq-server 服务一直处于 activating 状态，DashBoard 登录报“503 Service Unavailable”。

原因：消息队列的数据目录和 erlang cookie 出现了不一致。如果是单控制节点，最常见的原因是 rabbitmq 未配置开机自启，或者数据目录在断电时写入不完整。

解决：先用 systemctl status rabbitmq-server 查看具体报错，如果确认是 cookie 不被识别，从备份里恢复 /var/lib/rabbitmq/.erlang.cookie，然后重启服务。这里提醒一点：平时不检查开机自启列表，到故障时才发现 rabbitmq 根本没有 enable，这属于管理盲区。

5.4 PackStack 中途失败后重复安装冲突

现象：PackStack 安装 neutron 时报错失败，清理后重跑，报“某个组件已存在”或者数据库表重复。

原因：PackStack 执行到一半时，已经创建了 neutron 数据库、装了一半的包，甚至已经写了一部分 /etc/neutron 配置，直接重跑会和现有残留冲突。

解决：不要盲目重跑。先用 packstack --answer-file 重新生成一份干净应答文件，把已经失败的组件相关的安装项关闭，等成功后再单独补装。或者干脆把相关组件的包卸载、清理 /var/lib/puppet 和对应数据库，再从头来一遍。这个过程我一般保留原始 log，按日志一条条核对，比反复试错快得多。

5.5 Dashboard 显示不出云主机列表，全是报错

现象：登录 Horizon 后，项目概览页无法显示实例列表，页面报 “Unable to retrieve instance list” 之类错误。

原因：Horizon 到 Nova API 的认证或 endpoint 地址出了问题。常见场景是控制节点 IP 发生过变更，keystone 里的 endpoint 还记录着旧地址，或者 nova-api 服务没起来。

解决：先在命令行执行 openstack endpoint list，对照 nova 的 endpoint 看 public/admin/internal 地址是否都指向当前控制节点 IP。如果地址不对，用 openstack endpoint set 修正；如果服务进程本身挂了，systemctl restart nova-api，再看 /var/log/nova/nova-api.log。

6. 验收超融合系统的自测方法：把冒烟测试做成一条命令

超融合系统交付时，最怕验收只停留在“能创建一台虚拟机”。我每次做完部署，都会用一组命令做冒烟测试，覆盖镜像、网络、卷、关键服务状态和开机自启，验证完再交接给业务部门。

# 来源环境变量后，依次验证 API、卷操作、关键服务状态 source /root/keystonerc_admin # 验证 keystone 认证链路 openstack service list >/dev/null && echo "keystone OK" # 验证 cinder 到 Ceph 的连通链路：建一块卷再删除 openstack volume create --size 1 smoke-vol sleep 5 openstack volume delete smoke-vol && echo "volume OK" # 检查控制节点关键服务是否在运行并已设置开机自启 systemctl is-active mariadb rabbitmq-server httpd systemctl is-enabled mariadb rabbitmq-server httpd >/dev/null && echo "auto-start OK"

这段脚本的逻辑是：service list 能返回数据，说明 keystone、数据库、API 层整个链条通；卷创建删除成功，说明 cinder 到 Ceph 的读写通路没问题；systemctl is-enabled 检查的是重启后服务能不能自己回来。

我早期吃过一个亏：当时只验证了“能建虚拟机”，没有验证“控制节点重启后服务自动拉起”。后来一次控制节点断电，机器起来后 nova-api 没启动，平台整个黑匣子一样没有任何提示，恢复时间被拉长到半天。从那以后，我的验收清单里永远会加一条重启测试，把三台节点依次重启，再执行一遍上面的冒烟脚本。超融合这种架构，服务编排链路很长，任何一个进程没起来，API 都会报错，但日志位置各不相同，排查成本很高。宁可把验证做细，也不要把问题留给夜里值班的同事。希望帮你提前把这些坑排掉。

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