http层负载均衡之haproxy

uyfrjk

http层负载均衡之haproxy实践篇（一）

方案
　　上篇文章讲到了负载均衡的相关理论知识，这篇文章我打算讲讲实践方法以及实践中遇到的问题
　　方案：haproxy http层负载均衡
　　安装一个haproxy服务，两个web服务
　　haproxy：192.168.1.227:80
　　web1 http://192.168.1.226:8081/login
　　web2 http://192.168.1.246:8888/login
　　web服务自行准备，文章中就不说了
　　负载均衡算法为轮询调度
　　会话保持实现方式为cookie识别，插入cookie
　　优点：
　　1 配置简单
　　2 提供会话保持功能
　　3 性能不错

安装与配置
　　安装



tar -zxvf haproxy-1.49.tar.gz   
cd haproxy-1.4.9  
make TARGET=linux26 PREFIX=/haproxy   
make install PREFIX=/haproxy
创建目录 mkdir /home/haproxy/logs/
　　配置





global  
log 127.0.0.1   local3  
#log 127.0.0.1  local1 notice  
#log loghost    local0 info  
maxconn 4096
#chroot /usr/local/haproxy
#chroot /home/haproxy  
uid 502
gid 502
daemon  
nbproc 1  
pidfile /home/haproxy/logs/haproxy.pid  
#debug  
#quiet  
defaults  
log     global
mode    http  
option  httplog  
option  dontlognull  
option  forwardfor  
option  redispatch
log     127.0.0.1 local3
retries 3  
maxconn 32000  
balance roundrobin  
stats   uri     /haproxy-stats  
contimeout      5000  
clitimeout      50000  
srvtimeout      50000  
listen   web_proxy *:80
appsession JSESSIONID len 52 timeout 3h
#插入cookie的方式
cookie SRV insert indirect nocache
#模式有http tcp health
mode http
stats enable
stats hide-version
#查看状态
stats uri /haproxy-stats
stats refresh 10s
monitor-uri /haproxy_test
#负载均衡方案:轮调
balance roundrobin
option httpclose
#后端可以获取客户端的真实ip
option forwardfor
#健康检查
option httpchk HEAD /login HTTP/1.0
#option  httpchk GET /ping.jsp
#后端真实服务
server  webA 192.168.1.226:8081 cookie A check  
server  webB 192.168.1.246:8888 cookie B check

　　这里注意配置检查地址
　　option httpchk HEAD /login HTTP/1.0
　　启动
　　/usr/local/sbin/haproxy -f /etc/haproxy/haproxy.cfg
　　查看进程
　　ps -ef|grep haproxy
　　关闭进程
　　kill –9 pid
　　查看监控页面
　　http://192.168.1.227/haproxy-stats
　　如下图：注意状态一栏显示200，如果不是则表示web服务器未启动，或者健康检查链接不可访问

　　测试
　　然后打开不同的浏览器，模拟用户访问
　　http://192.168.1.227/login/
　　会看到

　　

　　证明请求被分发到不同的web服务器了
　　查看cookie

　　cookie被加入了SRV=A
　　会话保持的流程
　　1.客户端首次请求，经过haproxy到web服务端时，web服务端set-cookie并响应到haproxy
　　2.haproxy在cookie后插入SRV=A，并响应客户端
　　3.客户端第二次请求，经过haproxy时，haproxy将srv后缀去掉，然后请求服务端
　　总结
　　该方案解决的问题
　　1.负载均衡，并解决web服务的单点故障
　　2.会话保持
　　存在的缺点
　　1.web服务器的session保存存在单点故障，即其中一台web服务器宕机之后，存储在上面的session也会丢失
　　2.负载均衡服务器存在单点故障
　　下一篇文章将讨论如何解决以上2个缺点
　　
　　上篇文章 大型网站系统架构的演进（三）如何提高网站的高可用和高性能
　　目录 大型网站系统架构的演进目录






分类: 大型网站架构