“软”负载均衡学习点滴（三）

Author : 岑文初

Email: [e-mail]

Blog: http://blog.csdn.net/cenwenchu79

Date: 2009-5-26

目录

需求转而学习... 2

“软”负载均衡... 2

LVS （Linux Virtual Server）... 3

Virtual Server三种模式介绍... 3

Virtual Server三种模式的比较... 5

Virtual Server三种模式实践... 6

三种模式下的简单压力测试... 9

HA-Proxy. 10

HA-Proxy安装和使用... 10

HA-Proxy的压力测试结果... 15

“软”负载学习心得... 15

HA-Proxy

HA-Proxy相比LVS的使用要简单很多，功能方面也很丰富。HA-Proxy可以在4，7两层作负载均衡，4层大多用于邮件服务器、内部协议通信服务器等作负载均衡，7层用于Http分析负载转发。

在HA-Proxy官方网站可以下载配置说明文档(configuration.txt)和架构文件(architecture.txt)作为参考。具体的使用细节不做太多介绍，这里主要通过具体的配置来大致说一下HA-Proxy的结构。

HA-Proxy 组件图

HA-Proxy配置中分成四部分内容，当然这些组件不是必选的，可以根据需要选择部分作为配置。Defaults组件是配置默认参数的，这些参数可以被利用配置到frontend，backend，listen组件中（当这些组件某些参数没有被配置而在Defaults中配置了）。Frontend组件是接收请求的前端虚拟节点，就类似于LVS中配置了VIP的Load Balancer，Frontend可以直接指定后端指向那一个backend(可动态选择)。Backend是后端服务集群的配置，类似于LVS中的那些Real Server，一个Backend对应一个或者多个实体服务器。Listen是Frontend和Backend的组合体，可以直接定义一个类似于JBoss的 Server Farm。还有一些默认的配置可以通过在配置文件中配置或者在命令行中作为参数输入。

HA-Proxy安装和使用

安装HA-Proxy：

1． 下载HA-Proxy安装包。

2． 解压执行make TARGET=linux26（注意，TARGET后面根据本机操作系统内核版本来填写）

3． Make install

4． 目录下执行haproxy，如果有使用说明出现表示已经安装正常。

5． 使用方式haproxy –f 配置文件地址。（例如 haproxy –f haproxy.cfg）

HA-Proxy日志配置说明：

HA-Proxy可以收集本机及其他后端服务器日志，但是需要在Load Balancer上作一些配置。

首先修改/etc/sysconfig/syslog文件，将SYSLOGD_OPTIONS="-m 0” 修改为SYSLOGD_OPTIONS="-m 0 -r -x"，支持收集远程服务器日志。

然后修改/etc/syslog.conf，增加如下语句：

#add by haproxy

local0.* /home/admin/tools/haproxy-1.3.17/haproxy.log // haproxy.log地址代表了需要存储日志的地址

执行service syslog restart，重新启动系统日志器

最后就是在HA-Proxy的配置中增加日志输出（具体可以参考后面的配置文件说明）

HA-Proxy配置文件说明：

下面的配置文件简单来说就是配置了根据请求参数的不同，将请求分别定向到后端的淘宝集群和阿里软件集群。具体配置文件(haproxy.cfg)如下：

log 127.0.0.1 local0 info //日志输出配置，所有的日志都记录在本机，通过local0的系统日志器输出，这关系到前面我们做的配置

daemon //以后台进程方式启动Ha-proxy

nbproc 2 //启动两个ha-proxy进程实例

pidfile /home/admin/tools/haproxy-1.3.17/haproxy.pid // pid记录的文件

defaults //默认配置

mode http //默认采用http模式，可以配置tcp来做4层消息转发

option httplog //采用http日志格式

retries 3 //三次连接失败就认为是服务器不可用，主要是通过后面的check配置来实现服务器状态检查

maxconn 2000 //最大连接数

contimeout 5000 //连接超时时间

clitimeout 50000 //客户端连接超时时间

srvtimeout 50000 //服务端连接超时时间

stats uri /admin?stats //服务器状态统计查看页面

stats auth wenchu:wenchu //服务器状态查看授权的用户名和密码设置，可以不设置

option httpchk HEAD /welcome.html HTTP/1.0 //服务器状态检查设置，这里是向每一个后端服务器请求/welcome.html页面来检查服务端健康状况。

frontend http-in //前端节点定义

bind :8181 //虚拟服务节点监听本地的8181端口

mode http

log global

option httplog

option httpclose //每次请求完毕后主动关闭http通道，HA-Proxy不支持keep-alive模式，只能够模拟这种模式的实现

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

capture request header Host len 20 //此配置和一下的类似配置都是抓取Http请求中的参数记录到日志中。

capture request header User-Agent len 16

capture request header Content-Length len 10

capture request header Referer len 20

capture response header Content-Length len 10

//控制策略的配置

acl api_taobao url_sub -i sip_apiname=taobao. //在请求url中包含sip_apiname=taobao，则此控制策略返回true,否则为false

acl api_alisoft url_sub -i sip_apiname=alisoft. //在请求url中包含sip_apiname=alisoft，则此控制策略返回true,否则为false

acl invalid_req url_sub -i sip_apiname= //在请求url中包含sip_apiname=，则此控制策略返回true,否则为false

acl stat_req url_dir -i admin //在请求url中存在admin作为部分地址路径，则此控制策略返回true,否则返回false

block if !invalid_req !stat_req //block表示阻止请求，返回403错误，当前表示如果不满足策略invalid_req，同时也不满足策略stat_req，则阻止请求。（就是要求URL中必需有参数sip_apiname，除非是查看服务器状态的URL）。

use_backend alisoft_server if api_alisoft //如果是满足策略api_alisoft的情况，则使用alisoft_server作为后端服务集群。

use_backend taobao_server if api_taobao //如果是满足策略api_taobao的情况，则使用taobao_server作为后端服务集群。

default_backend alisoft_server //使用alisoft_server作为默认后端服务集群。

backend alisoft_server //后端节点定义

mode http

balance roundrobin //负载均衡策略配置

cookie SERVERID //允许插入serverid到cookie中，serverid后面可以定义

server app1 10.2.225.139:80 cookie 1 check fall 5 weight 1 //真实服务器配置定义cookie 1表示serverid为1，check表示需要状态检查，fall 5表示失败五次就认为服务器状态不可用（不在接受请求），weight 1表示权重

server app2 10.2.225.136:80 cookie 2 check fall 5 weight 2

backend taobao_server //后端节点定义

mode http

server app3 10.2.226.41:80 check fall 5

完成配置后，执行haproxy –f haproxy.cfg，后台进程就可以启动了，然后在浏览器中输入刚才定义的状态检查地址可以看到如下内容：

可以看到定义的前端和后端节点的状态。对于Ha-proxy很多配置这里面都没有使用，也没有详细讲解，使用者可以通过查看官方的配置文档了解细节。下面三个图片分别说明了对于sip_apiname不同的访问产生最后的结果。

上图的sip_apiname为alisoft.get.user，因此被定向到Alisoft集群，也就是136或者139上（这里是136处理了服务）。

上图的sip_apiname为taobao.get.user，因此被定向到Alisoft集群，也就是41上。

上图的sip_apiname没有传递，因此被拒绝访问，返回403错误。

HA-Proxy的压力测试结果

简单的压力测试采用Apache ab，500并发用户，10w的请求总数。

	总耗时(s)	TPS(#/sec)
LVS-NAT	22.480	4448.34
LVS-TUNNEL	10.707	9339.80
LVS-DR	10.177	9825.68
HA-2Node	21.387	4675.61
HA-5Node	27.371	3653.37

HA-2Node为配置了两个节点作为后段的服务节点，HA-5Node为配置了5个节点作为后端的服务处理节点。上面结果看到2个节点的HA反而比5个节点的速度来的快，同时HA在7层的转发和LVS-NAT性能相近。

HA-Proxy使用下来，总体上感觉比较简单，但功能却十分强大，但是性能方面来说需要关注在多节点和高压力的情况下的表现。

“软”负载均衡学习心得

从LVS三种模式中也看到了类似于分布式文件系统的一些设计经验，就是避免在管理资源过程中，让Manager成为了系统瓶颈。就好比LVS-NAT中的Load Balancer既负责请求分配同时也负责消息回复，成为了系统的关键节点，自身性能损耗比较大，加上算法对于数据采集的要求，自身稳定性和可用性下降，最后影响了整个架构。在HDFS中，Master的责任就和明晰，就是负责节点管理，不参与数据传输和通道建立，因此就可以很大程度上提升自身的效率。资源管理（申请，归还，状态检查等）和资源使用应该清晰的划分开来，这样可以让各个角色可以更好的独立的满足需求，防止由于其他功能影响到了“本职工作”。

就负载均衡效率来说，硬件实现负载均衡应该优于用软件实现负载均衡，就好比SSL硬件加速器要远优于SSL软件解析模块。但从另一个角度来看，分布式计算，分布式存储，分布式DB都采用横向扩展结合低成本资源的方式满足需求。而软件实现负载在很多情况下可以尽可能的降低成本，同时在性能损失较小的情况下实现硬件负载所支持的所有功能。因此在一定的环境下，部分采用软件来实现负载均衡能够增加可扩展性，提升配置灵活度，降低配置成本。

从LVS到HA-Proxy，可以发现不论从4层做转发还是7层做转发都会存在损失，而且LVS-NAT模式和HA-Proxy都会受到解析负载度和内容大小的影响。因此完全采用软件负载或者采用某一种配置的软件负载都不可行，通过将硬件负载和软件负载相结合，或者多种软件负载混合使用，可以更好的发挥软件负载灵活的优势，同时也不会因为转发损失影响性能。

附带：

为了投稿这篇文章压了很久，同时和软负载相对应的还有服务隔离机制的文章，后续会发，同时对于软负载的运行期动态配置也做了尝试，在HA上效果不错。当前sip已经采用了软负载+服务隔离的策略，提高平台服务质量。

text-al