HAproxy做七层代理+keepalived高可用,实现动静分离,由nginx处理静态页面,tomcat处理动态页面

2023-12-20 17:59:34

目录

一、三种软负载均衡器的区别

关于三种负载均衡器的性能对比:

关于三种负载均衡器的代理类型对比:

关于三种负载均衡器的健康检查对比:

二、haproxy的8中负载均衡调度算法

haproxy的会话保持的方式

haproxy的配置文件学习

三、实操

前言

1、准备nginx和tomcat的访问页面

2、安装haproxy,修改haproxy的配置文件

步骤一:安装haproxy,编译,安装并完成systemd管理

步骤二:完成haproxy的配置文件修改

步骤三:测试是否可以完成访问

3、另外一台复制一样的haproxy配置(一模一样的配置)

4、安装keepalived,编写haproxy的健康检查脚本,然后修改keepalived的配置文件

5、复制到另一台,一模一样的keepalived服务

6、测试

7、修改haproxy的配置文件,设置基于cookie的会话保持

?编辑

四、完成haproxy的日志分割

五、关于haproxy的内核参数优化


一、三种软负载均衡器的区别

  • 关于三种负载均衡器的性能对比:

LVS是基于内核实现的,他的性能最好;

其次是haproxy,最后是nginx

  • 关于三种负载均衡器的代理类型对比:

LVS只支持基于ip的四层代理转发,也不支持正则匹配;

haproxy和nginx都可以作为四层代理和七层代理,同时都支持正则匹配。

  • 关于三种负载均衡器的健康检查对比:

对于lvs,本身是没有对节点服务器做健康检查的机制,是通过keepalived软件实现的,有三种方式:

  • 发送心跳消息(ping);
  • tcp端口检查(给节点服务器的ip:端口发送tcp连接请求,三次握手成功表明检测健康);
  • http url检测,通过给节点服务器发送http get请求,查看相应的响应状态码,如果是2和3开头,表示健康,如果是4和5开头,表示不健康;

对于nginx,对节点服务器分为被动健康检查和主动健康检查;

  • 被动检查:需要在upstream配置的时候,添加max_fails 允许失败的最大次数和fail_timeout达到失败以后,暂停服务到恢复服务的时间
  • 主动检查:需要借助第三方upstream_check模块,可以动态的去对节点服务器进行健康检查;

对于haproxy来说,它本身支持tcp端口检查,以及http url检查,以及脚本检测

二、haproxy的8中负载均衡调度算法

  • roundrobin 轮询
  • static-rr 加权轮询
  • leastconn 最小连接数
  • source 源地址哈希
  • uri 对于url访问路径哈希缓存
  • url_param ? ? ? ? 根据请求的URL参数哈希
  • hdr(NAME)? 对于请求头做哈希缓存
  • rdp-cookie(NAME) ?根据cookie的key哈希
  • rdp-cookie(NAME) ?根据cookie的key哈希

haproxy的会话保持的方式

HAProxy 提供了3种实现会话保持的方式
1)source(源地址hash)
2)设置cookie
3)会话粘性表stick-table

haproxy的配置文件学习

global		#全局配置,主要用于定义全局参数,属于进程级的配置,通常和操作系统配置有关
    #将info(及以上)的日志发送到rsyslog的local0接口,将warning(及以上)的日志发送到rsyslog的local1接口
    log 127.0.0.1 local0 info
    log 127.0.0.1 local1 warning	
	
    maxconn 30000			            #最大连接数,HAProxy 要求系统的 ulimit -n 参数大于 maxconn*2+18

    #chroot /var/lib/haproxy            #修改haproxy工作目录至指定目录,一般需将此行注释掉
    pidfile     /var/run/haproxy.pid    #指定保存HAProxy进程号的文件
    user haproxy            #以指定的用户名身份运行haproxy进程
    group haproxy           #以指定的组名运行haproxy,以免因权限问题带来风险
    daemon					#让haproxy以守护进程的方式工作于后台
    #nbproc 1				#指定启动的haproxy进程个数,只能用于守护进程模式的haproxy,默认只启动一个进程。haproxy是单进程、事件驱动模型的软件,单进程下工作效率已经非常好,不建议开启多进程
    spread-checks 2         #在haproxy后端有着众多服务器的场景中,在精确的时间间隔后统一对众服务器进行健康状况检查可能会带来意外问题;此选项用于将其检查的时间间隔长度上增加或减小一定的随机时长;默认为0,官方建议设置为2到5之间。

defaults   	#配置默认参数,这些参数可以被用到listen,frontend,backend组件     
    log     global			#所有前端都默认使用global中的日志配置
    mode    http			#模式为http(7层代理http,4层代理tcp)
    option  http-keep-alive #使用keepAlive连接,后端为静态建议使用http-keep-alive,后端为动态应用程序建议使用http-server-close
    option  forwardfor      #记录客户端IP在X-Forwarded-For头域中,haproxy将在发往后端的请求中加上"X-Forwarded-For"首部字段
    option  httplog			#开启httplog,在日志中记录http请求、session信息等。http模式时开启httplog,tcp模式时开启tcplog
    option  dontlognull		#不在日志中记录空连接
    option  redispatch		#当某后端down掉使得haproxy无法转发携带cookie的请求到该后端时,将其转发到别的后端上
    option  abortonclose    #当服务器负载很高的时候,自动结束掉当前队列处理比较久的链接
    maxconn 20000			#最大连接数,“defaults”中的值不能超过“global”段中的定义
    retries 3               #定义连接后端服务器的失败重连次数,连接失败次数超过此值后会将对应后端服务器标记为不可用
    #contimeout 5000        #设置连接超时时间,默认单位是毫秒
    #clitimeout 50000       #设置客户端超时时间,默认单位是毫秒
    #srvtimeout 50000       #设置服务器超时时间,默认单位是毫秒
    timeout http-request 2s 	#默认http请求超时时间,此为等待客户端发送完整请求的最大时长,用于避免类DoS攻击。haproxy总是要求一次请求或响应全部发送完成后才会处理、转发
    timeout queue 3s   	    #默认客户端请求在队列中的最大时长
    timeout connect 1s		#默认haproxy和服务端建立连接的最大时长,新版本中替代contimeout,该参数向后兼容
    timeout client 10s		#默认和客户端保持空闲连接的超时时长,在高并发下可稍微短一点,可设置为10秒以尽快释放连接,新版本中替代clitimeout
    timeout server 2s		#默认和服务端保持空闲连接的超时时长,局域网内建立连接很快,所以尽量设置短一些,特别是高并发时,新版本中替代srvtimeout
    timeout http-keep-alive 10s		#默认和客户端保持长连接的最大时长。优先级高于timeout http-request 也高于timeout client
    timeout check 2s		#和后端服务器成功建立连接后到最终完成检查的最大时长(不包括建立连接的时间,只是读取到检查结果的时长)

frontend http-in    #定义前端域
    bind *:80                        #设置监听地址和端口,指定为*或0.0.0.0时,将监听当前系统的所有IPv4地址
    maxconn 18000                    #定义此端口上的maxconn
	
    acl url_static1   path_beg  -i /static /images                          #定义ACL,当uri以定义的路径开头时,ACL[url_static1]为true
    acl url_static2   path_end  -i .jpg .jpeg .gif .png .html .htm .txt     #定义ACL,当uri以定义的路径结尾时,ACL[url_static2]为true

    use_backend ms1 if url_static1       #当[url_static1]为true时,定向到后端域ms1中
    use_backend ms2 if url_static2       #当[url_static2]为true时,定向到后端域ms2中
    default_backend dynamic_group        #其他情况时,定向到后端域dynamic_group中

backend ms1    #定义后端域ms1
    balance            roundrobin        #使用轮询算法
    option httpchk     GET /test.html   #表示基于http协议来做健康状况检查,只有返回状态码为2xx或3xx的才认为是健康的,其余所有状态码都认为不健康。不设置该选项时,默认采用tcp做健康检查,只要能建立tcp就表示健康。
    server ms1.inst1 192.168.80.100:80 maxconn 5000 check inter 2000 rise 2 fall 3
    server ms1.inst2 192.168.80.100:81 maxconn 5000 check        #同上,inter 2000 rise 2 fall 3是默认值,可以省略

backend ms2    #定义后端域ms2
    balance roundrobin
    option httpchk     GET /test.html
    server ms2.inst1 192.168.80.101:80 maxconn 5000 check
    server ms2.inst2 192.168.80.101:81 maxconn 5000 check

backend dynamic_group    #定义后端域dynamic_group
    balance roundrobin
    option http-server-close
    cookie HA_STICKY_dy insert indirect nocache    
    server appsrv1 192.168.80.100:8080 cookie appsrv1 maxconn 5000 check
    server appsrv2 192.168.80.101:8080 cookie appsrv2 maxconn 5000 check

listen stats    #定义监控页面
    bind *:1080                   #绑定端口1080
    stats enable                  #启用统计报告监控
    stats refresh 30s             #每30秒更新监控数据
    stats uri /stats              #访问监控页面的uri
    stats realm HAProxy\ Stats    #监控页面的认证提示
    stats auth admin:admin        #监控页面的用户名和密码
	
----------------------------------------------------------------------------------------------------------
●balance roundrobin		#负载均衡调度算法
roundrobin:轮询算法;leastconn:最小连接数算法;source:来源访问调度算法,类似于nginx的ip_hash

●check 指定此参数时,HAProxy 将会对此 server 执行健康检查,检查方法在 option httpchk 中配置。同时还可以在 check 后指定 inter, rise, fall 三个参数, 分别代表健康检查的周期、连续几次成功认为 server UP、连续几次失败认为 server DOWN,默认值是 inter 2000 rise 2 fall 3

inter 2000		#表示启用对此后端服务器执行健康检查,设置健康状态检查的时间间隔,单位为毫秒
rise 2			#设定server从离线状态重新上线需要成功检查的次数;不指定默认为2
fall 3			#表示连续三次检测不到心跳频率则认为该节点失效

●cookie:在 backend server 间启用基于 cookie 的会话保持策略,最常用的是 insert 方式。
cookie HA_STICKY_dy insert indirect nocache,指 HAProxy 将在响应中插入名为 HA_STICKY_dy 的 cookie,其值为对应的 server 定义中指定的值,并根据请求中此 cookie 的值决定转发至哪个 server。

indirect    #代表如果请求中已经带有合法的 HA_STICK_dy cookie,则 HAProxy 不会在响应中再次插入此 cookie
nocache     #代表禁止链路上的所有网关和缓存服务器缓存带有 Set-Cookie 头的响应

●若节点配置后带有“backup”表示该节点只是个备份节点,仅在所有在线节点都失效该节点才启用。不携带“backup”,表示为在线节点,和其它在线节点共同提供服务。
----------------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------------
#frontend域和backend域中所有的配置都可以配置在listen域下
listen  webcluster
        bind *:80
        option httpchk GET /test.html
        balance roundrobin
        server inst1 192.168.80.100:80 check inter 2000 rise 2 fall 3
        server inst2 192.168.80.101:80 check inter 2000 rise 2 fall 3
----------------------------------------------------------------------------------------------------------

三、实操

前言

架构图

能实现haproxy的七层负载,同时通过keepalived实现高可用,访问192.168.20.200可以将动态转发给tomcat处理,静态页面交给nginx处理

1、准备nginx和tomcat的访问页面

首先nginx都是访问http://ip/static/index.html

首先tomcat都是访问http://ip/test/123.jsp?

2、安装haproxy,修改haproxy的配置文件

步骤一:安装haproxy,编译,安装并完成systemd管理

#安装haproxy
yum install -y zlib-devel openssl-devel pcre-devel systemd-devel
useradd -M -s /sbin/nologin haproxy

cd /opt
tar xf haproxy-2.8.3.tar.gz
cd /opt/haproxy-2.8.3/

make ARCH=x86_64 TARGET=linux-glibc USE_PCRE=1 USE_OPENSSL=1 USE_ZLIB=1 USE_SYSTEMD=1 
make install PREFIX=/usr/local/haproxy

mkdir /etc/haproxy
cp /opt/haproxy-2.8.3/examples/quick-test.cfg /etc/haproxy/haproxy.cfg

cp /opt/haproxy-2.8.3/examples/haproxy.init /etc/init.d/haproxy
vim /etc/init.d/haproxy
 26 [ "${NETWORKING}" = "no" ] && exit 0
##修改第26行,允许识别字符串变量的值

ln -s /usr/local/haproxy/sbin/haproxy /usr/sbin/
haproxy -v

chmod +x /etc/init.d/haproxy
chkconfig --add /etc/init.d/haproxy
chkconfig --level 35 haproxy on
chkconfig --list haproxy

service haproxy start
netstat -lntp | grep haproxy

步骤二:完成haproxy的配置文件修改

frontend http-in
    bind 0.0.0.0:80
    #maxconn 18000
    acl url_static   path_beg  -i /static
    acl url_dynamic   path_end  -i .jsp

    use_backend static if url_static
    use_backend dynamic if url_dynamic
    default_backend static

backend static
    balance            roundrobin
    option httpchk     GET /test.html
    server static.inst1 192.168.20.10:80 maxconn 5000 check inter 2000 rise 2 fall 3
    server static.inst2 192.168.20.30:80 maxconn 5000 check

backend dynamic
    balance roundrobin
    server dynamic.inst1 192.168.20.8:8080 maxconn 5000 check
    server dynamic.inst2 192.168.20.8:8081 maxconn 5000 check
    server dynamic.inst3 192.168.20.18:8080 maxconn 5000 check


listen stats
    bind *:1080
    stats enable
    stats refresh 30s
    stats uri /stats
    stats realm HAProxy\ Stats

步骤三:测试是否可以完成访问

测试完成

3、另外一台复制一样的haproxy配置(一模一样的配置)

4、安装keepalived,编写haproxy的健康检查脚本,然后修改keepalived的配置文件

[root@localhost keepalived]#ls
check_haproxy.sh  keepalived.conf  keepalived.conf.bak
[root@localhost keepalived]#cat check_haproxy.sh 
#!/bin/bash

netstat -natp|grep haproxy &>/dev/null
if [ $? -ne 0 ];then
  systemctl stop keepalived
fi

?

global_defs {
   notification_email {
     acassen@firewall.loc
     failover@firewall.loc
     sysadmin@firewall.loc
   }
   notification_email_from Alexandre.Cassen@firewall.loc
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id HAPROXY_01
}

vrrp_script check_ha {
    script "/etc/keepalived/check_haproxy.sh"
    interval 2
    weight 1
}

vrrp_instance VI_1 {
    state MASTER
    interface ens33
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    track_script {
        check_ha
}
    virtual_ipaddress {
        192.168.20.200
    }
}

5、复制到另一台,一模一样的keepalived服务

6、测试

测试VIP可以正常使用

此时是可以在两个nginx的静态页面上去相互跳转的?

?

测试健康检查

关闭到/test.html文件,(因为是通过http来对节点服务器做健康检查的)

?此时访问这个页面 将不会再跳转到accp web 同时做了日志分割,这个日志是显示因为健康检查,/test.html文件无法访问,所以该节点服务器不再服务了

当恢复/test.html页面访问服务以后?

通过日志可以看到该节点服务器恢复服务了?

测试高可用 关闭haproxy服务,然后看一下VIP是否会漂移到备上

master服务器

backup服务器?

7、修改haproxy的配置文件,设置基于cookie的会话保持

backend dynamic
    balance roundrobin
    cookie HA_STICKY_dy insert indirect nocache
    server dynamic.inst1 192.168.20.8:8080 cookie app01 maxconn 5000 check
    server dynamic.inst2 192.168.20.8:8081 cookie app02 maxconn 5000 check
    server dynamic.inst3 192.168.20.18:8080 cookie app03 maxconn 5000 check

?

?

?日志分析? 都是分配给同一个节点服务器

?

四、完成haproxy的日志分割

方法一:

----------------------日志定义--------------------------------
#默认 haproxy 的日志是输出到系统的 syslog 中,查看起来不是非常方便,为了更好的管理 haproxy 的日志,我们在生产环境中一般单独定义出来。需要将 haproxy 的 info 及 notice 日志分别记录到不同的日志文件中。

//方法一
vim /etc/haproxy/haproxy.cfg
global
	log /dev/log local0 info
	log /dev/log local0 notice
    ......

defaults
    ......
    log global
    ......

#需要修改rsyslog配置,为了便于管理。将haproxy相关的配置独立定义到haproxy.conf,并放到/etc/rsyslog.d/下,rsyslog启动时会自动加载此目录下的所有配置文件。
vim /etc/rsyslog.d/haproxy.conf
if ($programname == 'haproxy' and $syslogseverity-text == 'info')
then -/var/log/haproxy/haproxy-info.log
&~
if ($programname == 'haproxy' and $syslogseverity-text == 'notice')
then -/var/log/haproxy/haproxy-notice.log
&~

#说明:
这部分配置是将haproxy的info日志记录到/var/log/haproxy/haproxy-info.log下,将notice日志记录到/var/log/haproxy/haproxy-notice.log下。“&~”表示当日志写入到日志文件后,rsyslog停止处理这个信息。

service rsyslog restart
service haproxy restart

tail -f /var/log/haproxy/haproxy-info.log		#查看haproxy的访问请求日志信息

方法二:

//方法二
#修改haproxy.cfg,将info及以上级别的日志发送到rsyslog的local0接口,将warning及以上级别的日志发送到rsyslog的local1接口
vim /etc/haproxy/haproxy.cfg
global
    ......
    log 127.0.0.1 local0 info
    log 127.0.0.1 local1 warning
    ......

defaults
    ......
    log global
    ......

#注:信息级日志会打印HAProxy 的每一条请求处理,会占用大量的磁盘空间,在生产环境中,将日志级别调整为notice


#为 rsyslog 添加 haproxy 日志的配置
mkdir /var/log/haproxy

vim /etc/rsyslog.d/haproxy.conf
$ModLoad imudp
$UDPServerRun 514
$FileCreateMode 0644                               #日志文件的权限
$FileOwner haproxy                                 #日志文件的owner
local0.*     /var/log/haproxy/haproxy.log          #local0接口对应的日志输出文件
local1.*     /var/log/haproxy/haproxy_warn.log     #local1接口对应的日志输出文件

#修改 rsyslog 的启动参数
vim /etc/sysconfig/rsyslog
......
SYSLOGD_OPTIONS="-c 2 -r -m 0"

#重启 rsyslog 和 HAProxy
service rsyslog restart
service haproxy restart

tail -f /var/log/haproxy/haproxy.log

五、关于haproxy的内核参数优化

vim /etc/sysctl.conf
#开启重用。允许将TIME-WAITsockets重用于新的TCP连接,默认0,表示关闭;
net.ipv4.tcp_tw_reuse = 1
#用于向外连接的端口范围。缺省情况下很小
net.ipv4.ip_local_port_range = 1024 65535
#SYN队列长度,记录尚未收到客户端确认信息的连接请求的最大值。默认为1024,加大队列长度可容纳更多等待连接的网络连接数。
net.ipv4.tcp_max_syn_backlog = 10240
#表示系统同时保持TIME_WAIT最大数量,如果超过,TIME_WAIT将立刻被清除并打印警告信息。默认180000,此项参数可控制TIME_WAIT 最大数量
net.ipv4.tcp_max_tw_buckets = 5000
#系统中最多有多少个TCP套接字不被关联到任何一个用户文件句柄上,如超过,连接将即刻被复位并打印警告信息,这个限制仅是为防止简单的DoS攻击,不能过分依靠它或人为减小这个值,更应该增加这个值(如果增加内存后)
net.ipv4.tcp_max_orphans = 3276800
#为打开对端的连接,内核需发送个SYN并附带个回应前一个SYN的ACK。即三次握手中的第二次握手。该设置决定内核放弃连接前发SYN+ACK包的数量。
net.ipv4.tcp_synack_retries = 3
#如web应用中listen函数的backlog默认会给我们内核参数的net.core.somaxconn限制到128,而 nginx 定义的 NGX_LISTEN_BACKLOG 默认511,所以有必要调整这个值。
net.core.somaxconn = 32768


sysctl -p

文章来源:https://blog.csdn.net/liu_xueyin/article/details/135108703
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。