Na semana passada, os desenvolvedores do GitHub
fizeram o upload do código-fonte do seu balanceador de carga - GLB Director. A equipe trabalhou neste projeto por vários anos.
O que é notável é a sua decisão, como é organizada e quem mais transferiu os sistemas de balanceamento de carga para o código aberto, informamos mais adiante.
/ Flickr / theilr / ccPor que o GitHub possui um balanceador
O GitHub usa a infraestrutura de nuvem
bare metal para aumentar a produtividade. Nesse caso, o software funciona sem níveis adicionais de virtualização no bare metal.
Anteriormente, a empresa usava o
haproxy com uma configuração de hardware especial para fornecer balanceamento de carga, o que fornecia tolerância a falhas para conexões Ethernet de 10 gigabits. No entanto, essa abordagem não foi bem dimensionada (escala vertical implícita) e o GitHub decidiu criar seu próprio balanceador de carga, que ainda poderia funcionar em hardware de baixo custo.
O que pode e como o GLB Director
O balanceador do GitHub garante conexões TCP ininterruptas, gerencia a carga de serviços individuais, é resistente a ataques DDoS e pode ser dimensionado horizontalmente. Ele é "
aprisionado " para trabalhos em data centers, onde um grande número de servidores anuncia um único endereço IP via
BGP e os roteadores usam a estratégia
ECMP .
O balanceamento de carga
é realizado nos níveis L4 e L7. Diferentemente de soluções como
LVS , o GLB Director não direciona todos os pacotes para um nó do diretor para redistribuí-los entre outros nós. Em vez disso, ele
usa uma variação de hash
HRW (rendezvous hashing) para criar uma tabela estática para selecionar um par de servidores proxy (primário e secundário) para cada conexão de entrada. Se um deles falhar, o pacote será enviado para o segundo. O sistema lembra essa opção e não precisa ser feita para cada pacote.
A "integridade" dos servidores é monitorada pela solução glb-healthcheck, que alterna os sistemas primário e secundário em caso de problemas. O glb-healthcheck
monitora a operação correta de cada túnel
GUE (encapsulamento genérico UDP) e uma porta HTTP arbitrária dos servidores back-end.
O GLB também usa o sistema
Netfilter e o utilitário
iptables . O Netfilter resolve uma tarefa simples: determina se o pacote TCP / IP interno em cada pacote GUE está em conformidade com a pilha TCP do kernel Linux. Caso contrário, ele redireciona o pacote para o servidor proxy secundário, em vez de decapsulá-lo localmente.
O diagrama de interação dos componentes é semelhante a este:
O GitHub
espera que seu balanceador seja útil para todas as empresas que possuem seus próprios data centers.
Como instalar o GLB e começar a trabalhar com ele pode ser encontrado no
guia de início rápido preparado pelos desenvolvedores .
Desenvolvimentos semelhantes
Em maio, o Facebook também
compartilhou o código-fonte da sua biblioteca de balanceadores de carga Katran. A gigante de TI o
utiliza para distribuir com eficiência a carga entre os servidores back-end.
O balanceador anterior da empresa - L4LB - não conseguiu lidar com a tarefa, pois exigia servidores dedicados ao trabalho, o que aumentava a carga na rede. Para resolver esse problema, a empresa desenvolveu o Katran. É lançado usando a estrutura do eXpress Data Path e a máquina virtual eBPF. A VM estende a funcionalidade geral executando programas em pontos individuais no kernel do Linux.
/ Flickr / da sal / ccO balanceador atualizado
distribui com mais eficiência
a carga na infraestrutura e aumenta a velocidade do processamento de pacotes. Desenvolvedores de código-fonte
"carregados" no GitHub.
O sistema Katran
tem várias diferenças em relação à solução proposta no GitHub. Por exemplo, o Facebook usa túneis XDP e IPIP que funcionam com o kernel do Linux. O GLB, por outro lado, recorreu à ajuda do DPDK para processar pacotes a partir do espaço do usuário.
Theo Julienne, o desenvolvedor do GitHub,
acrescentou que o
DPDK permite lidar com grandes volumes de tráfego de entrada. Isso garante alto desempenho (conexão de 10 gigabits), mesmo em ambientes de trabalho complexos e fornece alguma proteção contra ataques DDoS.
A transferência de ferramentas poderosas como GLB e Katran para código aberto abrirá novas oportunidades para outras empresas de TI e contribuirá para o desenvolvimento mais rápido do ecossistema de TI no mundo.
PS Alguns artigos adicionais do First Corporate IaaS Blog: