【问题标题】:OpenShift HAProxy scaling is just not workingOpenShift HAProxy 扩展不起作用
【发布时间】:2014-12-07 21:44:37
【问题描述】:

我一直在尝试让 OpenShift 的 HAProxy 扩展与任何 NodeJS Express 4 应用程序(它本质上是一个 REST API)一起工作,但我运气不佳。

我正在使用 loader.io 的压力测试工具,每分钟只有 100 个用户(从 0 开始上升),因为我确信至少 NodeJS/Express 应该能够处理这个问题。现在,这确实会在 60 秒内产生大约 10-20k 个请求,但仍然如此。

请求开始冲击服务器后会发生什么,我可以看到 CPU 上升,内存保持稳定,HAProxy 的日志文件让我知道它即将扩大规模。

从来没有。 HAProxy 在扩展之前崩溃,然后我失去了与 OpenShift 主机的 SSH 连接。不过,它会在一段时间后恢复。

有一次我确实看到它达到了默认的 128 连接限制,然后尝试启动另一个齿轮,但由于请求不断涌入,我猜它无法处理它?

起初我以为是因为使用了一个小齿轮,因为我正在运行“top”,并且看到 CPU 负载飙升到了顶峰,最终我断开了连接。

我删除了该应用并切换到 small.highcpu 齿轮(每小时收费)。

当它应该扩大规模时(少于 100 个并发用户)仍然崩溃。

small.highcpu 齿轮确实做了一些不同的事情,因为在它重新启动后,它会添加一个新齿轮,但它不会缩小(即使所有流量都停止了),所以我必须手动缩小

如果我保持第二档并在 1 分钟内再次尝试对 100 个用户进行压力测试,HAProxy 仍然会下降(内存使用率和 CPU 似乎还可以),不久之后我就失去了 SSH 连接。此外,这一次它不会自行出现。我还在我的 NodeJS 应用程序中收到以下错误:

{ [Error: socket hang up] code: 'ECONNRESET' }
{ [Error: socket hang up] code: 'ECONNRESET', sslError: undefined }

如果我在此之后手动重新启动 HAProxy(我不得不重新启动,因为它没有启动),我可以看到本地齿轮已关闭,而第二齿轮已启动,这意味着我的 NodeJS 应用程序在第一齿轮崩溃,但在二档保持在线。

这真的是预期的行为吗?在处理 NodeJS 和 HAProxy 时,我应该做些不同的事情吗?

如果我什至不能处理 100 个用户/分钟,我真的无法证明为这样的服务付费是合理的,因为我确信我最终会达到远远超过 100 个的峰值。

更新:这是一个 loader.io 图表/报告,它显示了 HAProxy 何时放弃: http://ldr.io/1tV2iwj

更新 2:我尝试使用 Blitz 代替 loader.io,只是为了确定 HAProxy 何时发疯。 Blitz 以 12k 次命中、26k 错误和 4k 超时结束。

此外,HAProxy 出现故障,并且似乎永远不会恢复。这次我决定等待,几分钟后,本地齿轮确实恢复了。不过,它并没有带来任何额外的装备。

这也是 HAProxy 在 Blitz 测试发生时告诉我的(在它崩溃并且我断开连接之前):

==> app-root/logs/haproxy_ctld.log <==
I, [2014-10-13T07:14:48.857616 #74934]  INFO -- : add-gear - capacity: 143.75% gear_count: 1 sessions: 23 up_thresh: 90.0%

==> app-root/logs/haproxy.log <==
[WARNING] 285/071506 (74918) : Server express/local-gear is DOWN, reason: Layer7 timeout, check duration: 10002ms. 0 active and 0 backup servers left. 128 sessions active, 0 requeued, 0 remaining in queue.
[ALERT] 285/071506 (74918) : proxy 'express' has no server available!
[WARNING] 285/071511 (74918) : Server express/local-gear is DOWN for maintenance.

更新 3:再次尝试使用 Blitz,这次 HAProxy/NodeJS 没有恢复,而是卡在了以下行(我仍然可以 SSH):

DEBUG: Sending SIGTERM to child...

这里没有太多的模式,除了 HAProxy 没有做它应该做的事情:缩放。 我相当有信心这不是我的 NodeJS 应用程序有问题,因为它没有报告任何错误(到日志文件或 New Relic)。

【问题讨论】:

    标签: node.js openshift scaling haproxy


    【解决方案1】:

    您的设备内存不足,因此您的所有进程都被杀死了。 (这就是为什么你也会被踢出你的 ssh 会话。)当这种情况发生时,它可能会使 haproxy 配置处于错误状态,如果它在重新启动时没有自动修复,我会认为这是一个错误.

    【讨论】:

    • 谢谢!我将此标记为答案,因为它是迄今为止我发现的问题的最接近的解释。我一直在与 RedHat 工程师交谈,他们可以确认这一点。这似乎是由于它们的默认 HAProxy 配置,它期望连接请求逐渐扩展,因此 HAProxy 有时间扩展。在我的例子中,HAProxy 由于突然大量的请求而停止维护。无论如何,这就是 RedHat 所说的。我希望这在生产中不会成为问题,但我希望从一开始就有很多个请求。
    • 哦,还有一件事!你会建议留在 small.highcpu 齿轮上,还是你认为小齿轮就足够了,因为它们都不能处理这种负载?再次感谢你。 :)
    • 由于您遇到内存问题,我建议您升级到中档。此外,您可能需要调整 MAX_SESSIONS_PER_GEAR(这可以控制 haproxy 允许每个齿轮拥有多少并发会话,进而决定您的应用何时放大或缩小)。如果您在开始时预计会出现高负载,则应将应用的最小齿轮数设置为预期负载的合适数量(最小齿轮数 =~ 预期并发会话数除以 MAX_SESSIONS_PER_GEAR)
    猜你喜欢
    • 2014-11-29
    • 1970-01-01
    • 2014-11-30
    • 2014-02-20
    • 2019-03-21
    • 2011-08-18
    • 2012-03-02
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多