从 All-in-One 到 1 控 2 计：角色拆分不难，难的是让三台机器“步调一致”——时间、解析、网络、源，一样都不能各自为政
一、部署概述
| 项目 | 值 |
|---|---|
| 目标拓扑 | 1 台 controller + 2 台 compute |
| controller | 10.10.10.160（同时承担网络节点角色，建议 ≥ 8G 内存 / 50G 磁盘） |
| compute1 / compute2 | 10.10.10.161 / 10.10.10.162（建议 ≥ 4G 内存） |
| 系统 | CentOS 7.9.2009（Train 必须 CentOS 7；Ussuri 起用 CentOS 8） |
| 内网 yum | http://10.10.10.10/centos/7.9.2009/ |
| 耗时 | 约 40~90 分钟 |
上篇回顾：（六）运维脚本：健康检查与巡检——单机环境已运维熟练，本篇开始扩展拓扑。
先说结论打消顾虑：**多节点和单机用的是同一个 Packstack，区别只是把应答文件里三个角色的 Host 写成三台不同的机器。**真正的工作量在部署之前——让三台机器的“地基”完全一致。单机手册里的所有坑在多节点全部适用，且新增三类问题：节点间通信、时间一致性、SSH 分发。
二、拓扑与角色划分
图表代码
部署后：多节点
controller 10.10.10.160
Keystone/Glance/Nova调度/Neutron/OVN/br-ex
compute1 10.10.10.161
nova-compute
compute2 10.10.10.162
nova-compute
部署前：单机 All-in-One
10.10.10.160
controller+compute+network+storage
| 角色 | 职责 | 本例所在机器 |
|---|---|---|
| controller | 全部控制面服务 + 数据库 + MQ + 认证 | 10.10.10.160 |
| network | OVN 北向/南向、外部网桥 br-ex | 10.10.10.160（与 controller 同机） |
| compute | 跑实例 | 10.10.10.161 / .162 |
| storage | Cinder 卷 | 10.10.10.160（体验环境从简） |
把 network 单独放一台就是经典“三角色”拓扑（控制/计算/网络各司其职），实验环境没必要，同机即可。
三、基础环境（【每一台】节点都执行）
3.1 主机名与 hosts（三台内容完全一样）
bash
hostnamectl set-hostname controller # 10.10.10.160 上 |
hostnamectl set-hostname compute1 # 10.10.10.161 上 |
hostnamectl set-hostname compute2 # 10.10.10.162 上 |
cat >> /etc/hosts <<'EOF' |
10.10.10.160 controller |
10.10.10.161 compute1 |
10.10.10.162 compute2 |
EOF |
应该看到：任意一台机器
ping controller、ping compute1、ping compute2都通。
单机时 hosts 写错只是 Keystone 端点解析失败；多节点时，控制面组件之间全靠主机名互相找对方，hosts 不通则部署必失败——且报错位置分散在各个服务的连接阶段，比单机难定位得多。务必逐台验证。
3.2 关防火墙 + SELinux + NetworkManager
bash
systemctl stop firewalld && systemctl disable firewalld |
setenforce 0 |
sed -i 's/^SELINUX=.*/SELINUX=permissive/' /etc/selinux/config |
# ★ 多节点比单机更容易中招：NetworkManager 和 network 服务打架 |
systemctl stop NetworkManager && systemctl disable NetworkManager |
systemctl restart network |
应该看到：
systemctl is-active network输出 active，三台机器 IP 都没丢。
为什么 NetworkManager 在多节点更危险：controller 上的 OVN、br-ex 网桥对网卡的接管状态非常敏感，NetworkManager 偶发抢管网卡，会造成间歇性的节点间通信故障——时好时坏的问题最难排查，所以必须 disable 而不只是 stop。
3.3 时间同步：三台指向同一个源
bash
yum install -y chrony |
# /etc/chrony.conf 中所有 server 行统一改为： |
# server 10.10.10.10 iburst |
systemctl restart chronyd && systemctl enable chronyd |
chronyc sources |
date |
应该看到：三台机器都出现
^*同步源，且date输出一致（秒级内）。
时间一致性是多节点部署的故障率第一名。单机时时间漂了只影响自己；多节点时 controller 签发的 Token 要被 compute 上的服务消费，compute 时钟落后就会把“新 Token”判为“未生效/已过期”，表现是 compute 服务反复掉线、日志里一片 401。三台机器必须指向同一个NTP 源（而不是各自上网同步）。
3.4 yum 源与 packstack（每一台都要装）
bash
# yum 源配置与单机相同（第（二）篇第 1.4 节整段复制），三台都做 |
yum install -y centos-release-openstack-train |
yum install -y openstack-packstack |
rpm -q openstack-packstack |
应该看到：每台机器都有
openstack-packstack-15.1.0...输出。
★ 常见误区：以为只有 controller 需要 packstack。Packstack 部署时会 SSH 到每台机器执行安装，compute 节点同样要能解析 OpenStack 软件包。
四、SSH 免密（controller → 各 compute）
bash
ssh-keygen -t rsa -N "" -f ~/.ssh/id_rsa |
ssh-copy-id root@10.10.10.161 |
ssh-copy-id root@10.10.10.162 |
应该看到：
ssh root@10.10.10.161 hostname不输密码直接返回 compute1。
不配免密也行——部署过程中 Packstack 会逐台要求输入 root 密码——但配免密有两个好处：部署无需人守；失败重跑时不会被密码提示打断节奏。顺手验证一下方向反了行不行（有些操作会从 compute 回连）：
bash
ssh root@10.10.10.161 "ssh root@controller hostname" # 能返回 controller 即双向 OK五、应答文件（【仅 controller】执行）
5.1 生成与修改
bash
packstack --gen-answer-file=/root/answers.txt |
# ★ 核心就三行：把角色分给不同的机器 |
sed -i 's/^CONFIG_CONTROLLER_HOST=.*/CONFIG_CONTROLLER_HOST=10.10.10.160/' /root/answers.txt |
sed -i 's/^CONFIG_COMPUTE_HOSTS=.*/CONFIG_COMPUTE_HOSTS=10.10.10.161,10.10.10.162/' /root/answers.txt |
sed -i 's/^CONFIG_NETWORK_HOSTS=.*/CONFIG_NETWORK_HOSTS=10.10.10.160/' /root/answers.txt |
# 常用附加项 |
sed -i 's/^CONFIG_KEYSTONE_ADMIN_PW=.*/CONFIG_KEYSTONE_ADMIN_PW=Admin@123/' /root/answers.txt |
sed -i 's/^CONFIG_NTP_SERVERS=.*/CONFIG_NTP_SERVERS=10.10.10.10/' /root/answers.txt |
sed -i 's/^CONFIG_PROVISION_IMAGE_URL=.*/CONFIG_PROVISION_IMAGE_URL=<不会302的镜像URL>/' /root/answers.txt |
# 组件取舍与单机一致（第（三）篇 4.2 节），可选组件建议同样关掉 |
5.2 三个关键参数的含义
| 参数 | 说明 | 本例 |
|---|---|---|
| CONFIG_CONTROLLER_HOST | 控制节点 IP，单个 | 10.10.10.160 |
| CONFIG_COMPUTE_HOSTS | 计算节点 IP，逗号分隔多台；以后扩容改这行补跑一次即可 | 10.10.10.161,10.10.10.162 |
| CONFIG_NETWORK_HOSTS | 网络节点 IP；与 controller 同机为简配，单独一台即经典三角色 | 10.10.10.160 |
与单机对照（第（三）篇 4.1 节）：单机是四行 Host 全指向本机；多节点只是把 COMPUTE 从“本机”改成了“两台外部机器”。部署工具没有变，变的只有拓扑描述。
5.3 镜像 URL 特别提醒
CONFIG_PROVISION_IMAGE_URL必须指向不会 302 重定向的地址——单机踩过的 273 字节坑（第（五）篇），在多节点会以同样的方式复现，而且两台 compute 都可能“种下”坏镜像，排查工作量翻倍。内网没有镜像源就把该行留默认，装完手动上传真实镜像。
五点五、深一层：外部网关 br-ex 是怎么工作的
多节点拓扑中，controller（兼网络节点）上有一个特殊设备 br-ex，浮动 IP 能从外网访问到实例，全靠它：
text
外网物理交换机 |
│ |
ens33（物理网卡，无 IP 或仅管理 IP） |
│ |
br-ex（OVS 网桥，外部网关 172.24.4.1 挂在这里） |
│ |
router1 的外网接口 → DNAT/SNAT → 租户网络 |
几个关键点：
- 物理网卡与 br-ex 的关系：packstack 部署时会自动把物理网卡桥接进 br-ex。如果部署后浮动 IP 从外部 ping 不通，第一件事就是
ovs-vsctl show查 br-ex 下有没有挂物理网卡 - 外部网段与物理网一致性问题：flat 网络的 172.24.4.0/24 要么是真实可达的网段，要么需要在测试机上加路由；从外部测浮动 IP 时，你的电脑必须能路由到这个网段
- 多节点下的变化：单机时 br-ex 和实例在同一台机器，一切天然可达；多节点时实例分布在 compute 上，浮动 IP 流量要跨机器回 controller 的 br-ex，geneve 隧道（6081/udp）承载这段流量——这也是第（二）篇强调放行 6081 的原因
验证 br-ex 状态的命令集：
bash
ovs-vsctl show # 网桥与物理网卡挂接关系 |
ip addr show br-ex # 外部网关 172.24.4.1 是否挂上 |
ovs-ofctl dump-flows br-ex | head # 流表（进阶） |
实测经验：多节点排障时，“浮动 IP 不通”的问题链是 安全组 → 路由器网关 → br-ex 挂接 → 隧道连通性，从上往下查，九成在前两步就解决了。
六、用脚本把「三台一致」自动化（可选进阶）
逐台手敲 8 条命令容易漏，把基础环境写成一键脚本，scp 到每台执行：
bash
#!/bin/bash |
# node-init.sh —— 多节点基础环境一键初始化（在各节点以 root 执行） |
# 用法：./node-init.sh <角色：controller|compute1|compute2> |
ROLE=$1 |
hostnamectl set-hostname $ROLE |
cat >> /etc/hosts <<'EOF' |
10.10.10.160 controller |
10.10.10.161 compute1 |
10.10.10.162 compute2 |
EOF |
systemctl stop firewalld && systemctl disable firewalld |
setenforce 0 |
sed -i 's/^SELINUX=.*/SELINUX=permissive/' /etc/selinux/config |
systemctl stop NetworkManager && systemctl disable NetworkManager |
systemctl restart network |
sed -i 's/^server.*/server 10.10.10.10 iburst/' /etc/chrony.conf |
systemctl restart chronyd && systemctl enable chronyd |
yum install -y centos-release-openstack-train openstack-packstack |
rpm -q openstack-packstack && echo "=== $ROLE 初始化完成 ===" |
bash
# 在 controller 上分发并执行 |
for h in 10.10.10.160 10.10.10.161 10.10.10.162; do |
scp node-init.sh root@$h:/root/ |
done |
**脚本化的额外收益：三台机器的配置天然一致，不会出现“A 台关了防火墙、B 台忘了”这类隐蔽差异——这正是多节点故障的第一大源头。**注意 yum 源配置（第（二）篇 1.4 节的 local.repo）需要提前放入镜像模板或单独分发。
七、从 2 台到 N 台：扩容思路
Packstack 的多节点拓扑是声明式的，扩容非常直接：
- 新机按 node-init.sh 初始化
- 改应答文件：
CONFIG_COMPUTE_HOSTS=161,162,163（追加新 IP） - 重新执行
packstack --answer-file=answers.txt（支持续装，已有节点不受影响） - 验证：
openstack compute service list出现新节点且 up
反过来，下线一台 compute：先迁移实例（openstack server migrate），再从 COMPUTE_HOSTS 去掉 IP 重跑。生产环境更规范的做法是用 Kolla-Ansible 的 inventory 管理，但学习阶段用 Packstack 完全够。
八、执行前检查清单（最后一道关）
bash
# 1) 三行 Host 与规划一致 |
grep -E '^CONFIG_(CONTROLLER|COMPUTE|NETWORK)_HOSTS?' /root/answers.txt |
# 2) 三台机器互 ping 通、时间一致、packstack 就位 |
ssh root@10.10.10.161 'hostname && chronyc sources | head -3 && rpm -q openstack-packstack' |
ssh root@10.10.10.162 'hostname && chronyc sources | head -3 && rpm -q openstack-packstack' |
# 3) 双向免密 OK |
ssh root@10.10.10.161 "ssh root@controller hostname" |
应该看到：三行 IP 与拓扑一致；两台 compute 主机名、时间源、packstack 版本全部正确。
这份清单看似重复劳动，实际是性价比最高的一次投入：多节点部署中途失败后重跑一次就是几十分钟，而这份检查 3 分钟就能跑完。
下篇预告：（八）多节点部署执行、验证与排障——按下回车后发生了什么，以及怎么用“实例分布在不同 compute 节点”这个标志性现象确认协同成功。完结篇见。
