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


你可能感兴趣的:(淘宝)