O backend do Haproxy permanece inativo e nunca é ativado novamente

2

Funciona bem até o momento em que o servidor remoto fica indisponível por algum tempo. Nesse caso, o servidor fica inativo nos logs e nunca é ativado novamente. Config é bem simples:

defaults
    retries 3
    timeout connect 5000
    timeout client 3600000
    timeout server 3600000
    log global
    option log-health-checks

listen amazon_ses
    bind 127.0.0.2:1234
    mode tcp
    no option http-server-close
    default_backend bk_amazon_ses

backend bk_amazon_ses
    mode tcp
    no option http-server-close
    server amazon email-smtp.us-west-2.amazonaws.com:587 check inter 30s fall 120 rise 1

Aqui estão os registros quando o problema ocorre:

Jul  3 06:45:35 jupiter haproxy[40331]: Health check for server bk_amazon_ses/amazon failed, reason: Layer4 timeout, check duration: 30004ms, status: 119/120 UP. 
Jul  3 06:46:35 jupiter haproxy[40331]: Health check for server bk_amazon_ses/amazon failed, reason: Layer4 timeout, check duration: 30003ms, status: 118/120 UP. 
Jul  3 06:47:35 jupiter haproxy[40331]: Health check for server bk_amazon_ses/amazon failed, reason: Layer4 timeout, check duration: 30002ms, status: 117/120 UP.
...
Jul  3 08:44:36 jupiter haproxy[40331]: Health check for server bk_amazon_ses/amazon failed, reason: Layer4 timeout, check duration: 30000ms, st
atus: 0/1 DOWN. 
Jul  3 08:44:36 jupiter haproxy[40331]: Server bk_amazon_ses/amazon is DOWN. 0 active and 0 backup servers left. 0 sessions active, 0 requeued, 
0 remaining in queue. 
Jul  3 08:44:36 jupiter haproxy[40331]: backend bk_amazon_ses has no server available!'

E é isso. Nada além do recarregamento manual do servidor (o service haproxy reload no FreeBSD) traz o servidor de volta à vida. Eu também tentei remover a parte do cheque e o que segue - ainda acontece a mesma coisa. Não haproxy pode ser configurado para tentar indefinidamente e não marcar um servidor para baixo? Obrigado.

    
por Rihad 03.07.2018 / 10:09

1 resposta

0

Você já tentou usar tempos limite menores? Também usando algo assim? \

server amazon email-smtp.us-west-2.amazonaws.com:587 check inter 5s fall 3 rise 2

Além disso, tente adicionar essas opções ao seu back-end:

mode tcp
option tcplog
option log-health-checks

e, em seguida, verifique novamente os logs do haproxy, veja se você obtém informações adicionais.

Você também pode tentar, manualmente, a partir da caixa haproxy para fazer telnet naquele servidor na porta 587 e ver se consegue se conectar quando o haproxy o relata como inativo? Se você não consegue se conectar via telnet, é normal que o haproxy relate isso.

Existe alguma limitação de taxa, firewall ou qualquer outra configuração similar na sua caixa SMTP que possa bloquear o servidor haproxy?

    
por 10.07.2018 / 07:13

Tags