网站负载均衡与高可用方案的选型
负载均衡与高可用本来是个很大的话题，可以做的方式多种多样，我只是把自己熟悉一点的简单讲一些。 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就搞定了。