haproxy简述

jonvi

　　haproxy是免费、极速且可靠的用于为TCP和基于HTTP应用程序提供高可用、负载均衡和代理服务的解决方案，尤其适用于高负载且需要持久连接或者7层处理机制的web站点，这些站点通常又需要会话保持或七层处理，HAProxy运行在当前硬件上，完全可以支持数以万讲的并发连接。并且它的运行模式使得它可以很简单安全的整合进行您当前的架构中
　　

　　HAProxy目前主要有两个版本：
　　1.4----提供较好的弹性，衍生于1.2版本，并提供了额外的新特性，其中大多数是期待己久的
　　客户端侧的长连接(client-side keep-alive)
　　TCP加速(TCP speedups)
　　响应池(response buffering)
　　RDP协议
　　基于源的粘性(source-based stickness)
　　可支持基于URI地址将客户端的请求调度到同一个后端服务器，适用于缓存服务器，提高缓存服务器的命中率
　　更好的统计数据接口(a much better stats interfaces)
　　更详细的健康状态检测机制(more verbose health checks)
　　基于流量的健康评估机制(traffic-based health)
　　支持HTTP认证
　　服务器管理命令行接口(server managerment from CLI)
　　基于ACL的持久性连接(ACL-based persistence)
　　日志分析器
　　
　　1.3---------内容交换和超强负载：衍生于1.2版本，并提供了额外的新特征
　　内容交换(content switching)：基于任何请求标准挑选服务器池
　　ACL：编写内容交换规则
　　负载均衡算法(load-balancing algorithms)：更多算法的支持
　　内容探测(content inspection)：阻止非授权协议
　　透明代理(transparent proxy)：在Linux系统上允许使用客户端IP直接连入服务器
　　内核TCP拼接(kernel TCP splicing)：无copy方式在客户端和服务器间转发数据以实现G级别的数据速率
　　分层设计(layered design)：分别实现套接字、TCP、HTTP处理以提供更好的健壮性、更快的处理机制及便捷的演进能力
　　快速、公平调度器(fast and fair scheduler)：为某些任何指定优先级可实现更好的QOS
　　会话速率限制(session rate limiting)：适用于托管环境
　　
　　支持的平台及OS：
　　x86,x86_64,Alpha,SPARC,MIPS及PARISC平台上的linux 2.4
　　x86,x86_64,ARM(ixp245)及PPC64平台上的Linux 2.6
　　UltraSPARC 2和3上的Sloaris 8/9
　　Opteron和UltraSPARC平台上的Sloaris 10；
　　x86平台上的FreeBSD 4.1-8
　　i386,amd64,macppc,alpha,sparc64和VAX平台上的OpenBSD 3.1-current
　　

　　若要获得最高性能，需要在Linux 2.6或打了epoll补丁的Linux 2.4上运行haproxy 1.2.5以上的版本，haproxy 1.1默认使用的polling系统为select()，其处理的文件数达数千 个时性能便会急剧下降。1.2和1.3版本的默认为poll(),在有些操作系统上可能会有性能方面的问题，但在Sloaris上表现相当不错。Haproxy 1.3在Linux 2.6及打了epoll补丁的Linux 2.4上默认使用epoll，在FreeBSD上使用kqueue,这两种机制在任何负载上都能提供恒定的性能表现
　　

　　在较新版本的Linux 2.6(>=2.6.27.19)上，HAProxy还能够使用splice()系统调用在接口间无复制地转发任何数据，这甚至可以达到10Gbps的性能。
　　

　　基于以上事实，在x86或x86_64平台上，要获取最好性能的负载均衡器，建议按顺序考虑以下方案：
　　Linux 2.6.32及之后版本上运行HAProxy 1.4；
　　打了epoll补丁的Linux 2.4运行HAProxy 1.4
　　FreeBSD上运行HAProxy 1.4
　　Sloaris 10上运行HAProxy 1.4
　　

　　性能
　　HAProxy借助于OS上几种常见的技术来实现性能的最大化
　　单进程、事件驱动模型显著降低了上下文切换的开销及内存占用
　　O(1)事件检查器(event checker)允许其在高并发连接中对任何连接的任何事件实现即时探测
　　O(1)：随着队列增长，挑选下一个程序运行的标准规范
　　在任何可用的情况下，单(single buffering)机制能以不复制任何数据的方式完成读写操作，这会节约大量的CPU时钟周期以及内存带宽
　　借助于Linux 2.6上的splice()系统调用 ，HAProxy可以实现零复制转发(zero-copy forwarding)，Linux 3.5及以上的OS中还可以实现零复制启动(zero-starting)
　　MRU内存分配器在固定大小的内存池中可实现即时内存分配，这能够显著减少创建一个会话的时长
　　树型存储：侧重于使用作者多年前开发的弹性二叉树，实现为o(log(N))的低开销来保持计时器命令、保持运行队列命令及管理轮询及最少连接队列
　　优化的HTTP首部分析：优化的首部分析功能避免了在HTTP首部分析过程中重读任何内存区域
　　精心地降低了昂贵的系统调用，大部分工作都在用户空间完成，如时间读取、缓冲聚合及文件描述符的启用和禁用等
　　
　　所有的这些细微之处的优化实现了在中等规模负载之上依然有着相当低的CPU负载，甚至于在非常高的负载场景中，5%的用户空间占用率和95%的系统空间占用率也是非常普遍的现象，这意味着HAProxy进程消耗比系统空间消耗低20倍以上，因此，对OS进行性能调优是非常重要的。即使用户空间的占用率提高一倍，其CPU占用率也仅为10%，这也解释了为何7层处理对性能影响有限这一现象。由此，在高端系统上HAProxy的7层性能可轻易超过硬件负载均衡设备。
　　

　　在生产环境中，在7层处理上使用HAProxy作为昂贵的高端硬件负载均衡设备故障时的紧急解决方案也时长可见。硬件负载均衡设备在"报文"级别处理请求，这在支持跨报文请求(request across multiple packets)有着较高的难度，并且它们不缓冲任何数据，因此有着较长的响应时间。对应地，软件负载均衡设备使用TCP缓冲，可建立极长的请求，且有着较大的响应时间
　　

　　

　　Haproxy:
　　1、具有一定的高可用性能，可以检查后端服务器的健康状况
　　2、可靠的、高性能 的TCP/HTTP的反向代理服务器
　　3、提供功能丰富的GUI界面
　　4、基于事件驱动、单进程响应多个请求
　　

　　可以从三个因素评估负载均衡器的性能：
　　会话率：单位时间内完成的会话数
　　会话并发能力：同时持有的会话数
　　数据率：单位时间内所能进行数据交换的能力
　　
　　haproxy配置文件格式
　　最优先处理的命令行参数
　　"global"配置段，设置全局参数
　　进程定义相关配置
　　优化相关配置
　　"proxy"配置段，如"default" "listen" "frontend" "backend"
　　
　　时间格式：
　　us：微秒
　　ms：毫秒
　　s：秒
　　m：分钟
　　h：小时
　　d：天
　　

　　配置文件例子：
　　global
　　daemon
　　maxconn 25600
　　

　　defaults
　　mode http
　　timeout connect 5000ms
　　time client 5000ms
　　time server 5000ms
　　

　　frontend http-in
　　bind *:80
　　default_backend servers
　　

　　backend servers
　　server server1 127.0.0.1:8000 maxconn 32
　　

　　

　　全局配置项
　　

　　进程管理及安全相关的参数
　　chroot ：修改haproxy的工作目录到指定的目录并在放弃权限前执行chroot()操作,可以提升haproxy的安全级别，注意要确保指定的目录为空目录且任何用户都不能有写权限
　　daemon：让haproxy以守护进程的方式工作于后台,也可以在命令行中以"--db"选项将其禁用
　　gid ：指定运行haproxy的GID,建议使用专用于运行haproxy的GID，以免因权限问题带来风险
　　group ：同gid，只不过用的是组名
　　log   [max level [min level]]：定义全局的syslog服务器，最多可以定义两个
　　log-send-hostname []：在syslog信息的首部添加当前主机名,可以为"string"指定的名称，也可以缺少使用当前主机名
　　nbproc ：指定启动的harpoxy进程个数，只能用于守护进程模式的haproxy；默认只启动一个进程，鉴于调试困难等多方面原因,一般只在单进程仅能打开少数据文件描述符的场景中才使用多进程模式
　　pidfile:
　　uid：以指定的UID身份运行haproxy进程
　　user：同uid，只不过使用的是用户名
　　ulimit-n：设置每进程所能够打开的最大文件描述符数目，默认情况下其会自动计算，因此不推荐修改此选项
　　stats：
　　node：定义当前节点的名称，用于HA场景中多haproxy进程共享同一个IP地址时
　　description：当前实例的描述信息
　　

　　性能调整相关的参数：
　　maxconn ：设定每个haproxy进程所接受的最大并发连接数，其等同于命令行选项"-n"；"ulimit -n"自动计算的结果正是参照此参数设定的
　　maxpipes ：haproxy使用pipe完成基于内核的tcp报文重组，此选项用于设定每进程所允许使用的最大pipe个数；每个pipe会打开两个文件描述符，因此，"ulimit -n"自动计算时会根据需要调大此值,默认为maxconn/4，其通常会显得过大
　　noepoll：在Linux系统上禁用epoll机制
　　nokqueue：在BSE系统上禁用kqueue机制
　　nopoll：禁用poll机制
　　nosepoll：在Linux禁用启发式epoll机制
　　nosplice：禁止在Linux套接字上使用内核tcp重组,这会导致更多的recv/send系统调用；不过在Linux 2.6.25--28系列的内核上，tcp重组功能有bug存在
　　spread-check
　　在haproxy后端有着众多服务器的场景中，在精确的时间间隔后统一对众多服务器进行健康状况检查可能会带来意外问题; 此选项用于将其检查的时间间隔长度上增加或者减少一定的随机时长；
　　tune.chksize : 设定检查缓冲区的大小 ,单位为字节；更大的值有助于在较大的页面中完成基于字符串或者模式的文本查找,但也会占用更多的系统资源；不建议修改
　　tune.maxaccept :
　　设定haproxy进程内核调度运行时一次性可以接受的连接的个数；较大的值可以带来较大的吞吐率,默认在单进程模式下为100，多进程模式下为8；设置为-1可以禁止此限制；一般不建议修改
　　tune.maxpollevents :
　　设定一次系统调用可以处理的事件最大数，默认值取决于OS；其值小于200时可节约带宽，但会略微增大网络延迟，而大于200时会降低延迟，但会稍微增加网络带宽的占用量
　　tune.maxrewrite :
　　设定为首部重写或追加而预留的缓冲空间，建议使用1024左右的大小; 在需要使用更大的空间时，haproxy会自动增加其值；
　　tune.rcvbuf.client
　　tune.rcvbuf.server :
　　设定内核套接字中服务器端或者客户端接收缓冲的大小 ，单位为字节；强烈推荐使用默认值
　　tune.sndbuf.client
　　tune.sndbuf.server
　　

　　

　　Debug相关参数：
　　debug
　　quiet
　　
　　

　　代理段配置项：
　　defaults
　　frontend
　　backend  
　　listen   
　　
　　"defaults"段用于为所有其它配置段提供默认参数，这配置默认配置参数可由下一个"defaults"重新设定
　　

　　"frontend"段用于定义一系列监听的套接字，这些套接字可接受客户端请求并与之建立连接
　　

　　"backend"段用于定义一系列"后端"服务器，代理将会将对应客户端的请求转发到这些服务器
　　

　　"listen"段通过关联"前端"和"后端"定义了一个完整的代理，通常只对TCP流量有用
　　

　　所有代理的名称只能使用大小写字母、数字，-，_，.和:冒号。此外，ACL名称会区分大小写
　　
　　配置文件中的关键字参考
　　

　　1、balance
　　
　　balance  [  ]
　　balance url_param  [ check_post [  ]]
　　
　　定义负载均衡算法，可用于"defaults","listen","backend"
　　用于在负载均衡场景中挑选一个server,其仅应用于持久信息不可用的条件下或需要一个连接重新派发到另一个服务器时。支持的算法有：
　　

　　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：通过为URL指定的参数在每个HTTP GET请求中将会被检索；如果找到了指定参数且其通过等于号"="被赋予了一个值，那么此值将被执行hash运算并被服务器的总权重相除后派发至某匹配的服务器；此算法可以通过追踪请求中的用户标识进而确保同一个用户ID的请求将被送往同一个特定的服务器，除非服务器的总权重发生了变化，如果某请求中没有出现指定的参数或其没有有效值，则使用轮叫算法对相应请求进行调度；此算法默认为静态，不过其也可以使用hash-type进行调整
　　hdr()：对于每个HTTP请求，通过指定的HTTP首部会被检索；如果相应的首部没有出现或其没有有效值，则使用轮叫算法对相应请求进行调度；其有一个可选选项"use_domain_only"，可在指定检索类似Host类的首部时仅计算域名部分以降低hash算法的运算量；此算法默认为静态的，不过也可以通过hash-type进行调整
　　rdp-cookie
　　rdp-cookie(name)
　　
　　2、bind
　　
　　bind []: [,...]
　　bind []: [,...] interface
　　
　　此指令仅能用于frontend和listen区段，用于定义一个或几个监听的套接字
　　

　　：可选选项，其可以为主机名，IPV4、IPV6地址；省略此选项，将其指定为*或者0.0.0.0时，将监听当前系统的所有IPV4地址
　　：可以是一个特定的TCP端口，也可是一个端口范围(5000-10240)，代理服务器将通过指定的端口来接收客户端请求；需要注意的是，每组监听的套接字在同一个实例上只能使用一次，而且小于1024的端口需要有特定权限的用户才能使用，这可能需要通过uid参数来定义
　　：指定物理接口的名称，仅能在Linux系统上使用；其不能使用接口别名，而仅能使用物理接口名称，而且只有管理员有权限绑定的物理接口；
　　

　　3、mode
　　
　　mode { tcp | http | health }
　　
　　设定实例的运行模式或协议，当实现内容交换时，前端和后端必须工作于同一个模式(一般来说都是HTTP模式)，否则将无法启动实例
　　
　　tcp：实例运行于纯TCP模式，在客户端和服务器端间将建立一个全双工的连接，且不会对7层报文做任何类型的检查；此为默认模式，通常用于SSL, SSH,SMTP等应用
　　http：实例运行于HTTP模式，客户端请求在转发到后端服务器之前将被深度分析，所有不与RFC格式兼容的请求都会被拒绝
　　health：实例运行于health模式，其对入站请求仅响应"OK"信息并关闭连接，且不会记录任何日志信息；此模式将用于响应外部组件的健康状态检查请求；目前来讲，此模式已经废弃，因为tcp或者http模式中的monitor关键字可完成类似功能
　　
　　4、hash-type
　　

　　hash-type
　　
　　定义用于将hash码映射至后端服务器的方法；其不能用于frontend段；可用方法有map-based和consistent，在大多数场景下推荐使用默认的map-based方法
　　map-based：hash表是一个包含了所有在线服务器的静态数组。其hash值将会非常平滑，会将权重考虑在列，但其为静态方法，对在线服务器的权重进行调整将不会生效，这意味着其不支持慢速启动。此外，挑选服务器是根据其在数组中的位置进行的，因此，当一台服务器宕机或添加了一台新的服务器时，大多数连接将会被重新派发至一个与此前不同的服务器上，对于缓存服务器的工作场景来说，此方法不甚适用。
　　consistent：hash表是一个由各服务器填充而成的树状结构；基于hash键在hash树中查找相应的服务器时，最近的服务器将被选中。此方法是动态的，支持在运行时修改服务器权重，因此兼容慢速启动的特性。添加一个新的服务器时，仅会对一小部分请求产生影响，因此，尤其适用于后端服务器为cache的场景。不过，此算法不甚平滑，派发至各服务器的请求未必能达到理想的均衡效果，因此，可能需要不时的调整服务器的权重以获得更好的均衡性。
　　
　　5、log
　　

　　log global
　　log   [ ]
　　
　　为每个实例启用事件和流量日志，因此可用于所有区段。每个实例最多可以指定两个log参数，不过，如果使用了"log global"且"global"段已经定了两个log参数时，多余的log参数将被忽略。
　　
　　global：当前实例的日志系统参数同"global"段中的定义时，将使用此格式；每个实例仅能定义一次"log global"语句，且其没有任何额外参数
　　：定义日志发往的位置，其格式之一可以为