乐趣区

就是要你懂负载均衡lvs和转发模式

jiezi

本文希望阐述清楚 LVS 的各种转发模式，以及他们的工作流程和优缺点，同时从网络包的流转原理上解释清楚优缺点的来由，并结合阿里云的 slb 来说明优缺点。

如果对网络包是怎么流转的不太清楚，推荐先看这篇基础：程序员的网络知识 — 一个网络包的旅程，对后面理解 LVS 的各个转发模式非常有帮助。

几个术语和缩写

cip：Client IP，客户端地址
vip：Virtual IP，LVS 实例 IP
rip：Real IP，后端 RS 地址
RS: Real Server 后端真正提供服务的机器
LB：Load Balance 负载均衡器
LVS：Linux Virtual Server
sip：source ip
dip：destination

LVS 的几种转发模式

  • DR 模型 —（Director Routing- 直接路由）
  • NAT 模型 — (NetWork Address Translation- 网络地址转换)
  • fullNAT —（full NAT）
  • ENAT –（enhence NAT 或者叫三角模式 /DNAT，阿里云提供）
  • IP TUN 模型 — (IP Tunneling – IP 隧道)

DR 模型(Director Routing– 直接路由)

如上图所示基本流程(假设 cip 是 200.200.200.2，vip 是 200.200.200.1）：

  1. 请求流量(sip 200.200.200.2, dip 200.200.200.1) 先到达 LVS
  2. 然后 LVS，根据负载策略挑选众多 RS 中的一个，然后将这个网络包的 MAC 地址修改成这个选中的 RS 的 MAC
  3. 然后丢给交换机，交换机将这个包丢给选中的 RS
  4. 选中的 RS 看到 MAC 地址是自己的、dip 也是自己的，愉快地手下并处理、回复
  5. 回复包（sip 200.200.200.1，dip 200.200.200.2）
  6. 经过交换机直接回复给 client 了（不再走 LVS）

我们看到上面流程，请求包到达 LVS 后，LVS 只对包的目的 MAC 地址作了修改，回复包直接回给了 client。

同时还能看到多个 RS 和 LVS 都共用了同一个 IP 但是用的不同的 MAC，在二层路由不需要 IP，他们又在同一个 vlan，所以这里没问题。

RS 上会将 vip 配置在 lo 回环网卡上，同时 route 中添加相应的规则，这样在第四步收到的包能被 os 正常处理。

优点：

  • DR 模式是性能最好的一种模式，入站请求走 LVS，回复报文绕过 LVS 直接发给 Client

缺点：

  • 要求 LVS 和 rs 在同一个 vlan；
  • RS 需要配置 vip 同时特殊处理 arp；
  • 不支持端口映射。

为什么要求 LVS 和 RS 在同一个 vlan（或者说同一个二层网络里）

因为 DR 模式依赖多个 RS 和 LVS 共用同一个 VIP，然后依据 MAC 地址来在 LVS 和多个 RS 之间路由，所以 LVS 和 RS 必须在一个 vlan 或者说同一个二层网络里

DR 模式为什么性能最好

因为回复包不走 LVS 了，大部分情况下都是请求包小，回复包大，LVS 很容易成为流量瓶颈，同时 LVS 只需要修改进来的包的 MAC 地址。

DR 模式为什么回包不需要走 LVS 了

因为 RS 和 LVS 共享同一个 vip，回复的时候 RS 能正确地填好 sip 为 vip，不再需要 LVS 来多修改一次（后面讲的 NAT、Full NAT 都需要）

总结下 DR 的结构

绿色是请求包进来，红色是修改过 MAC 的请求包

NAT 模型(NetWork Address Translation – 网络地址转换)

nat 模式的结构图如下：

基本流程：

  1. client 发出请求（sip 200.200.200.2，dip 200.200.200.1）
  2. 请求包到达 lvs，lvs 修改请求包为（sip 200.200.200.2，dip rip）
  3. 请求包到达 rs，rs 回复（sip rip，dip 200.200.200.2）
  4. 这个回复包不能直接给 client，因为 rip 不是 VIP 会被 reset 掉
  5. 但是因为 lvs 是网关，所以这个回复包先走到网关，网关有机会修改 sip
  6. 网关修改 sip 为 VIP，修改后的回复包（sip 200.200.200.1，dip 200.200.200.2）发给 client

优点：

  • 配置简单
  • 支持端口映射（看名字就知道）
  • RIP 一般是私有地址，主要用户 LVS 和 RS 之间通信

缺点：

  • LVS 和所有 RS 必须在同一个 vlan
  • 进出流量都要走 LVS 转发
  • LVS 容易成为瓶颈
  • 一般而言需要将 VIP 配置成 RS 的网关

为什么 NAT 要求 lvs 和 RS 在同一个 vlan

因为回复包必须经过 lvs 再次修改 sip 为 vip，client 才认，如果回复包的 sip 不是 client 包请求的 dip（也就是 vip），那么这个连接会被 reset 掉。如果 LVS 不是网关，因为回复包的 dip 是 cip，那么可能从其它路由就走了，LVS 没有机会修改回复包的 sip

总结下 NAT 结构

注意这里 LVS 修改进出包的 (sip, dip) 的时候只改了其中一个，所以才有接下来的 full NAT。当然 NAT 最大的缺点是要求 LVS 和 RS 必须在同一个 vlan，这样限制了 LVS 集群和 RS 集群的部署灵活性，尤其是在阿里云这种对外售卖的公有云环境下，NAT 基本不实用。

full NAT 模型(full NetWork Address Translation- 全部网络地址转换)

基本流程（类似 NAT）：

  1. client 发出请求（sip 200.200.200.2 dip 200.200.200.1）
  2. 请求包到达 lvs，lvs 修改请求包为（sip 200.200.200.1，dip rip） 注意这里 sip/dip 都被修改了
  3. 请求包到达 rs，rs 回复（sip rip，dip 200.200.200.1）
  4. 这个回复包的目的 IP 是 VIP(不像 NAT 中是 cip)，所以 LVS 和 RS 不在一个 vlan 通过 IP 路由也能到达 lvs
  5. lvs 修改 sip 为 vip，dip 为 cip，修改后的回复包（sip 200.200.200.1，dip 200.200.200.2）发给 client

优点：

  • 解决了 NAT 对 LVS 和 RS 要求在同一个 vlan 的问题，适用更复杂的部署形式

缺点：

  • RS 看不到 cip（NAT 模式下可以看到）
  • 进出流量还是都走的 lvs，容易成为瓶颈（跟 NAT 一样都有这个问题）

为什么 full NAT 解决了 NAT 中要求的 LVS 和 RS 必须在同一个 vlan 的问题

因为 LVS 修改进来的包的时候把 (sip, dip) 都修改了(这也是 full 的主要含义吧)，RS 的回复包目的地址是 vip（NAT 中是 cip），所以只要 vip 和 rs 之间三层可通就行，这样 LVS 和 RS 可以在不同的 vlan 了，也就是 LVS 不再要求是网关，从而 LVS 和 RS 可以在更复杂的网络环境下部署。

为什么 full NAT 后 RS 看不见 cip 了

因为 cip 被修改掉了，RS 只能看到 LVS 的 vip，在阿里内部会将 cip 放入 TCP 包的 Option 中传递给 RS，RS 上一般部署自己写的 toa 模块来从 Options 中读取的 cip，这样 RS 能看到 cip 了, 当然这不是一个开源的通用方案。

总结下 full NAT 的结构

注意上图中绿色的进包和红色的出包他们的地址变化

那么到现在 full NAT 解决了 NAT 的同 vlan 的要求，基本上可以用于公有云了，但是还是没解决进出流量都走 LVS 的问题（LVS 要修改进出的包）

那么有没有一个方案能够像 full NAT 一样不限制 lvs 和 RS 之间的网络关系，同时出去的流量跟 DR 模式一样也不走 LVS 呢？

阿里云的 ENAT 模式(enhence NAT)

优点：

  • 不要求 LVS 和 RS 在同一个 vlan
  • 出去的流量不需要走 LVS，性能好

缺点：

  • 集团实现的自定义方案，需要在所有 RS 上安装 ctk 组件（类似 full NAT 中的 toa）

基本流程：

  1. client 发出请求（cip，vip）
  2. 请求包到达 lvs，lvs 修改请求包为（vip，rip），并将 cip 放入 TCP Option 中
  3. 请求包根据 ip 路由到达 rs，ctk 模块读取 TCP Option 中的 cip
  4. 回复包 (RIP, vip) 被 ctk 模块截获，并将回复包改写为（vip, cip)
  5. 因为回复包的目的地址是 cip 所以不需要经过 lvs，可以直接发给 client

ENAT 模式在内部也会被称为 三角模式或者 DNAT/SNAT 模式

为什么 ENAT 的回复包不需要走回 LVS 了

因为之前 full NAT 模式下要走回去是需要 LVS 再次改写回复包的 IP，而 ENAT 模式下，这件事情在 RS 上被 ctk 模块提前做掉了

为什么 ENAT 的 LVS 和 RS 可以在不同的 vlan

跟 full NAT 一样

总结下 ENAT 的结构

最后说一下不太常用的 TUN 模型

IP TUN 模型(IP Tunneling – IP 隧道)

基本流程：

  1. 请求包到达 LVS 后，LVS 将请求包封装成一个新的 IP 报文
  2. 新的 IP 包的目的 IP 是某一 RS 的 IP，然后转发给 RS
  3. RS 收到报文后 IPIP 内核模块解封装，取出用户的请求报文
  4. 发现目的 IP 是 VIP，而自己的 tunl0 网卡上配置了这个 IP，从而愉快地处理请求并将结果直接发送给客户

优点：

  • 集群节点可以跨 vlan
  • 跟 DR 一样，响应报文直接发给 client

缺点：

  • RS 上必须安装运行 IPIP 模块
  • 多增加了一个 IP 头
  • LVS 和 RS 上的 tunl0 虚拟网卡上配置同一个 VIP（类似 DR）

DR 模式中 LVS 修改的是目的 MAC

为什么 IP TUN 不要求同一个 vlan

因为 IP TUN 中不是修改 MAC 来路由，所以不要求同一个 vlan，只要求 lvs 和 rs 之间 ip 能通就行。DR 模式要求的是 lvs 和 RS 之间广播能通

IP TUN 性能

回包不走 LVS，但是多做了一次封包解包，不如 DR 好

总结下 IP TUN 的结构

图中红线是再次封装过的包，ipip 是操作系统的一个内核模块。

DR 可能在小公司用的比较多，IP TUN 用的少一些，相对而言接下来的三种比较类似，用的也比较多，他们之间的可比较性很强，所以放在一块了。

参考资料

https://www.atatech.org/articles/15279

https://www.atatech.org/articles/48739

https://www.atatech.org/articles/48571

云服务 ALB 接入，后端依赖内核模块及接口使用指南

程序员的网络知识 — 一个网络包的旅程

本文作者：plantegg

阅读原文

本文为云栖社区原创内容，未经允许不得转载。

退出移动版