相比于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 webserverbackend 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 3listen配置方式:
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
daemonnbproc 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模式