企业官网建设流程全解析

1. 为什么要动网络插件这块蛋糕

OpenStack Ussuri 版本部署完之后，默认走的是 LinuxBridge + VLAN 这套组合拳。这套方案稳定、简单、上手快，很多中小规模集群跑个一两年都不会出什么大问题。但只要你集群规模往上走，或者业务对网络隔离、多租户、跨节点通信有更高要求的时候，LinuxBridge 的短板就会一个接一个冒出来。最典型的就是 VLAN 数量受限于 4094 个，而且二层网络在大规模场景下广播风暴的风险会明显上升。这时候把底层网络从 LinuxBridge 换成 OpenVSwitch，再叠加 VXLAN 做隧道封装，基本就是一条绕不开的路。

我这次操作的背景是一个已经跑起来的 Ussuri 集群，CentOS 8 系统，控制节点和计算节点分开部署，原来用的是 LinuxBridge + VLAN 模式。业务已经在上面跑了，所以不能推倒重来，只能做在线改造。这个改造的难点不在于 OpenVSwitch 本身有多复杂，而在于怎么让已有的实例网络在切换过程中尽量少受影响，以及怎么保证 Neutron 的配置和底层 OVS 的桥接关系完全对齐。一旦对不齐，就会出现实例能拿到 IP 但 ping 不通网关，或者跨节点通信直接断掉的情况。

这篇文章适合两类人看：一类是正在规划 OpenStack 网络方案，想搞清楚 LinuxBridge 和 OVS 到底该怎么选的架构同学；另一类是已经踩在坑里，需要一份可复现的改造步骤的运维同学。我会把整个改造过程拆成设计思路、核心原理、实操步骤、问题排查四个部分，尽量把每个参数背后的逻辑讲清楚，让你不只是照抄命令，而是知道为什么这么改。

需要提前说明的是，这次改造涉及控制节点和计算节点两边的 Neutron 配置、OVS 网桥创建、物理网卡挂载、VXLAN 隧道建立等多个环节，任何一个环节出错都可能导致网络中断。所以我在每个关键步骤都会标注注意事项，建议你在测试环境先完整走一遍再上生产。

2. 改造前的整体设计与方案选型

2.1 LinuxBridge 和 OpenVSwitch 的核心差异

很多人觉得这两个都是虚拟交换机，功能差不多，随便用哪个都行。实际上它们在设计哲学上有本质区别。LinuxBridge 是内核原生的二层桥接设备，配置简单，和 iptables、ebtables 配合得很自然，但它本质上就是一个二层转发设备，没有流表、没有隧道封装能力、没有细粒度的流控。OpenVSwitch 则是一个完整的虚拟交换机实现，支持 OpenFlow 流表、支持 VXLAN/GRE/Geneve 隧道封装、支持 QoS、支持端口镜像，功能上完全是另一个量级。

从 Neutron 的角度看，LinuxBridge 模式下每个网络对应一个 Linux Bridge，VLAN 标签直接打在物理网卡的子接口上。而 OVS 模式下，Neutron 会通过 OVS agent 在 br-int 上做 VLAN 转换，再通过 br-tun 做隧道封装，最后通过 br-ex 或者 br-eth 对接物理网络。这个多层桥接结构看起来复杂，但它带来的好处是网络隔离更彻底、隧道通信更灵活、后续扩展性更强。

具体到这次改造，我选择 OVS + VXLAN 而不是 OVS + VLAN，主要考虑三点：第一，VXLAN 的 VNI 有 1600 万个，远超 VLAN 的 4094 个，多租户场景下不用再担心 ID 不够用；第二，VXLAN 是三层网络上的二层隧道，跨网段通信不需要物理网络支持 Trunk，对底层网络设备的要求更低；第三，后续如果要接 SDN 控制器或者做网络功能虚拟化，OVS 的流表机制更容易对接。

2.2 改造范围与影响面评估

这次改造涉及的角色有三个：控制节点、计算节点、网络节点。在 Ussuri 的典型部署里，网络节点可能和控制节点合并，也可能独立部署。我这次的环境是控制节点和网络节点合并，计算节点独立。改造的核心动作包括：

• 在所有节点上安装 OpenVSwitch 相关软件包
• 修改 Neutron 的 ML2 配置，把 mechanism_drivers 从 linuxbridge 改成 openvswitch
• 修改 OVS agent 配置，指定隧道类型为 vxlan，配置本地隧道 IP
• 在计算节点上创建 br-int、br-tun、br-ex 等网桥，并把物理网卡挂到对应网桥上
• 清理原有的 LinuxBridge 配置和 VLAN 子接口
• 重启 Neutron 相关服务，验证网络连通性

影响面方面，改造期间所有实例的网络会短暂中断，具体中断时长取决于你的操作速度和环境复杂度。如果实例有浮动 IP 或者对外提供服务，建议在业务低峰期操作，并提前通知相关方。另外，如果集群里有多个计算节点，建议逐个节点改造，不要一次性全改，这样即使出问题也能快速定位是哪个节点的问题。

2.3 改造前的备份与回滚方案

这一步很多人会跳过，但我强烈建议你认真做。改造前需要备份的内容包括：

• /etc/neutron/目录下的所有配置文件
• /etc/sysconfig/network-scripts/下的网卡配置文件
• 数据库中的 Neutron 相关表（至少备份 networks、subnets、ports、agents 这几张表）
• 当前 OVS 或者 LinuxBridge 的状态信息，比如ovs-vsctl show、brctl show、ip link show的输出

回滚方案的核心思路是：如果改造失败，能够快速恢复到 LinuxBridge 模式。具体做法是保留一份原始的 Neutron 配置文件，在需要回滚时替换回去，然后重启 Neutron 服务，再清理掉 OVS 创建的网桥和端口。需要注意的是，如果已经有实例在 OVS 模式下创建了新的端口，回滚后这些端口可能需要手动清理，否则会残留脏数据。

提示：备份数据库时建议使用mysqldump导出为 SQL 文件，不要只做物理文件拷贝，因为 MySQL 在运行状态下直接拷贝数据文件可能导致数据不一致。

3. 核心组件原理与配置细节拆解

3.1 OpenVSwitch 网桥结构详解

OVS 在 OpenStack 环境中通常涉及三个核心网桥：br-int、br-tun、br-ex。br-int 是集成网桥，所有实例的虚拟网卡都挂在这个网桥上，它负责 VLAN 标签的本地转换和端口隔离。br-tun 是隧道网桥，负责 VXLAN 隧道的建立和拆除，跨节点的流量都从这里走。br-ex 是外部网桥，负责对接物理网络，浮动 IP 和外部访问都经过这个网桥。

这三个网桥之间的关系是这样的：实例发出的流量先到 br-int，br-int 根据流表把流量打上内部 VLAN 标签，然后转发到 br-tun。br-tun 根据目的地址查流表，找到对应的 VXLAN 隧道，把原始二层帧封装成 VXLAN 包，通过物理网卡发出去。对端节点收到 VXLAN 包后，br-tun 解封装，再通过 br-int 转发到目标实例。如果是访问外部网络，流量会从 br-int 转到 br-ex，再由 br-ex 通过物理网卡发出去。

理解这个结构很重要，因为后面配置的时候，你需要知道每个网桥该挂什么、该配什么。比如 br-tun 上需要配置本地隧道 IP，br-ex 上需要挂物理网卡，br-int 上不需要配 IP 地址。这些细节如果搞错了，网络肯定不通。

3.2 VXLAN 隧道通信原理与参数选择

VXLAN 的核心思想是把二层帧封装在三层 UDP 包里传输。每个 VXLAN 网络有一个 24 位的 VNI 标识，理论上支持 1600 万个网络。VXLAN 的封装格式是在原始以太网帧前面加上 VXLAN 头、UDP 头、IP 头和新的以太网头。对端收到后逐层解封装，还原出原始二层帧。

在 OpenStack 环境中，VXLAN 的隧道端点就是各个计算节点的 br-tun 上的本地 IP。这个 IP 通常选管理网或者专门的一张隧道网卡。我这次用的是管理网 IP，因为环境里没有单独的隧道网。需要注意的是，隧道 IP 必须互通，而且 MTU 要调整。因为 VXLAN 封装会增加 50 字节的开销（外层以太网头 14 字节 + IP 头 20 字节 + UDP 头 8 字节 + VXLAN 头 8 字节），所以如果物理网卡 MTU 是 1500，那么实例网卡的 MTU 应该设为 1450，否则大包会被分片或者丢弃。

MTU 这个问题在实际操作中非常容易踩坑。表现就是小包能通，大包不通，ping 小包正常，但 SSH 登录卡顿或者 HTTP 请求超时。排查的时候可以用ping -M do -s 1472来测试，1472 加上 28 字节的 IP 和 ICMP 头正好是 1500。如果这个命令不通，就说明 MTU 有问题。

3.3 Neutron ML2 与 OVS Agent 配置项解析

Neutron 的 ML2 插件通过 mechanism_drivers 来决定使用哪种底层网络技术。从 LinuxBridge 切到 OVS，核心就是把这个参数从linuxbridge改成openvswitch。同时，tenant_network_types也要从vlan改成vxlan，或者保留vlan,vxlan让两者共存。

OVS agent 的配置文件里，有几个参数必须配对：

• tunnel_types = vxlan：指定隧道类型
• local_ip = <隧道IP>：指定本地隧道端点 IP
• bridge_mappings = physnet1:br-ex：把物理网络名称映射到 OVS 网桥
• enable_tunneling = True：启用隧道功能

这些参数如果配错，OVS agent 启动时会报错，或者启动后无法建立隧道。比如local_ip如果填了一个不可达的地址，br-tun 上的隧道端口就建不起来，跨节点通信直接挂掉。

另外，/etc/neutron/plugins/ml2/openvswitch_agent.ini这个文件在 Ussuri 里是 OVS agent 的主配置文件，而/etc/neutron/plugins/ml2/ml2_conf.ini是 ML2 插件的配置。两个文件都要改，缺一不可。

4. 完整实操流程与关键步骤

4.1 环境准备与软件包安装

先在所有节点上确认系统版本和当前网络模式。执行cat /etc/centos-release确认是 CentOS 8，执行neutron agent-list确认当前用的是 LinuxBridge agent。然后安装 OpenVSwitch 相关包：

dnf install -y openvswitch openvswitch-ovn-common python3-openvswitch

安装完成后启动 OVS 服务并设置开机自启：

systemctl enable --now openvswitch systemctl status openvswitch

这里有个细节要注意：CentOS 8 的 OVS 版本默认是 2.13 左右，这个版本对 VXLAN 的支持已经很完善了，不需要额外编译。但如果你用的是更老的系统，可能需要升级 OVS 到 2.11 以上才能稳定支持 VXLAN。

安装完 OVS 后，先不要急着改 Neutron 配置，先用ovs-vsctl show看一下当前 OVS 的状态。如果是全新安装，应该只有一个空的数据库，没有任何网桥。如果有残留配置，建议先清理干净。

4.2 控制节点 Neutron 配置修改

控制节点的修改主要集中在 ML2 配置和 OVS agent 配置。先编辑/etc/neutron/plugins/ml2/ml2_conf.ini：

[ml2] type_drivers = flat,vlan,vxlan tenant_network_types = vxlan mechanism_drivers = openvswitch,l2population extension_drivers = port_security

这里我把tenant_network_types设成了vxlan，意味着新建的租户网络默认走 VXLAN。如果你想让 VLAN 和 VXLAN 共存，可以写成vlan,vxlan，但要注意 VLAN 的物理网络映射也要配好。

然后编辑/etc/neutron/plugins/ml2/openvswitch_agent.ini：

[ovs] tunnel_type = vxlan local_ip = 10.0.0.10 bridge_mappings = physnet1:br-ex [agent] tunnel_types = vxlan l2_population = True enable_distributed_routing = False

local_ip这里填的是控制节点的管理网 IP，实际环境中要换成你自己的。bridge_mappings里的physnet1要和 Neutron 里创建的物理网络名称一致，br-ex是后面要创建的 OVS 网桥。

改完配置后，重启 Neutron 服务：

systemctl restart neutron-server systemctl restart neutron-openvswitch-agent

重启后查看 agent 状态，确认 OVS agent 已经注册并且是 up 状态：

neutron agent-list

如果 OVS agent 显示为 down，大概率是配置文件有问题，可以查看/var/log/neutron/openvswitch-agent.log定位具体错误。

4.3 计算节点 OVS 网桥创建与物理网卡挂载

计算节点的操作是整个改造中最关键也最容易出错的部分。先创建三个核心网桥：

ovs-vsctl add-br br-int ovs-vsctl add-br br-tun ovs-vsctl add-br br-ex

然后配置 br-tun 的本地隧道 IP。这里不需要给 br-tun 配 IP 地址，而是通过 OVS 的local_ip参数让 agent 自动处理。但需要确保 br-tun 上有一个端口能到达隧道网络。通常的做法是把管理网网卡挂到 br-tun 上，或者创建一个内部端口：

ovs-vsctl add-port br-tun vxlan0 -- set interface vxlan0 type=vxlan options:local_ip=10.0.0.11 options:remote_ip=flow options:key=flow

不过在实际操作中，更推荐让 Neutron OVS agent 自动管理隧道端口，手动创建容易和 agent 的流表冲突。所以这一步可以跳过，等 agent 启动后会自动创建。

接下来处理物理网卡。假设计算节点的物理网卡是ens192，原来在 LinuxBridge 模式下可能挂了 br-ex 或者直接配了 IP。改造时需要把ens192从原来的桥里摘出来，挂到 br-ex 上：

ovs-vsctl add-port br-ex ens192

然后把ens192的 IP 地址转移到 br-ex 上。这一步要特别小心，因为一旦转移，SSH 可能会断。建议在控制台或者带外管理口操作。具体做法是编辑/etc/sysconfig/network-scripts/ifcfg-ens192，把 IP 配置删掉，改成：

DEVICE=ens192 TYPE=Ethernet BOOTPROTO=none ONBOOT=yes

然后创建/etc/sysconfig/network-scripts/ifcfg-br-ex：

DEVICE=br-ex TYPE=OVSBridge DEVICETYPE=ovs BOOTPROTO=static IPADDR=10.0.0.11 NETMASK=255.255.255.0 GATEWAY=10.0.0.1 ONBOOT=yes

重启网络服务：

systemctl restart network

注意：CentOS 8 默认使用 NetworkManager，如果 network 服务不生效，需要用nmcli来配置。建议提前确认系统的网络管理方式，避免配置不生效。

4.4 清理 LinuxBridge 残留配置

OVS 配置完成后，需要把原来的 LinuxBridge 配置清理掉，否则会冲突。先查看当前的 LinuxBridge：

brctl show

如果看到brq开头的网桥，说明还有 LinuxBridge 残留。删除这些网桥：

brctl delbr brqXXXXXX

同时删除 VLAN 子接口：

ip link delete ens192.100

然后修改 Neutron 的 LinuxBridge agent 配置，把 agent 停掉：

systemctl stop neutron-linuxbridge-agent systemctl disable neutron-linuxbridge-agent

在控制节点上删除 LinuxBridge agent：

openstack network agent list openstack network agent delete <linuxbridge-agent-id>

清理完成后，重启 OVS agent，让它重新同步网络状态：

systemctl restart neutron-openvswitch-agent

4.5 验证 VXLAN 隧道与实例连通性

所有节点改造完成后，开始验证。先在控制节点查看 agent 状态：

openstack network agent list

确认所有节点的 OVS agent 都是 up 状态。然后在计算节点上查看 OVS 配置：

ovs-vsctl show

应该能看到 br-int、br-tun、br-ex 三个网桥，br-tun 上有 vxlan 类型的端口，br-ex 上挂着物理网卡。

接下来创建一台测试实例，挂到新建的 VXLAN 网络上，然后测试跨节点通信。如果实例能正常获取 IP，能 ping 通网关，能跨节点 ping 通另一台实例，说明改造成功。

如果跨节点不通，先在计算节点上抓包：

tcpdump -i any -n vxlan

看看有没有 VXLAN 包发出和收到。如果有发出没收到，检查物理网络是否放通了 UDP 4789 端口。如果有收到但实例不通，检查 br-int 的流表和 VLAN 标签是否正确。

5. 常见问题与排查技巧实录

5.1 实例能拿 IP 但 ping 不通网关

这个问题在改造后非常常见，原因通常有三个：一是 br-int 上的流表没有正确下发，二是 VLAN 标签转换有问题，三是安全组规则拦截了 ICMP。排查的时候先在计算节点上执行：

ovs-ofctl dump-flows br-int

看看有没有对应的流表项。如果没有，说明 OVS agent 没有正确同步网络状态，可以重启 agent 试试。如果有流表但流量还是不通，检查实例所在的端口 VLAN 标签和网络定义的 segmentation ID 是否一致。

安全组的问题也容易被忽略。默认安全组是允许同组内通信和出站的，但 ICMP 入站需要单独加规则。可以在控制节点执行：

openstack security group rule create --protocol icmp --dst-port -1 default

5.2 跨节点 VXLAN 隧道建立失败

隧道建立失败的表现是ovs-vsctl show里看不到 vxlan 端口，或者端口状态是 down。先检查local_ip配置是否正确，两个节点的隧道 IP 必须互通。然后检查防火墙：

firewall-cmd --list-all

确保 UDP 4789 端口是放通的。如果用的是 iptables，也要检查对应的规则。另外，如果物理网络有 ACL 或者安全策略，也需要放通 VXLAN 流量。

还有一个隐蔽的问题是 MTU。如果物理网卡 MTU 是 1500，但中间网络设备不支持 1550 的大包，VXLAN 封装后的包会被丢弃。这种情况下需要把物理网卡 MTU 调大到 1550 以上，或者把实例网卡 MTU 调小到 1450。

5.3 OVS agent 启动报错排查

OVS agent 启动失败通常会在日志里留下明确线索。常见的错误包括：

查看日志的命令是：

journalctl -u neutron-openvswitch-agent -f

或者直接看/var/log/neutron/openvswitch-agent.log。日志里通常会告诉你具体是哪个配置项出了问题。

5.4 改造后浮动 IP 无法访问

浮动 IP 不通的原因通常是 br-ex 的配置有问题。先检查 br-ex 上是否挂了物理网卡：

ovs-vsctl list-ports br-ex

然后检查 br-ex 是否有正确的 IP 和路由：

ip addr show br-ex ip route show

如果 br-ex 没有 IP，说明网络配置文件没生效。另外，Neutron 的 L3 agent 需要配置external_network_bridge = br-ex，并且gateway_external_network_id要设置正确。如果用的是 DVR 模式，还需要检查enable_distributed_routing和router_distributed的配置。

提示：浮动 IP 不通的时候，先在网络节点上 ping 一下浮动 IP，如果能通说明是外部网络的问题，如果不通说明是 Neutron 内部的问题。这样能快速缩小排查范围。

6. 改造后的性能调优与扩展建议

6.1 OVS 流表优化与 l2population 启用

改造完成后，建议启用 l2population 来减少广播流量。l2population 的作用是把 ARP 请求和广播包通过控制平面同步到各个节点，而不是通过 VXLAN 隧道泛洪。这样能显著降低跨节点的广播流量，提升网络性能。

启用方法是在 ML2 配置里加上l2population，在 OVS agent 配置里设置l2_population = True。启用后，br-tun 上的流表会多出一些针对 ARP 的规则，可以通过ovs-ofctl dump-flows br-tun查看。

另外，可以调整 OVS 的流表缓存和超时时间。默认的流表超时是 30 秒，对于频繁通信的场景可以适当调大，减少流表频繁上下发的开销。具体参数在/etc/neutron/plugins/ml2/openvswitch_agent.ini里的[ovs]段，可以设置ovs_integration_bridge = br-int和ovs_tunnel_bridge = br-tun来明确指定网桥名称。

6.2 MTU 统一调整与验证方法

MTU 问题在 VXLAN 环境里是绕不开的。我的建议是统一把实例网卡的 MTU 设为 1450，物理网卡设为 1550。这样 VXLAN 封装后的包不会超过 1550，避免分片。

设置实例 MTU 的方法是在 Neutron 的网络或者子网里指定：

openstack subnet set --mtu 1450 <subnet-id>

设置物理网卡 MTU 的方法是在网卡配置文件里加MTU=1550，然后重启网络。验证的时候用：

ping -M do -s 1422 <目标IP>

1422 加上 28 字节的 IP 和 ICMP 头正好是 1450。如果这个命令能通，说明 MTU 配置正确。

6.3 后续扩展方向与注意事项

改造完成后，后续可以考虑几个扩展方向。一是接入 OVN 替代 Neutron 的 OVS agent，OVN 提供了更原生的分布式路由和 ACL 能力，性能和管理性都更好。二是启用 DVR，把路由功能下沉到计算节点，减少网络节点的瓶颈。三是接入 SDN 控制器，通过 OpenFlow 实现更灵活的网络策略。

不过这些扩展都需要在现有基础上做进一步改造，建议先把基础的 OVS + VXLAN 跑稳定，再考虑下一步。每次改造前都要做好备份和回滚方案，不要一次性改太多东西，否则出问题很难定位。

我个人在实际操作中的体会是，网络改造最怕的就是心急。一步一步来，每改一个节点就验证一个节点，确认没问题再改下一个。遇到问题不要慌，先看日志，再用抓包和流表分析，大部分问题都能定位到具体的配置项。另外，测试环境一定要和生产环境保持一致的网络拓扑，否则测试通过不代表生产没问题。