lb-常用的负载均衡软件

一 haproxy

1.1介绍

HAProxy是一个使用C语言编写的自由及开放源代码软件,其提供高可用性、负载均衡,以及基于TCP和HTTP的应用程序代理,官网网站:http://www.haproxy.org/。

haproxy负载均衡的算法有如下7种:Roundrobin,static-rr,source,leastconn,uri,uri_param,hdr()。

1.2 调度算法

https://blog.csdn.net/eddie_cm/article/details/79796883

roundrobin 
基于权重进行轮询,在服务器的处理时间保持均匀分布时,这是最平衡,最公平的算法.此算法是动态的,这表示其权重可以在运行时进行调整.不过在设计上,每个后端服务器仅能最多接受4128个连接 
static-rr 
基于权重进行轮叫,与roundrobin类似,但是为静态方法,在运行时调整其服务器权重不会生效.不过,其在后端服务器连接数上没有限制 
leastconn 
新的连接请求被派发至具有最少连接数目的后端服务器.在有着较长时间会话的场景中推荐使用此算法,如LDAP、SQL等;其并不太适用于较短会话的应用层协议,如HTTP.此算法是动态的,可以在运行时调整其权重 
first 
第一个具有可用连接槽的服务器得到连接.这些服务器将从最小到最大的id选择.一旦一个服务器到达它的最大连接数,下一个服务器将被使用.如果不定义每个服务器的maxconn参数,这个算法是无意义的.使用这个算法的目的是尽量使用最小数量的服务器以便于其他服务器可以在非密集时段待机.这个算法将忽略服务器权重 
source 
将请求的源地址进行hash运算,并由后端服务器的权重总数相除后派发至某匹配的服务器.这可以使得同一个客户端IP的请求始终被派发至某特定的服务器.不过,当服务器权重总数发生变化时,如某服务器宕机或添加了新的服务器,许多客户端的请求可能会被派发至与此前请求不同的服务器.常用于负载均衡无cookie功能的基于TCP的协议.其默认为静态,不过也可以使用hash-type修改此特性 
uri 
对URI的左半部分(“?”标记之前的部分)或整个URI进行hash运算,并由服务器的总权重相除后派发至某匹配的服务器.这可以使得对同一个URI的请求总是被派发至某特定的服务器,除非服务器的权重总数发生了变化.此算法常用于代理缓存或反病毒代理以提高缓存的命中率.需要注意的是,此算法仅应用于HTTP后端服务器场景.其默认为静态算法,不过也可以使用hash-type修改此特性 
url_param 
通过< argument>为URL指定的参数在每个HTTP GET请求中将会被检索.如果找到了指定的参数且其通过等于号”=”被赋予了一个值,那么此值将被执行hash运算并被服务器的总权重相除后派发至某匹配的服务器.此算法可以通过追踪请求中的用户标识进而确保同一个用户ID的请求将被送往同一个特定的服务器,除非服务器的总权重发生了变化.如果某请求中没有出现指定的参数或其没有有效值,则使用轮叫算法对相应请求进行调度.此算法默认为静态的,不过其也可以使用hash-type修改此特性 
hdr(< name>) 
对于每个HTTP请求,通过< name>指定的HTTP首部将会被检索.如果相应的首部没有出现或其没有有效值,则使用轮询算法对相应请求进行调度.其有一个可选选项”use_domain_only”,可在指定检索类似Host类的首部时仅计算域名部分(比如通过www.baidu.com来说,仅计算”baidu”字符串的hash值)以降低hash算法的运算量.此算法默认为静态的,不过其也可以使用hash-type修改此特性 
hash-type < method> < function> < modifier> 
针对每个进行hash运算的算法,都可以指定一个hash-type

< method>:从function中计算的hash中选择服务器的方法 
map-based 
哈希表是一个包含所有活跃服务器的静态数组.哈希将非常流畅,将考虑权重,但它是静态的.当服务器处于启用状态,哈希表将忽略服务器权重的变化.此外,由于服务器是通过在阵列中的位置来选择的,因此当服务器数量发生变化时,大多数映射都会发生更改. 这意味着当服务器启动或关闭时,或者当服务器添加到服务器池时,大多数连接将被重新分配到不同的服务器. 例如,这对缓存会造成很大的影响 
consistent 
一致性哈希算法,将0~2^32-1构成一个环,每个后端服务器生成大量节点平均分配在环的不同位置.将url哈希后的数值以2^32为被除数进行取模,计算后的数值一定在该环的不同位置.数值顺时针旋转遇到的第一个服务器便是选定的服务器.这个散列是动态的,它支持在服务器启动时更改权重.它具有的优点是,当服务器启动或关闭时,只有其关联被移动.将服务器添加到池中时,只有少部分映射被重新分配,使其成为高速缓存的理想方法.但是,由于其原理,分配永远不会很顺畅,有时可能需要调整服务器的权重或ID以获得更均衡的分配.为了在多个负载均衡器上获得相同的分配,重要的是所有服务器都具有完全相同的ID.注意:如果未指定散列函数,则一致散列使用sdbm和avalanche

二 lvs

2.1介绍

LVS的英文全称是Linux Virtual Server,即Linux虚拟服务器。它是我们国家的章文嵩博士的一个开源项目。在linux内存2.6中,它已经成为内核的一部分,在此之前的内核版本则需要重新编译内核。LVS工作模式分为NAT模式、TUN模式、以及DR模式。LVS的调度算法分为两大类:固定调度算法:rr,wrr,dh,sh 和 动态调度算法:wlc,lc,lblc,lblcr。

2.2 三种工作模式

参考 https://blog.csdn.net/weixin_40470303/article/details/80541639
https://blog.csdn.net/Ki8Qzvka6Gz4n450m/article/details/79119665

lvs相关术语

  1. DS:Director Server。指的是前端负载均衡器节点。
  2. RS:Real Server。后端真实的工作服务器。
  3. VIP:向外部直接面向用户请求,作为用户请求的目标的IP地址。
  4. DIP:Director Server IP,主要用于和内部主机通讯的IP地址。
  5. RIP:Real Server IP,后端服务器的IP地址。
  6. CIP:Client IP,访问客户端的IP地址。

1 VS/NAT模式(Network address translation)

这个是通过网络地址转换的方法来实现调度的。首先调度器(LB)接收到客户的请求数据包时(请求的目的IP为VIP),根据调度算法决定将请求发送给哪个后端的真实服务器(RS)。然后调度就把客户端发送的请求数据包的目标IP地址及端口改成后端真实服务器的IP地址(RIP),这样真实服务器(RS)就能够接收到客户的请求数据包了。真实服务器响应完请求后,查看默认路由(NAT模式下我们需要把RS的默认路由设置为LB服务器。)把响应后的数据包发送给LB,LB再接收到响应包后,把包的源地址改成虚拟地址(VIP)然后发送回给客户端。

大致流成:

客户端请求vip----调度器把这个请求转发给rs真实的服务器---rs根据默认路由把包发送给lb调度器----lb再把包的原地址改成vip发送给客户端

优缺点:

#### 1.2.1 NAT技术将请求的报文和响应的报文都需要通过LB进行地址改写,因此网站访问量比较大的时候LB负载均衡调度器有比较大的瓶颈,一般要求最多之能10-20台节点
####1.2.2 只需要在LB上配置一个公网IP地址就可以了。
#### 1.2.3 每台内部的节点服务器的网关地址必须是调度器LB的内网地址。
#### 1.2.4  NAT模式支持对IP地址和端口进行转换。即用户请求的端口和真实服务器的端口可以不一致。

2 DR模式

DR模式是通过改写请求报文的目标MAC地址,将请求发给真实服务器的,而真实服务器响应后的处理结果直接返回给客户端用户。同TUN模式一样,DR模式可以极大的提高集群系统的伸缩性。而且DR模式没有IP隧道的开销,对集群中的真实服务器也没有必要必须支持IP隧道协议的要求。但是要求调度器LB与真实服务器RS都有一块网卡连接到同一物理网段上,必须在同一个局域网环境。
DR模式是互联网使用比较多的一种模式。

2.1 大致流程:

客户端请求vip-->调度器把自己的mac地址改成RS服务器的mac地址-->RS真实服务器直接返回给客户端

2.2 优缺点

特点1:保证前端路由将目标地址为VIP报文统统发给Director Server,而不是RS
RS可以使用私有地址;也可以是公网地址,如果使用公网地址,此时可以通过互联网对RIP进行直接访问
RS跟Director Server必须在同一个物理网络中
所有的请求报文经由Director Server,但响应报文必须不能进过Director Server
不支持地址转换,也不支持端口映射
RS可以是大多数常见的操作系统
RS的网关绝不允许指向DIP(因为我们不允许他经过director)
RS上的lo接口配置VIP的IP地址
缺陷:RS和DS必须在同一机房中

3 TUN模式

virtual server via ip tunneling模式:采用NAT模式时,由于请求和响应的报文必须通过调度器地址重写,当客户请求越来越多时,调度器处理能力将成为瓶颈。为了解决这个问题,调度器把请求的报文通过IP隧道转发到真实的服务器。真实的服务器将响应处理后的数据直接返回给客户端。这样调度器就只处理请求入站报文,由于一般网络服务应答数据比请求报文大很多,采用VS/TUN模式后,集群系统的最大吞吐量可以提高10倍。
VS/TUN的工作流程图如下所示,它和NAT模式不同的是,它在LB和RS之间的传输不用改写IP地址。而是把客户请求包封装在一个IP tunnel里面,然后发送给RS节点服务器,节点服务器接收到之后解开IP tunnel后,进行响应处理。并且直接把包通过自己的外网地址发送给客户不用经过LB服务器。如下图所示:

3.1 请求大致流程

客户端请求---lb接收到请求进行ip tunnel封装---rs服务器根据ip tunnel包头信息得到客户端的请求---rs用自己的公网线路,返回给客户端,原地址是vip

3.2 优缺点

优点:负载均衡器只负责将请求包分发给后端节点服务器,而RS将应答包直接发给用户。所以,减少了负载均衡器的大量数据流动,负载均衡器不再是系统的瓶颈,就能处理很巨大的请求量,这种方式,一台负载均衡器能够为很多RS进行分发。而且跑在公网上就能进行不同地域的分发。

缺点:隧道模式的RS节点需要合法IP,这种方式需要所有的服务器支持”IP Tunneling”(IP Encapsulation)协议,服务器可能只局限在部分Linux系统上。
RIP、VIP、DIP全是公网地址
RS的网关不会也不可能指向DIP
所有的请求报文经由Director Server,但响应报文必须不能进过Director Server
不支持端口映射
RS的系统必须支持隧道
其实企业中最常用的是 DR 实现方式,而 NAT 配置上比较简单和方便

2.3八种调度算法

1.轮叫调度 rr

这种算法是最简单的,就是按依次循环的方式将请求调度到不同的服务器上,该算法最大的特点就是简单。轮询算法假设所有的服务器处理请求的能力都是一样的,调度器会将所有的请求平均分配给每个真实服务器,不管后端 RS 配置和处理能力,非常均衡地分发下去。

2. 加权轮叫 wrr

加权轮训调度,它将依据不同RS的权值分配任务。权值较高的RS将优先获得任务,并且分配到的连接数将比权值低的RS更多。相同权值的RS得到相同数目的连接数

这种算法比 rr 的算法多了一个权重的概念,可以给 RS 设置权重,权重越高,那么分发的请求数越多,权重的取值范围 0 – 100。主要是对rr算法的一种优化和补充, LVS 会考虑每台服务器的性能,并给每台服务器添加要给权值,如果服务器A的权值为1,服务器B的权值为2,则调度到服务器B的请求会是服务器A的2倍。权值越高的服务器,处理的请求越多。

3. 最少链接 lc

最小连接数调度(least-connection),IPVS表存储了所有活动的连接。LB会比较将连接请求发送到当前连接最少的RS.

这个算法会根据后端 RS 的连接数来决定把请求分发给谁,比如 RS1 连接数比 RS2 连接数少,那么请求就优先发给 RS1

4. 加权最少链接 wlc

加权最小连接数调度,假设各台RS的全职依次为Wi,当前tcp连接数依次为Ti,依次去Ti/Wi为最小的RS作为下一个分配的RS

这个算法比 lc 多了一个权重的概念。

5. 基于局部性的最少连接调度算法 lblc

基于地址的最小连接数调度(locality-based least-connection):将来自同一个目的地址的请求分配给同一台RS,此时这台服务器是尚未满负荷的。否则就将这个请求分配给连接数最小的RS,并以它作为下一次分配的首先考虑

这个算法是请求数据包的目标 IP 地址的一种调度算法,该算法先根据请求的目标 IP 地址寻找最近的该目标 IP 地址所有使用的服务器,如果这台服务器依然可用,并且有能力处理该请求,调度器会尽量选择相同的服务器,否则会继续选择其它可行的服务器

6. 复杂的基于局部性最少的连接算法 lblcr

记录的不是要给目标 IP 与一台服务器之间的连接记录,它会维护一个目标 IP 到一组服务器之间的映射关系,防止单点服务器负载过高。

7. 目标地址散列调度算法 dh

该算法是根据目标 IP 地址通过散列函数将目标 IP 与服务器建立映射关系,出现服务器不可用或负载过高的情况下,发往该目标 IP 的请求会固定发给该服务器。

8. 源地址散列调度算法 sh

与目标地址散列调度算法类似,但它是根据源地址散列算法进行静态分配固定的服务器资源

三 nginx

3.1介绍

Nginx是一个网页服务器,它能反向代理HTTP, HTTPS, SMTP, POP3, IMAP的协议链接,以及一个负载均衡器和一个HTTP缓存。Nginx是由伊戈尔·赛索耶夫为俄罗斯访问量第二的Rambler.ru站点开发的,官网网站为http://nginx.org/。
Nginx支持的算法基本有五种算法,分别为round robin(默认),weight, ip_hash,url_hash(第三方),fair(第三方)。

3.2 nginx的常用算法

参考 https://www.cnblogs.com/DarrenChan/p/8967412.html
https://www.cnblogs.com/eddie1127/p/11779778.html

1 round robin(默认)

轮询方式,依次将请求分配到各个后台服务器中,默认的负载均衡方式。
适用于后台机器性能一致的情况。
挂掉的机器可以自动从服务列表中剔除。

upstream backendserver {
server 192.168.0.14:80 max_fails=2 fail_timeout=10s;
server 192.168.0.15:80 max_fails=2 fail_timeout=10s;
 } 

2.weight

根据权重来分发请求到不同的机器中,指定轮询几率,weight和访问比率成正比,用于后端服务器性能不均的情况。
例如:

upstream backendserver { 
server 192.168.0.14:80 weight=5 max_fails=2 fail_timeout=10s; 
server 192.168.0.15:80 weight=10 max_fails=2 fail_timeout=10s;
}

3 IP_hash

根据请求者ip的hash值将请求发送到后台服务器中,可以保证来自同一ip的请求被打到固定的机器上,可以解决session问题

upstream backendserver { 
ip_hash; 
server 192.168.0.14:80 max_fails=2 fail_timeout=10s; 
server 192.168.0.15:80 max_fails=2 fail_timeout=10s; 
} 

经验证客户端访问是按照从上到下依次访问的

4 url_hash(第三方)

https://blog.csdn.net/weixin_34372728/article/details/91526903
需编译安装第三方模块 ngx_http_upstream_hash_module
按访问的URL的哈希结果来分配请求,使每个URL定向到一台后端服务器,可以进一步提高后端缓存服务器的效率。Nginx本身不支持url_hash,如果需要这种调度算法,则必须安装Nginx的hash软件包。
根据请求的url的hash值将请求分到不同的机器中,当后台服务器为缓存的时候效率高。
例如:
在upstream中加入hash语句,server语句中不能写入weight等其他的参数,hash_method是使用的hash算法

upstream backend {    
server squid1:3128;    
server squid2:3128;    
hash $request_uri;    
hash_method crc32;    
}
upstream backendserver { 
server 192.168.0.14:80 max_fails=2 fail_timeout=10s; 
server 192.168.0.15:80 max_fails=2 fail_timeout=10s; 
hash $request_uri;
 }

5 fail(第三方)

https://blog.csdn.net/yu870646595/article/details/52047309 安装方法
https://github.com/gnosek/nginx-upstream-fair 插件下载地址
需编译安装第三方模块 ngx_http_upstream_fair_module
比 weight、ip_hash更加智能的负载均衡算法,fair算法可以根据页面大小和加载时间长短智能地进行负载均衡,也就是根据后端服务器的响应时间 来分配请求,响应时间短的优先分配。Nginx本身不支持fair,如果需要这种调度算法,则必须安装upstream_fair模块

upstream backendserver {
fair; 
server 192.168.0.14:80 max_fails=2 fail_timeout=10s; 
server 192.168.0.15:80 max_fails=2 fail_timeout=10s; 
} 
}  

6 最少连接数 least_conn

特点:按nginx反向代理与后端服务器之间的连接数,连接数最少的优先分配。
适用业务场景:适用于客户端与后端服务器需要保持长连接的业务。

upstream backendserver { 
 least_conn; 
server 192.168.0.14:80 max_fails=2 fail_timeout=10s; 
 server 192.168.0.15:80 max_fails=2 fail_timeout=10s; 
 } 

3.3 调度状态

1.down 表示单前的server暂时不参与负载

2.weight 默认为1.weight越大,负载的权重就越大。

3.max_fails :允许请求失败的次数默认为1.当超过最大次数时,返回proxy_next_upstream 模块定义的错误

4.fail_timeout:max_fails次失败后,暂停的时间。

5.backup: 其它所有的非backup机器down或者忙的时候,请求backup机器。所以这台机器压力会最轻。

nginx支持同时设置多组的负载均衡,用来给不用的server来使用。
client_body_in_file_only 设置为On 可以讲client post过来的数据记录到文件中用来做debug
client_body_temp_path 设置记录文件的目录 可以设置最多3层目录
location 对URL进行匹配.可以进行重定向或者进行新的代理 负载均衡
例如:

upstream bakend{#定义负载均衡设备的Ip及设备状态    
ip_hash;    
server 127.0.0.1:9090 down;    
server 127.0.0.1:8080 weight=2;    
server 127.0.0.1:6060;    
server 127.0.0.1:7070 backup;    
}
posted @ 2020-04-21 18:33  huningfei  阅读(1250)  评论(0编辑  收藏  举报
levels of contents