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 = 1net.ipv4.ip_local_port_range = 1024 65023net.ipv4.tcp_max_syn_backlog = 10240net.ipv4.tcp_max_tw_buckets = 400000net.ipv4.tcp_max_orphans = 60000net.ipv4.tcp_synack_retries = 3net.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.gztar -xzf haproxy-1.7.2.tar.gz

编译并装置

make PREFIX=/home/ha/haproxy TARGET=linux2628make 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/confvi /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端响应超时50sfrontend 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/shset -ePATH=/sbin:/bin:/usr/sbin:/usr/bin:/home/ha/haproxy/sbinPROGDIR=/home/ha/haproxyPROGNAME=haproxyDAEMON=$PROGDIR/sbin/$PROGNAMECONFIG=$PROGDIR/conf/$PROGNAME.cfgPIDFILE=$PROGDIR/conf/$PROGNAME.pidDESC="HAProxy daemon"SCRIPTNAME=/etc/init.d/$PROGNAME# Gracefully exit if the package has been removed.test -x $DAEMON || exit 0start(){       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       ;;esacexit 0

运行

启动、进行和重启：

service haproxy startservice haproxy stopservice 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  #日志文件的ownerlocal0.*     /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 detailsSYSLOGD_OPTIONS="-c 2 -r -m 0"

重启rsyslog和HAProxy

service rsyslog restartservice haproxy restart

此时就应该能在/var/log目录下看到haproxy的日志文件了

用logrotate进行日志切分

通过rsyslog输入的日志是不会进行切分的，所以须要依附Linux提供的logrotate(Linux零碎Logrotate服务介绍)来进行切分工作

应用root用户，创立haproxy日志切分配置文件：

mkdir /root/logrotatevi /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:8080ms1.srv2 - 192.168.8.112:8080ms2.srv1 - 192.168.8.111:8081ms2.srv2 - 192.168.8.112:8081def.srv1 - 192.168.8.111:8082def.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 warningdefaults    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 checkbackend 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 checkbackend 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 checklisten 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 warningdefaults    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_serversbackend 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/debugpidfile ：指定记录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/结尾（疏忽大小写）时为truebind [ip]:[port]：frontend服务监听的端口default_backend [name]：frontend对应的默认backenddisabled：禁用此frontendhttp-request [operation] [condition]：对所有达到此frontend的HTTP申请利用的策略，例如能够回绝、要求认证、增加header、替换header、定义ACL等等。http-response [operation] [condition]：对所有从此frontend返回的HTTP响应利用的策略，大体同上log：同global域的log配置，仅利用于此frontend。如果要沿用global域的log配置，则此处配置为log globalmaxconn：同global域的maxconn，仅利用于此frontendmode：此frontend的工作模式，次要有http和tcp两种，对应L7和L4两种负载平衡模式option forwardfor：在申请中增加X-Forwarded-For Header，记录客户端ipoption 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-balancecookie：在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：禁用此backendhttp-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.1option 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 3cookie [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为1timeout 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.gztar -xzf keepalived-1.2.19.tar.gz./configure --prefix=/usr/local/keepalivedmakemake 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.jianshu.com/p/c9f...