微学堂TCP/HTTP 负载均衡利器 - HAProxy 介绍及实践

Posted 2021-05-01 ITPUB技术小栈

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了微学堂TCP/HTTP 负载均衡利器 - HAProxy 介绍及实践相关的知识，希望对你有一定的参考价值。

本文编辑整理自【微学堂】第七期活动实录。

嘉宾介绍

Godbach，ChinaUnix 内核源码版、集群高可用版资深版主。先后从事网络安全产品研发以及互联网安全等工作，有丰富的 DDoS 防御，流量负载均衡和 DPI 经验。

直播实录

TCP/HTTP 负载均衡利器 - HAProxy 介绍及实践

很荣幸能做一次关于 HAProxy 的分享，本次分享侧重于系统介绍 HAProxy 的相关功能，以及提供几个配置的实例。

本次分享的大纲如下：

第一部分，先简单介绍一下 HAProxy 的版本情况。

HAProxy 当前的开发版本是1.7，稳定版本是1.6，是一个应用层负载均衡，支持 IPv4 和 IPv6。大家访问 HAProxy 官网最好用 https。

第二部分，介绍 HAProxy 的连接模式。

完整处理一次Client 请求，HAProxy 需要两条 TCP 连接。

对于这两条 TCP 连接如何关闭，HAProxy 支持5种方式：

1. keep alive，缺省模式，一次请求处理完毕，两端的连接都不主动关闭，让 Client 和 Server 进行处理；

2. tunnel，只处理连接的第一个 request 和 response，其余的直接 forward。应该是较为高效的传输方式。有些场景比如 NTLM，需要这种模式；

3. passive mode，双向都添加 Connection: close header，是否关闭连接，由 server 和 client 决定；

4. server close，处理完response，就 close server端连接。为了降低 server 端的并发，还保持了 client 的 keep alive；

5. force close，两端连接都主动关闭。较为暴力，不考虑 keep alive。

这 5 中模式中，serve close 和 force close 都是会尽快的关闭后端 real server 的 TCP 连接，目的就是降低 real server 的负载。

这是HAProxy 官网提供的部署方式。

第三部分，功能列表。介绍 HAProxy 的各项功能。

当前 HAProxy 不支持的功能就是 Cache。HAProxy 作者也有计划添加，不过暂时还没有开始。下面着重介绍几个重要的功能。

HAProxy 支持的负载均衡算法比较多，其中 roundrobin 是动态的 rr 算法，支持在运行过程中修改 real server 的 weight。static-rr 也支持 weight，但是不支持动态修改。如果大家在实际过程中对于动态修改没有严格要求，建议用 stitic-rr，因为这是性能最好的。

leastconn 适合 TCP 连接持续较长的情况，比如 LDAP，SQL 等，不适用于 HTTP 短连接。因为 leastconn 是按照连接数多少来进行负载均衡的，短的连接用这个算法意义不是很大，反而是可以用 rr 算法就行

HAProxy 支持好几种 hash 类的负载均衡，包含源 IP，URI，URI 的参数，还是可以任意指定 header 进行 hash。hash 算法的好处在于，可以确保同一个请求，只会被分到唯一的real server 上。对于后端 real sever 有 cache 的情况下，可以避免后端 real server 重复 cache。

第二个介绍的重要功能是持久化。

这个也是很常用的功能，比如按照源 IP 进行 persistence。一旦一个 Client IP 被分配给某个 real server，那么以后都会直接查询这个 persitence 表项，直接找到结果，不用走标准的分配 server 的流程。当然，超时情况除外。

cookie 方面，支持多种模式。

cookie insert, 直接在 response 插入 cookie，value 是 rs id；

cookie prefix 是针对一些只支持一个 cookie 的情形，添加 rs id 和分隔符到 cookie 的前面。转发给 server 之前会删掉，对 server >透明；

cookie rewrite 是直接修改 cookie 的 value 为 rs id。

实际中，cookie insert 应该更常用一些。

第三个常用功能，Content Routing。

对于 HAProxy 的标准配置，有 frontend 是对外服务的 IP，backend 是实际的 server pool。一个 frontend 可以使用多个 backend pool。具体选择哪个，就根据实际的需求，配置不同的 ACL。对于不同的请求，分配到不同的 backend 中。

注意，负载均衡算法是在 backend 中才执行的。所以，一个请求到了 HAProxy，第一步选择出来一个 backend，第二步，在backend 中通过配置的负载均衡算法，选出 real server。

这里的 content routing，就是选择对应的 backend 。实际引用中，应该是存在需要将网站的资源进行动静分离，动态网页一个 backend，静态资源一个 bakcend。这样可以更高效的服务。

第四块常用功能，内容重写。

可以根据需求，修改 Request 和 Response 的 header。实际中，还有进行 HTTP Redirect 的功能，比如讲 HTTP 请求 redirect 为 HTTPS 请求。内容重写同时支持支持在 frontend 和 backend 中执行。不同的修改位置，对于 request 和 response 的执行有不同的影响。

这里我自己之前遇到过一个坑。顺便分享一下。比如配置一个 acl，检测到满足某个条件，同时修改 URI 和某个 header：

replace A to XXX if ACL

replace B to YYY if ACL

对于以上情况，如果 ACL 中本身又包含了对 A 的匹配，那么第二条 replace B 很有可能不会执行的。因为这两条配置中的 ACL 都是单独执行的。当执行到第二条配置的 ACL 是，由于 A 的内容已经改变，ACL 的结果可能就是 false 了。所以 replace B 就执行不了。

以上是重点介绍几个常用功能。接下来介绍整个分享的第四部分，配置实例。

一共介绍五个实例。涉及到几个不同的方面。第一个实例，典型的配置。

global section 定义全局的一些配置default 定义一些缺省配置，frontend 和 backend 共用frontend 和 backend 各自定义，frotend 通过配置项 use_backend 或者 default_backend 来引用某个 backend。backend 可以理解为 server pool，定义一组 server，并且指定负载均衡算法。

此外，一个 HAProxy 配置文件支持定义多个 frontend。多个 frontend 可以引用相同的 backend。

当然，还有一种把 frotend 和 backend 混在一起的配置方式，就是 listen 这种方式的。

我个人喜欢层次分明一些，一般就是定义 frontend 和 backend，然后通过 use_backend 或者 default_backend 来关联 backend。

第二个实例，动态配置。

所谓动态配置，有种说法就是 Hot Configuration。在不重启进程的情况下，修改 HAProxy 的一些配置。HAProxy 支持了很多动态配置的功能，可以通过 HAProxy 源码的 doc/management.txt 去了解。

还有，就是通过这种方式，还可以实时的查看 HAProxy 运行时的很多状态。包括 session 情况，内存使用情况等等。分析问题的时候，应该比较方便。

第三个实例，多进程的配置。

HAProxy 支持多进程，而且是所有进程都是做相同的事情，不是 nginx 的那种 master + worker 的方式。

这个配置实例中，重点是介绍了避免 epoll 惊群的配置方式。这个配置，可以提升多进程模式下的 HAProxy 性能，降低系统的负载。其核心的思路，就是保证不同的进程，绑定不同的 socket。进程之间不存在对同一个 socket 的竞争。

这个问题我本人专门做个 debug。建议在用 HAProxy 的同学，可以把这个配置方式集成进来。

第四个实例，HAproxy 多实例间的同步。

前面提到，HAProxy 支持 persitence，其实就是在 HAProxy 的内存里保存了一些表项。比如源 IP 和 rs 的对应关系。如果启用多个实例，或者在 HA 的情况下，HAProxy 支持通过配置，将本地的表项，发送给远程的另外一个实例。这样在 HAProxy 主从切换的时候，可以维持表项。

第五个实例，就是 HAProxy 自带的统计页面。

这个应该是不少同学，觉得 HAProxy 做的比较好用的一个地方，直观展示 HAProxy 的使用情况。不过内部实现其实都是用 C 写的页面。用 C 写出来这样的页面，对于程序员来说，还是比较折腾的。

以上是分享的第四分部，配置实例。接下来是第五部分，调试和分析问题。

management.txt 是 1.6 中专门介绍 HAProxy 启动、停止、管理以及定位问题的文档。个人觉得比较使用的，一是抓包分析。而是通过 Unix Socket Command 去看 session 的情况。

主要内容基本上是以上介绍的。当期 HAProxy 重要的资料，可能还是配置手册。

此外，有问题也可以给你 HAProxy 的 mail list 发邮件。这几年 HAProxy 的社区比我 2012 刚开始搞的时候，活跃一些了。而且 HAProxy的作者也比较热心，一般他有时间的话，应该也会回复的。昨天特意搜索了一下那些公司在用 HAProxy。见下图

据说国内的 sina 也用了 HAProxy。我不是很确定，所以没有列举出来。

以上是本次分享的所有内容。我个人主要是从事了几年的 HAProxy 开发，所以可能介绍的时候偏重于实现等。

互动筛选

Q1：老师，您好，HAProxy性能不错，但我想请教下HAProxy有没有像nginx一样的轮询重试机制，比如后端某个节点出现500，404等错误，在检测间隙，负载重新轮询到一个健康的节点，并将正确请求反馈给用户，但是用户自始至终感觉不到错误，如果存在，可以介绍下吗？

A1：我之前了解的应该是没有的。你这个需求，感觉更偏重业务一些。HAProxy 只有在试图和 real sever 建连失败的时候，会考虑 retry 其他的 real server。一旦 TCP 握手成功了。不会再考虑 500/404 的问题。

Q2 ：想请教下，HA是否有这个实现？或者HA更适合做四层负载，还是七层？

A2：你考虑的问题，应该是有额外的 health check 来保证更合适吧。HAProxy 是做七层负载均衡的。HAProxy 不做四层。不要看到 TCP 就认为 HAProxy 做四层。不是这样的。

Q3 ：后端服务器之间文件，数据同步一致性怎么做比较好？比如网站图片，代码，附件，数据库？

A3：HAProxy 的优势是读取到了应用层的数据，给你提供了修改应用层数据的机会。HAProxy 自己在配置 real sever 的时候，是可以开启 health check 的。网站图片一般会考虑使用分布式文件系统去存储，保证一致性。对于静态资源，比如js,css等也可以使用分布式文件系统或者rsync来做。对于数据库的一致性，这个要看你在什么场景下了。

Q4 ：老师好，这个配置实例中，重点是介绍了避免 epoll 惊群的配置方式。这个配置，可以提升多进程模式下的 HAProxy 性能，降低系统的负载。其核心的思路，就是保证不同的进程，绑定不同的 socket。进程之间不存在对同一个 socket 的竞争。这里的socket应该是cpu绑定吗？

A4：这个不是绑定 CPU 的，是绑定进程的。HAProxy 多进程模式下，对于不少功能，支持的不够好。之前的 stick table，和统计页面应该都不支持多进程。

Q5 ：什么和进程绑定？听人说官方不建议使用多进程模式？多进程占用资源是不是多？

A5：官方不建议的原因，就是有些功能，多进程没支持好。fork 这个东西你理解他的原理吗？多进程模式我个人觉得还是不错的功能，但是官方的博客中说了，多进程这种需要配合cpu-map功能，且最好将处理同一个frontend的请求，由同一个物理CPU的core去处理会更好。多进程从我目前生产使用来看，资源占用并不多。

Q6 ：跟nginx比起来，哪个好？

A6：HAProxy 和 NGinx 的性能有略，我记得之前有一个对比。HAProxy 应该是是好一些。但是这几年 nginx 肯定也在做性能的改进。最近的比较我自己没做过。Nginx plus支持动态配置，开源版本本身不支持，但是通过nginx-lua模块是可以做到动态配置，如果关心upstrem的动态配置，可参看nginx-lua-upstream-module模块。Haproxy如果使用了SO_REUSEPORT，那与nginx的SO_REUSEPORT还是差好多，现象上不一样啊。

【招募令】

“

【微学堂】是什么？

【微学堂】

【微学堂】是由IT168打造的，面向广大IT人士的一档在线互动栏目。在这里，你能认识更多的朋友，分享更多的案例经验，学习更强的技术才能。

“

如果，你……

【微学堂】

对系统运维、大数据、云计算、移动互联网……等IT领域有独特的见解~

对某一行业，或某一工具有深入的研究~

热衷分享，在表达上极具感染力~

……

“

那么，你将会得到……

【微学堂】