OVS核心架构：数据平面与控制平面分离

聊到OVS的架构，我习惯先画一张图。不是那种花里胡哨的架构图，而是三个核心组件：ovs-vswitchd、ovsdb-server，还有内核模块。这三兄弟分工明确，配合默契。

说白了，OVS的设计哲学就是「数据平面与控制平面分离」。这个概念你听着可能有点抽象，我换个说法：管转发的人不管策略，管策略的人不碰数据。

1. ovs-vswitchd：控制平面的核心

这是OVS的守护进程，运行在用户空间。它的职责是什么？处理OpenFlow协议、管理流表、与控制器通信。

我在项目中遇到过一个问题：ovs-vswitchd挂了，但网络还在跑。为什么？因为数据平面已经下刷到内核模块了。嗯，这里要注意——ovs-vswitchd主要负责控制逻辑，不直接参与数据转发。

我曾经踩过一个坑：在ovs-vswitchd重启时，流表会丢失。如果你用的是OpenFlow控制器，控制器会重新下发流表。但如果你用的是静态流表，那就得手动恢复了。所以，生产环境一定要配控制器，别偷懒。

2. ovsdb-server：配置的仓库

ovsdb-server是个轻量级的数据库服务，专门存OVS的配置信息。比如网桥、端口、QoS策略、隧道信息，全存在这里。

你想想看，ovs-vswitchd启动时，第一件事就是去ovsdb-server拉配置。如果ovsdb-server挂了，ovs-vswitchd就不知道该怎么干活了。

组件	存储内容	协议
ovsdb-server	网桥、端口、QoS、隧道配置	OVSDB协议
ovs-vswitchd	流表、OpenFlow状态	OpenFlow协议

我个人习惯用ovs-vsctl命令操作ovsdb-server。比如：

# 创建一个网桥
ovs-vsctl add-br br-int

# 添加一个端口
ovs-vsctl add-port br-int eth0

# 查看所有配置
ovs-vsctl show

这些命令本质上是往ovsdb-server里写数据。ovs-vswitchd监听到配置变化后，会动态调整行为。

3. 内核模块：数据平面的加速器

这才是真正干活的组件。OVS的内核模块（openvswitch.ko）负责快速转发数据包。它维护了一个内核态的流表缓存，叫datapath流表。

数据包到达时，流程是这样的：

1. 内核模块查datapath流表
2. 命中？直接转发，零用户态开销
3. 未命中？上送到ovs-vswitchd处理
4. ovs-vswitchd查完整流表，下刷到内核
5. 后续同类型包，直接内核转发

说白了，这就是一个缓存加速机制。我第一次接触时觉得挺巧妙——把频繁匹配的流表项下刷到内核，性能提升非常明显。

4. 数据平面与控制平面分离

这个设计理念，其实不是OVS独创的。传统交换机也有类似思路——控制平面跑路由协议，数据平面做硬件转发。

OVS把这一套搬到了软件里：

• 控制平面：ovs-vswitchd + ovsdb-server，跑在用户空间
• 数据平面：内核模块，跑在内核空间

为什么要分离？我举个例子。假设你有一个OpenStack集群，Neutron需要动态调整网络策略。如果每次调整都要重启数据平面，那网络就断了。但有了分离设计，控制平面可以随时调整流表，数据平面无缝切换。

我曾经在项目中遇到一个场景：需要临时封锁某个VM的流量。用OpenFlow控制器下发一条流表，ovs-vswitchd收到后下刷到内核模块，整个过程零丢包、零中断。

5. 实战中的组件协作

我们来看一个完整的流程。假设Neutron创建了一个新的网络：

1. Neutron通过OVSDB协议，往ovsdb-server写入新网桥配置
2. ovs-vswitchd监听到配置变化，创建网桥
3. Neutron通过OpenFlow协议，下发流表到ovs-vswitchd
4. ovs-vswitchd把流表写入用户空间流表，同时下刷到内核模块
5. VM发送数据包，内核模块直接匹配转发

你看，整个过程三个组件各司其职。ovsdb-server管配置，ovs-vswitchd管策略，内核模块管转发。

我个人习惯在生产环境部署时，把ovsdb-server和ovs-vswitchd放在同一个宿主机上，但监控和日志要分开。这样排查问题时，能快速定位是配置问题还是流表问题。

嗯，最后说一句。理解OVS的架构，其实就是理解谁负责决策，谁负责执行。这个思路，在SDN和云计算里到处都能看到。