CrazyBoy Mr先说一句题外话：标题里的 opensrack 我按 OpenStack 来理解，应该是集群内部代号或者输入时的笔误。无论是新买裸机还是把旧物理机重装加入控制平面，扩容计算节点都是比较高频的操作，但很多团队的做法是节点起来、注册 up 就算完事，这其实是把"服务在线"和"业务可用"混为一谈了。
我最近就做了一次 OpenStack 集群扩容，往现有环境里加了一台新的计算节点，节点加入后我做了一整轮专项测试。这篇文章把测试方法、验证顺序、判定标准和我踩过的坑完整记录下来，给同样在维护 OpenStack 的运维和架构师一个可以直接拿去用的参考。
1. 计算节点入池后，这三条链路必须先过一遍
1.1 这次扩容的实际场景
环境里原有的计算节点跑了挺长时间，CPU 和内存使用率已经偏高，加上最近有批新业务要上线，我这边申请到了一台新的物理服务器。服务器的硬件是双路 CPU、512GB 内存、两块 1.6TB NVMe 固态硬盘，系统装的是 CentOS Stream 9 的兼容发行版，OpenStack 版本是 Yoga 之后的新版本，网络采用 VXLAN 的 neutron 架构，存储通过 Cinder 接了一个独立存储集群。
把 nova-compute、neutron 相关的 agent 装好，配置文件按已有节点的模板改完 hostname 和 IP，重启服务之后，openstack compute service list 里确实能看到新节点状态是 up，很多人做到这一步就觉得扩容完成了。但实际上，计算节点成功注册只代表控制平面"看见"了它，后续的虚拟机调度、网络连通、存储挂载、迁移恢复，这些才是真正决定业务能不能用的环节。
1.2 我理解的"计算节点测试"到底要覆盖什么
节点加入后的测试，不是简单开机、建一台虚拟机。我的习惯是把测试拆成三条链路：
第一条是管理链路，也就是控制节点到新计算节点的 API 通信。nova-compute 上报心跳、neutron agent 与控制节点通信、RabbitMQ 消息队列是否通畅，这些出问题的时候节点会显示 up 但实际调度不过去，现象非常隐蔽。
第二条是资源链路，就是新节点的 CPU、内存、磁盘、虚拟化能力是否真的可以被调度器使用。很多节点注册不上或者虚拟机起不来，问题都卡在 /dev/kvm 没有权限、BIOS 没开虚拟化、CPU 型号不兼容这些地方。
第三条是业务链路，就是虚拟机在新节点上起来之后，网络能不能通、安全组规则是否生效、云硬盘能不能挂载、能不能做迁移。这一条涉及 nova、neutron、cinder 三个组件的协同，最容易暴露出配置差异。
这篇测试记录就按照这三条链路展开，后面每一步对应的检查命令和预期结果我都会写出来。
1.3 执行测试前，先确认新节点的基础信息
在开始动手之前，我先把下面的信息列成一张表，后续所有测试都要以这张表为准：
| 检查项 | 内容 |
|---|---|
| 新节点主机名 | compute-node-04 |
| 管理网 IP | 10.10.20.24 |
| VXLAN 隧道 IP | 10.10.30.24 |
| nova-compute 服务版本 | 与现有节点一致 |
| RabbitMQ 访问凭据 | 独立配置文件，不沿用其他节点 |
| 物理 CPU 型号 | Intel Xeon Gold 6338 |
把主机名和 IP 确认好之后，一定还要确认新节点的 /etc/hosts 已经把控制节点、网络节点、存储节点的所有主机名解析配好。这个点经常被忽略，如果 hosts 文件解析不全，后面 rabbitmq 连接、nova-conductor 回调都会出现莫名奇妙的超时。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 前置自检项：网络、时间、消息队列，一个都不能少
2.1 先测网络连通性，别急着 openstack service list
管理网络不通的话，后续所有测试都没有意义，所以我把网络验证放在了第一步。在控制节点上先 ping 新节点的管理 IP，再把 VXLAN 隧道 IP 也 ping 一遍。需要注意，VXLAN 流量是有封装开销的，默认 MTU 1500 的物理网络里，隧道内层可用 MTU 大约是 1450，所以我会用下面的命令测大包：
bash复制# 从控制节点发起，测试到新节点管理 IP 的大包连通性
ping -M do -s 1472 -c 5 10.10.20.24
# 从网络节点发起，测试到新节点 VXLAN 隧道 IP
ping -M do -s 1450 -c 5 10.10.30.24
为什么要卡这个包大小？如果物理交换机端口 MTU 配置不对，小包能通，大包不通，虚拟机创建出来后网络会时断时续。-M do 表示不允许分片，如果新节点网卡或者交换机不支持巨型帧，这里的 ping 就会直接报错，可以第一时间发现物理网络层面的隐患。
在控制节点、网络节点、新计算节点三者之间互相测完 ICMP 之后，我还会用 iperf3 做一次简单的带宽打流，确认不是"能通但速度极慢"的状态。新节点管理网带宽通常要求万兆，如果 iperf3 测出来的吞吐只有几百 Mb/s，说明网卡协商速率或者 bond 模式有问题，需要先处理再继续。
2.2 NTP 时间同步是很多人会漏掉的一环
时间不同步对 OpenStack 的影响其实非常大。nova-compute 上报状态、实例的 task_state 切换、keystone token 校验、RabbitMQ 的消息确认，这些都对时间敏感。我在新加节点时见过最典型的一个问题是：所有服务状态都正常，但创建虚拟机的请求发到新节点后一直处于 BUILD 状态，最后超时失败，排查了大半天才发现是节点时间比控制节点快了两分钟。
检查时间同步的命令很简单：
bash复制# 在新计算节点上执行
chronyc tracking
chronyc sources -v
主要看两个指标：一是系统时间是否已经同步到 NTP 服务器；二是时钟偏移量，正常情况下应该在几十毫秒以内。我用的是三层架构里专门的 NTP 服务器，如果环境中没有独立 NTP 服务器，至少要让所有节点都指向控制节点。还有个容易踩的细节：修改时区或者手动调整时间之后，要重启一下 rabbitmq 相关服务和 nova-compute，否则客户端连接还保留着旧的时钟状态。
如果你在检查时发现新节点时间慢了几分钟，建议直接：
bash复制# 强制同步一次时钟
chronyc makestep
# 确认同步结果
date
时间同步做完之后还要检查一下 timedatectl status，确认时区跟其他节点一致。时区不一致虽然不会阻断服务运行，但排查日志的时候时间对不上会非常痛苦。
2.3 服务注册状态要区分"up"和"enabled"
很多人用 openstack compute service list 看到新节点状态是 up 就认为没问题，但完整判断标准应该是两点：State 是 up，Status 是 enabled。如果 Status 是 disabled，调度器会直接跳过这个节点，即使服务活着也不会创建虚拟机。
bash复制openstack compute service list --host compute-node-04
输出应该类似下面这样：
bash复制+----+----------------+----------------+------+---------+-------+----------------------------+
| ID | Binary | Host | Zone | Status | State | Updated At |
+----+----------------+----------------+------+---------+-------+----------------------------+
| 21 | nova-compute | compute-node-04| nova | enabled | up | 2025-06-10T14:02:23.000000 |
| 22 | nova-conductor | controller | nova | enabled | up | 2025-06-10T14:02:25.000000 |
+----+----------------+----------------+------+---------+-------+----------------------------+
如果发现新节点的 nova-compute 状态不是 up，我的排查顺序是：先看 journalctl -u openstack-nova-compute 有没有报错，再确认 /etc/nova/nova.conf 里的 transport_url 能不能正常连接 RabbitMQ，然后在控制节点上单独测试 rabbitmqctl list_connections 有没有来自新节点的连接。
这里有一个我踩过坑的地方：nova-compute 配置文件拷贝自旧节点，如果忘记修改 host 参数，新节点会以旧节点的 hostname 注册到 nova 数据库，然后出现两个计算节点抢同一个 hostname 的诡异问题。/etc/nova/nova.conf 中的 host 必须显式写成新节点自己的主机名，不能依赖系统的 hostname 自动推断。检查方法很简单：
bash复制openstack host list
如果看到两个计算节点具有相同的 Host 名称，赶紧停掉新节点的 nova-compute 服务，把配置文件里的 host 改好再启动。
2.4 RabbitMQ、数据库连接和防火墙的连带检查
在测服务注册状态的同时，我会顺手验证 RabbitMQ 和数据库连通性。RabbitMQ 是 nova、neutron 各组件之间通信的枢纽，如果新节点无法连接 RabbitMQ，最直接的现象是服务起不来或者反复重启。检查命令：
bash复制# 在控制节点的 rabbitmq 节点上查看是否有来自新节点的连接
rabbitmqctl list_connections name peer_host state
正常情况下能看到新节点 IP 对应的连接，状态是 running。数据库连接的话，nova-compute 本身没有太多直接数据库操作，但 nova-api、nova-conductor 会查数据库里有没有这个 host 的记录。可以先简单验证一下 MySQL 是否能从新节点连过去：
bash复制# 从新计算节点测试数据库 3306 端口连通性
nc -vz 10.10.10.5 3306
如果 nc 不通，看看是不是防火墙没有放行。很多公司内部网络为了安全会做节点间的访问控制，扩容完新节点之后经常漏掉数据库和消息队列对应的 ACK 策略，导致服务起不来或者状态异常。这里提醒一句，如果环境用的是 firewalld，要确认 openstack-nova-compute 和 neutron 相关的端口都已经加入白名单；如果是 iptables，建议跟现有节点导出规则做一次 diff。
3. 硬件虚拟化与 CPU 兼容性检查：新节点到底有没有"办业务"的能力
3.1 虚化能力检查：/dev/kvm 必须可写
计算节点的核心职责是跑虚拟机，如果硬件虚拟化没有开启或者 KVM 设备不可用，nova-compute 即便注册成功，也无法正常创建虚拟机。检查方式很直接：
bash复制# 在计算节点上执行
ls -l /dev/kvm
正常情况下应该看到 crw-rw---- 1 root kvm 10, 232 ... /dev/kvm。如果 /dev/kvm 不存在，大概率是 BIOS 里的 VT-x/AMD-V 没有开启。这时候不用继续往下测了，先把物理机重启进 BIOS 打开虚拟化再回来。
接下来确认当前内核是否加载了 KVM 模块：
bash复制lsmod | grep kvm
正常输出会包含 kvm_intel 或 kvm_amd。如果模块没加载，检查一下 modprobe kvm_intel 是否能执行成功，以及 CPU 是否支持相关特性：
bash复制egrep -c '(vmx|svm)' /proc/cpuinfo
这个数字如果大于 0，说明 CPU 带有虚拟化指令集。还有一个容易被忽略的点：nova-compute 进程跑在容器或虚拟化环境里的时候，需要确认 /dev/kvm 是否被正确映射进容器。不是所有 OpenStack 部署都是裸机跑服务，Kolla 这类容器化部署方式对设备映射的要求更严格。
3.2 CPU 型号一致性决定了后续能不能热迁移
新节点加进来之后，如果后续规划里有热迁移需求，必须在测试前确认新节点和现有节点的 CPU 型号是否一致，或者 nova 是否配置了 CPU 模式归一化。先看当前 CPU：
bash复制# 在计算节点执行
lscpu | grep "Model name"
我这次加的节点是 Intel Xeon Gold 6338，而现有节点是 Xeon Silver 4310，两者都属于 Ice Lake 架构，型号不一致但仍然兼容。如果你的现有节点是老的 Broadwell，新节点是 Ice Lake，不做配置直接加入池子，普通创建没问题，但热迁移会出现虚拟机无法启动的严重问题。
解决办法是在 /etc/nova/nova.conf 的 libvirt 段配置统一的 cpu_mode：
ini复制[libvirt]
cpu_mode = host-model
cpu_models = CascadeLake-Server, IceLake-Server
host-model 模式让 libvirt 从源宿主机读取 CPU 特性，迁移到目标宿主机时会做兼容过滤。如果两个节点 CPU 差异太大，就需要用 cpu_mode = custom 并锁定一个较老的基础 CPU 模型，缺点是性能会受一些影响。在测试阶段，我会用下面的命令在不同节点上分别读取 CPU 能力:
bash复制virsh capabilities | grep -A 5 "<model>"
然后对比模型名是否一致，或者能否落到对方的能力子集里。做这一步的目的，是为了避免过段时间业务方提热迁移需求的时候才发现 CPU 不兼容，那时再调整配置就要影响现有节点，成本和风险完全不同。
3.3 新节点如果是 GPU 机器，透传配置该怎么验证
现在很多 OpenStack 集群都会带 GPU 节点跑 AI 推理或渲染任务，我这次验的新节点虽然没有 GPU，但我把相关的检查方法也写在这里，供实际场景参考。带 GPU 的计算节点加入后，首先用 lspci 确认设备是否被宿主机识别：
bash复制lspci | grep -i nvidia
如果能看到 GPU 设备但 nova 里无法创建带 GPU 的虚拟机，多半是 /etc/nova/nova.conf 中 PCI 透传白名单没有配置。常见的配置内容是：
ini复制[pci]
passthrough_whitelist = { "address": "0000:17:00.0" }
alias = { "name": "gpu-a100", "device_type": "type-PCI", "vendor_id": "10de" }
配置完需要重启 nova-compute，然后在控制节点上验证：
bash复制openstack hypervisor show compute-node-04
看返回的 pci_stats 字段里有没有对应的 GPU 设备。没有出现的话，用 nova-manage pci list 检查一下 nova 是否成功扫描到 PCI 设备。GPU 透传的测试通常建议直接创建一台 flavor 里定义了 pci_passthrough:alias 的虚拟机来做，单纯依赖服务列表不可靠，因为 nova-scheduler 对 PCI 资源请求的处理是在调度阶段完成的，很多问题只有真正发起创建才会暴露。
4. 用一台带亲和性的虚拟机验证调度与实例生命周期
4.1 把虚拟机"钉"在新节点上，排除调度器变量
前置链路都通了之后，接下来要验证的就是虚拟机能不能真正落到新节点上运行。为了不让 nova-scheduler 把虚拟机随机调度到其他节点干扰判断，我会先把虚拟机指定到新节点：
bash复制# 确认镜像
openstack image list
# 确认网络
openstack network list
# 直接指定 host 创建测试虚拟机
openstack server create \
--flavor m1.small \
--image cirros-0.6.2 \
--nic net-id=private-net \
--availability-zone nova:compute-node-04 \
test-on-compute04
--availability-zone nova:compute-node-04 是 OpenStack 里的指定主机写法，意思是在 nova 这个 AZ 下面强制选择 compute-node-04。只有当你确实想验证新节点调度能力时才建议这么做，业务虚拟机不要轻易指定主机，否则会破坏调度器的均衡逻辑。
创建完成后，用下面的命令确认虚拟机实际所在位置：
bash复制openstack server show test-on-compute04 \
-c id -c status -c "OS-EXT-SRV-ATTR:host" -c addresses
输出里 OS-EXT-SRV-ATTR:host 字段应该是 compute-node-04，status 是 ACTIVE。如果看到状态长时间停留在 BUILD，马上看新节点上的 nova-compute 日志：
bash复制tail -f /var/log/nova/nova-compute.log
常见的问题包括镜像格式不支持、CPU 特性与配置不符、磁盘不够、nova-compute 权限不对等等。我不建议直接在 dashboard 上反复点创建按钮来测试，应该用命令行工具，并把 uuid 记下来，方便后续对应日志排查。
4.2 虚拟化层同步验证：virsh list 必须能看到实例进程
OpenStack 层显示 ACTIVE 还不够，我还会跑到新节点的宿主机上确认 KVM 层面确实跑起了对应的虚拟机：
bash复制# 在计算节点执行
virsh list --all
正常情况下能看到一个名字形如 instance-0000xxxx 的虚拟域，状态是 running。如果 OpenStack 显示 ACTIVE 但 virsh 里看不到对应实例，说明 nova-compute 的状态上报与实际 libvirt 驱动不一致，这属于比较严重的数据不一致问题，需要立即处理。
另外还要确认实例的 vCPU、内存分配是否符合预期：
bash复制virsh vcpucount instance-0000xxxx
virsh dominfo instance-0000xxxx
对比 flavor 定义里的 vCPU 数量和内存大小。我遇到过新节点的宿主机内存被其他进程占满、虚拟机虽然创建成功但内存被 overcommit 到 swap 的情况，只在 nova 层看很难发现，必须到宿主机上核验。
4.3 生命周期操作也要走一遍，不能只测"建出来"
实例成功创建之后，我还会把生命周期里常用的几个操作逐个验证一遍。首先是冷重启：
bash复制openstack server reboot test-on-compute04
等待实例状态变为 ACTIVE。然后是硬重启（强制断电再启动）：
bash复制openstack server reboot --hard test-on-compute04
接着验证 rebuild（重建镜像）和快照：
bash复制# 创建快照
openstack server image create --name test-snapshot test-on-compute04
# 重建（恢复原镜像）
openstack server rebuild --image cirros-0.6.2 test-on-compute04
这些操作看起来基础，但每操作一步，新节点的 nova-compute 都要与 glance、cinder、neutron 做一次完整的交互，任何一个组件配置不匹配都会在这里暴露。经历过一次扩容后，我强烈建议大家把这些"看起来没用"的生命周期操作走完再交付。而且测试完不要忘记清理资源，测试虚拟机、快照、云硬盘都要删掉，避免占用资源还产生计费。
4.4 resize 和迁移测试：先做冷迁移，再判断要不要测热迁移
实例生命周期里有一项最容易推迟到"以后再说"的就是迁移，但我是建议扩容后至少做一次迁移验证。如果新节点与旧节点之间 CPU 兼容性已经确认过，可以做一次热迁移
bash复制openstack server live-migrate --host compute-node-04 test-on-compute04
但热迁移需要满足很多前提条件：共享存储或镜像后端支持块迁移、neutron 端口绑定模式匹配、CPU 特性兼容、nova 配置里 allow_resize_to_same_host 等参数合理。我这次前几步测试的时候先做的是冷迁移，因为冷迁移对存储的要求低，可以更早验证 nova 的调度和网络 plug 流程是否在新节点上正常工作：
bash复制openstack server migrate test-on-compute04
等待迁移完成之后，确认实例已经在目标节点上 ACTIVE。这个结果说明了 nova-conductor、nova-scheduler、nova-compute 三者之间的协调是正常的。如果冷迁移通过而热迁移不通过，问题多半集中在 CPU 兼容、网络 agent 或其他运行时资源层面，可以再单独排查。
5. 网络与存储联调：VM 起来了不代表扩容成功
5.1 二层网络和安全组规则验证
有些扩容测试做到虚拟机起来了就算结束，但实际上虚拟机网络都不通的情况很常见。这里的关键是：nova-compute 上的 neutron agent 是否正常，以及 VXLAN 网络能否在新节点上正常建立。
在控制节点上先确认网络 agent 的状态：
bash复制openstack network agent list
新节点上应该有一个 neutron-openvswitch-agent 的状态是 :-) 表示 alive，XXX 表示挂掉。如果 agent 没起来，看日志：
bash复制journalctl -u neutron-openvswitch-agent -f
我在实际扩容的时候遇到过新节点的 Open vSwitch 网桥没有自动创建成功，导致虚拟机创建后网卡处于 down 状态。这种问题的排查可以先检查 Open vSwitch 的网桥：
bash复制ovs-vsctl show
然后在创建的测试虚拟机里执行 ip addr，查看有没有拿到私网 IP。如果没拿到 IP，检查 DHCP 服务是否正常工作。最好用 cirros 镜像测试，因为它启动快、尺寸小，排查问题很方便。
安全组测试也不能跳过。如果新节点被加入到一个新的 AZ 或项目里，默认安全组可能没有放行 ICMP 和 SSH，结果虚拟机通了二层网络但业务访问过去，会以为是网络故障。验证方式是在控制节点上给安全组加一条放行规则，然后从外部 ping 测试虚拟机的私网 IP:
bash复制openstack security group rule create \
--protocol icmp --ingress default
5.2 浮动 IP 和外部访问链路验证
私网通了之后，还要验证浮动 IP。这块最容易暴露问题的地方是 neutron 路由命名空间和 iptables 规则是否在新节点上真正生效。步骤是：
bash复制# 创建一个浮动 IP
openstack floating ip create public-net
# 绑定到测试虚拟机
openstack server add floating ip test-on-compute04 203.0.113.10
之后从外部网络去 ping 这个浮动 IP。如果 ping 不通，我通常按下面的顺序排查：
- 先查 neutron 路由器的 namespace 里有没有对应浮动 IP 的 NAT 规则；
- 再查新节点上的安全组规则是不是拦掉了入站流量；
- 最后查物理网络交换机对浮动 IP 网段的路由是否正常工作。
这一步操作的时候值得注意：测试完成之后要把浮动 IP 释放掉，不要一直占用公网地址池。
5.3 云硬盘挂载验证：cinder 到 nova 再到实例内部
最后是存储链路。新建一个云硬盘并挂载到测试虚拟机，验证新计算节点对共享存储的访问没有问题：
bash复制# 创建云硬盘
openstack volume create --size 1 test-vol
# 挂载到测试实例
openstack server add volume test-on-compute04 test-vol
# 在实例里查看块设备
openstack console log show test-on-compute04
在实例内部执行 lsblk，如果能看到一个 1G 的新磁盘，说明 cinder-volume 通过存储网络把卷暴露给了 nova-compute，并且 libvirt 成功把磁盘作为 virtio 设备挂载给了虚拟机。再执行：
bash复制sudo mkfs.ext4 /dev/vdb
sudo mount /dev/vdb /mnt
格式化并挂载都成功的话，存储链路基本没有问题。如果 lsblk 里看不到设备，排查方向是先确认新节点到存储后端的 iSCSI 或 FC 链路是否通，再看 nova-compute 有没有权限访问存储。
我见过一个比较隐蔽的问题：新节点的 nova-compute 所在的物理机到存储网络的 MTU 不一致，导致云硬盘挂载过程中出现间歇性 IO 错误，虚拟机偶尔能起来偶尔起不来。这种问题常出现在用了不同供应商网卡的新服务器上，务必检查网卡的 MTU 与存储交换机是否匹配。
6. 并发创建和故障注入测试：把新节点当"新员工"试用一阵子
6.1 用并发创建脚本测试调度器与新节点的承载能力
基础功能验证通过后，下一步就是模拟真实业务负载。我不会手动一台一台去点创建，而是用一个简单的 for 循环批量创建虚拟机：
bash复制for i in $(seq 1 20); do
openstack server create \
--flavor m1.small \
--image cirros-0.6.2 \
--nic net-id=private-net \
load-test-$i &
done
wait
这个命令会并发发出 20 个创建请求，测试 nova-scheduler 在收到批量请求时能不能把负载合理地分配到新节点上。命令执行后观察：
- 是否所有虚拟机都进入 ACTIVE 状态？
- 有多少台实际落在新节点？
- 新节点上有没有出现 CPU 或磁盘 IO 的严重瓶颈？
如果环境中还有监控系统，我会直接打开新节点的 CPU、内存、磁盘 IO 监控曲线，看有没有明显打满的尖峰。nova-scheduler 默认是随机或者按权重调度，如果新节点的权重配置较高，可能会承担更多实例，这是正常的。如果你希望在新节点刚上线时先少承担业务，可以在 nova.conf 里调低权重：
ini复制[DEFAULT]
cpu_allocation_ratio = 16.0
ram_allocation_ratio = 1.5
这两个参数控制着 nova 认为物理节点可以超配的 CPU 和内存比例。如果新节点的配置比旧节点强，相对超配比例可以适当调大，但别一次调太高，避免超配过猛导致虚拟机性能问题。
6.2 模拟新节点故障：强制停止 nova-compute 的行为验证
接下来这一步是很多运维都不敢做但恰恰最有价值的：故障注入。我会分两个场景来模拟故障。
第一个场景是停掉 nova-compute 服务：
bash复制# 模拟 nova-compute 进程崩溃
systemctl stop openstack-nova-compute
稍等片刻，在控制节点上执行：
bash复制openstack compute service list --host compute-node-04
你会看到新节点的 State 从 up 变成 down。这个结果说明控制平面能及时发现节点失联。然后重启服务，确认状态恢复：
bash复制systemctl start openstack-nova-compute
此时新节点上的虚拟机应该不会受到影响，因为虚拟机进程是 libvirt 在管理的，nova-compute 挂掉不影响已经运行的虚拟机。但如果你在停服务期间尝试创建新的虚拟机，调度器会直接跳过这个节点，这也是预期行为。
第二个场景是直接模拟宿主机崩溃，这个操作比较危险，需要提前确定节点上没有重要业务或已经做过迁移。我会在物理机控制台上执行：
bash复制# 模拟突然断电或内核崩溃，谨慎操作
echo c > /proc/sysrq-trigger
这种破坏性测试做完之后，如果配置了 nova 的自动疏散机制，控制节点会自动把该节点上的实例在其他健康节点上重建。没有配置的话，你可能会看到实例状态变成 ERROR 或者 SHUTOFF，然后需要手动执行疏散：
bash复制openstack server evacuate --host compute-node-01 test-on-compute04
故障注入测试的目的不是找麻烦，而是确认你的集群在真实故障发生时有足够的手段恢复。如果没有做这块测试，平时也不会知道新节点的自动疏散、状态检测配置是否生效，到真的出故障那天再去查文档，代价就大了。
6.3 验证结束后清理测试资源，防止残留影响业务
测试完成后，需要把创建出来的所有测试资源清理干净。按照依赖关系的顺序删除：先删除挂载的卷，再删除浮动 IP，然后删除虚拟机，最后删除云硬盘和快照。
bash复制# 删浮动 IP
openstack server remove floating ip test-on-compute04 203.0.113.10
openstack floating ip delete 203.0.113.10
# 卸载并删除卷
openstack server remove volume test-on-compute04 test-vol
openstack volume delete test-vol
# 删除虚拟机
openstack server delete load-test-1 load-test-2 load-test-3
清理完之后，再用 openstack server list --all-projects 检查一遍确认没有遗漏。我这次就遇到过测试虚拟机没删干净，结果新节点上线才三天，磁盘就被测试镜像撑爆。别让测试阶段的垃圾数据影响生产环境的资源水位。
7. 实测中我踩过的坑和给你的最后建议
7.1 坑一：nova-compute 注册 up 了，但跑的还是旧配置
这是我这次扩容中遇到最隐蔽的问题。因为新计算节点是从模板机克隆出来的，配置文件里除了 IP 之外基本都一样。我启动服务之后，openstack compute service list 看到的节点状态确实是 up，但随后创建虚拟机一直失败。后来看日志发现，nova-compute 默认以 /etc/nova/nova.conf 里的 host 字段作为标识注册，而克隆机上的 host 字段依然沿用了模板机的名字，导致节点实际上以模板机的身份注册，数据混乱。
解决办法就是必须在启动 nova-compute 之前，在配置文件里显式指定 host = compute-node-04。如果你的环境里用了 hostname 自动推断，也要确认系统的 /etc/hostname 已经改掉。启动后再次用 openstack host list 确认没有重复的 host 名再继续。
7.2 坑二：VXLAN 隧道测试的 MTU 参数被忽略
在验证网络连通性时，如果只测 1500 字节的普通 ping，很多 MTU 问题根本测不出来。我这次是从控制节点到新节点测试大包时才发现交换机端口没有放行巨型帧，导致流量虽然通了但吞吐量极低。所以我把这一步的位置放得很靠前，建议大家在节点正式上线前务必执行一次带 -M do 的大包 ping。
还有一个相关的小细节：/etc/neutron/plugins/ml2/ml2_conf.ini 里的本地 IP 应该设置成新节点的隧道 IP，而不是管理 IP，否则 VXLAN 流量会走向错误的网段。检查命令：
bash复制grep "^local_ip" /etc/neutron/plugins/ml2/ml2_conf.ini
7.3 坑三：测试阶段过于依赖 dashboard，忽略了命令行
dashboard 在排查问题时信息量非常有限，尤其是看不到实例具体落在哪台宿主机、看不到 nova-compute 的日志。整个扩容测试过程，我超过九成的操作是在命令行完成的。命令行不仅能精确地查看每个组件的状态，还能把所有的 API 请求结果格式化输出，方便后续做对比。建议运维同学把本文涉及的核心 openstack 命令整理成一个脚本，下次再扩容节点时直接复用，能省很多时间。
真正验证完这一整套流程之后，新节点才算是真正具备承接业务流量的能力。扩容测试这活儿没有太多高深的技术，核心是把每一条链路都当成可能出问题的环节去验证，不要想当然，也不要只看表面状态。后面如果再扩容，我也会继续按这个思路走一遍，直到把所有新节点都测试到和现有节点同等水平为止。