Quase não há informações sistemáticas sobre o NSX ALB em russo na rede, apenas a documentação do fornecedor em inglês. Portanto, na primeira parte, resumi fontes díspares e fiz uma visão geral do produto: falei sobre as características, arquitetura e lógica de trabalho, inclusive para sites geograficamente dispersos. Na segunda parte, descreverei como implantar e configurar o sistema. Esperamos que ambos os artigos sejam úteis para aqueles que procuram um balanceador para ambientes de nuvem e desejam avaliar rapidamente os recursos do NSX ALB.
Recursos e capacidades
NSX ALB é um balanceador de carga definido por software (SDLB) de nível corporativo. Isso não é típico de sistemas de balanceamento de carga do tipo que normalmente usa balanceadores de carga de hardware. Essa abordagem para construir o sistema dá ao NSX ALB fácil gerenciamento e escalabilidade horizontal e vertical.
Quais recursos o NSX ALB oferece:
- Controle automático de potência do balanceador. Quando a carga dos clientes aumenta, a potência é aumentada automaticamente, quando a carga diminui, ela cai.
- Balanceamento de carga em servidores dispersos geograficamente. Um mecanismo separado do Global Server Load Balancing (GSLB) é responsável por isso.
- Balanceamento em um dos níveis: L4 (sobre TCP / UDP) e L7 (sobre HTTP / HTTPS).
- . NSX ALB ( VMware) on-premise :
- Inteligência de aplicativos integrada. O sistema monitora o desempenho do aplicativo e coleta dados: tempo para cada etapa do processamento da conexão, avaliação do status do aplicativo e logs de tráfego em tempo real. Se surgir um problema, o monitoramento pode dizer rapidamente onde procurá-lo.
Os dados em tempo real são coletados em conexões abertas simultaneamente, tempo de ida e volta (RTT), rendimento, erros, atrasos de resposta, atrasos de handshake SSL, tipos de resposta e muito mais. Todas as informações em um só lugar:
No bloco Log Analytics à direita, são coletadas estatísticas sobre os principais parâmetros de conexão. Você pode passar o mouse sobre a seção desejada e familiarizar-se rapidamente.
Além disso, o NSX ALB tem:
- Suporte para multilocação para diferenciar o acesso aos recursos.
- Health Monitor .
- Web Application Firewall (WAF).
- IPAM DNS.
- , . . IP-, . : Botnet, DoS, Mobile threats, Phishing, Proxy, Scanner, Spam source, Web attacks, Windows exploit .., – .
- Analisando os cabeçalhos HTTP de pacotes de passagem. Você pode usar scripts (DataScript) baseados na linguagem Lua e definir ações Avi dependendo dos valores nestes cabeçalhos: redirecionar uma solicitação, fechar ou redefinir uma conexão, falsificar URIs ou valores em um cabeçalho HTTP, selecionar um pool de servidores específico para processar uma solicitação, trabalhar com cookies etc.
- Atuando como um controlador de entrada para Kubernetes.
O NSX ALB pode ser gerenciado por meio de GUI, CLI e API REST.
Arquitetura e esquema de trabalho NSX ALB
O NSX ALB funciona de acordo com os princípios padrão para a maioria dos SDLBs. Os servidores que fornecem o serviço de balanceamento são combinados em pools . Acima dos pools, o administrador do sistema cria serviços virtuais (VS) . Eles contêm parâmetros do serviço que está sendo balanceado, por exemplo: tipo de aplicativo, algoritmo de balanceamento, configurações de conexão. O VS também fornece aos clientes um endereço IP virtual externo (IP Virtual, VIP) para acessar o serviço balanceado.
Vamos dar uma olhada em como é a arquitetura: O
elemento-chave do sistema é o controlador (controlador Avi)... Ele é responsável pelo aumento automático de energia e controla centralmente o VS. Você pode implantar um único controlador ou um cluster de failover de controladores em sua infraestrutura.
Na configuração de failover, o cluster do controlador consiste em 3 nós. Um dos nós se torna o líder, o resto dos seguidores. Todos os 3 nós estão ativos e compartilham a carga entre si. Os principais cenários para um cluster de controladores:
- se um nó falhar, isso não afetará a operação do cluster;
- se o nó principal falhar, esta função é transferida para um dos restantes;
- se 2 nós falharem, o serviço do controlador no nó restante entra no modo somente leitura para evitar um cérebro dividido e espera que outro nó esteja disponível novamente.
Depois de implantar o controlador, o engenheiro cria um VS e um pool de servidores para cada VS. Para servidores dentro do pool, você pode escolher um algoritmo de balanceamento :
- Round Robin - a nova conexão irá para o próximo servidor no pool.
- Menos conexões - a nova conexão irá para o servidor com o menor número de conexões simultâneas.
- Menos carga - a nova conexão irá para o servidor com menos carga, independentemente do número de conexões.
- Hash consistente - novas conexões são distribuídas entre os servidores com base no hash computado. A chave para calcular o hash é especificada em um campo especial ou em uma string personalizada. Para cada solicitação, um hash é calculado usando esta chave. A conexão é enviada ao servidor correspondente ao hash computado.
- Fastest Response – .
- Fewest Tasks – ( Avi CLI REST API.
- Fewest Servers – , .
Depois de criar o VS e o pool de servidores, o próprio controlador implanta máquinas virtuais de serviço, Service Engine (SE) , nas quais o serviço balanceado está localizado. Cada serviço (VS) é distribuído em vários SEs, que processam as solicitações do cliente em paralelo. Isso garante resiliência do serviço em caso de falhas da máquina virtual.
O controlador pode avaliar a carga e adicionar novos SEs ou excluir os descarregados. Devido a essa arquitetura, o NSX ALB pode ser dimensionado tanto horizontalmente - aumentando o número de SEs, quanto verticalmente - aumentando a capacidade de cada SE.
Quanto mais serviços o SE equilibra, mais interfaces de rede são usadas. No diagrama detalhado abaixo, vemos 2 tipos de redes:
- a rede de controle e transmissão de informações de serviço forma o Plano de Controle ,
- redes de dados formam o plano de dados .
Cada SE possui uma interface de rede separada na rede de controle para comunicação com o controlador. O resto das interfaces são conectadas à rede externa e à rede onde o pool de servidores para balanceamento está localizado. Essa separação da infraestrutura de rede melhora a segurança.
Para cada VS, você precisa definir os parâmetros SE nos quais o serviço será hospedado. Esses parâmetros são definidos no Grupo SE (Grupo SE) . Ao criar o VS, selecionamos o grupo SE: você pode especificar um grupo padrão (Grupo padrão) ou criar um novo grupo se o VS precisar de configurações especiais da máquina virtual.
O grupo selecionado determinará como o novo VS será colocado. Por exemplo, se os SEs do grupo padrão já estiverem implantados no sistema e esses SEs ainda tiverem recursos, o novo VS com o grupo padrão especificado estará localizado neles. Se especificarmos um novo grupo para VS, novos SEs com parâmetros diferentes serão implantados sob ele.
No nível do grupo SE, defina as seguintes configurações de posicionamento do VS:
- número máximo de SEs em um grupo,
- número máximo de VS por SE,
- maneira de colocar VS no SE: Compacto, quando primeiro preenchemos o primeiro SE o mais firmemente possível e passamos para o próximo, ou Distribuído com uma distribuição uniforme:
- Parâmetros da máquina virtual SE: número de vCPU, memória e tamanho do disco,
A taxa de transferência por 1 vCPU é de aproximadamente 40 mil conexões / s, com uma média de 4 GB / s. Este indicador difere para diferentes níveis de balanceamento e protocolo utilizado: é mais em L4, menos em L7 devido à necessidade de analisar o tráfego, com SSL é muito menos devido à necessidade de criptografia.
- o tempo de vida de um SE não utilizado, após o qual deve ser excluído,
- recursos para hospedar SE. Em um ambiente VMware, você pode especificar ou excluir um cluster específico ou hosts e armazenamento de dados para uso.
Vamos passar para a arquitetura e o fluxo de trabalho do serviço de balanceamento global GSLB.
Arquitetura e fluxo de trabalho para servidores dispersos geograficamente
Em um serviço virtual regular, podemos adicionar servidores ao pool de apenas uma nuvem. Mesmo se adicionarmos várias nuvens ao controlador ao mesmo tempo, não seremos capazes de combinar servidores de diferentes nuvens dentro de um VS. Esta tarefa é resolvida pelo serviço de balanceamento global GSLB. Ele permite que você equilibre servidores geograficamente dispersos localizados em diferentes nuvens.
Dentro de um serviço global, você pode usar nuvens privadas e públicas ao mesmo tempo. Aqui estão os casos em que você pode precisar de um GSLB:
- alta disponibilidade de serviço se todos os servidores em uma das nuvens estiverem indisponíveis,
- recuperação de desastres se uma nuvem estiver completamente inacessível,
- , , . .
Vejamos a arquitetura do GSLB:
O esquema de trabalho em poucas palavras: o balanceamento é executado pelo serviço DNS local implantado dentro do NSX ALB. O cliente envia uma solicitação para se conectar ao serviço usando o nome FQDN. O DNS fornece ao cliente o IP virtual do VS local na nuvem ideal. O serviço escolhe a nuvem ideal com base no algoritmo de balanceamento, dados sobre a disponibilidade de VS local no Health Monitor e a localização geográfica do cliente. Você pode definir diferentes algoritmos de balanceamento - tanto no nível de serviço global quanto no nível GSLB.
Como você pode ver no diagrama GSLB, ele é baseado nos elementos do diagrama anterior: pools de servidores, acima deles serviços virtuais locais (VS) com IP virtual local (VIP) e máquinas virtuais de serviço (SE). Novos elementos aparecem ao construir o GSLB.
Serviço global (VS global) - um serviço balanceado entre servidores geograficamente dispersos ou nuvens privadas e públicas.
Um Site GSLB inclui o controlador e os SEs por ele gerenciados, localizados na mesma nuvem. Para cada site, você pode definir geolocalização em latitude e longitude. Isso permitirá que o GSLB selecione o pool de servidores com base na distância do cliente.
Os sites GSLB baseados no sistema NSX ALB são divididos em líderes (líderes) e seguidores (seguidores). Como no caso dos controladores, este esquema fornece tolerância a falhas para o serviço GSLB.
O site principal toma decisões de equilíbrio, lida com conexões e monitora. Você só pode alterar a configuração GSLB do controlador de site mestre.
Os sites escravos podem ser ativos ou passivos.
- Um site escravo passivo somente lida com conexões de clientes de entrada se o site mestre escolher seu VS local.
- O site escravo ativo recebe sua configuração do site mestre e, se travar, pode assumir o papel principal.
Os sites GSLB também podem ser sites externos construídos em balanceadores de terceiros.
O pool global é diferente do pool local, que contém servidores locais. Em um pool global, você pode combinar serviços virtuais geograficamente dispersos de diferentes locais. Em outras palavras, o pool global contém VSs locais, que são estabelecidos no nível dos sites GSLB.
O equilíbrio das conexões entre os servidores no pool global é realizado:
- pelo algoritmo Round Robin,
- por geolocalização do servidor,
- ,
- Consistent Hash.
Para um serviço global, você pode criar vários pools globais e incluir um ou mais sites em cada VS local. Neste caso, as novas conexões serão distribuídas de acordo com geolocalização ou de acordo com prioridades especificadas. Para definir prioridades para os servidores do pool, você pode definir um peso diferente para cada um.
Um exemplo de equilíbrio entre pools globais . É assim que o VS global distribuirá as conexões neste esquema: O
GslbPool_3 tem uma prioridade de 10 e será o preferido para conexões de cliente. Dessas conexões, 40% da carga irá para VS-B3 e 60% para VS-B4. Se GslbPool_3 ficar indisponível, todas as conexões do cliente irão completamente para GslbPool_2, e a carga entre VS-B3 e VS-B4 será distribuída uniformemente.
DNS localcontêm registros com nomes FQDN de serviços balanceados por meio dele.
GSLB DNS é o modo operacional DNS VS local, que é usado para balancear conexões entre sites GSLB.
O VS de DNS local começa a agir como GSLB DNS quando o selecionamos como o serviço DNS para um GSLB elevado. Esse VS de DNS deve ser implantado em todos os sites incluídos em pools globais.
O GSLB adiciona registros FQDN de serviço global a cada DNS local. O NSX ALB preenche esse registro com os IPs virtuais do VS local de todos os sites incluídos no pool global de VS. Esses VIPs adicionais são adicionados automaticamente com novos VSs locais adicionados ao pool. Os dados dos registros são atualizados à medida que se acumulam informações sobre a carga do serviço, a disponibilidade de servidores e o afastamento dos clientes dos sites. Quando um novo cliente se conecta usando o FQDN, um dos DNS locais emite o endereço VIP do VS local, levando em consideração esses dados reais acumulados.
Como implantar e configurar o sistema NSX ALB, bem como aumentar o serviço GSLB nele, descreverei na segunda parte deste artigo.