LVS-模式

LVS主要是DR,TUN,NAT和淘宝的FULLNAT模式，对于绝大部分人而言只能选择原版内核支持的前三种。

1.DR模式

DR模式是效率最高的一种，对于每个请求LVS把目的mac改为从RS中选择的机器的mac，再将修改后的数据帧在与服务器组的局域网上发送。可是局限性是LVS机器须要和RS至少能有一个网卡同在一个VLAN下面，这样限制了DR模式只能在比较单一的网络拓扑下使用。

2.TUN模式

TUN模式其实性能与DR模式相比差异不大的，TUN模式下会动态地从RS列表选择一台服务器，将请求报文封装在另外一个IP报文中，再将封装后的IP报文转发给选出的服务器；RS服务器收到报文后，先将报文解封得到原来目标地址为VIP的报文，服务器发现VIP地址被配置在本地的IP隧道设备上，因此就处理这个请求，而后根据路由表将响应报文直接返回给客户。TUN模式能够解决DR模式下不能垮网段的问题，甚至能够垮公网进行。可是须要RS能支持ipip模块。

3.NAT模式

NAT模式对RS没有其余要求，惟一的要求是得把RS的网关设置为LVS机器。由于进出的流量都要经过LVS机器，因此性能相对会差不少，并且部署的规模很难作大。

以上DR模式和TUN模式在部署的时候都须要在本机绑定VIP，很是麻烦，好比咱们以前有的老应用由于一些历史问题单个应用的VIP有40来个，若是用LVS作负载均衡基本就崩溃了，每次新增/删除一个VIP，估计得线下测试好屡次ip addr add/del的用法。NAT模式在部署的时候也是太麻烦了。并且还有一个很关键很关键的是，使用了LVS后万一被人ddos怎么办？syn-cookie在抵挡***的时候效果通常不是太好，这样***透过lvs直击后端应用就杯具了。因此在不少大公司都不敢直接把lvs放公网，前面得加个防火墙啥的。因此淘宝单独搞了一个fullnat模式，一方面能够解决部署绑VIP、或者把RS的网关设置为LVS机器IP带来的部署复杂问题，另一方面是加了一个syn-proxy等等，能够抵挡下通常的网络层***。可是使用FULLNAT模式后确实有个麻烦的是后端机器看不到用户的IP了，因此RS上还得用装上打过补丁的内核，对取IP的操做就劫持才能获取到用户IP。

对于大规模网站，其实不管单独使用哪一种LVS都是不能替换商业设备的，因此仍是得配合nginx or haproxy作负载均衡。这个时候最简单的就是lvs(fullnat)+nginx/haproxy（nginx官方版本如今没有4层代理功能，haproxy对后端又不支持keepalive）,固然使用DR模式或者TUN模式也还能够的。总之基本都得用2层才能搞得定，知足大部分应用上的需求。其实对于不少小公司，我以为直接用nginx/haproxy就OK了。搞的那么复杂维护成本会很是高的，自动化运维没有跟上的时候只会把本身给玩死。