haproxy健康检查（haproxy健康检测）
本文目录一览：
apache haproxy 怎么样
一、lvs的优势：1、抗负载能力强，因为lvs工作方式的逻辑是非常之简单，而且工作在网络4层仅做请求分发之用，没有流量，所以在效率上基本不需要太过考虑。在我手里的 lvs，仅仅出过一次问题：在并发最高的一小段时间内均衡器出现丢包现象，据分析为网络问题，即网卡或linux2.4内核的承载能力已到上限，内存和 cpu方面基本无消耗。2、配置性低，这通常是一大劣势，但同时也是一大优势，因为没有太多可配置的选项，所以除了增减服务器，并不需要经常去触碰它，大大减少了人为出错的几率。3、工作稳定，因为其本身抗负载能力很强，所以稳定性高也是顺理成章，另外各种lvs都有完整的双机热备方案，所以一点不用担心均衡器本身会出什么问题，节点出现故障的话，lvs会自动判别，所以系统整体是非常稳定的。4、无流量，上面已经有所提及了。lvs仅仅分发请求，而流量并不从它本身出去，所以可以利用它这点来做一些线路分流之用。没有流量同时也保住了均衡器的IO性能不会受到大流量的影响。5、基本上能支持所有应用，因为lvs工作在4层，所以它可以对几乎所有应用做负载均衡，包括http、数据库、聊天室等等。另：lvs也不是完全能判别节点故障的，譬如在wlc分配方式下，集群里有一个节点没有配置VIP，会使整个集群不能使用，这时使用wrr分配方式则会丢掉一台机。目前这个问题还在进一步测试中。所以，用lvs也得多多当心为妙。二、nginx和lvs作对比的结果1、nginx工作在网络的7层，所以它可以针对http应用本身来做分流策略，比如针对域名、目录结构等，相比之下lvs并不具备这样的功能，所以 nginx单凭这点可利用的场合就远多于lvs了；但nginx有用的这些功能使其可调整度要高于lvs，所以经常要去触碰触碰，由lvs的第2条优点 看，触碰多了，人为出问题的几率也就会大。2、nginx对网络的依赖较小，理论上只要ping得通，网页访问正常，nginx就能连得通，nginx同时还能区分内外网，如果是同时拥有内外网的 节点，就相当于单机拥有了备份线路；lvs就比较依赖于网络环境，目前来看服务器在同一网段内并且lvs使用direct方式分流，效果较能得到保证。另 外注意，lvs需要向托管商至少申请多一个ip来做Visual IP，貌似是不能用本身的IP来做VIP的。要做好LVS管理员，确实得跟进学习很多有关网络通信方面的知识，就不再是一个HTTP那么简单了。3、nginx安装和配置比较简单，测试起来也很方便，因为它基本能把错误用日志打印出来。lvs的安装和配置、测试就要花比较长的时间了，因为同上所述，lvs对网络依赖比较大，很多时候不能配置成功都是因为网络问题而不是配置问题，出了问题要解决也相应的会麻烦得多。4、nginx也同样能承受很高负载且稳定，但负载度和稳定度差lvs还有几个等级：nginx处理所有流量所以受限于机器IO和配置；本身的bug也还是难以避免的；nginx没有现成的双机热备方案，所以跑在单机上还是风险较大，单机上的事情全都很难说。5、nginx可以检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点。目前lvs中 ldirectd也能支持针对服务器内部的情况来监控，但lvs的原理使其不能重发请求。重发请求这点，譬如用户正在上传一个文件，而处理该上传的节点刚 好在上传过程中出现故障，nginx会把上传切到另一台服务器重新处理，而lvs就直接断掉了，如果是上传一个很大的文件或者很重要的文件的话，用户可能 会因此而恼火。6、nginx对请求的异步处理可以帮助节点服务器减轻负载，假如使用apache直接对外服务，那么出现很多的窄带链接时apache服务器将会占用大 量内存而不能释放，使用多一个nginx做apache代理的话，这些窄带链接会被nginx挡住，apache上就不会堆积过多的请求，这样就减少了相 当多的内存占用。这点使用squid也有相同的作用，即使squid本身配置为不缓存，对apache还是有很大帮助的。lvs没有这些功能，也就无法能 比较。7、nginx能支持http和email（email的功能估计比较少人用），lvs所支持的应用在这点上会比nginx更多。在使用上，一般最前端所采取的策略应是lvs，也就是DNS的指向应为lvs均衡器，lvs的优点令它非常适合做这个任务。重要的ip地址，最好交由lvs托管，比如数据库的ip、webservice服务器的ip等等，这些ip地址随着时间推移，使用面会越来越大，如果更换ip则故障会接踵而至。所以将这些重要ip交给lvs托管是最为稳妥的，这样做的唯一缺点是需要的VIP数量会比较多。nginx可作为lvs节点机器使用，一是可以利用nginx的功能，二是可以利用nginx的性能。当然这一层面也可以直接使用squid，squid的功能方面就比nginx弱不少了，性能上也有所逊色于nginx。nginx也可作为中层代理使用，这一层面nginx基本上无对手，唯一可以撼动nginx的就只有lighttpd了，不过lighttpd目前还没有 能做到nginx完全的功能，配置也不那么清晰易读。另外，中层代理的IP也是重要的，所以中层代理也拥有一个VIP和lvs是最完美的方案了。nginx也可作为网页静态服务器，不过超出了本文讨论的范畴，简单提一下。具体的应用还得具体分析，如果是比较小的网站（日PV1000万），用nginx就完全可以了，如果机器也不少，可以用DNS轮询，lvs所耗费的机器还是比较多的；大型网站或者重要的服务，机器不发愁的时候，要多多考虑利用lvs。 **************************************************************************************************************** Nginx的优点: 性能好，可以负载超过1万的并发。 功能多，除了负载均衡，还能作Web服务器，而且可以通过Geo模块来实现流量分配。 社区活跃，第三方补丁和模块很多 支持gzip proxy 缺点: 不支持session保持。 对后端realserver的健康检查功能效果不好。而且只支持通过端口来检测，不支持通过url来检测。 nginx对big request header的支持不是很好，如果client_header_buffer_size设置的比较小，就会返回400bad request页面。 Haproxy的优点: 它的优点正好可以补充nginx的缺点。支持session保持，同时支持通过获取指定的url来检测后端服务器的状态。 支持tcp模式的负载均衡。比如可以给mysql的从服务器集群和邮件服务器做负载均衡。 缺点： 不支持虚拟主机(这个很傻啊) 目前没有nagios和cacti的性能监控模板 LVS的优点: 性能好，接近硬件设备的网络吞吐和连接负载能力。 LVS的DR模式，支持通过广域网进行负载均衡。这个其他任何负载均衡软件目前都不具备。 缺点： 比较重型。另外社区不如nginx活跃。 *************************************************************************************现在网络中常见的的负载均衡主要分为两种：一种是通过硬件来进行进行，常见的硬件有比较昂贵的NetScaler、F5、Radware和Array等商用的负载均衡器，也有类似于LVS、Nginx、HAproxy的基于Linux的开源的负载均衡策略, 商用负载均衡里面NetScaler从效果上比F5的效率上更高。对于负载均衡器来说，不过商用负载均衡由于可以建立在四~七层协议之上，因此适用 面更广所以有其不可替代性，他的优点就是有专业的维护团队来对这些服务进行维护、缺点就是花销太大，所以对于规模较小的网络服务来说暂时还没有需要使用。 另一种负载均衡的方式是通过软件：比较常见的有LVS、Nginx、HAproxy等，其中LVS是建立在四层协议上面的，而另外Nginx和HAproxy是建立在七层协议之上的，下面分别介绍关于 LVS：使用集群技术和Linux操作系统实现一个高性能、高可用的服务器，它具有很好的可伸缩性（Scalability）、可靠性（Reliability）和可管理性（Manageability）。 LVS的特点是： 1、抗负载能力强、是工作在网络4层之上仅作分发之用，没有流量的产生； 2、配置性比较低，这是一个缺点也是一个优点，因为没有可太多配置的东西，所以并不需要太多接触，大大减少了人为出错的几率； 3、工作稳定，自身有完整的双机热备方案； 4、无流量，保证了均衡器IO的性能不会收到大流量的影响； 5、应用范围比较广，可以对所有应用做负载均衡； 6、LVS需要向IDC多申请一个IP来做Visual IP，因此需要一定的网络知识，所以对操作人的要求比较高。 Nginx的特点是： 1、工作在网络的7层之上，可以针对http应用做一些分流的策略，比如针对域名、目录结构； 2、Nginx对网络的依赖比较小； 3、Nginx安装和配置比较简单，测试起来比较方便； 4、也可以承担高的负载压力且稳定，一般能支撑超过1万次的并发； 5、Nginx可以通过端口检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点，不过其中缺点就是不支持url来检测； 6、Nginx对请求的异步处理可以帮助节点服务器减轻负载； 7、Nginx能支持http和Email，这样就在适用范围上面小很多； 8、不支持Session的保持、对Big request header的支持不是很好，另外默认的只有Round-robin和IP-hash两种负载均衡算法。 HAProxy的特点是： 1、HAProxy是工作在网络7层之上。 2、能够补充Nginx的一些缺点比如Session的保持，Cookie的引导等工作 3、支持url检测后端的服务器出问题的检测会有很好的帮助。 4、更多的负载均衡策略比如：动态加权轮循(Dynamic Round Robin)，加权源地址哈希(Weighted Source Hash)，加权URL哈希和加权参数哈希(Weighted Parameter Hash)已经实现 5、单纯从效率上来讲HAProxy更会比Nginx有更出色的负载均衡速度。 6、HAProxy可以对Mysql进行负载均衡，对后端的DB节点进行检测和负载均衡。 ***********************************************************************************************现在网站发展的趋势对网络负载均衡的使用是随着网站规模的提升根据不同的阶段来使用不同的技术： 第一阶段：利用Nginx或者HAProxy进行单点的负载均衡，这一阶段服务器规模刚脱离开单服务器、单数据库的模式，需要一定的负载均衡，但是 仍然规模较小没有专业的维护团队来进行维护，也没有需要进行大规模的网站部署。这样利用Nginx或者HAproxy就是第一选择，此时这些东西上手快， 配置容易，在七层之上利用HTTP协议就可以。这时是第一选择 第二阶段：随着网络服务进一步扩大，这时单点的Nginx已经不能满足，这时使用LVS或者商用F5就是首要选择，Nginx此时就作为LVS或者 F5的节点来使用，具体LVS或者F5的是选择是根据公司规模，人才以及资金能力来选择的，这里也不做详谈，但是一般来说这阶段相关人才跟不上业务的提 升，所以购买商业负载均衡已经成为了必经之路。 第三阶段：这时网络服务已经成为主流产品，此时随着公司知名度也进一步扩展，相关人才的能力以及数量也随之提升，这时无论从开发适合自身产品的定制，以及降低成本来讲开源的LVS，已经成为首选，这时LVS会成为主流。 最终形成比较理想的状态为：F5/LVS—Haproxy—Squid/Varnish—AppServer。
RabbitMQ 镜像集群 宕机恢复、负载均衡、跨机房多活
起因：在实际项目开发过程中，需要使用RabbitMQ来实现消息队列的功能，但仅仅实现功能之后并不能对自己满足，既然学一次，就要更深的了解她，吃一吃架构方面的相关内容，提升自己。
RabbitMQ在镜像集群中，机器其实是平行关系，所有的节点都是互相复制的
场景描述：
A是Master
B是Slave
A正常运行，B宕机了，只需要启动B即可，B就会自动加入集群
A和B都宕机了，只要A在B之前启动就可以了
A和B都宕机了，A启动不起来了，即便是B启动了，有可以B直接启动不了啦
B和C都加入了A为Master的集群，这个时候都需要将B和C从A的集群中forget，B和C启动不起来了
RabbitMQv3.2版本以后提供了一个离线清除集群节点的命令参数，也就是节点无法启动状态下
HAProxy是一款提供高可用的负载均衡器（之前大家都是使用的Nginx居多，upstream反向代理实现负载均衡非常容易），HAProxy可以基于TCP四层（Lvs也是TCP四层的），HTTP七层（Nginx是HTTP七层）的负载均衡应用代理软件，免费高速可靠的一种LBS解决方案
HAProxy的并发连接完全可以支持以万为单位的
Nginx
优点：
1、工作在网络7层之上，可针对http应用做一些分流的策略，如针对域名、目录结构，它的正规规则比HAProxy更为强大和灵活，所以，目前为止广泛流行。
2、Nginx对网络稳定性的依赖非常小，理论上能ping通就能进行负载功能。
3、Nginx安装与配置比较简单，测试也比较方便，基本能把错误日志打印出来。
4、可以承担高负载压力且稳定，硬件不差的情况下一般能支撑几万次的并发量。
5、Nginx可以通过端口检测到服务器内部的故障，如根据服务器处理网页返回的状态码、超时等，并会把返回错误的请求重新提交到另一个节点。
6、不仅仅是优秀的负载均衡器/反向代理软件，同时也是强大的Web应用服务器。可作为静态网页和图片服务器，在高流量环境中稳定性也很好。
7、可作为中层反向代理使用。
缺点：
1、适应范围较小，仅能支持http、https、Email协议。
2、对后端服务器的健康检查，只支持通过端口检测，不支持url来检测
3、负载均衡策略比较少：轮询、权重、IP_hash、url_hash
HAProxy
优点：
1、HAProxy是支持虚拟主机的，可以工作在4、7层(支持多网段)
2、HAProxy的优点能够补充Nginx的一些缺点，比如支持Session的保持，Cookie的引导；同时支持通过获取指定的url来检测后端服务器的状态。
3、HAProxy跟LVS类似，本身就只是一款负载均衡软件；单纯从效率上来讲HAProxy会比Nginx有更出色的负载均衡速度，在并发处理上也是优于Nginx的。
4、HAProxy支持TCP协议的负载均衡转发，可以对MySQL读进行负载均衡，对后端的MySQL节点进行检测和负载均衡。
5、HAProxy负载均衡策略非常多，HAProxy的负载均衡算法现在具体有如下8种
缺点：
1、不支持POP/SMTP协议
2、不支持SPDY协议
3、不支持HTTP cache功能。现在不少开源的lb项目，都或多或少具备HTTP cache功能。
4、重载配置的功能需要重启进程，虽然也是soft restart，但没有Nginx的reaload更为平滑和友好。
5、多进程模式支持不够好
HAProxy+Keepalived（负载均衡节点的高可用）
将上面的配置文件内容放入 /etc/haproxy/haproxy.cfg中
启动HAProxy
启用成功后可以到控制台进行验证
通过federation的配置来进行数据通道搭建
这个时候你需要自己定义一个上游节点upstream(166节点)，一个下游节点downstream(167节点)，federation是单向发送的，相当于消息发送到upstream的一个exchange上，然后转发到downstream的queue上
1、 在下游节点创建一个exchage和一个queue和binding的routingkey，用来进行数据接收
2、 在下游节点建立federation upstream规则和上游节点进行数据同步
3、 进入下游节点的federation status没有任何数据，需要建立策略来保证通道连通
4、 进入下游节点的Policy菜单，Pattern是个正则表达式，这里表示以down开头的exchange和queue都匹配
5、 这个时候看exchange和queue，规则就应用上了
6、 这个时候去federation status看，发现上游连接已经连接上了
7、 这个时候我们先去看上游的overview
8、 再看上游的exchange和queue就已经根据下游配置的upstream和policy规则将exchange和queue创建好了
灰色的这个重定向exchange不能发送消息，如果要发送则在down-exchange上进行发送
9、 我们在上游的down-exchange发送一条消息，进行测试
可以在下游查看这条消息
10、 因为上游及节点只是一个中转，如果上游及诶单也要消息down-exchange里的消息怎么办？
只需要在本地建立一个binding关系就好
不要以为每天把功能完成了就行了，这种思想是要不得的，互勉~！
2018-10-15 HAProxy
HAProxy是TCP / HTTP反向代理服务器，尤其适合于高可用性环境
可以针对HTTP请求添加cookie，进行路由后端服务器
可平衡负载至后端服务器，并支持持久连接
支持基于cookie进行调度
支持所有主服务器故障切换至备用服务器
支持专用端口实现监控服务
支持不影响现有连接情况下停止接受新连接请求
可以在双向添加，修改或删除HTTP报文首部
支持基于pattern实现连接请求的访问控制
通过特定的URI为授权用户提供详细的状态信息
软件包：yum install haproxy
主程序：/usr/sbin/haproxy
配置文件：/etc/haproxy/haproxy.cfg
Unit file：/usr/lib/systemd/system/haproxy.service
配置段：
global：全局配置段
进程及安全配置相关的参数
性能调整相关参数
Debug参数
proxies：代理配置段
defaults：为frontend, backend, listen提供默认配置
fronted：前端，相当于nginx, server {}
backend：后端，相当于nginx, upstream {}
listen：同时拥有前端和后端,适用于一对一环境，也就是前段和后端是一一对应的关系，只有一个端和一个后端
备注：以下的所有实验都是根据此拓扑图完成的
代理配置段：
check：对当前server做健康状态检测，只用于四层检测
注意：httpchk，“smtpchk”, “mysql-check”, “pgsql-check” and “ssl-hello-chk” 用于定义应用层检测方法
addr：检测时使用的IP地址，可以实现后端的服务器检测时使用一个ip地址，提供服务使用另外一个ip地址，使流量分流，提高效率
port ：针对此端口进行检测
inter delay：连续两次检测之间的时间间隔，默认为2000ms
rise count：连续多少次检测结果为“成功”才标记服务器为可用；默认为2
fall count：连续多少次检测结果为“失败”才标记服务器为不可用；默认为3
cookie value：为当前server指定cookie值，实现基于cookie的会话黏性
disabled：标记为不可用
redirprefix：将发往此server的所有GET和HEAD类的请求重定向至指定的URL
cookie name [ rewrite | insert | prefix ] [ indirect ] [ nocache ] [ postonly ] [ preserve ] [ httponly ] [ secure ] [ domain domain ]* [ maxidle idle ] [ maxlife life ]
name：cookie名称，用于实现持久连接
rewrite：重写
insert：插入
prefix：前缀
在火狐浏览器上访问时，按F12进入调试页面也可以看到，第一次访问时响应报文里会有一个cookie值，这样浏览器下次访问时就会带着这个cookie值，从而被调度到固定的主机
stats enable
启用统计页；基于默认的参数启用stats page
-stats uri: /haproxy?statsuri默认值
-stats realm : HAProxy\Statistics
-stats auth: no authentication
stats uri prefix
自定义stats page uri
stats auth user:passwd
认证时的账号和密码，可使用多次
stats realm realm
认证时的realm
stats hide-version
隐藏版本
stats refresh delay
设定自动刷新时间间隔
stats admin { if | unless } cond
启用stats page中的管理功能
示例
maxconn conns：为指定的frontend定义其最大并发连接数；默认为2000
mode { tcp|http|health}
定义haproxy的工作模式
tcp：基于layer4实现代理；可代理mysql, pgsql, ssh, ssl等协议,https时使用此模式，默认模式
http：仅当代理协议为http时使用,centos实际默认模式
health：工作为健康状态检查的响应模式，当连接请求到达时回应“OK”后即断开连接，较少使用
TCP模式的健康状态检测示例
对后端服务器做http协议的健康状态检测：
option httpchk默认为：/ OPTIONS HTTP/1.0
option httpchk uri
option httpchk method uri
option httpchk method uri version
定义基于http协议的7层健康状态检测机制http-check expect [!] match pattern
http协议健康状态检测响应内容或指定响应码
option forwardfor[ except network ] [ header name ] [ if-none ]
在由haproxy发往后端主机的请求报文中添加“X-Forwarded-For”首部，其值为前端客户端的地址；用于向后端主发送真实的客户端IP
[ except network ]：请求报文来自此处指定的网络时不予添加此首部，如haproxy自身所在网络
[ header name ]：使用自定义的首部名称，而非“X-Forwarded-For”
[ if-none ]如果没有首部才添加首部，如果有使用默认值
示例
errorfile code file 自定义错误页
code：HTTP status code，支持200, 400, 403, 408, 500, 502, 503, 504，file：错误页文件路径
errorlo ccode url
相当于errorloc 302 code url，利用302重定向至指URL
示例1
reqadd string [{if | unless} cond]
在请求报文尾部添加指定首部
rspadd string [{if | unless} cond]
在响应报文尾部添加指定首部
示例：rspadd X-Via:\ HAPorxy
reqdel search [{if | unless} cond]
reqidel search [{if | unless} cond] (ignore case) 不分大小写
从请求报文中删除匹配正则表达式的首部
rspdel search [{if | unless} cond]
rspidel search [{if | unless} cond] (ignore case) 不分大小写
从响应报文中删除匹配正则表达式的首部
示例1
示例1
示例2
示例3基于acl实现动静分离
示例4实现不同的域调度到不同服务器
示例5
1 、支持ssl会话；
bind *:443 ssl crt /PATH/TO/SOME_PEM_FILE
crt后证书文件为PEM格式，且同时包含证书和所有私钥
cat demo.crt demo.key demo.pem
2、 把80端口的请求重向定443
bind *:80
redirect scheme https if !{ ssl_fc}
3、 向后端传递用户请求的协议和端口（frontend或backend）
http-request set-header X-Forwarded-Port %[dst_port] ---添加端口
http-request add-header X-Forwared-Proto https if { ssl_fc} ---添加https协议
支持https指的是客户端访问haproxy时使用https协议，因为这一段一般是外网，而haproxy访问后端的web服务器时不用https，因为这一段一般都是内网
示例
