3、Open vSwitch简介：OVS的架构、OVS核心组件、OVS与Linux Bridge的对比

好，咱们进入第三讲。前面两章我们把VXLAN的原理和报文结构聊透了，现在该聊聊实现VXLAN的核心工具——Open vSwitch了。

说实话，我第一次接触OVS是在一个数据中心项目里。当时客户要求做多租户隔离，传统的Linux Bridge根本搞不定，我折腾了两天，最后发现OVS才是正解。嗯，从那以后，我对OVS就特别上心。

3.1 OVS的整体架构

OVS的架构，说白了就是「控制面」和「数据面」分离的设计。你想想看，传统的交换机把控制和转发绑在一起，升级个功能得换硬件。OVS不一样，它把控制逻辑抽出来，转发面只管快速丢包。

我习惯把OVS的架构分成三层：

• 管理层：包括ovs-vsctl、ovs-ofctl这些命令行工具，还有OpenFlow控制器。这一层负责下发策略、配置网桥。
• 核心层：ovs-vswitchd守护进程，负责处理OpenFlow流表、学习MAC地址、处理VXLAN隧道封装。这是OVS的大脑。
• 数据层：内核模块openvswitch.ko，负责快速转发。说白了，大部分数据包都在内核里处理，只有匹配不到流表的包才会上送到ovs-vswitchd。

这里有个关键点：OVS的数据面有两个模式——内核态和用户态（DPDK）。内核态适合通用场景，性能够用；用户态DPDK模式适合高性能场景，能跑到线速。我在项目中遇到过，如果对延迟要求极高，比如金融交易系统，必须上DPDK模式。

3.2 OVS核心组件详解

3.2.1 ovs-vswitchd

这是OVS最核心的守护进程。它负责：

• 管理OpenFlow流表
• 处理VXLAN、GRE等隧道封装
• 学习MAC地址（类似传统交换机的MAC学习）
• 与OpenFlow控制器通信（比如OVN、OpenDaylight）

我举个例子，当你创建一个VXLAN隧道时，ovs-vswitchd会在内核里安装一条流表规则，告诉内核：「看到这个VNI的包，就给我封装成VXLAN发出去」。这个过程对用户是透明的。

我曾经踩过一个坑：ovs-vswitchd如果挂了，所有网络流量都会中断。因为内核里的流表虽然还在，但新的连接建立不了。所以生产环境一定要做高可用，比如用OVS的主动备份模式。

3.2.2 ovsdb-server

ovsdb-server是OVS的数据库服务。它存储了所有配置信息，包括：

• 网桥配置（br-int、br-ex等）
• 端口配置（VXLAN端口、VLAN端口）
• QoS策略
• 流表备份

你想想看，OVS的配置是持久化的。重启机器后，ovsdb-server会从磁盘加载配置，然后ovs-vswitchd根据配置重建网桥和流表。这个设计很聪明，避免了每次重启都要重新配置。

我个人习惯用ovs-vsctl show命令查看当前配置，这个命令就是从ovsdb-server里读取数据的。如果ovsdb-server挂了，ovs-vsctl命令会报错，但已经运行的网络不会受影响——因为ovs-vswitchd还在跑。

3.3 OVS与Linux Bridge的对比

很多新手会问：「Linux Bridge也能做二层交换，为什么还要用OVS？」这个问题问得好。我直接给你列个对比表：

特性	Linux Bridge	Open vSwitch
二层交换	支持	支持
VLAN支持	支持（802.1Q）	支持（802.1Q + QinQ）
VXLAN隧道	需要额外配置	原生支持，性能更好
OpenFlow协议	不支持	原生支持
流表控制	基于MAC学习	基于流表，灵活可编程
QoS	简单限速	精细的流量控制
多租户隔离	需要手动配置	通过VNI自动隔离
性能	内核态，性能尚可	内核态+DPDK，性能更强

说白了，Linux Bridge适合简单的场景，比如给KVM虚拟机提供网络。但如果你要做VXLAN Overlay、多租户隔离、SDN控制器对接，OVS是唯一的选择。

我记得有一次帮朋友排查问题，他用Linux Bridge做VXLAN，结果隧道不通。我一看，他忘了配置VXLAN的VTEP IP。换成OVS后，一条命令搞定：ovs-vsctl add-port br-int vxlan0 -- set interface vxlan0 type=vxlan options:remote_ip=192.168.1.100。这就是差距。

下一章，我们会动手搭建第一个OVS网桥，并创建VXLAN隧道。到时候你会看到，OVS的命令行操作其实非常直观。