Da última vez falamos sobre os recursos do NSX Edge em termos de roteamento estático e dinâmico, e hoje trataremos do balanceador de carga.
Antes de prosseguirmos com a configuração, gostaria de lembrá-lo brevemente sobre os principais tipos de balanceamento.
Теория
Todas as soluções atuais de balanceamento de carga útil são frequentemente divididas em duas categorias: balanceamento no quarto (transporte) e no sétimo (aplicativo) níveis do modelo. . O modelo OSI não é o melhor ponto de referência para descrever métodos de balanceamento. Por exemplo, se um balanceador L4 também suportar terminação TLS, ele se tornará um balanceador L7? Mas é o que é.
- Balanceador L4 na maioria das vezes, é um proxy intermediário entre o cliente e um conjunto de back-ends disponíveis, que encerra conexões TCP (ou seja, responde independentemente ao SYN), seleciona um back-end e inicia uma nova sessão TCP em sua direção, enviando SYN de forma independente. Este tipo é um dos básicos, outras opções são possíveis.
- Balanceador L7 distribui o tráfego entre back-ends disponíveis “mais sofisticados” do que o balanceador L4. Ele pode decidir qual back-end escolher com base, por exemplo, no conteúdo da mensagem HTTP (URL, cookie, etc.).
Independentemente do tipo, o balanceador pode suportar as seguintes funções:
- A descoberta de serviço é o processo de determinação do conjunto de back-ends disponíveis (estático, DNS, Consul, Etcd, etc.).
- Verificação da funcionalidade dos backends detectados (“ping” ativo do backend usando uma solicitação HTTP, detecção passiva de problemas nas conexões TCP, presença de vários códigos 503 HTTP nas respostas, etc.).
- O próprio balanceamento (round robin, seleção aleatória, hash de IP de origem, URI).
- Rescisão TLS e verificação de certificado.
- Opções relacionadas à segurança (autenticação, prevenção de ataques DoS, limitação de velocidade) e muito mais.
O NSX Edge oferece suporte para dois modos de implantação do balanceador de carga:
Modo proxy ou um braço. Nesse modo, o NSX Edge usa seu endereço IP como endereço de origem ao enviar uma solicitação a um dos back-ends. Assim, o balanceador executa simultaneamente as funções de NAT de Origem e Destino. O back-end vê todo o tráfego enviado do balanceador e responde diretamente a ele. Nesse esquema, o balanceador deve estar no mesmo segmento de rede dos 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 realiza o NAT de destino, substituindo o endereço VIP pelo endereço do backend selecionado.
3. O Edge realiza o NAT de origem, substituindo o endereço do usuário que enviou a solicitação pelo seu próprio.
4. O pacote é enviado para o backend selecionado.
5. O backend não responde diretamente ao usuário, mas sim ao Edge, pois o endereço original do usuário foi alterado para o endereço do balanceador.
6. O Edge transmite a resposta do servidor ao usuário.
O diagrama está abaixo.
Modo transparente ou embutido. Neste cenário, o balanceador possui interfaces nas redes interna e externa. Ao mesmo tempo, não há acesso direto à rede interna da rede externa. O balanceador de carga integrado atua como um gateway NAT para 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 realiza o NAT de destino, substituindo o endereço VIP pelo endereço do backend selecionado.
3. O pacote é enviado para o backend selecionado.
4. O backend recebe uma solicitação com o endereço original do usuário (o NAT de origem não foi realizado) e responde diretamente a ela.
5. O tráfego é novamente aceito pelo balanceador de carga, pois em um esquema inline ele geralmente atua como gateway padrão para o farm de servidores.
6. O Edge executa NAT de origem para enviar tráfego ao usuário, usando seu VIP como endereço IP de origem.
O diagrama está abaixo.
Prática
Minha bancada de testes possui 3 servidores executando Apache, que está configurado para funcionar em HTTPS. O Edge realizará o balanceamento round robin de solicitações HTTPS, fazendo proxy de cada nova solicitação para um novo servidor.
Vamos começar
Gerando um certificado SSL que será usado pelo NSX Edge
Você pode importar um certificado CA válido ou usar um certificado autoassinado. Para este teste usarei autoassinado.
- Na interface do vCloud Director, acesse as configurações dos serviços Edge.
- Vá para a guia Certificados. Na lista de ações, selecione adicionar um novo CSR.
- Preencha os campos obrigatórios e clique em Manter.
- Selecione o CSR recém-criado e selecione a opção CSR de autoassinatura.
- Selecione o período de validade do certificado e clique em Manter
- O certificado autoassinado aparece na lista de certificados disponíveis.
Configurando o perfil do aplicativo
Os perfis de aplicativos oferecem controle mais completo sobre o tráfego de rede e tornam o gerenciamento simples e eficaz. Eles podem ser usados para definir o comportamento para tipos específicos de tráfego.
- Vá para a guia Load Balancer e habilite o balanceador. A opção Aceleração habilitada aqui permite que o balanceador use balanceamento L4 mais rápido em vez de L7.
- Vá para a guia Perfil do aplicativo para definir o perfil do aplicativo. Clique em +.
- Defina o nome do perfil e selecione o tipo de tráfego ao qual o perfil será aplicado. Deixe-me explicar alguns parâmetros.
Persistência – armazena e rastreia dados da sessão, por exemplo: qual servidor específico no pool está atendendo à solicitação do usuário. Isso garante que as solicitações do usuário sejam roteadas para o mesmo membro do pool durante o tempo de vida da sessão ou de sessões subsequentes.
Habilitar passagem SSL – Quando esta opção é selecionada, o NSX Edge para de encerrar o SSL. Em vez disso, o encerramento ocorre diretamente nos servidores que estão sendo balanceados.
Insira o cabeçalho HTTP X-Forwarded-For – permite determinar o endereço IP de origem do cliente que se conecta ao servidor web por meio do balanceador de carga.
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 Pool Side SSL e selecionar o certificado gerado anteriormente na guia Certificados de Servidor Virtual -> Certificado de Serviço.
- Da mesma forma para Certificados de Pool -> Certificado de Serviço.
Criamos um pool de servidores, cujo tráfego será balanceado Pools
- Vá para a guia Piscinas. Clique em +.
- Definimos o nome do pool, selecionamos o algoritmo (vou usar round robin) e o tipo de monitoramento para o backend do health check.A opção Transparente indica se os IPs de origem iniciais dos clientes estão visíveis para os servidores internos.
- Se a opção estiver desabilitada, o tráfego para servidores internos vem do IP de origem do balanceador.
- Se a opção estiver habilitada, os servidores internos veem o IP de origem dos clientes. Nessa configuração, o NSX Edge deve atuar como gateway padrão para garantir que os pacotes retornados passem pelo NSX Edge.
O NSX oferece suporte aos seguintes algoritmos de balanceamento:
- IP_HASH – seleção do servidor com base nos resultados de uma função hash para o IP de origem e destino de cada pacote.
- LASTCONN – balanceamento de conexões de entrada, dependendo do número já disponível em um determinado servidor. Novas conexões serão direcionadas ao servidor com menos conexões.
- ROUND_ROBIN – novas conexões são enviadas para cada servidor por vez, de acordo com o peso que lhe é atribuído.
- URI – a parte esquerda do URI (antes do ponto de interrogação) é hash e dividida pelo peso total dos servidores no pool. O resultado indica qual servidor recebe a solicitação, garantindo que a solicitação seja sempre roteada para o mesmo servidor, desde que todos os servidores permaneçam disponíveis.
- CABEÇALHO HTTP – balanceamento baseado em um cabeçalho HTTP específico, que pode ser especificado como parâmetro. Se o cabeçalho estiver faltando ou não tiver nenhum valor, o algoritmo ROUND_ROBIN será aplicado.
- URL – Cada solicitação HTTP GET procura o parâmetro de URL especificado como argumento. Se o parâmetro for seguido por um sinal de igual e um valor, o valor será hash e dividido pelo peso total dos servidores em execução. O resultado indica qual servidor recebe a solicitação. Este processo é usado para rastrear IDs de usuários em solicitações e garantir que o mesmo ID de usuário seja sempre enviado para o mesmo servidor, desde que todos os servidores permaneçam disponíveis.
- No bloco Membros, clique em + para adicionar servidores ao pool.
Aqui você precisa indicar:- nome do servidor;
- Endereço IP do servidor;
- a porta na qual o servidor receberá tráfego;
- porta para verificação de saúde (Monitorar verificação de saúde);
- peso – usando este parâmetro você pode ajustar a quantidade proporcional de tráfego recebido para um membro específico do pool;
- Max Connections – número máximo de conexões com o servidor;
- Conexões mínimas – o número mínimo de conexões que o servidor deve processar antes que o tráfego seja encaminhado para o próximo membro do pool.
Esta é a aparência do pool final de três servidores.
Adicionando Servidor Virtual
- Vá para a guia Servidores Virtuais. Clique em +.
- Ativamos o servidor virtual usando Enable Virtual Server.
Damos-lhe um nome, selecionamos o Perfil de Aplicação, Pool criado anteriormente e indicamos o endereço IP para o qual o Servidor Virtual receberá solicitações externas. Especificamos o protocolo HTTPS e a porta 443.
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 recebidas por segundo.
Isso completa a configuração do balanceador; você pode verificar sua funcionalidade. Os servidores possuem 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 solicitação subsequente será processada pelo próximo servidor do pool.
Entramos no endereço externo do balanceador no navegador e vemos:
Após atualizar a página, a solicitação será processada pelo seguinte servidor:
E novamente - para verificar o terceiro servidor do pool:
Ao verificar, você pode perceber que o certificado que o Edge nos envia é o mesmo que geramos no início.
Verificando o status do balanceador no console do Edge Gateway. Para fazer isso, digite mostrar pool de balanceadores de carga de serviço.
Configurando o Service Monitor para verificar o status dos servidores no pool
Usando o Service Monitor, podemos monitorar o status dos servidores no pool de back-end. Se a resposta a uma solicitação não for a esperada, o servidor poderá ser retirado do pool para não receber novas solicitações.
Por padrão, três métodos de verificação estão configurados:
- Monitor TCP,
- monitor HTTP,
- Monitor HTTPS.
Vamos criar um novo.
- Vá para a guia Monitoramento de serviço e clique em +.
- Escolher:
- nome do novo método;
- o intervalo em que as solicitações serão enviadas,
- tempo limite aguardando uma resposta,
- tipo de monitoramento – solicitação HTTPS usando o método GET, código de status esperado – 200(OK) e URL da solicitação.
- Isso conclui a configuração do novo Service Monitor; agora podemos usá-lo ao criar um pool.
Configurando regras de aplicativos
As regras de aplicação são uma forma de manipular o tráfego com base em determinados gatilhos. Com esta ferramenta podemos criar regras avançadas de balanceamento de carga que podem não ser possíveis através de perfis de aplicação ou outros serviços disponíveis no Edge Gateway.
- Para criar uma regra, acesse a aba Regras de Aplicação do balanceador.
- Selecione um nome, um script que usará a regra e clique em Manter.
- Após a criação da regra, precisamos editar o Servidor Virtual já configurado.
- Na guia Avançado, adicione a regra que criamos.
No exemplo acima, habilitamos o suporte a tlsv1.
Mais alguns exemplos:
Redirecione o tráfego para outro pool.
Com este script podemos redirecionar o tráfego para outro pool de balanceamento se o pool principal estiver inativo. Para que a regra funcione, vários pools devem ser configurados no balanceador e todos os membros do pool principal devem estar no estado inativo. Você precisa especificar o nome do pool, não seu ID.
acl pool_down nbsrv(PRIMARY_POOL_NAME) eq 0
use_backend SECONDARY_POOL_NAME if PRIMARY_POOL_NAME
Redirecione o tráfego para um recurso externo.
Aqui redirecionamos o tráfego para o site externo se todos os membros do pool principal estiverem inativos.
acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down
Ainda mais exemplos .
Isso é tudo para mim sobre o balanceador. Se você tiver alguma dúvida, pergunte, estou pronto para responder.
Fonte: habr.com