balanceador de carga http redundante

Question

Temos um cenário simples com dois servidores da Web para redundância e dimensionamento.

Mas como faço uma configuração de dois servidores web totalmente redundante? Posso pensar em duas soluções;

1. dois servidores da web, um balanceador de carga distribuindo a carga. uma máquina extra para o balanceador de carga. mas como o balanceador de carga será redundante?

2. duas máquinas, cada uma executando o servidor web E executando um balanceador de carga, distribuindo a carga. tem um ponto de entrada de DNS para ambas as máquinas. nenhuma máquina extra necessária para o balanceamento de carga.

Como vocês normalmente resolvem esse tipo de problema?

    

Answer 1

But how do I make a two web-server setup fully redundant?

Normalmente, você não faz isso. Tornar o banco de dados totalmente redundante com failover contínuo é difícil. E a redundância total requer hardware adicional, por isso muitas vezes não é implementada antes que o site cresça para ser um pouco maior.

Você deve pensar no estado da sessão - estado de login do usuário, conteúdo do carrinho de compras etc. Como isso será tratado?

Se o seu serviço for completamente sem estado (serviço de arquivo estático fx sem personalização para cada usuário), você poderá usar o DNS Round Robin para publicar 2 endereços IP para seu site, um para cada servidor.

Se você precisar de um pouco mais de controle sobre como o failover é tratado, considere 2 servidores da Web, ambos compartilhando o mesmo endereço IP por meio de Windows NLB ou no Linux usando algo como Linux-HA , Mantenha-se vivo , etc. (há várias soluções possíveis).

    

Answer 2

Se você está limitado a apenas dois servidores, pode fazer pior do que o DNS round robin com um balanceador de carga em cada máquina apontando um para o outro. Tradicionalmente, o balanceador de carga é um nível próprio em seus próprios servidores com redundância e failover próprios.

    

Answer 3

Assumindo balanceadores de carga de hardware, eles geralmente podem ser configurados em um cluster ativo / passivo para failover usando suas configurações nativas. Se você estiver usando um balanceador de carga de software (não o Microsoft NLB), procure um que seja compatível com VRRP e use o VRRP para lidar com o failover do balanceador de carga. Se você estiver usando o NLB da Microsoft, ele será executado em todas as máquinas no cluster de dimensionamento e tratará as falhas da máquina automaticamente.

    

Answer 4

link

Instale o haproxy nos dois servidores junto com o heartbeat. O Haproxy fará o balanceamento de carga para ambos os servidores Web e o heartbeat fornecerá failover sobre um ip virtual se um dos servidores falhar.

    

Answer 5

Normalmente, existem duas maneiras de implementar soluções de failover de alta disponibilidade / escalabilidade. O primeiro é usar TTLs curtos em um registro DNS round robin, em conjunto com um balanceador de carga, e o segundo é usar monitoramento de pulsação e failover de endereço IP com uma solução de hardware ou software. Algumas soluções usam uma combinação dessas duas abordagens para confiabilidade adicional.

Não está dizendo que você deve gastar dinheiro para fazer isso, mas confira as soluções ZXTM e GLB da Zeus para ter uma idéia do que é possível com uma solução comercial. Eu os usei no passado com meu próprio hardware e com bons resultados.

FWIW, você deve ser bastante confiável usando TTLs curtos em seus registros de DNS e, em seguida, apontando programaticamente o DNS em uma Webhead de backup, se perder o LB. Você pode usar um serviço como o Zerigo para fazer isso, já que eles fornecem uma API que você pode usar para alterar seus registros em tempo real. Se você deseja otimizar o custo, essa é a maneira de rolar.

Parece haver algumas soluções para fazer isso com o Linux, incluindo uma solução construída sobre o LVS: link , mas pode haver limitações sobre onde você pode implantá-lo (como não na AWS) e custos adicionais de configurá-lo, monitorá-lo e implementá-lo corretamente.