Depuração de HAProxy

1

Eu testei / testei um cluster de servidores localmente por um bom tempo sem problemas. Recentemente, configurei meu cluster de servidores para um teste ao vivo, e notei problemas, e acredito que o HAProxy em meu cluster pode estar com alguns problemas.

Primeiramente vou passar por cima de um pouco da estrutura do cluster, talvez haja um problema em como eu os configurei, talvez eu precise de múltiplos proxies.

Eu tenho dois clusters de servidores que o HAProxy está balanceando. Vamos chamá-los de SC1 e SC2. O cluster principal é SC1, qualquer coisa na porta 80 para o HAProxy será enviada para o SC1. O SC1 processará o pedido e enviará outro pedido para o SC2 através do proxy na porta 8080. Eu não acho que isso seria um problema, mas eu noto nos meus logs no meu servidor que o SC1 não consegue se conectar ao SC2, eu acredito que isso é porque meu HAProxy está sendo sobrecarregado.

A razão pela qual eu estou pensando que o HAProxy está sendo sobrecarregado é porque quando eu olho para a minha página de estatísticas, muitas vezes leva > 1 segundo para responder. Por causa disso, decidi dar uma olhada nos logs do HAProxy. Eu notei uma anormalidade nos logs, que acredito estar ligada aos meus problemas. A cada minuto ou mais (às vezes mais, às vezes menos), recebo a seguinte mensagem:

Oct  8 15:58:52 haproxy rsyslogd-2177: imuxsock begins to drop messages from pid 3922 due to rate-limiting
Oct  8 15:58:52 haproxy kernel: [66958.500434] net_ratelimit: 2997 callbacks suppressed
Oct  8 15:58:52 haproxy kernel: [66958.500436] nf_conntrack: table full, dropping packet

Eu queria saber quais eram as repercussões disso. Isso causaria a queda de pacotes ou isso poderia causar atrasos também? Como posso resolver este problema? Estou executando no servidor Ubuntu 12.04LTS.

Aqui estão minhas modificações sysctl:

fs.file-max = 1000000
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1

Aqui está o meu arquivo de configuração:

global
   log /dev/log   local0 info
   log /dev/log   local0 notice
   maxconn 50000
   user u1
   group g1
   #debug

defaults
   log     global
   mode    http
   option  httplog
   option  dontlognull
   option  forwardfor
   retries 3
   option redispatch
   option http-server-close
   maxconn 50000
   contimeout      10000
   clitimeout      50000
   srvtimeout      50000
   balance roundrobin

listen  sc1 255.255.255.1:80
    maxconn 20000
    server  sc1-1 10.101.13.68:80 maxconn 10000
    server  sc1-2 10.101.13.66:80 maxconn 10000
listen  sc1-1_Update  255.255.255.1:8181
    maxconn 20000
    server  sc1-1 10.101.13.66:80 maxconn 20000
listen  sc1-2_Update  255.255.255.1:8282
    maxconn 20000
    server  sc1-2 10.101.13.68:80 maxconn 20000
listen  sc2 255.255.255.1:8080
    maxconn 30000
    server  sc2-1 10.101.13.74:80 maxconn 10000
    server  sc2-2 10.101.13.78:80 maxconn 10000
    server  sc2-3 10.101.13.82:80 maxconn 10000
listen  sc2-1_Update 255.255.255.1:8383
    maxconn 30000
    server  sc2-2 10.101.13.78:80 maxconn 15000
    server  sc2-3 10.101.13.82:80 maxconn 15000
listen  sc2-2_Update 255.255.255.1:8484
    maxconn 30000
    server  sc2-1 10.101.13.74:80 maxconn 15000
    server  sc2-3 10.101.13.82:80 maxconn 15000
listen  sc2-3_Update 255.255.255.1:8585
    maxconn 30000
    server  sc2-1 10.101.13.74:80 maxconn 15000
    server  sc2-2 10.101.13.78:80 maxconn 15000
listen  stats :8888
    mode http
    stats enable
    stats hide-version
    stats uri /
    stats auth user:pass

O sc1 e o sc2 são os principais clusters. Todos os outros que eu uso quando eu tenho que atualizar meus servidores (encaminhar porta 80 para 8181 no haproxy por exemplo para atualizar o servidor sc1-1).

Qualquer ajuda com este assunto seria muito apreciada.

Obrigado

    
por Eumcoz 08.10.2013 / 18:22

1 resposta

2

Parece que sua tabela de acompanhamento de conexões está sendo preenchida. Remover as regras do iptables que usam o rastreamento de conexão resolveria o problema.

Se isso não for uma opção e você tiver RAM disponível, poderá aumentar o tamanho da tabela:

cat /proc/sys/net/netfilter/nf_conntrack_max
echo 131072 > /proc/sys/net/netfilter/nf_conntrack_max

Você provavelmente deve aumentar o hashsize também:

cat /sys/module/nf_conntrack/parameters/hashsize
echo 32768 > /sys/module/nf_conntrack/parameters/hashsize

Esses números são apenas o dobro das configurações padrão na minha área de trabalho, não sei exatamente o que você precisa. Você também vai querer adicionar isso ao sysctl.conf.

Eu seria muito cuidadoso ao usar net.ipv4.tcp_tw_recycle , o que pode causar sérios problemas com o NAT.

    
por 09.10.2013 / 04:24