Tutorial Load Balancers (Balanceamento de Carga)

Balanceamento de Carga (load balancing) refere-se ao processo de distribuição de um conjunto de tarefas sobre um conjunto de recursos (e.g. instâncias computacionais), visando de tornar mais eficiente seu processamento geral. O balanceamento de carga pode otimizar o tempo de resposta e evitar a sobrecarga desigual de alguns nós de computação enquanto outros ficam ociosos.

O dispositivo responsável por fazer o balanceamento de carga é o load balancer, sendo virtual ou físico.

O load balancer como serviço da plataforma NNumbers Cloud é bem flexível e permite gerenciar diferentes tipos de cargas, rejeitar requisições, redirecionar requisições para sites externos, direcionar requisições para outros pools, configurar diferentes pesos para cada membro individualmente de cada pool, etc.

Inicialmente na criação de um load balancer é criado um listener, um pool, um ou mais membros são atribuídos ao pool e um monitor também é criado. Posteriormente, é possível criar listeners adicionais, pools adicionais e monitores adicionais.

Preparação do Ambiente de Tutorial

Neste tutorial serão criadas redes para serem utilizadas por instâncias dos pools (explicados a seguir) dos load balancers, instâncias onde serão instalados web servers e load balancers e um roteador para integrar as redes.

Rede Privada

Crie uma rede privada (blue-net), com as configurações abaixo. Veja os detalhes de cada configuração de rede são explicados no Tutorial de Redes.

CIDR	10.10.0.0/16
DHCP	10.10.0.100, 10.10.255.254
DNS	8.8.8.8 1.1.1.1

Roteador

Crie um roteador (main-router). Para mais informações veja o Tutorial Roteadores.

• Crie uma interface para a sub-rede blue-subnet no roteador

Grupos de segurança

Crie dois grupos de segurança, um para ICMP e SSH e outro para HTTP (para mais informações veja o Tutorial Grupos de Segurança):

• Crie um grupo de segurança para teste ICMP e acesso SSH.
  • Regra de entrada ICMP, IPv4, origem SEU-IP-PUBLICO/32.
  • Regra de entrada TCP porta 22 (SSH), IPv4, origem SEU-IP-PUBLICO/32.
• Crie um grupo de segurança para acesso HTTP.
  • Regra de entrada TCP porta 80 (HTTP), IPv4, origem 0.0.0.0/0 — aqui a exposição pública é a intenção: é o serviço que o balanceador vai publicar.

SSH e ICMP são restritos de propósito

Descubra o seu endereço com curl https://checkip.amazonaws.com e use-o em /32. Abrir a porta 22 para 0.0.0.0/0 expõe as quatro instâncias deste laboratório a varredura automatizada. A diferença entre os dois casos está explicada em Planejamento de instâncias.

Instâncias Computacionais

Crie quatro instâncias (contagem/count = 4) chamadas blue-box da mesma imagem Linux (e.g. ubuntu-focal_fossa-server-amd64-20.04-lts). Para mais informações veja o Tutorial de Criação de Instâncias Computacionais.

• use a sub-rede recém criada (blue-net)

Crie um grupo de segurança para teste ICMP e acesso SSH. Para mais informações veja o Tutorial Grupos de Segurança.

• Atribua o grupo de segurança para a porta de cada instância. Crie um grupo de segurança para acesso HTTP

• Atribua o grupo de segurança para a porta de cada instância. Atribua um IP flutuante para a instância blue-box-1. Para mais informações veja o IPs Flutuantes.

A partir da máquina onde está a chave privada do par de chaves usado na criação das instâncias, alcance as instâncias sem IP público através da que tem IP flutuante.

Opção recomendada — ProxyJump. Ela não abre túneis manuais e verifica a identidade de cada host:

# Acessa blue-box-2 saltando por blue-box-1
ssh -J ubuntu@<IP-FLUTUANTE-blue-box-1> ubuntu@<IP-PRIVADO-blue-box-2>

Para não repetir o salto a cada comando, declare-o em ~/.ssh/config:

Host blue-box-1
  HostName <IP-FLUTUANTE-blue-box-1>
  User ubuntu

Host blue-box-2 blue-box-3 blue-box-4
  User ubuntu
  ProxyJump blue-box-1

Alternativa — túnel local, quando você precisa expor as portas na sua máquina:

ssh -L 2222:<IP-PRIVADO-blue-box-2>:22 \
    -L 2223:<IP-PRIVADO-blue-box-3>:22 \
    -L 2224:<IP-PRIVADO-blue-box-4>:22 \
    ubuntu@<IP-FLUTUANTE-blue-box-1>

# Em outro terminal, com o túnel aberto:
ssh -p 2222 ubuntu@localhost

Não desative a verificação do host

Você verá, em materiais antigos, -o StrictHostKeyChecking=no e -o UserKnownHostsFile=/dev/null. As duas opções desligam a verificação da identidade do servidor e deixam a conexão vulnerável a interceptação — inclusive dentro da nuvem.

Na primeira conexão, o SSH mostra a impressão digital do host e pergunta se você confia:

The authenticity of host '203.0.113.10' can't be established.
ED25519 key fingerprint is SHA256:AbCd…
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Compare essa impressão digital com a do console da instância (Computação → Instâncias → Log, onde as chaves do host são impressas no primeiro boot). Confirmando, ela é gravada em ~/.ssh/known_hosts e as conexões seguintes são verificadas automaticamente.

Em automação, use no máximo -o StrictHostKeyChecking=accept-new: ele aceita um host desconhecido na primeira vez, mas recusa um host cuja chave mudou — que é o caso que interessa detectar.

Instância recriada muda a chave do host, e o SSH avisa com REMOTE HOST IDENTIFICATION HAS CHANGED. Depois de confirmar que foi você quem recriou, remova a entrada antiga:

ssh-keygen -R <IP-OU-NOME-DO-HOST>

Instale o web server nginx em cada instância para teste do load balancer.

sudo apt update
sudo apt dist-upgrade -y
sudo apt install nginx -y

Criação do Load Balancer

Para criar um load balancer selecione o menu Projeto -> Rede -> Balanceadores de Carga, Create Load Balancer, conforme figura abaixo:

Em seguida será exibido o assistente de criação de load balancer.

No assistente de criação de load balancer na opção Detalhes do load balancer:

• Nome: Identificador do load balancer.
• IP address: Endereço IP que pode ou não ser informado. Se for informado deve pertencer à mesma sub-rede selecionada no campo sub-rede.
• Descrição: Uma descrição breve do load balancer.
• Zona de Disponibilidade: É a Zona de disponibilidade onde serão criadas as instâncias de load balancer.
• Flavor: Tipo de instância de load balancer. Atualmente apenas o modelo de alta disponibilidade está disponível.
• Subnet: A sub-rede ao qual deve pertencer este load balancer.
• Admin State UP: Se estiver marcado com opção Sim, o load balancer irá criar as instâncias assim que for concluída a criação. Pode ser desligado (opção Não)

Para este tutorial informe o nome do blue-loadbalancer, o Flavor de alta disponibilidade, a sub-rede blue-net, deixe os campos com o valor padrão e clique no botão Avançar.

A seguir, inicia-se a configuração do listener.

Listeners (Ouvintes)

Cada porta que escuta o tráfego em um balanceador de carga específico é configurada separadamente e ligada ao load balancer. Vários listeners podem ser associados ao mesmo load balancer, mas cada um deve usar uma porta exclusiva (e.g. para um mesmo endpoint onde são disponibilizados os protocolos HTTP e HTTPS é necessário criar um listener para cada protocolo e porta).

Conforme dito anteriormente, no momento inicial apenas é possível criar um listener. Posteriormente é possível adicionar os demais.

Ainda no assistente de criação de load balancer, na opção Detalhes do Listener, Os campos, Nome, Descrição, Protocolo, Porta e Admin State Up permanecem no assistente independente das demais opções selecionadas. Entretanto, os demais campos podem variar conforme a opção de Protocolo selecionada (veja abaixo):

• Create Listener:

  • Sim: Cria listener durante criação do load balancer.
  • Não: Não cria listener durante criação do load balancer. Nesta opção nem os pools, nem os membros dos pools, nem os monitores serão criados[\2].

• Nome: o nome do listener

• Descrição: Breve descrição do listener.

• Protocolo:

  • HTTP
  • TCP
  • TERMINATEDHTTPS
  • HTTPS
  • UDP
  • SCTP

• Porta: A porta IP a qual o listener deverá ouvir. Deve ser um número inteiro de 1 a 65535.

• Client Data Timeout: tempo limite de inatividade do cliente front-end em milissegundos. Padrão: 50000.

• TCP inspect Timeout: Tempo, em milissegundos, para aguardar pacotes TCP adicionais para inspeção de conteúdo. Padrão: 0.

• Member Connect Timeout: Tempo limite de conexão de membro de backend em milissegundos. Padrão: 5000.

• Member Data Timeout: Tempo limite de inatividade do membro backend em milissegundos. Padrão: 50000.

• Connection Limit: O número máximo de conexões permitidas para este listener. O valor padrão é -1, que representa conexões infinitas.

• Allowed Cidrs: Lista de CIDRs separados por linha para as redes/hosts permitidos. Se deixado em branco, será permitido acesso a qualquer rede/host.

• TLS Cipher String: Uma sequência das cifras permitidas usando a sintaxe OpenSSL. A sintaxe é uma lista separada de dois pontos dos chiphers (cifras), ex. TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256 Nota, não inclua aspas. O campo vazio define a TLS Cipher String padrão configurada globalmente (veja Especificação Técnica do Load Balancer com TLS).

• Insert Headers: inserção de cabeçalhos adicionais no cabeçalho HTTP, apenas "X-Forwarded-For", "X-Forwarded-Port" e "X-Forwarded-Proto" são suportados.

• Admin State UP:

  • Sim: O listener já fica ativo (ouvindo o protocolo e porta definidos) assim que o processo do assistente é concluído. Pode ser alterado posteriormente.
  • Não: O listener já não fica ativo assim que o processo do assistente é concluído. Pode ser alterado posteriormente.

Quando o protocolo UDP ou o protocolo SCTP é selecionado, apenas os campos Nome, Descrição, Protocolo, Port, Connection Limit, Allowed Cidrs e Admin State Up permanecem no assistente.

Quando o protocolo TCP ou o protocolo HTTPS são selecionados, apenas os campos Nome, Descrição, Protocolo, Port, Client Data Timeout, TCP Inspect Timeout, Member Connect Timeout, Member Data Timeout, Connection Limit, Allowed CIDRs e Admin State Up permanecem no assistente.

Quando o protocolo HTTP é selecionado, todos os campos, exceto TLS Cipher String, ficam disponíveis no assistente.

Quando o protocolo TERMINATED_HTTPS for selecionado, todos os campos ficam disponíveis e a opção SSL Certificates será habilitada no assistente de criação do load balancer. Para os casos de SNI com múltiplos domínios, selecione os diversos certificados.

Assim como a criação de um listener na criação do load balancer, também é possível posteriormente criar outros listeners. E, portanto, as mesmas regras de opções valem no assistente de criação. Por exemplo, na tela abaixo, ao selecionar o protocolo TERMINATED_HTTPS a opção de menu do assistente é ativada.

Para este tutorial defina o nome (blue-boxes-lb-listener-http), selecione HTTP, porta 80 e mantenha os demais valores padrão e clique no botão Avançar.

Pools

Existem duas abordagens principais para balanceamento de carga: algoritmos de agendamento estáticos, que não levam em consideração o estado dos diferentes recursos computacionais, e algoritmos de agendamento dinâmicos, que geralmente são mais gerais e mais eficientes, mas requerem trocas de informações entre os diferentes recursos de computacionais, sob o risco de um perda de eficiência. A plataforma NNumbers Cloud suporta ambas as abordagens.

Os pools podem ser reutilizados por diferentes listeners e também por políticas L7.

Outro elemento que influencia a distribuição de carga para os membros do pool de recursos é o tipo de persistência da sessão.

Na tela Detalhes do Pool

• Nome: O nome do pool
• Descrição: Uma breve descrição
• Algorithm:
  • LEAST_CONNECTIONS: aloca requisições à instância com o menor número de conexões ativas.
  • ROUND_ROBIN: Rotaciona requisições uniformemente entre várias instâncias.
  • SOURCE_IP: as requisições de um endereço IP de origem exclusivo são direcionadas de forma consistente para a mesma instância.
• Session Persistence:
  • SOURCE_IP: Persistência da sessão com base no ip de origem.
  • HTTP_COOKIE: Persistência de sessão baseada em cookie HTTP.
  • APP_COOKIE: Persistência da sessão com base no cookie do aplicativo.
• Cookie Name: O nome do cookie de aplicação. Habilitado somente quando APP_COOKIE foi selecionado no campo Session Persistence.
• TLS Enabled:
  • Sim: Habilita o TLS para recriptografia de backend, as comunicações entre o balanceador de carga e os servidores membros são criptografadas e habilita campo “TLS Cipher String”.
  • Não: Desabilita o TLS para recriptografia de backend, as comunicações entre o balanceador de carga e os servidores membros são criptografadas e desabilita campo “TLS Cipher String”.
• TLS Cipher String: Uma sequência das cifras permitidas usando a sintaxe OpenSSL. A sintaxe é uma lista separada de dois pontos dos chiphers (cifras), ex. TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256. Nota, não inclua aspas. O campo vazio define a TLS Cipher String padrão configurada globalmente veja Especificação Técnica do Load Balancer com TLS.
• Admin State Up:
  • Sim: O pool já fica ativo assim que o processo do assistente é concluído. Pode ser alterado posteriormente.
  • Não: O pool já não fica ativo assim que o processo do assistente é concluído. Pode ser alterado posteriormente.

Para este tutorial, preencha apenas o nome do pool blue-pool-webserver, selecione o algoritmo round robin (ROUND_ROBIN), deixe os demais campos com o valor padrão e clique em Avançar.

Pools Members

Os recursos (instâncias) computacionais, são atribuídos como membros a um pool de recursos e então o algoritmo de distribuição de carga configurado em Detalhes do Pool fazem a distribuição entre os membros.

Nesta tela o assistente de criação de load balancer permite adicionar instâncias que estão disponíveis na lista abaixo através de um clique no botão Adicionar e permite adicionar configurações de instâncias que ainda não foram criadas, através do botão Add external member, mas, que pertencem a uma sub-rede visível para o seu projeto.

Para este tutorial, se você seguiu os passos de criação da rede, criação do roteador e criação das instâncias recomendado acima, clique em adicionar as instâncias blue-box-1 e blue-box-2, configure o campo Port (porta) com 80 (valor padrão da porta HTTP), deixe os demais campos com o valor padrão e clique em Avançar.

• IP Address:
  • Quando um membro é inserido na lista a partir da lista de hosts disponíveis na lista abaixo e a instância tem apenas uma interface e IP interno este campo é somente leitura.
  • Quando um membro é inserido na lista a partir da lista de hosts disponíveis na lista abaixo e a instância tem mais de um IP e/ou interface este campo permite selecionar o IP e automaticamente a sub-rede será atribuída.
  • Quando é inserido na lista a partir do botão “Add external member” este campo permite a digitação.
• Subnet: Quando um membro é inserido na lista a partir da lista de hosts disponíveis na lista abaixo este campo é somente leitura. Quando é inserido na lista a partir do botão “Add external member” este campo permite a seleção
• Port: Permite informar a porta que receberá a requisição. Por padrão a porta sugerida é igual a porta informada no listener, entretanto, permite informar porta diferente para o backend.
• Weight: É o peso dado a carga do balanceador. Dependendo do algoritmo selecionado na criação do pool este parâmetro tem comportamento diferente.
• Monitor Address: Opcional. Permite informar um IP diferente para monitoramento do membro (veja Monitores).
• Monitor Port: Opcional. Permite informar uma porta diferente para monitoramento do membro (veja Monitores).
• Admin State UP:
  • Sim: O membro está ativado no pool
  • Não: O membro está inativado no pool
• Backup:
  • Sim: Quando selecionado determina o membro como membro backup, ou seja, somente quando não houver mais nenhum outro membro não backup ativo este membro será ativado. Após ativado se qualquer outro membro não backup voltar a funcionar este membro será automaticamente desativado e as requisições não serão mais encaminhadas.
  • Não: Define como membro não backup.
• Nome: Opcional. Permite digitar o nome do membro no pool. Recebe o nome da instância caso seja atribuído a partir da lista de instâncias disponíveis.

Crie um segundo pool e atribua blue-box-3 e blue-box-4 para o segundo pool.

Monitores

O monitor de integridade, ou simplesmente monitor, é usado para determinar a integridade dos membros do pool. As verificações de saúde são executadas rotineiramente em cada membro do pool e o resultado da verificação de saúde é usado para determinar se o membro recebe novas conexões. Cada pool pode ter apenas um monitor de integridade.

Ainda na tela do assistente de criação de Load Balancer, no passo Detalhes do Monitor, segue os seguintes campos:

• Nome: O nome do monitor
• Tipo: O tipo do monitor (HTTP, HTTPS, PING, TCP, TLS-HELLO e UDP-CONNECT)
• Delay: o intervalo entre as verificações de saúde em segundos. Deve ser maior ou igual ao tempo limite.
• Max Retries: o número de falhas de conexão permitidas antes de marcar o membro como inativo. Deve ser um número de 1 a 10.
• Max Retries Down: O número de falhas de conexão permitidas antes de marcar o membro como erro. Deve ser um número de 1 a 10. O padrão é 3.
• Timeout: o tempo em segundos após o qual uma verificação de integridade atinge o tempo limite. Deve ser um número maior ou igual a 0 e menor ou igual ao intervalo.
• HTTP Method: o método HTTP usado para realizar a verificação de integridade. As opções são: GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS, PATCH e CONNECT
• Expected Codes: os códigos de status HTTP esperados para obter uma verificação de integridade bem-sucedida. Deve ser um único número, uma lista de números separados por vírgulas ou um intervalo (dois números separados por um hífen).
• URL Path: o destino da solicitação HTTP de verificação de integridade para o membro. Deve ser um caminho de URL válido.
• Admin State UP: Indica o estado administrativo do monitor. Se o monitor for criado com o estado administrativo for ligado (up Sim), então, após a conclusão do assistente de criação do load balancer o monitor já passa a verificar se os membros do pool estão respondendo, neste caso, assim que o load balancer é criado os membros já começam a ser monitorados. Como opcionalmente os membros do pool podem ser criados e/ou atribuídos ao pool posteriormente, existe a opção de deixar o estado administrativo como desligado (up Não) e alterar em um momento futuro.

Para os tipos HTTP e HTTPS os campos Nome, Tipo, Max Retries Down, Delay, Max Retries, Timeout, HTTP Method, Expected Codes, URL Path e Admin State Up são habilitados.

Para os tipos PING, TCP, TLS-HELLO e UDP-CONNECT os campos Nome, Tipo, Max Retries Down, Delay, Max Retries, Timeout e Admin State Up são habilitados.

Para este tutorial chame o monitor de blue-monitor-http, selecione o tipo HTTP, selecione GET para HTTP Method, em URL Path preencha com /?monitor=blue-monitor-http, esse valor será usado para identificarmos quais são as chamadas realizadas pelo monitor do load balancer no web server de cada instância do pool, deixe os demais campos com o valor padrão e conclua a criação do load balancer clicando no botão Create Load Balancer.

Inicie a monitoração dos logs dos web-servers através do comando tail em cada uma das instâncias

tail -f /var/log/nginx/access.log

Observe que mesmo sem nenhuma requisição ocorrendo ao load balancer os logs mostram que os web servers permanecem recebendo requisições. Essas requisições, conforme pode ser observado no caminho /?monitor=blue-monitor-http, provém de chamadas realizadas do monitor do load balancer para verificar a saúde dos membros do pool a quantidade de requisições pode variar conforme o tempo configurado no monitor.

Exposição de Load Balancer

É possível ter load balancers em diferentes níveis de rede, públicos ou privados. Entretanto, para simplicidade deste tutorial iremos expor o load balancer criado acima com um IP flutuante. Para mais detalhes veja IPs Flutuantes.

No menu Projeto -> Rede -> Balanceadores de Carga, clique no botão seta para baixo à direita do load balancer o qual deseja-se expor e selecione a opção Associar IP Flutuante:

Atribua um IP flutuante para o load balancer (blue-loadbalancer).

Balanceamento de Carga Simples

Após a configuração anterior, o balanceamento de carga já está pronto para um teste de carga simples.

Utilize o comando curl remotamente para testar a chamada para o load balancer:

curl -v -L http://<IP-FLUTUANTE-ATRIBUIDO-PARA-O-LOADBALANCER>

Repita o comando acima algumas vezes e observe o log.

observação

• A opção -v permite visualizar os cabeçalhos e payload enviados e recebidos
• A opção -L permite seguir os redirects, serão demonstrados nos próximos exemplos.

Como não foi criada nenhuma política para L7 pode ser incluídos caminhos (path) adicionais e o balanceamento de carga será mantido, mas, a resposta dependerá de existir ou não o recurso nos web-servers (e.g. "404 Not Found" para caso o recurso não existir) ou da definição de regras no próprio web-server (os web-servers podem muitas vezes atuar como proxies estabelecendo regras adicionais de redirecionamento, reescrita de URL, cache, etc).

Exemplo

curl -v -L http://<IP-FLUTUANTE-ATRIBUIDO-PARA-O-LOADBALANCER>/teste

Observe nos logs dos web-servers que a chamada chega até as instâncias:

tail -f /var/log/nginx/access.log |grep -v monitor

observação

• o comando |grep -v monitor filtra para não aparecer as chamadas feitas pelo monitor de integridade do pool.

Balanceamento de Carga com Degradação de um Membro

Para fazer um teste de degradação, para o web-server de blue-box-2.

systemctl stop nginx.service

Observe no painel administrativo que o load balancer fica marcado como Degradado na coluna Estado Operacional (Operating Status).

Ative novamente o serviço do web server em blue-box-2.

systemctl start nginx.service

Observe que em poucos instantes o serviço volta para o estado online novamente.

aviso

• O tempo pode variar conforme o tempo configurado no monitor

Balanceamento de Carga com Diferentes Pesos

Em algumas situações pode ser necessário que a carga seja distribuída de forma que um ou alguns membros do pool recebam uma carga maior que outro(s). Através da configuração de peso (weight) de cada membro do pool é possível alterar essa distribuição de carga.

observação

• Os pesos diferentes terão comportamentos um pouco diferentes para cada tipo de algoritmo de agendamento escolhido para o balanceamento de carga.

Incremente o peso do membro blue-box-2 para 10.

Utilize o comando curl remotamente para testar a chamada para o load balancer:

curl -v -L http://<IP-FLUTUANTE-ATRIBUIDO-PARA-O-LOADBALANCER>

Observe nos logs que mais requisições são realizadas em blue-box-2.

Balanceamento de Carga com Políticas L7

Uma política L7 é uma coleção de regras L7 associadas a um listener, e que também pode ter uma associação a um pool de back-end.

É possível criar políticas L7 simples na camada de aplicação do protocolo TCP/IP no(s) listener(s) sobre os protocolos HTTP e HTTPS.

Uma regra L7 é um teste lógico único e simples que retorna verdadeiro ou falso.

Política L7 de Rejeição

No menu Rede -> Balanceadores de Carga, clique no link à esquerda da linha do load balancer que será incluída a política L7.

Selecione a aba Listeners, clique no link à esquerda da linha do listener que se deseja incluir a política L7:

Selecione a aba Políticas L7 (L7 Policies), clique no botão Criar Política L7 (Create L7 Policy):

Crie uma política L7 (blue-lb-listener-http-reject-policy) no listener blue-listener-http para rejeitar. Essa política irá retornar um HTTP Status Code 403 (Forbidden).

Forneça os detalhes da política L7.

• Nome: O nome da política L7
• Descrição: Uma breve descrição da política L7
• Ação:
  • De rejeição (REJECT):
    • A requisição é negada com um código de resposta apropriado e não encaminhada para nenhum pool de backend.
  • De redirecionamento para uma URL (REDIRECT_TO_URL):
    • A requisição é enviada um redirecionamento HTTP para a URL definida no parâmetro redirect_url.
  • De redirecionamento para um pool alternativo (REDIRECT_TO_POOL):
    • A requisição é encaminhada ao pool de back-end associado à política L7.
• Posição (Position): a posição desta política no listener. As posições começam em 1.
• Admin State UP: Se estiver marcado com opção Sim, a política L7 será ativada (padrão) assim que for concluída o assistente de criação de política L7. Pode ser desligado (opção Não)

Clique no link à direita da linha referente a política L7 recém criada, selecione a aba Regras L7 (L7 Rules):

Clique no botão Criar Regra L7 (Create L7 Rule):

Crie uma regra (redirect-para-url-externa) para o caminho (PATH) igual (EQUALS_TO) /teste:

• Inverter (Invert): quando verdadeiro, a lógica da regra é invertida. Por exemplo, com invert true, igual a se tornaria diferente de.
• Tipo: o tipo de regra L7.
  • COOKIE: a regra procura um cookie nomeado pelo parâmetro chave e o compara com o parâmetro de valor na regra.
  • CABEÇALHO: a regra procura um cabeçalho definido no parâmetro chave e o compara com o parâmetro de valor na regra.
  • FILE_TYPE: a regra compara a última parte do URI com o parâmetro de valor na regra. (por exemplo, txt, jpg etc.)
  • CAMINHO: a regra compara a parte do caminho do URI HTTP com o parâmetro de valor na regra.
  • HOST_NAME: a regra faz uma comparação entre o nome do host HTTP / 1.1 na solicitação e o parâmetro de valor na regra.
• Tipo de comparação: o tipo de comparação para a regra L7.
  • REGEX: correspondência de expressão regular de tipo Perl.
  • STARTS_WITH: String começa com.
  • ENDS_WITH: String termina com.
  • CONTAINS: String contém.
  • EQUAL_TO: String é igual a.
• Valor (Value): o valor a ser usado para a comparação. Por exemplo, o tipo de arquivo a ser comparado.

Através do comando curl remotamente teste a chamada para o caminho (path) /teste

curl -v -L http://<IP-FLUTUANTE-ATRIBUIDO-PARA-O-LOADBALANCER>/teste

observação

• A opção -L do comando curl irá seguir o redirecionamento para a URL recebida no cabeçalho Location.

O resultado deve conter o cabeçalho: `HTTP/1.1 403 Forbidden``

Observe nos logs dos web-servers que a chamada NÃO chega até as instâncias, pois, a rejeição da chamada é realizada na camada do load balancer

Política L7 de Redirecionamento

Crie uma política L7 (blue-lb-listener-http-redirect-url-policy) no listener blue-listener-http para redirecionar para uma URL externa — neste exemplo, https://example.com/. Essa política irá retornar um HTTP Status Code 302 (Found) e uma Location para onde será redirecionado.

O destino é um exemplo

example.com é reservado pela IANA para documentação (RFC 2606) e não sai do ar. Troque pelo destino real do seu redirecionamento.

Crie uma regra para o caminho (PATH) igual (EQUALS_TO) /externo.

Através do comando curl remotamente teste a chamada para o caminho (path) /externo

curl -v http://<IP-FLUTUANTE-ATRIBUIDO-PARA-O-LOADBALANCER>/externo

Observe nos logs dos web-servers que a chamada NÃO chega até as instâncias, pois o redirecionamento é realizado na camada do load balancer.

O resultado deve conter os cabeçalhos:

HTTP/1.1 302 Found
Location: https://example.com/

A opção -L do comando curl irá seguir o redirecionamento para a URL recebida no cabeçalho Location.

curl -v -L http://<IP-FLUTUANTE-ATRIBUIDO-PARA-O-LOADBALANCER>/externo

O resultado deverá ser algo similar ao conteúdo abaixo:

< HTTP/1.1 302 Found
< Location: https://example.com/
...
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=UTF-8

O que importa aqui são as duas respostas: o 302 veio do load balancer, sem tocar nas instâncias, e o 200 veio do destino externo depois que o curl -L seguiu o Location.

Política L7 de Redirecionamento para Outro Pool

Crie uma política L7 (blue-lb-listener-http-redirect-pool-policy) no listener blue-listener-http para redirecionar para o pool (REDIRECT_TO_POOL) blue-secondary-webserver-pool. Essa política irá redirecionar uma chamada feita a um endpoint de blue-loadbalancer para os membros de blue-secondary-webserver-pool.

• Inclua uma regra
  • Invert: No
  • Tipo: PATH
  • Compare Type: EQUALS_TO
  • Value: /pool

Através do comando curl remotamente teste a chamada para o caminho (path) /pool

curl -v http://<IP-FLUTUANTE-ATRIBUIDO-PARA-O-LOADBALANCER>/pool

observação

• Não é necessário a opção -L, pois, o redirecionamento acontece no backend (load balancer).

Observe nos logs dos web-servers blue-box-1 e blue-box-2 que as requisições NÃO chegam até as instâncias, pois o redirecionamento é realizado na camada do load balancer.

Observe nos logs dos web-servers blue-box-3 e blue-box-4 que as requisições chegam até as instâncias, pois o redirecionamento é realizado na camada do load balancer.

Edição e Exclusão de Regras L7

As regras configuradas podem ser editadas clicando no link de cada linha na coluna tipo, à esquerda, e depois no botão Editar Regra L7 (Edit L7 Rule) ou simplesmente clicando no botão Editar Regra L7 (Edit L7 Rule) à direita de cada linha.

O procedimento de exclusão de regras L7 é feito através do clique no botão Excluir Regra L7 (Delete L7 Rule) clicando na 🔽 ao final de cada linha ou selecionando as linhas desejadas no campo de seleção checkbox à esquerda e depois clicando no botão vermelho, no canto superior direito, Excluir Regras L7 (Delete L7 Rules).

Balanceamento de Carga com Terminação de HTTPS

Quando você acessa um site usando o protocolo HTTPS (formalmente conhecido como handshake SSL/TLS), muito trabalho cria e mantém um canal de comunicação seguro. Seu cliente (e.g. navegador) e o servidor web trabalham juntos para negociar uma cifra mutuamente aceitável, trocar chaves e configurar uma chave de sessão. Uma vez estabelecido, ambas as extremidades da conversa usam a chave de sessão para criptografar e descriptografar todo o tráfego adicional. Como a chave de sessão é exclusiva da conversa entre o cliente e o servidor, um terceiro não pode descriptografar o tráfego ou interferir na conversa.

Para criar o balanceamento de carga de um site com HTTPS, primeiramente siga o Tutorial Criação de Segredos no NNumbers Cloud KMS. Em seguida crie um Listener na porta desejada (e.g. 443 ou outra), conforme o tutorial Listeners (Ouvintes) utilizando o protocolo TERMINATED_HTTPS, será então apresentada uma nova opção de menu no wizard de criação de listeners chamada SSL Certificates, conforme a figura abaixo.

aviso

A interface não atende certificados SNI. Em caso de necessidade de uso de certificados SNI é necessário criar/configurar o load balancer por API.

Selecione o certificado clicando no botão ( ➕ ) relativo à linha do certificado desejado.

Clique no botão Create Listener e finalize a criação do listener. [\3]

Certificados Let’s Encrypt

A Let's Encrypt é uma autoridade certificadora gratuita, automatizada e aberta que emite certificados seguindo o protocolo ACME[\4]. O protocolo ACME[\4], por sua vez, permite que certificados sejam emitidos e renovados sem interação humana.

Portanto, para usar certificados automatizados e gratuitos emitidos pela Let 's Encrypt, é necessário implementar um lado do protocolo ACME[\4]. Essa implementação pode ser feita através da instalação de softwares que permitem essa comunicação da autoridade certificadora (_Let's Encrypt* neste tutorial) com um _endpoint HTTP* (porta 80) que responda no DNS, o qual deverá receber o desafio-resposta para a instalação do certificado.

A plataforma NNumbers Cloud não dispõe de uma implementação para o protocolo ACME[\4] nativamente (e.g. via HTTP 01 com certbot). Entretanto, é possível em uma VPS instalar o certbot para esse propósito.

Para que o certbot funcione corretamente e seja possível gerar os certificados é necessário que seja criado uma política L7 e sua devida regra.

Configuração do Load Balancer Para o Protocolo ACME

Seguindo as instruções de criação de listeners, crie um listener HTTP, porta 80.

Para o listener HTTP, porta 80 criado, crie um novo pool (e.g. acme-pool) e inclua a VPS onde será instalado o certbot[\5] como único membro desse pool (veja detalhes em Pools).

Crie uma nova Política L7 de Redirecionamento para Outro Pool com uma regra com os parâmetros abaixo:

• Invert: No
• Tipo: PATH
• Compare Type: STARTS_WITH
• Value: /.well-known/acme-challenge

Configuração da VPS que Executará o Certbot

Instale as ferramentas de linha de comando curl e jq na VPS onde será instalado o certbot.

Instale o certbot em uma VPS conforme a documentação oficial do Certbot, escolhendo o sistema operacional da sua instância.

Utilização de Certificados Let’s Encrypt em Listeners TERMINATED_HTTPS

Para utilização dos certificados Let’s Encrypt em listeners TERMINATED_HTTPS, no NNumbers Cloud Load Balancer é necessário que seja gerado um certificado do tipo PKCS#12 sem senha.

A geração de certificado do tipo PKCS#12 pode ser feito através do seguinte comando:

openssl pkcs12 -export \
-out /etc/letsencrypt/live/${DOMAIN}/${FILE_BASE_NAME}.pfx \
-inkey /etc/letsencrypt/live/${DOMAIN}/privkey.pem \
-in /etc/letsencrypt/live/${DOMAIN}/cert.pem \
-certfile /etc/letsencrypt/live/${DOMAIN}/chain.pem \
-passout pass:

Em seguida é necessário armazená-lo como um segredo no NNumbers Cloud KMS (veja Tutorial Criação de Segredos no NNumbers Cloud KMS).

Especificação Técnica do Load Balancer com TLS

Apesar de a especificação TLSv1.2 aceitar diversos outros ciphers e cipher suites, apenas os ciphers e cipher suites compatíveis com ambos são habilitados. Sendo a versão mínima requerida a versão TLSV1.2.

Tickets TLS

Não são aceitos.

Ciphers

ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-RSA-CHACHA20-POLY1305
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES256-GCM-SHA384

Cipher Suites

TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256

Estados do Load Balancer

• Apenas no estado Ativo é permitido alterações no balanceador de carga. Todos os outros demais estados deixam o load balancer imutável.
• Apenas nos estados Ativo e Erro é permitido failover. Os estados Pendente* deixam o load balancer imutável.
• Apenas nos estados Ativo e Erro é permitida a exclusão. Os estados Pendente* deixam o load balancer imutável.

Próximos passos

• IPs flutuantes
• Grupos de segurança
• Kubernetes Ingress