Haproxy 四/七层负载均衡

1、负载均衡介绍：

正向代理和反向代理：

正向代理：客户端主动使用代理服务器，代表客户端发送请求至目标服务器。此时代理器称为正向代理服务器，

代理服务器隐藏了客户端的真是ip和地址。

反向代理：代理服务器接受并转发到后端服务器的代理服务器，此时代理服务器成为反向代理服务器。客户端发

送请求至反向代理服务器，由反向代理服务器根据需求提供服务或者转发至后端服务器。反向代理隐

藏了后端服务器的真实IP。

1.1 什么是负载均衡

负载均衡：load balance ，简称LB  ，是一种是一种服务或者基于硬件设备等实现高可用的反向代理技术，负载均衡将服务或者流量分担给指定的多个后端服务器或设备，由他们一起来提供和分担服务，从而提高公司的业务水平和并发处理能力，保证了业务的高可用性。

1.2 为什么使用负载均衡

• web服务器的动态水平扩展
• 增加业务并发访问及处理能力——解决单服务器的处理瓶颈问题
• 节约公网IP地址——较低成本
• 隐藏内部服务器IP——提高安全性
• 配置简单——固定的格式文件
• 功能丰富——支持四层和七层，支持动态下线主机
• 性能强悍——并发处理数万甚至数十万

1.3 负载均衡的类型

四层负载均衡

1. 通过ip+port决定负载均衡调度的分配
2. 对流量请求进行NAT处理，转发至后端real server
3. 记录tcp、udp流量分别由那台服务器处理，后续该请求流量将绑定都由该服务器处理。
4. 支持四层的软件
   1. LVS：重量级四层负载均衡器
   2. Nginx：轻量级四层负载均衡器，可缓存
   3. haproxy

 

七层负载均衡

1. 通过虚拟url或主机IP进行流量识别，根据应用层信息进行解析，决定是否需要进行负载均衡
2. 代理后台服务器与客户端建立连接，如nginx可代理前后端与客户端进行tcp连接，与后端服务器建立tcp连接
3. 支持七层的软件
   1. Nginx：基于http协议
   1. haproxy：七层代理，会话保持，标记，路劲转移等

四层与七层的区别：

所谓的四层和七层负载均衡是根据四层或七层的信息来决定如何进行转发流量

四层负载均衡：

通过三层的ip地址加上四层的端口号来决定那些流量需要做负载均衡，对需要处理的流量进行NAT处理     转发至后台服务器，并记录下这个tcp或者udp的流量由那台服务器提供，后续相同的流量都将转发到同一台服务器处理。

七层负载均衡：

是在四层的基础上，在考虑应用层的特征信息决定是否负载均衡。例如web服务器的负载均衡除了通过ip和端口号还可以根据七层的URl、浏览器类别、语言等等决定是否进行负载均衡。

总结：

1. 分层位置：四层负载均衡在传输层以下，七层负载均衡在应用层以下
2. 性能方面：由于四层负载均衡架构不需要解析报文内容，在网络吞吐量和处理能力上比七层要强，但是七层可以支持解析应用层报文内容，识别URL、cookie值、http header等信息
3. 原理：四层负载均衡通过ip和端口号，七层的负载均衡基于虚拟的UrL或主机ip等
4. 功能类比：四层类似于路由器；七层类似于代理服务器
5. 安全性上：四层无法识别DDOS攻击；七层可防御SYN cookie\Flood攻击

3、haproxy七层代理：

解决LVS没有后端监测的，无法判定后端server状态以及无法自动调度到健康服务器的问题！！！

七层负载均衡的功能更为强大，。。。。。

3.1 Haproxy下载

Haproxy -v 查看版本

3.2 haproxy的基本配置信息：global、proxies

haproxy的配置文件haproxy.cfg 由两大部分组成：

Global:全局配置段

• 进程及安全配置相关参数
• 性能调整相关参数
• Debug参数

proxies：代理配置段

• defaults：为frontend、backend、listen 提供默认配置
• frontend：前端，相当于nginx中的server{}
• backend：后端，相当于nginx中的upstream{}
• Listen: 同时拥有前端和后端配置，推荐使用

3.2.1 global全局配置参数说明：

多进程和多线程参数设置

多进程nbproc N 和 多线程nbthread N两个参数是互斥的：

开启多进程：

使用nbproc N 全局参数，并绑定对应的cpu核心，防止核心抖动（来回跳）从而减少资源消耗：

查看多线程信息：pstree -p

开启多线程：

查看线程数：

日志设置

指定日志名：

在rsyslog中添加日志配置：

并打开UDP协议：

3.2.2 proxies 配置

3.2.2.1 defauls 参数配置

3.2.2.2 frontend参数配置

Bind——指定监听地址和端口号，也可用于listen中

3.2.2.3 backend 配置

server配置：！！！ 参数跟在server后

例：

check：对指定server进行健康检查

Addr <ip>：可指定的健康状态监测

Port <num>：指定的健康状态监测端口

Inter <num>：健康状态检查间隔时间，默认2000ms

Fall <num>：后端服务器从线上转为线下的检查的连续失效次数，默认为3

rise <num>：后端服务器从下线恢复上线的检查的连续有效次数，默认为2

Weight <weight> ：默认为1 （1—256）表示不参加负载均衡，但仍接受持久连接

backup：标记服务器为备份状态，只有在所有非备份记住down机时提供服务。

disabled：标记服务器为不可用，即维护状态。

Redirect perfix http://......    ：访问重定向至其他url网址，只适用于http

Redir http://..

Maxconn <n> ：server的最大并发连接数（同一时间的连接数）

3.2.3.4 listen的简化配置

$RANDOM 随机数

 

3.4 socat工具：对haproxy进行调整（临时）

影响范围小，修改后不需要对整个服务进行重启，更改方式方便实现脚本自动化。

修改是临时生效的，重启服务失效

下载：yum install socat

1、修改 /var/lib/haproxy/stats 的权限为S （提权），并重启生效

/etc/haproxy/haproxy.cfg

2、修改方式：

echo "help"  | socat stdio /var/lib/haproxy/stats -----查看帮助

Get 查看参数

Set 进行修改

修改server参数：例disable

3.4.1 针对多线程的修改方法

如果开启多线程那么我们在对进行的sock文件进行操作时其对进程的操作时随机的~

所有如果需要指定操作进程那么需要用多soct文件方式来完成！！！！！！！！！

4、haproxy的算法：静态 2种 动态 3种 其他 4种

通过固定参数balance 指名对后端服务器的调度算法，balance可以配置在listen 或 backend中。

调度分为静态和动态调度算法。

有些算法可以根据参数在静态和动态中转换。

4.1、静态算法：（不支持动态修改socat）

静态算法按照事先定义好的规则轮询公平调度，不关心后端服务器的当前负载和连接数、相应速度。简单说就是不会根据具体情况调整它的调度。且无法实时修改权重值（socat），只能靠重启生效。

4.1.1 static-rr：基于权重的轮询调度

不支持实时修改权重，不支持慢启动。其后端主机数量没有限制，相当于LVS中的wrr。

慢启动：是指在服务器刚刚启动时不会马上把他所应承担的压力全部给他，而是先给一部分，没问题后再给一部分。

配置：该算法就会根据权重以此进行调度（10两次，20一次）

4.1.2 first：自上而下顺序调度

• 根据列表中的位置自上而下以此调度
• 只有当第一台或前一台服务器连接数达到上限才会将请求分配给下一台服务器
• 会忽略服务器的权重设置
• 同样不支持socat实时进行权重修改。

配置：自上而下，忽略权重

4.2、动态算法：（支持动态修改socat）

1、基于后端服务器状态进行适当调整

2、请求将优先调度至负载较低的的服务器

3、支持haproxy的socat动态调整，无需重启

4.2.1 roundrobin : 相比于static-rr 支持实时调整

• 基于权重的轮询动态调度算法
• 支持权重的socat实时调整
• 支持慢启动（会对新加的服务器逐渐增加转发数）
• 其每个后端的backend中最多支持4095个real server
• roundrobin为默认调度算法，应用最为广泛

配置：

在运行时socat更改weight为3，并查看变化

可以发现，次数由2变为了3

4.2.2 leastconn：基于最少连接的动态调度

• Leastconn 加权的最少连接的动态
• 支持权重的调整和慢启动
• 根据当前连接最少的后端服务器而非权重进行优先调度（当有新客户端加入时）
• 比较适合长连接的场景使用，比如mysql

配置：

4.3 其他算法（可以根据参数在静态和动态中转换）

即算静态算法也算动态算法！！！

4.3.1 source ：源地址hash

源地址hash，即同一个源地址的请求会被转发至同一个后端web服务器。

但是当后端服务器发生变化时，会导致很多用户的请求重新调度至新的后端服务器，默认为静态方式。但是也可以通过hash-type支持的选项更改算法。选项方法有两种方式，分别是取模法和一致性hash。

配置：

由于会绑定第一次连接的服务器，所以后续会一直绑定该服务器

4.3.1.1 map-based 取模法 ：（默认）

• 对source地址进行hash计算，在基于服务器总权重的取模，最终决定转发的server
• 此方法时静态的，即不支持实时调整权重，不支持慢启动。
• 缺点是，当服务器总权重发生改变时，即上线或下线，会使调度结果整体都改变。Hash-type默认使用此算法。
• 由于调度改变会导致大部分会话丢失，这里就要使用一致性hash

取模运算：就是计算两个数相除之后的余数 例：10%3=1，20%3=2

配置：

查看访问调度：此时两个客户端访问的都是用一个server

静态修改权重：web2为2，此时客户端1没变，客户端2发生改变

4.3.1.2 一致性hash （consistent）

• 当服务器的总权重发生变化时，对调度的结果影响时局部的，不会引起大的变动。
• 该hash算法是动态的，支持使用socat等工具进行在线权重调整，支持慢启动。

配置：

4.3.2 uri

• 基于用户请求的uri左半部分或整个uri做hash，再将hash结果对总权重取模，决定转发服务器
• 适用于后端是缓存服务器场景
• 默认是静态算法，同样可以选择hash-type算法 map-based 或 consistent
• 只支持mode http模式

Uri 取模法：

Uri 一致性hash：

4.3.3 url_param

• 对用户请求的url 中的params部分中的一个参数key对应的value值做hash计算
• 如果无key，将按roundrobin算法

Url_param 取模法：

Url_param 一致性hash：

4.3.4 hdr

• 针对http头部请求中的指定信息做hash
• 然后有服务器总权重取模以后指定服务器，如果无有效值，则会使用默认的轮询调度

Hdr 取模法：

Hdr 一致性hash：

4.3.6 算法总结

5、高级功能及配置

5.1 基于cookie值的会话保持：

配置选项：

配置：

测试：

5.2 haprixy的状态页：

通过web页面显示当前haproxy的运行状态！！！！

配置选项：

配置：

端口号为8888，uri值为status。账号密码：lee

测试登陆：访问时输入端口号和uri值

页面参数信息：

5.3 IP 透传

服务器正常不会记录客户端的真实地址，但是但web服务器需要记录真是地址时，就需要ip透传

ip透传用于做访问统计、安全防护、行为分析、区域排行等场景。

开启四层透传：

haproxy设置：

nginx服务器设置：

测试：

访问10服务器：

10服务器上查看IP记录：

开启七层透传：

5.5 自定义haproxy错误界面

对指定的报错进行重定向内容，显示自定义的错误页面

两种方式 errorfile 和 errorloc

默认的错误界面页面模板：

5.5.1 errorfile 自定义错误页面文件

当网页进行报错时，会根据报错方式跳转到对应的路径文件位置

添加格式：在/etc/haproxy/haproxy.cfg

errorfile <code> <file>

1、复制模板文件到自定义目录：

2、在haproxy.cfg中添加

例：注意文件路径和文件内容（乱写会报错）

5.5.2 errorloc 基于http的重定向错误页面

当网页进行报错时，会根据报错方式跳转到对应的http网址

添加格式：

Errorloc <code> <url>

例：报错类型+跳转的网址

5.6 haproxy 四层负载（tcp）

针对除http以外的tcp协议应用服务访问的应用场景

MYSQL

Redis

Memcache

RabbitMQ

注意：

如果使用frontend 和 backend ，一定在之间都要指定mode tcp