【均衡负载之LVS 系列一】 - LVS 五种工作模式

本文主要阐述LVS的各种转发模式，以CDN集群为例

当集群服务能力遇到性能瓶颈，需要进行拓展时，有两种解决思路：Scale-up 和 Scale-out，也称作垂直扩展和水平扩展。

垂直扩展：提升单机处理能力。垂直扩展的方式又有两种：

（1）增强单机硬件性能，例如：升级CPU，扩容硬盘及内存；
（2）提升单机架构性能，例如：使用Cache来减少IO次数，使用异步来增加单服务吞吐量，使用无锁数据结构来减少响应时间；

在业务发展迅猛的早期，如果对成本不敏感，可以采用 增加设备单机硬件能力 的方式来提高集群的服务能力，但垂直拓展有个明显缺点：单机设备能力有极限，并且随着硬件设备能力提高对应的硬件成本会急剧增加，性价比低

水平扩展：增加服务器数量，线性扩充集群。当然水平扩展对系统架构设计是有要求的，就CDN而言需要进行多层的均衡负载来实现。

常见的负载均衡

根据工作所在的协议层可以分为：

• 四层均衡负载：根据请求报文中IP和端口进行调度
• 七层均衡负载：根据请求报文中内容进行调度

根据软硬件划分

• 硬件均衡负载：
  F5 的 BIG-IP
  Citrix 的 NetScaler

这类硬件负载均衡器通常能同时提供四层和七层负载均衡，但同时也价格不菲。

• 软件均衡负载
  基于四层：LVS，HaProxy，Nginx，OSPF（ECMP，ospf为三层协议但ecmp为四层均衡）
  基于七层：Haproxy，Nginx，ATS（Apache Traffic Server），squid，varnish

LVS

以典型的四层均衡负载LVS为例。由于请求数据包需要经过LVS分配处理后到达后端RS，首先会想到通过类似于网关的NAT的方式来进行处理，分为NAT、full NAT、ENAT三种模型，通过NAT的方式由于请求包IP经过改写，回包同样需要根据映射表改写回原IP，故数据流的两个方向都要进行处理。如果要避免进行双方向的数据处理就不能对IP包头进行改写，自然我们会想到对更低的二层包信息进行改造，即网关将相应数据包指向LVS，LVS将数据包DIP对应的mac改为RS的mac，RS回包通过路由表选择直接回给网关，由于请求包数据量远小于回包数据量，能大大降低LVS的压力。除上述两种方式外，还可通过封装的方式将包分配（TUNNEL），下面我们具体介绍各种模型的实现原理及优缺点

• DR模型 -- （Director Routing-直接路由）
• NAT模型 -- (NetWork Address Translation-网络地址转换)
• fullNAT -- （full NAT，双向数据包都进行SNAT与DNAT）
• ENAT --（enhence NAT 或者叫三角模式/DNAT）
• IP TUN模型 -- (IP Tunneling - IP隧道)

几个常用术语的缩写

cip：Client IP，客户端地址
vip：Virtual IP，虚IP
rip：Real IP，后端RS地址
RS: Real Server 后端真正提供服务的机器
LB： Load Balance 负载均衡器
LVS： Linux Virtual Server
sip： source ip，源IP
dip： destination ip，目的IP
NAT： Network Address Translation，网络地址转换
SNAT: Source Network Address Translation，源地址转换
DNAT: Destination Network Address Translation，目的地址转换

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. LVS将处理过后的数据包丢给交换机，交换机根据二层MAC信息将这个包丢给选中的RS
4. 接收到数据包的RS看到MAC地址是自己的、dip也是自己的（VIP配置在lo），愉快地收下并处理，并根据路由表将回复包（sip 200.200.200.1， dip 200.200.200.2）返回给交换机
5. 回复包（sip 200.200.200.1， dip 200.200.200.2）经过交换机直接回复给client（不再走LVS）

可以看到经过上面的流程，请求包到达LVS后，LVS只对包的目的MAC地址作了修改，RS将回包直接回给了client。
由于LVS、RS都会接收处理到DIP为VIP的数据包，所以VIP必须绑定在网卡上，考虑到vlan内不能有多个设备对同一VIP进行ARP广播或应答，RS需将VIP配置在lo回环网卡上，并且对ARP进行相应的配置。

优点：

• DR模型下，LVS只需对请求的数据包进行处理，回包绕过LVS直接发给Client，大大降低了LVS的压力（请求包远少于数据包，并且只改二层mac信息）

缺点：

• LVS和RS必须在一个VLAN中（修改mac后数据包只在二层网络中路由）
• RS需将VIP绑在lo，并对ARP进行特殊配置

绿色是请求包进来，红色是修改过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 10.10.10.2）
3. 请求包到达rs， rs回复（sip 10.10.10.2，dip 200.200.200.2）
4. 这个回复包不能直接给client，因为sip不是200.200.200.1（vip）会被reset掉
5. 设置lvs为网关，所以这个回复包先走到lvs，lvs有机会修改sip
6. lvs修改sip为VIP，修改后的回复包（sip 200.200.200.1，dip 200.200.200.2）发给client

优点：

• 配置简单，通用性强
• 支持映射（NAT映射表）
• RIP可以是私网IP，用于LVS与RS之间通讯

缺点：

• LVS和RS必须在一个VLAN中（RS将LVS配置为网关，如果不在一个子网回包会经过路由器网关直接路由走，LVS没机会修改数据包）
• 进出流量都需要LVS进行处理，LVS容易成为集群瓶颈
• 需要将LVS配置为RS的网关

注意这里LVS修改进出包的(sip, dip)的时候只改了其中一个，进方向进行DNAT，出方向进行SNAT，要求LVS和RS必须在同一个vlan，限制了LVS集群和RS集群的部署灵活性，所以才有接下来的full NAT。

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

基本流程（类似NAT）：

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

优点：

• 解决了NAT对LVS和RS要求在同一个vlan的问题，适用更复杂的部署形式
• 不要求配置LVS为网关（LVS与RS可以通过三层通讯）

缺点：

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

为什么RS看不到CIP

RS接受到的数据包为（sip 200.200.200.1， dip rip），只能看到sip对应的VIP，一般会将cip放入TCP包的Option中传递给RS，RS上一般部署自己写的toa模块来从Options中读取的cip，这样RS能看到cip了, 当然这不是一个开源的通用方案。

full NAT解决了NAT模式下需要同vlan的问题，但是还是没解决进出流量都走LVS的问题（LVS要修改进出的包），那么有没有一个方案能够像full NAT一样不限制lvs和RS之间的网络关系，出去的流量跟DR模式一样也不走LVS呢？
有个方案，将回包方向的NAT处理放在RS上完成

ENAT模式(enhence NAT)

优点：

• 不要求LVS和RS在同一个vlan
• 出方向流量不需要走LVS，减小对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

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

基本流程：

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

优点：

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

缺点：

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

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

参考文章

https://yq.aliyun.com/article...