Na última vez, falamos sobre as capacidades do NSX Edge em relação ao roteamento estático e dinâmico, e hoje vamos nos aprofundar no balanceador de carga.
Antes de começarmos a configuração, gostaria de relembrar brevemente os principais tipos de balanceamento.
Teoria
Atualmente, as soluções de balanceamento de carga costumam ser divididas em duas categorias: balanceamento de nível quatro (transporte) e nível sete (aplicação) do modelo . O modelo OSI não é o melhor ponto de referência para descrever os métodos de balanceamento. Por exemplo, se um balanceador L4 também suporta término de TLS, ele se torna, nesse caso, um balanceador L7? Mas o que está feito, está feito.
- Balanceador L4 normalmente consiste em um proxy intermediário entre o cliente e um conjunto de backends disponíveis, que termina conexões TCP (isto é, responde ao SYN por conta própria), seleciona um backend e inicia uma nova sessão TCP em sua direção, enviando um SYN. Este tipo é um dos básicos, mas outras opções são possíveis.
- Balanceador L7 distribui o tráfego entre os backends disponíveis de maneira mais 'sofisticada' do que o balanceador L4. Ele pode tomar decisões sobre a seleção do backend com base, por exemplo, no conteúdo da mensagem HTTP (URL, cookie, etc.).
Independentemente do tipo, o balanceador pode suportar as seguintes funções:
- Descoberta de serviços – o processo de determinação do conjunto de backends disponíveis (Estático, DNS, Consul, Etcd, etc.).
- Verificação de saúde dos backends descobertos (ping ativo do backend via requisição HTTP, detecção passiva de problemas em conexões TCP, presença de múltiplos 503 HTTP codes nas respostas, etc.).
- O próprio balanceamento (round robin, seleção aleatória, hash de IP de origem, URI).
- Término de TLS e verificação de certificados.
- Opções relacionadas à segurança (autenticação, prevenção de ataques DoS, limitação de taxa) e muito mais.
O NSX Edge oferece suporte a dois modos de implementação do balanceador:
Modo proxy, ou one-arm. Neste modo, o NSX Edge usa seu próprio endereço IP como endereço de origem ao enviar uma solicitação para um dos backends. Assim, o balanceador de carga desempenha simultaneamente as funções de Source e Destination NAT. O backend vê todo o tráfego como enviado pelo balanceador de carga e responde diretamente a ele. Nesse esquema, o balanceador deve estar na mesma segmentação de rede que os servidores internos.
Veja como isso acontece:
1. O usuário envia uma solicitação para o endereço VIP (endereço do balanceador), que está configurado no Edge.
2. O Edge seleciona um dos backends e executa o destination NAT, substituindo o endereço VIP pelo endereço do backend selecionado.
3. O Edge realiza o source NAT, substituindo o endereço do usuário que fez a solicitação pelo seu próprio.
4. O pacote é enviado para o backend selecionado.
5. O backend responde não diretamente ao usuário, mas ao Edge, já que o endereço original do usuário foi alterado para o endereço do balanceador.
6. O Edge transmite a resposta do servidor para o usuário.
O diagrama abaixo.
Modo transparente, ou inline. Neste cenário, o balanceador de carga possui interfaces na rede interna e externa. Nesse caso, não há acesso direto à rede interna a partir da externa. O balanceador de carga integrado atua como um gateway NAT para as máquinas virtuais na rede interna.
O mecanismo é o seguinte:
1. O usuário envia uma solicitação para o endereço VIP (endereço do balanceador), que está configurado no Edge.
2. O Edge seleciona um dos backends e executa o destination NAT, substituindo o endereço VIP pelo endereço do backend selecionado.
3. O pacote é enviado para o backend selecionado.
4. O backend recebe a solicitação com o endereço original do usuário (source NAT não foi realizado) e responde diretamente a ele.
5. O tráfego é novamente recebido pelo balanceador de carga, já que na configuração inline, ele geralmente atua como o gateway padrão para o farm de servidores.
6. O Edge executa o source NAT para enviar o tráfego ao usuário, utilizando seu VIP como endereço IP de origem.
O diagrama abaixo.
Prática
No meu ambiente de teste, configurei 3 servidores com Apache, que está configurado para operar via HTTPS. O Edge realizará o balanceamento das solicitações HTTPS pelo método round robin, proxyando cada nova solicitação para um novo servidor.
Vamos começar.
Gerando um certificado SSL que será utilizado pelo NSX Edge.
Você pode importar um certificado CA válido ou usar um autoassinado. Neste teste, vou utilizar um autoassinado.
- Na interface do vCloud Director, vamos para as configurações dos serviços Edge.
- Vamos para a guia Certificados. No menu de ações, escolhemos adicionar um novo CSR.
- Preencha os campos necessários e clique em Keep.
- Selecione o CSR recém-criado e escolha a opção self-sign CSR.
- Escolha o período de validade do certificado e clique em Keep.
- O certificado autoassinado apareceu na lista de disponíveis.
Configure o Perfil da Aplicação.
Os perfis da aplicação oferecem um controle mais completo sobre o tráfego de rede e tornam a gestão dele simples e eficaz. Com eles, é possível definir o comportamento para tipos específicos de tráfego.
- Vá até a aba Load Balancer e ative o balanceador. A opção Acceleration enabled permite que o balanceador utilize um balanceamento L4 mais rápido em vez do L7.
- Acesse a aba Application profile para definir o perfil da aplicação. Clique em +.
- Defina o nome do perfil e escolha o tipo de tráfego para o qual o perfil será aplicado. Vou explicar alguns parâmetros.
Persistência – mantém e rastreia os dados da sessão, como por exemplo: qual servidor específico do pool atende à solicitação do usuário. Isso garante que as solicitações do usuário sejam direcionadas ao mesmo membro do pool durante a duração da sessão ou em sessões subsequentes.
Habilitar SSL passthrough – ao escolher esta opção, o NSX Edge deixa de terminar o SSL. Em vez disso, a terminação acontece diretamente nos servidores que estão sendo balanceados.
Inserir cabeçalho HTTP X-Forwarded-For – permite identificar o IP de origem do cliente que se conecta ao servidor web através do balanceador.
Habilitar SSL do lado do Pool – permite especificar que o pool selecionado consiste em servidores HTTPS.
- Como estarei balanceando o tráfego HTTPS, preciso habilitar o SSL do lado do Pool e escolher o certificado gerado anteriormente na aba Virtual Server Certificates → Service Certificate.
- Da mesma forma para Pool Certificates → Service Certificate.
Criar um pool de servidores cujo tráfego será balanceado Pools
- Vá até a aba Pools. Clique em +.
- Defina o nome do pool, escolha o algoritmo (usarei round robin) e tipo de monitoramento para o health check do backend. A opção Transparent indica se os IPs de origem dos clientes são visíveis para os servidores internos.
- Se a opção estiver desligada, o tráfego para os servidores internos vem do IP de origem do balanceador.
- Se a opção estiver ativada, os servidores internos veem os IPs de origem dos clientes. Nessa configuração, o NSX Edge deve atuar como o gateway padrão, garantindo que os pacotes retornados passem pelo NSX Edge.
NSX suporta os seguintes algoritmos de balanceamento:
- IP_HASH – seleção do servidor com base nos resultados da função hash para o IP de origem e destino de cada pacote.
- LEASTCONN – balanceamento de conexões de entrada, dependendo da quantidade já existente em um servidor específico. Novas conexões serão direcionadas para o servidor com o menor número de conexões.
- ROUND_ROBIN – novas conexões são enviadas a cada servidor em sequência, de acordo com o peso atribuído a ele.
- URI – a parte esquerda da URI (antes do ponto de interrogação) é hashada e dividida pelo peso total dos servidores no pool. O resultado indica qual servidor recebe a solicitação, garantindo que a solicitação sempre seja direcionada ao mesmo servidor, enquanto todos os servidores permanecerem disponíveis.
- HTTPHEADER – balanceamento com base em um cabeçalho HTTP específico que pode ser indicado como um parâmetro. Se o cabeçalho estiver ausente ou não tiver valor, aplica-se o algoritmo ROUND_ROBIN.
- URL – em cada solicitação HTTP GET, realiza-se a busca pelo parâmetro URL especificado como argumento. Se o parâmetro for seguido por um sinal de igual e um valor, este valor é hashado e dividido pelo peso total dos servidores em execução. O resultado indica qual servidor recebe a solicitação. Este processo é usado para rastrear identificadores de usuários nas solicitações e garantir que o mesmo user id seja sempre enviado ao mesmo servidor, enquanto todos os servidores permanecerem disponíveis.
- No bloco Members, clicamos em + para adicionar servidores ao pool.
Aqui é necessário especificar:- o nome do servidor;
- o endereço IP do servidor;
- a porta na qual o servidor receberá o tráfego;
- a porta para verificação de saúde (Monitor healthcheck);
- peso (Weight) – com este parâmetro, é possível regular a quantidade proporcional de tráfego recebido para um membro específico do pool;
- Max Connections – o número máximo de conexões para o servidor;
- Min Connections – o número mínimo de conexões que o servidor deve processar antes que o tráfego seja redirecionado para o próximo membro do pool.
Assim fica o pool final com três servidores.
Adicionamos o Servidor Virtual
- Vamos para a aba Servidores Virtuais. Clicamos em +.
- Ativamos o servidor virtual com o Enable Virtual Server.
Atribuímos um nome, escolhemos o Application Profile criado anteriormente, o Pool e indicamos o endereço IP para o qual o Servidor Virtual aceitará solicitações externas. Selecionamos o protocolo HTTPS e a porta 443.
Os parâmetros opcionais aqui:
Limite de Conexão – o número máximo de conexões simultâneas que o servidor virtual pode processar;
Limite de Taxa de Conexão (CPS) – o número máximo de novas solicitações de entrada por segundo.
Com isso, a configuração do balanceador é concluída, podendo-se verificar sua funcionalidade. Os servidores têm uma configuração simples que permite entender qual servidor do pool processou a solicitação. Durante a configuração, escolhemos o algoritmo de balanceamento Round Robin, e o parâmetro Weight para cada servidor é igual a um, portanto, cada nova solicitação será processada pelo próximo servidor do pool.
Digitamos o endereço externo do balanceador no navegador e vemos:
Após atualizar a página, a solicitação será processada pelo próximo servidor:
E mais uma vez – para verificar o terceiro servidor do pool:
Na verificação, podemos ver que o certificado enviado pelo Edge é o mesmo que geramos no início.
Verificação do status do balanceador a partir do console do Edge gateway. Para isso, digite show service loadbalancer pool.
Configuramos o Service Monitor para verificar o estado dos servidores no pool
Com o Service Monitor, podemos monitorar o estado dos servidores no pool de backend. Se a resposta à solicitação não corresponder ao esperado, o servidor pode ser removido do pool para que não receba novas solicitações.
Por padrão, foram configurados três métodos de verificação:
- TCP-monitor,
- HTTP-monitor,
- HTTPS-monitor.
Vamos criar um novo.
- Vamos para a aba de Service Monitoring e clicamos em +.
- Escolhemos:
- um nome para o novo método;
- o intervalo em que as solicitações serão enviadas,
- o tempo limite para a espera da resposta,
- o tipo de monitoramento – solicitação HTTPS utilizando o método GET, o código de status esperado – 200(OK) e a URL da solicitação.
- Com isso, a configuração do novo Service Monitor está finalizada, agora podemos utilizá-lo ao criar um pool.
Configuramos as Regras de Aplicação
As Regras de Aplicação são uma forma de manipular o tráfego baseado em certos gatilhos. Com esta ferramenta, podemos criar regras avançadas de balanceamento de carga, cuja configuração pode não ser possível através de Application profiles ou com outros serviços disponíveis no Edge Gateway.
- Para criar uma regra, vamos para a aba Regras de Aplicação do balanceador.
- Selecionamos um nome, o script que usará a regra e clicamos em Manter.
- Depois que a regra for criada, precisamos editar o Servidor Virtual já configurado.
- Na aba Avançado, adicionamos a regra que criamos.
No exemplo acima, ativamos o suporte ao tlsv1.
Mais alguns exemplos:
Redirecionar o tráfego para outro pool.
Com este script, podemos redirecionar o tráfego para outro pool de balanceamento, se o pool principal não estiver funcionando. Para que a regra funcione, devem haver vários pools configurados no balanceador, e todos os membros do pool principal devem estar em estado down. Deve-se especificar exatamente o nome do pool, e não seu ID.
acl pool_down nbsrv(PRIMARY_POOL_NAME) eq 0
use_backend SECONDARY_POOL_NAME if PRIMARY_POOL_NAME
Redirecionar o tráfego para um recurso externo.
Aqui, redirecionamos o tráfego para um site externo, se todos os membros do pool principal estiverem em estado down.
acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down
Ainda mais exemplos .
Isso é tudo sobre o balanceador. Se você tiver alguma dúvida, pergunte, estou à disposição para responder.
Fonte: habr.com
