verificação de integridade do nó elastichsearch para haproxy

Question

Eu tenho lugar haproxy na frente de um cluster ES de três nós (elasticsearch). Até agora, a maneira que eu verifico cada nó no haproxy é usando httpcheck. Abaixo está um trecho da minha configuração:

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

Até agora essa verificação funciona bem, mas se o cluster ficar vermelho, o código de resposta ainda será "200" (isso está correto, já que o nó está acessível), o que tornará o haproxy saudável.

Por outro lado, se eu verificar o status do cluster e marcar um nó como inativo ao receber o status de integridade "Red", isso marcará todos os servidores backend como inativos, desativando assim o serviço ES. Meu problema nessa abordagem é que, no passado, meu cluster era realmente vermelho, mas ainda era utilizável, pois havia apenas um único fragmento faltando (um log de dias). Em outras palavras, há casos em que o status ES Red não é um grande problema e você ainda deseja atender às solicitações ES (em vez de marcar todos os nós de back-end com o haproxy, esse serviço ES de bloqueio).

Existe alguma outra abordagem para isso?

    

Answer 1

Nós usamos o HAproxy para equilibrar entre dois clusters redundantes. Durante a operação normal, cada um recebe ~ 50% do tráfego; cada um é provisionado para tirar 100% quando necessário.

Tivemos uma falha recentemente baseada em um caso de falha que não planejamos: todos os nós cliente e mestre permaneceram ativos, então nosso cluster respondeu ao REST, mas todos os nós de dados estavam temporariamente off-line, todos os índices apareciam vermelhos e vazios e consultas contra eles retornaram 0 resultados. Mas com 200, seguindo a convenção REST.

Nossa verificação de integridade simples do HAproxy falhou neste caso; apenas verificado por 200s.

Agora estou investigando o uso de http-check expect ! string red com um URI que segmenta diretamente o índice de interesse. Eu não usei os recursos http-check mais avançados antes.

Uma verificação mais cara, mas deve levar corretamente os nós clientes de um cluster lobotomizado para fora do pool.

UPDATE (2): eu mudei para nós usando

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

e, de fato, parece um teste melhor.

(Segunda revisão: usando a verificação explícita para green ou yellow em vez de apenas não-vermelho, pensava tardiamente no índice totalmente ausente de _cat fiter ..._