Quando você exaure uma conexão de 1 Gpbs ao seu haproxy principal, como você expande a escala?

Question

Se você esgotar sua conexão de rede pública (digamos, 1 Gbps) com seu servidor haproxy que envia solicitações para seus servidores de back-end, quais opções você precisa dimensionar?

Como todo o tráfego de solicitações flui através do haproxy, como você pode escalar essa configuração se não tiver nenhuma largura de banda em sua porta?

    

Answer 1

Você adiciona outra porta.

Diga que sua rede existente se parece com um endereço IP público na frente de uma caixa HAProxy na frente dos N servidores de back-end. Você percorre (ou melhor ainda aborda a execução de 1 Gbps) de taxa de transferência, mas seus servidores de back-end ainda estão satisfeitos com recursos extras.

O próximo passo é obter um segundo endereço IP público e outra máquina HAProxy em seu cluster. Adicione um Balanceamento de carga do servidor global na frente para enviar tráfego em algumas configurações configuráveis caminho para cada um dos seus dois front-end caixas HAProxy.

Fizemos isso gerenciando nossos próprios Ketama Hash com base no servidor DNS de energia . Existem também respostas de serviços DNS que fornecem DNS programável com base na localização geográfica ou outros critérios.

    

Answer 2

Assumindo que você não tem meios para obter um uplink mais rápido ou dimensionar o dispositivo HAProxy existente, dimensione para vários.

Você pode dividir a carga entre eles de algumas maneiras diferentes:

1. round robin de DNS. Isso envolve apenas adicionar registros A extras ao nome DNS existente e, esperamos, dividir a solicitação de maneira quase uniforme em torno dos membros do registro A .
2. Resposta DNS seletiva. Responde a diferentes solicitações de DNS com respostas diferentes dependendo dos critérios - pode simplesmente impor a distribuição round-robin ou, se seu aplicativo puder ser dimensionado para novos locais de forma eficaz, pode responder a consultas com a instância mais próxima disponível do aplicativo para um determinado cliente (DNS geograficamente ciente).
3. BGP Anycast. Geralmente considerada "não é uma boa idéia" para comunicações com reconhecimento de sessão, pois as alterações de topologia podem interromper as sessões TCP, esse seria outro método de direcionar o tráfego para uma implantação do aplicativo próxima do usuário de uma perspectiva de topologia da Internet.