Tag: haproxy

HAproxy 代理redis

转眼2012 的1 月要过去了。。。还是不要空着一个月吧,随便写点什么记录一下。

1 月实践了一下haproxy  作为redis 的代理,统一了所有的redis 入口,对于应用来说,其实最好还是有一个全局的队列,这个中间层完全接管了mysql 和nosql 的写入读取。大工程啊,这里还是说一下简单的。

直接上配置吧:

global
log 127.0.0.1  local3 notice
ulimit-n 40960
maxconn 10240
user haproxy
group haproxy
nbproc  4
daemon
quiet
defaults
log     global
mode    http
option tcplog
balance roundrobin
stats uri /redis-proxy
stats auth hello:123
contimeout 5000
clitimeout 30000
srvtimeout 30000
listen monitor
mode http
bind 0.0.0.0:2000
listen redis
bind 0.0.0.0:6379
mode   tcp
option tcpka
server redis1 192.168.100.1:6379 check inter 5000 fall 3
server redis2 192.168.100.2:6379 check inter 5000 fall 3 backup

我这里两个redis ,一个是active 状态对外服务,另一个是热备。

用redis-benchmark 来随便打了一下压力,和redis-cli 直连性能上差不多。

timeout 一定要配置,之前就是忘了配置,其中一个down 了以后很久都不切。

haproxy 简单配置一个tcp 代理

haproxy 的tcp 应用,我实操过两次,一次是svn ,一次是openfile 。

最近一次就是openfire 了,因为忘了当时做svn tcp 代理时的配置,弄得焦头烂额的。。。mark 下,以免以后再次需要的时候忘记了。

global
log 127.0.0.1  local3 notice
ulimit-n 40960
maxconn 10240
user haproxy
group haproxy
nbproc  4
daemon
quiet
defaults
log     global
mode    tcp
option tcplog
listen mm
bind 0.0.0.0:5222
balance roundrobin
mode   tcp
server test 192.168.50.148:5222
当时的需求很简单,就是把访问到本机的5222 端口的所有请求代理到 148 的5222 。用iptables 其实也可以,却发现那台机器是openvz (BS 一下卖这个虚拟机给我朋友的某国内某大公司),用 iptables nat 的话,貌似要提权。

亚运赛事系统架构探索

广州亚运亚残在今天落幕了,一班亚运的同事将要离职,真让人伤感。随便写篇东西纪念一下我为亚运付出的一个月。

亚运赛事系统最初的系统架构,非常简单,就是前端用一堆组了lvs 的 squid 作为cache server ,后端跑nginx+resin 。

这个架构,优点就是够简单,如果cache server 不够,就横向扩展,同样简单。

但是,当整个系统的瓶颈不在缓存端时,缺点也很明显了。我发现,后端的load 很容易跑高,特点就是,缓存时间比较短(1 分钟),然后前端的穿透较多,再且,前端的访问很散列,并没有特别的热点。这样,如果作横向扩展,只会对后端的压力越大,因为穿透更多了。

之前去听SACC 2010 的,其实很多公司都用了一层haproxy 做 url hash 。于是,就对现有的架构作一次调整,希望对当时的负载情况有所帮助。

调整后的架构是这样的:最前端是一堆组了lvs 的haproxy ,作用是url hash 到后端的cache 。nginx 其实也是可以做url hash 的,在这里,选择nginx 还是 haproxy 呢,功能上nginx 确实稍胜一筹,但性能上 haproxy 也略优,选择什么也可以按个人爱好来定。呵呵。cache server 端,我也做了小调整,因为不需要只使用一个80 端口了,我一台服务器上跑两个squid 。用taskset 把2 个squid 绑定到cpu1 和 cpu2(默认都是cpu0 ) ,让cpu0 处理系统调用,cpu3 处理网络io 。一台4G 的服务器,在这个情况下已经算是把服务器使用得很尽了。cachedir 一律使用内存分区,不要出现磁盘io 。

但这个架构也不是绝对无敌,url hash 最怕遇到热点,特别热那种,就像110米跨栏决赛和男篮决赛。因为单一的url 并发过高,而导致其中一个cache server 跑满了一个cpu(url hash 把这个url 都调度到这个cache ) ,众所周知,squid 只能使用一个cpu ,这个cpu 跑满载了,请求就会开始阻塞了。然后连接数不断彪高,直接导致了前端的haproxy 也挂了,同时骨牌效应,所有的haproxy 都挂了。。。无奈,只好针对这个url 做特殊处理,rr 分配到后端多个squid ,而不走url hash 了。真是害人不浅阿。。。如果可以预先知道将会是热点的url ,这个问题将会更好解决,而不是要到haproxy 挂了才去处理。

末了,贴一下haproxy 的url hash 配置吧:

global
log 127.0.0.1 local3 notice
ulimit-n 409600
maxconn 102400
chroot /home/haproxy
pidfile /home/haproxy/var/haproxy.pid
user haproxy
group haproxy
nbproc 4
daemon
quiet

defaults
log global
mode http
option httplog
option dontlognull
option redispatch
option forwardfor
option httpclose
option log-separate-errors
monitor-uri /do_not_delete/monitor.txt
retries 3
stats uri /haproxy-status
maxconn 102400
contimeout 5000
clitimeout 50000
srvtimeout 50000
stats auth admin:123456

frontend http_server
bind :80
default_backend info_cache
acl url_static path_end BKM400101.json
use_backend info_cache_temp if url_static

backend info_cache
option httpchk HEAD /live.js HTTP/1.1\r\nHost:\ info.2010.163.com
balance uri len 15 # url hash
server inst1 192.168.51.1:3128 check inter 5000 fall 3
server inst2 192.168.51.1:3129 check inter 5000 fall 3
server inst3 192.168.51.2:3128 check inter 5000 fall 3
server inst4 192.168.51.2:3129 check inter 5000 fall 3
server inst5 192.168.51.3:3128 check inter 5000 fall 3
server inst6 192.168.51.3:3129 check inter 5000 fall 3

backend info_cache_temp
option httpchk HEAD /live.js HTTP/1.1\r\nHost:\ info.2010.163.com
balance roundrobin # rr
server inst1 192.168.51.1:3128 check inter 5000 fall 3
server inst2 192.168.51.1:3129 check inter 5000 fall 3
server inst3 192.168.51.2:3128 check inter 5000 fall 3
server inst4 192.168.51.2:3129 check inter 5000 fall 3
server inst5 192.168.51.3:3128 check inter 5000 fall 3
server inst6 192.168.51.3:3129 check inter 5000 fall 3

其实这个架构只是一个调优,如果整套系统需要优化的话,还是需要从最初的设计入手,很多细节都要顾及。

细节包括,那些数据传输的地址,不要使用163.com 的,因为带了很大串的cookie ,用户每一次访问都带有这么一大串,是很占带宽的。还有根据不同的文件设置不同的缓存,这个最初没有设计好的话,js , css 等文件就混入到163.com 的域名中难以隔离。还需要根据具体的业务去配置一下缓存。业务数据,一定要从一开始就要有系统地收集统计,调优后对比分析。等等等等。。。

在这个架构下,前面的haproxy 只是纯代理,后面的cache server ,可以任意选择,经典一点的,可以用 squid 。或者上varnish ,再或者试用 ATS 。

haproxy 打印 log 的问题

haproxy 可以把 log 打印到 syslog 去,但是,如果单纯地在 haproxy 的配置上写了这句:

log 127.0.0.1   local0

是不够的,即使你在 syslog 的配置里也写上了这句:

local0.*    /var/log/haproxy/local0.log

也还是不够的,haproxy 也不会把log 打印到相应的文件里。

需要修改 /etc/default/syslogd ,把

SYSLOGD=””   修改为   SYSLOGD=”-r”

然后重启一下 syslogd

/etc/init.d/sysklogd restart

我的系统是 debian ,centos 没去测试,syslog 的配置上印象中有点不同的。

原因可以参考这两段东西:

man 8 syslogd :

-r     This  option will enable the facility to receive message from the network using an internet domain socket with the syslog service (see ser-
vices(5)).  The default is to not receive any messages from the network.

———————————–

less configuration.txt:

log <address> <facility> [max level [min level]]

<address> can be one of:

– An IPv4 address optionally followed by a colon and a UDP port. If
no port is specified, 514 is used by default (the standard syslog
port).

– A filesystem path to a UNIX domain socket, keeping in mind
considerations for chroot (be sure the path is accessible inside
the chroot) and uid/gid (be sure the path is appropriately
writeable).

———————————————

haproxy 可以把log 打印去两个地方,一个是 监听着 514 udp 端口的 syslog ,一个是 unix socket 。而 syslog 的 -r 参数,就是让 syslog 监听514 port 的。

又或者让 haproxy 连接去 syslog 的 unix socket 也行,

syslogd -a /etc/haproxy/syslog.sock  让 syslogd 监听在unix socket ,这时,haproxy 可以这样配置

log /etc/haproxy/syslog.sock   local0

此 socket 必须在 haproxy 的 chroot 环境中。

==========================
update:

centos 下,修改 /etc/sysconfig/syslog ,把

SYSLOGD_OPTIONS=”-m 0″

改为

SYSLOGD_OPTIONS=”-m 0 -r”

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

update 2011-03-25:

现在装的debian 下,一般使用rsyslog 了。

其实,以前的syslog 之所以要加 -r ,就是为了syslog 能监听514 端口,而在 rsyslog 中,-r 参数并不能令到它监听514 。

应该作以下修改:

/etc/rsyslog.conf 中

# provides UDP syslog reception
# $ModLoad imudp
# $UDPServerRun 514

把注视去掉

# provides UDP syslog reception

$ModLoad imudp

$UDPServerRun 514