davidcoles/vc5Um balanceador de carga de camada 4 com Direct Server Return, horizontalmente escalável, para Linux usando XDP/eBPF
Este README está atualmente a ser atualizado para refletir alterações recentes - algumas informações podem não refletir o código atual. Esta iteração do código ainda não está pronta para batalha - utilize uma versão v0.2 para produção
Um balanceador de carga de camada 4 (L4LB) Direct Server Return (DSR) horizontalmente escalável para Linux usando XDP/eBPF.
Se acha que isto pode ser útil ou tiver alguma questão/sugestão, sinta-se à vontade para contactar-me em [email protected] ou abra um issue no GitHub.
Agora suporta IPv6 e distribuição na camada 3 (também conhecida como tunnelling)! A biblioteca XVS foi atualizada para incluir estas funcionalidades, eliminando também a necessidade de executar health checks a partir de um network namespace, simplificando consideravelmente o código. Isto porá fim ao requisito de que todos os backends partilhem uma VLAN com o balanceador de carga.
As restrições atuais do código significam que ativar tunnelling numa
base por serviço não é suportado. Usar a opção -tunnel permite que o
tunnelling de camada 3 seja ativado globalmente usando um único esquema
(IP-in-IP, GRE, FOU ou GUE). No futuro, o código será atualizado
para permitir que o tunnelling seja configurado ao nível do serviço.
O balanceamento de carga na camada 2 continuará a ser suportado - a principal razão para iniciar o projeto foi a falta de suporte para a camada 2 suporte pelo Katran do Facebook balanceador de carga.
É incluído um ficheiro de configuração de exemplo IPv6/L3 - documentação mais completa seguirá.
O VC5 é um balanceador de carga de rede concebido para funcionar como substituto de
appliances de hardware legados. Permite que serviços com endereços IP virtuais
(VIPs) sejam distribuídos por conjuntos de servidores backend ("reais").
Os servidores reais podem executar os próprios serviços ou atuar como
proxies para outra camada de servidores (ex.: HAProxy a servir como roteador de camada 7
HTTP/offload SSL quando decisões ao nível da aplicação precisam de ser
tomadas). O único requisito é que os VIPs precisam de ser configurados num
dispositivo loopback em cada servidor real, ex.: ip addr add 192.168.101.1/32 dev lo
Os serviços e servidores reais são especificados num ficheiro de configuração, juntamente com definições de health checks. Quando os servidores backend passam nos checks e há disponibilidade suficiente para fornecer um serviço, os endereços IP virtuais são anunciados aos routers via BGP.
A distribuição de tráfego nas camadas 2 e 3 é agora suportada. A distribuição na camada 2 requer que os servidores reais partilhem uma VLAN com o balanceador de carga; ao receber um pacote a ser distribuído, o balanceador de carga atualiza os endereços de hardware ethernet no pacote para usar o endereço MAC do servidor real como destino e o seu próprio endereço MAC como origem, e encaminha o pacote através da interface apropriada, atualizando o ID da VLAN 802.1Q se os pacotes tiverem tags VLAN.
A distribuição na camada 3 requer que os pacotes sejam encapsulados num protocolo de tunneling endereçado ao IP do servidor real e encaminhados através de um router (a menos que o servidor e o balanceador de carga partilhem uma VLAN). Se, quando encapsulado, um pacote exceder o tamanho máximo de transmissão da rede então uma mensagem ICMP é enviada à origem com indicação do MTU apropriado a utilizar. Os servidores backend apenas precisam de desencapsular pacotes - tunneling bidirecional com balanceadores de carga não é necessário.
Um servidor com uma interface de rede de 10Gbit/s deverá ser capaz de suportar um serviço HTTP com largura de banda de saída superior a 100Gbit/s devido à natureza assimétrica da maior parte do tráfego de Internet. Para serviços mais pequenos, uma ou duas máquinas virtuais modestas provavelmente suportarão um serviço que gera vários gigabits/s de tráfego de saída.
Se uma instância não for suficiente, então podem ser adicionados mais servidores para escalar horizontalmente a capacidade (e fornecer redundância) usando a funcionalidade ECMP do seu router. Interfaces bonded 802.3ad e VLAN trunking 802.1Q são suportados (ver diretório examples/).
Não são necessários módulos de kernel ou configurações complexas, embora para o melhor desempenho seja recomendado um driver de placa de rede com suporte para modo nativo XDP (ex.: mlx4, mlx5, i40e, ixgbe, ixgbevf, nfp, bnxt, thunder, dpaa2, qede). Uma lista completa está disponível na página de suporte de drivers do Projeto XDP.
Para melhores resultados, deve desativar/desinstalar o irqbalance.
Terá de selecionar um IP principal para passar ao balanceador. Este é usado para o BGP router ID.
Um exemplo simples num servidor com uma única interface ethernet sem tags:
apt-get install git make libelf-dev golang-1.20 libyaml-perl libjson-perl ethtool (ou o equivalente da sua distribuição)ln -s /usr/lib/go-1.20/bin/go /usr/local/bin/go (garanta que o binário Go está no seu PATH)git clone https://github.com/davidcoles/vc5.gitcd vc5/cmdcp config.sample.yaml config.yaml (edite config.yaml de acordo com os seus requisitos)make (descarrega a biblioteca libbpf, compila o binário e o ficheiro de configuração JSON)./vc5 10.1.10.100 config.json eth0 (ajuste para usar o endereço IP e a interface ethernet do seu servidor)ip addr add 192.168.101.1/32 dev lo)É quase de certeza mais fácil usar o binário da mais recente release do Github (compilado para x86-64). Este terá sido testado em produção, pelo que deverá ser fiável. Garanta que a sua configuração é compatível com esta versão usando o script config.pl da release etiquetada (ou, claro, pode construir o seu próprio ficheiro de configuração JSON como preferir).