如何理解Linux下的负载均衡?
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了如何理解Linux下的负载均衡?相关的知识,希望对你有一定的参考价值。
一、目前网站架构一般分成负载均衡层、web层和数据库层,我其实一般还会多加一层,即文件服务器层,因为现在随着网站的PV越来越多,文件服务器的压力也越来越大;不过随着moosefs、DRDB+Heartbeat的日趋成熟,这问题也不大了。网站最前端的负载均衡层称之为Director,它起的是分摊请求的作用,最常见的就是轮询。二、F5是通过硬件的方式来实现负载均衡,它较多应用于CDN系统,用于squid反向加速集群的负载均衡,是专业的硬件负载均衡设备,尤其适用于每秒新建连接数和并发连接数要求高的场景;LVS和nginx是通过软件的方式来实现的,但稳定性也相当强悍,在处理高并发的情况也有相当不俗的表现。
三、Nginx对网络的依赖较小,理论上只要ping得通,网页访问正常,nginx就能连得通,nginx同时还能区分内外网,如果是同时拥有内外网的节点,就相当于单机拥有了备份线路;lvs就比较依赖于网络环境,目前来看服务器在同一网段内并且lvs使用direct方式分流,效果较能得到保证。
四、目前较成熟的负载均衡高可用技术有LVS+Keepalived、Nginx+Keepalived,以前Nginx没有成熟的双机备份方案,但通过shell脚本监控是可以实现的,有兴趣的可具体参考我在51cto上的项目实施方案;另外,如果考虑Nginx的负载均衡高可用,也可以通过DNS轮询的方式来实现,有兴趣的可以参考张宴的相关文章。
五、集群是指负载均衡后面的web集群或tomcat集群等,但现在的集群意义泛指了整个系统架构,它包括了负载均衡器以及后端的应用服务器集群等,现在许多人都喜欢把Linux集群指为LVS,但我觉得严格意义上应该区分开。
六、负载均衡高可用中的高可用指的是实现负载均衡器的HA,即一台负载均衡器坏掉后另一台可以在<1s秒内切换,最常用的软件就是Keepalived和Heatbeat,成熟的生产环境下的负载均衡器方案有Lvs+Keepalived、Nginx+Keepalived.
七、LVS的优势非常多:①抗负载能力强;②工作稳定(因为有成熟的HA方案);③无流量;④基本上能支持所有的应用,基于以上的优点,LVS拥有不少的粉丝;但世事无绝对,LVS对网络的依赖性太大了,在网络环境相对复杂的应用场景中,我不得不放弃它而选用Nginx.
八、Nginx对网络的依赖性小,而且它的正则强大而灵活,强悍的特点吸引了不少人,而且配置也是相当的方便和简约,小中型项目实施中我基本是考虑它的;当然,如果资金充足,F5是不二的选择。
九、大型网站架构中其实可以结合使用F5、LVS或Nginx,选择它们中的二种或三种全部选择;如果因为预算的原因不选择F5,那么网站最前端的指向应该是LVS,也就是DNS的指向应为lvs均衡器,lvs的优点令它非常适合做这个任务。重要的ip地址,最好交由lvs托管,比如数据库的ip、webservice服务器的ip等等,这些ip地址随着时间推移,使用面会越来越大,如果更换ip则故障会接踵而至。所以将这些重要ip交给lvs托管是最为稳妥的。
十、VIP地址是Keepalived虚拟的一个IP,它是一个对外的公开IP,也是DNS指向的IP;所以在设计网站架构时,你必须向你的IDC多申请一个对外IP。
十一、在实际项目实施过程中发现,Lvs和Nginx对https的支持都非常好,尤其是LVS,相对而言处理起来更为简便。
十二、在LVS+Keepalived及Nginx+Keepalived的故障处理中,这二者都是很方便的;如果发生了系统故障或服务器相关故障,即可将DNS指向由它们后端的某台真实web,达到短期处理故障的效果,毕竟广告网站和电子商务网站的PV就是金钱,这也是为什么要将负载均衡高可用设计于此的原因;大型的广告网站我就建议直接上CDN系统了。
十三、现在Linux集群都被大家神话了,其实这个也没多少复杂;关键看你的应用场景,哪种适用就选用哪种,Nginx和LVS、F5都不是神话,哪种方便哪种适用就选用哪种。
十四、另外关于session共享的问题,这也是一个老生长谈的问题了;Nginx可以用ip_hash机制来解决session的问题,而F5和LVS都有会话保持机制来解决这个问题,此外,还可以将session写进数据库,这也是一个解决session共享的好办法,当然这个也会加重数据库的负担,这个看系统架构师的取舍了。
十五、我现在目前维护的电子商务网站并发大约是1000左右,以前的证券资讯类网站是100左右,大型网上广告大约是3000,我感觉web层的并发越来越不是一个问题;现在由于服务器的强悍,再加上Nginx作web的高抗并发性,web层的并发并不是什么大问题;相反而言,文件服务器层和数据库层的压力是越来越大了,单NFS不可能胜任目前的工作,现在好的方案是moosefs和DRDB+Heartbeat+NFS;而我喜欢的mysql服务器,成熟的应用方案还是主从,如果压力过大,我不得不选择oracle的RAC双机方案。
十六、现在受张宴的影响,大家都去玩Nginx了(尤其是作web),其实在服务器性能优异,内存足够的情况下,Apache的抗并发能力并不弱,整个网站的瓶颈应该还是在数据库方面;我建议可以双方面了解Apache和Nginx,前端用Nginx作负载均衡,后端用Apache作web,效果也是相当的好。
十七、Heartbeat的脑裂问题没有想象中那么严重,在线上环境可以考虑使用;DRDB+Heartbeat算是成熟的应用了,建议掌握。我在相当多的场合用此组合来替代EMC共享存储,毕竟30万的价格并不是每个客户都愿意接受的。
十八、无论设计的方案是多么的成熟,还是建议要配置Nagios监控机来实时监控我们的服务器情况;邮件和短信报警都可以开启,毕竟手机可以随身携带嘛;有条件的还可以购买专门的商业扫描网站服务,它会每隔一分钟扫描你的网站,如果发现没有alive会向你的邮件发警告信息或直接电话联系。
十九、至少网站的安全性问题,我建议用硬件防火墙,比较推荐的是华赛三层防火墙+天泰web防火墙,DDOS的安全防护一定要到位;Linux服务器本身的iptables和SElinux均可关闭,当然,端口开放越少越好。 参考技术A Linux下的负载均衡----这跟linux没有关系,操作系统而已。所有操作系统都可以,关键靠软硬件。
负载均衡范围很广,分为系统资源,电力供应,数据读取,网络数据传输,硬盘内存数据传输,
磁盘冗余的,群集负载均衡,问题是你希望在哪方面实现这样的功能。
其实简单点说,当资源或者传输出现重负荷,需要通过各种渠道来平衡,使各种重负荷从点到面。 参考技术B 我空间里面有本回答被提问者采纳 参考技术C WDAOIJDOISFDSF
大型网站架构系列:负载均衡详解
本文是负载均衡详解的第四篇,主要介绍了LVS的三种请求转发模式和八种负载均衡算法,以及Haproxy的特点和负载均衡算法。具体参考文章,详见最后的链接。
三、LVS负载均衡
LVS是一个开源的软件,由毕业于国防科技大学的章文嵩博士于1998年5月创立,用来实现Linux平台下的简单负载均衡。LVS是Linux Virtual Server的缩写,意思是Linux虚拟服务器。
基于IP层的负载均衡调度技术,它在操作系统核心层上,将来自IP层的TCP/UDP请求均衡地转移到不同的 服务器,从而将一组服务器构成一个高性能、高可用的虚拟服务器。
操作系统:Liunx
开发语言:C
并发性能:默认4096,可以修改但需要重新编译。
3.1.功能
LVS的主要功能是实现IP层(网络层)负载均衡,有NAT,TUN,DR三种请求转发模式。
3.1.1LVS/NAT方式的负载均衡集群
NAT是指Network Address Translation,它的转发流程是:Director机器收到外界请求,改写数据包的目标地址,按相应的调度算法将其发送到相应Real Server上,Real Server处理完该请求后,将结果数据包返回到其默认网关,即Director机器上,Director机器再改写数据包的源地址,最后将其返回给外界。这样就完成一次负载调度。
构架一个最简单的LVS/NAT方式的负载均衡集群Real Server可以是任何的操作系统,而且无需做任何特殊的设定,惟一要做的就是将其默认网关指向Director机器。Real Server可以使用局域网的内部IP(192.168.0.0/24)。Director要有两块网卡,一块网卡绑定一个外部IP地址 (10.0.0.1),另一块网卡绑定局域网的内部IP(192.168.0.254),作为Real Server的默认网关。
LVS/NAT方式实现起来最为简单,而且Real Server使用的是内部IP,可以节省Real IP的开销。但因为执行NAT需要重写流经Director的数据包,在速度上有一定延迟;
当用户的请求非常短,而服务器的回应非常大的情况下,会对Director形成很大压力,成为新的瓶颈,从而使整个系统的性能受到限制。
3.1.2LVS/TUN方式的负载均衡集群
TUN是指IP Tunneling,它的转发流程是:Director机器收到外界请求,按相应的调度算法,通过IP隧道发送到相应Real Server,Real Server处理完该请求后,将结果数据包直接返回给客户。至此完成一次负载调度。
最简单的LVS/TUN方式的负载均衡集群架构使用IP Tunneling技术,在Director机器和Real Server机器之间架设一个IP Tunnel,通过IP Tunnel将负载分配到Real Server机器上。Director和Real Server之间的关系比较松散,可以是在同一个网络中,也可以是在不同的网络中,只要两者能够通过IP Tunnel相连就行。收到负载分配的Real Server机器处理完后会直接将反馈数据送回给客户,而不必通过Director机器。实际应用中,服务器必须拥有正式的IP地址用于与客户机直接通信,并且所有服务器必须支持IP隧道协议。
该方式中Director将客户请求分配到不同的Real Server,Real Server处理请求后直接回应给用户,这样Director就只处理客户机与服务器的一半连接,极大地提高了Director的调度处理能力,使集群系统能容纳更多的节点数。另外TUN方式中的Real Server可以在任何LAN或WAN上运行,这样可以构筑跨地域的集群,其应对灾难的能力也更强,但是服务器需要为IP封装付出一定的资源开销,而且后端的Real Server必须是支持IP Tunneling的操作系统。
3.3.3LVS/TUN方式的负载均衡集群
DR是指Direct Routing,它的转发流程是:Director机器收到外界请求,按相应的调度算法将其直接发送到相应Real Server,Real Server处理完该请求后,将结果数据包直接返回给客户,完成一次负载调度。
构架一个最简单的LVS/DR方式的负载均衡集群Real Server和Director都在同一个物理网段中,Director的网卡IP是192.168.0.253,再绑定另一个IP: 192.168.0.254作为对外界的virtual IP,外界客户通过该IP来访问整个集群系统。Real Server在lo上绑定IP:192.168.0.254,同时加入相应的路由。
LVS/DR方式与前面的LVS/TUN方式有些类似,前台的Director机器也是只需要接收和调度外界的请求,而不需要负责返回这些请求的反馈结果,所以能够负载更多的Real Server,提高Director的调度处理能力,使集群系统容纳更多的Real Server。但LVS/DR需要改写请求报文的MAC地址,所以所有服务器必须在同一物理网段内。
3.3架构
LVS架设的服务器集群系统有三个部分组成:最前端的负载均衡层(Loader Balancer),中间的服务器群组层,用Server Array表示,最底层的数据共享存储层,用Shared Storage表示。在用户看来所有的应用都是透明的,用户只是在使用一个虚拟服务器提供的高性能服务。
LVS的体系架构如图:
LVS的各个层次的详细介绍:
Load Balancer层:位于整个集群系统的最前端,有一台或者多台负载调度器(Director Server)组成,LVS模块就安装在Director Server上,而Director的主要作用类似于一个路由器,它含有完成LVS功能所设定的路由表,通过这些路由表把用户的请求分发给Server Array层的应用服务器(Real Server)上。同时,在Director Server上还要安装对Real Server服务的监控模块Ldirectord,此模块用于监测各个Real Server服务的健康状况。在Real Server不可用时把它从LVS路由表中剔除,恢复时重新加入。
Server Array层:由一组实际运行应用服务的机器组成,Real Server可以是WEB服务器、MAIL服务器、FTP服务器、DNS服务器、视频服务器中的一个或者多个,每个Real Server之间通过高速的LAN或分布在各地的WAN相连接。在实际的应用中,Director Server也可以同时兼任Real Server的角色。
Shared Storage层:是为所有Real Server提供共享存储空间和内容一致性的存储区域,在物理上,一般有磁盘阵列设备组成,为了提供内容的一致性,一般可以通过NFS网络文件系统共享数 据,但是NFS在繁忙的业务系统中,性能并不是很好,此时可以采用集群文件系统,例如Red hat的GFS文件系统,oracle提供的OCFS2文件系统等。
从整个LVS结构可以看出,Director Server是整个LVS的核心,目前,用于Director Server的操作系统只能是Linux和FreeBSD,linux2.6内核不用任何设置就可以支持LVS功能,而FreeBSD作为 Director Server的应用还不是很多,性能也不是很好。对于Real Server,几乎可以是所有的系统平台,Linux、windows、Solaris、AIX、BSD系列都能很好的支持。
3.4均衡策略
LVS默认支持八种负载均衡策略,简述如下:
3.4.1.轮询调度(Round Robin)
调度器通过“轮询”调度算法将外部请求按顺序轮流分配到集群中的真实服务器上,它均等地对待每一台服务器,而不管服务器上实际的连接数和系统负载。
3.4.2.加权轮询(Weighted Round Robin)
调度器通过“加权轮询”调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器能处理更多的访问流量。调度器可以自动问询真实服务器的负载情况,并动态地调整其权值。
3.4.3.最少链接(Least Connections)
调度器通过“最少连接”调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能,采用“最小连接”调度算法可以较好地均衡负载。
3.4.4.加权最少链接(Weighted Least Connections)
在集群系统中的服务器性能差异较大的情况下,调度器采用“加权最少链接”调度算法优化负载均衡性能,具有较高权值的服务器将承受较大比例的活动连接负载。调度器可以自动问询真实服务器的负载情况,并动态地调整其权值。
3.4.5.基于局部性的最少链接(Locality-Based Least Connections)
“基于局部性的最少链接”调度算法是针对目标IP地址的负载均衡,目前主要用于Cache集群系统。该算法根据请求的目标IP地址找出该目标IP地址最近使用的服务器,若该服务器是可用的且没有超载,将请求发送到该服务器;若服务器不存在,或者该服务器超载且有服务器处于一半的工作负载,则用“最少链接” 的原则选出一个可用的服务器,将请求发送到该服务器。
3.4.6.带复制的基于局部性最少链接(Locality-Based Least Connections with Replication)
“带复制的基于局部性最少链接”调度算法也是针对目标IP地址的负载均衡,目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个目标IP地址到一组服务器的映射,而LBLC算法维护从一个目标IP地址到一台服务器的映射。该算法根据请求的目标IP地址找出该目标IP地址对应的服务器组,按“最小连接”原则从服务器组中选出一台服务器,若服务器没有超载,将请求发送到该服务器;若服务器超载,则按“最小连接”原则从这个集群中选出一台服务器,将该服务器加入到服务器组中,将请求发送到该服务器。同时,当该服务器组有一段时间没有被修改,将最忙的服务器从服务器组中删除,以降低复制的程度。
3.4.7.目标地址散列(Destination Hashing)
“目标地址散列”调度算法根据请求的目标IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。
3.4.8.源地址散列(Source Hashing)
“源地址散列”调度算法根据请求的源IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。
除具备以上负载均衡算法外,还可以自定义均衡策略。
3.5场景
一般作为入口负载均衡或内部负载均衡,结合反向代理服务器使用。相关架构可参考Ngnix场景架构。
4、HaProxy负载均衡
HAProxy也是使用较多的一款负载均衡软件。HAProxy提供高可用性、负载均衡以及基于TCP和HTTP应用的代理,支持虚拟主机,是免费、快速并且可靠的一种解决方案。特别适用于那些负载特大的web站点。运行模式使得它可以很简单安全的整合到当前的架构中,同时可以保护你的web服务器不被暴露到网络上。
4.1.特点
- 支持两种代理模式:TCP(四层)和HTTP(七层),支持虚拟主机;
- 配置简单,支持url检测后端服务器状态;
- 做负载均衡软件使用,在高并发情况下,处理速度高于nginx;
- TCP层多用于Mysql从(读)服务器负载均衡。 (对Mysql进行负载均衡,对后端的DB节点进行检测和负载均衡)
- 能够补充Nginx的一些缺点比如Session的保持,Cookie引导等工作
4.2.均衡策略
支持四种常用算法:
1.roundrobin:轮询,轮流分配到后端服务器;
2.static-rr:根据后端服务器性能分配;
3.leastconn:最小连接者优先处理;
4.source:根据请求源IP,与Nginx的IP_Hash类似。
五、本次分享总结
以上是本周的分享,从主要讲解了软件负载均衡的应用背景,Ngnix负载均衡,LVS负载均衡,Haproxy负载均衡。
因为时间关系,有些讲解的不细致,大家可以问下度娘/Google,希望本次分享对大家有帮助。
参考资料:
Nginx负载均衡实现原理图解 http://www.server110.com/nginx/201403/7225.html
Nginx架构及其web服务搭建优化配置详解
http://linux.it.net.cn/e/server/nginx/2015/0102/11183.html
Ngnix双主场景:http://network.51cto.com/art/201109/288597.htm
用LVS构架负载均衡Linux集群系统 linux lvs
http://blog.chinaunix.net/uid-45094-id-3012037.html
LVS基本介绍
http://os.51cto.com/art/201202/317108.htm
下次分享时间:下下周12月9日 晚7点30~~8点30见。《大型网站架构系列:分布式消息队列技术》
以上是关于如何理解Linux下的负载均衡?的主要内容,如果未能解决你的问题,请参考以下文章