[转][笔记] 1. HAProxy 介绍

转自（有部分自己补充的内容）:
http://freeloda.blog.51cto.com/2033581/1294094

一、前言
二、haproxy 简介
三、haproxy 版本特性
四、haproxy 支持的平台及OS
五、haproxy 性能特点
六、负载均衡器的性能评估因素

一、前言

在上几篇博客中我们主要讲解了nginx的相关知识，有nginx作为Web服务器的配置讲解，作为反向代理、负载均衡服务器的讲解，在这一节中我们主要讲解有haproxy知识，haproxy是免费、极速且可靠的用于为TCP和基于HTTP应用程序提供高可用、负载均衡和代理服务的解决方案，尤其适用于高负载且需要持久连接或7层处理机制的web站点。下面我们就来详细的说一说haproxy。

二、haproxy 简介

HAProxy是一款提供高可用性、负载均衡以及基于TCP（第四层）和HTTP（第七层）应用的代理软件，HAProxy是完全免费的、借助HAProxy可以快速并且可靠的提供基于TCP和HTTP应用的代理解决方案。免费开源，稳定性也是非常好，这个可通过一些项目可以看出来，单Haproxy也跑得不错，稳定性可以与硬件级的F5相媲美；

根据官方文档，HAProxy可以跑满10Gbps-New benchmark of HAProxy at 10 Gbps using Myricom's 10GbE NICs （Myri-10G PCI-Express），这个数值作为软件级负载均衡器是相当惊人的。

HAProxy 支持连接拒绝 : 因为维护一个连接的打开的开销是很低的，有时我们很需要限制攻击蠕虫（attack bots），也就是说限制它们的连接打开从而限制它们的危害。这个已经为一个陷于小型DDoS攻击的网站开发了而且已经拯救了很多站点，这个优点也是其它负载均衡器没有的。
HAProxy 支持全透明代理（已具备硬件防火墙的典型特点）: 可以用客户端IP地址或者任何其他地址来连接后端服务器. 这个特性仅在Linux 2.4/2.6内核打了cttproxy补丁后才可以使用. 这个特性也使得为某特殊服务器处理部分流量同时又不修改服务器的地址成为可能。
HAProxy现多于线上的Mysql集群环境，我们常用于它作为MySQL（读）负载均衡。自带强大的监控服务器状态的页面，实际环境中我们结合Nagios进行邮件或短信报警，这个也是我非常喜欢它的原因之一
HAProxy支持虚拟主机。
HAProxy特别适用于那些负载特大的web站点，这些站点通常又需要会话保持或七层处理。HAProxy运行在当前的硬件上，完全可以支持数以万计的并发连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中，同时可以保护你的web服务器不被暴露到网络上。

注，在功能上，能以proxy反向代理方式实现Web均衡负载，这样的产品有很多。包括lvs，Nginx，ApacheProxy，lighttpd等。国内生产环境上使用Haproxy的公司很多，例如淘宝的CDN系统，

taobao

三、haproxy 版本特性

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

1.HAProxy目前已经出到 1.6，稳定版有 1.4，1.5，1.6：

2.haproxy 1.4 版本特性

客户端的长连接(client-side keep-alive)
TCP加速(TCP speedups)
响应池(response buffering)
RDP协议
基于源的粘性(source-based stickiness)
更好的统计数据接口(a much better stats interfaces)
更详细的健康状态检测机制(more verbose health checks)
基于流量的健康评估机制(traffic-based health)
支持HTTP认证
服务器管理命令行接口(server management from the CLI)
基于ACL的持久性(ACL-based persistence)
日志分析器

haproxy 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)：适用于托管环境；

更多可查看官网：http://www.haproxy.org/#doc1.4

注，一般企业中用的较多的还是haproxy 1.4，但应用还是得看实际情况。

四、haproxy 支持的平台及OS

仅摘取出对于 Linux 的要求。

Linux 2.6 / 3.x on x86, x86_64, ARM, Sparc, PPC64

要获得高性能，需要支持 epoll 的 Linux 2.6/3.x。

快速数据传输：Linux 3.x/Linux 2.6(>=2.6.27.19) 和 haproxy 1.4 or 1.5 。

进过精心调优，数据转发率可达 40G。

双核 Xeon 1U 服务器，可获得 15000 ~ 40000 hits/s，2Gbps 的数据能力。

五、haproxy 性能特点

HAProxy借助于OS上几种常见的技术来实现性能的最大化。
单进程、事件驱动模型显著降低了上下文切换的开销及内存占用。

O(1)事件检查器(event checker)允许其在高并发连接中对任何连接的任何事件实现即时探测。在任何可用的情况下，单缓冲(single buffering)机制能以不复制任何数据的方式完成读写操作，这会节约大量的CPU时钟周期及内存带宽；
借助于Linux 2.6 (>= 2.6.27.19)上的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缓冲，可建立极长的请求，且有着较大的响应时间。

六、负载均衡器的性能评估因素

三个重要因素：

会话率：单位时间内的处理的请求数

这个指标非常重要，因为它直接决定了一个均衡调度器是否能够将它所接收到的所有请求分发出去。这个性能通常依赖于 CPU。

对于 HTTP/1.0 和 HTTP/1.1 协议，当关闭了 keep-alive 连接保持功能，session/s 和 requests/s 或者 hits/s 是一样的。

对于 HTTP/1.0 和 HTTP/1.1 协议，当开启了 keep-alive 连接保持功能，requests/s 或者 hits/s 要高很多，因为服务器端的工作减轻了很多，减少了很多的连接创建、关闭的工作。但这对于互联网应用没有太多意义，因为用户总是打开大量连接，但平均每个连接只发送较少的请求。

这个指标根据响应报文的平均大小而变化，如果响应报文是 with HTTP 302, 304 or 404 response codes，在 Xeon E5 系统上，session/s 可达到 100,000 。

会话并发能力：并发处理能力

这个指标与上一个指标相关联。当并发会话数上升时，session/s 会下降（除非使用了 epoll 或者 kqueue 机制）。

如果均衡调度器每秒接收了 10000 个会话，并且在 100ms 内响应，那么并发会话数为 1000。这个数字被内存以及系统允许的文件描述符数量所限制。

如果是 16KB buffer，HAProxy 的每个 session 需要 34KB，30000 sessions per GB of RAM。

在实践环境中，socket buffer 也需要一些内存，20000 sessions per GB of RAM 更为合理。

4层均衡代理一般声称支持百万并发会话，因为它们需要处理 TIME_WAIT socket，因为他们不处理数据，所以不需要 buffer，而且在直接路由模式下，只处理入站的请求，不处理出站的响应，所以它们必须在长时间维持会话，避免TCP连接关闭之前切断会话。

数据率：处理数据能力

这个指标一般是 session rate 的反面。使用 MB/s 或 GB/s 做为计量单位。当传输大的对象时，可获得更高的数据率，这时 session 的创建和销毁是最少的。large object 一般会增加并发会话数。大的数据率需要占用大量的 CPU 和 bus cycles，因为需要将数据从进入的网络接口拷贝到内存，然后拷贝到数据接口。硬件负载均衡倾向于直接将数据从入口复转接到出口，以获得更高的数据率，但这样就不能对它们进行处理。

2014 年的 Xeon E5 可获得 40Gpbs 的数据率。

这里列出的最高数据是根据具体情况来的（eg: empty objects for session rate, large objects for data rate）。因为很难告诉你在各种组合场景中准确的数字。实际中，数据会低于这里给出的上限，考虑取它们的中间值是比较合适的。