也说说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了。搞的那么复杂维护成本会非常高的，自动化运维没有跟上的时候只会把自己给玩死。

在使用LVS之前，建议大家一定仔细看看文档，没有好好看文档就别瞎折腾了。