网站负载均衡与高可用方案的选型

负载均衡与高可用本来是个很大的话题,可以做的方式多种多样,我只是把自己熟悉一点的简单讲一些。

bind
1. 其实最原始的负载均衡就是在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。

haproxy
haproxy其实是和很成熟的负载均衡软件,4/7通吃,调度算法也非常丰富,配置项目非常多,文档支持也很好,现在也支持了ssl加密了。haproxy因为之前一直采用的tunnel-like模式,所以现在对后端机器开不了keepalive,缺一个非常非常重要的特性。或许在2013年能搞出来。

nginx
nginx作为现在最火的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就搞定了。

此条目发表在Haproxy, keepalived, lvs分类目录。将固定链接加入收藏夹。

发表评论