HAproxy

发布于:2025-07-26 ⋅ 阅读:(13) ⋅ 点赞:(0)

相比于lvs,haproxy可以对与后端服务器进行健康检查,当后端某台服务器宕机后,可以将流量转移到另一台服务器上。但lvs是集成在内核上的负载均衡,不需要依赖软件。

haproxy四层与七层负载均衡:

四层:

基于TCP/UDP协议,基于ip和端口的负载均衡,客户端与后端真实服务器建立网络通信

七层:

基于http/https协议,客户端与负载调度器建立连接,负载调度器与后端真实服务器建立连接

两个连接都是独立的,可以对报文进行分析

负载均衡方式:

硬件:

软件:

haproxy配置文件解析:

global全局配置:

proxies代理配置:

haproxy算法:

静态算法:

按照预先定义的规则进行流量的调度,不支持热更新,也不会考虑服务器的负载,连接数和响应速度,不支持,慢启动等等。

慢启动:当后端一台服务器挂了又重新上线后,先将流量一点一点打到给服务器上,逐渐增加流量

static-rr:基于权重的轮询调度。相当于lvs中的wrr

first:根据服务器列表由上而下调度。当第一天台服务器满了再调度到第二台服务器上

动态算法:

roundrobin(默认):可以对real server进行动态的权值调正,支持慢启动,每个backend后端做多支持4053个真实的server

leastconn:加权最小连接,根据当前连接最小最小的服务器进行分配流量

其他算法:

可以配置某些参数实现成为动态算法

source:源地址hash,不支持scaot热更新

        base-map取模法(静态):

                源地址ip经过hash运算后得到一个值,用该值对后端真实服务器总权值进行取模,得到数字几就将该流量分发到第几台服务器。

                例如:后端四台服务器权重都是1,现有三个请求,源地址经过hash运算后分别是100,111,112那么,100%4......0,111%4.....1,112%4.....2以此类推,该三个请求分别会被调度到第0台,第1台和第2台服务器上。缺点:当某一台服务器宕机(权重发生改变)或人为改变权重值时就会导致整个所有请求的取模值发生改变,所有流量都会选取新的服务器

       一致性hash(动态)

        解决:hash-type   consistent(动态hash)

        hash环:环点从0-2^32-1,后端真实服务器所在环点(后端服务器ip%2^32)取模。前端流量所在环点(计算得到的hash值%2^32)取模。之后按照逆时针方向就近选取后端真实服务器。    优点:当后台服务器宕机后,只有少量请求会出现服务器波动,不会影响整体服务。

uri:基于url的算法,根据流量的url选择特定服务器

   测试:访问index1.html时流量到142上,访问index2.html时流量到144上

     

url-param:

 https://search.jd.com/Search?keyword=4090(?后面是param值)

测试:name值位111时访问144,name值为222时访问142

hdr:基于url头部算法

例如基于浏览器的流量分发:

测试:curl  -vA  "aa"  192.168.79.134----指定浏览器进行访问

简单的负载均衡配置:

实验环境:

一台客户机

一台haproxy

两台后端做web服务(nginx)

haproxy简单配置:

前后端配置方式:

frontend web-80
        bind *:80
        mode tcp
        balance roundrobin
        use_backend webserver

backend webserver
        server web1 192.168.79.142:80 check inter 5 fall 3 rise 3
        server web2 192.168.79.144:80 check inter 5 fall 3 rise 3

listen配置方式:

 listen web-80
        bind *:80
        mode tcp
        balance roundrobin
        server web1 192.168.79.142:80 check inter 5 fall 3 rise 3
        server web2 192.168.79.144:80 check inter 5 fall 3 rise 3

客户端测试:

热更改:在服务器不停服的情况下进行服务器的更改----scaot

haproxy多进程与多线程:

多进程配置

查看cpu内核:cat /proc/cpuinfo

    log         127.0.0.1 local2

    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     4000
    user        haproxy
    group       haproxy
    daemon

    nbproc 2------开启多进程
    cpu-map 1 0------第一个进程绑定第0个cpu
    cpu-map 2 1------第二个进程绑定第1个cpu

防止cpu切换引起延迟,提升服务器性能延迟

使用pstree命令查看

pstree -u----查看进程所属者

pstree  -a---查看进程命令参数

pstree  -p---查看进程id

haproxy在开启后会启动一个主进程,由于配置了多进程和cpu绑定,因此会在主进程下再次开启两个子进程 

多线程配置

注:多进程与多线程不可以同时存在

查看进程状态:cat  /proc/2262/status

在该进程下只有一个线程(默认也只有一个)

配置nbthread参数

 

 cat /proc/2390/status

错误页面访问:

当后端主机全部下线后,调度器将流量调度到错误页面。

本实验配置在haproxy调度器上,由于80端口已经被占用,于是开启8080端口配置错误页面,也可以新开一台后端用于提供错误页面访问

 

强制某一台后端下线:disabled

配置disabled参数,强制某一台后端下线

url重定向 :redirect  prefix

将流量重新调度到其他url上,只能用于http模式

在浏览器上访问:

 如果后端与重定向参数同时开启,流量同样会被调度到新的url上

 基于cookie的会话:

当流量请求来到调度器时,会给该流量发送cookie值,当用户接受该cookie值时,下次流量就会发送到指定的后端服务器。解决源地址hash,source大量流量请求问题。但是不支持tcp模式,只支持http模式。

配置;

cookie  name  +选项

name:cookie的名字,用于实现持久连接

insert:插入新的cookie

indirect:如果客户端有cookie,则不再发送cookie---节省开销

nocache:如果客户端与调度器之间有缓存服务器(CDN),不允许中间缓存服务器存放cookie。

                客户机访问CDN,CDN连接调度器,如果CDN上存在cookie值,那么达到CDN的流量就会全部流向某一台服务器,导致灾难性的流量

 

 测试:curl  -b(指定cookie值)  WEBCOOKIE=weba 192.168.79.134

 配置haproxy状态页:

 

haproxyACL访问控制:

 访问域名www.hx.com流量走web-cluster,访问其他内容,流量走cluster2

测试:客户机配置域名解析.ip为负载调度器

 

 访问包含a的流量走cluster1,其余走cluster2

-m 模糊匹配,sub包含

 

 haproxy的IP透传:四层

haproxy上配置option forwardfor ,mode  tcp

 realserver上在nginx主配置文件下加上' "$proxy_protocol_addr"'(日志格式,采集代理端ip)

 listen       80 proxy_protocol(走四层不走七层)
查看日志文件

七层透传:将mode改成http模式


网站公告

今日签到

点亮在社区的每一天
去签到