为什么要用-HAProxy-而不是-Nginx-做负载均衡

43次阅读

共计 3136 个字符,预计需要花费 8 分钟才能阅读完成。

负载均衡器是数据中心的入口点,处于访问一切资源的关键路径上。

这给了他们一些有趣的特征。首先,它们是在基础设施中需要监控的最重要的点。其次,他们处于一个独特的位置,不仅可以提供有关自己的特性,还可以提供他们所支持的后端的每项服务。

有两种流行的开源软件负载均衡器:HAProxynginx。让我们看看他们在这方面的异同。

启用负载均衡器上的监控

如题。负载均衡器将生产环境的一切服务组织成为一个整体系统。

  • 安装新的东西
  • 启用统计信息和监控内容
  • 启用日志
  • 启用 nginx 状态页面

编辑 /etc/nginx/nginx.conf

server { 
    listen 0.0.0.0:6644; 
    access_log off; 
    
    allow 127.0.0.0/8; 
    allow 10.0.0.0/8; 
    deny all;
    
    location / {stub_status on;} 
}

启用 HAProxy 统计信息页面
编辑/etc/haproxy/haproxy.cfg

listen stats 0.0.0.0:6427 
    mode http 
    maxconn 10 
    no log 
    
    acl network_allowed src 127.0.0.0/8 
    acl network_allowed src 10.0.0.0/8 
    tcp-request connection if if!network_allowed 
    
    stats enable 
    stats uri /

从负载均衡器收集指标
有标准的监控解决方案:datadog,signalfx,prometheus,graphite … [2]

这些工具从应用程序,服务器和基础架构收集指标,它们允许检索指标,绘制图表并发送警报。

将负载平衡器集成到我们的监控系统中至关重要。我们需要了解客户端活动情况,请求数,错误率等 …

毋庸置疑,监控能力将受限于负载均衡器测量到的信息。

可从 nginx 获得指标

nginx 只提供 7 种不同的指标。

Nginx 仅在所有站点上给出总和。单个站点或应用程序则没有任何数字对应。

活动连接:当前活动客户端连接数,包括等待连接。
接受:接受的客户端连接总数。
handling:已处理连接的总数。通常,参数值与 accept 相同,除非已达到某些资源限制(例如,worker_connections 限制)。
请求:客户端请求的总数。
读取:nginx 正在读取请求头的当前连接数。
写入:nginx 将响应写回客户端的当前连接数。
等待:等待请求的当前空闲客户端连接数。

资料来源:https://nginx.org/en/docs/htt…

HAProxy 提供的指标

HAProxy 提供 83 种不同的指标。

数字是全局,每个前端和每个后端(无论哪个有意义)。它们可在人类可读的网页上以原始 CSV 格式提供。

0. pxname [LFBS]:代理名称
1. svname [LFBS]:服务名称(FRONTEND 用于前端,BACKEND 用于后端,任何名称用于服务器 / 侦听器)2. qcur [..BS]:当前排队的请求。对于后端,这将报告未分配服务器的队列号。3. qmax [..BS]:qcur 的最大值
4. scur [LFBS]:当前会话
5. smax [LFBS]:最大会话
6. slim [LFBS]:配置的会话限制
7. stot [LFBS]:累计数连接
8. bin [LFBS]:字节输入
9. bout [LFBS]:字节输出

[...] 

32. 类型[LFBS] :( 0 = 前端,1 = 后端,2 = 服务器,3 = 套接字 / 监听器)33. rate [.FBS]:每秒的会话数超过最后一秒
34. rate_lim [.F ..]:每秒新会话的配置限制
35. rate_max [.FBS]:每秒新会话的最大数量
36. check_status [... S]:上次健康检查的状态,其中一个:37. check_code [... S]:layer5- 7 代码,如果可用
38. check_duration [... S]:以 ms 为单位完成上次健康检查所用的时间
39. hrsp_1xx [.FBS]:带 1xx 代码的 http 响应
40. hrsp_2xx [.FBS]:具有 2xx 代码的 http 响应
41. hrsp_3xx [.FBS]:具有 3xx 代码
42. http 响应.hrsp_4xx [.FBS]:具有 4xx 代码的 http 响应
43. hrsp_5xx [.FBS]:http 响应 5xx 代码
44. hrsp_other [.FBS]:与其他代码的 http 响应(协议错误)[...]

资料来源:http://cbonte.github.io/hapro…

监控负载均衡器

上述度量标准用于在正在运行的系统上生成状态。

首先,我们将看到每个负载均衡器开箱即用的状态页面。然后我们将深入研究第三方监控解决方案。

Nginx 状态页面

7 个 nginx 指标显示在人类可读的网页上,可在 127.0.0.1:6644/ 访问

不开玩笑。这就是 nginx 认为的“状态页面”。WTF?

它不显示负载平衡的应用程序。它不显示哪些服务器在线(有什么东西甚至运行???)。在该页面上没有什么可看的,它无助于调试任何问题。

HAProxy 统计页面

为了比较,让我们看一下 HAProxy 监控页面,可在 127.0.0.1:6427 访问

在这里,我们可以看到哪些服务器上升或下降,使用了多少带宽,连接了多少客户端等等。这就是监控的意义所在。

正如一位经验丰富的系统管理员曾经告诉我:“这页是宇宙中最重要的事情。”[1]

每当事情变得不稳定时。首先,您在浏览器中打开www.yoursite.com,看看它有多糟糕。其次,打开 HAProxy 统计信息页面以查找损坏的内容。此时,您已经 90%的时间发现了问题的根源。

在可用监控有限的环境中尤其如此,或者更糟糕的是,根本没有监控工具。状态页面随时可以提供帮助(如果不是,那么只需要几条配置行)。

将 nginx 与监控系统集成

我们所能得到的只是来自网络状态页面的 7 个指标,其中只有请求数是值得注意的。它没有以 API 友好格式公开,并且不可能获得每个站点的数字。我们唯一能做的就是解析原始文本,寄希望于在未来的版本中不会改变间距。

鉴于 nginx 没有公开任何有用的信息,现有的监控工具都不能与之集成。当没有任何东西可以得到时,没有任何东西可以显示,也没有什么可以提醒的。

注意:一些监控工具实际上假装支持 nginx 集成。这意味着他们解析文本并提取请求数。这就是他们所能获得的一切。

将 HAProxy 与监控系统集成

除了漂亮的人类可读监控页面之外,所有 HAProxy 指标都以 CSV 格式提供。工具可以(并且确实)利用它。

例如,这是 Datadog 提供的默认 HAProxy 仪表板:

Datadog 预制的 HAProxy 仪表板

资料来源:http://docs.datadoghq.com/int…

主机上安装的 Datadog 代理会定期收集 HAProxy 指标。可以绘制指标,可以将图表排列到仪表板(这是一个示例),同时我们可以配置自动警报。

HAProxy 状态页面提供当前状态(在生成页面时),而监控解决方案保存历史记录并允许事后的调试。

为什么 nginx 没有监控?

nginx 故意缺少所有监视功能。它们不会也永远不会 免费 提供。

如果您已被 nginx 锁定,并且需要一个合适的监控页面和用于集成的 JSON API,则必须支付“Nginx Plus”版本的费用。价格从每台服务器每年 1900 美元起。

请参阅:https://www.nginx.com/products/pricing/

结论:不惜一切代价避免使用 nginx

负载均衡器是传输的关键点,也是在基础架构中需要监控的最重要的事情。

Nginx 的为金钱而剥离了所有监控功能,同时装作开源的样子。

对我们的运营完全视而不见是不可接受的。远离nginx。请改用HAProxy

正文完
 0