本文主要以CDN集群为例，讲解LVS的各种转发模式。当集群服务容量遇到性能瓶颈需要扩展时，有两种解决思路：Scale-up和Scale-out，也称为垂直扩展和水平扩展。纵向扩展：提高单机处理能力。垂直扩展有两种方式：(1)提升单机硬件的性能，如：升级CPU、扩展硬盘和内存；(2)提高单机架构的性能，例如：使用Cache减少IO次数，使用异步增加单服务Throughput，使用无锁数据结构减少响应时间；在业务快速发展的初期，如果对成本不敏感，可以通过增加单机设备的硬件能力来增加集群的服务能力，但是垂直扩展有一个明显的缺点：容量单机设备的容量是有限制的，随着硬件设备容量的增加，相应的硬件成本也会急剧增加，性价比较低。水平扩展：增加服务器数量，线性扩展集群。当然，横向扩展需要系统架构设计。对于CDN，需要多层负载均衡来实现。常见的负载均衡可以根据工作所在的协议层来划分：四层负载均衡：根据请求报文中的IP和端口进行调度七层负载均衡：根据请求报文的内容进行调度根据软件和硬件部门硬件负载平衡：硬件负载平衡器，例如F5的BIG-IPCitrix的NetScaler通常可以同时提供第4层和第7层负载平衡，但它们也很昂贵。软件负载均衡基于四层：LVS、HaProxy、Nginx基于七层：Haproxy、Nginx、ATS（ApacheTrafficServer）、squid、varnishLVS以典型的四层负载均衡LVS为例。由于请求包需要经过LVS分配处理才能到达后端RS，所以首先想到的是通过类似于网关的NAT进行处理，分为三种模式：NAT、fullNAT、和ENAT。通过NAT，请求包IP改写后，返回包也需要根据映射表改写回原来的IP，所以数据流的两个方向都要处理。如果要避免双向数据处理，则不能重写IP标头。自然而然的，我们会想到修改下层二层包信息，即网关将对应的数据包指向LVS，LVS改变数据包的DIP对应的mac。对于RS的mac，RS回复包直接通过路由表发回网关。由于request包的数据量远小于reply包的数据量，可以大大减轻LVS的压力。除了以上两种方式外，还可以通过封装进行数据包分发（TUNNEL）。下面我们将详细介绍各种模型的实现原理和优缺点。DRmodel--(DirectorRouting-直接路由)NATmodel--(NetWorkAddressTranslation-NetworkAddressTranslation)fullNAT--(全NAT，双向数据包是SNAT和DNAT)ENAT--(enhenceNATortrianglemode/DNAT)IPTUN模型——（IPTunneling——IP隧道）几个常用术语的缩写cip：ClientIP，客户端地址vip：VirtualIP，virtualIPrip：RealIP，后端RS地址RS：RealServer实际的机器LB后端提供服务：LoadBalanceLVS:LinuxVirtualServersip:sourceip,sourceIPdip:destinationip,destinationIPNAT:NetworkAddressTranslation,SNAT:SourceNetworkAddressTranslation,sourceaddresstranslationDNAT:DestinationNetworkAddressTranslation,目的地址翻译DR模型（DirectorRouting--直接路由）上图基本流程（假设cip为200.200.200.2，vip为200.200.200.1）：请求流量（sip200.200.200.2，dip200.200.200.1）首先到达LVS然后是LVS，根据负载策略在众多RS中选择一个，然后将网络包的MAC地址修改为所选RS的MACLVS并将处理后的数据包丢给交换机，交换机再将数据包丢给根据二层MAC信息选择RS。收到数据包的RS看到MAC地址是自己的，dip也是自己的（VIP配置在lo），欣然接受处理，返回回复包（sip200.200.200.1，dip200.200.200.2)到交换机回复包(sip200.200.200.1,dip200.200.200.2)通过交换机直接回复客户端(不再走LVS),可以看到经过上面的过程,请求包到达了LVS之后，LVS只修改数据包的目的MAC地址，RS直接将数据包返回给客户端。由于LVS和RS都会接收并处理DIP为VIP的数据包，所以VIP必须绑定网卡。考虑到vlan中的多个设备不能进行ARP广播或者回复同一个VIP。RS需要在lo环回网卡上配置VIP，并相应配置ARP。优点：在DR模型下，LVS只需要处理请求的数据包，返回包绕过LVS直接发送给Client，大大减轻了LVS的压力（请求包远小于数据包，只二层mac信息改变）缺点：LVS和RS必须在同一个VLAN（修改mac后数据包只在二层网络路由）RS需要绑定VIP到lo，并进行特殊处理ARP上的配置。绿色是进来的请求包，红色是修改后的MAC。请求包NAT模型（NetWorkAddressTranslation-NetworkAddressTranslation）nat模式结构图如下：基本流程：客户端发送请求（sip200.200.200.2，dip200.200.200.1），请求包到达lvs,lvs修改请求包为(sip200.200.200.2,dip10.10.10.2)请求包到达rs,rs回复(sip10.10.10.2,dip200.200.200.2)这个回复包不能直接发给客户端,因为sip不是200.200.200.1（vip）会被reset，设置lvs为Gateway，所以这个回复包先到lvs，lvs有机会修改siplvs把sip改成VIP，修改后的回复包（sip200.200.200.1,dip200.200.200.2)发送给客户端。优点：配置简单，通用性强，支持映射（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集群的部署灵活性，所以才有了下一个fullNAT。全NAT模型（fullNetWorkAddressTranslation-fullnetworkaddresstranslation）的基本流程（类似NAT）：客户端向lvs发送请求（sip200.200.200.2dip200.200.200.1），lvs修改请求packetto(sip200.200.200.1,diprip)注意这里sip/dip被修改了。请求包到达rs，rs回复（siprip,dip200.200.200.1）。这个回复包的目的IP是VIP（不像NAT中的cip），所以LVS和RS不在一个vlan中，也可以通过IP路由到达lvslvs。修改sip为vip，dip为cip，将修改后的回复包（sip200.200.200.1，dip200.200.200.2）发送给客户端。优点：解决了LVS和RS在同一个vlan的NAT需求，适用于更复杂的部署形式。不需要配置LVS作为网关（LVS和RS可以三层互通）。缺点：RS看不到cip（NAT模式下可以看到），进出流量还是走lvs，容易成为瓶颈（和NAT一样的问题）。为什么RS看不到CIPRS收到的数据包是（sip200.200.200.1，diprip），而只能看到sip对应的VIP，一般把cip放在TCP包中选项传给RS。RS通常会部署自己写的toa模块来读取Options中的cip，这样RS就可以看到cip了。当然，这不是一个开源的通用解决方案。FullNAT解决了NAT方式下需要同一个vlan的问题，但是还是没有解决进出流量都走LVS的问题（LVS需要修改出入包），请问有没有解决办法不限制lvs和RS像fullNAT那样的网络关系，出流量和DR模式一样不走LVS？有一个解决方案，将返回方向的NAT处理放在RS上完成ENAT模式（enhenceNAT）。优点：不需要LVS和RS在同一个vlan。出站流量不需要经过LVS，减轻了LVS的压力缺点：CustomSolution，需要在所有RS上安装ctk组件（类似于fullNAT中的a）。基本流程：1.client发出请求(cip,vip)2.请求包到达lvs，lvs修改请求包为(vip,rip)，并将cip放入TCPOption3.请求包到达rs到ip路由，ctk模块读取TCPOption4中的cip，回复包(RIP,vip)被ctk模块拦截，回复包重写为(vip,cip)5.因为目的地址回复包的cip，不需要经过lvs，直接发给客户端IPTUN模型（IPTunneling-IP隧道）基本流程：请求包到达LVS后，LVS将请求包封装成anewIP报文的newIP包的目的IP是某个RS的IP，然后转发给RSRS。这个IP，以便愉快地处理请求并将结果直接发送给客户端。优点：集群节点可以跨VLAN，就像DR一样，响应报文直接发给客户端。缺点：必须在RS上安装并运行IPIP模块，并且增加了一个IP头LVS在RS上的tunl0虚拟网卡上配置相同的VIP（类似DR）。图中红线是重新封装的包，ipip是操作系统的一个内核模块。参考文章https://yq.aliyun.com/article...
