免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
查看: 4190 | 回复: 4

haproxy的一个简单的问题 [复制链接]

论坛徽章:
0
发表于 2012-11-14 10:09 |显示全部楼层
本帖最后由 webmultiple 于 2012-11-14 10:11 编辑

第一次测试使用haproxy做负载均衡用,怎么不能像lvs那样自动分配访问地址呢?
把配置文件帖出来,大家看一下**问题,我想实现的目的就是在别的机器上访问192.168.1.134时,安装在192.168.1.134上的haproxy按照轮循的方法返回192.168.1.133和192.168.1.135上的apache的页面。
  1. global
  2.         log 127.0.0.1   local0
  3.         maxconn 4096
  4.         chroot /usr/local/haproxy
  5.         uid 99
  6.         gid 99
  7.         daemon
  8.         nbproc 1
  9.         pidfile /usr/local/haproxy/haproxy.pid

  10. defaults
  11.         log     127.0.0.1       local3
  12.         mode    http
  13.         option httplog
  14.         option httpclose
  15.         option dontlognull
  16.         option forwardfor
  17.         option redispatch
  18.         retries 2
  19.         maxconn 2000
  20.         balance roundrobin
  21.         stats   uri     /haproxy-stats
  22.         stats  refresh 10s
  23.         stats  realm Haproxy \ statistic
  24.         stats auth admin:admin
  25.         contimeout      5000
  26.         clitimeout      50000
  27.         srvtimeout      50000

  28. listen web 192.168.71.134:80
  29.         #option httpchk HEAD /index.php  HTTP/1.0
  30.       server web1 192.168.71.135:80 weight 1 check inter 2000 rise 2 fall 5
  31.       server web2 192.168.71.133:80 weight 1 check inter 2000 rise 2 fall 5
复制代码

论坛徽章:
0
发表于 2012-11-14 10:13 |显示全部楼层
可是事实上确实在浏览器里输入192.168.71.134时页面显示的总是这台机器上的haproxy的主页,是haproxy这种反向代理,不像lvs那样轮循地址吗?那它怎么实现负载均衡呢?昨天配nginx也这么个情况,不知为什么

论坛徽章:
0
发表于 2012-11-14 10:46 |显示全部楼层
现在测试正常了,thanks

论坛徽章:
0
发表于 2012-11-19 10:22 |显示全部楼层
啥原因呢?说说啊。

论坛徽章:
1
数据库技术版块每日发帖之星
日期:2015-06-28 22:20:00
发表于 2012-11-19 10:37 |显示全部楼层
多看看Haproxy的配置参数,了解下haproxy的负载均衡的几种方法
balance 后面是负载均衡算法,haproxy给出了一下几个值作为负载均衡算法,大家可以根据自己的需求选择自己需要的负载均衡算法
roundrobin  每个服务器根据权重轮流使用,如果服务器的处理时间平均分布,这是最流畅和公平的算法。算法是动态的,对于实例启动慢的服务器的权重会在运行中调整。每个backend的活动服务器在设计上限制为4128个。在一些大的群里面, 当服务器很短的宕机后恢复回来,有时会有几百个请求被重新整合到群当中,并开始接收处理。尽管很少发生,但是很正常。这也说明了有机会监视它们,所以不必担心。

       static-rr  每个服务器根据权重轮流使用,类似roundrobin,但它是静态的,意味着运行时修改权重是无效的。另一方面,它对服务器的数量没有设计上的限制,服务器启动后便会立即进到群中,整个分发方案会重新计算。这会略微降低CPU的运行(约1%)。

       leastconn  连接数最低的服务器优先接收连接。Round-robin用于负载相同的服务器,使每台服务器都被使用。leastconn建议用于长会话服务,例如LDAP, SQL, TSE等,而不是很适合短会话协议,如HTTP。算法是动态的,对于实例启动慢的服务器的权重会在运行中调整。

       source    对源IP地址进行哈希,用可用服务器的权重总数除以哈希值,根据结果进行分配。只要服务器正常,同一个客户端IP地址总是访问同一台服务器。如果哈希的结果随可用服务器数量而变化,那么有的客户端会定向到不同的服务器。该算法一般用于不能插入cookie的TCP模式。它还可以用于广域网上,为拒绝使用会话cookie的客户端提供最有效的粘连。该算法默认是静态的,所以运行时修改服务器的权重是无效的,但是算法会根据"hash-type"的变化做调整。

       uri        对URI左端(问号之前)进行哈希,用可用服务器的权重总数除以哈希值,根据结果进行分配。只要服务器正常,同一个URI地址总是访问同一台服务器。一般用于代理缓存和反病毒代理,以最大限度的提高缓存的命中率。该算法只能用于HTTP后端。该算法默认是静态的,所以运行时修改服务器的权重是无效的,但是算法会根据"hash-type"的变化做调整。算法支持两个可选参数"len" 和 "depth", 都是后跟正整数。“len”参数指定算法只处理URI从头开始的字符数,据此计算哈希。因为大多URI以"/"开头,所以"len"最好不要设为1。"depth" 参数指定URI中最大的路径深度,据此计算哈希。请求中的每个斜线为一级。如果同时声明了这两个参数,则截取URI时必须同时满足。

url_param  在HTTP GET请求的查询串中查找<param>中指定的URL参数。若使用了修饰符"check_post",如果在URL问号('?')后面的查询串中找不到参数,就会搜索HTTP POST 请求实体。或者在指定的一些字节后面尝试搜索消息体。如果搜索不到实体, 则使用round robin算法。例如,假设客户端总是在前128个字节发送LB参数,就可以指定它。默认为48。如果到达网关的字节数量不够,实体数据是检索不到的,至少有:(default/max_wait, Content-Length or first chunk length)。如果Content-Length没有或为0,就不需要等待客户端发送更多的数据。当Content-Length有值且大于<max_wait>,则等待仅限于<max_wait>,并假设有足够的数据用于搜索参数的存在。万一Transfer-Encoding被用了,则只能检查第一个块。如果参数值被块边界分隔开,则只能随机均衡负载了。如果参数后面跟着 ('=') 和一个值,则可以根据这个值进行哈希,用可用服务器的权重总数除以哈希值,根据结果进行分配。还可用于跟踪请求中的用户身份,只要服务器正常,同一个用户ID的请求总是发给同一台服务器。如果没有参数或参数没有值,则使用轮询算法。该算法只用于HTTP后端。该算法默认是静态的,所以运行时修改服务器的权重是无效的,但是算法会根据"hash-type"的变化做调整。
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP