模式和限制
DR
RealServer感知客户端真实ip，和LVS有相同的VIP（loopback上配置VIP），直接返回响应给客户端，性能最好。
限制：RS必须和LVS在同一个子网中，不能跨vlan，因为必须二层可达。
NAT
RS感知客户端ip，与LVS没有相同的VIP，需要经过LVS代理才能将响应发给客户端。
限制：LVS必须做为RS的网关，确保RS的响应包能够经过LVS，然后LVS才能将源地址改为VIP，客户端从而能够接收。即，LVS和RS在同一个子网中。
DR和NAT模式下，LVS和RS都必须在同一个vlan中。
FULLNAT
RS不知道客户端ip（阿里通过修改内核协议栈，使用TOA方式（将客户端ip放到tcp的option中）将客户端ip传到RS，从而让RS能够获得客户端ip），与LVS没有相同的VIP，需要经过LVS代理才能将响应发给客户端。
限制：FULLNAT模式下，不要求RS和LVS在同一个vlan中。因为lvs与RS之间的通信只要3层可达即可，中间可以经过3层路由。
lvs和RS都要使用非主线的linux内核。
存在的问题
1，性能
单机lvs：
LVS是基于内核netfilter开发的一个应用程序，而netfilter是运行在内核协议栈的一个钩子框架。这就意味着当数据包到达LVS时，已经经过了一段很长的协议栈处理，但是这段处理对于LVS来说都不是必需的（只需要转发包即可，无需解析整个协议），这也造成了一部分不必要的性能损耗。
中断是影响LVS性能最重要的一个因素。在单核cpu上，假如我们一秒需要处理600万的数据包，每6个数据包产生一个硬件中断的话，那一秒就会产生100万个硬件中断，每一次产生硬件中断都会打断正在进行密集计算的负载均衡程序，中间产生大量的cache miss，对性能的影响异常大。多核cpu上，需要将处理网卡中断程序和负载均衡程序绑定到不同的核上。
使用主备模式的lvs集群：支持流量有限，容易成为瓶颈。
2，可用性
lvs通常使用keepalived来实现主备模式容灾，有以下缺点：
a、主备模式利用率低。一个集群同时只有一半的服务器在工作，另外一半的机器处于冷备状态，主节点不可用之后的切换速度相对较慢。
b、keepalived依赖的VRRP协议存在脑裂(split-brain)的风险，需引入第三方仲裁节点，在金融领域、跨园区容灾领域备受挑战。
lvs的进化
1，性能
性能上面，并没有明显的优化空间
2，可用性
采用lvs集群，加入以下可用性配置：
a，ospf+ecmp模式，核心交换机进入的数据均匀分布到各个lvs节点
b，lvs节点间必须定期进行session同步，解决节点上下线时会话迁移保持可用
