HAProxy使用详解

HAProxy使用详解

HAProxy详解

HAProxy是免费、极速且可靠的用于为TCP和基于HTTP应用程序提供高可用、负载均衡和代理服务的解决方案，尤其适用于高负载且需要持久连接或7层处理机制的web站点。HAProxy还可以将后端的服务器与网络隔离，起到保护后端服务器的作用。HAProxy的负载均衡能力虽不如LVS，但也是相当不错，而且由于其工作在7层，可以对http请求报文做深入分析，按照自己的需要将报文转发至后端不同的服务器（例如动静分离），这一点工作在4层的LVS无法完成。

安装配置HAproxy

HAProxy已经集成在base源中，可直接通过yum下载。

[root@node1 ~]# yum install haproxy

当然也可以去官网直接下载源码编译安装。

/etc/haproxy/haproxy.cfg为haproxy的主配置文件，里面包括全局配置段（global settings）和代理配置段（proxies）。

global settings：主要用于定义haproxy进程管理安全及性能相关的参数

proxies：代理相关的配置可以有如下几个配置端组成。

 - defaults <name>：为其它配置段提供默认参数，默认配置参数可由下一个“defaults”重新设定。

 - frontend <name>：定义一系列监听的套接字，这些套接字可接受客户端请求并与之建立连接。

 - backend  <name>：定义“后端”服务器，前端代理服务器将会把客户端的请求调度至这些服务器。

 - listen  <name>：定义监听的套接字和后端的服务器。类似于将frontend和backend段放在一起

HAproxy的工作模式：

HAProxy的工作模式一般有两种：tcp模式和http模式。

tcp模式：实例运行于TCP模式，在客户端和服务器端之间将建立一个全双工的连接，且不会对7层报文做任何类型的检查，只能以简单模式工作。此为默认模式，通常用于SSL、SSH、SMTP等应用。

http模式：实例运行于HTTP模式，客户端请求在转发至后端服务器之前将被深度分析，所有不与RFC格式兼容的请求都会被拒绝。

当实现内容交换时，前端和后端必须工作于同一种模式(一般都是HTTP模式)，否则将无法启动实例。工作模式可通过mode参数在default，frontend，listen，backend中实现定义。

mode {tcp|http}

--------------------------------------分割线 --------------------------------------

Haproxy+Keepalived搭建Weblogic高可用负载均衡集群

Keepalived+HAProxy配置高可用负载均衡

CentOS 6.3下Haproxy+Keepalived+Apache配置笔记

Haproxy + KeepAlived 实现WEB群集 on CentOS 6

Haproxy+Keepalived构建高可用负载均衡

使用 HAProxy 配置 HTTP 负载均衡器

--------------------------------------分割线 --------------------------------------

下面介绍一些HAproxy的常见用法。

应用实例

基于HAProxy实现负载均衡

在backend段或listen段中通过server定义后端节点。

格式：server <name> <address>[:port] [param*]

<name>：为此服务器指定的内部名称

[param*]：为此服务器设定的一系参数。其可用的参数很多，以下为常用参数。

服务器参数：

backup：设定为备用服务器，仅在负载均衡场景中的其它server均不可用于启用此server；

maxconn <maxconn>：指定此服务器接受的最大并发连接数；如果发往此服务器的连接数目高于此处指定的值，其将被放置于请求队列，以等待其它连接被释放；

maxqueue <maxqueue>：设定请求队列的最大长度；

observe <mode>：通过观察服务器的通信状况来判定其健康状态，默认为禁用，其支持的类型有“layer4”和“layer7”，“layer7”仅能用于http代理场景；

redir <prefix>：启用重定向功能，将发往此服务器的GET和HEAD请求均以302状态码响应；

weight <weight>：服务器权重，默认为1，最大值为256，0表示不参与负载均衡；

定义负载均衡的算法，算法的定义除了listen段和backend段中也可以放在defaults段中，定义格式如下：

balance <algorithm> [ <arguments> ]

balance url_param <param> [check_post [<max_wait>]]

常见的调度算法有：

roundrobin：基于权重进行轮询，此算法是动态的，其权重可以在运行时进行调整。

static-rr：基于权重进行轮询，与roundrobin类似，但是为静态方法，在运行时调整其服务器权重不会生效。

leastconn：新的连接请求被派发至具有最少连接数目的后端服务器，动态算法，适用于较长时间会话的场景。

source：将请求的源地址进行hash运算，并与后端服务器的总权重作取模运算后调度至某台服务器；同一IP地址的请求将始终被调度至某特定的服务器，静态算法，可以使用hash-type修改此特性；

uri：对URI的左半部分(“？”之前的部分)或整个URI进行hash运算，并与后端服务器的总权重作取模运算后调度至某台服务器；同一URI的请求将始终被调度至某特定的服务器，静态算法，可以使用hash-type修改此特性；

hdr(<name>)：根据用户请求报文中指定的http首部的值进行调度，常用于实现将对同一个虚拟主机的请求始终发往同个backend server。

前端代理服务器上配置示例（其余为默认配置）：

#---------------------------------------------------------------------

# main frontend which proxys to the backends

#---------------------------------------------------------------------

frontend  service *:80

default_backend            app

#---------------------------------------------------------------------

# static backend for serving up images, stylesheets and such

#---------------------------------------------------------------------

backend app

    balance    roundrobin

    server      app1 192.168.2.7:80 maxconn 3000 weight 2

    server      app2 192.168.2.18:80 maxconn 3000 weight 1

    server      app3 127.0.0.1:8080 backup

在app1（192.168.2.7）上配置测试页面：

[root@node1 ~]# vim /web/index.html

<h2>server node1</h2>

在app1（192.168.2.18）上：

[root@node2 ~]# vim /web/index.html

<h2>server node2</h2>

在代理服务器上有两个接口：192.168.1.116（面向客户端），192.168.2.11。配置完成后启动haproxy服务。后端节点上启动nginx服务。

已实现轮询访问。

在上述的算法中涉及到hash运算，hash-type参数可定义hash的运算方式。格式如下：

格式：hash-type <map-based|consistent>

map-based：静态方法，在线调整服务器权重不能立即生效。hash表是一个包含了所有在线服务器的静态数组。简而言之，通过这种运算方式将请求调度至后端的某台服务器，当后端的服务器放生变动时（如某台服务器宕机或新添加了一台服务器），大部分的连接将会被重新调度至一个与之前不同的服务器上。

consistent：动态发放，支持在线调整服务器权重。hash表是一个由各服务器填充而成的树状结构，使用此算法调度，当后端的服务器发生变动时，大分布的连接将依旧被调度至原本的服务器上。

默认方式为map-based，可应用于大部分场景。但是若后端的服务器为缓存服务器，使用默认方式，当后端的服务器调整时，将导致缓存无法命中，从而影响系统的性能。推荐的配置方式：

backend <name>

    balance    uri

    hash-type consistent

    server      ....

    server      ...

对后端服务器健康状况的检测

check为server的参数，可启动对此server执行健康状态的检测。check借助其额外的参数可实现更精细的监测机制。

inter <delay>：健康状态检测的时间间隔，单位为毫秒，默认为2000，可以使用fastinter和downinter来根据服务器端状态优化此时间延迟；

rise <count>：健康状态检测中，某离线的server从离线状态转换至正常状态需要成功检查的次数；

fall <count>：确认server从正常状态转换为不可用状态需要检查的次数；

配置示例：

backend app

    balance    roundrobin

    server      app1 192.168.2.7:80 maxconn 3000 weight 2 check inter 1 rise 1 fall 2

    server      app2 192.168.2.18:80 maxconn 3000 weight 1 check inter 1 rise 1 fall 2

    server      app3 127.0.0.1:8080 backup

state页面

启用统计报告，通过state页面可查看到各服务器的状态及其相关信息。关于state的配置建议单独定义一个listen。

listen stats

    mode http                                 

    bind 192.168.1.116:1080              #监听端口 

    stats enable                        #启用state功能

    stats scope app                      #统计报告的报告区段，不启动这项则报告所有区段

    stats hide-version                  #隐藏HAProxy版本号

    stats uri /haproxyadmin?stats        #state页面的访问路径

    stats realm Haproxy\ Statistics      #认证时提示信息

    stats auth baby:baby                #认证的账号密码

    stats admin if TRUE                  #启用管理功能

配置完成后重启haproxy服务。然后访问定义的路径：http://192.168.1.116:1080/haproxyadmin?stats。首先完成认证。

基于前面配置完成的健康状态检测，现在停止其中一台后端服务器的nginx服务。

[root@node1 web]# service nginx stop

Stopping nginx:                                            [  OK  ]

红色表示服务不在线，若停止所有后端服务器的服务，则会访问定义为backup的server（127.0.0.1上的sorry页面）。

更多详情见请继续阅读下一页的精彩内容：

1 2 下一页