haproxy实现负载均衡和动静分离

cnn

　　在做过了haprxy负载均衡和动静分离后，haproxy在这两方面的确比nginx更专业一些，session保持，cookie引导，url监测后端，mysql负载均衡等都是nginx所不具备的；但这并不能就说haprox就能取代nginx，nginx的缓存就是proxy所不具备的。
　　下面就来用haproxy做些基础的配置吧。
　　haproxy：192.168.3.124
　　node1：192.168.3.128
　　node2：192.168.3.129
　　一.基础配置:
　　1.安装proxy
　　yum install haproxy -y
　　现在的稳定版本1.5.X
　　cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.bak
　　2.开启proxy的系统日志
　　

vim/etc/rsyslog.conf
$ModLoad imudp
$UDPServerRun 514
local2.*                                               /var/log/haproxy.log
service rsyslog restart

　　3.修改配置文件实现简单的负载均衡

global
log         127.0.0.1 local2
chroot      /var/lib/haproxy
pidfile     /var/run/haproxy.pid
maxconn     4000# 定义每个haproxy进程的最大连接数 ，由于每个连接包括一个客户端和一个服务器端，所以单个进程的TCP会话最大数目将是该值的两倍。
user        haproxy
group       haproxy
daemon# 以守护进程的方式运行
nbproc 16## 设置haproxy启动时的进程数，根据官方文档的解释，我将其理解为：该值的设置应该和服务器的CPU核心数一致，即常见的2颗8核心CPU的服务器，即共有16核心，则可以将其值设置为：<=16 ，创建多个进程数，可以减少每个进程的任务队列，但是过多的进程数也可能会导致进程的崩溃。这里我设置为16
# turn on stats unix socket
stats socket /var/lib/haproxy/stats
defaults
mode                    http
log                     global
option                  httplog
option                  dontlognull# 启用该项，日志中将不会记录空连接。所谓空连接就是在上游的负载均衡器或者监控系统为了探测该服务是否存活可用时，需要定期的连接或者获取某一固定的组件或页面，或者探测扫描端口是否在监听或开放等动作被称为空连接；官方文档中标注，如果该服务上游没有其他的负载均衡器的话，建议不要使用该参数，因为互联网上的恶意扫描或其他动作就不会被记录下来
option http-server-close#对于某些server端不支持http长连接的情况，利用这个参数可以使用客户端到haproxy是长连接，而haproxy到server端是短连接
option forwardfor       except 127.0.0.0/8
option                  redispatch#当使用了cookie时，haproxy将会将其请求的后端服务器的serverID插入到cookie中，以保证会话的SESSION持久性；而此时，如果后端的服务器宕掉了，但是客户端的cookie是不会刷新的，如果设置此参数，将会将客户的请求强制定向到另外一个后端server上，以保证服务的正常。
retries                 3# 定义连接后端服务器的失败重连次数，连接失败次数超过此值后将会将对应后端服务器标记为不可用
timeout http-request    10s
timeout queue           1m
timeout connect         10s
timeout client          1m
timeout server          1m
timeout http-keep-alive 10s
timeout check           10s
maxconn                 3000
frontend  main *:80# 定义一个名为main的前端部分
default_backend             app#没有任何匹配的情况下，默认指向的后端服务器
backend app#定义一个名为app的后端部分
balance     roundrobin
server  app1 192.168.3.128:80 check
server  app2 192.168.3.129:80 check
stats enable#启用服务器的状态监控页
　　配置完毕后，需要重启haproxy
　　service haproxy restart
　　4.测试
　　[iyunv@usvr-124 haproxy]# curl 192.168.3.124/1.html
　　hello,192.168.3.129
　　[iyunv@usvr-124 haproxy]# curl 192.168.3.124/1.html
　　hello,192.168.3.128


　　由此看出是负载均衡的策略是轮询访问。
　　5.让我们来看下状态监控页。



　　
　　通过以上基础配置，我们差不多已经基本了解了haproxy的工作机制了，下面我们再来进阶下吧。
　　二.实现访问页面的动静分离
　　

global
chroot      /var/lib/haproxy
pidfile     /var/run/haproxy.pid
maxconn     4000
user        haproxy
group       haproxy
daemon
# turn on stats unix socket
stats socket /var/lib/haproxy/stats
defaults
mode                    http
log                     global
option                  httplog
option                  dontlognull
option http-server-close
option forwardfor       except 127.0.0.0/8
option                  redispatch
retries                 3
timeout http-request    10s
timeout queue           1m
timeout connect         10s
timeout client          1m
timeout server          1m
timeout http-keep-alive 10s
timeout check           10s
maxconn                 3000
frontend  main *:80
acl url_static       path_beg       -i /static /images /javascript /stylesheets#新建acl策略 path_beg:以/static /images等开头的访问路径，-i 忽略大小写
acl url_static       path_end       -i .jpg .gif .png .css .js#新建acl策略 path_end：以.jpg .gif等结尾的访问路径，-i 忽略大小写
use_backend static          if url_static#如果匹配url_static这个acl策略，则使用static这个后端
default_backend             app#没有任何配置的情况下，使用默认的后端app
backend static
balance     roundrobin#轮询访问
server      static 192.168.3.128:80 check
backend app
balance     roundrobin#轮询访问
server  app2 192.168.3.129:80 check

　　在这里我们新建了几条acl策略，用于实现了
　　1.当访问以/static /images /javascript /stylesheets开头的路径和.jpg .gif .png .css .js结尾的路径时，指向192.168.3.180这台后端服务器上
　　2.当没有任何匹配的情况下，指向默认的后端服务器192.168.3.129
　　我就不贴出访问结果了。
　　总结：通过上面的两个例子，我们了解了haproxy在负载均衡的强大之处，当然还可以实现mysql的读的负载均衡，至于更高级的功能让我们慢慢去了解吧。