OwenJi 2019-12-13
博文目录
一、Haproxy概述
1、HTTP请求
2、负载均衡常用调度算法
3、常见的Web群集调度器
二、Haproxy配置项介绍
1、global配置项通常有下面配置参数:
2、defaults配置项配置默认参数,一般会被应用组件继承,如果在应用组件中没有特别的声明,将安装默认配置参数:
3、listen配置项一般配置应用模块参数:
三、Haproxy的参数优化
Haproxy是目前比较流行的一种群集调度工具,同类群集调度工具有很多,如LVS和Nginx。相比较而言,LVS性能最好,但是搭建相对复杂;Nginx的upstream模块支持群集功能,但是对群集节点健康检查功能不强,性能没有Haproxy好。Haproxy官方网站是http://www.haproxy.org/ 。
通过URL访问网站使用的协议是HTTP协议,此类请求一般称为HTTP请求。HTTP请求的方式分为GET方式和POST方式。
当使用浏览器访问某一个URL,会根据请求URL返回状态码,通常正常的状态码为2 X X、3 X X(如200、301),如果出现异常会返回4 X X、5 X X(如400、500)。例如:访问http://www.test.com/a.php?ld=123 ,就是一个GET请求,如果访问正常,会从服务器的日志中获取200状态码。假如此请求使用POST方式,那么传递给a.php的ld参数依旧是123,但是浏览器的URL将不会显示后面的ld=123字样,因此表单类或者有用户名、密码等内容提交时建议使用POST方式。不管使用哪种方式,最终a.php获取的值是一样的。
LVS、Haproxy、Nginx最常用的调度算法有三种,如下所述:
RR(Round Robin):动态加权轮询算法,支持权重的运行时调整及慢启动机制;最大支持4095个后端主机;在服务器的处理时间平均分配的情况下这是最流畅和公平的算法。该算法是动态的,对于实例启动慢的服务器权重会在运行中调整。
LC(Least Connections): 最小连接数算法,连接数最少的服务器优先接收连接。建议用于长会话场景中使用,例如LDAP、SQL等协议,而不适合短会话协议。如HTTP.该算法是动态的,对于实例启动慢的服务器权重会在运行中调整。
- SH(Source Hashing):源地址哈希算法,对请求源IP地址进行哈希;取模法:将源地址hash计算后除以服务器总权重,服务器变动会影响全局调度效果;根据结果进行分配。只要服务器正常,同一个客户端IP地址总是访问同一个服务器。如果哈希的结果随可用服务器数量而变化,那么客户端会定向到不同的服务器;该算法默认是静态的,所以运行时修改服务器的权重是无效的,但是算法会根据“hash-type”的变化做调整。
该算法一般用于不能插入cookie的Tcp模式。它还可以用于广域网上为拒绝使用会话cookie的客户端提供最有效的粘连;一致性hash:服务器变动仅影响局部调度;动态调度。
目前常见的Web群集调度器分为软件和硬件,软件通常使用开源的LVS、Haproxy、Nginx;硬件一般使用比较多的是F5,也有很多人使用国内的一些产品,如梭子鱼、绿盟等。
Haproxy的配置文件通常分为三个部分:
- global;
- defaults;
- listen;
global为全局配置,defaults为默认配置,listen为应用组件配置。
global log 127.0.0.1 local <!--配置日志记录,local0为日志设备,默认存放到系统日志--> log 127.0.0.1 local1 notice <!--notice为日志级别,通常有24个级别--> #log loghost local0 info maxconn 4096 <!--最大连接数--> chroot /usr/share/haproxy <!--该服务自设置的根目录,一般需将此行注释掉--> uid 99 <!--用户UID--> gid 99 <!--用户GID--> daemon <!--守护进程模式-->
defaults log global <!--定义日志为global配置中的日志定义--> mode http <!--模式为http--> option httplog <!--采用http日志格式记录日志--> option dontlognull retries 3 <!--检查节点服务器失败次数,连续达到三次失败,则认为节点不可用--> redispatch <!--当服务器负载很高时,自动结束当前队列处理比较久的连接--> maxconn 2000 <!--最大连接数--> contimeout 5000 <!--连接超时时间--> clitimeout 50000 <!--客户端超时时间--> srvtimeout 50000 <!--服务器超时时间-->
listen appli4-backup 0.0.0.0:10004 <!--定义一个名为appli4-backup的应用--> option httpchk /index.html <!--检查服务器的index.html文件--> option persist <!--强制将请求发送到已经down掉的服务器,一般禁用此选项--> balance roundrobin <!--负载均衡调度算法使用轮询算法--> server inst1 192.168.114.56:80 check inter 2000 fall 3 <!--定义在线节点--> server inst2 192.168.114.56:81 check inter 2000 fall 3 backup <!--定义备份节点--> <!--注意:在以上定义备份节点的参数中, “check inter 2000”表示haproxy服务器和节点之间的一个心跳率, “fall 3”表示连续三次检测不到心跳频率则认为该节点失效。 节点配置后带有“ backup”表示该节点只是个备份节点, 只有主节点失效该节点才会上。去除backup,表示为主节点, 和其他主节点共同提供服务-->
关于Haproxy的参数优化,以下列举了几个关键的参数,并对各参数的生产环境的优化建议做了说明:
—————— 本文至此结束,感谢阅读 ——————