当前位置:   article > 正文

Linux下haproxy服务的配置文件haproxy.cfg详解

haproxy.cfg

一、HAProxy的概述:

 

HAProxy是一个使用C语言编写的自由及开放源代码软件,其提供高可用性、负载均衡,以及基于TCP和HTTP的应用程序代理。
HAProxy 特别适用于那些负载特大的web站点,这些站点通常又需要会话保持或七层处理。HAProxy运行在当前的硬件上,完全可以支持数以万计的并发连接。并且 它的运行模式使得它可以很简单安全的整合进您当前的架构中, 同时可以保护你的web服务器不被暴露到网络上。
HAProxy实现了一种事件驱 动, 单一进程模型,此模型支持非常大的并发连接数。多进程或多线程模型受内存限制 、系统调度器限制以及无处不在的锁限制,很少能处理数千并发连接。事件驱动模型因为在有更好的资源和时间管理的用户空间(User-Space) 实现所有这些任务,所以没有这些问题。此模型的弊端是,在多核系统上,这些程序通常扩展性较差。这就是为什么他们必须进行优化以 使每个CPU时间片(Cycle)做更多的工作。

 

二、haproxy.cfg配置文件详解

 

  1. global #全局设置
  2. maxconn 10000 #最大连接数
  3. stats socket /var/run/haproxy.stat mode 600 level admin
  4. log 127.0.0.1 local0 #日志输出配置,所有日志都记录在本机,通过local0输出
  5. uid 200 #所属运行的用户uid
  6. gid 200 #所属运行的用户组
  7. chroot /var/empty
  8. daemon #以后台形式运行haproxy
  • maxconn conns
    设定一个前端的最大并发连接数,因此其不能用于backend区段。对于大型站点来说,可以尽可能提高此值以便 让haproxy管理连接队列,从而避免无法应答用户请求。当然,此最大值不能超出“global”段中的定义。此外,需要留心的是,haproxy会为 每个连接维持两个缓冲,每个缓冲的大小为8KB,再加上其它的数据,每个连接将大约占用17KB的RAM空间。这意味着经过适当优化后,有着1GB的可用 RAM空间时将能维护40000-50000并发连接。
    如果为conns指定了一个过大值,极端场景下,其最终占据的空间可能会超出当前主机的可用内存,这可能会带来意想不到的结果;因此,将其设定了一个可接受值方为明智决定。其默认为2000。

  • log address facility [level [ minlevel ]]
    为每个实例启用事件和流量日志,因此可用于所有区段。每个实例最多可以指定两个log参数,不过,如果使用了“log global”且"global"段已经定了两个log参数时,多余了log参数将被忽略。

  • global:当前实例的日志系统参数同"global"段中的定义时,将使用此格式;每个实例仅能定义一次“log global”语句,且其没有任何额外参数;

  • address:定义日志发往的位置,其格式之一可以为IPv4_address:PORT,其中的port为UDP协议端口,默认为514;格式之二为Unix套接字文件路径,但需要留心chroot应用及用户的读写权限;

  • facility:可以为syslog系统的标准facility之一;

  • level:定义日志级别,即输出信息过滤器,默认为所有信息;指定级别时,所有等于或高于此级别的日志信息将会被发送;

 

  1. defaults #默认设置
  2. mode http #工作模式,支持TCP、http、health
  3. log global #使用global的日志
  4. option httplog #启用HTTP请求,会话状态和计时器的日志记录
  5. option dontlognull #启用空连接不记录日志
  6. monitor-uri /monitoruri
  7. maxconn 8000 #设置最大套接字连接数
  8. timeout client 30s #设置客户端的最长不活动时间
  9. retries 2 #2次连接失败就认为服务器不可用,主要通过后面的check检查
  10. option redispatch #当serverid对应的服务器挂掉后,强制定向到其他健康服务器
  11. timeout connect 5s #设置等待连接尝试到服务器成功的最长时间。
  12. timeout server 30s #设置服务器端的最长不活动时间。
  13. timeout queue 30s #设置队列中等待连接池空闲的最长时间
  14. stats uri /admin/stats #haproxy 监控页面的访问地址
  15. stats auth admin:westos #设置监控页面的用户和密码
  16. stats refresh 5s

 

  • mode { tcp|http|health } 设定实例的运行模式或协议。当实现内容交换时,前端和后端必须工作于同一种模式(一般说来都是HTTP模式),否则将无法启动实例。

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

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

  • health:实例工作于health模式,其对入站请求仅响应“OK”信息并关闭连接,且不会记录任何日志信息;此模式将用于响应外部组件的健康状态检查请求;目前业讲,此模式已经废弃,因为tcp或http模式中的monitor关键字可完成类似功能;

 

  1. frontend public #前台
  2. bind *:80 name clear
  3. default_backend dynamic

 

  • use_backend: 调用指定的后端主机(定义在frontend和listen中);
    语法: use_backend backend [{if | unless} condition]

  • condition 条件多为acl的名称

  • default_backend: 默认调用的后端主机;
    语法:default_backend backend

 

  1. # the application servers go here
  2. backend dynamic #后台
  3. balance roundrobin #负载均衡算法(轮循)
  4. server web2 172.25.83.3:80 check inter 1000
  5. server web2 172.25.83.3:80 check inter 1000
  6. #check inter 1500 是检测心跳频率

 

balance 定义负载均衡算法(可用于“defaults”和“backend”)。

语法:balance algorithm [ arguments ]
algorithm用于在负载均衡场景中挑选一个server,其仅应用于持久信息不可用的条件下或需要将一个连接重新派发至另一个服务器时。
支持的算法有:

  • roundrobin:基于权重进行轮叫,在服务器的处理时间保持均匀分布时,这是最平衡、最公平的算法。此算法是动态的,这表示其权重可以在运行时进行调整,不过,在设计上,每个后端服务器仅能最多接受4128个连接;

  • static-rr:基于权重进行轮叫,与roundrobin类似,但是为静态方法,在运行时调整其服务器权重不会生效;不过,其在后端服务器连接数上没有限制;

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

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

server 定义后端服务器

语法: server name address [param ]

  • name:为此服务器指定的内部名称,其将出现在日志及警告信息中;如果设定了"http-send-server-name",它还将被添加至发往此服务器的请求首部中;

  • address:此服务器的的IPv4地址,也支持使用可解析的主机名,只不过在启动时需要解析主机名至相应的IPv4地
    址;

  • param:为此服务器设定的一系参数;其可用的参数非常多,具体请参考官方文档中的说明,下面仅说明几个常用的参数:

disabled:此服务器禁用;

backup:设定为备用服务器,仅在负载均衡场景中的其它server均不可用才启用此server;

check:启动对此server执行健康状态检查,其可以借助于额外的其它参数完成更精细的设定;

inter delay:设定监控状态检查的时间间隔,单位为毫秒,默认为2000,也可以使用fastinter和downinter来根据服务器端专题优化此事件延迟;

rise count:设定检查状态检查中,某离线的server从离线状态转换至正常状态需要成功检查的次数;

fall count:设定检查状态检查中,某server从正常状态转换至离线状态需要成功检查的次数;

cookie value:为指定server设定cookie值,此处指定的值将在请求入站时被检查,第一次为此值挑选的server将在后续的请求中被选中,其目的在于实现持久连接的功能;

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

maxqueue maxqueue:设定请求队列的最大长度;0表示无上限;

weight weight:权重,默认为1,最大值为256,0表示不参与负载均衡;

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/笔触狂放9/article/detail/303202
推荐阅读
相关标签
  

闽ICP备14008679号