按下回车之后：SSH 分发 → Puppet 编排 → 三节点协同验证；多节点特有故障全收录 + 全系列复盘
一、部署概述
| 项目 | 值 |
|---|---|
| 拓扑 | controller 10.10.10.160 + compute1 .161 + compute2 .162 |
| 执行节点 | 仅 controller |
| 耗时 | 约 40~90 分钟 |
| 本篇目标 | 完成部署、验证"协同"、建立多节点排障思路，并给整个系列收尾 |
上篇回顾：（七）多节点部署：环境准备与应答文件------三台机器基础环境就绪、免密打通、应答文件三行关键配置检查完毕。
二、执行部署
bash
packstack --answer-file=/root/answers.txt这几十分钟里 Packstack 实际在做什么（理解流程，报错时才知道看哪）：
- SSH 分发：通过 SSH 连接三台机器（已配免密则全程无感），收集各节点信息
- 生成 manifest ：把应答文件翻译成 Puppet manifest，留档在
/var/tmp/packstack/ - 远程编排：在 controller 装全部控制面服务；在每台 compute 装 nova-compute、OVN agent 等角色服务
- 服务注册：各服务向 Keystone 注册端点、向数据库写入连接配置
全程刷屏（Puppet 的 notice 输出）属正常，只要最后一行出现 **** Installation completed successfully ****** 即成功 ，同时 controller 上生成 /root/keystonerc_admin。
失败重跑策略：
- packstack 支持续装，直接重跑同一命令即可
- 反复失败时，去
/var/tmp/packstack/找对应 manifest 和日志，按报错环节定位（是分发阶段失败还是某服务编排失败，处置完全不同） - 多次重跑会生成
answers.txt同目录的运行记录，可对比差异
三、部署后验证：确认"协同"而非"各自能跑"
多节点验证的核心思想只有一句话：单机验证证明"每个服务活着"，多节点验证要证明"跨机器的协作链路是通的"。
bash
|---|-------------------------------------|
| | source /root/keystonerc_admin |
| | openstack token issue # 基线：CLI 可用 |
3.1 计算节点全部注册（★标志性检查）
bash
openstack compute service list✔ 应该看到 ：nova-compute 有两行 ，分别对应 compute1、compute2，State 都是 up。
只有一行？说明有一台 compute 没注册成功------去那台机器看
systemctl status openstack-nova-compute。
3.2 网络 agent 全部存活
bash
openstack network agent list✔ 应该看到：controller 上的 OVN 相关 agent 正常，各节点条目 Alive=True。
3.3 起两台实例，验证调度分布（★本篇最有说服力的验证）
bash
|---|-------------------------------------------------------------------------------------|
| | openstack server create --flavor m1.tiny --image cirros --network public test-vm |
| | openstack server create --flavor m1.tiny --image cirros --network public test-vm2 |
| | |
| | openstack server list -c Name -c Status -c 'Host' |
✔ 应该看到 ：两台实例的 Host 分别落在 compute1 / compute2 上。
**这是多节点部署成功的标志性现象：Nova 调度器能够跨机器分配负载。**两台实例挤在同一节点，多半意味着另一台的 nova-compute 注册或通信有问题（回看 3.1）。
3.4 实例"真活三连"（老规矩，系列坑 1）
bash
|---|----------------------------------------------------------|
| | openstack console log show test-vm | head # 有内核引导输出 |
| | # 到实例所在的那台 compute 节点上： |
| | virsh dominfo <实例域名> | grep 'CPU time' # CPU time 持续增长 |
| | ping <浮动IP> # 安全组放行 icmp 后可连通 |
多节点下多了一个易错点：要登录到实例实际所在的那台 compute 节点去看 virsh，在 controller 上当然看不到 compute 上的实例。
3.5 跑健康检查脚本收尾
bash
bash os-health.sh # 第（六）篇脚本，在 controller 上直接复用四、多节点特有故障速查（全收录）
| 现象 | 排查方向 | 常见根因 |
|---|---|---|
| packstack 报 SSH 连不上某节点 | 逐台 ping + ssh 试 |
hosts 没配、root 密码错、没配免密、NetworkManager 抢管网卡 |
| 部署报 Keystone/MQ 连接超时 | 三台 chronyc sources、getenforce |
时间不同步（第一名）、防火墙/SELinux 没关干净 |
| nova-compute 显示 down | 去对应 compute 节点看服务与日志 | 时间漂移、hosts 解析错、rabbitmq/keystone 连接失败 |
| 实例 ACTIVE 但连不上 | openstack image show 看 size |
★273 字节 302 镜像坑（第（五）篇）；或无 /dev/kvm 引导极慢 |
| 实例都挤在一台 compute | compute service list 看另一台 |
该节点服务注册失败或与 MQ 断连 |
| NetworkManager 装完又起来 | systemctl is-enabled NetworkManager |
忘记 disable，间歇性抢占造成"时好时坏"的通信故障 |
**排障心法与单机完全一致：先看服务在不在 → 再看日志报什么 → 再查配置/时间/权限 → 最后查依赖（DB / MQ / Keystone）。**多节点只是把"一个服务"变成了"N 台机器上的 N 份服务"，第一动作永远是先定位"是哪台机器的问题"，再按单机方法深入。
五、多节点之后的进阶路线（完结不算终点）
走完本系列，你已经具备了继续深入的基础，几个自然的下一步：
| 方向 | 内容 | 前置条件 |
|---|---|---|
| 接入真实监控 | 用 Prometheus + node_exporter 监控三台节点，Grafana 出面板 | 本系列第（六）篇的巡检思路是雏形 |
| 换 Kolla-Ansible 重新部署 | 同样拓扑容器化实现，体验生产级工具 | 三台机器配 Docker |
| 对接 Ceph 存储 | Cinder/Swift/Glance 后端换成统一 Ceph 集群 | 磁盘资源充裕 |
| 开启 KVM 加速 | 宿主机开 VT-x，对比实例引导速度 | VMware/物理机 BIOS 支持 |
| 编排实验 | 开启 Heat，用模板一键创建整套环境 | 多节点稳定运行 |
建议顺序：先监控（让系统透明），再容器化部署（让部署规范），再存储（让数据沉淀）------每一步都建立在前一步的稳定性之上。
六、常见问答（FAQ）
Q1：能不能用一台 4G 内存的机器跟着做？
可以装（会慢），但实例一跑起来内存就紧张。建议控制节点 8G 起步，计算节点 4G 起步。
Q2：为什么不直接用官方文档手动部署？
手动部署一套 Train 需要 200+ 配置文件，学习价值高但排错成本巨大。Packstack 生成的配置文件本身就是官方推荐写法（它底层就是官方 Puppet 模块），可以边用 Packstack 边对照 /etc 下的配置文件学习。
Q3：实例引导要多久算正常？
有 KVM：cirros 几秒到 1 分钟；无 KVM（本系列）：1~3 分钟。超过 5 分钟没内核输出基本可断定是镜像问题。
Q4：多节点能只用两台机器吗？
能，controller 兼网络节点 + 1 台 compute，本系列第（七）篇拓扑去掉一台即可。
Q5：生产环境能照抄本系列吗？
不能。本系列是体验环境：防火墙全关、SELinux 宽容、组件单点、无备份。生产请用 Kolla-Ansible + 高可用拓扑 + 正式安全策略。
七、全系列复盘（完结总结）
| 篇 | 主题 | 关键收获 |
|---|---|---|
| （一） | 入门概览与选型 | 组件分工与调用链；学习用 Packstack、生产用 Kolla-Ansible |
| （二） | 单机环境准备 | 六块地基 + 6 个坑伏笔；CentOS 7 EOL 的内网源方案 |
| （三） | 一键部署与验证 | 应答文件是 Packstack 的全部秘密；nohup 丢后台；10 步验证清单 |
| （四） | 创建第一台云主机 | 网络→实例→浮动 IP 全链路；provider/租户网络分工；CLI↔Dashboard 对照 |
| （五） | 故障排查实录 | ★273 字节镜像坑；size 是镜像第一指标；通用排查起手式 |
| （六） | 运维脚本 | os-health.sh + 九大项巡检；巡检是排障经验的固化 |
| （七） | 多节点准备 | 三行应答配置决定拓扑；时间一致性是故障率第一名 |
| （八） | 多节点执行与排障 | 调度分布验证；先定位"哪台机器"再深入 |
回顾整个系列，反复出现、值得带走的思想只有两条：
**第一，"状态好看"不代表真的健康。**ACTIVE、active、up、enabled 这些账面状态都可能是假的，唯一的真相是行为证据：console.log 里有没有内核输出、CPU time 有没有在涨、IP 能不能连通。这条原则在第（五）篇的 273 字节坑里救过我们一次，在第（八）篇验证调度时又用了一次。
**第二，环境一致性是分布式部署的生命线。**时间、主机名解析、yum 源、防火墙策略------单机时它们只影响自己，多机时任何一处不一致都会以最诡异的报错形式爆发。所以多节点部署 80% 的工作量在"让三台机器步调一致"，部署命令本身只占 20%。
这两条经验不止属于 OpenStack------把它们带到 Kolla-Ansible、Kubernetes 或任何分布式系统的部署里，同样适用。
全系列完。感谢追更，欢迎在评论区交流你踩到的坑。