haproxy负载均衡配置文档剖析

1、基于haproxy的反向代理和负载均衡1安装方法一：Centos 卜使用 root 权限,使用指令:yum install haproxy.x86_64wan耍localhost -$ yum search haproxyLoaded plugins: fastestmirror, refresh-packagekit, securityLoading mirror speeds from cached hostfilc* base: mirrors.yun-* extras: mirrors.yun-* updates: baseextrasupdatesupdates/primory_db

2、= N/S Matched: haproxy = haproxy.x86 64 : HAProxy is a TCP/HTTP reverse proxy for high availability environments安装完成后程序位置:/usr/sbin/,配置文件位置:/etc/haproxy/方法二:下载.gz压缩包 解压,make && make install （暂时无测试）2配置以 root 权限打开/etc/h叩roxy/haproxy.cfg默认配置文件已有模板，简单改动即可实现代理和均衡frontend main :5000力ccl url.static

3、path.beg-i /static /images /javascript /stylesheets#ccl url.staticpath.end-i .jpg .gif .png .css .jstfuse.backend staticif urjtaticdefault.backendapp前端配置注释掉所有静态相关的配置（因为现在没有动静分离）.backend appbalance roundrobincookie SERVERID insert indirect nocachecookie SERVERID rewriteserver oppl 8:8080 c

4、ookie appl check inter 1500 rise 3 fall 3 weight 1server app2 14:8082 cookie app2 check inter 1500 rise 3 fall 3 weight 2#scrvcr app3 :5003 check#scrver app4 :5004 checkBalance:有roundrobin（轮询），source（ip哈希）, weight（权重），url（网址）等，更多的均衡方法请 查看官方手册.Cookie:设置cookie保持，有rewrite,

5、insert, prefix等，具体说明请查看附录说明.Server:设置后端服务器ip, cookie:设置cookie对应的server, check:后端检查,weight:权重 设置.附录I1 cookiecookie <name> rewrite | insert | prefix indirect nocache postonly preserve domain <domain> *maxidie <idle> maxlife <life> sections : defaults | frontend | listen | backe

6、ndyes | no | yes | yesArguments :<name> cookie的名称,用于持久性的监视、修改和增加。cookie在 response中通过“Set-Cookie"头发送给客户端，并由客户端的所有request的 “Cookie头返回。尤其注意不要与应用cookie重名。另外，如果相同客户端使 用了相同的后端（如HTTP/HTTPS）,如果不希望跨后端的持久性，也要注意使 用不同的cookie名称。rewrite 表示cookie由服务器提供，haproxy必定要修改它的 值，以包含服务器的标识符。这种模式便于应用来管理Set-cookie和

7、Cache-control头的复杂组合。应用可以决定是否适合发出一个持久性 cookie。如果所有的响应都要被监控，则该模式只能工作在HTTP close模式 下。除非应川的行为很复杂和/或破碎（broken?）,否则建议不要启动这个新 的配置模式。关键字不能与 insert 和prefix共用。insert表示如果客户端还没有允许访问服务器的cookie,haproxy会在服务器响应中插入持久性cookie。如果服务器发送了一个同名的cookie,当没有 同时声明"preserve"选项时，它会在处理前被删掉。因此，这个模式可以用 于升级“rewrite”模式下的已有配置

8、。cookie只是一个会活cookie,而且不 保存在客户端的磁盘中。默认的，除非有选项"indirect”,服务器才会看到 客户端发出的cookie。由于缓存的影响，通常明智的做法是添加关键字 “nocache" or "postonly"。关键字不能与"rewrite"和"prefix”共用。prefix持久性基于现有的cookie就可以，而不必依赖专门的cookieo在一些特殊的环境下需要使用，如客户端不支持多于一个cookie,而 应用已经需要了。这种情况下，每当服务器设置了 cookie名字，haproxy就 会在

9、名字前添加一个服务器标识符和分隔符的前缀。前缀在所有客户端的请求 中会被去掉，所以服务器还是会找到发送的cookie。既然所有的响应和请求 都要被修改，这个模式则需要运行在HTTP close模式下。关键字不能与 “rewrite" 和 "insert共用。indirect声明了该选项，没有cookie会被发送给客户端，即使客户端已经有一个合法的cookie给处理响应的服务器。如果服务器本身设置了这 样一个cookie,也会被删除，除非同时设置了选项preserve"。在"insert"模 式下，还会删除发送给服务器的request的cooki

10、e。持久机制对应用是完全透 明的。nocache如果在客户端和HAProxy之间彳j缓存，那么该选项建议与"insert模式结合使用，如果需要新增cookie,确保可缓存的response标记 为非缓存的。这很重要，因为所有可持久的cookie都被加在实例的一个可缓存 的主页上，那么所有客户会从外部缓存获取页面，并都共享同样的持久 cookie,导致一个服务器处理了太多的负载。参见insert"和"postonly选 项。postonly 该选项使cookie只能增加在POST请求的响应中。与 “nocache选项只能二选一，因为POST响应是不可缓存的，所以持久

11、cookie是 绝不会被缓存的。笫一个POST一般都是登录请求，大部分站点在此之前不需 要任何持久性的排序，这可以避免在缓存中查找持久cookie,以有效优化缓 存。参见"insert"和"nocache”选项。preserve 该选项可以与"insert"和/或"indirect”一起使用。允 许服务器自己发送持久cookieo在这种情况下，如果在response中发现有 cookie,则HAProxy会对其保持不变。在实例的注销请求之后，需要用它来结 束持久性。此时，服务器只需要发送一个带有无效值（如：empty）或过去日期 的c

12、ookieo与disable-on-404”检查选项相结合，可以实现一个完全正常的 关闭，因为用户注销后一定会离开服务器。domain该选项用于指定cookie插入的域，后跟一个合法的域名参数。如果域名以点开头，浏览器允许任何以域名结尾的主机使用它。还可以通 过多此调用此选项来指 定多个域名，但要注意有的浏览器对域的个数是有限制 的。有记录说在MSIE6或Firefox2上发送10个域是可以的。max idle该选项允许在闲置时间后忽略插入的cookie,只对insert模式的cookie有效。当cookie发送到客户端，cookie的日期也被发送 过 去。进一步讲，如果日期早于参数（秒）表示

13、的延迟，cookie会被忽略， 否则会根据发送给客户端的响应进行刷新。尤其是用户一直不关闭浏览器，可 以避免在一台服务器上占用太长时间（eg: after a farm size change）。如 果设置了选项，但是cookie没有日期，这种情况是允许的，只是会一直在响应 中刷新。这维护了管理员访问他们站点的能力。cookie的日期如果超过未来 24小时也会被忽略掉，使管理员可以在修复时区问题时不必把用户踢下线。maxlife该选项允许在生存时间过后忽略插入的cookie,不管是否还在使用,只对insert模式的cookie有效。当cookie发送到客户 端， cookie的日期也被发送过去

14、。进一步讲，如果日期早于参数（秒）表示的延迟，cookie会被忽略。如果request中的cookie没有H期，则会被设置一个 日期。cookie的日期如果超过未来24小时也会被忽略掉，使管理员可以在修 复时区问题时不必把用户踢下线。与maxidle不同，这个值是不刷新的，只在 笫一次访问日期计数。maxidie和maxlife可以一起使用，尤其是用户一直不 关闭浏览器，可以避免在一台服务器上占用太长时间(eg： after a farm size change) o与maxidle的超时后强行重新分配相比，这个要更好一些。每个HTTP后端可以只有一个持久cookie,并定义在default部

15、分， cookie的值可以是server声明中cookie关键字后面的值。如果服务器没有 指定cookie,则不会设置。2 Balancebalance <algorithm> <arguments> balance url_param <param> check_post <max_wait>定义选择后端服务的负载均衡算法May be used in sections : defaults | frontend | listen | backendyes | no | yes | yesArguments :<algorithm>是

16、负载均衡时选择服务器的算法，没有持续信息时可用，或连接重定向到另 一个服务器。<algorithm>可以是以下几种：roundrobin每个服务器根据权重轮流使用，如果服务器的处理时间平均分布，这是最流 畅和公平的算法。算法是动态的，对于实例启动慢的服务器的权重会在运行中调整。每个 backend的活动服务器在设计上限制为4128个。在一些大的群里面，当服务器很短的宕机 后恢复回来，有时会有几百个请求被重新整合到群当中，并开始接收处理。尽管很少发生, 但是很正常。这也说明了有机会监视它们，所以不必担心。static-rr每个服务器根据权重轮流使用，类似roundrobin,但它是静

17、态的，意味着运行 时修改权重是无效的。另一方面，它对服务器的数量没有设计上的限制，服务器启动后便 会立即进到群中，整个分发方案会重新计算。这会略微降低CPU的运行(约1%)。leastconn连接数最低的服务器优先接收连接。Round-robin用于负载相同的服务器，使 每台服务器都被使用。leastconn建议用于长会话服务，例如LDAP, SQL,TSE等，而不是很适 合短会话协议，如HTTP。算法是动态的，对于实例启动慢的服务器的权重会在运行中调整。source对源IP地址进行哈希，用可用服务器的权重总数除以哈希值，根据结果进行分 配。只要服务器正常，同一个客户端IP地址总是访问同一台服

18、务器。如果哈希的结果随可 用服务器数量而变化，那么有的客户端会定向到不同的服务器。该算法一般用于不能插入 cookie的TCP模式。它还可以用于广域网上，为拒绝使用会话cookie的客户端提供最有效 的粘连。该算法默认是静态的，所以运行时修改服务器的权重是无效的，但是算法会根据 "hash-type"的变化做调整。uri 对URI左端(问号之前)进行哈希，用可用服务器的权重总数除以哈希值，根据结 果进行分配。只要服务器正常，同一个URI地址总是访问同一台服务器。一般用于代理缓 存和反病毒代理，以最大限度的提高缓存的命中率。该算法只能用于HTTP后端。该算法默 认是静态的，所

19、以运行时修改服务器的权重是无效的，但是算法会根据"hash-type”的变化 做调整。算法支持两个可选参数"len"和"depth",都是后跟正整数参数指定算法只 处理URI从头开始的字符数，据此计算哈希。因为大多URI以开头，所以“len”最好不要设 为"depth”参数指定URI中最大的路径深度，据此计算哈希。请求中的每个斜线为一级。 如果同时声明了这两个参数，则截取URI时必须同时满足。url_param在HTTP GET请求的查询串中查找param中指定的URL参数。若使用了修饰符"check_post"，

20、如果在URL问号(？)后面的查询串中找不到参数，就 会搜索HTTP POST请求实体。尾者在指定的一些字节后而尝试搜索消息体。如果搜索不到 实体，则使用round robin算法。例如，假设客户端总是在前128个字节发送LB参数，就 可以指定它。默认为48。如果到达网关的字节数量不够，实体数据是检索不到的，至少有： (default/max_wait, Content-Length or first chunk length ),如果 Conte nt-Length 没有或为 0, 就不需要等待客户端发送更多的数据。当Content-Length有值且大于max_wait,则等待 仅限于max

21、_wait,并假设有足够的数据用于搜索参数的存在。Transfer- Encoding被用 了，则只能检查第一个块。如果参数值被块边界分隔开，则只能随机均衡负载了。如果参数后面跟着('=')和一个值，则可以根据这个值进行哈希，用可用服务器的 权重总数除以哈希值，根据结果进行分配。还可用于跟踪请求中的用户身份，只要服务器正常，同一个用户ID的请求总是发 给同一台服务器。如果没有参数或参数没有值，则使用轮询算法。该算法只用于HTTP后端。 该算法默认是静态的，所以运行时修改服务器的权重是无效的，但是算法会根据"hash-type” 的变化做调整。hdr(name)在每个H

22、TTP请求中查找HTTP头name。与ACL函数'hdr()'一样。括号括起 来的头名字不区分大小写。如果缺少头或头没有任何值，则使用roundrobin算法代替。启用 参数lse_domain_onM，哈希算法将只用于一些类似，Ho端的特定头的主域部分。例如主机值 ”h叩roxy.lwt.eu",则只考虑"lwt"o该算法默认是静态的，所以运行时修改服务器的权重 是无效的，但是算法会根据"hash-type”的变化做调整。rdp-cookierdp-cookie(name)为每个进来的TCP请求查询并哈希RDP cookie name

23、(或"mstshash”如果省略)。 与ACL函数7eq_rdp_cookie()一样，name不区分大小写。该机制用于退化的持久模式，可 以使同一个用户(或同一个会话ID)总是发送给同一台服务器。如果没有cookie,则使用 roundrobin算法代替。必须注意该声明要生效,前端必须确保在请求缓冲中已经有RDPcookie, 所以必须使用规则 tcp-request content accept'和 ACL 'req_rdp_cookie_cnt'相结合。该算法默 认是静态的，所以运行时修改服务器的权重是无效的，但是算法会根据"hash-type

24、”的变化做 调整。arguments是用于一些算法的可选参数列表，目前只有“url_param"和“uri"用到，例如：balance uri len <len> depth <depth>balance url_param <param> check_post <max_wait>如果没有其他算法、模式或选项的设置，后端的负载均衡算法默认为roundrobin。每个后 端只能设置一种。附录II1与nginx代理的对比Nginx的优点：1. 性能好，可以负载超过1万的并发。2. 功能多，除了负载均衡，还能作Web服务器，而且可以通过Geo模块来实现流量分配。3. 社区活跃，第三方补丁和模块很多4. 支持 gzip proxy5. 工作在网络的7层之上，可以针对http