HAProxy
可靠、高性能的 TCP/HTTP 负载均衡器
语言：English
HAProxy可靠、高性能的 TCP/HTTP 负载均衡器 |
|
镜像站点：主站 语言：English |
快速链接最新消息最新消息 描述 主要特性 支持的平台 性能 可靠性 安全性 他们在用！ 企业版功能 第三方扩展 商业支持 附加功能 其他解决方案 讨论 Slack 频道 邮件列表 10GbE 负载均衡 贡献 编码风格 待解决问题 已知缺陷 HATop：Ncurses 界面 Herald：负载反馈代理 haproxystats：统计信息收集 基于 Alpine 的 Docker 镜像 基于 Debian 的 Docker 镜像 基于 RHEL 的 Docker 镜像 Debian/Ubuntu 软件包  位访客在线
 感谢您的支持！
|
警告：此处为旧内容此页面是一个未整理的旧信息和旧链接列表，其中一些可能仍然有效，但绝对已经过时。为了保持主站的整洁，它们已于2021年11月23日从主站移除，并且正在进行手动清理，以便只保留相关和可能有用的内容。您应该不需要此页面上的任何信息。
描述HAProxy 是一款免费、非常快速且可靠的解决方案，为基于 TCP 和 HTTP 的应用程序提供高可用性、负载均衡和代理服务。它特别适用于流量非常高的网站，并为世界上许多访问量最大的网站提供支持。多年来，它已成为事实上的开源负载均衡器标准，现在大多数主流 Linux 发行版都附带它，并且通常默认部署在云平台中。由于它不会自我宣传，我们只有在管理员报告使用情况时才知道它的应用 :-) 它的运行模式使得将其集成到现有架构中变得非常容易且无风险，同时仍然提供了不将脆弱的 Web 服务器暴露在网络中的可能性，如下所示：  我们始终并行支持至少两个活跃版本，以及一个仅处于关键修复模式的旧版本。当前支持的版本是：
主要特性每个版本都在前一个版本的基础上带来了一系列新功能。向上兼容性是 HAProxy 的一个非常重要的方面，即使是 1.5 版本也能够运行 13 年前为 1.0 版本编写的配置。1.6 版本删除了一些长期弃用的关键字，并建议了替代方案。每个版本最具差异化的功能如下：
1.2 版本自 2006 年以来一直在生产环境中使用，并在 1.1 的基础上提供了更高的性能水平。该版本已不再维护，因为其大多数用户早已切换到 1.3。自 2002 年以来一直维持关键站点在线的 1.1 版本也已不再维护。建议用户升级到 1.4 或 1.5。
支持的平台已知 HAProxy 可在以下操作系统/平台上可靠运行：
在支持可扩展轮询机制的现代操作系统上可获得最高性能，例如 Linux 2.6/3.x 上的 epoll 或 FreeBSD 和 OpenBSD 上的 kqueue。这需要高于 1.2.5 版本的 haproxy。在 Linux 3.x 上使用 TCP splicing 和 haproxy 1.4 或 1.5 可以实现快速数据传输。经过非常仔细的调优，在这样的平台上已经实现了高达 40 Gbps 的转发速率。虽然支持 Solaris 和 AIX，但如果需要极端性能，则不应使用它们。 目前典型的 1U 服务器配备六核到八核处理器，通常能达到 200,000 到 500,000 请求/秒，并且在 Linux 下可以轻松跑满 25 Gbps 以太网。
性能 [ 警告：本节信息可追溯至 2007 年，此后性能已提高一个数量级 ] HAProxy 采用了一些操作系统架构中常见的技术，以实现绝对的最大性能：
所有这些微观优化使得即使在中等负载下，CPU 使用率也非常低。即使在非常高的负载下，当 CPU 饱和时，也很常见到像 5% 用户和 95% 系统这样的数据，这意味着 HAProxy 进程的消耗大约是其系统对应部分的 20 倍。这解释了为什么操作系统的调优非常重要。这也是为什么我们最终会构建我们自己的设备，以避免最终用户执行这项复杂而关键的任务。 在生产环境中，当非常昂贵的高端硬件负载均衡器在第 7 层处理上突然失效时，HAProxy 已多次被安装为应急解决方案。一些硬件负载均衡器仍然不使用代理，并在数据包层面处理请求，因此在支持跨多个数据包的请求和高响应时间方面有很大困难，因为它们根本不做任何缓冲。另一方面，软件负载均衡器使用TCP 缓冲，对长请求和高响应时间不敏感。HTTP 缓冲的一个很好的副作用是它通过减少会话持续时间来增加服务器的连接接受能力，从而为新请求留出空间。 衡量负载均衡器性能有3个重要因素：
负载均衡器与这些因素相关的性能通常是在最佳情况下公布的（例如：会话速率对应空对象，数据速率对应大对象）。这并非因为供应商不诚实，而是因为不可能确切地说明它在每种组合下的行为。因此，当这3个限制已知时，客户应该意识到它的性能通常会低于所有这些限制。对于软件负载均衡器，一个好的经验法则是，对于中等大小的对象，其实际平均性能约为最大会话和数据速率的一半。 您可能有兴趣查看 10-Gigabit/s 页面。
可靠性 - 自 2002 年以来一直保持高流量网站在线出于对可靠性的执着，我尽力通过设计来确保服务的完全连续性。在短期内，设计一个可靠的东西更困难，但从长远来看，它比那些试图通过重生进程和类似技巧来掩盖自身错误的破损代码更容易维护。 在单进程程序中，你没有失败的权利：最小的错误要么会使你的程序崩溃，要么使其疯狂旋转或冻结。在过去的 13 年里，稳定版本中没有发现过这样的错误，尽管在生产环境中运行的开发代码中发生过几次。 HAProxy 已经安装在 Linux 2.4 系统上，每天提供数百万页面的服务，并且在 3 年内仅因一次完整的操作系统升级而重启过一次。显然，它们没有直接暴露在互联网上，因为它们根本没有收到任何补丁。内核是经过大量修补的 2.4 版本，带有 Robert Love 的jiffies64补丁，以支持 497 天的时间回绕（这发生了两次）。在这样的系统上，软件一旦失败就会立即被发现！ 现在，它被全球许多财富500强公司使用，可靠地每天提供数十亿的页面服务或中继巨额资金。有些人甚至非常信任它，以至于他们将其用作解决简单问题的默认方案（我经常告诉他们这样做的方式很粗糙）。这些人有时仍然使用 1.1 或 1.2 版本，这些版本的演进非常有限，主要针对关键任务应用。HAProxy 非常适合这样的环境，因为它返回的指标提供了大量关于应用程序健康状况、行为和缺陷的宝贵信息，这些信息被用来使其更加可靠。1.3 版本现在已经接受了比 1.1 和 1.2 加起来多得多的测试，因此强烈建议用户迁移到稳定的 1.3 或 1.4 版本以用于关键任务。 如前所述，大部分工作由操作系统执行。因此，很大一部分的可靠性都涉及到操作系统本身。最新版本的Linux 2.4以提供有史以来最高水平的稳定性而闻名。然而，它需要一系列补丁才能达到高性能水平，而且这个内核现在确实过时了，所以在最近的硬件上运行它通常会很困难（尽管有些人仍然这样做）。Linux 2.6和3.x包含了达到这种性能水平所需的功能，但对于真正稳定的操作，只应考虑旧的LTS版本，每年升级不超过一次。有些人更喜欢在Solaris上运行它（或者没有选择）。Solaris 8和9现在被认为是真正稳定的，提供的性能水平可与旧的Linux 2.4（没有epoll补丁）相媲美。Solaris 10的性能可能更接近早期的Linux 2.6。FreeBSD表现出良好的性能，但pf（防火墙）吃掉了一半的性能，需要禁用才能接近Linux。OpenBSD有时会因为套接字停留在FIN_WAIT2状态而显示套接字分配失败，当客户端突然消失时。另外，我注意到热重配在OpenBSD下不起作用。 当系统被推到极限时，可靠性会显著下降。这就是为什么精细调整sysctls非常重要。没有通用的规则，每个系统和每个应用程序都是特定的。然而，重要的是要确保系统永远不会耗尽内存，并且永远不会交换。一个正确调优的系统必须能够在满负荷下运行多年而不会变慢或崩溃。
安全性 - 13 年来无一例入侵在部署软件负载均衡器时，安全性是一个重要的考虑因素。可以加固操作系统，限制开放端口和可访问服务的数量，但负载均衡器本身仍然是暴露的。因此，我对编程风格非常小心。haproxy 很少遇到漏洞，其架构显著限制了漏洞的影响，并通常允许简单的变通方法。其远程不可预测的事件处理使得可靠地利用任何漏洞变得非常困难，而且如果进程崩溃，漏洞就会被发现。顺便说一下，所有这些漏洞都是通过对意外崩溃的反向分析发现的。 无论如何，在编写操作标头的代码时都非常小心。不可能的状态组合会被检查并返回，错误从会话创建到销毁都会被处理。全球有几个人审查了代码，并提出了清理建议以提高清晰度，便于审计。顺便说一句，我习惯于拒绝那些引入可疑处理或对异常情况不够注意的补丁。 我通常建议以root身份启动 HAProxy，因为这样它就可以将自己关在chroot jail 中，并在启动实例之前放弃其所有权限。如果不是以root身份启动，这是不可能的，因为只有rootroot 才能执行chroot()，这与一些管理员的看法相反。日志提供了大量信息来帮助维持令人满意的安全级别。它们通常通过UDP发送，因为一旦 chroot，/dev/log
计时器有助于区分手动输入的请求和浏览器的请求。
HAProxy 还提供基于正则表达式的标头控制。请求的部分内容，以及请求和响应的标头可以被拒绝、允许、移除、重写或添加。这通常用于阻止危险的请求或编码（例如，Apache Chunk 漏洞），并防止服务器意外地向客户端泄露信息。其他功能，如Cache-control 检查，确保敏感信息不会因为应用服务器的错误而被上游代理意外缓存。商业支持和可用性
我还认为有必要感谢Loadbalancer.org。我与他们没有任何关联，但像我们一样，他们为该项目贡献了相当多的时间和金钱来增加新功能，并且他们在邮件列表上帮助用户，所以我对他们的工作表示尊重。他们是一家英国公司，他们的负载均衡器也使用 HAProxy，尽管它与 ALOHA 有些不同。附加功能和贡献 一些满意的用户贡献了代码，这些代码可能被包含也可能不被包含。其他人花了很长时间分析代码，还有一些人维护着最新的端口。最困难的内部更改是由一些大客户以付费时间的形式贡献的，他们有能力支付一名开发人员数月的时间来从事一个开源项目。不幸的是，其中一些客户不希望被列出，其中最大的客户就是这种情况。
地理位置支持 不久前，Cyril Bonté 联系我，讨论他开发的一个非常有趣的功能，最初是为 1.4 版本开发的，现在同时支持 1.4 和 1.5。这个功能是地理定位，许多用户长期以来一直要求这个功能，而且这个功能不需要按国家代码分割 IP 文件。事实上，它的配置非常简单方便。 该功能尚未合并，因为它针对一个特定目的（GeoIP）做了我们希望用于更通用用途（地图转换器、会话变量以及在重定向URL中使用变量）的事情，这将允许以更大的灵活性实现相同的功能（例如：从标头中提取IP，或将国家代码和/或AS号传递给后端服务器等）。Cyril 对这些论点非常 receptive，并同意在功能实现之前将他的补丁集维护在树外（更新：带有地图的 1.5-dev20 现在使这成为可能）。Cyril 的代码维护良好并在生产中使用，因此在 1.4 上使用它没有风险，只是升级到 1.5 后配置语句会略有变化。
sFlow 支持 Neil Mckee 在 2013 年初向列表发布了一个补丁，不幸的是，这个补丁没有收到任何兴趣或反馈的迹象，考虑到所做的工作量，这很令人遗憾。我个人对 sFlow 一无所知，并向 Neil 表达了我的怀疑，即当您可以通过现有日志免费获得更详细的信息时，对一些 HTTP 流量进行采样的好处是什么。
sFlow 带来的价值在于其测量是标准的，并且旨在与来自交换机、路由器、服务器和应用程序的 sFlow 数据流无缝集成，从而提供对大规模多层系统性能的全面端到端视图。因此，其目的与其说是孤立地排查 haproxy 的问题，不如说是分析 haproxy 所属的整个系统的性能。 也许最好的例证是 1-in-N 采样功能。如果您将 sampling.http 配置为，比如说，1-in-400，那么您可能每秒只能从一个 haproxy 实例看到少数几个 sFlow 记录，但这足以告诉您很多关于正在发生的事情的信息——而且是实时的。即使您有一堆负载均衡器、数百台网络服务器、一个巨大的 memcache 集群和一个快速的网络互连都在向同一个分析器贡献它们自己的 sFlow 数据流，这些数据也不会让您应接不暇。
即使在那次解释之后，邮件列表上也没有就此主题展开讨论，所以我猜想目前用户对此兴趣不大。我怀疑sFlow可能更多地部署在网络设备上，而不是应用层设备上，这可以解释这种情况。代码量很大（虽然不是巨大），如果没人表现出一点兴趣，我对其合并和维护的好处并不信服。因此，目前我倾向于将其保留在树外。Neil已将其发布在GitHub上：https://github.com/sflow/haproxy。 如果您确实使用了这个补丁，请将您的反馈报告给邮件列表，并投入一些时间帮助进行代码审查和测试。
此表列举了导致 1.4 版本的所有已知重要贡献，以及提议的资金和有待开发但仍在等待空闲时间的功能。不过，它没有更新。 一些可能未出现在上表中的较早的代码贡献仍在此处列出。
其他解决方案如果您不需要 HAProxy 的所有功能，并且正在寻找一个更简单的解决方案，您可能会在这里找到您需要的东西：
|
