vlambda博客
学习文章列表

HAProxy高可用、负载均衡

HAProxy特点和优点:

   1.支持原声SSL,同时支持客户端和服务器的SSL.

   2.支持IPv6和UNIX套字节(sockets)

   3.支持HTTP Keep-Alive

   4.支持HTTP/1.1压缩,节省宽带

   5.支持优化健康检测机制(SSL、scripted TCP、check agent...)

   6.支持7层负载均衡。

   7.可靠性和稳定性非常好。

   8.并发连接40000-50000个,单位时间处理最大请求20000个,最大数据处理10Gbps.

   9.支持8种负载均衡算法,同时支持session保持。

   10.支持虚拟主机。

   11.支持连接拒绝、全透明代理。

   12.拥有服务器状态监控页面。

   13.支持ACL.

四层负载均衡


七层负载均衡

这里仍以常见的 TCP 应用为例,由于负载均衡器要获取到报文的内容,因此只能先代替后端服务器和客户端建立连接,接着,才能收到客户端发送过来的报文内容,然后再根据该报文中特定字段加上负载均衡器中设置的负载均衡算法来决定最终选择的内部服务器。纵观整个过程,七层负载均衡器在这种情况下类似于一个代理服务器

1.haproxy是什么?

haproxy是一个用c语言编写的自由及开源代码软件,其提供web的高可用(我的理解是检测到某个web服务器故障之后就不再向这台服务器申请访问)、负载均衡, 基于TCP(第四层)和HTTP(第七层)应用的代理软件,支持虚拟主机,它是免费、快速并且可靠的一种解决方案。

2.haproxy一般在什么时候会用到?

haproxy技术一般是在哪些负载特别大的网站上使用的,也就是说如果web承受不住大流量访问,就可以在内网多加几台web服务器,然后用haproxy服务器去代理客户端的访问。

3.haproxy能干嘛?有什么作用?

在功能上,proxy通过反向代理方式实现 WEB均衡负载。和 Nginx,ApacheProxy,lighttpd,Cheroke 等一样。 Haproxy 并不是 web 服务器。以上提到所有带反向代理均衡负载的产品,都清一色是 WEB 服务器。简单说,就是他们能处理解析页面的。而Haproxy 仅仅是一款的用于均衡负载的应用代理。其自身并不能提供web服务。但其配置简单,拥有非常不错的服务器健康检查功能还有专门的系统状态监控页面,当其代理的后端服务器出现故障, HAProxy会自动将该服务器摘除,故障恢复后再自动将该服务器加入。

重点!

4、haproxy文件参数讲解:

haproxy的配置文件主要由五个部分组成,分别为[global、defaults、frontend、backend、listen]

global:是全局配置参数段。主要用来控制Haproxy启动前的进程及相关设置

Defaults:配置一些默认参数。如果frontend、backend、listen等段末设置则使用defaults段来配置

listen:主要用来监听和端口转发.[listen可以看成一个虚拟主机或者一个实例]此部分是frontend和backend部分的 结合体

frontend:用来匹配接受客户端所有请求的域名  url等,并针对不同的匹配做不同的请求处理

backend:定义后端服务器集群,以及对后端服务器的一些权重、队列、连接等选项的设置


global全局配置参数讲解:

log

全局的日志配置其中日志级别有err, warning, info, debug 4种

chroot

修改haproxy的工作目录至指定目录并在放弃权限之前执行chroot()操作,可以提升haproxy的安全级别,不过需要注意的是确保指定的目录为空目录且任何用户均不能有写权限;

pidfile

指定haproxy进程ID的存放位置

maxconn

设置每个haproxy进程可接受的最大并发连接数

user/group

设置启动haproxy进程的用户和组

daemon

让haproxy以守护进程的方式工作于后台,其等于“-D”选项的功能,当然也可以在命令行中以"-db"选项将其禁用

stats

用户访问统计数据的接口

扩展参数:

nbproc

设置haproc启动时可创建的进程数,此参数要求将haproxy运行模式设置为daemon,默认的话只启动一个进程;建议该值设置时小于CPU核数

defaults配置参数说明:

HAProxy高可用、负载均衡


mode

设置haproxy实例默认的运行模式,一共有tcp、http、health三个值可选择

tcp模式:在这个模式下客户端和服务器端将建立一个全双工的连接,不会对七层报文协议做任何检查,为默认模式;经常用于SSL、SSH、SMTP等应用

http模式:在这个模式下,客户端请求在装啊至服务器钱将会被深度分析,有所不予RFC格式兼容的请求都会被拒绝

health模式:目前这个模式已经不再应用

log

option  global

option  httplog

在默认情况下,haproxy 日志是不记录 HTTP 请求的,这样很不方便 HAProxy 问题的排查与监控。通过此选项可以启用日志记录 HTTP 请求

option  dontlognull

option  http-server-close

option  forwardfor except 127.0.0.0/8

option  redispatch

retries  3

设置连接后端服务器的失败重试次数,如果重试的次数超过这个值,haproxy将会把这个服务器标记为不可用

timeout  http-request  10s

timeout  queue  1m

timeout  connect  10s

设置连接到一台服务器最长的等待时间,默认是毫秒,也可以使用其他单位作为后缀

timeout  client  1m

设置客户端发送数据最长等待时间,默认单位是毫秒,可以用其他单位来表示

timeout  server  1m

设置服务器回应客户端数据发送的最长等待时间,默认是毫秒,可以使用其他单位来表示

timout  http-keep-alive  10s

timeout  check  10s

设置对后端服务器的检测超时时间,默认是毫秒,可以用其他单位来表示

maxconn   3000

设定一个前端的最大并发连接数,因此,其不能用于backend区段。对于大型站点来说,可以尽可能提高此值以便让haproxy管理连接队列,从而避免无法应答用户请求。当然,此最大值不能超出“global”段中的定义。此外,需要留心的是,haproxy会为每个连接维持两个缓冲,每个缓冲的大小为8KB,再加上其它的数据,每个连接将大约占用17KB的RAM空间。这意味着经过适当优化后,有着1GB的可用RAM空间时将能维护40000-50000并发连接。

如果为<conns>指定了一个过大值,极端场景下,其最终占据的空间可能会超出当前主机的可用内存,这可能会带来意想不到的结果;因此,将其设定了一个可接受值方为明智决定。其默认为2000

default_backend:#指定默认的后端服务器池,也就是指定一组后端真实服务器,而这些真实服务器组将在 backend 段进行定义。这里的htmpool 就是一个后端服务器


frontend配置参数讲解:

通过frontend关键字,定义一个名为"main"的前端虚拟节点

 bind

此选项用于定义一个或者几个监听的套接字,只能在frontend和list中定义。格式如下:

bind [<address>:[port_range]] [interface]

option httplog

默认情况下,haproxy日志是不记录HTTP请求的,此选项是的作用是启用日志记录HTTP请求的

option forwardfor

此选项的作用是保证后端服务器可记录客户端真实的IP

option httpclose

此选项表示客户端和服务端完成一次连接请求后,haproxy将主动关闭此TCP连接。这是对行能非常有帮助的一个参数

log global

表示使用global段中定义日志格式

default_backend htmpool

此选项用于指定后端默认的服务器池




backend配置参数说明:

option redispatch:此参数用于 cookie 保持的环境中。在默认情况下,HAProxy会将其请求的后端服务器的 serverID 插入到 cookie 中,以保证会话的 SESSION 持久性。而如果后端的服务器出现故障,客户端的 cookie 是不会刷新的,这就出现了问题。此时,如果设置此参数,就会将客户的请求强制定向到另外一个健康的后端服务器上,以保证服务的正常。

option abortonclose:如果设置了此参数,可以在服务器负载很高的情况下, 自动结束掉当前队列中处理时间比较长的链接。

balance:此关键字用来定义负载均衡算法。目前 HAProxy 支持多种负载均衡算法,常用的有如下几种:

roundrobin    是基于权重进行轮询调度的算法,在服务器的性能分布比较均匀的时候,这是一种最公平、最合理的算法。此算法经常使用。

static-rr    也是基于权重进行轮询的调度算法,不过此算法为静态方法,在运行时调整其服务器权重不会生效。

source    是基于请求源 IP 的算法。此算法先对请求的源 IP 进行 hash 运算, 然后将结果与后端服务器的权重总数相除后转发至某个匹配的后端服务器。这种方式可以使同一个客户端 IP 的请求始终被转发到某特定的后端服务器。

leastconn    此算法会将新的连接请求转发到具有最少连接数目的后端服务器。在会话时间较长的场景中推荐使用此算法,例如数据库负载均衡等。此算法不  适合会话较短的环境中,例如基于 HTTP 的应用。

uri    此算法会对部分或整个 URI 进行 hash 运算,再经过与服务器的总权重相除,最后转发到某台匹配的后端服务器上。

uri_param    此算法会根据 URL 路径中的参数进行转发,这样可保证在后端真实服务器数量不变时,同一个用户的请求始终分发到同一台机器上。

hdr(<name>):    此算法根据 http 头进行转发,如果指定的 http 头名称不存在,则使用 roundrobin 算法进行策略转发。

cookie:表示允许向 cookie 插入 SERVERID,每台服务器的 SERVERID 可在下面的 server 关键字中使用 cookie 关键字定义。

option httpchk:此选项表示启用 HTTP 的服务状态检测功能。HAProxy 作为一款专业的负载均衡器,它支持对 backend 部分指定的后端服务节点的健康检查,以保证在后端 backend 中某个节点不能服务时,把从 frotend 端进来的客户端请求分配至 backend 中其他健康节点上,从而保证整体服务的可用性。“option httpchk”的用法如下:

option httpchk <method> <uri> <version> 其中,各个参数的含义如下:

method    表示 HTTP 请求的方式,常用的有 OPTIONS、GET、HEAD 几种方式。一般的健康检查可以采用 HEAD 方式进行,而不是才采用 GET 方式,这是因为 HEAD 方式没有数据返回,仅检查 Response 的 HEAD 是不是 200 状态。因此相对与 GET 来说,HEAD 方式更快,更简单。

version    指定心跳检测时的 HTTP 的版本号。

server:这个关键字用来定义多个后端真实服务器,不能用于 defaults 和frontend部分。使用格式为:server <name> <address>[:port] [param*] 其中,每个参数含义如下:

check:表示启用对此后端服务器执行健康状态检查。

inter:设置健康状态检查的时间间隔,单位为毫秒。

rise:设置从故障状态转换至正常状态需要成功检查的次数,例如。“rise 2”表示 2 次检查正确就认为此服务器可用。

fall:设置后端服务器从正常状态转换为不可用状态需要检查的次数,例如,“fall 3”表示 3 次检查失败就认为此服务器不可用。

cookie:为指定的后端服务器设定 cookie 值,此处指定的值将在请求入站时被检查,第一次为此值挑选的后端服务器将在后

<name>    为后端真实服务器指定一个内部名称,随便定义一个即可。

<port>    指定连接请求发往真实服务器时的目标端口。在未设定时,将使用客户端请求时的同一端口。

[param*]    为后端服务器设定的一系参数,可用参数非常多,这里仅介绍常用的一些参数:

check

表示启用对此后端服务器执行健康状态检查。

inter

设置健康状态检查的时间间隔,单位为毫秒。

rise

设置从故障状态转换至正常状态需要成功检查的次数,例如。“rise 2”表示 2 次检查正确就认为此服务器可用。

fall

设置后端服务器从正常状态转换为不可用状态需要检查的次数,例如,“fall 3”表示 3 次检查失败就认为此服务器不可用。

cookie

为指定的后端服务器设定 cookie 值,此处指定的值将在请求入站时被检查,第一次为此值挑选的后端服务器将在后续的请求中一直被选中,其目的在于实现持久连接的功能。上面 的“cookie server1”表示 web1 的 serverid 为 server1。同理, “cookie server2”表示 web2 的 serverid 为 server2。

weight

设置后端真实服务器的权重,默认为 1,最大值为 256。设置为 0 表示不参与负载均衡。

backup

设置后端真实服务器的备份服务器,仅仅在后端所有真实服务器均不可用的情况下才启用

server php_server_1 10.12.25.68:80 cookie 1 check inter 2000 rise 3 fall 3 weight 2

    server php_server_2 10.12.25.72:80 cookie 2 check inter 2000 rise 3 fall 3 weight 1

    server php_server_bak 10.12.25.79:80 cookie 3 check inter 1500 rise 3 fall 3 backup



关于负载均衡算法

  #source    根据请求源IP

  #static-rr   根据权重

  #leastconn    最少连接者先处理

  #uri     根据请求的uri

  #url_param   根据请求的url参数

  #rdp-cookie  据据cookie(name)来锁定并哈希每一次请求

  #hdr(name)  根据HTTP请求头来锁定每一次HTTP请求

  #roundrobin  轮询方式


如果没有haproxy主配置文件可以自己写【配置文件来自于: https://www.cnblogs.com/happy1983/p/9265358.html

[root@xuegod63 ~]# mkdir /usr/local/haproxy/etc

[root@xuegod63 ~]# vim /usr/local/haproxy/etc/haproxy.cfg      #手动创建配置文件

global

log 127.0.0.1  local0

#log 127.0.0.1  local1 notice

#log loghost    local0 info

maxconn 4096

chroot /usr/local/haproxy

uid 99                          #所属运行的用户uid

gid 99                          #所属运行的用户组

daemon                     #以后台形式运行haproxy

nbproc 1                   #启动1个haproxy实例。# #工作进程数量(CPU数量) ,实际工作中,应该设置成和CPU核心数一样。这样可以发挥出最大的性能。

pidfile /usr/local/haproxy/run/haproxy.pid  #将所有进程写入pid文件

#debug      #调试错误时用

#quiet      #安静

defaults

log    global

log    127.0.0.1      local3        #日志文件的输出定向。产生的日志级别为local3. 系统中local1-7,用户自己定义

mode    http           #工作模式,所处理的类别,默认采用http模式,可配置成tcp作4层消息转发

option  httplog                     #日志类别,记载http日志

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

option  dontlognull    #不记录空连接,产生的日志

option  forwardfor     #如果后端服务器需要获得客户端真实ip需要配置的参数,可以从Http Header中获得客户端ip

option  redispatch     #当serverid对应的服务器挂掉后,强制定向到其他健康服务器

retries 2              #2次连接失败就认为服务器不可用,主要通过后面的check检查

maxconn 2000           #最大连接数

balance roundrobin                    #负载均衡算法

timeout connect      5000             #连接超时时间。单位:ms 毫秒

timeout client       50000            #客户端连接超时时间

timeout server      50000             #服务器端连接超时时间

mode    http

option  httpchk GET /index.html       #健康检测#注意实际工作中测试时,应该下载某一个页面来进行测试,因此这个页面应该是个小页面,而不要用首页面。这里是每隔一秒检查一次页面。

 

frontend http          #前端配置,http名称可自定义

bind 0.0.0.0:80        #发起http请求80端口,会被转发到设置的ip及端口

default_backend http_back   #转发到后端 写上后端名称

 

backend http_back    #后端配置,名称上下关联

server  s1 192.168.1.62:80  weight 3 check  #后端的主机 IP &权衡

server  s2 192.168.1.64:80  weight 3 check  #后端的主机 IP &权衡

#server node1 192.168.179.131:8081 check inter 2000 rise 3 fall 3 weight 30

    # inter 2000 健康检查时间间隔2秒

    # rise 3 检测多少次才认为是正常的

    # fall 3 失败多少次才认为是不可用的

# weight 30 权重







haproxy中ACL的使用

定义ACL的语法格式为:

acl <aclname> <criterion> [flags] [operator] <value> ...

<aclname>:ACL名称,区分字符大小写,且其只能包含大小写字母、数字、-(连接线)、_(下划线)、.(点号)和:(冒号);haproxy中,acl可以重名,这可以把多个测试条件定义为一个共同的acl;

<criterion>:测试标准,即对什么信息发起测试;测试方式可以由[flags]指定的标志进行调整;而有些测试标准也可以需要为其在<value>之前指定一个操作符[operator];

[flags]:目前haproxy的acl支持的标志位有3个:

-i:不区分<value>中模式字符的大小写;

-f:从指定的文件中加载模式;

--:标志符的强制结束标记,在模式中的字符串像标记符时使用;

<value>:acl测试条件支持的值有以下四类:

整数或整数范围:如1024:65535表示从1024至65535;仅支持使用正整数(如果出现类似小数的标识,其为通常为版本测试),且支持使用的操作符有5个,分别为eq、ge、gt、le和lt;

字符串:支持使用“-i”以忽略字符大小写,支持使用“\”进行转义;如果在模式首部出现了-i,可以在其之前使用“--”标志位;

正则表达式:其机制类同字符串匹配;

同一个acl中可以指定多个测试条件,这些测试条件需要由逻辑操作符指定其关系。条件间的组合测试关系有三种:“与”(默认即为与操作)、“或”(使用“||”操作符)以及“非”(使用“!”操作符)。