存档

‘HA-Linux集群技术/缓存加速/高负载/高可用’ 分类的存档

Nginx和LVS负载均衡的对比

2017年1月25日 评论已被关闭

Nginx和LVS负载均衡的对比
Nginx和LVS对比的总结:
Nginx工作在网络的7层,所以它可以针对http应用本身来做分流策略,比如针对域名、目录结构等,相比之下LVS并不具备这样的功能,所以Nginx单凭这点可利用的场合就远多于LVS了;但Nginx有用的这些功能使其可调整度要高于LVS,所以经常要去触碰触碰,触碰多了,人为出问题的几率也就会大。

Nginx对网络稳定性的依赖较小,理论上只要ping得通,网页访问正常,Nginx就能连得通,这是Nginx的一大优势!Nginx同时还能区分内外网,如果是同时拥有内外网的节点,就相当于单机拥有了备份线路;LVS就比较依赖于网络环境,目前来看服务器在同一网段内并且LVS使用direct方式分流,效果较能得到保证。另外注意,LVS需要向托管商至少申请多一个ip来做Visual IP,貌似是不能用本身的IP来做VIP的。要做好LVS管理员,确实得跟进学习很多有关网络通信方面的知识,就不再是一个HTTP那么简单了。

Nginx安装和配置比较简单,测试起来也很方便,因为它基本能把错误用日志打印出来。LVS的安装和配置、测试就要花比较长的时间了;LVS对网络依赖比较大,很多时候不能配置成功都是因为网络问题而不是配置问题,出了问题要解决也相应的会麻烦得多。

Nginx也同样能承受很高负载且稳定,但负载度和稳定度差LVS还有几个等级:Nginx处理所有流量所以受限于机器IO和配置;本身的bug也还是难以避免的。

Nginx可以检测到服务器内部的故障,比如根据服务器处理网页返回的状态码、超时等等,并且会把返回错误的请求重新提交到另一个节点。目前LVS中 ldirectd也能支持针对服务器内部的情况来监控,但LVS的原理使其不能重发请求。比如用户正在上传一个文件,而处理该上传的节点刚好在上传过程中出现故障,Nginx会把上传切到另一台服务器重新处理,而LVS就直接断掉了,如果是上传一个很大的文件或者很重要的文件的话,用户可能会因此而恼火。

Nginx对请求的异步处理可以帮助节点服务器减轻负载,假如使用 apache直接对外服务,那么出现很多的窄带链接时apache服务器将会占用大 量内存而不能释放,使用多一个Nginx做apache代理的话,这些窄带链接会被Nginx挡住,apache上就不会堆积过多的请求,这样就减少了相当多的资源占用。这点使用squid也有相同的作用,即使squid本身配置为不缓存,对apache还是有很大帮助的。

Nginx能支持http、https和email(email的功能比较少用),LVS所支持的应用在这点上会比Nginx更多。在使用上,一般最前端所采取的策略应是LVS,也就是DNS的指向应为LVS均衡器,LVS的优点令它非常适合做这个任务。重要的ip地址,最好交由LVS托管,比如数据库的 ip、webservice服务器的ip等等,这些ip地址随着时间推移,使用面会越来越大,如果更换ip则故障会接踵而至。所以将这些重要ip交给 LVS托管是最为稳妥的,这样做的唯一缺点是需要的VIP数量会比较多。Nginx可作为LVS节点机器使用,一是可以利用Nginx的功能,二是可以利用Nginx的性能。当然这一层面也可以直接使用squid,squid的功能方面就比Nginx弱不少了,性能上也有所逊色于Nginx。Nginx也可作为中层代理使用,这一层面Nginx基本上无对手,唯一可以撼动Nginx的就只有lighttpd了,不过lighttpd目前还没有能做到 Nginx完全的功能,配置也不那么清晰易读。另外,中层代理的IP也是重要的,所以中层代理也拥有一个VIP和LVS是最完美的方案了。具体的应用还得具体分析,如果是比较小的网站(日PV小于1000万),用Nginx就完全可以了,如果机器也不少,可以用DNS轮询,LVS所耗费的机器还是比较多的;大型网站或者重要的服务,机器不发愁的时候,要多多考虑利用LVS。

keepalived+nginx双机热备笔记

2016年11月13日 评论已被关闭

keepalived+nginx双机热备笔记
http://imkerwin.com/588.html
os版本:CentOS release 6.8 (Final)

内核:2.6.32-642.1.1.el6.x86_64

keepalived版本:keepalived-1.2.22

keepalive安装:(当然为了省事也可以直接 yum install keepalived)

1.安装前先解决依赖问题。
yum -y install gcc gcc+ gcc-c++
yum install popt-devel openssl openssl-devel libssl-dev libnl-devel popt-devel

2.源码包安装。去官网把keepalived-1.2.22.tar下载到本地,解压,进入目录,./configure,make,make install

3.拷贝文件。(因个人安装目录会有区别,请留意绝对路径,和你本地保持一致)
cp /usr/local/sbin/keepalived /usr/sbin/
cp /usr/local/etc/rc.d/init.d/keepalived /etc/init.d/
cp /usr/local/etc/sysconfig/keepalived /etc/sysconfig/

4.启动&停止。
service keepalived start/stop /etc/init.d/keepalived start/stop

5.配置文件keepalived.conf说(理论上是指定/etc/keepalived/keepalived.conf这个,因为我启动的时候查看日志说启动这个)

=======================================================================

配置文件:

[root@lmsc-nginx1 ~]# cat /etc/keepalived/keepalived.conf
global_defs {
router_id LVS_DEVEL
}
#监测nginx进程状态,每2秒执行一次
vrrp_script chk_nginx {
script “/data/scripts/chk_nginx.sh” #检测脚本路径
interval 2
weight 2
}
vrrp_instance VI_1 {
state MASTER #从服务器为BACKUP
interface eth0 #绑定vip的网卡
virtual_router_id 51
priority 100 #从服务器要低于100
advert_int 1
mcast_src_ip XXXX.XXXX.XXXX.XXXX #MASTER服务器IP,从服务器写从服务器的IP
authentication {
auth_type PASS
auth_pass 111111
}
track_script {
chk_nginx #监测nginx进程状态
}
virtual_ipaddress {
XXXX.XXXX.XXXX.XXXX #虚拟IP 也就是vip
}
}

上面的配置适用于物理机,但是一般的云主机,对方会在路由上限制arp协议广播的那就需要改一下配置了,将mcast_src_ip XXXX.XXXX.XXXX.XXXX这段修改成下面(阿里云,金山云就需要如下配置)

unicast_src_ip XXXX.XXXX.XXXX.XXXX##(本地IP地址)

unicast_peer {

XXX.XXX.XXX.XXX##(对端IP地址)此地址一定不能忘记

}

====================================================================

检测脚本:chk_nginx.sh

#!/bin/bash
A=`ps -C nginx –no-header |wc -l`
if [ $A -eq 0 ];then
/data/nginx/sbin/nginx
sleep 3
if [ `ps -C nginx –no-header |wc -l` -eq 0 ];then
killall keepalived
fi
fi

重点配置的地方已经加了#号并且说明,主机和备机的配置文件差别也就服务器IP和priority的值不同,其他都一样,因此就不列出来了,另外还可以加上smtp的相关参数用于报警,这个我认为没有必要,因为我本地有zabbix。

6.keepalived日志 (/var/log/messages)。

7.测试成败,在主机杀掉keepalived进程,虚拟ip会自动漂移到备机。

8.遇到的问题,主和备都出现了绑定vip的情况,可以适用tcpdump vrrp命令看看是否有数据包进来,确定是否防火墙问题,主备之间vrrp包能否正常通讯,各自判定各自服务器已挂导致。解决方法,主备之间互相放行varrp iptables -A INPUT -i eth0 -p vrrp -s 主/备 -j ACCEPT

keepalived可以服务后,就剩下nginx的配置了,nginx的配置这里不多说了。

搭建LVS负载均衡环境,出现SYN_RECV状态的处理

2016年7月13日 评论已被关闭

搭建LVS负载均衡环境,出现SYN_RECV状态的处理
http://blog.csdn.net/xabc3000/article/details/8622133
第一次搭建LVS+KEEPALIVED环境时挺顺利的,过一段时间后重新搭建此环境时居然出问题,不管怎么配置修改参数,客户端总是连接不上realserver,通过ipvsadm -lc查看,结果如下:
CP 00:54 SYN_RECV h100:12949 192.168.4.200:5678 h104:5678
通过艰难的对比,查找资料,终于找到了问题的原因,在此鄙视一下百度,找出来的资源一点用都没有。
闲话少说,原因如下:
realserver的服务监听IP我选择了监听指定的IP,即eth0的IP,而未监听lo,即本地地址,那么即使收到了由directoryserver转发的请求,通过本地广播给本机的lo:0,因为服务没有监听lo,所以也不会有响应。
杯具啊,花了我那么多时间………………
realserver的ifconfig结果如下:
eth0 Link encap:Ethernet HWaddr 00:30:48:C8:7D:CA
inet addr:192.168.10.55 Bcast:192.168.15.255 Mask:255.255.240.0
inet6 addr: fe80::230:48ff:fec8:7dca/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:5369998 errors:0 dropped:0 overruns:0 frame:0
TX packets:357128 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:493767975 (470.8 MiB) TX bytes:181277721 (172.8 MiB)
Memory:fbee0000-fbf00000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:11414 errors:0 dropped:0 overruns:0 frame:0
TX packets:11414 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:3994708 (3.8 MiB) TX bytes:3994708 (3.8 MiB)
lo:0 Link encap:Local Loopback
inet addr:192.168.4.200 Mask:255.255.255.255
UP LOOPBACK RUNNING MTU:16436 Metric:1

Bug#649106: syncid ‘fix’ breaks state sync in init script completely

2016年7月4日 评论已被关闭

 

Bug#649106: syncid ‘fix’ breaks state sync in init script completely
Hans van Kranenburg Fri, 13 Mar 2015 07:34:38 -0700
https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1308990.html
On 03/13/2015 01:09 PM, Alexander Wirt wrote:
Would you mind to test the attached patch?

Yes.

Without the patch I see the ‘ipvsadm -h’ errors and on stop even weird “Memory allocation problem” errors. I have no idea why. Worse, systemd just says: “SUCCESS”, both on start and stop…:

# systemctl start ipvsadm
# systemctl status ipvsadm
● ipvsadm.service – LSB: ipvsadm daemon
Loaded: loaded (/etc/init.d/ipvsadm)
Active: active (exited) since Fri 2015-03-13 15:05:19 CET; 1s ago
Process: 2760 ExecStop=/etc/init.d/ipvsadm stop (code=exited, status=0/SUCCESS) Process: 2926 ExecStart=/etc/init.d/ipvsadm start (code=exited, status=0/SUCCESS)

Mar 13 15:05:19 lb-bassie ipvsadm[2926]: Starting IPVS Connection Synchronization Daemon: masterTry `/sbin/ipvsadm -h’ or ‘/sb…mation. Mar 13 15:05:19 lb-bassie ipvsadm[2926]: backupTry `/sbin/ipvsadm -h’ or ‘/sbin/ipvsadm –help’ for more information.
Mar 13 15:05:19 lb-bassie ipvsadm[2926]: failed!
Mar 13 15:05:19 lb-bassie systemd[1]: Started LSB: ipvsadm daemon.
Hint: Some lines were ellipsized, use -l to show in full.
# ps afxu | grep ipvs
root 3079 0.0 0.4 12720 2152 pts/0 S+ 15:05 0:00 \_ grep ipvs
# systemctl stop ipvsadm
# systemctl status ipvsadm
● ipvsadm.service – LSB: ipvsadm daemon
Loaded: loaded (/etc/init.d/ipvsadm)
Active: inactive (dead) since Fri 2015-03-13 15:08:24 CET; 1s ago
Process: 3820 ExecStop=/etc/init.d/ipvsadm stop (code=exited, status=0/SUCCESS) Process: 2926 ExecStart=/etc/init.d/ipvsadm start (code=exited, status=0/SUCCESS)

Mar 13 15:05:19 lb-bassie ipvsadm[2926]: Starting IPVS Connection Synchronization Daemon: masterTry `/sbin/ipvsadm -h’ or ‘/sb…mation. Mar 13 15:05:19 lb-bassie ipvsadm[2926]: backupTry `/sbin/ipvsadm -h’ or ‘/sbin/ipvsadm –help’ for more information.
Mar 13 15:05:19 lb-bassie ipvsadm[2926]: failed!
Mar 13 15:05:19 lb-bassie systemd[1]: Started LSB: ipvsadm daemon.
Mar 13 15:08:24 lb-bassie systemd[1]: Stopping LSB: ipvsadm daemon…
Mar 13 15:08:24 lb-bassie ipvsadm[3820]: Stopping IPVS Connection Synchronization Daemon: masterMemory allocation problem
Mar 13 15:08:24 lb-bassie ipvsadm[3820]: backupMemory allocation problem
Mar 13 15:08:24 lb-bassie ipvsadm[3820]: failed!
Mar 13 15:08:24 lb-bassie systemd[1]: Stopped LSB: ipvsadm daemon.
Hint: Some lines were ellipsized, use -l to show in full.

And with the patch, it’s like this:

# systemctl start ipvsadm
# systemctl status ipvsadm
● ipvsadm.service – LSB: ipvsadm daemon
Loaded: loaded (/etc/init.d/ipvsadm)
Active: active (exited) since Fri 2015-03-13 15:01:51 CET; 1s ago
Process: 1747 ExecStop=/etc/init.d/ipvsadm stop (code=exited, status=0/SUCCESS) Process: 1859 ExecStart=/etc/init.d/ipvsadm start (code=exited, status=0/SUCCESS)

Mar 13 15:01:51 lb-bassie ipvsadm[1859]: Starting IPVS Connection Synchronization Daemon: master backup.
Mar 13 15:01:51 lb-bassie systemd[1]: Started LSB: ipvsadm daemon.
# ps afxu | grep ipvs
root 1862 0.0 0.0 0 0 ? S 15:01 0:00 \_ [ipvs-m:0:0] root 1864 0.0 0.0 0 0 ? S 15:01 0:00 \_ [ipvs-b:0:0] root 1917 0.0 0.4 12720 2112 pts/0 S+ 15:02 0:00 \_ grep ipvs
# systemctl stop ipvsadm
# systemctl status ipvsadm
● ipvsadm.service – LSB: ipvsadm daemon
Loaded: loaded (/etc/init.d/ipvsadm)
Active: inactive (dead) since Fri 2015-03-13 15:02:05 CET; 1s ago
Process: 1938 ExecStop=/etc/init.d/ipvsadm stop (code=exited, status=0/SUCCESS) Process: 1859 ExecStart=/etc/init.d/ipvsadm start (code=exited, status=0/SUCCESS)

Mar 13 15:01:51 lb-bassie ipvsadm[1859]: Starting IPVS Connection Synchronization Daemon: master backup.
Mar 13 15:01:51 lb-bassie systemd[1]: Started LSB: ipvsadm daemon.
Mar 13 15:02:05 lb-bassie systemd[1]: Stopping LSB: ipvsadm daemon…
Mar 13 15:02:05 lb-bassie ipvsadm[1938]: Stopping IPVS Connection Synchronization Daemon: master backup.
Mar 13 15:02:05 lb-bassie systemd[1]: Stopped LSB: ipvsadm daemon.
# ps afxu | grep ipvs
root 1976 0.0 0.4 12720 2152 pts/0 S+ 15:02 0:00 \_ grep ipvs

So, that’s ok!


Hans van Kranenburg – System / Network Engineer
+31 (0)10 2760434 | hans.van.kranenb…@mendix.com | www.mendix.com

To UNSUBSCRIBE, email to debian-bugs-dist-requ…@lists.debian.org
with a subject of “unsubscribe”. Trouble? Contact listmas…@lists.debian.org

HAproxy均衡负载部署和配置文件详解

2016年6月1日 评论已被关闭

HAproxy均衡负载部署和配置文件详解

http://my.oschina.net/duxuefeng/blog/35232?fromerr=2ax7tc3l

HAProxy提供高可用性负载均衡以及基于TCPHTTP应用的代理,支持虚拟主机,它是免费、快速并且可靠的一种解决方案。根据官方数据,其最高极限支持10G的并发。

HAProxy特别适用于那些负载特大的web站点, 这些站点通常又需要会话保持或七层处理。HAProxy运行在当前的硬件上,完全可以支持数以万计的并发连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中, 同时可以保护你的web服务器不被暴露到网络上。

其支持从4层至7层的网络交换,即覆盖所有的TCP协议。就是说,Haproxy 甚至还支持 Mysql 的均衡负载。。

如果说在功能上,能以proxy反向代理方式实现 WEB均衡负载,这样的产品有很多。包括 NginxApacheProxylighttpdCheroke 等。 

但要明确一点的,Haproxy 并不是 Http 服务器。以上提到所有带反向代理均衡负载的产品,都清一色是 WEB 服务器。简单说,就是他们能自个儿提供静态(html,jpg,gif..)或动态(php,cgi..)文件的传输以及处理。而Haproxy 仅仅,而且专门是一款的用于均衡负载的应用代理。其自身并不能提供http服务。

但其配置简单,拥有非常不错的服务器健康检查功能还有专门的系统状态监控页面,当其代理的后端服务器出现故障, HAProxy会自动将该服务器摘除,故障恢复后再自动将该服务器加入。自1.3版本开始还引入了frontend,backend,frontend根据任意HTTP请求头内容做规则匹配,然后把请求定向到相关的backend

另外, 版本1.3 是处于活跃开发阶段的版本, 它支持如下新特性:

l         内容交换 : 可以根据请求(request)的任何一部分 来选择一组服务器, 比如请求的 URI , Host(header) , cookie , 以及其他任何东西. 当然,对那些静态分离的站点来说,对此特性还有更多的需求。 

l         全透明代理 : 可以用 客户端IP地址 或者任何其他地址来连接后端服务器. 这个特性仅在Linux 2.4/2.6内核打了cttproxy 补丁后才可以使用. 这个特性也使得为某特殊服务器处理部分流量同时又不修改服务器的地址成为可能。
 

l         基于树的更快的调度器 : 1.2.16以上的版本要求所有的超时都设成同样的值以支持数以万计的全速连接. 这个特性已经移植到1.2.17. 

l         内核TCP拼接 : 避免了内核到用户然后用户到内核端的数据拷贝, 提高了吞吐量同时又降低了CPU使用率 . Haproxy 1.3支持Linux L7SW 以满足在商用硬件上数Gbps 的吞吐的需求。 

l         连接拒绝 : 因为维护一个连接的打开的开销是很低的,有时我们很需要限制攻击蠕虫(attack bots),也就是说限制它们的连接打开从而限制它们的危害。 这个已经为一个陷于小型DDoS攻击的网站开发了而且已经拯救了很多站点。 

l         细微的头部处理 : 使得编写基于header的规则更为简单,同时可以处理URI的某部分。 

l         快而可靠的头部处理 : 使用完全RFC2616 兼容的完整性检查对一般的请求全部进行分析和索引仅仅需要不到2ms 的时间。 

l         模块化设计 : 允许更多人加入进此项目,调试也非常简单. poller已经分离, 已经使得它们的开发简单了很多. HTTP已经从TCP分离出来了,这样增加新的七层特性变得非常简单. 其他子系统也会很快实现模块化 

l         投机I/O 处理 : 在一个套接字就绪前就尝试从它读取数据。poller仅推测哪个可能就绪哪个没有,尝试猜测,并且如果成功,一些开销很大的系统调用就可以省去了。如果失败,就会调用这些系统调用。已知的使用Linux epoll()已经净提升起码10%了。 

l         ACLs : 使用任意规则的任意组合作为某动作的执行条件。
 

l         TCP 协议检查 : 结合ACL来对请求的任意部分进行检查,然后再进行转发。这就可以执行协议验证而不是盲目的进行转发。比如说允许SSL但拒绝SSH
 

l         更多的负载均衡算法 : 现在,动态加权轮循(Dynamic Round Robin),加权源地址哈希(Weighted Source Hash),加权URL哈希和加权参数哈希(Weighted Parameter Hash)已经实现。其他算法比如Weighted Measured Response Time也很快会实现。 

安装:

        1、从官网 http://haproxy.1wt.eu/#down 下载最新版本,如  haproxy-1.4.16.tar.gz   
2、解压缩, # tar zcvf haproxy-1.4.16.tar.gz  建议移动到工作目录  /usr/local/haproxy/ 下,否则后续安装时还要用PREFIX=/usr/local/haprpxy指定安装路径
3、运行 make install 即完成安装
程序为 /usr/local/haproxy  或  /usr/local/sbin/haproxy, 运行程序 haproxy,显示版本信息即说明安装成功
文档在/usr/local/doc/haproxy下
Man:/usr/local/share/man/man1

配置:    # vi haproxy.cfg

配置内容如下:

global                                #全局设置
        log 127.0.0.1   local0 #日志输出配置,所有日志都记录在本机,通过local0输出
        #log 127.0.0.1  local1 notice
        #log loghost    local0 info

       ulimit-n 82000       #设置每个进程的可用的最大文件描述符
        maxconn 4096        #最大连接数
        chroot /usr/local/haproxy    #
改变当前工作目录
        uid 99                       #所属运行的用户uid
        gid 99                       #所属运行的用户组
        daemon                   #以后台形式运行ha-proxy
        nbproc 3                 #启动2个ha-proxy实例

        pidfile /usr/local/haproxy/run/haproxy.pid     #pid文件位置
        debug        #调试模式,输出启动信息到标准输出
        #quiet     #安静模式,启动时无输出

defaults                       #默认设置
log     global
log     127.0.0.1       local3        #日志文件的输出定向
mode    http                            #所处理的类别,默认采用http模式,可配置成tcp作4层消息转发
option  httplog                        #日志类别,采用httplog
option  httpclose   #每次请求完毕后主动关闭http通道,ha-proxy不支持keep-alive,只能模拟这种模式的实现

option  dontlognull
option  forwardfor  #如果后端服务器需要获得客户端真实ip需要配置的参数,可以从Http Header中获得客户端ip

option  redispatch
retries 2                      #3次连接失败就认为服务器不可用,主要通过后面的check检查          

        maxconn 2000         #最大连接数
balance roundrobin                     #负载均衡算法
stats   uri     /haproxy-stats        #haproxy 监控页面的访问地址,可通过http://ip/haproxy-stats访问
contimeout      5000                     #连接超时时间
clitimeout      50000                  #客户端连接超时时间
srvtimeout      50000              #服务器端连接超时时间

listen app-balancer 0.0.0.0:80
mode http
#  log 127.0.0.1 local3
#cookie ServerID insert nocache
cookie ServerID prefix
cookie JSESSIONID prefix

        capture request header Cookie len 200
capture request header X-Forwarded-For len 15
capture request header Host len 15
capture request header Referrer len 15

        appsession JSESSIONID len 52 timeout 1080000
balance roundrobin
option httpchk GET /ok.jsp HTTP/1.0   #健康检查
server app_1 192.168.0.243:8080 cookie app1 minconn 100 maxconn 40960 check inter 5000 rise 2 fall 5 weight 2
server app_2 192.168.0.242:8080 cookie app2 minconn 100 maxconn 40960 check inter 2000 rise 2 fall 5 weight 2
server app_4 192.168.0.245:8080 cookie app2 minconn 100 maxconn 40960 check inter 2000 rise 2 fall 5 weight 1
#option forwardfor except 192.168.0.159
option forwardfor
stats enable
stats uri /haproxy-stat
stats realm “test_123 monitor”
stats auth admin:admin

运行:

启动服务:
# /usr/local/haproxy/sbin/haproxy -f /usr/local/haproxy/haproxy.cfg

重启服务:
# /usr/local/haproxy/sbin/haproxy -f /usr/local/haproxy/haproxy.cfg -st `cat /usr/local/haproxy/logs/haproxy.pid`  (没有换行)

停止服务:
# killall haproxy

当然,为了方便系统在开机时加载,还可以创建启动脚本:
# vim /etc/rc.d/init.d/haproxy  内容如下:

#! /bin/sh
set -e

PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/haproxy/sbin
PROGDIR=/usr/local/haproxy
PROGNAME=haproxy
DAEMON=$PROGDIR/sbin/$PROGNAME
CONFIG=$PROGDIR/conf/$PROGNAME.conf
PIDFILE=$PROGDIR/run/$PROGNAME.pid
DESC=”HAProxy daemon”
SCRIPTNAME=/etc/init.d/$PROGNAME

# Gracefully exit if the package has been removed.
test -x $DAEMON || exit 0

start()
{
echo -n “Starting $DESC: $PROGNAME”
$DAEMON -f $CONFIG
echo “.”
}

stop()
{
echo -n “Stopping $DESC: $PROGNAME”
haproxy_pid=cat $PIDFILE
kill $haproxy_pid
echo “.”
}

restart()
{
echo -n “Restarting $DESC: $PROGNAME”
$DAEMON -f $CONFIG -p $PIDFILE -sf $(cat $PIDFILE)
echo “.”
}

case “$1” in
start)
start
;;
stop)
stop
;;
restart)
restart
;;
*)
echo “Usage: $SCRIPTNAME {start|stop|restart}” >&2
exit 1
;;
esac 
exit 0

保存后赐予可执行权限
# chmod +x /etc/rc.d/init.d/haproxy

就可以使用 service haproxy start|stop|restart 来控制服务的启动停止跟重启。
并通过以下命令加载到开机服务启动列表
# chkconfig –add haproxy

配置日志:
# vim /etc/syslog.conf

在最下边增加
local3.*         /var/log/haproxy.log
local0.*         /var/log/haproxy.log

重启核心日志服务使配置起效
# service syslog restart

然后就可查看日志了
# tail –f /var/log/harpoxy.log

Aug 22 15:32:06 localhost haproxy[64136]: Proxy www started. 
Aug 22 15:32:06 localhost haproxy[64136]: Proxy cherokee started. 
Aug 22 15:32:06 localhost haproxy[64136]: Proxy wap started. 
Aug 22 15:32:06 localhost haproxy[64136]: Proxy pic started. 
Aug 22 15:32:06 localhost haproxy[64136]: Proxy img started. 
Aug 22 15:32:06 localhost haproxy[64136]: Proxy public started. 
Aug 22 15:32:06 localhost haproxy[64136]: Proxy public started. 
Aug 22 15:32:59 localhost haproxy[64137]: 219.142.128.30:6416 [22/Aug/2009:15:32:59.754] public stats/<STATS> 0/-1/-1/-1/0 200 17329 – – PR– 0/0/0/0/0 0/0 “GET /?stats HTTP/1.1” 
Aug 22 15:32:59 localhost haproxy[64137]: 219.142.128.30:6416 [22/Aug/2009:15:32:59.754] public stats/<STATS> 0/-1/-1/-1/0 200 17329 – – PR– 0/0/0/0/0 0/0 “GET /?stats HTTP/1.1”

应用举例

WEB 均衡负载虚拟主机 

重新打开配置文件haproxy.cfg,留意最下部分的均衡主机选项
listen  localhost 0.0.0.0:1080                   #运行的端口及主机名
mode    http
option  httpchk GET /index.htm              #用于健康检测的后端页面
server  s1 127.0.0.1:3121 weight 3 check    #后端的主机 IP &权衡
server  s2 127.0.0.1:3122 weight 3 check    #后端的主机 IP &权衡

在实验中,我们的的后端是 squid 分开了2个端口在同一台服务器上。
以其中一项为例:

server  s1 127.0.0.1:3121 weight 3 check

s1             是可自己定义的服务器别名
127.0.0.1:3121   服务器的IP地址以及端口号
weight 3        所能分配到请求的高低权衡,数字越大分配到的请求数就越高
check          接受 haproxy 的定时检查,以确定后端服务器的健康情况。

如需配置虚拟主机,相当简单,紧需修改 localhost 为你虚拟主机的的域名,加到haproxy配置中, 再为其分配后端服务器的参数即可。

 例:

listen  www.x1.com 0.0.0.0:1080                    #运行的端口及主机名
mode    http
option  httpchk GET /index.htm              #用于健康检测的后端页面
server  s1 127.0.0.1:3121 weight 3 check  #后端的主机 IP &权衡
server  s2 127.0.0.1:3122 weight 3 check  #后端的主机 IP &权衡

listen  www.x2.com 0.0.0.0:1080                     #运行的端口及主机名
mode    http
option  httpchk GET /index.htm                     #用于健康检测的后端页面
server  s1 127.0.0.1:3121 weight 3 check       #后端的主机 IP &权衡
server  s2 127.0.0.1:3122 weight 3 check       #后端的主机 IP &权衡

保存配置后重新加载,即可生效,刷新管理页面也可看到新的虚拟主机。

性能对比

在此,我们用最近最火红的http 兼前端WEB均衡负载服务器Nginx 与Haproxy 做个简单的性能对比。

测试环境:

CPU:Xeon2.8G X2
RAM:4G
OS:RedHat As5.3 X64

工具:apache ab
参数:ab -i -c 500 -n 100000  (500并发,1W请求)
最终服务端:2个squid 需实现均衡负载

成绩如下:

####### Nginx + haproxy :  (由Nginx通过反向代理发送请求至haproxy, 并由其进行均衡负载)

Concurrency Level:      500
Time taken for tests:   53.758 seconds
Complete requests:      100000
Failed requests:        0
Write errors:           0
Total transferred:      38600386 bytes
HTML transferred:       0 bytes

Requests per second:    1860.19 [#/sec] (mean)
Time per request:       268.790 [ms] (mean)
Time per request:       0.538 [ms] (mean, across all concurrent requests)
Transfer rate:          701.21 [Kbytes/sec] received
####### haproxy :  (单独由haproxy进行均衡负载)
Concurrency Level:      500
Time taken for tests:   32.562 seconds
Complete requests:      100000
Failed requests:        0
Write errors:           0
Total transferred:      36606588 bytes
HTML transferred:       0 bytes
Requests per second:    3071.02 [#/sec] (mean)
Time per request:       162.812 [ms] (mean)
Time per request:       0.326 [ms] (mean, across all concurrent requests)
Transfer rate:          1097.85 [Kbytes/sec] received
####### nginx : (单独由nginx进行均衡负载)
Concurrency Level:      500
Time taken for tests:   36.539 seconds
Complete requests:      100000
Failed requests:        0
Write errors:           0
Total transferred:      38600000 bytes
HTML transferred:       0 bytes
Requests per second:    2736.82 [#/sec] (mean)
Time per request:       182.694 [ms] (mean)
Time per request:       0.365 [ms] (mean, across all concurrent requests)
Transfer rate:          1031.65 [Kbytes/sec] received

反复测试,得出其结果:
Haproxy 单独进行均衡负载的性能最强,超过了Nginx。
然而 Nginx + Haproxy 的搭配性能最弱,应该是跟通过了2层反向代理有关。
所以想用 Haproxy 替代 Nginx 所自带的均衡负载功能将会令性能打折。
但虽然如此 Haproxy 对均衡负载功能远比 Nginx 成熟,例如session粘贴,cookies 引导等都是 nginx 所没有的。
可根据需要而选择搭配。
相关启动参数介绍

相关启动参数介绍 

   #./haproxy –help //haproxy相关命令参数介绍.

   haproxy  -f  <配置文件>  

[-n 最大并发连接总数] [-N 每个侦听的最大并发数] [-d] [-D] [-q] [-V] [-c] [-p <pid文件>] [-s] [-l] [-dk]

       [-ds] [-de] [-dp] [-db] [-m <内存限制M>] [{-sf|-st} pidlist…]

       -d     前台,debug模式

       -D     daemon模式启动

       -q     安静模式,不输出信息

       -V     详细模式

       -c     对配置文件进行语法检查

       -s     显示统计数据

       -l     显示详细统计数据

       -dk    不使用kqueue

       -ds    不使用speculative epoll

       -de    不使用epoll

       -dp    不使用poll

       -db    禁用后台模式,程序跑在前台

       -sf <pidlist>      程序启动后向pidlist里的进程发送FINISH信号,这个参数放在命令行的最后

       -st <pidlist>      程序启动后向pidlist里的进程发送TERMINATE信号,这个参数放在命令行的最后

附:一个比较简单的配置文件内容

global
log 127.0.0.1   local0
maxconn 4096
chroot /usr/local/haproxy
uid 99
gid 99
daemon
nbproc 1
pidfile /usr/local/haproxy/haproxy.pid
debug #quiet
defaults
log     127.0.0.1       local3
mode    http
option httplog
option httpclose
option dontlognull
option forwardfor
option redispatch
retries 2
maxconn 2000
balance roundrobin
contimeout      5000
clitimeout      50000
srvtimeout      50000 
 
listen webinfo :1080
mode http
balance roundrobin
option httpclose
option forwardfor
server phpinfo1 192.168.18.2:10000 check weight 1 minconn 1 maxconn 3 check inter 40000
server phpinfo2 127.0.0.1:80 check weight 1 minconn 1 maxconn 3 check inter 40000
 
listen webmb :1081
mode http
balance roundrobin
option httpclose
option forwardfor
server webmb1 192.168.1.91:10000 weight 1 minconn 1 maxconn 3 check inter 40000
server webmb2 127.0.0.1:10000 weight 1 minconn 1 maxconn 3 check inter 40000
 
listen stats :8888
mode http
transparent
stats uri / haproxy-stats
stats realm Haproxy \ statistic
stats auth admin:admin

HAproxy 配置详解

2016年6月1日 评论已被关闭

HAproxy 配置详解
http://www.linuxidc.com/Linux/2014-01/94648.htm
一  haproxy  简介
HAProxy提供高可用性、负载均衡以及基于TCP和HTTP应用的代理,支持虚拟主机,它是免费、快速并且可靠的一种解决方案。HAProxy特别适用于那些负载特大的web站点,这些站点通常又需要会话保持或七层处理。HAProxy运行在当前的硬件上,完全可以支持数以万计的并发连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中,同时可以保护你的web服务器不被暴露到网络上.

二 haproxy 的配置
haproxy 配置中分成五部分内容,分别如下:
1 global:参数是进程级的,通常是和操作系统相关。这些参数一般只设置一次,如果配置无误,就不需要再次进行修改
2 defaults:配置默认参数,这些参数可以被用到frontend,backend,Listen组件
3 frontend:接收请求的前端虚拟节点,Frontend可以更加规则直接指定具体使用后端的backend
4 backend:后端服务集群的配置,是真实服务器,一个Backend对应一个或者多个实体服务器
5 Listen Fronted和backend的组合体

三 haproxy 安装配置
1 安装
# wget http://haproxy.1wt.eu/download/1.4/src/haproxy-1.4.24.tar.gz
# tar  xf  haproxy-1.4.24.tar.gz
#uname  -r
2.6.18-274.el5PAE
#make  TARGET=linux26PREFIX=/usr/local/haproxy
#make install PREFIX=/usr/local/haproxy
#mkdir /usr/local/haproxy/{etc,logs,run}
#cd  examples/
#cp haproxy.cfg /usr/local/haproxy/etc
#cp  haproxy.init/etc/init.d/haproxy
#chmod 700 /etc/init.d/haproxy
#chkconfig  –add haproxy
#chkconfig  haproxy on

#cat  haproxy.cfg
##全局配置信息###
global
log 127.0.0.1 local3 #[error warringinfo debug]#定义haproxy 日志级别
#      log 127.0.0.1  local1 notice
#log loghost    local0 info
maxconn 20480  #默认最大连接数
chroot /usr/local/haproxy #chroot运行路径
uid 99                    #运行haproxy 用户 UID
gid 99                    #运行haproxy 用户组gid
daemon                    #以后台形式运行harpoxy
nbproc 1                  #设置进程数量
pidfile /usr/local/haproxy/run/haproxy.pid #haproxy 进程PID文件
ulimit-n 819200  #ulimit 的数量限制
#debug        #haproxy 调试级别,建议只在开启单进程的时候调试
#quiet

####默认配置选项#######

defaults
log    global
mode    http        #所处理的类别(7层代理http,4层代理tcp)
maxconn 50000      #最大连接数
option  httplog    #日志类别为http日志格式
option  httpclose  #每次请求完毕后主动关闭http通道
option  dontlognull  #不记录健康检查日志信息
option  forwardfor  #如果后端服务器需要获得客户端的真实ip,需要配置的参数,可以从http header 中获取客户端的IP
retries 3            #3次连接失败就认为服务器不可用,也可以通过后面设置
option redispatch  #serverID 对应的服务器挂掉后,强制定向到其他健康的服务器
stats refresh 30    # 设置统计页面刷新时间间隔
option abortonclose  #当服务器负载很高的时候,自动结束掉当前队列处理比较久的连接
balance roundrobin    #设置默认负载均衡方式,轮询方式
#balance source        # 设置默认负载均衡方式,类似于nginx的ip_hash
#balnace leastconn    #设置默认负载均衡方式,最小连接数
contimeout 5000      #设置连接超时时间
clitimeout 50000      #设置客户端超时时间
srvtimeout 50000      #设置服务器超时时间
timeout check  2000  #设置心跳检查超时时间
#timeout http-request  10s  #默认http请求超时时间
#timeoutqueue          1m    #默认队列超时时间
#timeoutconnect        10s  #默认连接超时时间
#timeoutclient        1m    #默认客户端超时时间
#timeoutserver        1m    #默认服务器超时时间
#timeout http-keep-alive10s  #默认持久连接超时时间

#########设置监控页面######
listen  admin_status
bind 0.0.0.0:81          #设置Frontend和Backend的组合体,监控组的名称,按需要自定义名称
mode http                #设置http的7 层模式层
log 127.0.0.1 local3 err  #错误日志记录
stats refresh 30s          #设置监控页面刷新时间:5s
stats uri  /haproxy-stats  # 设置监控页面的url
stats realm  Frank \Frank #设置页面提示信息
stats auth admin:admin    #设置监控页面的用户和密码:admin,可以设置多个用户名
stats auth  Frank:Frank  #设置监控页面的用户和密码:Frank
stats hide-version        #隐藏统计页面的HAproxy版本信息
stats  admin if TRUE      #设置手工启动/禁用,后端服务器(haproxy-1.4.9以后版本)

########设置haproxy 错误页面#####

errorfile 403 /usr/local/haproxy/errorfiles/403.http
errorfile 500 /usr/local/haproxy/errorfiles/500.http
errorfile 502 /usr/local/haproxy/errorfiles/502.http
errorfile 503 /usr/local/haproxy/errorfiles/503.http
errorfile 504 /usr/local/haproxy/errorfiles/504.http

##### 设置frontend#########

frontend http_80_in
bind 0.0.0.0:80          #设置监听端口,即haproxy提供的web服务端口,和lvs的vip 类似
mode http                # http 的7层模式
log global                #应用全局的日志设置
option httplog            #启用http的log
option httpclose          #每次请求完毕后主动关闭http通道,HA-proxy不支持keep-alive模式
option forwardfor          #如果后端服务器需要获得客户端的真实IP需要配置此参数,将可以从HttpHeader中获得客户端IP

####acl 策略配置######
acl  frank_web hdr_reg(host)  -i ^(www.test.com.sh|news.test.com.sh)$
#如果请求的域名满足正则表达式中的2个域名返回true -i 是忽略大小写
# acl frank_fund  hdr_dom(host)  -i fund.test.com.sh
#如果请求的域名满足fund.test.com.sh返回true -i是忽略大小写
acl frank    hdr(host) -i test.com.sh
#如果请求的域名满足test.com.sh返回true -i是忽略大小写
#acl file_req url_sub -i  killall=
#在请求url中包含killall=,则此控制策略返回true,否则为false
# acl dir_req url_dir -i allow
#在请求url中存在allow作为部分地址路径,则此控制策略返回true,否则返回false
acl missing_cl hdr_cnt(Content-length)eq 0
#当请求的header中Content-length等于0时返回true
#### Manage interface ####
acl Frank_Manage path_dir /Frank/manage/
acl Frank_Network src  192.168.151.189 192.168.152.0/24
## deny lb.html###
acl Frank_lb  path /lb.html

########acl策略匹配相应#############

block if Frank_lb
block if Frank_Manage !Frank_Network
#block if missing_cl
#当请求中header中Content-length等于0阻止请求返回403
#block if !file_req || dir_req
#block表示阻止请求,返回403错误,当前表示如果不满足策略file_req,或者满足策略dir_req,则阻止请求
redirect prefix http://192.168.151.249code 301 if frank
#当访问test.com.sh的时候,用http的301挑转到http://192.168.151.249
use_backend  server_web if frank_web
#当满足frank_web的策略时使用server_web的backend
#use_backend  server_blog if frank_fund
#当满足frank_fund的策略时使用server_blog的backend
default_backend server_web
#以上都不满足的时候使用默认server_bbs的backend

##########backend的设置##############
####################backend  server_web#########################
123456789101112 backendserver_web
mode http            #http的7层模式
balance roundrobin  #负载均衡的方式,roundrobin平均方式
cookie etnetchinaid insert indirectnocache domain .test.com.sh maxidle 20s maxlife 30s #允许插入serverid到cookie中,serverid后面可以定义
#      cookie SERVERID insert indirect nocache
#      appsession  JSESSIONID len 64 timeout 300s request-learn
option httpchk GET /lb.html HTTP/1.0 #心跳检测的文件
server 192.168.51.78 192.168.151.78:80cookie cookie78 check inter 1500 rise 3 fall 3 weight 1
#服务器定义,cookie 1表示serverid为web1,check inter1500是检测心跳频率rise 3是3次正确认为服务器可用,
#fall 3是3次失败认为服务器不可用,weight代表权重
server 192.168.151.79 192.168.151.79:80cookie cookie79 check inter 1500 rise 3 fall 3 weight 1
#服务器定义,cookie 1表示serverid为web2,check inter1500是检测心跳频率rise 3是3次正确认为服务器可用,  #fall 3是3次失败认为服务器不可用,weight代表权重

Haproxy 配置项\配置实例

2016年6月1日 评论已被关闭

Haproxy 配置项\配置实例

 http://www.cnblogs.com/dkblog/archive/2012/03/13/2393321.html

常用配置选项:

 

OPTION 选项:

option httpclose :HAProxy会针对客户端的第一条请求的返回添加cookie并返回给客户端,客户端发送后续请求时会发送

此cookie到HAProxy,HAProxy会针对此cookie分发到上次处理此请求的服务器上,如果服务器不能忽略

此cookie值会影响处理结果。如果避免这种情况配置此选项,防止产生多余的cookie信息。

option forwardfor :如果服务器上的应用程序想记录发起请求的客户端的IP地址,需要在HAProxy上配置此选项,这样

HAProxy会把客户端的IP信息发送给服务器,在HTTP请求中添加”X-Forwarded-For”字段。

option originalto :如果服务器上的应用程序想记录发起请求的原目的IP地址,需要在HAProxy上配置此选项,这样HAProxy

会添加”X-Original-To”字段。

option dontlognull :保证HAProxy不记录上级负载均衡发送过来的用于检测状态没有数据的心跳包。

 

BALANCE 选项:

balance source :如果想让HAProxy按照客户端的IP地址进行负载均衡策略,即同一IP地址的所有请求都发送到同一服务

器时,需要配置此选项。

balance roundrobin :HAProxy把请求轮流的转发到每一个服务器上,依据每台服务器的权重,此权重会动态调整。最常

见的默认配置。

 

COOKIE 选项:

cookie JSESSIONID prefix :如果客户端只支持一个cookie,并且服务器上的应用程序已经对返回设置了cookie,

HAProxy设置此选项可以改写应用程序设置的cookie信息,把服务器的信息添加到原cookie中去。

cookie SERVERID indirect :HAProxy会删除添加的cookie信息,避免此cookie信息发送到服务器。

cookie SERVERID rewrite :

cookie SERVERID insert :

cookie SERVERID insert nocache :

cookie SERVERID insert postonly :

option httpclose
no option httpclose
Enable or disable passive HTTP connection closing   启用或禁止消极的HTTP连接关闭
May be used in sections :   defaults | frontend | listen | backend
yes   |    yes   |   yes  |   yes
Arguments : none

默认的,客户端与服务端的通讯,HAProxy只做分析、日志和分析每个连接的第一个request。如果设置了 “option
httpclose” , 则会检查双向的http头是否有”Connection: close”,如果没有则自动添加,使每个客户端或服务端在每次传输后,都会主动关闭TCP连接,使HTTP传输处于HTTP close模式下。任何 “Connection” 头如果不是”close”,都会被移除。

很少会有服务器不正确的忽略掉头,即使收到”Connection: close”也不关闭连接,否则就是不兼容HTTP 1.0浏览器标准。 如果发生这种情况,可以使用”option forceclose”,在服务端响应后主动关闭请求连接。选项 “forceclose”还可以及早释放服务连接,而不必等到客户端的应答确认。

这个选项可以设置在frontend或backend上,只要其上可以建立连接。如果同时设置了”option forceclose”,那么它比”httpclose”优先。如果同时设置了 “option http-server-close”,则会实现”option forceclose”的效果。

option forceclose
no option forceclose

Enable or disable active connection closing after response is transferred.     启用或禁止response后的主动关闭连接

May be used in sections :   defaults | frontend | listen | backend
yes   |    yes   |   yes  |   yes

Arguments : none
有的HTTP服务器收到”option httpclose”设置的”Connection: close”,也不会关闭连接,如果客户端也不关闭,连接会 一直打开,直到超时。这会造成服务器上同一时段内的大量连接,日志中也会显示较高的全局会话时间。

此时,可以使用 “option forceclose”,当完成响应时,立即关闭对外的服务通道。该选项隐式打开httpclose选项。需要注意,该选项允许解析完整的request 和 response,所以可以很快关闭至服务器的连接,比httpclose更早释放一些资源。
如果同时启用了”option http-pretend-keepalive”,虽然会禁止发送 “Connection: close”头,但是依然会在整个response被接收后,关闭连接。

option http-server-close
no option http-server-close
Enable or disable HTTP connection closing on the server side  启用或禁止关闭服务端的HTTP连接
May be used in sections :   defaults | frontend | listen | backend
yes   |    yes   |   yes  |   yes
Arguments : none
默认的,客户端与服务端通讯,haproxy 只是分析、记日志,并处理每个连接的第一个请求。该选项设置server端为HTTP 连接关闭模式,并支持客户端为HTTP keep-alive的pipelining模式。提供了最低的客户端延迟和最快的服务端会话重用,以节省服务资源,类似”option forceclose”。还允许无keepalive能力的服务端在keep-alive模式下为客户端提供服务,但是需要符合 RFC2616。需要注意的是,有些服务器遇到”Connection: close” 时并不总是执行关闭,那么keep-alive 则无法使用,解决方法是启用 “option http-pretend-keepalive”.

目前,日志无法指明请求是否来自同一会话;日志中的接收日期为前一个请求的结束;请求时间为新请求的等待时间;keep-alive request time 存活请求时间为超时时间,绑定 “timeout http-keep-alive” 或 “timeout http-request”的设置。
这个操作可以设置在frontend或backend上,只要其上可以建立连接。需要注意的是,这个选项可以与 “option httpclose”结合, 但 “option httpclose”优先级更高,结合后基本实现了forceclose的效果。

option http-pretend-keepalive (http-假装-长连接)
no option http-pretend-keepalive
Define whether haproxy will announce keepalive to the server or not  定义 haproxy 与服务器是否是 keepalive 的。
May be used in sections :   defaults | frontend | listen | backend
yes   |    yes   |   yes  |   yes
Arguments : none
当声明了 “option http-server-close” 或 “option forceclose”, haproxy会在给server的request头中添加 “Connection: close” 。然而有些服务器看到这个头,会返回未知长度的response,并自动避免chunked encoding,其实这是不对的。它会阻止haproxy保持客户端长连接,还会使客户端或缓存接收了未完成的响应,却认为响应结束了。
设置 “option http-pretend-keepalive”, haproxy会在服务器端保持长连接,服务端则不会出现前面的问题。当 haproxy 获取了完整的response, 才会以类似forceclose的方式关闭服务端。这样客户端得到一个普通的响应,连接也在服务端被正常关闭。
建议不将其设为默认值,因为大部分服务器会在发送完最后一个包之后更高效的关闭连接,并释放缓存,而且网络上的数据包也会略微降低整体的峰值性能。但是启用该选项,haproxy会略微少做一些工作。所以如果haproxy在整个架构中是个瓶颈,可以启用该操作,以节省CPU。

这个选项可以设置在frontend或backend上,只要其上可以建立连接。这个选项可以与 “option httpclose”结合, 使服务端keepalive,客户端close,但并不建议这样做。

balance <algorithm> [ <arguments> ]
balance url_param <param> [check_post [<max_wait>]]
定义选择后端服务的负载均衡算法
May be used in sections :   defaults | frontend | listen | backend
yes   |    no    |   yes  |   yes
Arguments :
<algorithm> 是负载均衡时选择服务器的算法,没有持续信息时可用,或连接重定向到另一个服务器。<algorithm> 可以是以下几种:
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”的变化做调整。

hdr(name)  在每个HTTP请求中查找HTTP头<name>。与ACL函数’hdr()’一样。括号括起来的头名字不区分大小写。如果缺少头或头没有任何值,则使用roundrobin算法代替。
启用参数’use_domain_only’,哈希算法将只用于一些类似’Host’的特定头的主域部分。例如主机值”haproxy.1wt.eu”,则只考虑 “1wt”。该算法默认是静态的,所以运行时修改服务器的权重是无效的,但是算法会根据”hash-type”的变化做调整。

rdp-cookie
rdp-cookie(name)
为每个进来的TCP请求查询并哈希RDP cookie <name> (或“mstshash”如果省略) 。与ACL函数 ‘req_rdp_cookie()’一样,name不区分大小写。该机制用于退化的持久模式,可以使同一个用户(或同一个会话ID)总是发送给同一台服务器。如果没有cookie, 则使用roundrobin算法代替。
必须注意该声明要生效,前端必须确保在请求缓冲中已经有RDP cookie,所以必须使用规则tcp-request content accept’ 和ACL ‘req_rdp_cookie_cnt’相结合。
该算法默认是静态的,所以运行时修改服务器的权重是无效的,但是算法会根据”hash-type”的变化做调整。

<arguments> 是用于一些算法的可选参数列表,目前只有”url_param” 和 “uri” 用到,例如:
balance uri [len <len>] [depth <depth>]
balance url_param <param> [check_post [<max_wait>]]

如果没有其他算法、模式或选项的设置,后端的负载均衡算法默认为roundrobin。每个后端只能设置一种。
Examples :
balance roundrobin
balance url_param userid
balance url_param session_id check_post 64
balance hdr(User-Agent)
balance hdr(host)
balance hdr(Host) use_domain_only

注意:  以下的警告和限制是使用“check_post“扩展和”url_param”所必须考虑 :
– 所有POST请求都要考虑,因为在包含二进制数据的体或实体中,没有办法决定是否会找到参数。因此需要另一种方法,限制POST请求的体中不含有URL参数 (见 acl reqideny http_end)

– 大于请求缓冲大小的 <max_wait> 值是没用的。在build时设置缓冲大小,默认16KB。
– 不支持Content-Encoding, 参数搜索会失败;负载均衡会改用 Round Robin。
– 预计: 不支持100-continue,负载均衡会改用 Round Robin。
– Transfer-Encoding (RFC2616 3.6.1) 只在第一个块中支持。如果在第一个块中的参数值不完整,选择的服务器就没有定义。(实际上取决于在第一个块中定义的有多小)
– 该特性不支持生成100, 411 或 501 响应。
–  有的情况下,需要”check_post”只是要查看整个消息体的内容。检查一般会停在任意数量的空格(LWS: linear
white space)或控制符上,表示这可能是一个URL参数列表。这可能不是一个关于SGML的类型消息体。

See also : “dispatch”, “cookie”, “appsession”, “transparent”, “hash-type” and “http_proxy”.

 

hash-type <method>
将哈希映射到服务器的方法。Specify a method to use for mapping hashes to servers
May be used in sections :   defaults | frontend | listen | backend
yes   |    no    |   yes  |   yes
Arguments :
map-based  哈希表是包含所有在线服务器的静态数组。哈希结果很平滑,并考虑了权重,但是会忽略服务器启动时的权重变化,也就是说不能慢启动。另外,服务器是根据数组中的位置所选择的,所以服务器数量变化时,大部分映射也会变化。当一台服务器启动或关闭,或服务器加入到群中,大部分连接会再分配给不同的服务器,这对有缓存的实例会比较麻烦。

consistent  哈希表是由每个服务器构成的树,会在树上查找哈希Key,并选择最近的服务器。这种哈希是动态的,支持服务器启动时修改权重,所以可以慢启动。它有一个好处是当服务器启动或关闭时,只有其本身的关系被移除,当服务器加入群时,只有一小部分的映射会被重新分配,所以是一个比较理想的支持缓存的算法。但是根据其原理,算法不会非常平滑,有时候必须调整服务器的权重或ID来获得更平衡的分布。要保持多次负载均衡时的相同分布,服务器ID是绝对不能变的。(roloand:haproxy根据服务器的ID初始化其哈希值)
默认值是”map-based”,建议大部分情况下使用。

See also : “balance”, “server”
dispatch <address>:<port>
设置一个默认的服务器地址
May be used in sections :   defaults | frontend | listen | backend
no    |    no    |   yes  |   yes
Arguments : none
<address> 默认服务器的IPv4地址,也可以是主机名称,名称只在启动时解析为IP地址。
<ports>  端口号,所有连接都会发送给这个端口,但是不允许像其他服务器一样使用端口偏移(port offsets)。

“dispatch”关键字指定了一个默认的服务器,用于无可用服务器时的连接的处理。过去常用于前传非持久连接给后备负载均衡器,由于定义简单,还用于简单的TCP中继(TCP relays)。 建议对于明确的连接处理,应使用”server”直接声明。

====================

一:Global parameters
* Process management and security
– chroot 改变当前工作目录
– daemon 运行方式为后台工作
– user – group 工作用户和组
-log <address> <facility>日志输出设备
– nbproc 创建工作的进程数目
-pidfile pid文件位置
– ulimit-n 设置每个进程的可用的最大文件描述符
– stats 创建监控所用的套接字目录
– node 创建另外一个节点名字共用一个IP地址,用来识别哪个节点在处理流量
– description 描述实例的名称
maxconn <number> 每个进程可用的最大连接数
maxpipes <number>  每个进程可用的最大管道数
nokqueue  nopoll  nosepoll nosplice  禁用这些功能
spread-checks <0..50, in percent>  health check 的时间间隔
tune.bufsize <number>
tune.maxaccept <number>
tune.maxpollevents <number>
tune.maxrewrite <number>
tune.rcvbuf.client <number>
tune.rcvbuf.server <number>
tune.sndbuf.client <number>
tune.sndbuf.server <number>
以上凭字面理解吧
debug  调试模式,输出启动信息到标准输出
quiet   安装模式,启动时无输出

二:defaults 块
作用于其后紧跟的listen块,直至下一个defaults 块,下一个default 将替换上一个块作用于以后的listen
frontend 块,接受请求的端口组
backend块,后端处理的server 组
listen块,frontend和backend 块的结合

三:常用配置命令

balance <algorithm> [ <arguments> ]
balance url_param <param> [check_post [<max_wait>]]   负载均衡模块设置

Examples :
balance roundrobin
balance url_param userid
balance url_param session_id check_post 64
balance hdr(User-Agent)
balance hdr(host)
balance hdr(Host) use_domain_only

block { if | unless } <condition>  在7层阻止访问
Example:
acl invalid_src src 0.0.0.0/7 224.0.0.0/3  acl定义和squid 很像
acl invalid_src src_port 0:1023
acl local_dst hdr(host) -i localhost
block if invalid_src || local_dst

capture cookie <name> len <length>  在请求和回应包中捕捉记录指定长度的cookie,name 为cookie的开头几个字母

Example:
capture cookie ASPSESSION len 32

capture request header <name> len <length>
capture response header <name> len <length> 同上

clitimeout <timeout> (deprecated)
contimeout <timeout> (deprecated)  客户端超时时间,不赞成设置

cookie <name> [ rewrite | insert | prefix ] [ indirect ] [ nocache ] [ postonly ] [ domain <domain> ]*   允许持续的基于cookie 的后端连接

default_backend <backend> 默认应用的后端

Example :
use_backend dynamic if url_dyn
use_backend static if url_css url_img extension_img
default_backend dynamic    当没有匹配时就用dynamic

errorfile <code> <file> 定义出现错误的代码的返回页
Example :
errorfile 400 /etc/haproxy/errorfiles/400badreq.http
errorfile 403 /etc/haproxy/errorfiles/403forbid.http
errorfile 503 /etc/haproxy/errorfiles/503sorry.http

errorloc <code> <url> errorloc302 <code> <url>   出错重定向到指定url
force-persist { if | unless } <condition>  在特定条件下,强制继续连接down 掉的服务器后端
fullconn <conns>  定义后端组的最大连接数
grace <time>  haproxy停止后,再持续多长时间用于处理连接
http-check disable-on-404  如果后端检测返回404,将不再把后端计入负载均衡
http-check send-state 允许haproxy 发送 X-Haproxy-Server-State
http-request { allow | deny | http-auth [realm <realm>] } [ { if | unless } <condition> ]   七层访问控制
Example:
acl nagios src 192.168.129.3
acl local_net src 192.168.0.0/16
acl auth_ok http_auth(L1)

http-request allow if nagios
http-request allow if local_net auth_ok
http-request auth realm Gimme if local_net auth_ok
http-request deny

Example:
acl auth_ok http_auth_group(L1) G1

http-request auth unless auth_ok

mode { tcp|http|health }   设定启动的实例的协议类型
monitor fail { if | unless } <condition>  监控失败条件设置

option abortonclose 丢弃由于客户端等待时间过长而关闭连接但仍在haproxy等待队列中的请求
option accept-invalid-http-request  接受无效的http请求,建议关闭(开启可能有安全隐患)
option accept-invalid-http-response 接受无效的response ,建议关闭
option allbackups  应该是后备服务器,如果正常的后端无法使用,就使用这些后备的设备,balance方式还是用原来的,没有优先的选择,常用来提供错误的页面
option checkcache    分析后端response,阻止可缓存的cookie,它对response 进行严格检查,包括”Cache-control”, “Pragma” and “Set-cookie” ,查看在客户端代理那边保存是否有风险,如果这个允许的话,符全以下条件 的response 将被允许,其它的将被阻止。
– all those without “Set-Cookie” header ;
– all those with a return code other than 200, 203, 206, 300, 301, 410,
provided that the server has not set a “Cache-control: public” header ;
– all those that come from a POST request, provided that the server has not
set a ‘Cache-Control: public’ header ;
– those with a ‘Pragma: no-cache’ header
– those with a ‘Cache-control: private’ header
– those with a ‘Cache-control: no-store’ header
– those with a ‘Cache-control: max-age=0’ header
– those with a ‘Cache-control: s-maxage=0’ header
– those with a ‘Cache-control: no-cache’ header
– those with a ‘Cache-control: no-cache=”set-cookie”‘ header
– those with a ‘Cache-control: no-cache=”set-cookie,’ header
(allowing other fields after set-cookie)

option clitcpka   是否允许客户端发送tcp keepalive 包,这个和http 的keepalive 没有关系
option contstats   允许连续的流量统计更新
option dontlog-normal   开启正常连接的日志
option dontlognull   记录空连接
option forceclose  允许关闭session 在后端把response 发送后
option forwardfor [ except <network> ] [ header <name> ]        允许在request 中加入X-Forwarded-For header 发往server
option http-pretend-keepalive    定义是否haproxy要宣布同server keepalive
option http-server-close   是否开启在server 端 connection closing
option http-use-proxy-header    用non-standard Proxy-Connection 替换 connection

option httpchk <method> <uri> <version>  允许用http协议检查server 的健康
Examples :
# Relay HTTPS traffic to Apache instance and check service availability
# using HTTP request “OPTIONS * HTTP/1.1” on port 80.
backend https_relay
mode tcp
option httpchk OPTIONS * HTTP/1.1\r\nHost:\ www
server apache1 192.168.1.1:443 check port 80

option httplog [ clf ] 定制日志格式
option http_proxy  开启http 代理模式,只有最基本的代理功能
option ignore-persist { if | unless } <condition> 在某条件下拒绝持续连接,适用于对静态文件的负载均衡
option independant-streams  启用双向超时处理,如socket 的read 和write
option log-health-checks   记录健康检查日志
option log-separate-errors   对非完全成功的连接改变日志记录等级
option logasap   大传输大文件时可以提前记录日志
option mysql-check   mysql 健康检查
option nolinger  清除肮脏连接后开成的tcp 状态及占用的资源,不过并不是强列要求你用这个选项,当然如果你有thousands of FIN_WAIT1 sessions on your system ,那肯定得用了
option originalto [ except <network> ] [ header <name> ]   允许在requests中加入X-Original-To header 发往server
option persist     强制将http请求发往已经down 掉的server
option redispatch   是否允许重新分配在session 失败后
option smtpchk   smtp 检查
option socket-stats  允许对单个socket进行统计
option srvtcpka  是否允许向server 发送keepalive
option tcpka 是否允许向server和client发送keepalive
option tcplog  允许记录tcp 连接的状态和时间
option transparent   允许客户端透明代理
rate-limit sessions <rate> 设置frontend 每秒处理的连接的上限,如果到达上限就停止建立新的connection

redirect location <to> [code <code>] <option> [{if | unless} <condition>]
redirect prefix   <to> [code <code>] <option> [{if | unless} <condition>] 重定向,相当于rewrite

Example: move the login URL only to HTTPS.
acl clear      dst_port  80
acl secure     dst_port  8080
acl login_page url_beg   /login
acl logout     url_beg   /logout
acl uid_given  url_reg   /login?userid=[^&]+
acl cookie_set hdr_sub(cookie) SEEN=1

redirect prefix   https://mysite.com set-cookie SEEN=1 if !cookie_set
redirect prefix   https://mysite.com           if login_page !secure
redirect prefix   http://mysite.com drop-query if login_page !uid_given
redirect location http://mysite.com/           if !login_page secure
redirect location / clear-cookie USERID=       if logout

Example: send redirects for request for articles without a ‘/’.
acl missing_slash path_reg ^/article/[^/]*$
redirect code 301 prefix / drop-query append-slash if missing_slash
redisp (deprecated)
redispatch (deprecated) 开启session 重新分配在connection连接失败后,不赞成启用
reqadd  <string> [{if | unless} <cond>] 在http请示的末尾加上string

Example : add “X-Proto: SSL” to requests coming via port 81
acl is-ssl  dst_port       81
reqadd      X-Proto:\ SSL  if is-ssl

reqallow  <search> [{if | unless} <cond>]
reqiallow <search> [{if | unless} <cond>] (ignore case)    request 请求访问控制

Example :
# allow www.* but refuse *.local
reqiallow ^Host:\ www\.
reqideny  ^Host:\ .*\.local

reqdel  <search> [{if | unless} <cond>]
reqidel <search> [{if | unless} <cond>]  (ignore case) 删除请求的head 中的内容

Example :
# remove X-Forwarded-For header and SERVER cookie
reqidel ^X-Forwarded-For:.*
reqidel ^Cookie:.*SERVER=

reqdeny  <search> [{if | unless} <cond>]
reqideny <search> [{if | unless} <cond>]  (ignore case) 拒绝访问

reqrep  <search> <string> [{if | unless} <cond>]
reqirep <search> <string> [{if | unless} <cond>]   (ignore case)  request 请求替换
Example :
# replace “/static/” with “/” at the beginning of any request path.
reqrep ^([^\ ]*)\ /static/(.*)     \1\ /\2
# replace “www.mydomain.com” with “www” in the host name.
reqirep ^Host:\ www.mydomain.com   Host:\ www

reqtarpit  <search> [{if | unless} <cond>]
reqitarpit <search> [{if | unless} <cond>]  (ignore case) 阻止http请求中的某些信息

Examples :
# ignore user-agents reporting any flavour of “Mozilla” or “MSIE”, but
# block all others.
reqipass   ^User-Agent:\.*(Mozilla|MSIE)
reqitarpit ^User-Agent:

# block bad guys
acl badguys src 10.1.0.3 172.16.13.20/28
reqitarpit . if badguys

retries <value> 当对server的connection失败后,重试的次数
rspadd <string> [{if | unless} <cond>] response 增加信息
rspdel  <search> [{if | unless} <cond>]
rspidel <search> [{if | unless} <cond>]  (ignore case)
rspdeny  <search> [{if | unless} <cond>]
rspideny <search> [{if | unless} <cond>]  (ignore case)
rsprep  <search> <string> [{if | unless} <cond>]
rspirep <search> <string> [{if | unless} <cond>]  (ignore case)
以上和request 的差不多

source <addr>[:<port>] [usesrc { <addr2>[:<port2>] | client | clientip } ] 定义从代理出去的连接的对象,用于限定地址可以访问server

一些timeout

srvtimeout <timeout> server 处理超时,不赞成设置
timeout check                             X          –         X         X
timeout client                            X          X         X         –
timeout clitimeout          (deprecated)  X          X         X         –
timeout connect                           X          –         X         X
timeout contimeout          (deprecated)  X          –         X         X
timeout http-keep-alive                   X          X         X         X
timeout http-request                      X          X         X         X
timeout queue                             X          –         X         X
timeout server                            X          –         X         X
timeout srvtimeout          (deprecated)  X          –         X         X
timeout tarpit                            X          X         X         X

stats auth <user>:<passwd> 监控统计的帐号和密码
backend public_www
server srv1 192.168.0.1:80
stats enable
stats hide-version
stats scope   .
stats uri     /admin?stats
stats realm   Haproxy\ Statistics
stats auth    admin1:AdMiN123
stats auth    admin2:AdMiN321

# internal monitoring access (unlimited)
backend private_monitoring
stats enable
stats uri     /admin?stats
stats refresh 5s

还有很多参数,以上能用到的也没有几个,只要满足当前需求就好,对于性能要求高的话,建议把不需要的功能 都关了吧.

====================

HAProxy的配置示例

HAProxy配置中分成五部分内容,当然这些组件不是必选的,可以根据需要选择部分作为配置。
global:参数是进程级的,通常和操作系统(OS)相关。这些参数一般只设置一次,如果配置无误,就不需要再次配置进行修改
defaults:配置默认参数的,这些参数可以被利用配置到frontend,backend,listen组件
frontend:接收请求的前端虚拟节点,Frontend可以根据规则直接指定具体使用后端的 backend(可动态选择)。
backend:后端服务集群的配置,是真实的服务器,一个Backend对应一个或者多个实体服务器。
listen:Frontend和Backend的组合体。

下面是HAProxy的一些常用的配置,这个配置是用来说明HAProxy的一些常用功能的配置,具体详细配置请查看安装目录下的doc目录下的文档文件,或者到http://cn.haproxy.org/下载中文配置说明文档

配置具体实例,后附说明:

global

#全局的日志配置 其中日志级别是[err warning info debug]

#local0 是日志设备,必须为如下24种标准syslog设备的一种:

#kern user mail daemon auth syslog lpr news

#uucp cron auth2 ftp ntp audit alert cron2

#local0 local1 local2 local3 local4 local5 local6 local7

#但是之前在/etc/syslog.conf文件中定义的是local0所以

#这里也是用local0

log 127.0.0.1 local0 info #[err warning info debug]

#最大连接数

maxconn 4096

#用户

user admin

#组

group admin

#使HAProxy进程进入后台运行。这是推荐的运行模式

daemon

#创建4个进程进入deamon模式运行。此参数要求将运行模式设置为”daemon”

nbproc 4

#将所有进程的pid写入文件 启动进程的用户必须有权限访问此文件。

pidfile /home/admin/haproxy/logs/haproxy.pid

defaults

#默认的模式mode { tcp|http|health },tcp是4层,http是7层,health只会返回OK

mode http

#采用http日志格式

option httplog

#三次连接失败就认为是服务器不可用,也可以通过后面设置

retries 3

如果cookie写入了serverId而客户端不会刷新cookie,

#当serverId对应的服务器挂掉后,强制定向到其他健康的服务器

option redispatch

#当服务器负载很高的时候,自动结束掉当前队列处理比较久的链接

option abortonclose

#默认的最大连接数

maxconn 4096

#连接超时

contimeout 5000

#客户端超时

clitimeout 30000

#服务器超时

srvtimeout 30000

#=心跳检测超时

timeout check 2000

#注:一些参数值为时间,比如说timeout。时间值通常单位为毫秒(ms),但是也可以通过加#后缀,来使用其他的单位。

#- us : microseconds. 1 microsecond = 1/1000000 second

#- ms : milliseconds. 1 millisecond = 1/1000 second. This is the default.

#- s : seconds. 1s = 1000ms

#- m : minutes. 1m = 60s = 60000ms

#- h : hours. 1h = 60m = 3600s = 3600000ms

#- d : days. 1d = 24h = 1440m = 86400s = 86400000ms

########统计页面配置############

listen admin_stats

#监听端口

bind 0.0.0.0:1080

#http的7层模式

mode http

#日志设置

log 127.0.0.1 local0 err #[err warning info debug]

#统计页面自动刷新时间

stats refresh 30s

#统计页面url

stats uri /admin?stats

#统计页面密码框上提示文本

stats realm Gemini\ Haproxy

#统计页面用户名和密码设置

stats auth admin:admin

stats auth admin1:admin1

#隐藏统计页面上HAProxy的版本信息

stats hide-version

#######网站检测listen定义############

listen site_status

bind 0.0.0.0:1081

mode http

log 127.0.0.1 local0 err #[err warning info debug]

#网站健康检测URL,用来检测HAProxy管理的网站是否可以用,正常返回200,不正常返回500

monitor-uri /site_status

#定义网站down时的策略

#当挂在负载均衡上的指定backend的中有效机器数小于1台时返回true

acl site_dead nbsrv(denali_server) lt 1

acl site_dead nbsrv(tm_server) lt 1

acl site_dead nbsrv(mms_server) lt 1

#当满足策略的时候返回500

monitor fail if site_dead

#如果192.168.0.252或者192.168.0.31这两天机器挂了

#认为网站挂了,这时候返回500,判断标准是如果mode是

#http返回200认为是正常的,如果mode是tcp认为端口畅通是好的

monitor-net 192.168.0.252/31

########frontend配置############

frontend http_80_in

#监听端口

bind 0.0.0.0:80

#http的7层模式

mode http

#应用全局的日志配置

log global

#启用http的log

option httplog

#每次请求完毕后主动关闭http通道,HA-Proxy不支持keep-alive模式

option httpclose

#如果后端服务器需要获得客户端的真实IP需要配置次参数,将可以从Http Header中

#获得客户端IP

option forwardfor

###########HAProxy的日志记录内容配置##########

capture request header Host len 40

capture request header Content-Length len 10

capture request header Referer len 200

capture response header Server len 40

capture response header Content-Length len 10

capture response header Cache-Control len 8

####################acl策略定义#########################

#如果请求的域名满足正则表达式返回true -i是忽略大小写

acl denali_policy hdr_reg(host) -i ^(www.gemini.taobao.net|my.gemini.taobao.net|auction1.gemini.taobao.net)$

#如果请求域名满足trade.gemini.taobao.net 返回 true -i是忽略大小写

acl tm_policy hdr_dom(host) -i trade.gemini.taobao.net

##在请求url中包含sip_apiname=,则此控制策略返回true,否则为false

acl invalid_req url_sub -i sip_apiname=

##在请求url中存在timetask作为部分地址路径,则此控制策略返回true,否则返回false

acl timetask_req url_dir -i timetask

#当请求的header中Content-length等于0时返回 true

acl missing_cl hdr_cnt(Content-length) eq 0

######################acl策略匹配相应###################

##当请求中header中Content-length等于0 阻止请求返回403

block if missing_cl

##block表示阻止请求,返回403错误,当前表示如果不满足策略invalid_req,或者满足策略timetask_req,则阻止请求。

block if !invalid_req || timetask_req

#当满足denali_policy的策略时使用denali_server的backend

use_backend denali_server if denali_policy

#当满足tm_policy的策略时使用tm_server的backend

use_backend tm_server if tm_policy

#reqisetbe关键字定义,根据定义的关键字选择backend

reqisetbe ^Host:\ img dynamic

reqisetbe ^[^\ ]*\ /(img|css)/ dynamic

reqisetbe ^[^\ ]*\ /admin/stats stats

#以上都不满足的时候使用默认mms_server的backend

default_backend mms_server

#HAProxy错误页面设置

errorfile 400 /home/admin/haproxy/errorfiles/400.http

errorfile 403 /home/admin/haproxy/errorfiles/403.http

errorfile 408 /home/admin/haproxy/errorfiles/408.http

errorfile 500 /home/admin/haproxy/errorfiles/500.http

errorfile 502 /home/admin/haproxy/errorfiles/502.http

errorfile 503 /home/admin/haproxy/errorfiles/503.http

errorfile 504 /home/admin/haproxy/errorfiles/504.http

##########backend的设置##############

backend mms_server

#http的7层模式

mode http

#负载均衡的方式,roundrobin平均方式

balance roundrobin

#允许插入serverid到cookie中,serverid后面可以定义

cookie SERVERID

#心跳检测的URL,HTTP/1.1¥r¥nHost:XXXX,指定了心跳检测HTTP的版本,XXX为检测时请求

#服务器的request中的域名是什么,这个在应用的检测URL对应的功能有对域名依赖的话需要设置

option httpchk GET /member/login.jhtml HTTP/1.1\r\nHost:member1.gemini.taobao.net

#服务器定义,cookie 1表示serverid为1,check inter 1500 是检测心跳频率

#rise 3是3次正确认为服务器可用,fall 3是3次失败认为服务器不可用,weight代表权重

server mms1 10.1.5.134:80 cookie 1 check inter 1500 rise 3 fall 3 weight 1

server mms2 10.1.6.118:80 cookie 2 check inter 1500 rise 3 fall 3 weight 2

backend denali_server

mode http

#负载均衡的方式,source根据客户端IP进行哈希的方式

balance source

#但设置了backup的时候,默认第一个backup会优先,设置option allbackups后

#所有备份服务器权重一样

option allbackups

#心跳检测URL设置

option httpchk GET /mytaobao/home/my_taobao.jhtml HTTP/1.1\r\nHost:my.gemini.taobao.net

#可以根据机器的性能不同,不使用默认的连接数配置而使用自己的特殊的连接数配置

#如minconn 10 maxconn 20

server denlai1 10.1.5.114:80 minconn 4 maxconn 12 check inter 1500 rise 3 fall 3

server denlai2 10.1.6.104:80 minconn 10 maxconn 20 check inter 1500 rise 3 fall 3

#备份机器配置,正常情况下备机不会使用,当主机的全部服务器都down的时候备备机会启用

server dnali-back1 10.1.7.114:80 check backup inter 1500 rise 3 fall 3

server dnali-back2 10.1.7.114:80 check backup inter 1500 rise 3 fall 3

backend tm_server

mode http

#负载均衡的方式,leastconn根据服务器当前的请求数,取当前请求数最少的服务器

balance leastconn

option httpchk GET /trade/itemlist/prepayCard.htm HTTP/1.1\r\nHost:trade.gemini.taobao.ne

server tm1 10.1.5.115:80 check inter 1500 rise 3 fall 3

server tm2 10.1.6.105:80 check inter 1500 rise 3 fall 3

######reqisetbe自定义关键字匹配backend部分#######################

backend dynamic

mode http

balance source

option httpchk GET /welcome.html HTTP/1.1\r\nHost:www.taobao.net

server denlai1 10.3.5.114:80 check inter 1500 rise 3 fall 3

server denlai2 10.4.6.104:80 check inter 1500 rise 3 fall 3

backend stats

mode http

balance source

option httpchk GET /welcome.html HTTP/1.1\r\n Host:www.163.com

server denlai1 10.5.5.114:80 check inter 1500 rise 3 fall 3

server denlai2 10.6.6.104:80 check inter 1500 rise 3 fall 3

HAproxy负载均衡-ACL篇

2016年6月1日 评论已被关闭

HAproxy负载均衡-ACL篇

http://blog.csdn.net/tantexian/article/details/50015975

ACL定制法则:

开放策略:拒绝所有,只开放已知

拒绝策略:允许所有,只拒绝某些

事实上实现安全策略,无非也就是以上两种方法

 

redirect

参考:http://cbonte.github.io/haproxy-dconv/configuration-1.4.html#4-redirect

如果符合某种特定条件,则返回某种新的前缀

aclclear         dst_port 80
acl secure         dst_port 8080
acl login_page         url_beg         /login                          #如果url的地址,除了主机名之外是login的页面则定义成logon,如果是登录页面却又属于不安全的连接 那么
acl logout         url_beg         /logout
acl uid_given          url_reg          /login?userid=[^&]+
acl cookie_set         hdr_sub(cookie)SEEN=1                         #取得cookie的子串,如果没有cookie则:

redirect prefix   https://mysite.com set-cookie SEEN=1 if!cookie_set        #如果定义的第一个用户来访问我们的站点的时候,没有被设置cookie 在将用户的请求转为https
redirect prefix  https://mysite.com             iflogin_page !secure
redirect prefix   http://mysite.com drop-query             if login_page !uid_given
redirect locationhttp://mysite.com/               if !login_page secure
redirect location / clear-cookie USERID=               if logout

我们自定定义一个acl

如果访问的是/bbs开头的地址,那么将其跳转到/forum

acl acbbs url_beg/bbs

redirect /forum if/bbs     #if判断是否匹配/bbs  如果匹配则将/bbs 跳转至/forum

只不过对于haproxy来讲需要基于acl的机制来实现,所以要比nginx要麻烦一点

 

reqadd

如果访问的是ssl则则加入X-Proto首部

acl is-ssldst_prot 81

reqadd X-Proto:\SSL if is-ssl

 

rspadd

响应报文首部,所有响应首部都需要经过haproxy,因此经过haproxy的时候,想通告其客户端是通过haproxy来转发过来的,因此这时候会在首部添加一个 X-Via首部,明确说明是通过代理服务器转发的

#只要是通过haproxy转发的请求统统添加首部信息,如下所示:

rspadd X-Via:\ 10.0.10.61        #haproxy的IP地址

 

Server的检测机制

backup

check

disabled

fall          #检测机[1]制,检测超过几次认为失败

inter           #检测的时间间隔

另外inter还可以对其做优化:

fastinter       #快速检测

downinter       #慢速检测

以上可以做启发式检测,如果发现故障了可以将其快速检测几次

限制最大连接数

Maxconn参数为最大连接数,可以将其限制最大连接数,如下所示

backend webserver
balance uri
hash-type consistent
server   web1 10.0.10.82:80 check  weight 1 maxconn 2000
server   web2 10.0.10.83:80 check  weight 1 maxconn 3000

访问管理页面:

wKiom1OuQ6Oi_aP-AAFu_XJOHmA317.jpg

如果请求过多,所有超出这个最大连接数 ,如果还被转发至这个服务器中会被放入至等待队列中,如果队列也超时了,这个请求则会直接被响应403

 

maxqueue

维持每个队列的长度

 

minconn

最少连接,用来将maxconn定制为动态值

 

observer<mode>

健康状态监测,如果存活则不对其检查
可以根据4/7层做观测
redir

所有发往这个服务器的请求做重定向,因此可以实现单台服务器的重定向

实现重定向:

server  web1 10.0.10.82:80 check  weight 1 maxconn 2000 redir http://www.baidu.com

访问测试,可发现最后访问其haproxy的IP地址 最后被跳转至百度页面中了

 

slowstart

让haproxy支持慢启动,但是对于haproxy来讲第一启动是没有任何意义的

慢启动只在服务器故障又重新上线的时候才有效果

 

weight

权重

 

HAproxy 的 ACL 机制

http访问控制参数

rediect blockhttp-request use_backend

但凡是使用if的时候必须使用acl进行定义,访问控制列表的定义可以通过源地址/目标地址,源端口目标端口来定义,所以acl中所支持定义的标准和机制还是比较多的

·ACL     基本定义语法

·acl     名称 acl标准 [标志位][操作]

·acl     区分大小写

通常参数都是 -i

值的类型

e.g 1024:65535

比较操作

eg ge gt le lt

字符串

常用参数  -i

常用的匹配标准:

dst         目标地址

dst_port    目标端口

src         源地址

src_prot    源端口

acl goodguys src ip/24             如果是goodguys则允许访问

tcp-request content accept if goodguys   如果是goodguys则允许发起连接请求

tcp-request content reject        没有if语句 则拒绝所有(reject)

 

定义ACL

基于SRC做访问控制

我们期望用户访问的时候如果来源地址是10.0.10.1则拒绝访问

frontend  web_server

bind*:80

default_backendwebservers

acl badguy src 10.0.10.1

block if badguy

acl定义规则名称为badguy,并且定义如果来源是10.0.10.1的IP地址拒绝访问

block表示拒绝的意思,if后面加判断,如果匹配badguy名称定义的规则那么就执行block的操作

再次访问

wKioL1OuQ5qjjODGAACwq9LSQOg694.jpg

使用重定向

如果想访问403页面重定向到其他页面的话,则:

frontend web_server
bind *:80

default_backend webserver

acl badguy src 10.0.10.1
block if badguy
errorloc 403 http://baidu.com/     #定义错误页面重定向

 

在七层做其他的匹配

hdr

检查首部是否属于某个指定字符的

frontend web_server
bind *:80
default_backend webserver
acl badguy src 10.0.10.1
acl dstipaddrhdr(Host) 10.0.10.61
redirectlocation  http://www.qq.com/ if dstipaddr
errorloc 403 http://baidu.com

以上,通过har机制检测 如果头部信息包含此IP地址那么将其重定向至qq.com

如果非此IP地址,那么请求的uri返回是403,那么则直接跳转到baidu.com

 

hdr_reg  正则表达式匹配

说明某个首部的值只要匹配这个正则,则执行跳转

 

http_first_req

第一次请求匹配

 

method  访问方法匹配(GET或POST等)

实现简单动静分离功能

acl read method GET

acl read methodHEAD

 

acl write methodPUT

acl write methodPOST

 

use_backend imgserif read

use_backend uploadif write

 

基于path http路径做访问控制

是做精确匹配的,因此通常只匹配用户已经知道的文件路径

来自某个ip的主机访问的是1.html 则拒绝访问,其他全部放行,则:

#首先定义acl 名称denyfile 根据path来做访问控制,而path一定跟的是具体访问路径

#http-reques 来做规则 如果是badguy 并且访问的是denyfile 如果匹配两者则deny掉

frontend web_server
bind *:80
default_backend webserver
acl badguy src 10.0.10.1
acl denyfile path/1.html
http-request deny if badguy denyfile

重新加载配置文件,并且访问测试:

wKiom1OuQ-ThlEeLAAEOaoZfaWs288.jpg

访问/1.html 则返回403 ,访问其他uri则正常返回

 

path_beg

path只能定义单一路径或文件,但是path_beg可以定义多个文件或路径

实例:实现动静分离功能

首先定义两个backend,分别以动态和静态进行分组

backend jingtai
balance roundrobin
server   web1 10.0.10.82:80 check  weight 1maxconn 2000

backend dongtai
balance roundrobin
server   web2 10.0.10.83:80 check  weight 1maxconn 3000

 

配置frontend

frontend  web_server

bind *:80

default_backend webservers

acl badguy src 10.0.10.1

acl denyfile path /1.html

#http-request deny if badguy denyfile

 

acl static path_end .html

use_backend jingtai if static

default_backend dongtai

定义acl名称为static ,如果访问匹配是.html的文件,那么直接跳转至jingtai 这个backend

如果访问的不匹配.html 那么直接跳转至默认backend dongtai组

重新加载规则,访问测试:

wKioL1OuQ9Hzaxd6AAELWeDuSss192.jpg

 

实现完全动静分离

在path_end中可以使用-i参数指定多个选项

修改配置信息,将一系列尽可能出现的静态内容文件类型加入acl的static组内

bind *:80

default_backend webservers

acl badguy src 10.0.10.1

acl denyfile path /1.html

#http-request deny if badguy denyfile

 

acl static path_end -i .html .jpg .png.jpeg .gif .swf .css .xml .txt .pdf

use_backend jingtai if static

default_backend dongtai

 

 

path_reg

正在表达式匹配

acl url_static  path_reg  -i .jpg$ .html$ 等  ^/static ^/images^/stylsheets

基于正则表达式匹配要比基于字符匹配慢很多,所以如果可以写成字符匹配就尽可能使用 path_end path_end 而不要使用path_reg

 

url

之前我们在用path做匹配的时候发现,path不包含头部信息,而url全部包含

做url匹配要做整个路径匹配,但事实上用的最多的是path 而不是url,以为用户访问文件的时候,可能是这样访问:

http://xxx.com/login.php?name=test&password=xxxx

很显然login.php 才是访问的文件,而根据整个路径结尾进行判断的话则不能判断其类型的,所以更多用到的是path_end ,因为path_end顶多只能匹配到login.php

而不包含后面的内容

 

url_beg

url开头

 

url_end

url结尾

 

有些时候我们用url做匹配的时候可能会使用多条进行组合起来

比如:

#如果badguy 访问的是除了denyfile之外的其他文件,则将被拒绝

http-request denyif badguy !denyfile

如果badguy 或其他人 访问的是除了denyfile之外的其他文件,则将被拒绝

http-request denyif badguy OR denyfile

 

健康状态检查机制

monitor-uri

通过web组件实现监控的,明确指定监控哪个uri而不是内部监控机制(check)

frontend www

bind :80

monitor-uri   /haproxy

意思为做状态监测必须去请求这个uri的页面,能请求到并且状态为200则认为正常的

 

httpchk

做服务器的健康状态监测的时候明确说明http协议,可以指定检查那个uri,还可以指定那种方式检查uri,只启用就明确说明只做uri监测 而后面的监测方法全部省略了

backendhttps_relay
mode tcp
option httpchk OPTIONS * HTTP/1.1\r\nHost:\ www
server apache1 192.168.1.1:443 check port 80

也就意味着我们做健康检测的时候,是发送自定义信息去check

也就是说httpchk是发送的自定义的方法以及发送的请求报文格式的,只有发送的请求返回值是200,才认为正常否则失败的

http请求格式:

<method><uri> <version>

<header>

<body>

将OPTIONS *HTTP/1.1\r\nHost:\ www 转换成标准格式,如下所示:

OPTIONS * HTTP/1.1

Host: www

 

例:定义对MySQL进行检测

option mysqlchkuser mysqlusername

使用option参数套mysqlchk插件以mysqlusername的名称去连接mysql,只要能连接上,则认为数据库正常,否则不允许连接

 

综合示例:

示例1.实现动静分离

匹配以/static/images /img /css 目录的URI,并匹配以静态文件内容的URI

acl usr_staticpath_beg -i /static /images /img /css

acl usr_staticpath_end -i .gif .png .jpg

 

#判断用户访问如果主机名以www开头的话则标示为host_www

acl host_wwwhdr_beg(host) -i www

 

如果主机是以img video download 的域名开头,都被认为是静态内容

acl host_statichdr_beg(host) -i img. video. download.

 

#而后做匹配内容,如果三者匹配其中一个则分发至backend static组

use_backend static if host_static or host_www or url_static

default_backendappservers

 

实例2
global
pidfile /var/run/haproxy.pid
log 127.0.0.1 local0 info

defaults
mode http
clitimeout         600000   # maximum inactivity time on the client side
srvtimeout         600000   # maximum inactivity time on the server side
timeout connect          8000    # maximum time to wait for aconnection
attempt to a server to succeed
stats enable
stats auth             admin:password
stats uri            /monitor
stats refresh          5s
option httpchk          GET /status
retries              5
option redispatch
errorfile 503 /path/to/503.text.file

balance roundrobin     # each server isused in turns, according to assigned weight

frontend http
bind :80
monitor-uri   /haproxy  # end point tomonitor HAProxy status (returns 200)

#只要用户访问的path路径是以api开头则匹配
acl api1 path_reg ^/api1/?
acl api2 path_reg ^/api2/?

如果是api1的话则使用backend api1 以此类推
use_backend api1 if api1
use_backend api2 if api2

backend api1
# option httpclose
server srv0 127.0.0.1:9000 weight 1 maxconn 100 check inter4000
server srv1 127.0.0.1:9001 weight 1 maxconn 100 check inter4000
server srv2 127.0.0.1:9002 weight 1 maxconn 100 check inter4000

backend api2
option httpclose
server srv01 127.0.0.1:8000 weight 1 maxconn 50 check inter 4000

但是没有默认服务器也就意味着只允许用户请求api1api2,以别的任何方式都访问不到

 

haproxylisten配置示例:

基于COOKIE做持久连接

只要在listen中还是在backend中是要使用cookie指令 就意味着server中去引用这个cookie的,每个用户都加上sessionid,因此会为每个用户请求插入一个会话ID,因此基于这个会话id做负载均衡调度

listen webfarm
bind 192.168.0.99:80
mode http
stats enable
stats auth someuser:somepassword             #指定某个用户某个密码
balance roundrobin                    #指定调度算法
cookie JSESSIONID prefix                  #基于cookie做负载均衡
option httpclose

option forwardfor                   #添加首部信息
option httpchk HEAD /check.txt HTTP/1.0     #http首部请求的方法是head 请求的是 /check.txt 协议是1.0 ,没有跟主机就意味着请求的是默认主机,而不是检测虚拟主机
server webA 192.168.0.102:80 cookie A check     #使用cookie做了负载均衡
server webB 192.168.0.103:80 cookie B check

 

对mysql读集群做负载均衡

只是对于读请求可以做负载均衡,如果对于写做负载均衡的时候直接这样调度是不合适的

frontendmysqlservers
bind *:3306
default_backend myservs

backend myservs
balance leastconn
option mysqlchk user root
server myserv1 172.16.100.11:3306 check
server myserv2 172.16.100.12:3306 check

 

负载均衡之Haproxy配置详解(及httpd配置)

2016年6月1日 评论已被关闭

负载均衡之Haproxy配置详解(及httpd配置)

http://blog.csdn.net/tantexian/article/details/50056199

下图描述了使用keepalived+Haproxy主从配置来达到能够针对前段流量进行负载均衡到多台后端web1、web2、web3、img1、img2.但是由于haproxy会存在单点故障问题,因此使用keepalived来实现对Haproxy单点问题的高可用处理。
常用开源软件负载均衡器有:Nginx、LVS、Haproxy。
三大主流软件负载均衡器对比(LVS VS Nginx VS Haproxy)
LVS:
1、抗负载能力强。抗负载能力强、性能高,能达到F5硬件的60%;对内存和cpu资源消耗比较低
2、工作在网络4层,通过vrrp协议转发(仅作分发之用),具体的流量由linux内核处理,因此没有流量的产生。
2、稳定性、可靠性好,自身有完美的热备方案;(如:LVS+Keepalived)
3、应用范围比较广,可以对所有应用做负载均衡;
4、不支持正则处理,不能做动静分离。
5、支持负载均衡算法:rr(轮循)、wrr(带权轮循)、lc(最小连接)、wlc(权重最小连接)
6、配置 复杂,对网络依赖比较大,稳定性很高。
Ngnix:
1、工作在网络的7层之上,可以针对http应用做一些分流的策略,比如针对域名、目录结构;
2、Nginx对网络的依赖比较小,理论上能ping通就就能进行负载功能;
3、Nginx安装和配置比较简单,测试起来比较方便;
4、也可以承担高的负载压力且稳定,一般能支撑超过1万次的并发;
5、对后端服务器的健康检查,只支持通过端口来检测,不支持通过url来检测。
6、Nginx对请求的异步处理可以帮助节点服务器减轻负载;
7、Nginx仅能支持http、https和Email协议,这样就在适用范围较小。
8、不支持Session的直接保持,但能通过ip_hash来解决。、对Big request header的支持不是很好,
9、支持负载均衡算法:Round-robin(轮循)、Weight-round-robin(带权轮循)、Ip-hash(Ip哈希)
10、Nginx还能做Web服务器即Cache功能。
HAProxy的特点是:
1、支持两种代理模式:TCP(四层)和HTTP(七层),支持虚拟主机;
2、能够补充Nginx的一些缺点比如Session的保持,Cookie的引导等工作
3、支持url检测后端的服务器出问题的检测会有很好的帮助。
4、更多的负载均衡策略比如:动态加权轮循(Dynamic Round Robin),加权源地址哈希(Weighted Source Hash),加权URL哈希和加权参数哈希(Weighted Parameter Hash)已经实现
5、单纯从效率上来讲HAProxy更会比Nginx有更出色的负载均衡速度。
6、HAProxy可以对Mysql进行负载均衡,对后端的DB节点进行检测和负载均衡。
9、支持负载均衡算法:Round-robin(轮循)、Weight-round-robin(带权轮循)、source(原地址保持)、RI(请求URL)、rdp-cookie(根据cookie)
10、不能做Web服务器即Cache。
三大主流软件负载均衡器适用业务场景:
1、网站建设初期,可以选用Nigix/HAproxy作为反向代理负载均衡(或者流量不大都可以不选用负载均衡),因为其配置简单,性能也能满足一般的业务场景。如果考虑到负载均衡器是有单点问题,可以采用Nginx+Keepalived/HAproxy+Keepalived避免负载均衡器自身的单点问题。
2、网站并发达到一定程度之后,为了提高稳定性和转发效率,可以使用LVS、毕竟LVS比Nginx/HAproxy要更稳定,转发效率也更高。不过维护LVS对维护人员的要求也会更高,投入成本也更大。

注:Niginx与Haproxy比较:Niginx支持七层、用户量最大,稳定性比较可靠。Haproxy支持四层和七层,支持更多的负载均衡算法,支持session保存等。具体选型看使用场景,目前来说Haproxy由于弥补了一些Niginx的缺点用户量也不断在提升。

衡量负载均衡器好坏的几个重要因素:
1、会话率 :单位时间内的处理的请求数
2、会话并发能力:并发处理能力
3、数据率:处理数据能力
经过官方测试统计,haproxy  单位时间处理的最大请求数为20000个,可以同时维护40000-50000个并发连接,最大数据处理能力为10Gbps。综合上述,haproxy是性能优越的负载均衡、反向代理服务器。

总结HAProxy主要优点:

一、免费开源,稳定性也是非常好,这个可通过我做的一些小项目可以看出来,单Haproxy也跑得不错,稳定性可以与LVS相媲美;

二、根据官方文档,HAProxy可以跑满10Gbps-New benchmark of HAProxy at 10 Gbps using Myricom’s 10GbE NICs (Myri-10G PCI-Express),这个作为软件级负载均衡,也是比较惊人的;

三、HAProxy可以作为MySQL、邮件或其它的非web的负载均衡,我们常用于它作为MySQL(读)负载均衡;

四、自带强大的监控服务器状态的页面,实际环境中我们结合Nagios进行邮件或短信报警,这个也是我非常喜欢它的原因之一;

五、HAProxy支持虚拟主机。

下述将选择Haproxy作为负载均衡器进行讲解:
本次使用环境:
环境centos7.1
Haproxy 1.5.4
Haproxy+keeplived  172.31.2.31
Haproxy+keeplived  172.31.2.32
下述针对Haproxy的配置文件进行详解:
vim /etc/haproxy/haproxy.cfg
文本部分:
global                                                       # 全局参数的设置
    log         127.0.0.1 local2                      # log语法:log <address_1>[max_level_1] # 全局的日志配置,使用log关键字,
                                                                     指定使用127.0.0.1
                                                                     上的syslog服务中的local0日志设备,记录日志等级为info的日志
    chroot      /var/lib/haproxy                 #改变当前工作目录
    pidfile     /var/run/haproxy.pid          #当前进程id文件
    maxconn     4000                                #最大连接数
    user        haproxy                                #所属用户
    group     haproxy                                #所属组
    daemon                                               #以守护进程方式运行haproxy
    stats socket /var/lib/haproxy/stats
defaults
    mode                    http                        #默认的模式mode { tcp|http|health },tcp是4层,http是7层,health只会返回OK
    log                        global                    #应用全局的日志配置
    option                  httplog                  # 启用日志记录HTTP请求,默认haproxy日志记录是不记录HTTP请求日志
    option                  dontlognull          # 启用该项,日志中将不会记录空连接。所谓空连接就是在上游的负载均衡器
                                                                   或者监控系统为了探测该 服务是否存活可用时,需要定期的连接或者获取某
                                                                  一固定的组件或页面,或者探测扫描端口是否在监听或开放等动作被称为空连接;
                                                                  官方文档中标注,如果该服务上游没有其他的负载均衡器的话,建议不要使用
                                                                   该参数,因为互联网上的恶意扫描或其他动作就不会被记录下来
    option http-server-close                   #每次请求完毕后主动关闭http通道
    option forwardfor       except 127.0.0.0/8   #如果服务器上的应用程序想记录发起请求的客户端的IP地址,需要在HAProxy
                                                                            上 配置此选项, 这样 HAProxy会把客户端的IP信息发送给服务器,在HTTP
                                                                            请求中添加”X-Forwarded-For”字段。 启用  X-Forwarded-For,在requests
                                                                            头部插入客户端IP发送给后端的server,使后端server获取到客户端的真实IP。
    option                  redispatch                      # 当使用了cookie时,haproxy将会将其请求的后端服务器的serverID插入到
                                                                            cookie中,以保证会话的SESSION持久性;而此时,如果后端的服务器宕掉
                                                                            了, 但是客户端的cookie是不会刷新的,如果设置此参数,将会将客户的请
                                                                            求强制定向到另外一个后端server上,以保证服务的正常。
    retries                 3                             # 定义连接后端服务器的失败重连次数,连接失败次数超过此值后将会将对应后端
                                                                  服务器标记为不可用
    timeout http-request    10s             #http请求超时时间
    timeout queue           1m                 #一个请求在队列里的超时时间
    timeout connect         10s                #连接超时
    timeout client          1m                   #客户端超时
    timeout server          1m                   #服务器端超时
    timeout http-keep-alive 10s           #设置http-keep-alive的超时时间
    timeout check           10s                 #检测超时
    maxconn                 3000                 #每个进程可用的最大连接数
frontend  main *:80                             #监听地址为80
    acl url_static       path_beg       -i /static /images /javascript /stylesheets
    acl url_static       path_end       -i .jpg .gif .png .css .js
    use_backend static          if url_static
    default_backend             my_webserver     #定义一个名为my_app前端部分。此处将对于的请求转发给后端
backend static                                                 #使用了静态动态分离(如果url_path匹配 .jpg .gif .png .css .js静态文件则
                                                                            访问此后端)
    balance     roundrobin                               #负载均衡算法(#banlance roundrobin 轮询,balance source 保存session值,
                                                                           支持static-rr,leastconn,first,uri等参数)
    server      static 127.0.0.1:80 check             #静态文件部署在本机(也可以部署在其他机器或者squid缓存服务器)
backend my_webserver                                  #定义一个名为my_webserver后端部分。PS:此处my_webserver只是一个
                                                                            自定义名字而已,但是需要与frontend里面配置项default_backend 值相一致
    balance     roundrobin                               #负载均衡算法
    server  web01 172.31.2.33:80  check inter 2000 fall 3 weight 30              #定义的多个后端
    server  web02 172.31.2.34:80  check inter 2000 fall 3 weight 30              #定义的多个后端
    server  web03 172.31.2.35:80  check inter 2000 fall 3 weight 30              #定义的多个后端
更多关于Haproxyacl配置请参考博文:http://blog.csdn.net/tantexian/article/details/50015975
配置完成则重启服务:

systemctl restart haproxy

 
假若想访问监控界面:配置stats uri  /haproxy项,重启服务:
systemctl reload haproxy
注意:假若页面范围不了,是否selinux关闭了,iptables开启此端口了(iptables -F)
同理在172.31.2.32上面安装上述步骤安装配置好haproxy:
上述对Haproxy的优缺点及配置进行了详细讲解。
接下来对Haproxy+web负载均衡使用进行实战讲解:
首先配置三台web服务器:172.31.2.33、172.31.2.34、172.31.2.35
三台都是同样操作:

1、实验环境

centos 7.1 X64 mini版

2、配置web服务器(node33/34/35):

测试方便,关闭selinux、关闭iptables

一下都采用默认,不做配置即可。

yum install httpd -y

# vim /etc/httpd/conf/httpd.conf

httpd监听端口:

DocumentRoot:网页存放的路径,文档的根目录

重启httpd

# systemctl restart httpd

页面访问httpd:

修改显示内容:

# vim /var/www/html/index.html

I’m node33!!! My IP is 172.31.2.33…

再次访问:

这样三个web服务33/34/35搭建成功!!!!

接下来配置负载均衡(本次实验只用一个Haproxy:172.31.2.31):

vim /etc/haproxy/haproxy.cfg

浏览器请求172.31.2.31:
从上述结果可知,前端对172.31.2.31的请求,被Haproxy的负载均衡器,均衡请求到三个后端web172.31.2.33、172.31.2.34、172.31.2.35上面去了。
这样当三个当中的一个出现故障,流量则能正常分发到剩余两个正常的web上,从来提高了系统可靠性。
跟多关于keepalived+Haproxy请参考文章:http://blog.csdn.net/tantexian/article/details/50056229

千万级并发HAproxy均衡负载系统介绍

2016年6月1日 评论已被关闭

千万级并发HAproxy均衡负载系统介绍

http://blog.csdn.net/byxdaz/article/details/21327845

Haproxy介绍及其定位

HAProxy提供高可用性负载均衡以及基于TCP和HTTP应用的代理,支持虚拟主机,它是免费、快速并且可靠的一种解决方案。根据官方数据,其最高极限支持10G的并发。

HAProxy特别适用于那些负载特大的web站点,这些站点通常又需要会话保持或七层处理。HAProxy运行在当前的硬件上,完全可以支持数以万计的并发连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中,同时可以保护你的web服务器不被暴露到网络上。

其支持从4层至7层的网络交换,即覆盖所有的TCP协议。就是说,Haproxy甚至还支持 MySQL 的均衡负载。。

如果说在功能上,能以proxy反向代理方式实现 WEB均衡负载,这样的产品有很多。包括Nginx,ApacheProxy,lighttpd,Cheroke等。

但要明确一点的,Haproxy 并不是 Http服务器。以上提到所有带反向代理均衡负载的产品,都清一色是 WEB 服务器。简单说,就是他们能自个儿提供静态(html,jpg,gif..)或动态(php,cgi..)文件的传输以及处理。而Haproxy仅仅,而且专门是一款的用于均衡负载的应用代理。其自身并不能提供http服务。

但其配置简单,拥有非常不错的服务器健康检查功能还有专门的系统状态监控页面,当其代理的后端服务器出现故障, HAProxy会自动将该服务器摘除,故障恢复后再自动将该服务器加入。自1.3版本开始还引入了frontend,backend,frontend根据任意HTTP请求头内容做规则匹配,然后把请求定向到相关的backend。

另外, 版本1.3是处于活跃开发阶段的版本, 它支持如下新特性:

l内容交换 : 可以根据请求(request)的任何一部分来选择一组服务器,比如请求的 URI , Host头(header) , cookie ,以及其他任何东西. 当然,对那些静态分离的站点来说,对此特性还有更多的需求。

l全透明代理 :可以用客户端IP地址或者任何其他地址来连接后端服务器.这个特性仅在Linux 2.4/2.6内核打了cttproxy补丁后才可以使用. 这个特性也使得为某特殊服务器处理部分流量同时又不修改服务器的地址成为可能。

l基于树的更快的调度器 : 1.2.16以上的版本要求所有的超时都设成同样的值以支持数以万计的全速连接.这个特性已经移植到1.2.17. 

l内核TCP拼接 :避免了内核到用户然后用户到内核端的数据拷贝, 提高了吞吐量同时又降低了CPU使用率 . Haproxy 1.3支持Linux L7SW以满足在商用硬件上数Gbps 的吞吐的需求。

l连接拒绝 : 因为维护一个连接的打开的开销是很低的,有时我们很需要限制攻击蠕虫(attack bots),也就是说限制它们的连接打开从而限制它们的危害。这个已经为一个陷于小型DDoS攻击的网站开发了而且已经拯救了很多站点。

l细微的头部处理 :使得编写基于header的规则更为简单,同时可以处理URI的某部分。

l快而可靠的头部处理 :使用完全RFC2616 兼容的完整性检查对一般的请求全部进行分析和索引仅仅需要不到2ms的时间。

l模块化设计 :允许更多人加入进此项目,调试也非常简单. poller已经分离,已经使得它们的开发简单了很多. HTTP已经从TCP分离出来了,这样增加新的七层特性变得非常简单.其他子系统也会很快实现模块化

l投机I/O 处理 : 在一个套接字就绪前就尝试从它读取数据。poller仅推测哪个可能就绪哪个没有,尝试猜测,并且如果成功,一些开销很大的系统调用就可以省去了。如果失败,就会调用这些系统调用。已知的使用Linux epoll()已经净提升起码10%了。

lACLs : 使用任意规则的任意组合作为某动作的执行条件。

lTCP 协议检查 :结合ACL来对请求的任意部分进行检查,然后再进行转发。这就可以执行协议验证而不是盲目的进行转发。比如说允许SSL但拒绝SSH。

l更多的负载均衡算法 :现在,动态加权轮循(Dynamic Round Robin),加权源地址哈希(Weighted Source Hash),加权URL哈希和加权参数哈希(Weighted Parameter Hash)已经实现。其他算法比如Weighted Measured Response Time也很快会实现。

安装和配置

Haproxy 的配置相当简单,

从官方网站:http://www.haproxy.org下载最新版本。

# wget http://haproxy.1wt.eu/download/1.3/src/haproxy-1.3.20.tar.gz

# tar zcvf haproxy-1.3.20.tar.gz

# cd haproxy-1.3.20

# make TARGET=linux26 PREFIX=/usr/local/haprpxy

# make install PREFIX=/usr/local/haproxy

安装完毕后,进入安装目录创建配置文件

# cd /usr/local/haproxy

# vi haproxy.cfg

配置内容如下:

global
log 127.0.0.1 local0
#log 127.0.0.1 local1 notice
#log loghost local0 info
maxconn 4096
chroot /usr/local/haproxy
uid 99 #所属运行的用户uid
gid 99 #所属运行的用户组
daemon
nbproc 1
pidfile /usr/local/haproxy/run/haproxy.pid
#debug
#quiet

defaults
log global
log 127.0.0.1 local3 #日志文件的输出定向
mode http #所处理的类别
option httplog #日志类别
option httpclose
option dontlognull
option forwardfor
option redispatch
retries 2 #设置多个haproxy并发进程提高性能
maxconn 2000
balance roundrobin #负载均衡算法
stats uri /haproxy-stats #haproxy 监控页面的访问地址
# 可通过 http://localhost:1080/haproxy-stats 访问
contimeout 5000
clitimeout 50000
srvtimeout 50000

listen localhost 0.0.0.0:1080 #运行的端口及主机名
mode http
option httpchk GET /index.htm #健康检测
server s1 127.0.0.1:3121 weight 3 check #后端的主机 IP &权衡
server s2 127.0.0.1:3122 weight 3 check #后端的主机 IP &权衡

启动服务:
# /usr/local/haproxy/sbin/haproxy -f /usr/local/haproxy/haproxy.cfg

重启服务:
# /usr/local/haproxy/sbin/haproxy -f /usr/local/haproxy/haproxy.cfg -st `cat /usr/local/haproxy/logs/haproxy.pid` (没有换行)

停止服务:
# killall haproxy

当然,为了方便系统在开机时加载,还可以创建启动脚本:
# vim /etc/rc.d/init.d/haproxy 内容如下:

#! /bin/sh
set -e

PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/haproxy/sbin
PROGDIR=/usr/local/haproxy
PROGNAME=haproxy
DAEMON=$PROGDIR/sbin/$PROGNAME
CONFIG=$PROGDIR/conf/$PROGNAME.conf
PIDFILE=$PROGDIR/run/$PROGNAME.pid
DESC=”HAProxy daemon”
SCRIPTNAME=/etc/init.d/$PROGNAME

# Gracefully exit if the package has been removed.
test -x $DAEMON || exit 0

start()
{
echo -n “Starting $DESC: $PROGNAME”
$DAEMON -f $CONFIG
echo “.”
}

stop()
{
echo -n “Stopping $DESC: $PROGNAME”
haproxy_pid=cat $PIDFILE
kill $haproxy_pid
echo “.”
}

restart()
{
echo -n “Restarting $DESC: $PROGNAME”
$DAEMON -f $CONFIG -p $PIDFILE -sf $(cat $PIDFILE)
echo “.”
}

case “$1” in
start)
start
;;
stop)
stop
;;
restart)
restart
;;
*)
echo “Usage: $SCRIPTNAME {start|stop|restart}” >&2
exit 1
;;
esac 
exit 0

保存后赐予可执行权限
# chmod +x /etc/rc.d/init.d/haproxy

就可以使用 service haproxy start|stop|restart 来控制服务的启动停止跟重启。
并通过以下命令加载到开机服务启动列表
# chkconfig –add haproxy

配置日志:
# vim /etc/syslog.conf

在最下边增加
local3.* /var/log/haproxy.log
local0.* /var/log/haproxy.log
重启核心日志服务使配置起效
# service syslog restart

然后就可查看日志了
# tail –f /var/log/harpoxy.log

Aug 22 15:32:06 localhost haproxy[64136]: Proxy www started. 
Aug 22 15:32:06 localhost haproxy[64136]: Proxy cherokee started. 
Aug 22 15:32:06 localhost haproxy[64136]: Proxy wap started. 
Aug 22 15:32:06 localhost haproxy[64136]: Proxy pic started. 
Aug 22 15:32:06 localhost haproxy[64136]: Proxy img started. 
Aug 22 15:32:06 localhost haproxy[64136]: Proxy public started. 
Aug 22 15:32:06 localhost haproxy[64136]: Proxy public started. 
Aug 22 15:32:59 localhost haproxy[64137]: 219.142.128.30:6416 [22/Aug/2009:15:32:59.754] public stats/<STATS> 0/-1/-1/-1/0 200 17329 – – PR– 0/0/0/0/0 0/0 “GET /?stats HTTP/1.1”
Aug 22 15:32:59 localhost haproxy[64137]: 219.142.128.30:6416 [22/Aug/2009:15:32:59.754] public stats/<STATS> 0/-1/-1/-1/0 200 17329 – – PR– 0/0/0/0/0 0/0 “GET /?stats HTTP/1.1”

应用举例

WEB 均衡负载 & 虚拟主机

重新打开配置文件 haproxy.cfg,留意最下部分的均衡主机选项
listen localhost 0.0.0.0:1080 #运行的端口及主机名
mode http
option httpchk GET /index.htm #用于健康检测的后端页面
server s1 127.0.0.1:3121 weight 3 check #后端的主机 IP &权衡
server s2 127.0.0.1:3122 weight 3 check #后端的主机 IP &权衡

在实验中,我们的的后端是 squid 分开了2个端口在同一台服务器上。
以其中一项为例:

server s1 127.0.0.1:3121 weight 3 check

s1 是可自己定义的服务器别名
127.0.0.1:3121 服务器的IP地址以及端口号
weight 3 所能分配到请求的高低权衡,数字越大分配到的请求数就越高
check 接受 haproxy 的定时检查,以确定后端服务器的健康情况。

如需配置虚拟主机,相当简单,紧需修改 localhost 为你虚拟主机的的域名,加到haproxy配置中, 再为其分配后端服务器的参数即可。

例:

listen www.x1.com 0.0.0.0:1080 #运行的端口及主机名
mode http
option httpchk GET /index.htm #用于健康检测的后端页面
server s1 127.0.0.1:3121 weight 3 check #后端的主机 IP &权衡
server s2 127.0.0.1:3122 weight 3 check #后端的主机 IP &权衡

listen www.x2.com 0.0.0.0:1080 #运行的端口及主机名
mode http
option httpchk GET /index.htm #用于健康检测的后端页面
server s1 127.0.0.1:3121 weight 3 check #后端的主机 IP &权衡
server s2 127.0.0.1:3122 weight 3 check #后端的主机 IP &权衡

保存配置后重新加载,即可生效,刷新管理页面也可看到新的虚拟主机。

性能对比

在此,我们用最近最火红的 http 兼前端WEB均衡负载服务器 Nginx与 Haproxy 做个简单的性能对比。

测试环境:

CPU:Xeon2.8G X2 
RAM:4G
OS:RedHat As5.3 X64

工具:apache ab
参数:ab -i -c 500 -n 100000(500并发,1W请求)
最终服务端:2个squid 需实现均衡负载

成绩如下:

####### Nginx + haproxy : (由Nginx通过反向代理发送请求至haproxy,并由其进行均衡负载)

Concurrency Level: 500
Time taken for tests: 53.758 seconds
Complete requests: 100000
Failed requests: 0
Write errors: 0
Total transferred: 38600386 bytes
HTML transferred: 0 bytes

Requests per second: 1860.19 [#/sec] (mean)
Time per request: 268.790 [ms] (mean)
Time per request: 0.538 [ms] (mean, across all concurrent requests)
Transfer rate: 701.21 [Kbytes/sec] received
####### haproxy : (单独由haproxy进行均衡负载)
Concurrency Level: 500
Time taken for tests: 32.562 seconds
Complete requests: 100000
Failed requests: 0
Write errors: 0
Total transferred: 36606588 bytes
HTML transferred: 0 bytes
Requests per second: 3071.02 [#/sec] (mean)
Time per request: 162.812 [ms] (mean)
Time per request: 0.326 [ms] (mean, across all concurrent requests)
Transfer rate: 1097.85 [Kbytes/sec] received
####### nginx : (单独由nginx进行均衡负载)
Concurrency Level: 500
Time taken for tests: 36.539 seconds
Complete requests: 100000
Failed requests: 0
Write errors: 0
Total transferred: 38600000 bytes
HTML transferred: 0 bytes
Requests per second: 2736.82 [#/sec] (mean)
Time per request: 182.694 [ms] (mean)
Time per request: 0.365 [ms] (mean, across all concurrent requests)
Transfer rate: 1031.65 [Kbytes/sec] received

反复测试,得出其结果:
Haproxy 单独进行均衡负载的性能最强,超过了Nginx。
然而 Nginx + Haproxy 的搭配性能最弱,应该是跟通过了2层反向代理有关。
所以想用 Haproxy 替代 Nginx 所自带的均衡负载功能将会令性能打折。
但虽然如此 Haproxy 对均衡负载功能远比 Nginx 成熟,例如session粘贴,cookies 引导等都是 nginx 所没有的。
可根据需要而选择搭配。
相关启动参数介绍

相关启动参数介绍

#./haproxy –help //haproxy相关命令参数介绍.

haproxy-f<配置文件>

[-n 最大并发连接总数] [-N 每个侦听的最大并发数] [-d] [-D] [-q] [-V] [-c] [-p <pid文件>] [-s] [-l] [-dk]

[-ds] [-de] [-dp] [-db] [-m <内存限制M>] [{-sf|-st} pidlist…]

-d前台,debug模式

-Ddaemon模式启动

-q安静模式,不输出信息

-V详细模式

-c对配置文件进行语法检查

-s显示统计数据

-l显示详细统计数据

-dk不使用kqueue

-ds不使用speculative epoll

-de不使用epoll

-dp不使用poll

-db禁用后台模式,程序跑在前台

-sf <pidlist>

程序启动后向pidlist里的进程发送FINISH信号,这个参数放在命令行的最后

-st <pidlist>

程序启动后向pidlist里的进程发送TERMINATE信号,这个参数放在命令行的最后

参考资源 (resources)

本文仅作为引子,Haproxy 配置以其功能远远不止这些。更多资料可到以下网站中获取。

·Haproxy 中文 http://cn.haproxy.org

·Haproxy 英文 http://www.haproxy.org

·中国开源社区 http://www.oschina.net

  • Haproxy安装和动态配置更改测试
    本文主要描述haproxy的安装及简单配置过程。并且应用这个简单的配置做mysql的负载均衡,同时haproxy的配置文件发生变化时我们如何重新启动haproxy程序,并且确定haproxy程序重新启…
  • haproxy安装配置调优
    HAProxy提供高可用性、负载均衡以及基于TCP和HTTP应用的代理,支持虚拟主机,它是免费、快速并且可靠的一种解决方案。根据官方数据,其最高极限支持10G的并发。HAProxy 特别适用于那些…
  • keepalived+haproxy实现web服务的高可用和负载均衡
    keepalived是一个类似于layer3, 4 & 5交换机制的软件,也就是我们平时说的第3层、第4层和第5层交换.Keepalived的作用是检测web服务器的状态,如果有一台web服务器死机,…
  • Haproxy学习笔记-源码安装
    HAProxy提供高可用性、负载均衡以及基于TCP和HTTP应用的代理,支持虚拟主机, 它是免费、快速并且可靠的一种解决方案。HAProxy特别适用于那些负载特大的web站点, 这些站点通常又需要会话…
  • haproxy 命令配置实例
    Global parameters * Process management and security- chroot 改变当前工作目录- daemon 运行方式为后台工作

配置haproxy虚拟主机

2016年6月1日 评论已被关闭

配置haproxy虚拟主机
http://blog.chinaunix.net/uid-20553497-id-2881299.html
haproxy的安装和使用都比较简单。安装的话可以直接编辑Makefile配置一下就行了。

global
log 127.0.0.1 local0
log 127.0.0.1 local1 notice
maxconn 40960
chroot /var/run/haproxy
pidfile /var/run/haproxy.pid #方便热启动
uid 99
gid 99
daemon

defaults
log global
mode http
option httplog
option dontlognull
retries 3
option redispatch
maxconn 2000
contimeout 5000
clitimeout 50000
srvtimeout 50000
frontend lvs2-lvs3
bind *:8080
acl is_lvs2 hdr_end(host) -i lvs2.test.net:8080
acl is_lvs3 hdr_end(host) -i lvs3.test.net:8080
use_backend lvs2 if is_lvs2
use_backend lvs3 if is_lvs3

backend lvs2
balance roundrobin
server free172 10.253.3.14:80 weight 10
server free173 10.253.3.15:80 weight 10
backend lvs3
balance roundrobin
server free174 10.253.3.16:80 weight 10
server free173 10.253.3.15:80 weight 10
listen lvs2.test.net 0.0.0.0:8000
mode http
option httplog
maxconn 10
stats refresh 30s
stats uri /stats
stats realm test
stats auth admin:admin
stats hide-version
想热启动的话可以使用
sbin/haproxy -f etc/haproxy.cfg -sf $(cat /var/run/haproxy.pid )

这样就可以在同一个IP上配置虚拟主机了。当然如果有多个VIP的话也可以使用

listen lvs2.test.net 192.168.1.44:80
mode http
balance roundrobin
server free172 10.253.3.14:80 weight 10
server free173 10.253.3.15:80 weight 10
listen lvs3.test.net 192.168.1.44:80
mode http
balance roundrobin
server free174 10.253.3.16:80 weight 10
server free173 10.253.3.15:80 weight 10
这样的模式来完成。
这里有一篇也写得很好,基本能满足现在普通的逆向代理,设置虚拟机,根据path来选择后端机器等需求

http://xukaizijian.blog.163.com/blog/static/17043311920115283358709/

基于域名负载均衡的Haproxy配置

2016年6月1日 评论已被关闭

基于域名负载均衡的Haproxy配置
http://blog.csdn.net/youyudehexie/article/details/7606504
[plain] view plain copy
global
log 127.0.0.1 local0 info #[err warning info debug] //日志位置
maxconn 4096
daemon #设置成后台运行
nbproc 1 #进程数量
# pidfile /home/admin/haproxy/logs/haproxy.pid

defaults
log     global
mode    http #默认模式
option  httplog #http日志格式
option  dontlognull
retries 3  #三次失败后认为服务器不可用
option  redispatch  #如果cookie写入了serverId而客户端不会刷新cookie,当serverId对应的服务器挂掉后,强制定向到其他健康的服务器
maxconn 2000 #当服务器负载很高的时候,自动结束掉当前队列处理比较久的链接默认的最大连接数
contimeout 5000 #连接超时
clitimeout 30000 #客户端超时
srvtimeout 30000 #服务器超时

frontend web_in
mode http
maxconn 1000
bind :80
acl is_a hdr_beg(host) -i www.abc.test1  #判断域名是不是www.abc.test1,是则给与a服务器集群服务
acl is_b hdr_beg(host) -i www.abc.test2  #判断域名是不是www.abc.test2,是则给与a服务器集群服务

use_backend a_server if is_a
use_backend b_server if is_b

backend a_server
mode http #http 模式
stats   uri  /haproxy
balance roundrobin
cookie  JSESSIONID prefix
stats   hide-version
option  httpclose
server web1 128.1.87.3:80 check
server web2 128.1.2.5:80 check

backend b_server
mode http #http 模式
stats   uri  /haproxy
balance roundrobin
cookie  JSESSIONID prefix

stats   hide-version
option  httpclose
server web1 128.1.87.4:80

Haproxy根据域名匹配后端服务器

2016年6月1日 评论已被关闭

Haproxy根据域名匹配后端服务器

http://www.linuxidc.com/Linux/2015-05/117087.htm
CentOS 7.1 1503最小化安装,nginx和Haproxy通过yum安装,关闭防火墙,清空iptables
Haproxy主机ip:192.168.70.161
后端nginx主机ip:192.168.70.158,192.168.70.159

一、配置haproxy,只保留到defaults,下面的修改为如下
frontend  main *:80
acl test2 hdr_beg(host) -i node2.linuxu.me        //acl设定匹配请求的url
acl test3 hdr_beg(host) -i node3.linuxu.me
use_backend node2          if test2
use_backend node3      if test3
default_backend            node2
backend node2                                                              //设置两台后端nginx服务器
balance    roundrobin
server      node2 192.168.70.159:80 check
backend node3
balance    roundrobin
server  node3 192.168.70.158:80 check

二、分别在nginx原index.html添加h1字段以区别,注意是在head里分别添加

node2
<h1>node2.linuxu.me</h1>
node3
<h1>node3.linuxu.me</h1>

三、添加host文件并访问测试

Nginx反向代理和负载均衡部署指南

2016年6月1日 评论已被关闭

Nginx反向代理和负载均衡部署指南
http://www.cnblogs.com/jacktang/p/3669115.html
1.        安装

1)         从Nginx官网下载页面(http://nginx.org/en/download.html)下载Nginx最新版本(目前是1.5.13版本)安装包;

2)         解压后复制到部署目录。

 

2.        启动和停止Nginx

Nginx目前只支持命令行操作,操作前先进入Dos命令环境,并进入Nginx部署目录。

1)         启动Nginx:start nginx

2)         停止Nginx:nginx -s stop

3)         修改配置后重启:nginx -s reload

这三个命令可分别做成bat文件,放在部署目录下,方便后续操作。

start nginx.bat文件内容:start nginx

stop nginx.bat文件内容:nginx -s stop

reload nginx.bat文件内容:nginx -s reload

 

3.        反向代理配置

修改部署目录下conf子目录的nginx.conf文件(如nginx-1.5.13\conf\nginx.conf)内容,可调整相关配置。

反向代理配置示例:

location / {

#设置主机头和客户端真实地址,以便服务器获取客户端真实IP

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

 

#禁用缓存

proxy_buffering off;

 

#设置反向代理的地址

proxy_pass http://192.168.1.1;

}

代理地址根据实际情况修改。

 

4.        负载均衡配置

nginx 的 upstream默认是以轮询的方式实现负载均衡,这种方式中,每个请求按时间顺序逐一分配到不同的后端服务器,如果后端服务器down掉,能自动剔除。

另外一种方式是ip_hash:每个请求按访问ip的hash结果分配,这样每个访客固定访问一个后端服务器,可以解决session的问题。

 

负载均衡配置示例:

upstream backend {

#ip_hash;

 

server 192.168.1.251;

server 192.168.1.252;

server 192.168.1.247;

}

 

server {

listen       80;

server_name  trffweb;

 

location / {

 

#反向代理的地址

proxy_pass http://backend;

}

}

 

Upstream命名和服务器地址根据实际情况修改。

 

5.        完整配置示例

nginx.conf:

 

worker_processes  1;

events {

worker_connections  1024;

}

 

http {

include       mime.types;

default_type  application/octet-stream;

sendfile        on;

keepalive_timeout  65;

 

upstream backend {

#ip_hash;

server 192.168.1.251;

server 192.168.1.252;

server 192.168.1.247;

}

 

server {

listen       80;

server_name  2;

 

location / {

#设置主机头和客户端真实地址,以便服务器获取客户端真实IP

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

 

#禁用缓存

proxy_buffering off;

 

#反向代理的地址

proxy_pass http://backend;

}

}

 

}

XCache Zend Guard Loader Zend OPcache在php.ini中的顺序

2016年6月1日 评论已被关闭

XCache Zend Guard Loader Zend OPcache在php.ini中的顺序
http://blogunion.org/posts/xcache-zend-guard-loader-zend-opcache-php-ini.html
我的WordPress缓存优化后,就是快,主要加了一些PHP扩展,比如:XCache、Zend Guard Loader、Zend OPcache、Memcache、Memcached等。很多朋友在加的过程中遇到了困难,发现几者之间存在共存问题,其实是可以共存的。

php.ini中加载这几个扩展是需要顺序的,我分享下我的加载顺序。在php.ini末依次加入:ZendOpcache、memcache、XCache、ZendGuardLoader。如果在配置上有什么问题,欢迎联系我为你解决。

nginx upstream的几种配置方式

2016年6月1日 评论已被关闭

nginx upstream的几种配置方式

http://yangzb.iteye.com/blog/560421
nginx算法
nginx 的upstream目前支持4种方式的分配
1、轮询(默认)
每个请求按时间顺序逐一分配到不同的后端服务器 ,如果后端服务器down掉,能自动剔除。
2、weight
指定轮询几率,weight和访问比率成正比,用于后端服务器性能不均的情况。
例如:
upstream bakend {
server 192.168.0.14 weight=10;
server 192.168.0.15 weight=10;
}
2、ip_hash
每个请求按访问ip的hash结果分配,这样每个访客固定访问一个后端服务器,可以解决session 的问题。
例如:
upstream bakend {
ip_hash;
server 192.168.0.14:88;
server 192.168.0.15:80;
}
3、fair(第三方)
按后端服务器的响应时间来分配请求,响应时间短的优先分配。
upstream backend {
server server1;
server server2;
fair;
}
4、url_hash(第三方)
按访问url的hash结果来分配请求,使每个url定向到同一个后端服务器,后端服务器为缓存时比较有效。
例:在upstream中加入hash语句,server语句中不能写入weight等其他的参数,hash_method是使用的hash算法
upstream backend {
server squid1:3128;
server squid2:3128;
hash   $request_uri;
hash_method crc32;
}
tips:
upstream bakend{#定义负载均衡 设备的Ip及设备状态
ip_hash;
server 127.0.0.1:9090 down;
server 127.0.0.1:8080 weight=2;
server 127.0.0.1:6060;
server 127.0.0.1:7070 backup;
}
在需要使用负载均衡的server中增加
proxy_pass http://bakend/ ;
每个设备的状态设置为:
1.down 表示单前的server暂时不参与负载
2.weight 默认为1.weight越大,负载的权重就越大。
3.max_fails :允许请求失败的次数默认为1.当超过最大次数时,返回proxy_next_upstream 模块定义的错误
4.fail_timeout:max_fails次失败后,暂停的时间。
5.backup: 其它所有的非backup机器down或者忙的时候,请求backup机器。所以这台机器压力会最轻。
nginx支持同时设置多组的负载均衡,用来给不用的server来使用。
client_body_in_file_only 设置为On 可以讲client post过来的数据记录到文件中用来做debug
client_body_temp_path 设置记录文件的目录 可以设置最多3层目录
location 对URL进行匹配.可以进行重定向或者进行新的代理 负载均衡

nginx负载均衡配置

2016年6月1日 评论已被关闭

nginx负载均衡配置
http://outofmemory.cn/code-snippet/3038/nginx-load-junheng-configuration
nginx负载均衡配置
使用负载均衡的话,可以修改配置http节点如下:

#设定http服务器,利用它的反向代理功能提供负载均衡支持
http {

#设定mime类型,类型由mime.type文件定义
include             /etc/nginx/mime.types;
default_type    application/octet-stream;

#设定日志格式
access_log        /var/log/nginx/access.log;

#省略上文有的一些配置节点
#。。。。。。。。。。

#设定负载均衡的服务器列表
upstream mysvr {
#weigth参数表示权值,权值越高被分配到的几率越大
server 192.168.8.1x:3128 weight=5;
#本机上的Squid开启3128端口,不是必须要squid
server 192.168.8.2x:80    weight=1;
server 192.168.8.3x:80    weight=6;
}

upstream mysvr2 {
#weigth参数表示权值,权值越高被分配到的几率越大
server 192.168.8.x:80    weight=1;
server 192.168.8.x:80    weight=6;
}

#第一个虚拟服务器
server {
#侦听192.168.8.x的80端口
listen             80;
server_name    192.168.8.x;

#对aspx后缀的进行负载均衡请求
location ~ .*\.aspx$ {
#定义服务器的默认网站根目录位置
root     /root;
#定义首页索引文件的名称
index index.php index.html index.htm;

#请求转向mysvr 定义的服务器列表
proxy_pass    http://mysvr ;

#以下是一些反向代理的配置可删除.

proxy_redirect off;

#后端的Web服务器可以通过X-Forwarded-For获取用户真实IP
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

#允许客户端请求的最大单文件字节数
client_max_body_size 10m;

#缓冲区代理缓冲用户端请求的最大字节数,
client_body_buffer_size 128k;

#nginx跟后端服务器连接超时时间(代理连接超时)
proxy_connect_timeout 90;

#连接成功后,后端服务器响应时间(代理接收超时)
proxy_read_timeout 90;

#设置代理服务器(nginx)保存用户头信息的缓冲区大小
proxy_buffer_size 4k;

#proxy_buffers缓冲区,网页平均在32k以下的话,这样设置
proxy_buffers 4 32k;

#高负荷下缓冲大小(proxy_buffers*2)
proxy_busy_buffers_size 64k;

#设定缓存文件夹大小,大于这个值,将从upstream服务器传
proxy_temp_file_write_size 64k;

}
}
}

nginx负载均衡配置的几种策略

2016年6月1日 评论已被关闭

nginx负载均衡配置的几种策略
http://outofmemory.cn/code-snippet/3074/nginx-load-junheng-configuration-jizhong-strategy
nginx负载均衡配置
nginx的upstream目前支持4种方式的分配

1、轮询(默认)

每个请求按时间顺序逐一分配到不同的后端服务器,如果后端服务器down掉,能自动剔除。

2、weight

指定轮询几率,weight和访问比率成正比,用于后端服务器性能不均的情况。 例如:

upstream bakend {
server 192.168.0.14 weight=10;
server 192.168.0.15 weight=10;
}
2、ip_hash

每个请求按访问ip的hash结果分配,这样每个访客固定访问一个后端服务器,可以解决session的问题。 例如:

upstream bakend {
ip_hash;
server 192.168.0.14:88;
server 192.168.0.15:80;
}
3、fair(第三方)

按后端服务器的响应时间来分配请求,响应时间短的优先分配。

upstream backend {
server server1;
server server2;
fair;
}
4、url_hash(第三方)

按访问url的hash结果来分配请求,使每个url定向到同一个后端服务器,后端服务器为缓存时比较有效。

例:在upstream中加入hash语句,server语句中不能写入weight等其他的参数,hash_method是使用的hash算法

upstream backend {
server squid1:3128;
server squid2:3128;
hash $request_uri;
hash_method crc32;
}
tips:

upstream bakend{#定义负载均衡设备的Ip及设备状态
ip_hash;
server 127.0.0.1:9090 down;
server 127.0.0.1:8080 weight=2;
server 127.0.0.1:6060;
server 127.0.0.1:7070 backup;
}
在需要使用负载均衡的server中增加

proxy_pass http://bakend/;

每个设备的状态设置为:

1.down 表示单前的server暂时不参与负载 2.weight 默认为1.weight越大,负载的权重就越大。 3.max_fails :允许请求失败的次数默认为1.当超过最大次数时,返回proxy_next_upstream 模块定义的错误 4.fail_timeout:max_fails次失败后,暂停的时间。 5.backup: 其它所有的非backup机器down或者忙的时候,请求backup机器。所以这台机器压力会最轻。

nginx支持同时设置多组的负载均衡,用来给不用的server来使用。

client_body_in_file_only 设置为On 可以讲client post过来的数据记录到文件中用来做debug
client_body_temp_path 设置记录文件的目录 可以设置最多3层目录
location 对URL进行匹配.可以进行重定向或者进行新的代理 负载均衡

Nginx 负载均衡配置和策略

2016年6月1日 评论已被关闭

Nginx 负载均衡配置和策略
http://outofmemory.cn/code-snippet/3040/Nginx-load-junheng-configuration-strategy
nginx负载均衡配置
Nginx 的 HttpUpstreamModule 提供对后端(backend)服务器的简单负载均衡。一个最简单的 upstream 写法如下:

upstream backend {
server backend1.example.com;
server backend2.example.com;
server.backend3.example.com;
}

server {
location / {
proxy_pass http://backend;
}
}
1、后端服务器
通过 upstream 可以设定后端服务器,指定的方式可以是 IP 地址与端口、域名、UNIX 套接字(socket)。其中如果域名可以被解析为多个地址,则这些地址都作为 backend。下面举例说明:

upstream backend {
server blog.csdn.net/poechant;
server 145.223.156.89:8090;
server unix:/tmp/backend3;
}
第一个 backend 是用域名指定的。第二个 backend 是用 IP 和端口号指定的。第三个 backend 是用 UNIX 套接字指定的。

2、负载均衡策略
Nginx 提供轮询(round robin)、用户 IP 哈希(client IP)和指定权重 3 种方式。

默认情况下,Nginx 会为你提供轮询作为负载均衡策略。但是这并不一定能够让你满意。比如,某一时段内的一连串访问都是由同一个用户 Michael 发起的,那么第一次 Michael 的请求可能是 backend2,而下一次是 backend3,然后是 backend1、backend2、backend3…… 在大多数应用场景中,这样并不高效。当然,也正因如此,Nginx 为你提供了一个按照 Michael、Jason、David 等等这些乱七八糟的用户的 IP 来 hash 的方式,这样每个 client 的访问请求都会被甩给同一个后端服务器。具体的使用方式如下:

upstream backend {
ip_hash;
server backend1.example.com;
server backend2.example.com;
server.backend3.example.com;
}
这种策略中,用于进行 hash 运算的 key,是 client 的 C 类 IP 地址(C 类 IP 地址就是范围在 192.0.0.0 到 223.255.255.255 之间,前三段号码表示子网,第四段号码为本地主机的 IP 地址类别)。这样的方式保证一个 client 每次请求都将到达同一个 backend。当然,如果所 hash 到的 backend 当前不可用,则请求会被转移到其他 backend。

再介绍一个和 ip_hash 配合使用的关键字:down。当某个一个 server 暂时性的宕机(down)时,你可以使用“down”来标示出来,并且这样被标示的 server 就不会接受请求去处理。具体如下:

upstream backend {
server blog.csdn.net/poechant down;
server 145.223.156.89:8090;
server unix:/tmp/backend3;
}
还可以使用指定权重(weight)的方式,如下:

upstream backend {
server backend1.example.com;
server 123.321.123.321:456 weight=4;
}
默认情况下 weight 为 1,对于上面的例子,第一个 server 的权重取默认值 1,第二个是 4,所以相当于第一个 server 接收 20% 的请求,第二接收 80% 的。要注意的是 weight 与 ip_hash 是不能同时使用的,原因很简单,他们是不同且彼此冲突的策略。

3、重试策略
可以为每个 backend 指定最大的重试次数,和重试时间间隔。所使用的关键字是 max_fails 和 fail_timeout。如下所示:

upstream backend {
server backend1.example.com weight=5;
server 54.244.56.3:8081 max_fails=3 fail_timeout=30s;
}
在上例中,最大失败次数为 3,也就是最多进行 3 次尝试,且超时时间为 30秒。max_fails 的默认值为 1,fail_timeout 的默认值是 10s。传输失败的情形,由 proxy_next_upstream 或 fastcgi_next_upstream 指定。而且可以使用 proxy_connect_timeout 和 proxy_read_timeout 控制 upstream 响应时间。

有一种情况需要注意,就是 upstream 中只有一个 server 时,max_fails 和 fail_timeout 参数可能不会起作用。导致的问题就是 nginx 只会尝试一次 upstream 请求,如果失败这个请求就被抛弃了 : ( ……解决的方法,比较取巧,就是在 upstream 中将你这个可怜的唯一 server 多写几次,如下:

upstream backend {
server backend.example.com max_fails fail_timeout=30s;
server backend.example.com max_fails fail_timeout=30s;
server backend.example.com max_fails fail_timeout=30s;
}
4、备机策略
从 Nginx 的 0.6.7 版本开始,可以使用“backup”关键字。当所有的非备机(non-backup)都宕机(down)或者繁忙(busy)的时候,就只使用由 backup 标注的备机。必须要注意的是,backup 不能和 ip_hash 关键字一起使用。举例如下:

upstream backend {
server backend1.example.com;
server backend2.example.com backup;
server backend3.example.com;
}

Nginx 负载均衡模块 ngx_http_upstream_module 详述

2016年6月1日 评论已被关闭

Nginx 负载均衡模块 ngx_http_upstream_module 详述
http://blog.csdn.net/defonds/article/details/13003121
译序:截至发稿时止,官方最新 ngx_http_upstream_module 指令详述。官方随时在更新,请及时关注官网最新公布。以下是官方原文。
ngx_http_upstream_module 模块用于定义可以被 proxy_pass、fastcgi_pass 以及memcached_pass 等指令引用的服务器群。
配置示例
[plain] view plain copy print?
upstream backend {
server backend1.example.com       weight=5;
server backend2.example.com:8080;
server unix:/tmp/backend3;

server backup1.example.com:8080   backup;
server backup2.example.com:8080   backup;
}

server {
location / {
proxy_pass http://backend;
}
}

动态可配置群,仅作为我们商业订阅的一部分:
[plain] view plain copy print?
upstream appservers {
zone appservers 64k;

server appserv1.example.com      weight=5;
server appserv2.example.com:8080 fail_timeout=5s slow_start=30s;
server 192.0.2.1                 max_fails=3;

server reserve1.example.com:8080 backup;
server reserve2.example.com:8080 backup;
}

server {
location / {
proxy_pass http://appservers;
health_check;
}

location /upstream_conf {
upstream_conf;
allow 127.0.0.1;
deny all;
}
}

指令
语法:upstream name { … }
默认值:—
上下文:http
定义一群服务器。服务器可以监听到不同的端口。此外,监听 TCP 和 UNIX-domian socket 的服务器可以混合定义。
例如:
[plain] view plain copy print?
upstream backend {
server backend1.example.com weight=5;
server 127.0.0.1:8080       max_fails=3 fail_timeout=30s;
server unix:/tmp/backend3;
}

默认情况下,请求是使用一个加权重的循环负载方法分配给各个主机的。在上面的例子中,每七个请求会以以下方案进行分配:五个请求分给 backend1.example.com 而另外两个请求分别分配给第二和第三个主机。如果在连接一台主机时发生错误,当前请求会被传给下一台主机,如此这般知道所有运行中的服务器都被尝试。如果没有任何主机成功返回,客户端会受到从最后一台主机返回的通信结果。
语法:server address [parameters];
默认值:—
上下文:upstream
定义一台主机的地址以及其他一些参数。地址可以被指定为一个域名或一个 IP 地址,端口号参数可选,或者被指定为 “unix:” 前缀之后的一个 UNIX-domain socket 路径。端口号没指定的话就使用端口号 80。解析到多个 IP 地址的域名会一次性定义多台主机。
可以定义以下参数:
weight=number
设置服务器的权重,默认为 1。
max_fails=number
设置由 fail_timeout 定义的时间段内连接该主机的失败次数,以此来断定 fail_timeout 定义的时间段内该主机是否可用。默认情况下这个数值设置为 1。零值的话禁用这个数量的尝试。由proxy_next_upstream、fastcgi_next_upstream、以及memcached_next_upstream 等指令来判定错误尝试。
fail_timeout=time
设置
在指定时间内连接到主机的失败次数,超过该次数该主机被认为不可用。
服务器被视为无效的时段。
这个参数默认是 10 秒钟。
slow_start=time
设置一台不健康的主机变成健康主机,或者当一台主机在被认为不可用变成可用时,将其权重由零恢复到标称值的时间。默认值为零,也就是说,禁用慢启动。
这个功能仅作为我们的商业订阅的一部分。
backup
将当前服务器标记为备份服务器。当主服务器不可用时,向备用服务器传递请求。
down
标记当前服务器为永不可用;和 ip_hash 指令一起使用。
举例:
[plain] view plain copy print?
upstream backend {
server backend1.example.com     weight=5;
server 127.0.0.1:8080           max_fails=3 fail_timeout=30s;
server unix:/tmp/backend3;

server backup1.example.com:8080 backup;
}

如果群里面只有一台主机,那么 max_fails、 fail_timeout 和 slow_start 参数将被忽略,而且这样的主机也永远不会被认为不可用。
语法:zone name size;
默认值:—
上下文:upstream
使群动态可配。定义持有群的配置和工作进程之间共享的运行时状态的共享内存区域的名字和大小。这样的群允许在运行时添加、删除和修改服务器。这个配置通过 upstream_conf 进行访问。
这一指令仅作为我们商业订购的一部分。
语法:ip_hash;
默认值:—
上下文:upstream
指定一个使用负载均衡方法根据客户端 IP 地址将请求分发给一些服务器的群。客户 IPv4 地址或者 IPv6 地址的前三个位群作为一个散列键。这个方法可以使同一个客户端的常常被发送给同一台主机,除非这台主机是不可用状态。在这种情况下(该主机不可用)客户端请求会被传递到另一台主机。大多数情况下,它将被发送给同一台主机。
Nginx 1.3.2 和 1.2.2 之后开始支持 IPv6 地址。
如果服务器中的一台需要临时移除掉,那么它应该使用 down 参数标记以保持客户 IP 地址的当前散列。
例如:
[plain] view plain copy print?
upstream backend {
ip_hash;

server backend1.example.com;
server backend2.example.com;
server backend3.example.com down;
server backend4.example.com;
}

在 Nginx 1.3.1 和 1.2.2 版本之前的版本是无法使用 ip_hash 负载均衡方式定义服务器权重的。
语法:keepalive connections;
默认:—
上下文:upstream
这一指令在 Nginx 版本 1.1.4 之后出现。
激活 upstream 服务器的连接缓存。
connections 参数设置保存在每个工作进程缓存中的 upstream 主机的闲置 keepalive 连接的最大个数。超出这个数目时,最近很少使用的连接被关闭。
应该特别指出的是 keepalive 指令并没有限制一个 Nginx 工作进程所能承载的连接总量。connections 应该设置为一个足够小的值以使 upstream 服务器也足以应对新的连接。
带有 keepalive 连接的 memcached upstream 配置例子:
[plain] view plain copy print?
upstream memcached_backend {
server 127.0.0.1:11211;
server 10.0.0.2:11211;

keepalive 32;
}

server {

location /memcached/ {
set $memcached_key $uri;
memcached_pass memcached_backend;
}

}

对于 HTTP,proxy_http_version 指令应该设置为 “1.1”,并且清空 “Connection” 头字段:
[plain] view plain copy print?
upstream http_backend {
server 127.0.0.1:8080;

keepalive 16;
}

server {

location /http/ {
proxy_pass http://http_backend;
proxy_http_version 1.1;
proxy_set_header Connection “”;

}
}

作为一种选择,HTTP/1.0 持久连接可以通过传递 “Connection: Keep-Alive” 头字段到 upstream 服务器来使用,虽然这种方法并不被推荐。
对于 FastCGI 服务器,需要为持久连接设置 fastcgi_keep_conn:
[plain] view plain copy print?
upstream fastcgi_backend {
server 127.0.0.1:9000;

keepalive 8;
}

server {

location /fastcgi/ {
fastcgi_pass fastcgi_backend;
fastcgi_keep_conn on;

}
}

当使用 round-robin 之外的负载均衡方法时,需要在 keepalive 指令之前将他们激活。
SCGI 和 uwsgi 协议没有长连接的概念。
语法:least_conn;
默认值:—
上下文:upstream
描述:这一指令出现在版本 1.3.1 和 1.2.2 中。
定义一群应该在请求传递给具有最小有效连接的服务器时使用的负载均衡方法,要考虑到服务器的权重。如果有很多这样的服务器,将会使用带权重的 round-robin 方法。
语法:health_check [interval=time] [fails=number] [passes=number] [uri=uri] [match=name];
默认值:—
上下文:location
激活定期健康检查。
支持以下可选参数:
interval:两次连续性健康检查的间隔时间,默认为 5 秒;
fails:设置连续性健康检查失败的次数,超过这个次数的话这台服务器就被认为是不健康的,默认为 1;
passes:设置连续性健康检查通过的次数,超过这个次数的话这台服务器就被认为是健康的,默认为 1;
uri:定义健康检查请求用的 URI,默认为 “/”;
match:定义健康检查返回通过的匹配块的配置;默认情况下,返回应该具有状态码 2XX 或者 3XX。
例如,
[plain] view plain copy print?
location / {
proxy_pass http://backend;
health_check;
}

将会每隔五秒钟发送 “/” 到 backend 群的每个服务器。如果有任何通信错误或者超时发生,或者代理服务器返回为 2XX 或者 3XX 之外的状态码,健康检查失败,这台服务器就被认为是不健康的了。来自客户端的请求不会被传递给不健康的服务器。
健康检查可以被配置成测试返回的状态码,头字段以及其值,还有正文内容。测试单独地使用 match 参数引用到的 match 指令进行配置,例如:
[plain] view plain copy print?
http {
server {

location / {
proxy_pass http://backend;
health_check match=welcome;
}
}

match welcome {
status 200;
header Content-Type = text/html;
body ~ “Welcome to nginx!”;
}
}

这一配置说明了健康检查通过的条件是,健康检查请求应该成功返回,拥有状态码 200,Content-Type 是为 “text/html”,并且在正文中包含 “Welcome to nginx!”。
服务器群必须属于共享内存。
如果一些健康检查是为同一群服务器而定义,一个失败的任何检查就会使相关服务器被认为是不健康的。
这个指令仅作为我们的商业订阅的一部分。
语法:match name { … }
默认值:—
上下文:http
定义已命名测试设置,用于核对健康检查请求的返回。
可以在一个返回中进行以下项目测试:
status 200;
状态码为 200。
status ! 500;
状态码不是 500。
status 200 204;
状态码为 200 或者 400。
status ! 301 302;
状态码既不是 301 也不是 302。
status 200-399;
状态码在 200 – 399 之间。
status ! 400-599;
状态码不在 400 – 599 之间。
status 301-303 307;
状态码是 301,302,303,或者 307。
header Content-Type = text/html;
头包含字段 “Content-Type” 值为 text/html。
header Content-Type != text/html;
头包含字段 “Content-Type” 值不是 text/html。
header Connection ~ close;
头包含字段 “Connection” 值匹配正则表达式 close。
header Connection !~ close;
头包含字段 “Connection” 值不匹配正则表达式 close。
header Host;
头包含字段 “Host”。
header ! X-Accel-Redirect;
头没有 “X-Accel-Redirect” 字段。
body ~ “Welcome to nginx!”;
正文匹配正则表达式 “Welcome to nginx!”。
body !~ “Welcome to nginx!”;
正文不匹配正则表达式 “Welcome to nginx!”。
如果以上有些被定义,那么返回必须全都匹配时才能说明它测试通过。
仅仅检查返回正文的头 256 k 个字节。
例如:
[plain] view plain copy print?
# status is 200, content type is “text/html”,
# and body contains “Welcome to nginx!”
match welcome {
status 200;
header Content-Type = text/html;
body ~ “Welcome to nginx!”;
}
# status is not one of 301, 302, 303, or 307, and header does not have “Refresh:”
match not_redirect {
status ! 301-303 307;
header ! Refresh;
}
# status ok and not in maintenance mode
match server_ok {
status 200-399;
body !~ “maintenance mode”;
}

这个指令仅作为我们的商业订阅的一部分。
语法:sticky cookie name [expires=time] [domain=domain] [path=path];
sticky route variable …;
默认值:—
上下文:upstream
这一指令开始出现于版本 1.5.7。
激活会话关联,可以使来自同一客户端的请求总是传递给一群服务器中的同一个。例如:
[plain] view plain copy print?
upstream backend {
server backend1.example.com;
server backend2.example.com;

sticky_cookie_insert srv_id expires=1h domain=example.com path=/;
}

没有绑定到特定服务器的客户端请求会被传递到由配置的负载均衡方法选中的服务器。这个客户端的而后的请求将被传递到同一台服务器。如果指定服务器无法处理请求,一台新的服务器会被选中绑定,就像这个客户端的这次请求前没有绑定到任何服务器一样。
关于绑定服务器的信息保存在 HTTP cookie 中。第一个参数设置 cookie 名。其他参数如下:
expires
设置浏览器保持 cookie 的时间。特别值 max 将会使 cookie 在 “31 Dec 2037 23:55:55 GMT” 才过期。这个是老的浏览器所能知道最大日期值了。如果这个参数没有定义,cookie 会在浏览器会话结束时过期。
domain
定义设置的 cookie 的域名。
path
定义设置的 cookie 的路径。
如果任何一个参数被遗漏掉,相应的 cookie 属性就不会被设置上。
这个指令仅作为我们的商业订阅的一部分。
语法:upstream_conf;
默认值:—
上下文:location
开启 location 域的 HTTP upstream 配置接口。对于这一 location 的访问应该是受限的。
配置命令可以用于:
查看一群中的主要和备用服务器;
查看一个特别的服务器;
修改一个特别的服务器;
添加一个新的服务器(参考下边注释);
移除一个特别的服务器。
正如在 server 指令中提到的那样,指定一个服务器作为一个域名可能导致多个服务器被添加到群。因为地址在一群不需要是独特的,单个服务器在一个群可以被唯一引用的话只有用他们的 ID。服务器的 ID 会被自动分配,并在群配置中显示。
一个配置命令包括作为请求参数传递的参数,例如:
http://127.0.0.1/upstream_conf?upstream=appservers
支持以下参数:
upstream=name
选择一群。这一参数是强制必须的。
backup=
如果没有设置,选中一群中的主要服务器。如果设置了,则选中一群中的备用服务器。
id=number
选中一群中特定的主要服务器或者备用服务器。
remove=
移调一群中一台特定的主要服务器或者备用服务器。
add=
添加一台主要服务器或者备用服务器到群。
server=address
同 server 指令中的 “address” 参数。
weight=number
同 server 指令中的 “weight” 参数。
max_fails=number
同 server 指令中的 “max_fails” 参数。
fail_timeout=time
同 server 指令中的 “fail_timeout” 参数。
slow_start=time
同 server 指令中的 “slow_start” 参数。
down=
同 server 指令中的 “down” 参数。
up=
同 server 指令中的 “down” 参数相反。
前三个参数用于选择命令适用的对象。
比如,查看群组里头的主服务器,发送:
http://127.0.0.1/upstream_conf?upstream=appservers
查看群组里头的备用服务器,发送:
http://127.0.0.1/upstream_conf?upstream=appservers&backup=
查看群组里头特定的主服务器,发送:
http://127.0.0.1/upstream_conf?upstream=appservers&id=42
查看群组里头特定的备用服务器,发送:
http://127.0.0.1/upstream_conf?upstream=appservers&backup=&id=42
要添加一台主服务器或者备用服务器到群组,在 “server=” 参数中定义其地址即可。如果没有定义其他参数,该服务器添加后,其他参数设置为默认值(参见 server 指令)。
例如,添加一台新的主服务器到群组,发送:
http://127.0.0.1/upstream_conf?add=&upstream=appservers&server=127.0.0.1:8080
添加一台新的从服务器到群组,发送:
http://127.0.0.1/upstream_conf?add=&upstream=appservers&backup=&server=127.0.0.1:8080
添加一台主服务器到群组,设置其参数非默认值,且将其标记为 “down”,发送:
http://127.0.0.1/upstream_conf?add=&upstream=appservers&server=127.0.0.1:8080&weight=2&max_fails=3&fail_timeout=3s&down=
移除群组中的一台特定主服务器或者备用服务器,可以使用 id= 参数将其选择。
例如,移除群组中的一台特定主服务器,发送:
http://127.0.0.1/upstream_conf?remove=&upstream=appservers&id=42
移除群组中的一台特定从服务器,发送:
http://127.0.0.1/upstream_conf?remove=&upstream=appservers&backup=&id=42
修改群组中的一台特定的主服务器或从服务器,也使用 id= 参数将其选中。
例如,修改群组中一台特定主服务器为 “down”,发送:
http://127.0.0.1/upstream_conf?upstream=appservers&id=42&down=
修改群组里头的一台备用服务器地址,发送:
http://127.0.0.1/upstream_conf?upstream=appservers&backup=&id=42&server=192.0.2.3:8123
修改群组里头的一台主服务器的其他参数,发送:
http://127.0.0.1/upstream_conf?upstream=appservers&id=42&max_fails=3&weight=4
这个指令仅作为我们的商业订阅的一部分。
嵌入式变量
ngx_http_upstream_module 模块支持以下嵌入式变量:
$upstream_addr
为 UNIX-domain socket 保存服务器地址及端口号。如果请求处理时涉及多台服务器,使用逗号将他们的地址进行分隔,比如 “192.168.1.1:80, 192.168.1.2:80, unix:/tmp/sock”。如果一个由 “X-Accel-Redirect” 或者错误页面 发出的从一个服务器群组到另一个群组的重定向发生时,不同群组之间的服务器地址使用冒号分隔,比如 “192.168.1.1:80, 192.168.1.2:80, unix:/tmp/sock : 192.168.10.1:80, 192.168.10.2:80″。
$upstream_cache_status
保存访问响应缓存的状态(版本 0.8.3)。这一状态可以是 “MISS”,”BYPASS”,”EXPIRED”,”STALE”,”UPDATING” 或者 “HIT”。
$upstream_response_length
保存从 upstream 服务器获得的响应体长度(版本 0.7.27)字节的长度。几个响应长度的话使用逗号和冒号分隔,就像 $upstream_addr 中的地址那样。
$upstream_response_time
保存从 upstream 服务器获得的响应次数,长度以毫秒的分辨率保存,单位是秒。几个响应次数的话使用逗号和冒号分隔,就像 $upstream_addr 中的地址那样。
$upstream_status
保存从 upstream 服务器获得的响应码。几个响应码的话使用逗号和冒号分隔,就像 $upstream_addr 中的地址那样。
$upstream_http_…
保存服务器响应头。比如,”Server” 响应头可以使用 $upstream_http_server 参数激活。将头信息转化为参数名字的规则和以 “$http_” 前缀开始的参数规则一样。只保存最后一个响应头。
原文链接:http://nginx.org/en/docs/http/ngx_http_upstream_module.html。