2、OVS QoS架构：Ingress与Egress策略、QoS与Queue的关系
好，咱们进入第二章。这一章我打算把OVS的QoS架构彻底讲透。说实话，很多新手甚至老手，在配置QoS时都容易搞混一个概念——Ingress和Egress到底怎么区分？QoS和Queue又是什么关系？
我记得刚接触OVS那会儿，也在这上面栽过跟头。明明配了限速，结果流量还是跑得飞起。后来一查，原来是策略方向搞反了。嗯，今天咱们就把这些坑一个个填平。
2.1 什么是Ingress和Egress？
先看两个基本概念。Ingress，指的是流量进入交换机的方向。Egress，是流量离开交换机的方向。你想想看，一个数据包从物理网卡进来，经过OVS处理，再从另一个端口出去——进来的方向就是Ingress，出去的方向就是Egress。
在OVS里，这两个方向的处理方式完全不同。
- Ingress策略：在数据包进入OVS端口时生效。说白了，就是限制“谁可以进来，进来多少”。
- Egress策略：在数据包离开OVS端口时生效。说白了，就是控制“出去的速度和优先级”。
我个人习惯把Ingress比作“门卫”，Egress比作“交警”。门卫管你能不能进门，交警管你出门后怎么走、走多快。
核心要点：OVS的QoS限速主要针对Egress方向。Ingress方向虽然也有策略，但功能相对有限，通常用police（ policing）来实现。
2.2 Ingress策略：police机制
Ingress方向，OVS用的是police机制。它不像Egress那样有复杂的队列调度，而是简单粗暴——超过速率，直接丢包或标记。
我曾经在一个数据中心项目里，遇到过虚拟机疯狂发包导致宿主机CPU飙升的问题。排查了半天，发现是Ingress方向没有做任何限制。后来加了police规则，问题立刻解决。
配置示例：
# 创建一个ingress policing规则，限制入方向速率100Mbps
ovs-vsctl set Interface eth0 ingress_policing_rate=100000
ovs-vsctl set Interface eth0 ingress_policing_burst=10000这里要注意两个参数：
ingress_policing_rate：速率限制，单位Kbps。100000就是100Mbps。ingress_policing_burst：突发大小，单位Kb。允许短时间超过限制的流量。
避坑指南：我曾经遇到过一个问题——配置了ingress_policing_rate，但流量还是能超过限制。后来发现，burst值设得太大了。burst相当于一个“缓冲池”，如果设得太大，短时间内的突发流量就能绕过限制。建议burst设为rate的10%左右。
2.3 Egress策略：QoS与Queue
Egress方向才是OVS QoS的重头戏。这里涉及两个核心概念：QoS和Queue。
说白了，QoS是一个“容器”，Queue是容器里的“格子”。一个QoS可以包含多个Queue，每个Queue有不同的优先级和带宽保证。
| 概念 | 作用 | 类比 |
|---|---|---|
| QoS | 定义端口的流量整形策略 | 交通规则 |
| Queue | 定义具体的队列参数（速率、优先级） | 车道 |
我习惯这样理解：QoS就像一条高速公路的管理规则，Queue就是上面的快车道、慢车道、应急车道。每条车道有各自的限速和通行权限。
2.4 QoS的类型
OVS支持两种主要的QoS类型：
- linux-htb：层级令牌桶（Hierarchical Token Bucket）。支持多层队列，可以精细控制带宽分配。我个人最常用这个。
- linux-hfsc：分层公平服务曲线（Hierarchical Fair Service Curve）。延迟控制更好，但配置复杂一些。
配置示例：
# 创建一个HTB QoS，限制总带宽为1Gbps
ovs-vsctl set Port br0 qos=@newqos \
-- --id=@newqos create QoS type=linux-htb \
other-config:max-rate=1000000000 \
queues=0=@q0,1=@q1 \
-- --id=@q0 create Queue other-config:min-rate=500000000 \
-- --id=@q1 create Queue other-config:min-rate=200000000这段代码做了三件事：
- 创建了一个QoS对象，类型是linux-htb，总带宽1Gbps。
- 创建了两个Queue：q0最小保证500Mbps，q1最小保证200Mbps。
- 把这两个Queue绑定到QoS上。
小技巧：min-rate是最小保证带宽，max-rate是最大限制带宽。如果你只设min-rate不设max-rate，队列可以借用空闲带宽。这在流量波动大的场景下很实用。
2.5 QoS与Queue的关系
这个关系其实很简单：一个QoS管理多个Queue。QoS负责整体调度，Queue负责具体执行。
你想想看，如果没有Queue，QoS就是一个空壳子，没法区分不同流量。如果没有QoS，Queue就是散兵游勇，没有统一调度。
我记得有一次帮客户排查网络延迟问题。他们配置了QoS，但所有流量都走同一个Queue。结果视频会议和文件下载互相抢带宽，延迟高得离谱。后来我把流量分到不同Queue，视频走高优先级队列，下载走低优先级，问题立刻解决。
映射关系如下：
Port (br0)
└── QoS (linux-htb, max-rate=1Gbps)
├── Queue 0 (min-rate=500Mbps, 高优先级)
├── Queue 1 (min-rate=200Mbps, 中优先级)
└── Queue 2 (min-rate=100Mbps, 低优先级)然后通过流表规则，把不同流量映射到不同Queue：
# 把视频流量映射到Queue 0
ovs-ofctl add-flow br0 "priority=100,udp,tp_dst=3478,actions=set_queue:0,normal"
# 把文件下载流量映射到Queue 1
ovs-ofctl add-flow br0 "priority=50,tcp,tp_dst=80,actions=set_queue:1,normal"2.6 实战中的选择建议
说了这么多，到底什么时候用Ingress，什么时候用Egress？
- 限制虚拟机发出来的流量：用Egress。因为流量从虚拟机出来，经过OVS端口出去，Egress正好管这个方向。
- 限制外部进入的流量：用Ingress。但要注意，Ingress只能做简单的速率限制，不能做复杂的队列调度。
- 需要区分不同业务优先级：必须用Egress + 多个Queue。Ingress做不到。
一句话总结：Ingress是“限速门卫”，Egress是“调度交警”。QoS是“交通规则”，Queue是“具体车道”。搞清楚了这四者的关系，OVS QoS你就掌握了八成。
下一章，我会带大家实战配置一个完整的QoS限速方案。到时候咱们手把手操作，把今天讲的理论落地。嗯，今天就到这里，有问题随时交流。