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

niao5929

官网被墙。上求不去。天朝家国！！MGBD

Godbach

回复 40# niao5929

niao5929 兄是老 CU 了。欢迎多多参与讨论。


   

Godbach

回复 41# niao5929

唉，是啊。被屏蔽快三年了。


   

niao5929

和谐（zhuanzhi）社会为什么总是惧怕新技术，因为因为新技术总是可以很容易的摆脱他们设置的墙。
今天听说了VMWARE的kb.vmware.com网站，一个收集各种VMWARE使用问题和解决方法的网站。而且本身也不需要必须是VMWARE的授权用户。很有点社区的味道。但这给不光是企业用户同时也给所有人带来了方便。我猜想这也是VMWARE能普及的一个重要因素。希望CU能继续保持纯粹的技术至上的宗旨。成为当下中文环境里更好的技术网站。回复 43# Godbach


   

Godbach

回复 44# niao5929



对于个人来说，只能尽力而为。

   

zmoon

1. 多年前听闻有千万用户级haproxy,一直没机会用到，直到去年在几个有HA和负载均衡需求的B/S应用项目中使用，效果相当好，会一直推广使用。
keepalived+haproxy，自带的web监控页面，不仅能监视，也能控制后端服务器节点平滑下线上线，那是相当好用，就这一点，直接选型打败nginx


2. 使用 HAProxy 中遇到了哪些问题，以及最终如何解决

A：功能很强，但资料太少，需要摸索 ，那个appsession 功能就很少资料提到，刚好能解决使用后端的Tomcat Session来做会话的负载均衡的问题
（对APP1到APP2 的这种内部会话访问， SOURCE IP方式效果很差，毕竟部署APP应用的IP地址数量不会太多）。

B： 通过条件判断功能来做后端切换的功能不是一般的强大，几乎可以判断http请求的任何一部分数据，可以写出如http强制切换到https方式的这种用法，或者反过来，并可对用户透明。

C： 对比Nginx或者httpd这些，最大一个问题，没有URLREWRITE转换功能 http://x.x.x.x/abc  没法转换成http://x.x.x.x/def ，只能从其他方面来将就。

D：缺少类似bsd pfsync 在多haproxy之间的session状态同步功能，但我们的应用用户可以接受某个haproxy服务器故障情况下，另一台haproxy服务器只做IP层接管，由用户进行刷页面重新登陆的操作。

3. 我们的应用都是企业内部使用，不面对互联网用户，所以haproxy性能可满足要求，性能不是关键因素，稳定性更重要
LVS 这些从未列入考虑，反而以前还用过一段时间的apache httpd 做代理和负载均衡。

另外 要访问官网可以这么玩   https://www.haproxy.org/

laputa73

回复 38# Godbach


    我们实测的就是这个方案。
   参考的
   http://rdc.gleasy.com/%E4%BD%BF% ... BB%A3%E7%90%86.html
   但是发现反向默认网关NAT方式的效率很低
   上千并发性能就很差了。
   是iptables性能问题吗？
   
   

stay_sun

回复 1# Godbach


    比较 HAProxy 和其他负载均衡软件。如果做过负载均衡方案选型，可以分享最终的选择以及原因
其实感觉让我选型的话还是看  做需求的吧  如果要是有 7层协议层的解析的话  肯定选择haproxy
如果   剩下的直接转发 会用lvs 对haproxy 还是了解的不够  楼主求讲解

Godbach

回复 46# zmoon

1. 多年前听闻有千万用户级haproxy,一直没机会用到，直到去年在几个有HA和负载均衡需求的B/S应用项目中使用，效果相当好，会一直推广使用。
keepalived+haproxy，自带的web监控页面，不仅能监视，也能控制后端服务器节点平滑下线上线，那是相当好用，就这一点，直接选型打败nginx

嗯，这一点是很多使用 HAProxy 的人，觉得比较爽的地方。

   

Godbach

回复 46# zmoon

2. 使用 HAProxy 中遇到了哪些问题，以及最终如何解决

A：功能很强，但资料太少，需要摸索 ，那个appsession 功能就很少资料提到，刚好能解决使用后端的Tomcat Session来做会话的负载均衡的问题
（对APP1到APP2 的这种内部会话访问， SOURCE IP方式效果很差，毕竟部署APP应用的IP地址数量不会太多）。

HAProxy 本是是支持 appsession，而且也介绍的配置的方法。其实实现上，仍然是通过 table 来记录映射关系的。

B： 通过条件判断功能来做后端切换的功能不是一般的强大，几乎可以判断http请求的任何一部分数据，可以写出如http强制切换到https方式的这种用法，或者反过来，并可对用户透明。

嗯，这个在专门的负载均衡产品中，比如 F5/A10 就称之为 content  switching.

D：缺少类似bsd pfsync 在多haproxy之间的session状态同步功能，但我们的应用用户可以接受某个haproxy服务器故障情况下，另一台haproxy服务器只做IP层接管，由用户进行刷页面重新登陆的操作。

应用层的 session 同步较为复杂，支持起来难度也大。HAProxy 当前能够支持的也是一些 table 的同步。

不过可以启用 KeepAlived + HAProxy 来实现主备模式。