A AVI Networks, empresa americana, foi fundada em 2012, e tem no balanceamento de carga sua principal solução. Em 2019 foi adquirida pela VMware e tem se popularizado (sendo que o produto agora é chamado de NSX Advanced Load Balancer).
O principal diferencial da solução AVI é trabalhar nativamente no conceito SDN – Software Defined Network, diferente dos fabricantes tradicionais de balanceadores. Toda a solução AVI é baseada em software, podendo trabalhar on-premises ou em clouds (privadas e públicas).
Também é importante notar que a mesma Controller pode gerenciar Services Engines distribuídos em múltiplas clouds.
Componentes da solução
A solução conta com plano de controle e com plano de dados separados, conforme conceito SDN.
-
AVI Controller: Responsável pelo plano de controle, faz a função de Controller e também de Management. É o cérebro da solução, sendo implementada como appliance virtual standalone (1) ou redundante (3 neste caso). Utiliza API para comunicação e visibilidade das aplicações. Quando no modo “write” é capaz de provisionar automaticamente novos Services Engines. Prove a console para configuração e monitoramento da solução, com Insights e APIs para integração com outras soluções.
-
AVI Service Engine: São appliances virtuais, responsáveis pelo plano de dados. Nestes appliances criamos os “Virtual Services”, que são de fato os balanceadores. Um Service Engine pode ter um ou mais Virtual Service. Além do papel de Load Balancing, podemos ter Global Load Balancing e Web Application Firewall. Podemos ter redundância de SE (Ativo/Backup ou Ativo-Ativo, com Virtual Services distribuídos nos SEs).
-
Virtual Service: Aplicação criada no Service Engine responsável pelo balanceamento de carga. As configurações que o “cliente vê” (VIP por exemplo) estão no Virtual Service.
-
Cloud, SE Group e Folder: Cloud é o local onde o Service Engine vai ser instalado (não precisa ser literalmente uma cloud). SE Group, como o nome sugere, nos permite criar grupos de Service Engines, dentro de uma mesma Cloud, e define um domínio de falha. Escalonamento, failover e dados de sessão são sincronizados dentro do mesmo grupo. E Folder é um agrupamento dentro do SE Group, para organização.
-
Pool: Onde criamos a lista de servidores/aplicações que serão balanceadas.
Redundância de Controllers
Quando trabalhamos com 3 Controllers todas ficam ativas (uma como Leader e as demais Followers), e elas compartilham a carga (Virtual Services são distribuídos entre as Controllers).
A gerência da solução pode ser feita a partir de qualquer Controller e não apenas na Leader. E como solução SDN, a queda de uma Controller não afeta o processamento do tráfego, que é feito pelos Service Engines.
Se duas Controllers ficarem indisponíveis a controladora restante precisa ser manualmente promovida a “líder”, não impactando no balanceamento de carga. E mesmo se as 3 controladoras ficarem indisponíveis, o tráfego não é impactado nos balanceadores. No entanto, neste momento, não seria possível fazer alterações na configuração.
Data Plane Scaling
Uma característica bastante interessante da solução é a facilidade de crescimento.
Podemos criar novos Virtual Services em um mesmo Service Engine, e se necessário adicionar mais CPU e memória no SE (necessário reiniciar), ou então criar novos Service Engines (pode ser feito automaticamente pela Controller), e distribuir a carga usando BGP ou modo nativo.
No modo nativo a Controller cria um novo Service Engine, e o SE existente (primário) recebe todo o tráfego e redireciona parte para o novo SE.
Mais detalhes sobre a solução nos links abaixo:
Até a próxima.
About The Author
Ótimo material! Seria bem legal se aprofundar mais no tema.