Balanceamento de carga sem um balanceador de carga?

Question

Eu tenho 4 servidores de imagem alimentados por nginx em seus próprios subdomínios, que os usuários acessam aleatoriamente. Eu decidi colocá-los todos por trás de um balanceador de carga HAProxy para melhorar a confiabilidade e ver as estatísticas de tráfego de um único local. Parecia um acéfalo.

Infelizmente, a mudança foi uma falha completa, já que a porta de 100 MB do balanceador de carga estava completamente saturada com todas as solicitações que passavam por ela.

Eu queria saber o que fazer sobre isso - eu poderia obter uma atualização de porta ($$) ou retornar a 4 servidores de imagem separados que são acessados aleatoriamente. Pensei em colocar o HAProxy em cada servidor de imagem que, por sua vez, encaminharia para outro servidor de imagem se o serviço nginx desse servidor estivesse com problemas.

O que você faria? Eu não gostaria de gastar muito dinheiro adicional.

    

Answer 1

O que quer que quebre seu nginx (sobrecarga, defeito de hardware) provavelmente também quebraria seu haproxy. Provavelmente funcionaria melhor para obter um IP adicional (usar como um alias na interface) para cada servidor e usá-lo como o IP (diretamente ou por meio de um nome de DNS) que você publica através de suas URLs de imagem. Construa um script que irá realocar o ip secundário para outro servidor em caso de problemas sérios. O diabo nos detalhes estará em assegurar que o IP seja seguramente tirado do outro servidor. Caso o script não consiga mais efetuar login no servidor com falha e desalocar o alias de IP, a melhor coisa a fazer é desativá-lo com segurança através do IPMI, se estiver disponível.

Como alternativa, você poderia instalar algo CGIish no quarto servidor que apenas redireciona para uma escolha aleatória de servidores disponíveis; controlar a lista de servidores para os quais ele pode redirecionar com um script de monitoramento periódico (você pode usar indevidamente nagios check_http para isso, por exemplo). Como uma extensão, esse script também pode aceitar uma lista de exclusão de outro arquivo - realmente útil se você precisar desativar um dos servidores para manutenção.

Além disso, a sugestão de usar um CDN não é tão equivocada ... se você tem tráfego de arquivo estático que satura uma linha de 100MBit, você está falando de tráfego nos terabytes para dezenas de terabytes por mês, dependendo dos padrões de uso. .

    

Answer 2

Solução 1. Monitoramento / publicidade do DNS ativo

Configure um images.domain.com com um TTL baixo (30s-ish) para anunciar seus 4 IP's:
10.1.1.1, 10.1.1.2, 10.1.1.3, 10.1.1.4

Seus servidores de nome precisam pesquisar ativamente o status http de cada IP (como você monitoraria com o balanceador de carga) e parar de anunciar um IP quando o estado estiver 'baixo'. Faça um teste completo, mas evite quaisquer serviços comuns todas as caixas (por exemplo, um único backb db). Quando um nó falha no monitor, ele deixa de ser anunciado no DNS.

As capturas, Mais solicitações de DNS devido ao baixo TTL. Failover leva "DNS TTL" segundos (e algumas pessoas gostam de desobedecer o TTL também) Seus servidores de nomes precisam estar relativamente próximos dos serviços, ou ter padrões sensíveis configurados como se houvesse uma interrupção de rede entre o NS e seus servidores de imagem.

Você também pode criar 4 nomes de domínios separados que retornam a outro ip pelo mesmo método.

Solução 2. Failover de IP

O controle de IP do rackandboneman é implementado sem muita complicação no linux com keepalived / lvs usando o protocolo VRRP . (Supondo que suas caixas estejam próximas umas das outras na rede e no linux, os sistemas operacionais são como bsd e solaris tem implementações vrrp / carp)

Com 4 caixas, você pode criar uma topologia de círculo para o failover de IP do Virutal, o que significa que você pode perder 2 caixas uma ao lado da outra, mas perder apenas 1 VIP, a caixa à esquerda do [] tem a prioridade mais alta o VIP.

         vip 1        vip 2        vip3         vip4
nodes [ 1 <-> 2 ]  [ 2 <-> 3 ]  [ 3 <-> 4 ]  [ 4 <-> 1 ]

ou 3 nós por VIP, em ordem de prioridade, configuração mais complexa, mas melhor disponibilidade.

nodes [1 - 2 - 3]  [2 - 3 - 4]  [3 - 4 - 1 ] [ 4 - 1 - 2]

Com o keepalived, eu configuraria o script do monitor para acessar o serviço http local que seu balanceador de carga faria para avaliar a integridade do servidor. Verifique também se o tráfego VRRP está usando a mesma interface do tráfego real se você tiver várias nics.