一、LVS的问题

1. LVS在大规模网络中应用存在不足
   各转发模式,网络拓扑复杂,运维成本高
2. 和商用LB设备相比
   缺少TCP标志位DDOS攻击防御
3. 主备部署方式不足
   性能无法线性扩展

线性扩展指的是水平增加几个调度节点，LVS虽然可以结合Keepalived实现高可用，但实际上只有一个调度器在工作，VIP始终漂在master节点上。

1.DR模式-不足

1. LVS-RS间必须在同一个VLAN
2. RS上绑定VIP,风险大;
   

2.NAT模式-不足

RS必须设置LVS为自己的网关，当RS处于不同网段时，则需要通过配置策略路由，将数据包返回LVS，策略路由配置繁琐。

3.TUNNEL-不足

二、解决办法

LVS的DR、TUN、NAT转发模式运维成本高

   第四种转发模式FULLNAT，主要针对云端环境：实现LVS-RealServer间跨vlan通讯，并且in/out流都经过LVS。FULLNAT需要编译内核来实现，keepalived也需要重新编译安装，因为原始版本并不支持该模式。FULLNAT转发损耗最大，因为要转换两层，当硬件好时，可以忽略。
  云端环境中每个租户都会设置自己的vxlan，也就是私有网络，其实就是每个RealServer在不同的vxlan下,同时还希望实现负载均衡，所以需要一种跨vlan的调度方式。NAT虽然实现了在不同网络下的调度，但是还是难以实现跨vlan的调度，不好设置。

LVS的各个转发模式缺少攻击防御模块

SYNPROXY:synflood攻击防御模块
其他TCP FLAG DDOS攻击防御策略
第四种转发模式数据流来回都要经过LVS，所以可以做抗攻击。

性能无法线性扩展
FULLNAT解决：Cluster部署模式

FULLNAT是一种新的转发模式

• 主要思想：引入local address(内网ip地址)，cip-vip转换为lip-rip,而lip和rip均是IDC内网IP，可以实现跨vlan通讯；
• keepalived配置方式：
  virtual_server 172.25.254.100 {
  
    lb_kind FNAT/DR/NAT/TUNNEL
  
    local_address {
  
      192.168.1.1
  
    }
  
  }

三、NAT转发模式与FULLNAT转发模式对比

NAT模式是将请求报文做DNAT，将应答报文做SNAT转换。
商用的负载均衡很多都是NAT，因为应答数据包不经过LVS时，就无法控制实现安全防护。
FULLNAT是LVS在请求报文和应答报文经过时做两次转换DNAT与SNAT。

四、NAT与FULLNAT转发模式的session表

NAT用client address作为hash key

FULLNAT-session表是双向hash,用五元组作为hash key，即 源地址、源端口、协议、目标端口、目标地址。

五、FULLNAT模式下获取客户端地址模型图

六、SYNPROXY实现原理

LVS在会构造SYNACK包seq与客户端进行TCP三次握手，如果发现客户端是个tcp半连接，则不转发给后端服务器。

七、CLUSTER如何实现的线性扩展

路由器是硬件，而且可以通过vrrp协议做冗余。当数据包经过路由器时，会通过ospf协议负载到后端调度器，调度器节点需要配置相应的OSPF协议。能支持多少条等价路由，主要看路由器性能，以前是不支持的，不是不支持等价路由,而是不支持一致性hash,不支持一致性hash在业务中会出现当原来访问的调度节点挂掉后，路由器转换后的接替调度节点如何把原来的客户请求还发送到原来的realserver,因为业务访问的很多都是动态的，动态页面，需要应用处理的，客户端已经和后端服务器建立了session连接，还没处理完，就断开，调度到其他后端服务器，会导致客户端之前做的工作没了。虽然不会有报错，但是用户感受不好，比如购物时购物车被清空了。
  原来阿里是在每个节点上维护一个session表，调度节点时刻同步session表，来维护session的一致性。现在路由器性能好了，支持一致性哈希,由路由器记录，所有数据都要经过路由器，vip整个上移到路由器，路由器就变成调度器，通过ospf等价路由线性扩展调度器。