陆拾贰號1. 新节点上线前的检查清单：这几项不确认，后面全白搭
先说个我自己的经历。去年年中给一套生产环境的 OpenStack 集群加计算节点，当时分区、网络都配好了，nova-compute 服务也起来了，openstack compute service list 一看状态也是 up，我觉得稳了，直接往里迁了几台业务虚拟机。结果第二天监控告警，新节点上的实例网络时通时不通，CPU 占用率也忽高忽低。排查了大半天，最后发现是 /etc/hosts 里新节点的主机名映射和 controller 节点不一致，消息队列里一堆解析超时。从那以后，我养成了一个习惯：加节点之前，先把能检查的项目全部过一遍再动手。
新计算节点要加入 OpenStack 集群，第一步不是装软件包，而是确认它和现有控制节点、网络节点之间的“共识”。这个共识包括四块：系统版本、网络规划、主机名解析、时间同步。
系统版本这块，我建议直接和现有计算节点保持一致。比如你现有节点是 CentOS Stream 9 + OpenStack 2024.1（Caracal），新节点就别搞成 Ubuntu 24.04 + 某个其他版本，否则后面排查问题的时候，命令、路径、日志格式全不一样，你会在两台机器之间来回跳，效率极低。我吃过这个亏，所以现在都要求新节点从模板机克隆，或者至少用同一套 kickstart 引导。
网络规划要重点看三张网：
- 管理网（管理 IP、消息队列、数据库访问走这里）
- 数据网/租户网（虚拟机实例的网卡桥接、VXLAN/GRE 隧道流量走这里）
- 存储网（如果用了 Ceph，块设备读写流量走这里）
新节点上这些网络的 IP、VLAN、网桥配置必须和控制节点能互通。特别是存储网，很多问题都出在这：ceph status 看着是 HEALTH_OK，但新节点上挂载 RBD 镜像的时候延迟特别高，甚至直接超时，多半就是存储网没连通或者 MTU 不对。我自己会先把 MTU 统一成 9000（如果交换机支持），然后每张网卡 ping -M do -s 8972 <网关> 测一遍，能通才算过。
主机名解析也容易踩坑。/etc/hosts 里必须把 controller、network、所有 compute 节点的 IP 和主机名写全，而且主机的 hostname 要和 /etc/hosts 里的完全一致。注意，OpenStack 里 nova-compute 上报的主机名是取自 socket.gethostname()，如果它和 /etc/hosts 不一致，会出现节点状态 up 但 hypervisor 列表里始终找不到这台机器的情况。
时间同步更不用说了，NTP 或 chrony 必须配好。Keystone token 的有效期是有限的，如果新节点的时间比 controller 快了 1 分钟，token 验证直接失败，你会看到“Auth system token validity failed”之类莫名其妙的报错。我一般会把新节点的时间偏差控制在 10ms 以内，用 chronyc sources -v 验证。
关于系统软件源，我有个建议：把 rpm 包和 pip 包缓存一份内网源，这样加节点的时候不用等外网下载，而且版本是固定的，不会出现“昨天能装、今天装不了”的依赖冲突。生产环境加节点，最怕的就是软件源不稳定，你装到一半，网络断了，rpm 事务中断，依赖关系一团糟。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 节点加入与注册：让 Nova 真正“认识”这台机器
新节点的系统准备做完之后，接下来才是 OpenStack 层面的接入。这一步分几个阶段，每个阶段都有对应的验证命令，别一上来就去创建虚拟机，先确认 Nova 真的把节点纳管了。
2.1 安装 Nova Compute 服务
节选几个关键的包，Ubuntu/Debian 系和 RHEL 系命令不一样，我以 RHEL/CentOS 系为例：
bash复制yum install -y openstack-nova-compute openstack-utils
如果新节点要承担 KVM 虚拟化，还要装：
bash复制yum install -y qemu-kvm libvirt-daemon libvirt-daemon-driver-qemu
装完之后，把 /etc/nova/nova.conf 里和现有计算节点对齐。最重要的几项：
[DEFAULT] transport_url：指向 RabbitMQ 的连接串，原来节点怎么写，这里就怎么写[keystone_authtoken]：对接 Keystone 的地址、用户名密码[neutron]：对接 Neutron 的地址、认证信息[libvirt] virt_type = kvm：如果用 QEMU 模拟，性能会差很多，建议确认 CPU 支持虚拟化
这里有一个非常容易忽略的地方：[vnc] 配置。现在很多环境都用 noVNC 做实例控制台，新节点上的 VNC proxy 地址要对，否则从 Horizon 打开“控制台”页签会白屏。常见配置是：
ini复制[vnc]
enabled = true
vncserver_listen = 0.0.0.0
vncserver_proxyclient_address = <新节点管理IP>
novncproxy_base_url = http://<controller-ip>:6080/vnc_auto.html
vncserver_proxyclient_address 这个参数填错了，实例启动成功但你连不上控制台。
2.2 注册节点到 Nova Cell
这一步是很多人容易漏掉的。Nova 从 Stein 版本开始引入了 cell v2 的概念，计算节点必须被发现并映射到 cell 里，调度器才能把实例调度到这台机器上。
如果你的环境是单 cell，可以手动执行：
bash复制su -s /bin/sh -c "nova-manage cell_v2 discover_hosts --verbose" nova
执行完能看到类似 Found 2 cell mappings. 的输出，其中应该包含新节点的 UUID。
如果环境是多 cell 或者 cell 注册有问题，手动指定 cell 映射：
bash复制nova-manage cell_v2 map_cell_and_hosts --name <cell_name> --transport-url rabbit://... --database_connection mysql+pymysql://nova:...
更好的做法是开启自动发现，在 controller 节点的 /etc/nova/nova.conf 里设置：
ini复制[scheduler]
discover_hosts_in_cells_interval = 60
这样每隔 60 秒 Nova 会自动扫描新加入的计算节点，省去手动执行的麻烦。生产环境我推荐这个方案，好处是以后再加节点不用每次手动 discover。
2.3 验证节点是否被正确识别
注册完成之后，按这个顺序跑一遍：
bash复制# 查看 nova-compute 服务的上报状态
openstack compute service list --service nova-compute
# 查看 hypervisor 资源统计
openstack hypervisor list
openstack hypervisor show <新节点hostname>
# 确认可用域
openstack aggregate list
正常状态下，新节点应该是 enabled + up，而且 hypervisor show 里面的 vcpus、memory_mb、local_gb 和你机器实际配置一致。
如果 compute service list 显示 down，别急，先检查三件事：
- 新节点到 RabbitMQ 的 5672 端口通不通
- 新节点到 Keystone 的 5000 端口通不通
/etc/nova/nova.conf里transport_url的密码是否正确
这些都是最基础的，但往往就是最基础的出问题。
提示：注册完成后，不要急着把旧节点上的云主机迁移过来。先在新节点上手动创建一个测试实例，确认基本功能正常，再做负载迁移和性能验证。
3. 基础功能验证：一台新节点能不能撑起业务，先跑通这些场景
节点注册完成、状态 up，这只是第一步。接下来要拿真实的场景去压它。基础功能验证要覆盖几个层面：实例创建与调度、网络连通性、存储挂载、迁移操作。
3.1 实例创建与调度验证：确认调度器真的会把负载发过去
从命令行创建一台小规格测试机：
bash复制openstack server create \
--image cirros-0.6.2 \
--flavor m1.tiny \
--network demo-net \
--availability-zone nova:<新节点hostname> \
--key-name mykey \
test-on-new-node
这里用 --availability-zone nova:<主机名> 强制把实例调度到新节点。加了这一条之后，调度器会优先选择这个可用域里的 compute 节点。如果创建成功，说明 nova-conductor、nova-scheduler、nova-compute 这条链路基本通了。
创建完看一眼：
bash复制openstack server show test-on-new-node
确认 OS-EXT-SRV-ATTR:host 确实是你新加的节点，status 是 ACTIVE。如果一直卡在 BUILD 状态，多半是调度失败或者镜像拉取失败。这时候去 controller 上看 nova-conductor 日志，去新节点上看 nova-compute 日志，一般是这两处才会有明确的错误。
3.2 网络连通性验证：实例起来不代表网络是通的
实例 ACTIVE 之后，网络这块必须测。我每次加完节点都会做个检查表，逐项打勾：
- 实例能拿到内网 IP（DHCP 正常）
- 从新节点所在网段的主机 ping 实例内网 IP，通不通
- 给实例绑定浮动 IP，从外部网络 ping 浮动 IP，通不通
- 实例访问外网（比如 ping 114.114.114.114），通不通
- 同一网络内两个实例互 ping，通不通
- 跨 VLAN/租户网络互 ping，通不通
这六项里只要有一项不通，先怀疑两处：
/etc/neutron/plugins/ml2/linuxbridge_agent.ini或openvswitch_agent.ini里的物理网卡映射是否正确（physical_interface_mappings）- 新节点上的网桥/OVS 是否已正常加入对应 bridge
拿 Linux bridge 方案举例，我经常在排查时执行：
bash复制ip link show
brctl show
确保 bridge_name（通常是 brqxxxx）确实绑定到了数据网物理网卡上，而不是只有一个孤零零的 bridge 接口。很多新节点加入后实例网络不通，都是因为 agent 配置里的网卡名和实际系统网卡名不一致，比如节点上实际是 enp3s0，配置里写的却是 eth0。
网络这块还有一个高发坑：安全组和 MTU。如果你的 overlay 网络用的是 VXLAN，物理网络 MTU 设置了 1500，那 VXLAN 报文的实际可用 MTU 只有 1450。新节点上实例的 MTU 如果不匹配，会出现大包 ping 不通、小包通的情况。拿 Cirros 镜像进控制台，ip link set dev eth0 mtu 1450 试一下，如果能通，就说明网络路径没问题，只是 MTU 协商问题。
3.3 迁移测试：热迁移能不能用，是衡量节点状态的重要标准
新节点建议做一次冷迁移和一次热迁移测试。冷迁移就是关机再迁，热迁移是保持实例运行状态迁移到其他节点。
bash复制# 冷迁移
openstack server migrate <instance-id> --live False
# 热迁移
openstack server migrate <instance-id> --live True
热迁移有一个前提条件：源节点和目标节点的 CPU 型号必须兼容。如果新旧节点 CPU 型号不一致（比如旧的是 Intel Xeon E5-2650，新的是 Intel Xeon Gold 6248），热迁移前需要确认 Nova 配置里 cpu_mode 是 host-model 还是 custom。我建议统一配置成 host-model，或者在新旧节点之间做一次 CPU 型号对齐，否则热迁移会直接失败，报错信息类似 “Target CPU does not support source CPU”。
热迁移还会涉及共享存储。如果实例的底层磁盘在本地而非共享存储上，热迁移会失败或者变成一个非常慢的“块迁移”。我建议在测试环境先跑一遍，观察迁移是否完成，以及迁移过程中的网络流量是否正常。
4. 性能基准测试：新节点能不能扛住生产负载，数据说话
功能通了，得看性能。生产环境不可能让一个性能有缺陷的节点直接上线，所以我每次加完节点都会跑一轮基准测试，把数据存下来，以后出问题可以对比。
4.1 CPU 和内存基准测试：用标准工具压出极限值
我常用 sysbench、stress、stream 这几个工具。安装方式很简单：
bash复制yum install -y sysbench stress
CPU 测试：
bash复制sysbench cpu --threads=16 --time=60 run
重点看 events per second，这个数字越高越好。同一个型号的节点，跑出来的数值应该接近。如果明显偏低，检查一下 CPU 频率是否是 performance 模式，以及是否被 BIOS 限频了。
内存测试：
bash复制sysbench memory --memory-block-size=1M --memory-total-size=10G --threads=16 run
同时用 stream 测内存实际带宽。注意，stream 的结果对编译器优化选项很敏感，你只需要跟旧节点同样的命令对比，看趋势，不要纠结绝对数值。
内存这块有个反直觉的点：不要满内存压。我一般压到总内存的 80%，因为 Linux 的页缓存会吃掉一部分内存，压满了容易触发 OOM，把宿主机的服务进程杀掉，那就不叫测试叫事故了。
4.2 磁盘性能测试：fio 的参数别乱用
磁盘测试必须用 fio，而且要模拟真实业务场景。我最常用的是这四种组合：
| 场景 | 读写模式 | 块大小 | 队列深度 | 关注指标 |
|---|---|---|---|---|
| 数据库随机写 | randwrite | 4K | 32 | IOPS、p99 延迟 |
| 日志顺序写 | write | 128K | 32 | 带宽 |
| 系统盘随机读 | randread | 4K | 32 | IOPS、平均延迟 |
| 大数据顺序读 | read | 1M | 16 | 带宽 |
举例：
bash复制fio --name=random-write \
--ioengine=libaio \
--rw=randwrite \
--bs=4k \
--size=4G \
--numjobs=4 \
--iodepth=32 \
--iodepth_batch=16 \
--iodepth_batch_complete=16 \
--runtime=60 \
--time_based \
--direct=1 \
--group_reporting \
/dev/sdb1
跑出来的结果重点看 slat（提交延迟）和 clat（完成延迟）的 p99 值。如果 p99 超过 20ms，说明这块盘的延迟抖动很大，不适合跑数据库类业务。
注意测试分区一定要选对。很多人一上来就 fio 整个 /dev/sda，在生产节点上跑这种测试很危险，可能把分区表、文件系统都写坏。我会单独划一块测试用的 LVM 卷或者临时分区，测完就删，不影响业务。
4.3 网络吞吐测试：iperf3 是最快最直接的结论
网络性能在新节点测试里特别容易被忽视。实例之间的东西向流量、计算节点到 Ceph 的存储流量，都对新节点的网卡吞吐有要求。
我一般会做两组测试：
- 裸机层面：两个计算节点之间直接跑 iperf3
- 虚拟化层面：两个跨节点的实例之间跑 iperf3
裸机测试：
bash复制# 新节点上启动服务端
iperf3 -s
# 旧节点或 controller 上发起测试
iperf3 -c <新节点IP> -t 60 -P 4
看 SUM 行的 Transfer 和 Bitrate，如果带宽远低于网卡标称值，考虑网卡 bonding 是否生效、断流中断是否被 RSS 均衡到了多个核、以及是否有网卡固件问题。10G 网卡实测只有 2Gbps，最常见的坑就是没开多队列，中断全部跑在 CPU0 上。
虚拟机层面的 iperf3 测试，要先把实例的安全组规则放开，否则 iperf 的端口被安全组拦掉。这一点经常有人踩坑，跑出来的结果以为是虚拟化开销太大，其实是安全组把 UDP 包给丢了。
4.4 稳定性测试：压 24 小时，看有没有悄悄挂掉的进程
短时间的基准测试能看出性能，看不出来稳定性。我习惯上新节点之后跑 24 小时的稳定性任务：
- 用
stress -c 16 -m 80%持续压 CPU 和内存 - 用
fio持续跑随机读写 - 用
ping -f持续打内网网关
每 10 分钟记录一次 CPU、内存、负载、网络丢包率。24 小时后看趋势图。如果出现以下情况，说明节点有问题：
- 内存使用率逐渐升高且不回弹（内存泄漏）
- 负载均值持续高于 CPU 核数（调度异常）
- ping 丢包率超过 0.1%（网络不稳定）
dmesg里出现 PCIe AER error 或 soft lockup
这些信息都是后续给硬件厂商报修、给系统调优的依据，测完一定要存档。
5. 常见问题与排查技巧实录
这部分是我最想写的。新节点接入 OpenStack 之后，翻车点实在太多了，我把这些年遇到的问题整理成一张速查表，再挑几个典型场景展开说。
| 现象 | 可能原因 | 快速排查命令 | 解决方案 |
|---|---|---|---|
| 计算节点状态 down | nova-compute 服务未启动 / 消息队列断开 | systemctl status openstack-nova-compute |
启动服务并检查 transport_url |
| 调度失败 no valid host | 节点资源不足 / 未 discover | openstack hypervisor show <host> |
修正资源超分比 / discover_hosts |
| 实例创建卡在 BUILD | 镜像上传失败 / 网络 agent 异常 | tail -f /var/log/nova/nova-compute.log |
检查镜像服务、neutron agent |
| 实例 IP 无法 ping 通 | 安全组 / MTU / 网桥配置错误 | ip link show brctl show |
调整安全组规则或 MTU |
| 热迁移失败 | CPU 型号不兼容 / 无共享存储 | openstack server migration list |
配置 cpu_mode=host-model / 挂共享存储 |
| keystone token 验证失败 | 时间不同步 | chronyc tracking |
配置 chrony 并同步时间 |
| fio 结果远低于预期 | 本地磁盘性能 / 文件系统 mount 参数 | cat /sys/block/sda/queue/scheduler |
调整 IO 调度器为 none 或 mq-deadline |
5.1 新节点状态 up 但 hypervisor 列表看不见
这个坑非常隐蔽。openstack compute service list 能看到 nova-compose up，但 openstack hypervisor list 里没有它。原因是 nova-scheduler 会周期性发现 host，但 cell v2 的映射可能没建立。
解法是去 controller 上手动执行：
bash复制su -s /bin/sh -c "nova-manage cell_v2 discover_hosts --verbose" nova
如果执行完还是不行，检查 /etc/nova/nova.conf 里的 [api_database] connection 是否和 controller 的数据库配置一致。我之前遇到过一个环境，新节点也配了数据库地址，但指向的是错误的 schema，导致 discover 的时候连不上库。
5.2 实例创建时提示 “No valid host was found”
这个问题分两层。第一层是真正的资源不足，调度器确实找不到满足 flavor 要求的节点。第二层是调度器没把新节点算进去。
我的排查顺序：
openstack hypervisor show <新节点>看 vcpus、memory_mb、free_disk_gb 还有没有剩余openstack flavor show m1.tiny看规格要求- 如果资源足够，检查
nova-scheduler日志，看get_hosts_by_cells的过滤结果
还有一个容易忽略的点：cpu_allocation_ratio 和 ram_allocation_ratio。如果新节点上这两个参数没设置，它会用控制节点上的默认值。控制节点默认 cpu_allocation_ratio=16.0，如果你生产环境的控制节点改成了 1.0，新节点没继承这个配置，调度器就会认为资源不足或者超分太多，导致调度结果不符合预期。
5.3 新节点的实例网络时通时不能通
这种问题最折磨人，因为不是完全不通，而是间歇性故障。我用过的绝招是分方向排查：
- 先从 controller 上连新节点的管理 IP，长时间 ping 观察丢包率
- 从 netns 里看 Neutron DHCP 命名空间的路由表：
ip netns exec qdhcp-xxxx ip route - 抓包对比：tcpdump 在实例虚拟网卡上抓，和物理网卡上抓，看到底是哪个环节丢了 ARP 请求
有一次我发现新节点的 ARP cache 一直在刷新，原因是它在同一张物理网卡上跑了 tenant 网络和 management 网络，两个 VLAN 的广播包互相干扰。后来把 tenant 网络单独拆到另一张物理网卡，问题消失。这块的背后逻辑是：如果一张网卡上既有管理 VLAN 又有 VXLAN 隧道，Linux bridge 的 FDB 学习和 ARP 泛洪会互相影响，特别是在流量大的时候表现特别明显。
5.4 性能测试结果与旧节点差距明显
不是因为新节点硬件不如旧节点，很多时候是配置问题。最容易让新节点性能掉坑的五个原因：
- CPU governor 是 powersave，不是 performance
- BIOS 里超线程被关掉了（HT 关掉后，超分能力下降，性能上限也受影响）
- NUMA 拓扑没感知，虚拟机的 vCPU 跨 NUMA node 访问内存，延迟翻倍
- 磁盘 IO 调度器用的还是
cfq，不是none或mq-deadline - 网卡没开多队列
排查顺序建议：
bash复制cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
lscpu | grep NUMA
cat /sys/block/sda/queue/scheduler
ethtool -l eth0
如果你发现 scaling_governor 是 powersave，立刻改成 performance：
bash复制cpupower frequency-set -g performance
这个改动很重要。我的经验是，同一台机器，从 powersave 切到 performance，sysbench CPU 事件数能涨 15-20%，这在生产环境是肉眼可见的差异。
6. 关于测试脚本的一点建议
每次加节点都手动敲命令太累了。我现在是把整个测试流程写成一个脚本，参数化传入新节点 IP 和型号，一键跑完，输出一份报告。脚本里包含：
- 基础环境检查（时间、主机名、网络连通性）
- nova service / hypervisor 状态检查
- 创建测试实例并检查调度位置
- 网络连通性检查（ping、SSH）
- sysbench CPU / 内存测试
- fio 磁盘测试
- iperf3 网络吞吐测试
跑完生成一个 /tmp/node-test-report-<hostname>.txt，里面包含所有测试数据和结论。这样以后任何一次“添加计算节点后测试”，都有统一的衡量标准，不会因为手动操作遗漏某项测试。
这个脚本的思路很简单：把需要手敲的命令按顺序组织起来，加 set -e，哪一步失败就停下来报错，方便定位问题。后台用 nohup 跑，把输出重定向到文件里，隔段时间来看结果就行。
新节点从加入到最终承载业务，完整走一遍这个流程，基本上能保证节点状态健康、资源充裕、性能达标、网络稳定。没有哪一步是多余的。经历过一次因为跳过某项测试而导致线上事故后，你会发现这份检查表和测试流程不是流程负担，而是安全感。