Maximizar as conexões TCP no balanceador de carga HAProxy

Question

No momento, estou usando o HAProxy para fazer o balanceamento de carga de conexões tcp de clientes para o meu servidor de aplicativos Erlang. A conexão é persistente, o que significa que estou limitado a aproximadamente 64 K clientes em um servidor otimizado (atualmente estou executando o HAProxy em uma instância m1.large EC2). Meu servidor de aplicativos foi projetado para dimensionar horizontalmente com base no número de conexões TCP. O que me preocupa é que precisarei de um número igual de servidores HAProxy como servidores de aplicativos, já que é uma conexão 1: 1. Existe atualmente uma maneira de "proxy" a conexão tcp para o servidor de aplicativos para que, uma vez que o HAProxy envie o cliente para o meu servidor Erlang, ele possa liberar a conexão, pronto para servir outro cliente? Há algum documento, soluções existentes por aí que eu possa ler, para que eu tenha que me preocupar apenas com o limite de 64K em meus servidores de aplicativos, e não nos próprios servidores de balanceamento de carga?

    

Answer 1

O que faz você pensar que está limitado a clientes de 64K? Você deve ser capaz de servir mais do que isso. Não é a contagem de portas que é o fator limitante, mas a capacidade de memória e CPU que limita a quantidade de conexões que você pode abrir a qualquer momento. Verifique: link que é datado, pense nisso como um problema c100k ou c1M. : -)

A propósito, o site haproxy tem um excelente artigo sobre o balanceamento de carga e a arquitetura do haproxy: link

Em relação ao limite de conexão, esse é um limite teórico que normalmente você não alcançaria, já que ficaria sem recursos antes disso.

Citação link

"O padrão TCP configura identificadores de conexão exclusivos como a tupla de endereço IP local, número de porta TCP local, endereço IP remoto e número de porta TCP remoto. No seu exemplo, os números locais são fixos, o que deixa aproximadamente 2 ^ 32 endereços remotos de IP (versão 4) e 2 ^ 16 números de portas TCP ou um potencial total aproximado de conexões TCP simultâneas de 281.474.976.710.656 (2 ^ 48 ou 2,81 * 10 ^ 14 ou 281 trilhões). "

    

Answer 2

Introdução

64k conexões IDLE concorrentes são amendoins para HAProxy e Erlang.

A primeira coisa a fazer é ativar a página de estatísticas no HAProxy . É obrigatório ter um monitoramento e ajuste de desempenho.

Então vamos entrar em limites.

O limite de conexão do SO

Só pode haver 1 conexão por tupla client_IP:client_PORT:server_IP:server_PORT . Ele vem da maneira como as conexões são armazenadas e recuperadas no kernel (ou seja, hashtable). O mesmo no Linux e no Windows.

Eu terei que discordar do aseq sobre isso. NÃO é um limite teórico. É um limite muito prático, provavelmente atingido por qualquer pessoa que esteja fazendo testes de carga moderados.

Suponhamos que há três computadores na configuração atual:

        [Test Computer]     [HAProxy Computer]     [Erlang Computer]

(front)   test_IP:????<------>haproxy_IP:80                      
(back)                        haproxy_IP:????<------>erlang_IP:80

Todo o IP é fixo e a porta do servidor web é fixa. Isso deixa apenas uma porta como parâmetro variável, portanto, a quantidade máxima de conexões é limitada pela quantidade de portas disponíveis em qualquer computador. Há pouco espaço para a cabeça aqui (veja Intervalo de Portos Efêmeros). Você precisa obter mais instâncias, instâncias Erlang e instâncias de teste de carga.

Observação : observe que os usuários vêm de muitos IPs naturalmente, enquanto os testadores de carga (curl, Apache ab, JMeter) geralmente são executados em uma única caixa com um único IP (o JMeter e ferramentas semelhantes podem ser dimensionados usando escravos distribuídos).

Observação : conexões HAProxy estão sempre em pares (uma para o cliente + uma para o servidor interno). Tenha isso em mente, porque a maioria dos limites do sistema deve ser 2 * N para permitir N usuários.

Intervalo de Portas Efêmeras

Apenas algumas portas são usadas para criar novas conexões. Eles são chamados ephemeral ports . O padrão do Linux é de 32768 a 61000.

Estenda o intervalo. Verifique primeiro se há algum serviço em execução usando-os em seus servidores.

sysctl net.ipv4.ip_local_port_range
net.ipv4.ip_local_port_range = 20000    65000

Esse ajuste só pode fornecer mais 60% de portas. Não será o suficiente para usar a web scale em um único servidor.

Porta de curta duração

Esteja ciente de que uma porta não pode ser reutilizada por um minuto inteiro depois de ser fechada (consulte Estados TCP), o que pode tornar o pool de portas bastante pequeno (por exemplo, 10k port / s qualquer pessoa?). Existem configurações de kernel para alterar a duração do fechamento e permitir a reutilização de portas de fechamento.

Você não precisará desses ajustes para conexões persistentes, na medida em que eles viverem o suficiente (alguns minutos antes de renovar pelo menos). É importante estar ciente do possível problema, no entanto.

HAProxy maxconn

Configure a configuração maxconn no HAProxy. É a quantidade máxima de conexões abertas permitidas a qualquer momento.

Ele pode ser configurado em global , por frontend ou por backend . A página de estatísticas mostra qual é a configuração ativa para cada um e tudo.

Ulimit do Linux

O ulimit é a quantidade máxima de arquivos abertos por um único processo (soquetes são arquivos no linux). O padrão do Linux está em algum lugar entre 1k e 10k.

O HAProxy configura automaticamente seu ulimit de processo com base no parâmetro maxconn .

Você provavelmente precisará ajustar o ulimit manualmente para o processo Erlang.

    

Answer 3

Acho que a melhor maneira de responder à sua pergunta é apontar que você não deve precisar de um mapeamento 1: 1 entre o HAProxy e seus servidores de aplicativos. Uma conexão persistente é possível com o HAProxy através de vários métodos. Eu sugeriria pesquisar na documentação por "persistente" para saber mais: link .

Por exemplo, com apenas conexões TCP, adicionar fonte de saldo à sua configuração deve fornecer persistência para você.

    

Answer 4

64k por host é um limite rígido definido, mas o appserver que o manipula normalmente fica sem memória antes disso. Geralmente, os appservers Java são executados em 2000 conexões simultâneas antes que a VM de 32 bits fique sem heap.