Geekly articles weekly

VMware NSX para o menor. Parte 5. Configurando o Balanceador de Carga



Parte I Introdutório
Parte Dois Configurar regras de firewall e NAT
Parte três. Configuração DHCP
Parte Quatro Configuração de roteamento

A última vez que falamos sobre os recursos do NSX Edge em termos de roteamento estático e dinâmico, e hoje trataremos do balanceador.

Antes de prosseguir com a instalação, gostaria de lembrar brevemente os principais tipos de balanceamento.

Teoria


Todas as soluções atuais de balanceamento de carga útil costumam ser divididas em duas categorias: balanceamento no quarto (transporte) e sétimo (aplicado) níveis do modelo OSI . O modelo OSI não é o melhor ponto de referência ao descrever métodos de balanceamento. Por exemplo, se o balanceador L4 também suportar a terminação TLS, ele se tornará um balanceador L7? Mas é isso, é isso.

  • O balanceador L4 geralmente é aquele que fica entre o cliente e o conjunto de back-end de proxy intermediário disponível, que finaliza as 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 o próprio SYN. Este tipo é um dos básicos, outras opções são possíveis.
  • O balanceador L7 distribui o tráfego para os back-end disponíveis "mais sofisticados" do que o balanceador L4. Ele pode decidir sobre um back-end com base, por exemplo, no conteúdo de uma mensagem HTTP (URL, cookie, etc.).

Independentemente do tipo, o balanceador pode suportar as seguintes funções:

  • A descoberta de serviço é o processo de determinar o conjunto de back-end disponíveis (Estático, DNS, Consul, Etcd etc.).
  • Verificando a integridade dos back-ends detectados ("ping" ativo do back-end usando uma solicitação HTTP, detecção passiva de problemas nas conexões TCP, presença de vários códigos HTTP 503 nas respostas seguidas, etc.).
  • Balanceamento próprio (round robin, seleção aleatória, hash de IP de origem, URI).
  • Terminação TLS e verificação de certificado.
  • Opções relacionadas à segurança (autenticação, prevenção de ataques de DoS, limite de velocidade) e muito mais.

O NSX Edge oferece suporte para dois modos de implantação do balanceador:

Modo proxy ou com um braço . Nesse modo, ao enviar uma solicitação para um dos back-end, o NSX Edge usa seu endereço IP como endereço de origem. Portanto, o balanceador executa as funções NAT de origem e destino. O back-end vê todo o tráfego como enviado do balanceador e responde diretamente a ele. Nesse esquema, o balanceador deve estar no mesmo segmento de rede que os servidores internos.

Aqui está como vai:

  1. O usuário envia uma solicitação para o endereço VIP (endereço do balanceador) configurado no Edge.
  2. O Edge seleciona um dos back-end e executa o NAT de destino, substituindo o endereço VIP pelo endereço do back-end selecionado.
  3. O Edge executa o NAT de origem, substituindo o endereço do usuário que enviou a solicitação pelo seu.
  4. O pacote é enviado para o back-end selecionado.
  5. O back-end não responde diretamente ao usuário, mas o Edge, pois o endereço original do usuário foi alterado para o endereço do balanceador.
  6. O Edge envia a resposta do servidor ao usuário.

Esquema abaixo.



Modo transparente ou embutido. Nesse cenário, o balanceador possui interfaces na rede interna e externa. No entanto, não há acesso direto à rede interna a partir do externo. O balanceador de carga interno 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) configurado no Edge.
  2. O Edge seleciona um dos back-end e executa o NAT de destino, substituindo o endereço VIP pelo endereço do back-end selecionado.
  3. O pacote é enviado para o back-end selecionado.
  4. O back-end recebe uma solicitação com o endereço original do usuário (o NAT de origem não foi executado) e responde diretamente a ele.
  5. O tráfego é novamente aceito pelo balanceador de carga, pois no esquema embutido geralmente atua como o gateway padrão para o farm de servidores.
  6. O Edge executa o NAT de origem para enviar tráfego ao usuário, usando seu VIP como o endereço IP de origem.

Esquema abaixo.



Prática


Na minha mesa de teste, estão configurados 3 servidores com Apache, os quais estão configurados para funcionar em HTTPS. O Edge equilibrará as solicitações HTTPS usando o método round robin, fazendo proxy de cada nova solicitação para um novo servidor.

Vamos começar.

Gerando um certificado SSL que usará o NSX Edge


Você pode importar um certificado CA válido ou usar um certificado autoassinado. Neste teste, usarei autoassinado.

  1. Na interface do vCloud Director, acesse as configurações de serviços de Borda.

  2. Vá para a guia Certificados. Na lista de ações, selecione a adição de um novo CSR.

  3. Preencha os campos obrigatórios e clique em Manter.

  4. Selecione o CSR recém-criado e selecione a opção CSR de autoassinatura.

  5. Selecione o período de validade do certificado e clique em Manter

  6. Um certificado autoassinado apareceu na lista de disponíveis.


Configurar perfil de aplicativo


Os perfis de aplicativos oferecem mais controle sobre o tráfego da rede e tornam o gerenciamento simples e eficiente. Com a ajuda deles, você pode determinar o comportamento para tipos específicos de tráfego.

  1. Vá para a guia Load Balancer e ligue o balancer. A opção Aceleração ativada aqui permite que o balanceador use um balanceamento L4 mais rápido em vez de L7.

  2. Vá para a guia Perfil do aplicativo para definir o perfil do aplicativo. Clique em +.

  3. Defina o nome do perfil e selecione o tipo de tráfego ao qual o perfil será aplicado. Vou explicar alguns parâmetros.

    Persistência - salva e rastreia os dados da sessão, por exemplo: qual servidor específico do pool está atendendo a uma solicitação do usuário. Isso garante que as solicitações do usuário sejam enviadas ao mesmo membro do pool durante toda a vida útil da sessão ou das sessões subseqüentes.

    Ativar passagem SSL - quando essa opção é selecionada, o NSX Edge para de encerrar o SSL. Em vez disso, a finalização ocorre diretamente nos servidores para os quais o balanceamento é realizado.

    Inserir cabeçalho HTTP X-Forwarded-For - permite determinar o endereço IP de origem do cliente que está se conectando ao servidor da Web por meio do balanceador.

    Ativar SSL do lado do pool - permite especificar que o pool selecionado consiste em servidores HTTPS.

  4. Como equilibrarei o tráfego HTTPS, preciso ativar o SSL do lado do pool e selecionar o certificado gerado anteriormente na guia Certificados do servidor virtual -> guia Certificado de serviço.

  5. Da mesma forma para certificados de pool -> certificado de serviço.


Criamos um pool de servidores, o tráfego no qual os pools serão equilibrados


  1. Vá para a guia Pools. Clique em +.

  2. Defina o nome do pool, selecione o algoritmo (usarei round robin) e o tipo de monitoramento para a verificação de saúde do back-end.A opção Transparente indica se os clientes IP de origem iniciais estão visíveis para os servidores internos.

    • Se essa opção estiver desativada, o tráfego para servidores internos será proveniente do IP de origem do balanceador.
    • Se essa opção estiver ativada, os servidores internos verão os clientes IP de origem. Nessa configuração, o NSX Edge deve atuar como o gateway padrão para garantir que os pacotes retornados passem pelo NSX Edge.

    O NSX suporta os seguintes algoritmos de balanceamento:

    • IP_HASH - seleção de 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 do número de já disponíveis em um servidor específico. Novas conexões serão direcionadas ao servidor com o menor número de conexões.
    • ROUND_ROBIN - novas conexões são enviadas para cada servidor por vez, de acordo com o peso especificado.
    • URI - a parte esquerda do URI (antes do ponto de interrogação) é dividida em hash e dividida pelo peso total dos servidores no pool. O resultado indica qual servidor recebe a solicitação, garantindo que ela sempre seja roteada para o mesmo servidor, desde que todos os servidores permaneçam disponíveis.
    • HTTPHEADER - balanceamento com base em um cabeçalho HTTP específico, que pode ser especificado como um parâmetro. Se o cabeçalho estiver ausente ou não tiver nenhum significado, o algoritmo ROUND_ROBIN será usado.
    • URL - cada solicitação HTTP GET procura o parâmetro 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. Esse processo é usado para rastrear identificadores de usuários em solicitações e para garantir que o mesmo ID de usuário seja sempre enviado ao mesmo servidor, desde que todos os servidores permaneçam disponíveis.

  3. No bloco Membros, clique em + para adicionar servidores ao pool.



    Aqui você precisa especificar:

    • nome do servidor
    • Endereço IP do servidor;
    • a porta para a qual o servidor receberá tráfego;
    • porta para verificação de integridade (Monitor de verificação de saúde);
    • Peso - com esse parâmetro, você pode ajustar a quantidade proporcional de tráfego recebido para um membro específico do pool;
    • Max Connections - o 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 redirecionado para o próximo membro do pool.



    É assim que parece o pool final de três servidores.


Adicionar servidor virtual


  1. Vá para a guia Servidores Virtuais. Clique em +.

  2. Ativamos o servidor virtual usando Ativar servidor virtual.

    Atribuímos um nome a ele, selecione o Perfil de Aplicativo, Pool criado anteriormente e especifique o endereço IP para o qual o Servidor Virtual aceitará solicitações externas. Especifique 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 um servidor virtual pode manipular;
    Limite da 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 seu desempenho. Os servidores têm a configuração mais simples, o que permite entender qual servidor do pool processou a solicitação. Durante a instalação, selecionamos o algoritmo de balanceamento Round Robin, e o parâmetro Weight para cada servidor é igual a um, portanto, cada próxima solicitação será processada pelo próximo servidor do pool.

Digite o endereço externo do balanceador no navegador e consulte:



Após atualizar a página, a solicitação será processada pelo seguinte servidor:



E novamente - para verificar o terceiro servidor da piscina:



Ao verificar, você pode ver que o certificado que o Edge nos envia é o mesmo que geramos desde o início.

Verifique o status do balanceador no console do gateway Edge. Para fazer isso, insira show service loadbalancer pool .



Configure 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 à solicitação não corresponder ao esperado, 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.

Crie um novo.

  1. Vá para a guia Monitoramento de Serviço, clique em +.

  2. Escolha:

    • nome para o novo método;
    • intervalo no qual as solicitações serão enviadas,
    • tempo limite de resposta
    • o tipo de monitoramento é uma solicitação HTTPS usando o método GET, o código de status esperado é 200 (OK) e o URL da solicitação.
  3. Isso completa a configuração do novo Monitor de Serviço, agora podemos usá-lo ao criar um pool.


Configurar regras de aplicativo


Regras de aplicação é uma maneira de manipular o tráfego com base em gatilhos específicos. Usando essa ferramenta, podemos criar regras avançadas de balanceamento de carga, que podem não ser possíveis de serem configuradas por meio de perfis de aplicativos ou usando outros serviços disponíveis no Edge Gateway.

  1. Para criar uma regra, vá para a guia Regras do Aplicativo do balanceador.

  2. Escolha um nome, um script que usará a regra e clique em Manter.

  3. Após a regra ser criada, precisamos editar o servidor virtual já configurado.

  4. Na guia Avançado, adicione a regra que criamos.



No exemplo acima, incluímos o suporte ao tlsv1.

Mais alguns exemplos:

Redirecione o tráfego para outro pool.

Com esse script, podemos redirecionar o tráfego para outro pool de balanceamento se o pool principal não funcionar. Para que a regra funcione, vários conjuntos devem ser configurados no balanceador e todos os membros do conjunto principal devem estar no estado inativo. Especifique 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 um site externo se todos os membros do pool principal estiverem no estado inativo.

 acl pool_down nbsrv(NAME_OF_POOL) eq 0 redirect location http://www.example.com if pool_down

Mais exemplos aqui .

Isso é tudo sobre o balanceador. Se você tiver alguma dúvida, pergunte, estou pronto para responder.

Source: https://habr.com/ru/post/pt448540/

More articles:


All Articles