Lvs

一般说来一个服务器如果同时有公网ip和私网ip，那么网卡上都是配置一下不同的vlan tag使得网卡能用属于不同vlan内的地址。因为LVS在用DR模式只是需要Director和RS能通过1个子网通信。所以当我的机器同时都有公网IP和私网IP的时候，配RS时就写的私网的IP。结果发现是跑不通的，后来想了一下是因为这个包在走内网地址转发的时候vlan tag信息丢了，造成包到RS后是处理不了的。 在使用TUN模式的时候是么有这样的问题的，但TUN模式有个很头大的问题是在于不支持MTU协商。如果client段发的请求报文超过1440（1440+ipip头20字节+20字节tcp头+20字节ip头）那么这个请求是不能处理的。因为client端完全在是不能动的，这个时候就只有靠iptables来解决了。 iptables -A OUTPUT -s VIP -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN,ACK -j TCPMSS --set-mss 1440 上面的这条就可以让RS在和client端三次握手的时候向对方表明自己的MSS是1440,避免client段发送的报文大于1440.

一般情况下大家在使用LVS的时候都很喜欢直接用DR模式，觉得DR模式的效率是最高。不过实际上DR模式在很多时候给我们带来的约束也非常大，最明显的莫过于LVS机器需要和RS机器能有一张网卡共处在一个vlan下。机房环境比较复杂的时候还用DR模式经常会受到各种的约束，比如同一个VLAN的IP都被用光了、同一个交换机下机柜没有空位了，etc。所以实际上我们也经常使用TUN模式。最近遇到一个之前使用DR模式，现在不能扩容的情况，上午就尝试在测试环境测试了一下DR模式到TUN模式的切换，整体影响和LVS主备切换的时候差不多，影响可控。实际的背景是现在LVS1和LVS2做互备给DNS1、DNS2做负载均衡。但是因为找不到机为能和LVS机器挂同一个VLAN下，所以我现在需要把LVS的模式修改为TUN模式，以便对RS直接扩容。机器列表： LVS: 192.168.100.16 LVS1-slave 192.168.100.17 LVS2-slave VIP:192.168.100.8 DNS Server: 192.168.100.18 DNS1 192.168.100.22 DNS2 192.168.100.38 DNS3(NEW) 192.168.128.29 DNS4(NEW) keepalived原来的配置文件： vrrp_instance dns { !state MASTER state BACKUP interface bond0 lvs_sync_daemon_interface bond0 virtual_router_id 51 priority 99 advert_int 1 nopreempt garp_master_delay 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 192.168.100.8/22 dev bond0 label bond0:1 #配置的时候主要掩码不要写错了 } } virtual_server 192.168.100.8 53 { delay_loop 30 lb_algo rr lb_kind DR ha_suspend persistence_timeout 0 protocol TCP real_server 192.168.100.18 53 { weight 100 TCP_CHECK { connect_port 53 connect_timeout 3 nb_get_retry 3 delay_before_retry 10 } ...

前几天看论坛上有人问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之前，建议大家一定仔细看看文档，没有好好看文档就别瞎折腾了。1、http://zh.linuxvirtualserver.org/handbooks2、http://www.linuxvirtualserver.org/Documents.html#manuals

随着开源技术的发展，以及商业设备价格的不断攀升。大公司总是希望能使用开源的方案来替换过去使用的商业设备。比如之前大家用的很多的F5和A10,现在已经在逐步被LVS替换。传统的单个lvs的性能是比不上商业设备的，而且稳定性等也相对会差些。去年淘宝开源了对LVS新增的FULLNAT，并且在公开的PPT里也详细介绍了淘宝使用的架构。基本思路就是把多个LVS组成一个OSPF集群，这样可以使得LVS集群的性能可以远远超过单个传统的商业设备（当然，对于F5等等其实也可以做这样的集群做水平化的扩展） 然后因为LVS上不能做7层的一些操作和ssl卸载，所以下面挂一个nginx或者haproxy就可以做一个全局的负载均衡了。不过关键还是在于要有配套化的维护平台才行。因为使用OSPF协议对到多个LVS机器的连接进行的状态检测，不能针对多个端口，所以最好每个VIP上只使用一个端口。如果一个VIP上使用多个端口的话，会引起一些问题。比如一个LVS访问后端nginx因为自己网络链路的出现问题时，可以使得这个LVS把上面绑定的VIP删除了，这样就不会影响外部用户的访问。但是如果上面帮顶了多个端口的话就很难权衡这样的策略。如果后端的单个APP上是跑了多种程序的，而且相互没有关系（对于公有云来说，其实很多人这样干的，或许习惯了在大公司干活的人不能理解，但是对于小企业来说少用一个服务器能节省成本就少用一个），那么后端所有APP的单个端口如果都挂了，前面的LVS是否删除VIP就比较难判断了，只能是做特殊的策略，如果所有的端口都挂了再回收掉VIP。

记得在学校的时候，使用路由器就会被提示在使用路由器，并且网络也会被断掉。之后有的路由器厂商就使用了一些小的手段来躲避运营商的封杀，但是往往使用了这样的固件的时候就没有办法访问百度了。 上周听了一个分享后才知道背后的原因，百度使用LVS做负载均衡的时候，增加了一个syn-proxy的功能。会对一些不正常的包当作攻击处理。路由厂商一般是把一个get请求的整个包拆分，如一个包的大小是N，那么就先发后面的N-1个包，再发一个大小为1的包。这样运营商就不能做正常的判断进行路由的封杀。但是以前却被百度的lvs给封杀了。现在百度应该是针对这样的情况做了改进，把这样的情况做特例处理了。

负载均衡与高可用本来是个很大的话题，可以做的方式多种多样，我只是把自己熟悉一点的简单讲一些。 bind1. 其实最原始的负载均衡就是在DNS上直接做多个A记录，这样用户解析网站域名的时候就会随机解析为我们设置的一个A记录的IP。但我们不能改变2个IP被解析的概率，如果2个机器的负载能力不同，那这种方式就欠妥了。2. 既然直接A记录不好控制比例，那么我们可以通过bind的view来根据查询源IP做解析。比如把网通的用户解析为网通机房的IP，把电信的用户解析为电信IP，具体的策略设置非常灵活，根据实际情况而定。对于DNS服务器自身的高可用和负载均衡可以使用keepalived打包完成。如果有条件的可以多个DNS机器跑OSPF集群解决。 LVS 一般大家使用keepalived来管理lvs，并能借助keepalived支持的vrrp协议实现HA。对于CDN节点这种类型的话，非常适用与LVS（DR）+[haproxy+squid]，因为单个几点的机器比较少，网络结构不会太负载，而流量又会非常大。直接在一个万兆交换机下挂10多个机器，其中2个做LVS（主/备），另外的所有机器同时部署haproxy和squid，所有机器的squid配置都一样，同时上面跑的haproxy的配置也都一样，backend里面把所有的机器都加进去，这样可以做采用URL hash算法来提高缓存的命中率。但是需要注意此种模式，交换机下的流量会比较大，比不使用haproxy会翻倍，一定要保证交换机的背板带宽够用。LVS相对其他很多负载均衡软件的优势时可以支持UDP，而且DR模式和TUN模式的时候对于大部分业务类型只有用户的请求经过LVS机器，后端服务器响应的内容都是直接返回给用户，所以不会像NAT模式进出的流量都要经过LVS。但是DR和TUN都需要给后端机器绑VIP，比较麻烦。而NAT模式又需要其他机器把LVS机器作为网关，也限制了其使用的范围。相对来说淘宝改的FULLNAT模式部署起来对环境的要求比较低，但是短时间内不会合并到trunk，使用RHEL以外发行版的同学基本不能使用。而且后端机器要获取客户端的IP需要单独安装一个toa的内核模块，因为做了snat后他们只能在一个tcp头的保留字段插入客户的真实IP。 haproxyhaproxy其实是和很成熟的负载均衡软件，4/7通吃，调度算法也非常丰富，配置项目非常多，文档支持也很好，现在也支持了ssl加密了。haproxy因为之前一直采用的tunnel-like模式，所以现在对后端机器开不了keepalive，缺一个非常非常重要的特性。或许在2013年能搞出来。 nginxnginx作为现在最火的webserver，在做代理方面也非常流行，做ssl加密非常方便，配置比起haproxy更加简单和灵活。但是整体而言，不能做4层的反向代理是个遗憾。负载算法方面nginx的不像haproxy有那么多，不过其实一般大家用的最多的还是简单的轮询，流量特别大的网站都是不可能使用wlc算法的，不然机器启动就直接被打暴了。 haproxy和nginx的高可用都需要借助keepalived来做（需要注意改内核参数使备机能直接监听非本地的IP）。当然，如果单个nginx或者haproxy撑不住，也可以使用2层结构，第一层跑LVS，下面一层跑haproxy或者nginx，不过此时VIP都是绑定在第一层的LVS上面。lvs上频繁修改配置reload还是需要注意，不小心搞挂了就悲剧了。 经常见很多论坛，就两三个机器在折腾LVS，问比如遇到RS上不能访问VIP，或者Director上访问不了VIP这些确实比较蛋疼的问题，基本都是没有仔细搞清楚lvs原理，也没有好好看文档的，对于这种我是建议直接跑个haproxy或者nginx就搞定了。