Pergunta

Estamos lutando com HAProxy por alguns dias agora na Amazon EC2; a experiência até agora tem sido ótimo, mas nós estamos presos em espremer mais desempenho fora do balanceador de carga de software. Nós não estamos exatamente Linux whizzes rede (nós somos uma loja NET, normalmente), mas nós temos até agora realizada nossa própria, tentar definir ulimits adequadas, inspecionando mensagens do kernel e tcpdumps por qualquer irregularidade. Até agora, porém, chegamos a um patamar de cerca de 1.700 pedidos / seg, em que o tempo limite do cliente ponto abundam (esteve usando e ajustes httperf para esta finalidade). Um colega de trabalho e eu estava ouvindo o mais recente podcast de estouro de pilha, em que os fundadores do Reddit, note que toda a sua site funciona fora de um nó HAProxy, e que até agora não se tornou um gargalo. Ack! Ou há alguma maneira de não ver que muitas solicitações simultâneas, estamos fazendo algo terrivelmente errado, ou a natureza compartilhada do EC2 está limitando a pilha de rede da instância EC2 (estamos usando um grande tipo de instância). Considerando o fato de que tanto Joel e os fundadores do Reddit concordam que a rede provavelmente será o fator limitante, é possível que é a limitação que estamos vendo?

Todos os pensamentos são muito apreciados!

Editar Parece que o problema real não era, de fato, com o nó do balanceador de carga! O culpado foi, na verdade os nós que executam httperf, neste caso. Como httperf constrói e destrói uma tomada para cada solicitação, ele gasta uma boa quantidade de tempo de CPU no kernel. Como nós batemos a taxa de solicitação superior, o TCP FIN TTL (sendo 60 por padrão) estava mantendo soquetes torno de muito tempo, e padrão do ip_local_port_range era demasiado baixo para este cenário de uso. Basicamente, após alguns minutos do cliente (httperf) nó constantemente criar e destruir novas tomadas, o número de portas não utilizadas ran, e «solicitações dos subsequentes errored-out, nesta fase, obtendo-se Pedido de números baixos / seg e uma grande quantidade de erros.

Nós também tinha olhado para nginx, mas Nós estamos trabalhando com RighScale, e eles têm drop-in scripts para HAProxy. Oh, e nós temos muito apertado um prazo [naturalmente] para mudar para fora componentes a menos que prove absolutamente necessário. Misericordiosamente, sendo em AWS nos permite testar uma outra configuração usando nginx em paralelo (se autorizado), e fazer a troca durante a noite mais tarde.

Esta página descreve cada uma das variáveis ??do sysctl razoavelmente bem (ip_local_port_range e tcp_fin_timeout estavam sintonizados, neste caso).

Foi útil?

Solução

Não é realmente uma resposta à sua pergunta, mas nginx e libra ambos têm boa reputação como balanceadores de carga. Wordpress apenas mudou para nginx com bons resultados.

Mas, mais especificamente, para depurar o problema. Se você não está vendo o uso de CPU de 100% (incluindo I / O de espera), então você está de rede ligada, sim. EC2 internamente usa uma rede gigabit, tente usar uma instância XL, então você tem o hardware subjacente para si mesmo, e não tem que compartilhar essa porta de rede gigabit.

Outras dicas

Não responder a pergunta diretamente, mas EC2 agora suporta o balanceamento de carga através Elastic Load Balancing em vez de correr seu próprio balanceador de carga em uma instância EC2.

EDIT: serviço de DNS Route 53 da Amazon agora oferece uma maneira de apontar um domínio de nível superior em um ELB com um registro "Alias". Desde Amazon sabe o endereço IP atual do ELB, ele pode retornar um registro para esse IP atual ao invés de ter que usar um registro CNAME, enquanto continuam a ser livres para mudar o IP de tempos em tempos.

Sim, Você poderia usar um balanceador de carga fora do local .. e em bare metal LVS é uma ótima escolha, mas sua latência vai ser horrível! Há rumores de que a Amazon está indo para corrigir o problema CNAME. No entanto, eles não são susceptíveis de adicionar https, em profundidade ou de saúde personalizado cheques, agentes de feedback, correspondência url, inserção cookie (e algumas pessoas com boa arquitetura diria muito bem também.) No entanto é por isso que Scalr, RightScale e outros estão usando HAProxy geralmente dois -los para trás uma entrada robin DNS round. Aqui no Loadbalancer.org estamos prestes a lançar nosso próprio appaliance carga EC2 equilíbrio: http: // blog. loadbalancer.org/ec2-load-balancer-appliance-rocks-and-its-free-for-now-anyway/ Estamos pensando em usar scripts de SSH para intergrate com autoscaling da mesma forma RightScale faz, quaisquer comentários apreciado no blog. Graças

Eu olhava para a mudança para um off-site do balanceador de carga, não no algo nuvem e correr como IPVS em cima dela. [A razão por que seria fora da nuvem da Amazon é por causa de coisas do kernel] Se a Amazon não limita o IP de origem dos pacotes que saem do que você poderia ir com um mecanismo de balanceamento de carga unidirecional. Fazemos algo assim, e ele nos recebe cerca de 800.000 solicitações simultâneas [embora não lidar com latência]. Eu também diria uso "Ab2" (apache banco), uma vez que é um pouco mais fácil de usar, e fácil de usar na minha humilde opinião.

Mesmo que o seu problema resolvido. KEMP Technologies têm agora um balanceador de carga totalmente soprado para AWS. Pode poupar algum aborrecimento.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top