haproxy七层均衡

一.haproxy的安装和服务信息

1.1实验环境

|--------------------|-------------|
| ip | 实验设备 |
| 172.25.254.100 | haproxy |
| 172.25.254.10 | RS1 |
| 172.25.254.20 | RS2 |
| 172.25.254.111 | client |

1.2软件安装及配置

haproxy主机上配置

#下载

#进入此文件进行编辑

#关闭防火墙

RS1主机上配置

#下载

#生成默认文件

#重启

#关闭防火墙

RS2主机上配置

#下载

#生成默认文件

#重启

#关闭防火墙

client主机上配置

#测试

1.3haproxy****的基本配置信息

官方文档：http://cbonte.github.io/haproxy-dconv/ HAProxy 的配置文件

haproxy.cfg由两大部分组成，分别是：

global：全局配置段

进程及安全配置相关的参数

性能调整相关参数

Debug参数

proxies：代理配置段

defaults：为frontend, backend, listen提供默认配置

frontend：前端，相当于nginx中的server {}

backend：后端，相当于nginx中的upstream {}

listen：同时拥有前端和后端配置,配置简单,生产推荐使用

#查看haproxy多进程或多线程的信息

1.3.1global配值

global配置参数说明

#查看haproxy多进程或多线程的信息

#进入该文件进行编辑

#注意

#每次修改完配置文件进行重启

#多进程模式下（nbproc）

#多线程模式下（nbthread）

1.3.2 proxies配置

1.3.2.1 proxies参数说明proxies

|--------------|-------------|-----------------------------------------------------------------|
| 参数 | 类型 | 作用 |
| defaults | proxies | 默认配置项，针对以下的frontend、backend和listen生效，可以多个 name也可以没有name |
| frontend | proxies | 前端servername，类似于Nginx的一个虚拟主机 server和LVS服务集 群。 |
| backend | proxies | 后端服务器组，等于nginx的upstream和LVS中的RS服务器 |
| listen | proxies | 将frontend和backend合并在一起配置，相对于frontend和backend 配置更简洁，生产常用 |

1.3.2.2 Proxies配置-defaults

参数如下

1.3.3.3 Proxies配置-frontend

frontend****配置参数：

bind：指定HAProxy的监听地址，可以是IPV4或IPV6，可以同时监听多个IP或端口，可同时用于listen字段中

#格式： bind [<address>]:<port_range> [, ...] [param*]

1.3.3.4 Proxies配置-backend

参数解释如图所示

server配置

实验示例：

#测试效果

1.3.3.5 Proxies配置-listen简化配置

使用listen替换 frontend和backend的配置方式，可以简化设置，通常只用于TCP协议的应用

实验示例：

#测试

1.4 socat工具

对服务器动态权重和其它状态可以利用 socat****工具进行调整，Socat 是 Linux 下的一个多功能
的网络工具，名字来由是Socket CAT，相当于netCAT的增强版.Socat 的主要特点就是在两个数据流之间建立双向通道，且支持众多协议和链接方式。如 IP、TCP、 UDP、IPv6、Socket文件等、
#下载

#修改配置文件

#查看haproxy状态

#查看集群状态

#设置权重

两种方式
#在配置文件里面设置权重

#用非交互形式设置权重

#查看集群权重

#下线和上线后端服务器
#下线后端服务器

#上线后端服务器

针对多进程处理方法
如果开启多进程那么我们在对进程的sock文件进行操作时其对进程的操作时随机的
如果需要指定操作进程那么需要用多soct文件方式来完成
实验示例：

#测试

二.haproxy的算法

HAProxy通过固定参数 balance 指明对后端服务器的调度算法
balance参数可以配置在listen或backend选项中。
HAProxy的调度算法分为静态和动态调度算法

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

2.1静态算法

静态算法：按照事先定义好的规则轮询公平调度，不关心后端服务器的当前负载、连接数和响应速度等，且无法实时修改权重(只能为0和1,不支持其它值)，只能靠重启HAProxy生效。

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

不支持运行时利用socat进行权重的动态调整(只支持0和1,不支持其它值)

不支持端服务器慢启动

其后端主机数量没有限制，相当于LVS中的 wrr
慢启动是指在服务器刚刚启动上不会把他所应该承担的访问压力全部给它，而是先给一部分，当没
问题后在给一部分

实验示例：

2.1.2 first

1.根据服务器在列表中的位置，自上而下进行调度

2.其只会当第一台服务器的连接数达到上限，新请求才会分配给下一台服务

3.其会忽略服务器的权重设置

4.不支持用socat进行动态修改权重,可以设置0和1,可以设置其它值但无效

实验示例：

#测试

2.2动态算法

动态算法

基于后端服务器状态进行调度适当调整，

新请求将优先调度至当前负载较低的服务器

权重可以在haproxy运行时动态调整无需重启

2.2.1 roundrobin

1. 基于权重的轮询动态调度算法，

2. 支持权重的运行时调整，不同于lvs中的rr轮训模式，

3. HAProxy中的roundrobin支持慢启动(新加的服务器会逐渐增加转发数)，

4. 其每个后端backend中最多支持4095个real server，

5. 支持对real server权重动态调整，

6. roundrobin为默认调度算法,此算法使用广泛

实验示例

2.2.2 leastconn

leastconn加权的最少连接的动态

支持权重的运行时调整和慢启动，即:根据当前连接最少的后端服务器而非权重进行优先调度(新客户 端连接)

比较适合长连接的场景使用，比如：MySQL等场景。

#测试

2.3其他算法

其它算法即可作为静态算法，又可以通过选项成为动态算法

2.3.1 source

源地址hash，基于用户源地址hash并将请求转发到后端服务器，后续同一个源地址请求将被转发至同一个后端web服务器。此方式当后端服务器数据量发生变化时，会导致很多用户的请求转发至新的后端服务器，默认为静态方式，但是可以通过hash-type支持的选项更改这个算法一般是在不插入Cookie的TCP模式下使用，也可给拒绝会话cookie的客户提供最好的会话粘性，适用于session会话保持但不支持cookie和缓存的场景源地址有两种转发客户端请求到后端服务器的服务器选取计算方式，分别是取模法和一致性hash

2.3.1.1 map-base取模法(静态)

map-based：取模法，对source地址进行hash计算，再基于服务器总权重的取模，最终结果决定将此请求转发至对应的后端服务器。
此方法是静态的，即不支持在线调整权重，不支持慢启动，可实现对后端服务器均衡调度

缺点是当服务器的总权重发生变化时，即有服务器上线或下线，都会因总权重发生变化而导致调度结果整体改变hash-type 指定的默值为此算法

取模法配置示例：

#测试

2.3.1.2一致性hash

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

算法：
1、后端服务器哈希环点keyA=hash(后端服务器虚拟ip)%(2^32)

2、客户机哈希环点key1=hash(client_ip)%(2^32) 得到的值在[0---4294967295]之间
3、将keyA和key1都放在hash环上,将用户请求调度到离key1最近的keyA对应的后端服务器

hash环偏斜问题

增加虚拟服务器IP数量，比如：一个后端服务器根据权重为1生成1000个虚拟IP，再hash。而后端服务器权重为2则生成2000的虚拟IP，再bash,最终在hash环上生成3000个节点，从而解决hash环偏斜问题
一致性hash配置示例：

#测试（注意这个结果虽然一样，但已经转为动态算法）

2.3.2 uri

基于对用户请求的URI的左半部分或整个uri做hash，再将hash结果对总权重进行取模后

根据最终结果将请求转发到后端指定服务器

适用于后端是缓存服务器场景

默认是静态算法，也可以通过hash-type指定map-based和consistent，来定义使用取模法还是一致性

注意：此算法基于应用层，所以只支持 mode http ，不支持 mode tcp

2.3.2.1 uri****取模法配置示例

#在RS2或者RS1添加这两个

2.3.2.2 uri一致性hash****配置示例

#测试

访问不同index

2.3.3 url_param

url_param对用户请求的url中的 params 部分中的一个参数key对应的value值作hash计算，并由服务器 总权重相除以后派发至某挑出的服务器,后端搜索同一个数据会被调度到同一个服务器，多用与电商.

通常用于追踪用户，以确保来自同一个用户的请求始终发往同一个real server

如果无没key，将按roundrobin算法

2.3.3.1 url_param****取模法配置示例

2.3.3.2 url_param一致性hash****配置示例

#在RS2或者RS1添加这两个

#测试

2.3.4 hdr

针对用户每个http头部(header)请求中的指定信息做hash，

此处由 name 指定的http首部将会被取出并做hash计算，

然后由服务器总权重取模以后派发至某挑出的服务器，如果无有效值，则会使用默认的轮询调度。

2.3.4.1 hdr****取模法配置示例

2.3.4.2一致性hash****配置示例#测试

2.3.5算法总结

#静态

static-rr--------->tcp/http

first------------->tcp/http

#动态

roundrobin-------->tcp/http

leastconn--------->tcp/http

random------------>tcp/http

#以下静态和动态取决于hash_type是否consistent

source------------>tcp/http

Uri--------------->http

url_param--------->http

hdr--------------->http

2.3.6****各算法使用场景

first #使用较少

static-rr #做了session共享的web集群

roundrobin

random

leastconn #数据库

source #基于客户端公网IP的会话保持

Uri--------------->http #缓存服务器，CDN服务商，蓝汛、百度、阿里云、腾讯

url_param--------->http #可以实现session保持

hdr · #基于客户端请求报文头部做下一步处理

三.高级功能及配置

3.1基于cookie的会话保持

cookie value：为当前server指定cookie值，实现基于cookie的会话黏性，相对于基于 source 地址hash调度算法对客户端的粒度更精准，但同时也加大了haproxy负载，目前此模式使用较少，已经被session共享服务器代替

注意：不支持 tcp mode，使用 http mode

3.1.1配置选项

cookie name [ rewrite | insert | prefix ][ indirect ] [ nocache ][ postonly ] [ preserve ][ httponly ] [ secure ][ domain ]* [ maxidle <idle> ][ maxlife ]

name： #cookie 的 key名称，用于实现持久连接

insert： #插入新的cookie,默认不插入cookie

indirect： #如果客户端已经有cookie,则不会再发送cookie信息

nocache： #当client和hapoxy之间有缓存服务器（如：CDN）时，不允许中间缓存器缓存

cookie，因为这会导致很多经过同一个CDN的请求都发送到同一台后端服务器

3.1.2配置示例

3.1.3验证cookie信息

#也可以这样

#curl访问时指定cookie

#也可以这样

3.2 HAProxy状态页

通过web界面，显示当前HAProxy的运行状态

3.2.1状态页配置项

3.2.2启用状态页

#进入配置文件编辑

#测试

#浏览器

#自动刷新状态页

#测试

3.3 IP透传

web服务器中需要记录客户端的真实IP地址，用于做访问统计、安全防护、行为分析、区域排行等场景。

3.3.2四层IP透传

实验示例：

#在RS1和RS2上

#测试

#现在haproxy主机上访问一下

#然后再RS2或者RS2上查看日志

3.3.3 七层IP透传

实验示例：

#haproxy主机上

#RS1和RS2主机上配置相同指令（在访问日志中通过变量$proxy_protocol_addr 记录透传过来的客户端IP）

3.4 ACL

访问控制列表ACL，Access Control Lists）

是一种基于包过滤的访问控制技术

它可以根据设定的条件对经过服务器传输的数据包进行过滤(条件匹配)即对接收到的报文进行匹配和过滤，基于请求报文头部中的源地址、源端口、目标地址、目标端口、请求方法、URL、文件后缀等信息内容进行匹配并执行进一步操作，比如允许其通过或丢弃。

实验前期准备

RS1和RS2主机（ 配置一样 ）

client主机配置

#测试是否能连接上

注意事项

实验示例：

#测试

实验示例：

haproxy主机上

RS1主机上

创建文件

#测试

3.4.1 ACL配置选项

3.4.1.1 ACL-Name名称

#ACL名称，可以使用大字母A-Z、小写字母a-z、数字0-9、冒号：、点.、中横线和下划线，并且严格区分大小写，比如:my_acl和My_Acl就是两个完全不同的acl5.8.1.2 ACL-criterion

3.4.1.2 ACL-flags匹配模式

-i 不区分大小写

-m 使用指定的正则表达式匹配方法

-n 不做DNS解析

-u 禁止acl重名，否则多个同名ACL匹配或关系

实验示例：

haproxy主机

RS2和RS1主机上

#测试

3.4.2 ACL示例-基于源IP或子网调度访问

3.4.2.1指定IP访问

实验示例

#测试（haproxy）

#测试（client）

3.4.2.2 拒绝指定ip

实验示例

3.4.3 ACL示例-基于文件后缀名实现动静分离

实验前期准备（RS1和RS2安装PHP）：

RS2主机上配置

#测试（RS2可以登录此界面）

RS1主机上配置（（不能登录）

实验示例：

#测试

3.4.4 ACL-匹配访问路径实现动静分离

实验前期准备（RS1和RS2）：

RS2

RS1

haproxy主机上

#测试

实验示例

#测试

3.5自定义HAProxy错误界面

对指定的报错进行重定向，进行优雅的显示错误页面

使用errorfile和errorloc指令的两种方法，可以实现自定义各种错误页面

实验示例：

#haproxy默认使用的错误错误页面

3.5.1 基于自定义的错误页面文件

#进入该界面文件编写

#再进入此界面编写

#测试

关闭RS1和RS2上的后端

进入浏览器测试

3.6 HAProxy四层负载

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

应用场景有： MySQL， Redis， Memcache ， RabbitMQ

实验示例（MySQL为例）：

（RS1和RS2上）

#下载

#进入此文件（RS2为例）

RS1

#测试（RS2上测试），在RS1上测试结果差不多

注意：此时是不能远程连接的，那么解决这个问题的话就要以下这些步骤

#实验示例（在RS2上）：

#测试（在RS1上远程连接）

#对 MySQL 服务实现四层负载

#测试