☰

haproxy 的 elastichsearch 节点健康检查

tag-icon • tag-icon haproxy elasticsearch
haproxy 的 elastichsearch 节点健康检查

我已将 haproxy 放置在三节点 ES（elasticsearch）集群前面。到目前为止，我检查 haproxy 中每个节点的方式是使用 httpcheck。下面是我的配置片段：

backend elastic_nodes
balance roundrobin
option forwardfor
option httpchk
http-check expect status 200
server elastic1 10.88.0.101:9200 check port 9200  fall 3 rise 3
server elastic2 10.88.0.102:9200 check port 9200  fall 3 rise 3
server elastic3 10.88.0.103:9200 check port 9200  fall 3 rise 3

到目前为止，此检查工作正常，但如果集群变为红色，响应代码仍然为“200”（这是正确的，因为 http-wise 节点是可访问的），这将使 haproxy 认为后端服务器是健康的。

另一方面，如果我检查集群的状态并在收到健康状态“红色”时将节点标记为关闭，这将标记所有后端服务器为关闭，从而禁用 ES 服务。我对这种方法的问题是，过去我的集群确实是红色的，但它仍然可用，因为只有一个分片丢失（一天的日志）。换句话说，有些情况下 ES 红色状态不是一个大问题，你仍然希望满足 ES 请求（而不是用 haproxy 标记所有后端节点关闭这个阻塞的 ES 服务）。

还有其他方法可以解决这个问题吗？

答案1

我们使用 HAproxy 在两个冗余集群之间实现平衡。正常运行期间，每个集群接收约 50% 的流量；必要时，每个集群可接收 100% 的流量。

我们最近遇到了一个故障，这是基于一个我们未曾预料到的故障案例：所有客户端和主节点都保持运行，因此我们的集群对 REST 有响应，但所有数据节点都暂时离线，所有索引都显示为红色且为空，针对它们的查询返回 0 个结果。但按照 REST 惯例，返回结果为 200。

在这种情况下，我们的简单 HAproxy 健康检查失败了；它仅仅检查了 200 秒。

我现在正在研究使用http-check expect ! string red直接针对感兴趣索引的 URI。我http-check之前没有使用过更高级的功能。

虽然检查成本更高，但是应该正确地将 lobotomized 集群的客户端节点从池中取出。

更新（2）：我已经切换到使用

option httpchk get /_cat/indices/<index of interest>
http-check expect rstring \b(green|yellow)\b

而且它确实看起来是一个更好的测试。

（第二次修订：使用显式检查green或而yellow不是仅仅非红色，后来才想到索引完全从 _catfiter 中缺失……

相关内容