本文主要阐述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）：
- 请求流量(sip 200.200.200.2, dip 200.200.200.1) 先到达 LVS
- 然后LVS，根据负载策略挑选众多 RS中的一个，然后将这个网络包的MAC地址修改成这个选中的RS的MAC
- LVS将处理过后的数据包丢给交换机，交换机根据二层MAC信息将这个包丢给选中的RS
- 接收到数据包的RS看到MAC地址是自己的、dip也是自己的（VIP配置在lo），愉快地收下并处理，并根据路由表将回复包（sip 200.200.200.1， dip 200.200.200.2）返回给交换机
- 回复包（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模式的结构图如下：
基本流程：
- client发出请求（sip 200.200.200.2，dip 200.200.200.1）
- 请求包到达lvs，lvs修改请求包为（sip 200.200.200.2， dip 10.10.10.2）
- 请求包到达rs， rs回复（sip 10.10.10.2，dip 200.200.200.2）
- 这个回复包不能直接给client，因为sip不是200.200.200.1（vip）会被reset掉
- 设置lvs为网关，所以这个回复包先走到lvs，lvs有机会修改sip
- 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是操作系统的一个内核模块。
