HAProxy是什么
HAProxy是一个收费的负载平衡软件,能够运行于大部分支流的Linux操作系统上。
HAProxy提供了L4(TCP)和L7(HTTP)两种负载平衡能力,具备丰盛的性能。HAProxy的社区十分沉闷,版本更新疾速(最新稳定版1.7.2于2017/01/13推出)。最要害的是,HAProxy具备媲美商用负载均衡器的性能和稳定性。
因为HAProxy的上述长处,它以后不仅仅是收费负载平衡软件的首选,更简直成为了惟一抉择。
HAProxy的外围性能
- 负载平衡:L4和L7两种模式,反对RR/动态RR/LC/IP Hash/URI Hash/URL_PARAM Hash/HTTP_HEADER Hash等丰盛的负载平衡算法
- 健康检查:反对TCP和HTTP两种健康检查模式
- 会话放弃:对于未实现会话共享的利用集群,可通过Insert Cookie/Rewrite Cookie/Prefix Cookie,以及上述的多种Hash形式实现会话放弃
- SSL:HAProxy能够解析HTTPS协定,并可能将申请解密为HTTP后向后端传输
- HTTP申请重写与重定向
- 监控与统计:HAProxy提供了基于Web的统计信息页面,展示衰弱状态和流量数据。基于此性能,使用者能够开发监控程序来监控HAProxy的状态
HAProxy的要害个性
性能
- 采纳单线程、事件驱动、非阻塞模型,缩小上下文切换的耗费,能在1ms内解决数百个申请。并且每个会话只占用数KB的内存。
- 大量精密的性能优化,如O(1)复杂度的事件查看器、提早更新技术、Single-buffereing、Zero-copy forwarding等等,这些技术使得HAProxy在中等负载下只占用极低的CPU资源。
- HAProxy大量利用操作系统自身的性能个性,使得其在解决申请时能施展极高的性能,通常状况下,HAProxy本身只占用15%的解决工夫,残余的85%都是在零碎内核层实现的。
- HAProxy作者在8年前(2009)年应用1.4版本进行了一次测试,单个HAProxy过程的解决能力冲破了10万申请/秒,并轻松占满了10Gbps的网络带宽。
稳定性
作为倡议以单过程模式运行的程序,HAProxy对稳定性的要求是非常严苛的。依照作者的说法,HAProxy在13年间从未呈现过一个会导致其解体的BUG,HAProxy一旦胜利启动,除非操作系统或硬件故障,否则就不会解体(我感觉可能多少还是有夸张的成分)。
在上文中提到过,HAProxy的大部分工作都是在操作系统内核实现的,所以HAProxy的稳定性次要依赖于操作系统,作者倡议应用2.6或3.x的Linux内核,对sysctls参数进行精密的优化,并且确保主机有足够的内存。这样HAProxy就可能继续满负载稳固运行数年之久。
集体的倡议:
- 应用3.x内核的Linux操作系统运行HAProxy
- 运行HAProxy的主机上不要部署其余的利用,确保HAProxy独占资源,同时防止其余利用引发操作系统或主机的故障
- 至多为HAProxy装备一台备机,以应答主机硬件故障、断电等突发状况(搭建双活HAProxy的办法在后文中有形容)
- sysctl的倡议配置(并不是万用配置,依然须要针对具体情况进行更精密的调整,但能够作为首次应用HAProxy的初始配置应用):
net.ipv4.tcp_tw_reuse = 1 net.ipv4.ip_local_port_range = 1024 65023 net.ipv4.tcp_max_syn_backlog = 10240 net.ipv4.tcp_max_tw_buckets = 400000 net.ipv4.tcp_max_orphans = 60000 net.ipv4.tcp_synack_retries = 3 net.core.somaxconn = 10000
HAProxy的装置和运行
上面介绍在CentOS7中装置和运行HAProxy最新稳定版(1.7.2)的办法
装置
为HAProxy创立用户和用户组,此例中用户和用户组都是”ha”。留神,如果想要让HAProxy监听1024以下的端口,则须要以root用户来启动
下载并解压
wget http://www.haproxy.org/download/1.7/src/haproxy-1.7.2.tar.gz tar -xzf haproxy-1.7.2.tar.gz
编译并装置
make PREFIX=/home/ha/haproxy TARGET=linux2628 make install PREFIX=/home/ha/haproxy
PREFIX为指定的装置门路,TARGET则依据以后操作系统内核版本指定:
- linux22 for Linux 2.2 - linux24 for Linux 2.4 and above (default) - linux24e for Linux 2.4 with support for a working epoll (> 0.21) - linux26 for Linux 2.6 and above - linux2628 for Linux 2.6.28, 3.x, and above (enables splice and tproxy)
此例中,咱们的操作系统内核版本为3.10.0,所以TARGET指定为linux2628
创立HAProxy配置文件
mkdir -p /home/ha/haproxy/conf vi /home/ha/haproxy/conf/haproxy.cfg
咱们先创立一个最简略配置文件:
global #全局属性 daemon #以daemon形式在后盾运行 maxconn 256 #最大同时256连贯 pidfile /home/ha/haproxy/conf/haproxy.pid #指定保留HAProxy过程号的文件 defaults #默认参数 mode http #http模式 timeout connect 5000ms #连贯server端超时5s timeout client 50000ms #客户端响应超时50s timeout server 50000ms #server端响应超时50s frontend http-in #前端服务http-in bind *:8080 #监听8080端口 default_backend servers #申请转发至名为"servers"的后端服务 backend servers #后端服务servers server server1 127.0.0.1:8000 maxconn 32 #backend servers中只有一个后端服务,名字叫server1,起在本机的8000端口,HAProxy同时最多向这个服务发动32个连贯
留神:HAProxy要求零碎的ulimit -n参数大于[maxconn*2+18],在设置较大的maxconn时,留神查看并批改ulimit -n参数
将HAProxy注册为零碎服务
在/etc/init.d目录下增加HAProxy服务的启停脚本:
vi /etc/init.d/haproxy #! /bin/sh set -e PATH=/sbin:/bin:/usr/sbin:/usr/bin:/home/ha/haproxy/sbin PROGDIR=/home/ha/haproxy PROGNAME=haproxy DAEMON=$PROGDIR/sbin/$PROGNAME CONFIG=$PROGDIR/conf/$PROGNAME.cfg PIDFILE=$PROGDIR/conf/$PROGNAME.pid DESC="HAProxy daemon" SCRIPTNAME=/etc/init.d/$PROGNAME # Gracefully exit if the package has been removed. test -x $DAEMON || exit 0 start() { echo -e "Starting $DESC: $PROGNAMEn" $DAEMON -f $CONFIG echo "." } stop() { echo -e "Stopping $DESC: $PROGNAMEn" haproxy_pid="$(cat $PIDFILE)" kill $haproxy_pid echo "." } restart() { echo -e "Restarting $DESC: $PROGNAMEn" $DAEMON -f $CONFIG -p $PIDFILE -sf $(cat $PIDFILE) echo "." } case "$1" in start) start ;; stop) stop ;; restart) restart ;; *) echo "Usage: $SCRIPTNAME {start|stop|restart}" >&2 exit 1 ;; esac exit 0
运行
启动、进行和重启:
service haproxy start service haproxy stop service haproxy restart
增加日志
HAProxy不会间接输入文件日志,所以咱们要借助Linux的rsyslog来让HAProxy输入日志
批改haproxy.cfg
在global域和defaults域中增加:
global ... log 127.0.0.1 local0 info log 127.0.0.1 local1 warning ... defaults ... log global ...
意思是将info级(及以上)的日志推送到rsyslog的local0接口,将warn级(及以上)的日志推送到rsyslog的local1接口,并且所有frontend都默认应用global中的日志配置。
注:info级的日志会打印HAProxy解决的每一条申请,会占用很大的磁盘空间,在生产环境中,倡议将日志级别调整为notice
为rsyslog增加haproxy日志的配置
vi /etc/rsyslog.d/haproxy.conf $ModLoad imudp $UDPServerRun 514 $FileCreateMode 0644 #日志文件的权限 $FileOwner ha #日志文件的owner local0.* /var/log/haproxy.log #local0接口对应的日志输入文件 local1.* /var/log/haproxy_warn.log #local1接口对应的日志输入文件
批改rsyslog的启动参数
vi /etc/sysconfig/rsyslog # Options for rsyslogd # Syslogd options are deprecated since rsyslog v3. # If you want to use them, switch to compatibility mode 2 by "-c 2" # See rsyslogd(8) for more details SYSLOGD_OPTIONS="-c 2 -r -m 0"
重启rsyslog和HAProxy
service rsyslog restart service haproxy restart
此时就应该能在/var/log目录下看到haproxy的日志文件了
用logrotate进行日志切分
通过rsyslog输入的日志是不会进行切分的,所以须要依附Linux提供的logrotate(Linux零碎Logrotate服务介绍)来进行切分工作
应用root用户,创立haproxy日志切分配置文件:
mkdir /root/logrotate vi /root/logrotate/haproxy /var/log/haproxy.log /var/log/haproxy_warn.log { #切分的两个文件名 daily #按天切分 rotate 7 #保留7份 create 0644 ha ha #创立新文件的权限、用户、用户组 compress #压缩旧日志 delaycompress #提早一天压缩 missingok #疏忽文件不存在的谬误 dateext #旧日志加上日志后缀 sharedscripts #切分后的重启脚本只运行一次 postrotate #切分后运行脚本重载rsyslog,让rsyslog向新的日志文件中输入日志 /bin/kill -HUP $(/bin/cat /var/run/syslogd.pid 2>/dev/null) &>/dev/null endscript }
并配置在crontab中运行:
0 0 * * * /usr/sbin/logrotate /root/logrotate/haproxy
HAProxy搭建L7负载均衡器
总体方案
本节中,咱们将应用HAProxy搭建一个L7负载均衡器,利用如下性能
- 负载平衡
- 会话放弃
- 健康检查
- 依据URI前缀向不同的后端集群转发
- 监控页面
架构如下:
架构中共有6个后端服务,划分为3组,每组中2个服务:
- ms1:服务URI前缀为ms1/的申请
- ms2:服务URI前缀为ms2/的申请
- def:服务其余申请
搭建后端服务
部署6个后端服务,能够应用任意的Web服务,如Nginx、Apache HTTPD、Tomcat、Jetty等,具体Web服务的装置过程省略。
此例中,咱们在192.168.8.111和192.168.8.112两台主机上别离装置了3个Nginx:
ms1.srv1 - 192.168.8.111:8080 ms1.srv2 - 192.168.8.112:8080 ms2.srv1 - 192.168.8.111:8081 ms2.srv2 - 192.168.8.112:8081 def.srv1 - 192.168.8.111:8082 def.srv2 - 192.168.8.112:8082
在这6个Nginx服务别离部署健康检查页面healthCheck.html,页面内容任意。确保通过http://ip:port/healthCheck.ht…
接下来在6个Nginx服务中部署服务页面:
- 在第一组中部署ms1/demo.html
- 在第二组中部署ms2/demo.html
- 在第三组中部署def/demo.html
demo.html的内容,以部署在192.168.8.111:8080上的为例:
Hello! This is ms1.srv1!
部署在192.168.8.112:8080上的就应该是
Hello! This is ms1.srv2!
以此类推
搭建HAProxy
在192.168.8.110主机装置HAProxy,HAProxy的装置和配置步骤如上一章中形容,此处略去。
HAProxy配置文件:
global daemon maxconn 30000 #ulimit -n至多为60018 user ha pidfile /home/ha/haproxy/conf/haproxy.pid log 127.0.0.1 local0 info log 127.0.0.1 local1 warning defaults mode http log global option http-keep-alive #应用keepAlive连贯 option forwardfor #记录客户端IP在X-Forwarded-For头域中 option httplog #开启httplog,HAProxy会记录更丰盛的申请信息 timeout connect 5000ms timeout client 10000ms timeout server 50000ms timeout http-request 20000ms #从连贯创立开始到从客户端读取残缺HTTP申请的超时工夫,用于防止类DoS攻打 option httpchk GET /healthCheck.html #定义默认的健康检查策略 frontend http-in bind *:9001 maxconn 30000 #定义此端口上的maxconn acl url_ms1 path_beg -i /ms1/ #定义ACL,当uri以/ms1/结尾时,ACL[url_ms1]为true acl url_ms2 path_beg -i /ms2/ #同上,url_ms2 use_backend ms1 if url_ms1 #当[url_ms1]为true时,定向到后端服务群ms1中 use_backend ms2 if url_ms2 #当[url_ms2]为true时,定向到后端服务群ms2中 default_backend default_servers #其余状况时,定向到后端服务群default_servers中 backend ms1 #定义后端服务群ms1 balance roundrobin #应用RR负载平衡算法 cookie HA_STICKY_ms1 insert indirect nocache #会话放弃策略,insert名为"HA_STICKY_ms1"的cookie #定义后端server[ms1.srv1],申请定向到该server时会在响应中写入cookie值[ms1.srv1] #针对此server的maxconn设置为300 #利用默认健康检查策略,健康检查距离和超时工夫为2000ms,两次胜利视为节点UP,三次失败视为节点DOWN server ms1.srv1 192.168.8.111:8080 cookie ms1.srv1 maxconn 300 check inter 2000ms rise 2 fall 3 #同上,inter 2000ms rise 2 fall 3是默认值,能够省略 server ms1.srv2 192.168.8.112:8080 cookie ms1.srv2 maxconn 300 check backend ms2 #定义后端服务群ms2 balance roundrobin cookie HA_STICKY_ms2 insert indirect nocache server ms2.srv1 192.168.8.111:8081 cookie ms2.srv1 maxconn 300 check server ms2.srv2 192.168.8.112:8081 cookie ms2.srv2 maxconn 300 check backend default_servers #定义后端服务群default_servers balance roundrobin cookie HA_STICKY_def insert indirect nocache server def.srv1 192.168.8.111:8082 cookie def.srv1 maxconn 300 check server def.srv2 192.168.8.112:8082 cookie def.srv2 maxconn 300 check listen stats #定义监控页面 bind *:1080 #绑定端口1080 stats refresh 30s #每30秒更新监控数据 stats uri /stats #拜访监控页面的uri stats realm HAProxy Stats #监控页面的认证提醒 stats auth admin:admin #监控页面的用户名和明码
批改实现后,启动HAProxy
service haproxy start
测试
首先,拜访一下监控页面http://192.168.8.110:1080/stats 并按提醒输出用户名明码
接下来就能看到监控页面:
监控页面中列出了咱们配置的所有frontend和backend服务,以及它们的具体指标。如连接数,队列状况,session rate,流量,后端服务的衰弱状态等等
接下来,咱们一一测试在HAProxy中配置的性能
健康检查
从监控页面中就能够间接看出健康检查配置的是否正确,上图中能够看到,backend ms1、ms2、default_servers上司的6个后端服务的Status都是20h28m UP,代表衰弱状态已继续了20小时28分钟,而LastChk显示L7OK/200 in 1ms则代表在1ms前进行了L7的健康检查(即HTTP申请形式的健康检查),返回码为200
此时咱们将ms1.srv1中的healthCheck.html改名
mv healthCheck.html healthCheck.html.bak
而后再去看监控页面:
ms1.srv1的状态变成了2s DOWN,LastChk则是L7STS/404 in 2ms,代表上次健康检查返回了404,再复原healthCheck.html,很快就能看到ms1.srv1从新复原到UP状态。
通过URI前缀转发申请:拜访http://192.168.8.110:9001/ms1…
能够看到胜利定向到了ms1.srv1上
拜访http://192.168.8.110:9001/ms2… :
拜访http://192.168.8.110:9001/def… :
负载平衡和会话放弃策略
在别离拜访过ms1/demo.html, ms2/demo.html, m3/demo.html后,查看一下浏览器的Cookie
能够看到HAProxy曾经回写了三个用于会话放弃的cookie,此时重复刷新这三个页面,会发现总是被定向到*.srv1上
接下来咱们删除HA_STICKY_ms1这条cookie,而后再拜访ms1/demo.html,会看到
同时也被新写入了一条Cookie
如果发现依然被定位到ms1.srv1,同时也没有写入新的HA_STICKY_ms1 Cookie,那么可能是浏览器缓存了ms1/demo.html页面,申请并没有达到HAProxy。F5刷新一下应该就能够了。
HAProxy搭建L4负载均衡器
HAProxy作为L4负载均衡器工作时,不会去解析任何与HTTP协定相干的内容,只在传输层对数据包进行解决。也就是说,以L4模式运行的HAProxy,无奈实现依据URL向不同后端转发、通过cookie实现会话放弃等性能。
同时,在L4模式下工作的HAProxy也无奈提供监控页面。
但作为L4负载均衡器的HAProxy可能提供更高的性能,适宜于基于套接字的服务(如数据库、音讯队列、RPC、邮件服务、Redis等),或不须要逻辑规定判断,并已实现了会话共享的HTTP服务。
总体方案
本例中,咱们应用HAProxy以L4形式来代理两个HTTP服务,不提供会话放弃。
global daemon maxconn 30000 #ulimit -n至多为60018 user ha pidfile /home/ha/haproxy/conf/haproxy.pid log 127.0.0.1 local0 info log 127.0.0.1 local1 warning defaults mode tcp log global option tcplog #开启tcplog timeout connect 5000ms timeout client 10000ms timeout server 10000ms #TCP模式下,应将timeout client和timeout server设置为一样的值,以防止出现问题 option httpchk GET /healthCheck.html #定义默认的健康检查策略 frontend http-in bind *:9002 maxconn 30000 #定义此端口上的maxconn default_backend default_servers #申请定向至后端服务群default_servers backend default_servers #定义后端服务群default_servers balance roundrobin server def.srv1 192.168.8.111:8082 maxconn 300 check server def.srv2 192.168.8.112:8082 maxconn 300 check
L4模式下的会话放弃
尽管TCP模式下的HAProxy无奈通过HTTP Cookie实现会话放弃,但能够很不便的实现基于客户端IP的会话放弃。只需将
balance roundrobin 改为 balance source
此外,HAProxy提供了弱小的stick-table性能,HAProxy能够从传输层的数据包中采样出大量的属性,并将这些属性作为会话放弃的策略写入stick-table中。
HAProxy要害配置详解
总览
HAProxy的配置文件共有5个域
global:用于配置全局参数 default:用于配置所有frontend和backend的默认属性 frontend:用于配置前端服务(即HAProxy本身提供的服务)实例 backend:用于配置后端服务(即HAProxy前面接的服务)实例组 listen:frontend+backend的组合配置,能够了解成更简洁的配置办法
global域的要害配置
daemon:指定HAProxy当前台模式运行,通常状况下都应该应用这一配置 user [username] :指定HAProxy过程所属的用户 group [groupname] :指定HAProxy过程所属的用户组 log [address] [device] [maxlevel] [minlevel]:日志输入配置,如log 127.0.0.1 local0 info warning,即向本机rsyslog或syslog的local0输入info到warning级别的日志。其中[minlevel]能够省略。HAProxy的日志共有8个级别,从高到低为emerg/alert/crit/err/warning/notice/info/debug pidfile :指定记录HAProxy过程号的文件绝对路径。次要用于HAProxy过程的进行和重启动作。 maxconn :HAProxy过程同时解决的连接数,当连接数达到这一数值时,HAProxy将进行接管连贯申请
frontend域的要害配置
acl [name] [criterion] [flags] [operator] [value]:定义一条ACL,ACL是依据数据包的指定属性以指定表达式计算出的true/false值。如"acl url_ms1 path_beg -i /ms1/"定义了名为url_ms1的ACL,该ACL在申请uri以/ms1/结尾(疏忽大小写)时为true bind [ip]:[port]:frontend服务监听的端口 default_backend [name]:frontend对应的默认backend disabled:禁用此frontend http-request [operation] [condition]:对所有达到此frontend的HTTP申请利用的策略,例如能够回绝、要求认证、增加header、替换header、定义ACL等等。 http-response [operation] [condition]:对所有从此frontend返回的HTTP响应利用的策略,大体同上 log:同global域的log配置,仅利用于此frontend。如果要沿用global域的log配置,则此处配置为log global maxconn:同global域的maxconn,仅利用于此frontend mode:此frontend的工作模式,次要有http和tcp两种,对应L7和L4两种负载平衡模式 option forwardfor:在申请中增加X-Forwarded-For Header,记录客户端ip option http-keep-alive:以KeepAlive模式提供服务 option httpclose:与http-keep-alive对应,敞开KeepAlive模式,如果HAProxy次要提供的是接口类型的服务,能够思考采纳httpclose模式,以节俭连接数资源。但如果这样做了,接口的调用端将不能应用HTTP连接池 option httplog:开启httplog,HAProxy将会以相似Apache HTTP或Nginx的格局来记录申请日志 option tcplog:开启tcplog,HAProxy将会在日志中记录数据包在传输层的更多属性 stats uri [uri]:在此frontend上开启监控页面,通过[uri]拜访 stats refresh [time]:监控数据刷新周期 stats auth [user]:[password]:监控页面的认证用户名明码 timeout client [time]:指连贯创立后,客户端继续不发送数据的超时工夫 timeout http-request [time]:指连贯创立后,客户端没能发送残缺HTTP申请的超时工夫,次要用于避免DoS类攻打,即创立连贯后,以十分迟缓的速度发送申请包,导致HAProxy连贯被长时间占用 use_backend [backend] if|unless [acl]:与ACL搭配应用,在满足/不满足ACL时转发至指定的backend
backend域的要害配置
acl:同frontend域 balance [algorithm]:在此backend下所有server间的负载平衡算法,罕用的有roundrobin和source,残缺的算法阐明见官网文档configuration.html#4.2-balance cookie:在backend server间启用基于cookie的会话放弃策略,最罕用的是insert形式,如cookie HA_STICKY_ms1 insert indirect nocache,指HAProxy将在响应中插入名为HA_STICKY_ms1的cookie,其值为对应的server定义中指定的值,并依据申请中此cookie的值决定转发至哪个server。indirect代表如果申请中曾经带有非法的HA_STICK_ms1 cookie,则HAProxy不会在响应中再次插入此cookie,nocache则代表禁止链路上的所有网关和缓存服务器缓存带有Set-Cookie头的响应。 default-server:用于指定此backend下所有server的默认设置。具体见上面的server配置。 disabled:禁用此backend http-request/http-response:同frontend域 log:同frontend域 mode:同frontend域 option forwardfor:同frontend域 option http-keep-alive:同frontend域 option httpclose:同frontend域 option httpchk [METHOD] [URL] [VERSION]:定义以http形式进行的健康检查策略。如option httpchk GET /healthCheck.html HTTP/1.1 option httplog:同frontend域 option tcplog:同frontend域 server [name] [ip]:[port] [params]:定义backend中的一个后端server,[params]用于指定这个server的参数,罕用的包含有: check:指定此参数时,HAProxy将会对此server执行健康检查,查看办法在option httpchk中配置。同时还能够在check后指定inter, rise, fall三个参数,别离代表健康检查的周期、间断几次胜利认为server UP,间断几次失败认为server DOWN,默认值是inter 2000ms rise 2 fall 3 cookie [value]:用于配合基于cookie的会话放弃,如cookie ms1.srv1代表交由此server解决的申请会在响应中写入值为ms1.srv1的cookie(具体的cookie名则在backend域中的cookie设置中指定) maxconn:指HAProxy最多同时向此server发动的连接数,当连接数达到maxconn后,向此server发动的新连贯会进入期待队列。默认为0,即有限 maxqueue:期待队列的长度,当队列已满后,后续申请将会发至此backend下的其余server,默认为0,即有限 weight:server的权重,0-256,权重越大,分给这个server的申请就越多。weight为0的server将不会被调配任何新的连贯。所有server默认weight为1 timeout connect [time]:指HAProxy尝试与backend server创立连贯的超时工夫 timeout check [time]:默认状况下,健康检查的连贯+响应超时工夫为server命令中指定的inter值,如果配置了timeout check,HAProxy会以inter作为健康检查申请的连贯超时工夫,并以timeout check的值作为健康检查申请的响应超时工夫 timeout server [time]:指backend server响应HAProxy申请的超时工夫
default域
上文所属的frontend和backend域要害配置中,除acl、bind、http-request、http-response、use_backend外,其余的均能够配置在default域中。default域中配置了的我的项目,如果在frontend或backend域中没有配置,将会应用default域中的配置。
listen域
listen域是frontend域和backend域的组合,frontend域和backend域中所有的配置都能够配置在listen域下
应用Keepalived实现HAProxy高可用
只管HAProxy十分稳固,但依然无奈躲避操作系统故障、主机硬件故障、网络故障甚至断电带来的危险。所以必须对HAProxy施行高可用计划。
下文将介绍利用Keepalived实现的HAProxy热备计划。即两台主机上的两个HAProxy实例同时在线,其中权重较高的实例为MASTER,MASTER呈现问题时,另一台实例主动接管所有流量。
原理
在两台HAProxy的主机上别离运行着一个Keepalived实例,这两个Keepalived争抢同一个虚IP地址,两个HAProxy也尝试去绑定这同一个虚IP地址上的端口。显然,同时只能有一个Keepalived抢到这个虚IP,抢到了这个虚IP的Keepalived主机上的HAProxy便是以后的MASTER。Keepalived外部保护一个权重值,权重值最高的Keepalived实例可能抢到虚IP。同时Keepalived会定期check本主机上的HAProxy状态,状态OK时权重值减少。
搭建HAProxy主备集群
环境筹备
在两台物理机上安装并配置HAProxy,本例中,将在192.168.8.110和192.168.8.111两台主机上上装置两套齐全一样的HAProxy,具体步骤省略,请参考“应用HAProxy搭建L7负载均衡器”一节。
装置Keepalived
下载,解压,编译,装置:
wget http://www.keepalived.org/software/keepalived-1.2.19.tar.gz tar -xzf keepalived-1.2.19.tar.gz ./configure --prefix=/usr/local/keepalived make make install
注册为零碎服务:
cp /usr/local/keepalived/sbin/keepalived /usr/sbin/ cp /usr/local/keepalived/etc/sysconfig/keepalived /etc/sysconfig/ cp /usr/local/keepalived/etc/rc.d/init.d/keepalived /etc/init.d/ chmod +x /etc/init.d/keepalived
留神:Keepalived须要应用root用户进行装置和配置
配置Keepalived
创立并编辑配置文件
mkdir -p /etc/keepalived/ cp /usr/local/keepalived/etc/keepalived/keepalived.conf /etc/keepalived/ vi /etc/keepalived/keepalived.conf
配置文件内容:
global_defs { router_id LVS_DEVEL #虚构路由名称 } #HAProxy健康检查配置 vrrp_script chk_haproxy { script "killall -0 haproxy" #应用killall -0查看haproxy实例是否存在,性能高于ps命令 interval 2 #脚本运行周期 weight 2 #每次查看的加权权重值 } #虚构路由配置 vrrp_instance VI_1 { state MASTER #本机实例状态,MASTER/BACKUP,备机配置文件中请写BACKUP interface enp0s25 #本机网卡名称,应用ifconfig命令查看 virtual_router_id 51 #虚构路由编号,主备机保持一致 priority 101 #本机初始权重,备机请填写小于主机的值(例如100) advert_int 1 #争抢虚地址的周期,秒 virtual_ipaddress { 192.168.8.201 #虚地址IP,主备机保持一致 } track_script { chk_haproxy #对应的健康检查配置 } }
如果主机没有killall命令,则须要装置psmisc包:
yum intall psmisc
别离启动两个Keepalived
service keepalived start
验证
启动后,先别离在两台主机查看虚IP 192.168.8.201由谁持有,执行命令:
ip addr sh enp0s25 (将enp0s25替换成主机的网卡名)
持有虚IP的主机输入会是这样的:
另一台主机输入则是这样的:
如果你先启动备机的Keepalived,那么很有可能虚IP会被备机抢到,因为备机的权重配置只比主机低1,只有执行一次健康检查就能把权重进步到102,高于主机的101。
此时拜访http://192.168.8.201:9001/ms1… ,能够看到咱们先前部署的网页。
此时,查看/var/log/haproxy.log,能看到此申请落在了抢到了虚IP的主机上。
接下来,咱们停掉以后MASTER主机的HAProxy实例(或者Keepalive实例,成果一样)
service haproxy stop
再次拜访http://192.168.8.201:9001/ms1… ,并查看备机的/var/log/haproxy.log,会看到此申请落在了备机上,主备主动切换胜利。
也能够再次执行ip addr sh enp0s25命令,会看到虚IP被备机抢去了。
在/var/log/message中,也可能看到keepalived输入的切换日志:
作者:kelgon
链接:https://www.gaodaima.com/p/c9f…