Precisa de ajuda para solucionar problemas de timeout TCP intermitente no HAProxy

Question

Eu tenho um aplicativo em que o cliente se conecta a um servidor por meio de um simples protocolo TCP baseado em TLS / SSL. Em desenvolvimento, isso funcionou muito bem por muitos meses enquanto estávamos desenvolvendo nossa aplicação. Recentemente, enquanto nos preparamos para o lançamento, eu fui em frente e adicionei o HAProxy ao mix para facilitar alguma ordem de distribuição de carga. Tudo funciona, tecnicamente, mas o problema é que o cliente agora está vendo saídas de tempo completamente aleatórias. Eles não são tipicamente consistentes, mas acontecem com aproximadamente 60 segundos de duração. Às vezes isso pode acontecer depois de 25 segundos. O servidor que haproxy encaminha a conexão TCP para avisos e faz uma desconexão limpa, o problema é que você não quer um monte de conexões simultâneas sendo interrompidas e reconectadas repetidamente sem qualquer motivo. Isso tem implicações em nossa infraestrutura de publicação / assinatura, além de outras coisas. O cliente é inteligente o suficiente para se reconectar imediatamente - no entanto, esse não é o comportamento que desejamos. O servidor responsável por aceitar essas conexões TCP por SSL não requer manutenção. Vou seguir em frente e assumir que há algum valor implícito que não estou vendo em minha configuração do HAProxy, causando esses tempos limites aleatórios, ou algo que requer que um TCP fique ativo. O fato de que os tempos de espera nem sempre são consistentes, no entanto, me faz pensar diferente. Se fosse 60 segundos no ponto cada vez que eu estivesse convencido de que é um problema de configuração. Neste caso particular, nem sempre são 60 segundos. Aqui está o que minha configuração parece agora:

global
stats socket /home/haproxy/status user haproxy group haproxy
    log 127.0.0.1   local1 info
#   log 127.0.0.1   local5 info 
    maxconn 4096
    ulimit-n 8250
        # typically: /home/haproxy
    chroot /home/haproxy
    user haproxy    
    group haproxy
    daemon
    quiet
    pidfile /home/haproxy/haproxy.pid

defaults
    log global
    mode    http
    option  httplog
    option  dontlognull
    retries 3
    option redispatch
    maxconn 2000
    contimeout  5000
    clitimeout  60000
    srvtimeout  60000

# Configuration for one application:
# Example: listen myapp 0.0.0.0:80
listen www 0.0.0.0:443
        mode tcp
        balance leastconn
    # Example server line (with optional cookie and check included)
    # server    srv3.0 10.253.43.224:8000 srv03.0 check inter 2000 rise 2 fall 3
# Status port (by default, localhost only...for debugging purposes)
    server ANID3 10.0.1.2:8888 check inter 3000 rise 2 fall 3 maxconn 500
    server ANID1 10.0.1.3:8888 check inter 3000 rise 2 fall 3 maxconn 500
    server ANID2 10.0.1.4:8888 check inter 3000 rise 2 fall 3 maxconn 500

listen health 0.0.0.0:9999
        mode http
        balance roundrobin
        stats uri /haproxy-status

Eu verifiquei que o HAProxy é o problema ao fazer com que nosso cliente o ignore e vá diretamente para um único servidor de aplicativos, onde não há tempo limite e tudo é bom e elegante. Assim que eu o rotear através de um dos nossos dois servidores haproxy, as desconexões aleatórias acontecem variando entre 25 e 60 segundos.

Obrigado por dar uma olhada nisso. É bastante frustrante, mas tenho certeza que é uma falta de compreensão do que exatamente o HAProxy espera do meu cliente.

    

Answer 1

Não deve haver razão para o fechamento antecipado da conexão, nem vejo como isso pode acontecer. Seus tempos limite estão definidos para 60s, então deve ser de 60s.

Hum, espere um minuto, você não está exibindo haproxy dentro de um VM com um relógio de funcionamento rápido? É um problema em algumas VMs, onde o relógio às vezes roda rápido demais (mais do que o dobro da velocidade correta) ou, em vez disso, é lento demais com grandes saltos uma vez por minuto. O haproxy sabe como se defender contra pausas e saltos de tempo muito longos que ele pode detectar, mas obviamente ele não pode se defender contra os relógios que estão rodando muito rápido sem ser reportado pelo sistema.

Se você estiver em uma VM, tente isso:

$  while sleep 1; do date; done

E deixe isso funcionar por um ou dois minutos. Verifique por si mesmo se está funcionando na velocidade correta. Já faz um tempo desde a última vez que observei essa questão desagradável, mas isso não significa que isso não acontecerá novamente.

BTW, você deve definir " option tcplog " na sua seção TCP e verificar os logs. Você verá então se do ponto de vista do haproxy, foi um tempo limite, um cliente ou servidor abortar e depois de quanto tempo.

    

Answer 2

Como o tempo é variável e você confirmou definitivamente que o back-end não é responsável, é improvável que ele seja uma configuração de tempo limite.

O que, estranhamente, me levaria a uma solução que talvez fosse o serviço ser reiniciado.

Se algo estiver reiniciando o HAProxy em um cron (por exemplo, monit - que faria uma pesquisa a cada 60 segundos), isso poderia significar que uma sessão dura até 60 segundos antes de ser finalizada ou mais curta.

Verifique novamente seu tempo de atividade no HAProxy e, se ele estiver sempre abaixo de um minuto, sua resposta.

Além disso, pode valer a pena rever as estatísticas do HAProxy apenas para garantir que você não atingiu nenhum limite de sessão difícil, fazendo com que um tempo limite alternativo seja atingido. Se houver menos de maxqueue solicitações na fila, por timeout queue segundos, se após esse tempo limite não for encontrado nenhum servidor não saturado, a solicitação será descartada.

    

Answer 3

Você pode testar isso:

defaults  
    timeout client 60000  
    option http-server-close  

Em vez de clitimeout

link

    

Answer 4

tente isso, resolvi esse problema.

listen mysql-slaves
bind 0.0.0.0:3306
mode tcp
maxconn 20000
option mysql-check user haproxy
balance roundrobin
contimeout 5000
clitimeout 50000
srvtimeout 50000
....