Linux集群之haproxy简介及应用

时间  2020-09-14
标签 linux 集群 haproxy 简介 应用 栏目 Linux 繁體版
原文   原文链接


1、haproyx简介javascript

  HAProxy提供高可用性、负载均衡以及基于TCP和HTTP应用的代理，支持虚拟主机，它是免费、快速而且可靠的一种解决方案。HAProxy特别适用于那些负载特大的web站点，这些站点一般又须要会话保持或七层处理。HAProxy运行在时下的硬件上，彻底能够支持数以万计的并发链接。而且它的运行模式使得它能够很简单安全的整合进您当前的架构中，同时能够保护你的web服务器不被暴露到网络上。php

 

  HAProxy实现了一种事件驱动、单一进程模型，此模型支持很是大的并发链接数。多进程或多线程模型受内存限制、系统调度器限制以及无处不在的锁限制，不多能处理数千并发链接。事件驱动模型由于在有更好的资源和时间管理的用户端(User-Space)实现全部这些任务，因此没有这些问题。此模型的弊端是，在多核系统上，这些程序一般扩展性较差。这就是为何他们必须进行优化以 使每一个CPU时间片(Cycle)作更多的工做。css

 

  HAProxy是免费、极速且可靠的用于为TCP和基于HTTP应用程序提供高可用、负载均衡和代理服务的解决方案，尤为适用于高负载且须要持久链接或7层处理机制的web站点。html

 

2、haproxy工做位置前端

wKiom1V8_HnQ4xBpAANJONWYLCo097.bmp

 

3、haproxy安装及配置文件详解java

3.1 安装haproxynode

  在CentOS 6.6 系统中HAProxy已经被收录在安装树中了，在配置好yum源以后直接使用yum install haproxy就能实现安装。web

yum install haproxy  -yredis

3.2 haproxy配置文件详解算法

  在安装完haproxy程序以后使用rpm-ql haproxy查看安装完所生成的文件，生成的文件比较的少，haproxy的配置文件在/etc/haproxy/haproxy.cfg。

[root@node-04 haproxy]# egrep -v"#|^$" haproxy.cfg 
global      #全局配置
   log         127.0.0.1 local2    #日志文件存放路径，指明为syslog服务器，最多能够定义两个
   chroot      /var/lib/haproxy    #haproxy的工做目录
   pidfile     /var/run/haproxy.pid    #pid文件存放位置
   maxconn     4000                #设定每一个haproxy进程所接受的最大并发链接数，其等同于命令行选项“-n”；“ulimit -n”自动计算的结果正是参照此参数设定的；
   user        haproxy     #指定haproxy身份运行haproxy程序
   group       haproxy     #指定haproxy组身份运行haproxy程序
   daemon          #让haproxy以守护进程的方式工做于后台，其等同于“-D”选项的功能，固然，也能够在命令行中以“-db”选项将其禁用；
   stats socket /var/lib/haproxy/stats #指明haproxy运行时socket文件存放位置
defaults    #提供frontend、backend、listen的公共配置信息段
   mode                    http    #haproxy的工做模式，有tcp和http
   log                     global  #日志文件从global承继
   option                  httplog #启动记录http请求、会话状态和计时器的功能
   option                  dontlognull #不记录空日志
   option http-server-close        #启动和禁用服务器端关闭HTTP链接的功能，服务器链接关闭功能主要是在长链接上使用；
   option forwardfor       except127.0.0.0/8  #容许在发往服务器的请求首部中插入“X-Forwarded-For”首部
   option                  redispatch      #开启或禁用若是某一个链接发生了错误是否是须要重启调度；
   retries                 3       #重次次数
   timeout http-request    10s     #等待客户端发送报文超时时长
   timeout queue           1m      #链接队列等待的超时时长
   timeout connect         10s     #等待上游服务器响应haproxy发送报文过程的超时时间
   timeout client          1m      
   timeout server          1m
   timeout http-keep-alive 10s     #设置保护链接的超时时间
   timeout check           10s     #设置健康状态额外的超时时间
   maxconn                 3000    #设定一个前端的最大并发链接数，所以，其不能用于backend区段。
frontend main *:5000   #用于定义一系列监听的套接字，这些套接字可接受客户端请求并与之创建链接。
   acl url_static       path_beg       -i /static /p_w_picpaths /javascript/stylesheets #定义一个ACL规则
   acl url_static       path_end       -i .jpg .gif .png .css .js
   use_backend static          ifurl_static   #匹配ACL规则的将会使用“static”的后端服务器
   default_backend             app         #在没有匹配的"use_backend"规则时为实例指定使用的默认后端
backend static  #用于定义一系列“后端”服务器，代理将会将对应客户端的请求转发至这些服务器。
   balance     roundrobin      #定义负载均衡调度算法
   server      static 127.0.0.1:4331check #为后端声明一个server，所以，不能用于defaults和frontend区段。“check”表示作健康状态检查
backend app
   balance     roundrobin
   server  app1 127.0.0.1:5001 check
   server  app2 127.0.0.1:5002 check
   server  app3 127.0.0.1:5003 check
   server  app4 127.0.0.1:5004 check


3.3 负载均衡调度算法

类型 说明
roundrobin 基于权重进行轮叫，在服务器的处理时间保持均匀分布时，这是最平衡、最公平的算法。此算法是动态的，这表示其权重能够在运行时进行调整，不过，在设计上，每一个后端服务器仅能最多接受4128个链接；

static-rr

 基于权重进行轮叫，与roundrobin相似，可是为静态方法，在运行时调整其服务器权重不会生效；不过，其在后端服务器链接数上没有限制；

leastconn

 新的链接请求被派发至具备最少链接数目的后端服务器；在有着较长时间会话的场景中推荐使用此算法，如LDAP、SQL等，其并不太适用于较短会话的应用层协议，如HTTP；此算法是动态的，能够在运行时调整其权重；

source

 将请求的源地址进行hash运算，并由后端服务器的权重总数相除后派发至某匹配的服务器；这可使得同一个客户端IP的请求始终被派发至某特定的服务器；不过，当服务器权重总数发生变化时，如某服务器宕机或添加了新的服务器，许多客户端的请求可能会被派发至与此前请求不一样的服务器；经常使用于负载均衡无cookie功能的基于TCP的协议；其默认为静态，不过也可使用hash-type修改此特性；

uri

 对URI的左半部分(“问题”标记以前的部分)或整个URI进行hash运算，并由服务器的总权重相除后派发至某匹配的服务器；这可使得对同一个URI的请求老是被派发至某特定的服务器，除非服务器的权重总数发生了变化；此算法经常使用于代理缓存或反病毒代理以提升缓存的命中率；须要注意的是，此算法仅应用于HTTP后端服务器场景；其默认为静态算法，不过也可使用hash-type修改此特性；

url_param

 经过<argument>为URL指定的参数在每一个HTTP GET请求中将会被检索；若是找到了指定的参数且其经过等于号“=”被赋予了一个值，那么此值将被执行hash运算并被服务器的总权重相除后派发至某匹配的服务器；此算法能够经过追踪请求中的用户标识进而确保同一个用户ID的请求将被送往同一个特定的服务器，除非服务器的总权重发生了变化；若是某请求中没有出现指定的参数或其没有有效值，则使用轮叫算法对相应请求进行调度；此算法默认为静态的，不过其也可使用hash-type修改此特性；
hdr(<name>) 对于每一个HTTP请求，经过<name>指定的HTTP首部将会被检索；若是相应的首部没有出现或其没有有效值，则使用轮叫算法对相应请求进行调度；其有一个可选选项“use_domain_only”，可在指定检索相似Host类的首部时仅计算域名部分(好比经过www.magedu.com来讲，仅计算magedu字符串的hash值)以下降hash算法的运算量；此算法默认为静态的，不过其也可使用hash-type修改此特性；


4、haproxy配置实践之启动haproxy状态统计报告页面

4.1 启动haproxy状态统计报告

  haproxy的状态统计报告的功能很是的强大，能够标记后端服务器不可用，所以应该监听在一个内网地址的特定端口上，在访问此页面时要进行认证，认证成功才能访问。

在haproxy.cfg配置文件中添加以下内容：

listen stats
    mode http
    bind 172.16.9.84:7009
    stats enable
    stats hide-version
    stats uri   /haproxyadmin?stats
    stats realm HAProxy\Statistics
    stats auth  admin:admin
    stats admin if  TRUE


4.2 解释状态统计报告段配置信息

listen stats   

    modehttp

    bind172.16.9.84:7009   #监听在指定的套接字上

    statsenable         #开启状态统计报告

    statshide-version     #隐藏状态统计报告中的haproxy版本信息

    statsuri   /haproxyadmin?stats #指定状态统计报告的访问URI地址

    statsrealm HAProxy\ Statistics #认证时的提示信息，空格要使用“\”进行转意

    statsauth  admin:admin     #认证时的用户名：密码

    statsadmin if  TRUE        #在指定的条件知足时启用统计报告页面的管理级别功能，它容许经过web接口启用或禁用服务器，不过，基于安全的角度考虑，统计报告页面应该尽量为只读的。


4.3 启动haproxy

[root@node-04 ~]# service haproxy start
Starting haproxy:                               [  OK  ]


4.4 检查监听端口

[root@node-04 ~]# ss -tanp|grep 7009
LISTEN    0      128           172.16.9.84:7009             *:*      users:(("haproxy",1465,7))


4.5 访问测试

  在浏览器中输入http://172.16.9.84:7009/haproxyadmin?stats进行访问，在认证成功后的页面以下

wKiom1V8_byDsiXVAAwH4M_jCY8906.bmp

 

5、haproxy配置实践之负载均衡Web服务

  用户请求haproxy反向代理服务器，实现负载均衡的效果，你也能够根据上面的调度算法根据业务的需求进行调整，实验拓扑；

wKioL1V8_4ChWkiKAAML2ON1uYc013.bmp

5.1 haproxy节点的配置内容

[root@node-04 haproxy]# egrep -v"#|^$" haproxy.cfg 
global
   log         127.0.0.1 local2
   chroot      /var/lib/haproxy
   pidfile     /var/run/haproxy.pid
   maxconn     4000
   user        haproxy
   group       haproxy
   daemon
   stats socket /var/lib/haproxy/stats
defaults
   mode                    http
   log                     global
   option                  httplog
   option                 dontlognull
   option http-server-close
   option forwardfor       except127.0.0.0/8
   option                  redispatch
   retries                 3
   timeout http-request    10s
   timeout queue           1m
   timeout connect         10s
   timeout client          1m
   timeout server          1m
   timeout http-keep-alive 10s
   timeout check           10s
   maxconn                 3000
frontend main *:80
   default_backend            websrvs
listen stats
    modehttp
    bind172.16.9.84:7009
    statsenable
    statshide-version
    statsuri   /haproxyadmin?stats
    statsrealm HAProxy\ Statistics
    statsauth  admin:admin
    statsadmin if  TRUE
backend websrvs
   balance     roundrobin
   server  web1 172.16.9.81:8080check 
   server  web2 172.16.9.83:8080check


5.2 各Web节点的测试页面的内容

Web节点监听在8080的端口上，如节点的测试页面以下:

Web-01节点测试页面：

<h1>Real Server node-01</h1>


Web-02节点测试页面：

<h1>Real Server node-02</h1>


5.3 从新加载haproxy的配置信息

service haproxy reload


5.4 访问测试

在浏览器http://172.16.9.84中访问或使用curl命令进行测试，将会出现轮询的效果

[root@node-04 haproxy]# curlhttp://172.16.9.84
<h1>Real Server node-01</h1>
[root@node-04 haproxy]# curlhttp://172.16.9.84
<h1>Real Server node-02</h1>


 

6、haproxy配置实践之基本Cookie绑定会话

  在上面的配置中实现的在访问Web服务器时能轮询的访问后端服务器，但在特定的场景中有时须要将用户的会话保持至同一台后端服务器时，就可使用基本Cookie的会话绑定。

  cookie为当客户端第一次访问服务器时，服务器生成一个随机的cookie，为此用户会话使用，用户浏览器收到cookie信息之后，将会保存在本身浏览器缓存中，然后在向同一个站点请求任何资源时都会附加会话标识信息。

  haproxy的cookie参数，是用于客户端在后端的upstream服务器端之间通讯时，若是upstream 设置了cookie给客户端的话，haproxy是将会修改、添加在原有cookie的基础上附加一些信息上去，以实现基本haproxy来追踪客户端的通讯信息

6.1 修改haproxy.cfg文件中backned段的代码

backend websrvs
   balance     roundrobin
   cookie WEBID insert indirect nocache
   server  web1 172.16.9.81:8080check cookie web1
   server  web2 172.16.9.83:8080check cookie web2


6.2 配置信息解释

cookie WEBID insert indirect nocache

  启用基于cookie后端服务器黏性的功能，insert表示内插方式去将当前haproxy调度出来的WEBID信息插入到客户端的cookie信息中去，并通知不要缓存用户的敏感信息。

  若是用户请求时第一次被调度至web1服务器，web1会回一个cookie信息给客户端，haproxy会把web1这个服务器本身的WEBID附加在cookie上，当客户端第二次请求发出web资源请求时，haproxy经过分析就知道此前就是由web1这台服务器响应的，因此haproxy就把此请求定向至web1。这样haproxy就能追踪此前每个server做出的响应。

6.3 访问测试

  在浏览器中按F12打开开发人员工具，进行查看Cookie的信息，在浏览器输入http://172.16.9.84/，当再次刷新时就被定位至同一台RealServer了，查看Cookie信息中包含了在HAProxy插入的WEBID=XX的HTTP首部请求信息。

Cookie:pma_lang=zh_CN;pma_collation_connection=utf8_general_ci; pma_mcrypt_iv=fmN5yE3kUyc%3D;WEBID=web1


 

7、haproxy配置实践之动静分离

  当客户端请求静态资源时haproxy将轮询的把用户的请求调度至后端服务器，请求的动态资源将调度至Web-02服务器上。

7.1 实验拓扑

wKioL1V8_6SDkHGIAAML2Gk7W6U098.bmp

7.2 haproxy的配置信息

[root@node-04 haproxy]# egrep -v"#|^$" haproxy.cfg 
global
   log         127.0.0.1 local2
   chroot      /var/lib/haproxy
   pidfile     /var/run/haproxy.pid
   maxconn     4000
   user        haproxy
   group       haproxy
   daemon
   stats socket /var/lib/haproxy/stats
defaults
   mode                    http
   log                     global
   option                  httplog
   option                 dontlognull
   option http-server-close
   option forwardfor       except127.0.0.0/8
   option                  redispatch
   retries                 3
   timeout http-request    10s
   timeout queue           1m
   timeout connect         10s
   timeout client          1m
   timeout server          1m
   timeout http-keep-alive 10s
   timeout check           10s
   maxconn                 3000
frontend main *:80
   acl url_dy       path_end       -i .php     #ACL规则，以.php结尾的URL将会被匹配
   use_backend dy          if url_dy       #匹配成功的将会调用“dy”后端服务器组
   default_backend            websrvs
listen stats
    modehttp
    bind172.16.9.84:7009
    statsenable
    statshide-version
    statsuri   /haproxyadmin?stats
    statsrealm HAProxy\ Statistics
    statsauth  admin:admin
    statsadmin if  TRUE
backend dy
   balance     roundrobin
   server      static172.16.9.83:8080 check
backend websrvs
   balance     roundrobin
   server  web1 172.16.9.81:8080check
   server  web2 172.16.9.83:8080check


7.3 后端服务器节点http页面内容

web-01节点的内容

[root@node-01 html]# cat index.htmlindex.php
<h1>Html Static Web-01</h1>
<h1>Real Server node-01</h1>


web-02节点的内容

[root@node-03 html]# cat index.htmlindex.php
<h1>Html Static Web-02</h1>
<h1>Real Server node-02</h1>


7.4 从新加载haproxy配置文件

service haproxy reload


7.5 访问测试

使用curl命令访问测试，静态资源的访问，将会出现轮询的效果：

[root@node-04 ~]# curl http://172.16.9.84/index.html
<h1>Html Static Web-01</h1>
[root@node-04 ~]# curlhttp://172.16.9.84/index.html
<h1>Html Static Web-02</h1>


使用curl命令访问测试，动态资源的访问，将会始终调度至同一台后端服务器的效果：

[root@node-04 ~]# curlhttp://172.16.9.84/index.php
<h1>Real Server node-02</h1>
[root@node-04 ~]# curl http://172.16.9.84/index.php
<h1>Real Server node-02</h1>


 

小结：

  haproxy的功能还远远不至上面列出的这些，更详细的内容请参考官方文档。

  haproxy的链接数是受套接字数量的限制，因此并发数量有限，在haproxy的前端能够加一个LVS，在LVS后一个haproxy的集群，经过LVS调度至不一样的haproxy服务器上，以实现高并发的场景。

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程