跳转至

Haproxy

Intro

介绍负载平衡的基础知识,HAProxy作为一种产品,用来做什么,不用来做什么,一些已知的陷阱避免,一些特定于操作系统的限制,获取、发展及更新它,如何确保您运行所有已知的修补程序,关于它的补充和替代品

HAProxy是:

  • TCP代理:它可以接受来自侦听套接字的TCP连接,连接到服务器并将这些插座连接在一起,允许流量两个方向流动;
  • HTTP反向代理(在HTTP术语中称为“网关”):它本身作为服务器,通过接受的连接接收HTTP请求侦听TCP套接字,并将来自这些连接的请求传递给使用不同连接的服务器
  • SSL终结器/启动器/卸载器:来自客户端的连接可以使用SSL/TLS,连接到服务器,甚至双向连接
  • TCP规范化器:由于操作在本地终止连接系统,双方没有关系,所以交通不正常等无效数据包,标志组合,窗口广告,序列号,不完整的连接(SYN floods),或者不会传递给另一个侧。这可以保护脆弱的TCP堆栈免受协议攻击允许与客户端优化连接参数而无需修改服务器的TCP堆栈设置
  • HTTP规范化程序:配置为处理HTTP流量时,仅有效完成请求已通过。这可以防止许多基于协议的攻击。另外,存在容差的协议偏差在规范中是固定的,这样它们就不会引起问题服务器(例如多行标题)
  • HTTP修复工具:它可以修改/修复/添加/删除/重写URL或任何请求或响应标头。这有助于解决互操作性问题在复杂的环境中
  • 基于内容的交换机:它可以考虑请求中的任何元素决定将请求或连接传递给哪个服务器。因此有可能通过同一端口处理多个协议(例如HTTP,HTTPS,SSH)
  • 服务器负载均衡器:它可以平衡TCP连接和HTTP要求。在TCP模式下,整体采用负载平衡决策连接。在HTTP模式下,根据请求做出决定
  • 交通监管机构:它可以在不同的点应用一些速率限制,保护服务器免受过载,根据需要调整流量优先级内容,甚至将这些信息传递给下层和外层网络组件通过标记数据包
  • 针对DDoS和服务滥用的保护:它可以保持广泛的数量每个IP地址,URL,cookie等的统计信息,并检测何时滥用发生,然后采取行动(减慢违法者,阻止他们,发送他们过时的内容等)
  • 网络故障排除的观察点:由于精度在日志中报告的信息,通常用于缩小一些与网络有关的问题
  • HTTP压缩卸载程序:它可以压缩不是由服务器压缩的响应,从而减少客户端的页面加载时间连接不良或使用高延迟的移动网络

HAProxy不是:

  • 一个显式的HTTP代理,即浏览器用来访问的代理互联网。有专门用于此任务的优秀开源软件,比如Squid。但是HAProxy可以安装在这样的代理前面提供负载平衡和高可用性
  • 缓存代理:它将按原样返回从服务器收到的内容并且不会干扰任何缓存策略。有优秀用于此任务的开源软件,如Varnish。可以安装HAProxy在这样的缓存前面提供SSL卸载,并通过可伸缩性智能负载平衡
  • 数据清理器:它不会修改请求体和响应体
  • 一个Web服务器:在启动期间,它将自己隔离在一个chroot jail和删除其权限,以便它不会执行任何单个文件系统访问一旦开始。因此,它无法转变为Web服务器。那里是非常好的开源软件,如Apache或Nginx,以及HAProxy可以安装在它们前面,以提供负载平衡和高可用性
  • 基于数据包的负载均衡器:它不会看到IP数据包,也不会看到UDP数据报,不会执行NAT甚至更少的DSR。这些是较低层的任务。一些基于内核的组件,如IPVS(Linux虚拟服务器)已经做到了非常好,与HAProxy完美搭配

HAProxy是一个单线程,事件驱动,非阻塞引擎。可以使HAProxy在多个进程上运行,但它随之而来 一些限制。通常,它在HTTP关闭或TCP模式下没有意义,因为内核端不能很好地扩展某些操作,例如connect(),它可以很好地扩展HTTP保持活动模式但性能可以通过单一流程实现的工作通常优于常见需求一个数量级。但是,当用作SSL时,它确实有意义offloader,在多进程模式下很好地支持此功能

基本功能:代理

  • 为服务器提供干净的连接,防止客户端连接缺陷和攻击
  • 监听多个IP地址或端口,甚至端口范围
  • Transparent accept:拦截任意IP地址流量,尽管不属于本地系统
  • 服务器端口不需要和侦听端口相关,甚至是由固定偏移量转换(对范围有用)
  • 为多站点LB中的服务器提供可靠的返回IP地址
  • 由于缓冲区和可能的短暂连接,下线服务器来减少并发连接数和内存占用量
  • 优化TCP堆栈(如:SACK)拥塞控制和减少RTT影响
  • 支持双方不同的协议系列(IPv4,IPv6,Unix)
  • 强制超时:在连接的不同阶段支持多级别的超时连接,以便于已死亡的客户端、服务器或攻击者占用资源时间太长
  • 协议验证:检查HTTP、SSL、Playload并拒绝无效协议成分,除非指定accept他们
  • 强制策略:确保只转发允许的内容
  • 传入和传出连接都可能限于某些网络名称空间(仅限Linux),可以轻松构建跨容器,多租户负载均衡器;
  • Proxy协议将客户端IP地址呈现给服务器尽管非HTTP流量,这是haproxy扩展,目前第三方产品有:
  • client : haproxy, hitch, stunnel, exaproxy, ELB, squid
  • server : haproxy, hitch, postfix, exim, nginx, squid, node.js, varnish

基本功能:SSL

  • 基于SNI的专注于性能没有站点限制的多主机
  • 支持用正则通配符匹配证书
  • 具有可配置策略的基于证书的客户端身份验证未能出示有效证书,将允许不同的服务器重新生成客户端证书
  • 后端服务器身份验证确保后端服务器不是中间人
  • 使用后端服务器进行身份验证可以让后端服务器知道它连接的是预期的haproxy节点
  • TLS NPN和ALPN扩展可以可靠的卸载SPDY/HTTP2连接并以明文形式传递给后端服务器
  • 当客户端发送以证书验证的请求时,OCSP装订通过内联来进一步减少首页加载时间
  • 动态记录大小调整提供高性能低延迟及通过让浏览器获取新object来显著减少页面加载
  • 永久访问所有相关的SSL/TLS层信息以进行日志记录、访问控制、报告等。这些元素可以嵌入到HTTP Header甚至作为Proxy协议扩展
  • 即使在易受攻击的SSL库中也能检测,记录和阻止某些已知攻击,例如影响OpenSSL某些版本的Heartbleed攻击
  • 支持无状态会话恢复,可以从CLI更新TLS凭证

基本功能:监控

  • 利用per-server参数持续监控服务器状态,这个确保服务器的路径是正常流量
  • 状态检查支持up或down滞后按顺序切换,防止状态错乱
  • 可以将检查发送到不同的地址/端口/协议:这样很容易被认为代表多个的单个服务,如:HTTP+HTTPS服务器的HTTPS端口
  • 服务器可以跟踪其他服务器并同时关闭,可以确保托管多个服务的服务器以原子方式失败而没有一个会发送到失败的服务器
  • 可以在服务器部署代理来监控负载和运行状态
  • 提供各种检查方法:TCP连接、HTTP请求、SMTP问候、SSL hello,LDAP、SQL、Redis、send/expect脚本,全部带或不带ssl连接
  • 状态更改将在日志和统计信息页面通知失败原因,也可发送到配置的电子邮件地址
  • 服务器状态也会在统计信息界面显示,并可用于执行路由决策,以便于将流量发送到不同的farms
  • haproxy可以使用运行状况检查请求将信息传递给服务器,例如服务器name、weight、其他服务器在farm的number(数量)等。所以服务器可以根据这些来调整响应和决策(例如推迟备份保持更多的可用CPU)
  • 服务器可以用健康检查报告更详细的状态,不仅仅是on或off
  • 服务器自身可以报告状态给其他组件,如路由器或其他负载均衡器,允许构建非常完整的多路径和多层基础设施

基本功能:高可用

  • 仅使用有效的服务器,其他自动驱逐出负载均衡农场
  • 支持正常关闭,以便于不影响有任何关系的农场
  • 当活动服务器关闭时,将自动使用备份服务器,便于在可能的情况下不丢失会话,这也允许构建多条路径到达同一个服务器(例如多个接口)
  • 当一个农场服务器太多时,能返回服务器失败状态,这和监控功能结合使用,让其为上游组件选择给定服务的不同LB节点
  • 无状态设计使构建集群变得容易,haproxy可以最好的确保服务连续性而无需存储在发生故障时可能丢失的信息
  • 与标准的VRRP守护进程良好的集成,haproxy可以轻松的对状态连接保持并于浮动虚拟IP很好的对应

基本功能:负载均衡

  • 支持不少于9钟负载均衡算法,其中一些适用于输入数据以提供无限的可能性列表。最普遍的是
  • round-robin (对于短连接,依次选择每个服务器)
  • leastconn (对于长连接选择最近很少使用、最低连接数的服务器)
  • source (用于SSL farms或终端服务器farms)服务器直接依赖于客户端源地址
  • URI (用于HTTP缓存,服务器直接依赖于HTTP URI)
  • HDR (服务器依赖于特定的HTTP hearder字段的内容)
  • 以上算法都支持per-server权重,以便适应农场中不同服务器,或者作用于流量比较小的特定服务器(debug,在下一个软件版本)
  • 动态权重支持round-robin leastconn 一致性hashing,这允许从CLI动态修改服务器权重甚至是服务器上运行的代理
  • 只要支持动态权重,就支持慢启动,这允许服务器逐步获取流量,这是个重要特征,对于需要在运行时编译类的脆弱应用程序服务器以及需要在完全运行之前填满冷缓存
  • hashing(散列)可以用于各种元素,如客户端源地址,URL组件,查询字符串元素,header字符串值,POST参数,RDP cookie
  • 一致性散列可以保护服务器farm免受大量重新分发的影响,在服务器farm钟添加或删除服务器,这在大型缓存farm中非常重要,它允许慢启动用于补充cold caches
  • 许多内部指标,如每台服务器连接数、每个后端可用连接插槽的数量,可以构建非常先进的负载平衡策略

基本特征:粘性(Stickiness)

haproxy提供相当全面的可能性保持访客访问相同服务器甚至跨越各种事件,如服务器添加/删除,down/up循环,并设计方法抵抗之间的距离多个负载均衡节点,因为它们并不需要任何复制

  • 粘性信息可以单独匹配和学习不同的地方,如:可以匹配JSESSIONID cookie 在cookie和URL都有,最多同一时间可学习8个并行源,每个可能指向不同的stick-table
  • 以多主方式在所有节点复制stick-tables
  • 常用的元素,如SSL-ID或RDP cookie(用于TSE farm)直接易于操作
  • 所有sticking rules可由ACL动态调节
  • 可以决定不stick某些服务器,例如备份服务器,以便于当规定的服务器返回时,可以自动进行load back,通常用于多路径环境

Configuration

详细介绍了所有配置关键字和他们的选择。它在需要更改配置时使用

关于HTTP的快速提醒

当HAproxy在HTTP模式下运行时,请求和相应都是完全分析和索引,因此几乎在contents的任何内容都可以建立匹配。了解http请求和响应的形成的方式非常重要,及haproxy如何分解它们,然后就会变得更容易编写正确的规则和调试现有配置

http事务模型:http协议是事务驱动的,意味着每个请求都领先一个回应

HAProxy支持5种连接模式:

  • 保持活跃:处理所有请求和响应(默认)
  • 隧道:只处理第一个请求和响应,其他一切都没有分析转发
  • 被动关闭:在两个方向上添加“连接:关闭”的隧道
  • 服务器关闭:响应后关闭面向服务器的连接
  • 强制关闭:响应结束后,主动关闭连接

对于HTTP/2,连接模式类似于“服务器关闭”模式:给定所有流的独立性,目前没有地方可以挂空闲响应后的服务器连接,因此在响应后关闭。HTTP/2仅支持传入连接,而不支持连接服务器

Text Only
HAProxy的配置过程涉及3个主要参数来源
1.来自命令行的参数,它始终优先
2.“全局”部分,用于设置流程范围的参数
3.代理部分可以采取“默认”,“听”的形式,“前端”和“后端”

配置文件支持3钟类型:转义反斜杠、双引号弱引用、单引号强引用
如果必须在字符串输入空格,则必须通过反斜杠进行转义

\标记空格并将其与分隔符区分开来
\#标记哈希并将其与注释区分开来
\\使用反斜杠
''使用单引号并将其与强引用区分开来
""使用双引号并将其与弱引用区分开来

Management

如何启动haproxy,如何运行时管理它,如何在多个节点上管理它,以及如何无缝升级

Text Only

Architecture

如何构建一个最好的负载均衡基础架构以及如何与第三方产品进行集成

Text Only

是用于在执行加载时选择服务器的算法 平衡。仅在没有持久性信息时适用 可用,或将连接重新分配给另一个连接时 服务器。可能是以下之一:

roundrobin每个服务器根据其权重依次使用。 当服务器的 处理时间保持平均分配。这个算法 是动态的,这意味着可以调整服务器权重 例如,慢速启动。受限于 每个后端最多可设计4095个活动服务器。请注意,在某些情况下 大型服务器场,当服务器关闭后又启动时 在很短的时间内,有时可能需要数百 要求将其重新集成到服务器场中并开始 接收流量。这很正常,尽管非常罕见。这是 如果您有机会观察到,请在此处指示 它,这样您就不必担心。

static-rr每个服务器根据其权重依次使用。 该算法与轮询算法相似,除了它是 静态,这意味着更改服务器在服务器上的权重 飞不会有任何效果。另一方面,它没有设计 服务器数量的限制,以及服务器何时运行 起来,一旦被立即重新引入农场 完整的地图将重新计算。它还使用更少的CPU 运行(大约-1%)。

minimumconn连接数最少的服务器收到 联系。循环在服务器组内执行 具有相同的负载,以确保将使用所有服务器。用 如果会话时间很长,建议使用此算法 预期,例如LDAP,SQL,TSE等...,但不是很好 适用于使用简短会话(例如HTTP)的协议。这 算法是动态的,这意味着服务器权重可能是 例如,针对慢速启动进行了动态调整。它会 除了考虑排队连接的数量外 建立的,以最大程度地减少排队。

首先,具有可用连接插槽的第一台服务器接收 联系。从最低的数字中选择服务器 最高的标识符(请参阅服务器参数“ id“), 哪一个 默认为服务器在服务器场中的位置。一旦服务器 达到其maxconn值,则使用下一个服务器。确实 在不设置maxconn的情况下使用此算法没有任何意义。 该算法的目的是始终使用最小的 服务器数量,以便可以关闭额外的服务器 在非密集时间。该算法忽略服务器 重量,并为RDP等长期会议带来更多好处 或IMAP而不是HTTP,尽管它在这里也很有用。在 为了有效地使用此算法,建议 云控制器定期检查服务器使用情况以将 它们在不使用时关闭,并定期检查后端队列以 队列膨胀时打开新服务器。或者, 使用“ http-check send-state ”可能会通知服务器负载。

source对源IP地址进行哈希处理并除以总数 正在运行的服务器的权重,以指定哪个服务器将 收到请求。这样可以确保相同的客户端IP 只要没有,地址将始终到达同一服务器 服务器关闭或启动。如果哈希结果由于 正在运行的服务器数量发生变化,许多客户端将 定向到另一台服务器。这个算法一般 在不插入Cookie的TCP模式下使用。也可能 在Internet上使用以提供最大努力的粘性 给拒绝会话cookie的客户。这个算法是 默认为静态,这意味着更改服务器的 飞行中的重量不会产生任何影响,但这可以是 使用“哈希类型”更改。

uri此算法对URI的左侧部分进行哈希处理( 问号)或整个URI(如果是“ whole”参数) 存在),然后将哈希值除以 正在运行的服务器。结果指定哪个服务器将 收到请求。这样可以确保相同的URI将 只要没有服务器,始终将其定向到同一服务器 上升或下降。这与代理缓存一起使用,并且 防病毒代理,以最大程度地提高缓存命中率。 请注意,此算法只能在HTTP后端中使用。 默认情况下,此算法为静态算法,这意味着 即时更改服务器的权重将无效, 但这可以使用“ hash-type ”进行更改。

Text Only
          该算法支持两个可选参数“ len”和
          “深度”,均跟一个正整数。这些
          当需要平衡服务器时,选项可能会有所帮助
          仅基于URI的开头。“ len”参数
          表示该算法只应考虑
          URI开头的字符以计​​算哈希值。
          请注意,将“ len”设置为1几乎没有道理,因为大多数
          URI以“ /”开头。

          “ depth”参数表示最大目录深度
          用于计算哈希。每个级别计一次
          在请求中斜杠。如果同时指定了两个参数,则
          达到两者中的任何一个时,评估都将停止。

          “仅路径”参数表示哈希密钥开始
          在路径的第一个“ /”位置。这可以用来忽略
          绝对URI的授权部分,并确保HTTP / 1
          和HTTP / 2 URI将提供相同的哈希值。

url_param参数中指定的URL参数将在 每个HTTP GET请求的查询字符串。

Text Only
          如果使用修饰符“ check_post”,则使用HTTP POST
          将在请求实体中搜索参数实参,
          在问号后的查询字符串中找不到该字符时
          ('?')在网址中。邮件正文只会开始是
          一旦公布的数据量已被分析
          收到或请求缓冲区已满。在极少数情况下
          使用分块编码,只有第一个块是
          扫描。由块边界分隔的参数值可以
          完全随机地平衡。此关键字用于支持
          可选的<max_wait>参数,现在将忽略它。

          如果找到该参数,后跟一个等号('='),然后
          一个值,然后将该值散列并除以总数
          正在运行的服务器的重量。结果指定
          服务器将收到请求。

          这用于跟踪请求中的用户标识符并确保
          相同的用户ID将始终发送到与
          只要没有服务器出现故障即可。如果找不到值,或者
          找不到参数,则循环算法为
          应用。请注意,此算法只能在HTTP中使用
          后端。默认情况下,此算法是静态的,这意味着
          即时更改服务器的权重不会
          效果,但是可以使用“ hash-type ”进行更改。

hdr()将在每个HTTP中查找HTTP标头 要求。就像等效的ACL'hdr()'函数一样, 括号中的标题名称不区分大小写。如果 标头不存在,或者如果标头不包含任何值,则 而是使用roundrobin算法。

Text Only
          可选的'use_domain_only'参数可用,用于
          将哈希算法减少到主域部分
          特定的标头,例如“主机”。例如,在主机中
          值“ haproxy.1wt.eu”,则仅考虑“ 1wt”。

          默认情况下,此算法为静态算法,这意味着
          即时更改服务器的权重将无效,
          但这可以使用“ hash-type ”进行更改。

随机的 随机() 随机数将用作保持一致的键 哈希函数。这意味着服务器的权重是 受尊敬的是,动态体重变化立即生效,因为 以及新服务器的添加。可以进行随机负载平衡 在大型服务器场或频繁添加服务器时很有用 或将其移除,因为这样可以避免锤击作用, 在这种情况下由roundrobin或lessconn导致。这 hash-balance-factor指令可用于进一步改进 负载平衡的公平性,尤其是在某些情况下 服务器的响应时间变化很大。当一个 参数存在,必须为整数1 或更大,指示选择之前的抽奖次数 这些服务器中负载最少的服务器。确实证明了 选择两个服务器中负载最小的一个就足够了 通过显着提高算法的公平性 始终避免选择服务器场中负载最大的服务器 并摆脱由 分配不均的一致清单。较高的值N 将夺走N-1个负载最高的服务器 牺牲性能。具有非常高的值,该算法 会收敛到minimumconn的结果,但速度要慢得多。 默认值为2,通常显示非常好 分布和性能。此算法也称为 两种随机选择的力量,并在此处进行描述: http://www.eecs.harvard.edu/~michaelm/postscripts/handbook2001.pdf

rdp cookie rdp-cookie(<名称>) RDP Cookie <名称>(如果省略,则为“ mstshash”) 查找并为每个传入的TCP请求进行哈希处理。就像 带有等效的ACL'req_rdp_cookie()'函数的名称 不区分大小写。此机制可用作降级 持续性模式,因为它可以始终发送 同一用户(或同一会话ID)到同一服务器。如果 找不到cookie,正常的轮循算法是 代替。

Text Only
          请注意,要使其正常工作,前端必须确保
          RDP cookie已经存在于请求缓冲区中。为了这
          您必须结合使用“ tcp-request内容接受”规则
          一个“ req_rdp_cookie_cnt” ACL。

          默认情况下,此算法为静态算法,这意味着
          即时更改服务器的权重将无效,
          但这可以使用“ hash-type ”进行更改。

          另请参见rdp_cookie模式获取功能。

是某些人可能需要的可选参数列表 算法。目前,只有“ url_param ”和“ uri”支持 可选参数。