企业集群平台LVS负载均衡算法分析与实现

一、LVS集群常见架构图

Load
Balancer层:位于整个集群系统的最前端,由一台或多台负载调度器(Director
Server)组成。LVS核心模板IPVS就安装在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的角色。

hared
Storage层:是为所有Real
Server提供共享存储空间和内容一致性的存储区域,一般由磁盘阵列设备组成。,为了提供内容的一致性,一般可以通过NFS网络文件系统共享数据,但是
NFS在繁忙的业务系统中,性能并不是很好,此时可以采用集群文件系统,例如Red hat的GFS文件系统,Oracle提供的OCFS2文件系统等。

从整个LVS结构可以看出,Director Server是整个LVS的核心,目前,用于Director Server的操作系统只有Linux和FreeBSD,Linux 2.6内核完全内置了LVS 的各个模块,不用任何设置就可以支持LVS功能。

对于Real Server,几乎所有的系统平台,Linux、Windows、Solaris、AIX、BSD系列都能很好地支持。

二、负载调度算法


负载均衡技术有很多实现方案,有基于DNS域名轮流解析的方法、有基于客户端调度访问的方法、有基于应用层系统负载的调度方法,还有基于IP地址的调度方法,在这些负载调度算法中,执行效率最高的是IP负载均衡技术。

LVS
的IP负载均衡技术是通过IPVS模块来实现的,IPVS是LVS集群系统的核心软件,它的主要作用是:安装在Director
Server上,同时在Director
Server上虚拟出一个IP地址,用户必须通过这个虚拟的IP地址访问服务器。这个虚拟IP一般称为LVS的VIP,即Virtual
IP。访问的请求首先经过VIP到达负载调度器,然后由负载调度器从Real Server列表中选取一个服务节点响应用户的请求。


用户的请求到达负载调度器后,调度器如何将请求发送到提供服务的Real Server节点,而Real
Server节点如何返回数据给用户,是IPVS实现的重点技术。IPVS实现负载均衡的方式有三种,分别是NAT(FULL
NAT)、TUN和DR,下面进行详细介绍。

三、DR模式


下面是DR模式数据传输图:

DR
模式: 即Virtual Server via Direct
Routing,也就是用直接路由技术实现虚拟服务器。这种方式的连接调度和管理与前两种一样,但它的报文转发方法又有所不同,VS/DR通过改写请求报
文的MAC地址,将请求发送到Real Server,而Real
Server将响应直接返回给客户,免去了VS/TUN中的IP隧道开销。这种方式是三种负载调度方式中性能最好的。

下面是DR模式IP包调度过程图:

原理图简述:

DR
模式将报文直接路由给目标真实服务器。在DR模式中,调度器根据各个真实服务器的负载情况,连接数多少等,动态地选择一台服务器,不修改目标IP地址和目
标端口,也不封装IP报文,而是将请求报文的数据帧的目标MAC地址改为真实服务器的MAC地址。然后再将修改的数据帧在服务器组的局域网上发送。因为数
据帧的MAC地址是真实服务器的MAC地址,并且又在同一个局域网。那么根据局域网的通讯原理,真实复位是一定能够收到由LB发出的数据包。真实服务器接
收到请求数据包的时候,解开IP包头查看到的目标IP是VIP。

此时只有自己的IP符合目标IP才会接收进来,所以我们需要在本地的回环借口上面配置VIP。另:由于网络接口都会进行ARP广播响应,但集群的其他机器都有这个VIP的lo接口,都响应就会冲突。所以我们需要把真实服务器的lo接口的ARP响应关闭掉。

然后真实服务器做成请求响应,之后根据自己的路由信息将这个响应数据包发送回给客户,并且源IP地址还是VIP。

 DR模式小结:

1、通过在调度器LB上修改数据包的目的MAC地址实现转发。注意源地址仍然是CIP,目的地址仍然是VIP地址。

2、请求的报文经过调度器,而RS响应处理后的报文无需经过调度器LB,因此并发访问量大时使用效率很高(和NAT模式比)

3、因为DR模式是通过MAC地址改写机制实现转发,因此所有RS节点和调度器LB只能在一个局域网里面

4、RS主机需要绑定VIP地址在LO接口上,并且需要配置ARP抑制。

5、RS节点的默认网关不需要配置成LB,而是直接配置为上级路由的网关,能让RS直接出网就可以。

6、由于DR模式的调度器仅做MAC地址的改写,所以调度器LB就不能改写目标端口,那么RS服务器就得使用和VIP相同的端口提供服务。

四、NAT/FULL NAT模式

NAT
模式: 即Virtual Server via Network Address
Translation,也就是网络地址翻译技术实现虚拟服务器。当用户请求到达调度器时,调度器将请求报文的目标地址(即虚拟IP地址)改写成选定的
Real Server地址,同时将报文的目标端口也改成选定的Real Server的相应端口,最后将报文请求发送到选定的Real
Server。在服务器端得到数据后,Real
Server将数据返回给用户时,需要再次经过负载调度器将报文的源地址和源端口改成虚拟IP地址和相应端口,然后把数据发送给用户,完成整个负载调度过
程。

下面是NAT模式IP包调度过程图:

原理图简述:

1、客户端请求数据,目标IP为VIP

2、请求数据到达LB服务器,LB根据调度算法将目的地址修改为RIP地址及对应端口(此RIP地址是根据调度算法得出的。)并在连接HASH表中记录下这个连接。

3、数据包从LB服务器到达RS服务器webserver,然后webserver进行响应。Webserver的网关必须是LB,然后将数据返回给LB服务器。

4、收到RS的返回后的数据,根据连接HASH表修改源地址为VIP、目标地址为CIP,及对应端口80.然后数据就从LB出发到达客户端。

5、客户端收到的就只能看到VIP\DIP信息。

NAT模式优缺点:

1、NAT技术将请求的报文和响应的报文都需要通过LB进行地址改写,因此网站访问量比较大的时候LB负载均衡调度器有比较大的瓶颈,一般要求最多之能10-20台节点

2、只需要在LB上配置一个公网IP地址就可以了。

3、每台内部的realserver服务器的网关地址必须是调度器LB的内网地址。

4、NAT模式支持对IP地址和端口进行转换。即用户请求的端口和真实服务器的端口可以不一致。

FULL NAT 模式

FULL NATT的基本原理:

FULL NAT  在client请求VIP 时,不仅替换了package 的dst ip,还替换了package的 src ip;但VIP 返回给client时也替换了src ip。

(1)、首先client 发送请求package给VIP;

(2)、 VIP 收到package后,会根据LVS设置的LB算法选择一个合适的realserver,然后把package 的DST IP 修改为realserver IP;把sorce ip 改成 lvs 集群的LB IP

(3)、 realserver 收到这个package后判断dst ip 是自己,就处理这个package ,处理完后把这个包发送给LVS LB IP。

(4)、 LVS 收到这个package 后把sorce ip改成VIP的IP,dst ip改成 client ip然后发送给client

FULL NAT 模式的注意事项:

FULL NAT 模式也不需要 LBIP 和realserver ip 在同一个网段;

full nat 跟nat 相比的优点是:保证RS回包一定能够回到LVS;因为源地址就是LVS--> 不确定

full nat  因为要更新sorce ip 所以性能正常比nat 模式下降 10%

五、IP TUNNEL模式

TUN
:即Virtual Server via IP Tunneling
也就是通过IP隧道技术实现虚拟服务器。在VS/TUN方式中,调度器采用IP隧道技术将用户请求转发到某个Real Server,而这个Real
Server将直接响应用户的请求,不再经过前端调度器。此外,对Real Server的地域位置没有要求,可以和Director
Server位于同一个网段,也可以在独立的一个网络中。因此,在TUN方式中,调度器将只处理用户的报文请求,从而使集群系统的吞吐量大大提高。

TUN的工作流程图如下所示:


和NAT模式不同的是,它在LB和RS之间的传输不用改写IP地址。而是把客户请求包封装在一个IP
tunnel里面,然后发送给RS节点服务器,节点服务器接收到之后解开IP
tunnel后,进行响应处理。并且直接把包通过自己的外网地址发送给客户不用经过LB服务器。

原理图过程简述:

1、客户请求数据包,目标地址VIP发送到LB上。

2、
LB接收到客户请求包,进行IP Tunnel封装。即在原有的包头加上IP
Tunnel的包头。然后会根据LVS设置的LB算法选择一个合适的realserver;并把client发送的package
包装到一个新的IP包里面;新的IP包的dst是realserver的IP。

3、
RS节点服务器根据IP Tunnel包头信息收到请求包,realserver 收到这个package后判断dst ip
是自己,然后解析出来的package的dst是VIP;会检测我们的网卡上是否绑定了VIP的ip地址;如果绑定了就会处理这个包,如果没有直接丢掉。
我们一般在realserver上面 lo:0 绑定了VIP的ip地址,就可以处理得到客户的请求包并进行响应处理。

4、响应处理完毕之后,RS服务器使用自己的公网线路将这个响应数据包发送给客户端。源IP地址是VIP地址。


IP TUNNEL 模式的注意事项:

TUNNEL 模式必须在所有的realserver 机器上面绑定VIP的IP地址

TUNNEL 模式的vip ------>realserver 的包通信通过TUNNEL 模式,不管是内网和外网都能通信,所以不需要lvs vip跟realserver 在同一个网段内

TUNNEL 模式 realserver会把packet 直接发给client 不会给lvs了

TUNNEL 模式走的隧道模式,所以运维起来比较难,所以一般不用。

六、LVS负载调度算法


Lvs的调度算法决定了如何在集群节点之间分布工作负荷。当director调度器收到来自客户端访问VIP的上的集群服务的入站请求时,director调度器必须决定哪个集群节点应该处理请求。Director调度器用的调度方法基本分为两类:

固定调度算法:rr,wrr,dh,sh

动态调度算法:wlc,lc,lblc,lblcr

LVS调度算法的生产环境选型

1、一般的网络服务,如www,mail,mysql等常用的LVS调度算法为:

a.基本轮询调度rr

b.加权最小连接调度wlc

c.加权轮询调度wrc

2、基于局部性的最小连接lblc和带复制的给予局部性最小连接lblcr主要适用于web cache和DB cache

3、源地址散列调度SH和目标地址散列调度DH可以结合使用在防火墙集群中,可以保证整个系统的出入口唯一。

实际适用中这些算法的适用范围很多,工作中最好参考内核中的连接调度算法的实现原理,然后根据具体的业务需求合理的选型。

本文出自 “爱维Linux” 博客,请务必保留此出处http://ixdba.blog.51cto.com/2895551/1767494

时间: 2024-10-07 14:59:01

企业集群平台LVS负载均衡算法分析与实现的相关文章

【Liinux运维】企业集群平台架构设计与实现

LVS: LVS是Linux Virtual Server的简写,意即Linux虚拟服务器,是一个虚拟的服务器集群系统.本项目在1998年5月由章文嵩博士成立,是中国国内最早出现的自由软件项目之一. haproxy: HAProxy是一个使用C语言编写的自由及开放源代码软件[1],其提供高可用性.负载均衡,以及基于TCP和HTTP的应用程序代理. HAProxy特别适用于那些负载特大的web站点,这些站点通常又需要会话保持或七层处理.HAProxy运行在当前的硬件上,完全可以支持数以万计的并发连

Apache反向代理结合Tomcat集群来实现负载均衡(一)

好的博文一般都能做到"望题知文",看下标题就知道下边要讲的内容,写这个标题时犹豫了一下,本来要将标题定位apache+tomcat实现负载均衡,可是又觉得这样显得比较模糊,后来想了一下,觉得利用Apache做负载均衡底层结合的是tomcat的集群功能,所以便用了这个标题. 首先先做下集群与负载均衡的概念区分,很多人一直都不理解这两个概念,不知道该如何区分这两个概念,又觉得这两个概念仿佛是一个技术的两个术语,其实不然,下边介绍下这两个概念: 什么是集群(Cluster) 所谓集群是指一组

Dubbo之旅--集群容错和负载均衡

当我们的系统中用到Dubbo的集群环境,因为各种原因在集群调用失败时,Dubbo提供了多种容错方案,缺省为failover重试. Dubbo的集群容错在这里想说说他是因为我们实际的项目中出现了此类的问题,因为依赖的第三方项目出现异常,导致dubbo调用超时,此时使用的是默认的集群容错方式,而配置的reties='3',这样前段系统连续掉用了三次服务,结果可想而知. 先说一下各节点关系: 这里的Invoker是Provider的一个可调用Service的抽象,Invoker封装了Provider地

Apache反向代理结合Tomcat集群来实现负载均衡(一)、概念理解

好的博文一般都能做到"望题知文",看下标题就知道下边要讲的内容,写这个标题时犹豫了一下,本来要将标题定位apache+tomcat实现负载均衡,但是又认为这样显得比較模糊.后来想了一下,认为利用Apache做负载均衡底层结合的是tomcat的集群功能.所以便用了这个标题. 首先先做下集群与负载均衡的概念区分,非常多人一直都不理解这两个概念,不知道该怎样区分这两个概念,又认为这两个概念仿佛是一个技术的两个术语,事实上不然,下边介绍下这两个概念: 什么是集群(Cluster) 所谓集群是指

Openfire 集群部署和负载均衡方案

一.   概述 Openfire是在即时通讯中广泛使用的XMPP协议通讯服务器,本方案采用Openfire的Hazelcast插件进行集群部署,采用Haproxy进行负载均衡,在示例环境中测试通过. 二.   示例环境 服务器配置如下: 服务器名 用途 操作系统 IP PC647 Openfire节点1 Windows7 10.200.10.11 seasky Openfire节点2 Windows xp 10.200.10.18 Lub1 Mysql数据库 LUbuntu 12 10.200.

Apache反向代理结合Tomcat集群来实现负载均衡(四)、Apache反向代理

上文中主要介绍了tomcat的集群方式,下边再来说下apache的反向代理.反向代理可以这样来理解,我们通常认为的代理(正向代理)是局域网内部机器本身不能上网,网关可以上网,大家在局域网内是通过网关上网的,这个网关就是个代理机器.反向代理意思就反了过来,现在网关并不是给内部局域网做代理的,而是给外部请求内部局域网做代理的,例如,当前一个应用系统在局域网内的A机器上,外部网络不能直接访问A机器,而是通过网关访问到了A,这里网关就是个反向代理了. 总结:正向代理---为在防火墙内的局域网客户端提供I

ASP.NET Core使用Docker-Swarm集群部署实现负载均衡实战演练

一.需求背景 人生苦短,我用.NET Core!阿笨对Docker是这样评价的:Docker在手,环境我有!Docker出手,集群我有!前面的Doc基础课程我们学习了如何使用Docker来部署搭建单机容器应用.当一台服务器的处理能力.存储空间不足时,不要企图去换更强大的服务器,对大型网站而言,不管多么强大的服务器,都满足不了网站持续增长的业务需求.实践中会发现,生产环境中使用单个 Docker 节点是远远不够的,搭建 Docker 集群势在必行.然而,面对 Kubernetes, Mesos等众

实践出真知——一文教你搭建Nginx+Tomcat集群,实现负载均衡及动静分离

实践出真知--一文教你搭建Nginx+Tomcat集群,实现负载均衡及动静分离 前言 ? 想必大家对于Nginx和Tomcat都非常熟悉了,Nginx的应用非常广泛,不仅是对web静态资源非常友好,而且也是非常实用的反向代理和负载均衡软件.结合后端Tomcat的服务,从而搭建Nginx+Tomcat集群. ? 对于直接想要实践的朋友而言可以获取本文的链接中的软件包后直接看第三备份的内容. 一.集群搭建结构及拓扑 1.1集群架构图示 Nginx+Tomcat集群的结构示意图如下: 1.2系统环境与

企业实战-实现基于LVS负载均衡集群的电商网站架构

实现LVS-DR工作模式: 环境准备:一台centos系统做DR.两台实现过基于LNMP的电子商务网站 机器名称 IP配置 服务角色 备注 lvs-server VIP:172.17.252.110 DIP:172.17.250.223 负载均衡器 开启路由功能 (VIP桥接) rs01 RIP:172.17.251.245 后端服务器 网关指向DIP(桥接) rs02 RIP:172.17.252.87 后端服务器 网关指向DIP(桥接) 实验步骤: 一.安装: 1.yum install i