haproxy负载均衡配置文档分解.docx

基于haproxy的反向代理和负载均衡 1 安装 方法一: Centos下使用root权限,使用指令: yum install haproxy.x86_64 安装完成后程序位置:/usr/sbin/, 配置文件位置: /etc/haproxy/ 方法二:下载.gz压缩包, 解压, make make install (暂时无测试) 2 配置 以root权限打开/etc/haproxy/haproxy.cfg 默认配置文件已有模板, 简单改动即可实现代理和均衡 前端配置注释掉所有静态相关的配置(因为现在没有动静分离). Balance: 有roundrobin(轮询), source(ip哈希), weight(权重), url(网址)等, 更多的均衡方法请查看官方手册. Cookie: 设置cookie保持, 有rewrite, insert, prefix等, 具体说明请查看附录说明. Server: 设置后端服务器ip, cookie:设置cookie对应的server, check: 后端检查, weight: 权重设置. 附录I 1 cookie cookie name [ rewrite | insert | prefix ] [ indirect ] [ nocache ]????????????? [ postonly ] [ preserve ] [ domain domain ]*????????????? [ maxidle idle ] [ maxlife life ]sections :?? defaults | frontend | listen | backend??????????????? yes?? |??? no??? |?? yes? |?? yes Arguments :??? name cookie的名称，用于持久性的监视、修改和增加。cookie在response中通过Set-Cookie头发送给客户端，并由客户端的所有request的Cookie头返回。尤其注意不要与应用cookie重名。另外，如果相同客户端使用了相同的后端（如HTTP/HTTPS），如果不希望跨后端的持久性，也要注意使用不同的cookie名称。??? rewrite?? 表示cookie由服务器提供，haproxy必定要修改它的值，以包含服务器的标识符。这种模式便于应用来管理 Set-cookie 和 Cache-control头的复杂组合。应用可以决定是否适合发出一个持久性cookie。如果所有的响应都要被监控，则该模式只能工作在 HTTP close模式下。除非应用的行为很复杂和/或破碎（broken?），否则建议不要启动这个新的配置模式。关键字不能与insert 和 prefix共用。 ???????????? ??? insert??? 表示如果客户端还没有允许访问服务器的cookie，haproxy会在服务器响应中插入持久性cookie。????????????? 如果服务器发送了一个同名的cookie，当没有同时声明 preserve 选项时，它会在处理前被删掉。因此，这个模式可以用于升级“rewrite”模式下的已有配置。cookie只是一个会话cookie，而且不保存在客户端的磁盘中。 默认的，除非有选项 indirect ，服务器才会看到客户端发出的cookie。由于缓存的影响，通常明智的做法是添加关键字nocache or postonly 。关键字不能与 rewrite 和 prefix共用。??? prefix??? 持久性基于现有的cookie就可以，而不必依赖专门的cookie。在一些特殊的环境下需要使用，如客户端不支持多于一个cookie，而应用已经需要 了。这种情况下，每当服务器设置了cookie名字，haproxy就会在名字前添加一个服务器标识符和分隔符的前缀。前缀在所有客户端的请求中会被去 掉，所以服务器还是会找到发送的cookie。既然所有的响应和请求都要被修改，这个模式则需要运行在HTTP close模式下。关键字不能与 rewrite 和 insert共用。??? indirect?? 声明了该选项，没有cookie会被发送给客户端，即使客户端已经有一个合法的cookie给处理响应的服务器。如果服务器本身设置了这样一个cookie，也会被删除，除非同时设置了选项preserve。在insert模式下，还会删除发送给服务器的request的cookie。持久机制对应用是完全透明的。??? nocache? 如果在客户端和HAProxy之间有缓存，那么该选项建议与insert模式结合使用， 如果需要新增cookie，确保可缓存的respo