【负载均衡大讨论，参与有礼】TCP/HTTP 负载均衡利器-- HAProxy

Godbach

回复 98# gaoyp27

不过这两年 HAProxy 明显的活跃起来了。


   

Purple_Grape

关于tcp长连接的负载均衡，我理解不太好，请教楼主和各位大神：

1、haproxy软重启怎样处理长连接？
2、round robin负载均衡算法，似乎是针对的是短连接，对长连接有什么效果？
3、两个后端，挂掉一个，长连接会怎样处理？还是直接tcp重传
4、haproxy针对tcp长连接有什么方法优化？

Godbach

回复 101# Purple_Grape

看来 LS 很关心长连接的处理。我来介绍一下我的理解，当然我自己也做过一些实践。

1、haproxy软重启怎样处理长连接？

HTTP 模式下，软重启的时候。老的进程，肯定会保证会处理完当前的 transcation，然后有可能会再多处理一个 transcation，就会断开连接。



   

Godbach

回复 101# Purple_Grape

2、round robin负载均衡算法，似乎是针对的是短连接，对长连接有什么效果？

就我个人理解，不存在 rr 算法是针对长连接还是短连接的问题。只是对于不同的配置，哪种算法更合适。

rr 就是一个比较简单的算法，轮流（也支持权重）的给后端 server 分配请求就行了。

3、两个后端，挂掉一个，长连接会怎样处理？还是直接tcp重传

你反复提到长连接和短连接。这个地方要先明确，HAProxy 前端和后端各自都是 TCP 连接的。

如果跑的是 HTTP，那么结合前端后端，就有多种模式：
1）前端长连接，后端也长连接
2）前端长连接，后端短连接
。。。

简单介绍一个，如果后端是按照 transcation 做负载均衡，也就是一个 request，就会触发选择一次 server。那么挂掉一个 server，如果也开启了 health check 的话，该 server 会很快从后端中踢掉，随后的 request 只转到可用的 server 上。


   

Godbach

回复 101# Purple_Grape

4、haproxy针对tcp长连接有什么方法优化？

既然是 TCP 连接，就无所谓长连接了吧。你指的就是持续时间较长的 TCP 连接吗？

HAProxy 提供了一些优化配置，诸如 tune.xxx 的。不知道你你指的优化，是想优化哪些方面，比如新建，比如吞吐等。


   

Purple_Grape

回复 104# Godbach


    可能我的tcp长连接说法不够准确，因为经常说http 长连接。

    我的意思是客户端主动通过tcp socket连接到服务端某个端口，连上后就等待服务端指令，空闲时也会发送心跳包到服务端以维持连接。（比如saltstack客户端与服务端的关系）

    如果客户端很多，需要扩展服务端，haproxy采用轮询的话，客户端与服务端的tcp连接会不会经常断？

撒加

针对我们公司自己的情况，谈一下haproxy的一些情况。
我刚加入现在这家公司的时候，负载均衡是用LVS+Keepalived，为什么用Keepalived？看当时的情况，一个是为了高可用，一个是为了管理LVS方便。因为整体架构比较烂（这里就不说多烂了），所以招我过来负责运维团队并重新设计架构，对原有业务进行架构迁移。在方案中，对于负载均衡这块考虑使用HAPROXY替换LVS，更换主要出于一下几点考虑：
1、LVS仅仅是转发流量，如果后期要使用ectd后者consul不是很方便。使用Haproxy就不同了，很容易来实现服务自动发现，尤其是在KVM环境下（我们使用kvm）
2、Haproxy 1.5版本支持多进程，在CPU核心比较多的时候，可以通过bind-process将不同的ft或者be运行在特定的CPU processor上，这一点是我们看中的。
3、LVS对后端的长连接支持不好，在LVS上容易产生大量的TIME-WAIT，同时后端产生大量的CLOSE-WAIT（当然有些博主说这并不是问题，呵呵...），而Haproxy支持与后端服务器的长连接，在访问量较大的时候，不易产生大量的TIME-WAIT和CLOSE-WAIT，对业务的稳定有着重要作用。
4、LVS多台场景下，没法同步有些IP信息，尤其在OSPF场景下，而Haproxy的peers功能就恰好支持，很赞的功能配合sticy-table。
综上我们最终前端Web服务的架构是Haproxy---->Varnish----->Tengine------>Resin(部署在KVM上)。虽然haproxy在7层的ACL规则非常灵活，由于不支持类似tengine中的include指令，导致配置文件的维护还是有点问题，所以Haproxy主要转发流量，Varnish对需要缓存的页面进行缓存，Tengine作为二级负载均衡，将动态的请求转发后端的Resin。

使用Haproxy中也出现过一些问题或者叫疑问吧
在使用Haproxy做四层负载均衡的时候，用户的真实IP需要使用tproxy来实现，同时需要iptable规则的支持，本来已经打算使用这种方式了，后来看到了Haproxy支持Proxy protocol的v1和v2版本，可以在不适用tproxy的方式下将用户的真实IP传递到后端。目前这种使用方法还是研究中，后期也打算用这种方式。

Haproxy的优化，每个人使用场景不同，可能侧重的面也不一样。就我们公司业务而言，主要有一下几点的优化：
1、Haproxy的安装
在1.5里的多进程及cpu-map功能其实是需要在编译的时候加上USE_CPU_AFFINITY=1才可以用bind-process。当然编译的时候还指定了TARGET_CFLAGS="-m64 -mtune=native -m128bit-long-double"，使用较高版本的gcc可以更好的利用CPU指令集。（想用gcc 4.8或者4.9可以安装devtoolset-2或者devtoolset-3）
2、多进程及cpu-map结合bind-process
3、网卡全部升级为Intel X350 T4 QP，升级驱动，开启RSS，并对RSS进行CPU绑定，高级玩家可以调整下网卡的中断速率
4、TCP/IP协议栈的优化
5、对后端开启长连接功能。option srvtcpka
6、自定义编译内核，同时修改了TIME-WAIT的超时时间，我们修改到5s
7、对后端的检查不能局限在后端返回200的状态码，可以多使用tcp-check send/expect功能
8、Haproxy的高可用我们目前已经验证完使用OSPF ECMP+多台Haproxy来实现了。
9、网卡bond，最少作为Haproxy连接后端的链路需要2个1G接口做bond，使用mode=4

更多可优化的内容可以看官方文档，哈哈。暂时总结这么多

Godbach

回复 105# Purple_Grape

   可能我的tcp长连接说法不够准确，因为经常说http 长连接。

    我的意思是客户端主动通过tcp socket连接到服务端某个端口，连上后就等待服务端指令，空闲时也会发送心跳包到服务端以维持连接。（比如saltstack客户端与服务端的关系）

    如果客户端很多，需要扩展服务端，haproxy采用轮询的话，客户端与服务端的tcp连接会不会经常断？

HAProxy 和后端 sever 也是一个独立的 TCP 连接，所以看你怎么配置了。HAProxy 到 sever 端也是可以配置 keepalive 的。

而 client 直接进行交互的是和 HAProxy listen 的 IP，这个也是一个 TCP 连接。

两个 TCP 连接都是独立的，HAProxy 通过 session table 维护他们之间的关系。两条 TCP 连接的配置都可以不一样的，分别对应在 frontend 和 backend 中。所以，连接要不要断开，是要看你的需求和配置。




   

Godbach

回复 106# 撒加

@撒加 的分享干活满满，都是实际的使用经验，赞！

可惜打分最多只能评 10 分。


   

Godbach

回复 106# 撒加

在使用Haproxy做四层负载均衡的时候，用户的真实IP需要使用tproxy来实现，同时需要iptable规则的支持，本来已经打算使用这种方式了，后来看到了Haproxy支持Proxy protocol的v1和v2版本，可以在不适用tproxy的方式下将用户的真实IP传递到后端。目前这种使用方法还是研究中，后期也打算用这种方式。

这个协议我倒没有仔细研究，欢迎研究完成之后分享一下。

感觉 tproxy 还是一个比较理想的将 client IP 传递给 server 的解决方法。