Visão geral do balanceamento de carga de rede TCP/UDP externo baseado em serviço de back-end

O balanceamento de carga de rede TCP/UDP externo do Google Cloud, referido balanceamento de carga de rede, é um balanceador de carga regional sem proxy. Um balanceador de carga de rede distribui o tráfego TCP ou UDP entre instâncias de máquina virtual (VM) na mesma região.

Um balanceador de carga de rede pode receber tráfego de:

  • Qualquer cliente na Internet
  • VMs do Google Cloud com IPs externos
  • VMs do Google Cloud que têm acesso à Internet por meio do Cloud NAT ou NAT baseada em instância

O balanceamento de carga da rede tem as seguintes características:

  • O balanceamento de carga da rede é um serviço gerenciado.
  • O balanceamento de carga da rede é implementado usando a rede virtual Andromeda e o Google Maglev.
  • Os balanceadores de carga de rede não são proxies.
    • Os pacotes com carga balanceada são recebidos pelas VMs de back-end com o IP de origem inalterado.
    • As conexões com balanceamento de carga são encerradas pelas VMs de back-end.
    • As respostas das VMs de back-end vão diretamente para os clientes, e não voltam pelo balanceador de carga. O termo do setor para isso é retorno direto do servidor.

Nesta página, você verá como o balanceamento de carga de rede funciona com um serviço de back-end, em vez de um pool de destino. Antes, a única opção para um balanceador de carga de rede era o balanceador de carga de rede baseado no pool de destino. Comparado aos pools de destino, os serviços de back-end oferecem um controle mais detalhado sobre o comportamento do balanceador de carga.

  • Uma configuração de serviço de back-end contém um conjunto de valores, como verificações de integridade, afinidade da sessão, tempos limite de diminuição de conexão e políticas de failover. A maioria dessas configurações tem valores padrão que permitem uma configuração fácil para você começar rapidamente.
  • Os balanceadores de carga de rede baseados em serviço de back-end usam verificações de integridade que correspondem ao tipo de tráfego (TCP, SSL, HTTP, HTTPS ou HTTP/2) que estão distribuindo. Os balanceadores de carga baseados em pool de destino são compatíveis somente com verificações de integridade HTTP legadas.
  • Os balanceadores de carga de rede baseados em serviço de back-end são compatíveis com o uso de grupos de instâncias gerenciadas como back-ends. Esses grupos automatizam determinados aspectos do gerenciamento de back-end e oferecem melhor escalonabilidade e confiabilidade em comparação com grupos de instâncias não gerenciadas. Os balanceadores de carga de rede baseados em pool de destino são compatíveis apenas com grupos de instâncias não gerenciadas.

Arquitetura

O diagrama a seguir ilustra os componentes de um balanceador de carga de rede:

Balanceador de carga de rede TCP/UDP externo com serviço de back-end regional
Balanceamento de carga de rede com serviço de back-end regional

O balanceador de carga é composto de vários componentes de configuração. Um único balanceador de carga pode ter o seguinte:

  • Um ou mais endereços IP externos regionais
  • Uma ou mais regras de encaminhamento externo regionais
  • Um serviço de back-end externo regional
  • Um ou mais grupos de instâncias de back-end
  • Verificação de integridade associada ao serviço de back-end

Além disso, você precisa criar regras de firewall para permitir sondagens de verificação de integridade para as VMs de back-end.

Endereço IP

Um balanceador de carga de rede requer pelo menos uma regra de encaminhamento. Essa regra faz referência a um único endereço IP externo regional. Os endereços IP externos regionais podem ser acessados em qualquer lugar na Internet, mas são provenientes de um pool exclusivo para cada região do Google Cloud.

Ao criar uma regra de encaminhamento, especifique o nome ou endereço IP de um endereço IP externo regional reservado existente. Se você não especificar um endereço IP, a regra de encaminhamento fará referência a um endereço IP externo regional temporário. Use um endereço IP reservado se você precisar manter o endereço associado ao seu projeto para reutilização depois de excluir uma regra de encaminhamento ou se precisar que várias regras de encaminhamento façam referência ao mesmo endereço IP.

O balanceamento de carga de rede aceita endereços IP externos regionais de nível Padrão e Premium. O endereço IP e a regra de encaminhamento precisam usar o mesmo nível de rede.

Veja as etapas para reservar um endereço IP em Endereços IP externos.

Regra de encaminhamento

Uma regra de encaminhamento externo regional especifica o protocolo e as portas em que o balanceador de carga aceita tráfego. Como os balanceadores de carga de rede não são proxies, eles passam o tráfego para back-ends no mesmo protocolo e na mesma porta. A regra de encaminhamento em combinação com o endereço IP forma o front-end do balanceador de carga.

O balanceador de carga preserva os endereços IP de origem dos pacotes de entrada. O endereço IP de destino dos pacotes de entrada é o endereço associado à regra de encaminhamento do balanceador de carga.

O tráfego de entrada é correspondido a uma regra de encaminhamento, que é uma combinação de um determinado endereço IP, protocolo e portas ou um intervalo de portas. A regra de encaminhamento direciona o tráfego para o serviço de back-end do balanceador de carga.

Um balanceador de carga de rede requer pelo menos uma regra de encaminhamento. É possível definir várias regras de encaminhamento para o mesmo balanceador de carga, conforme descrito na próxima seção.

Várias regras de encaminhamento

É possível configurar várias regras de encaminhamento externo regionais para o mesmo balanceador de carga de rede. Opcionalmente, cada regra de encaminhamento pode ter um endereço IP externo regional diferente ou várias regras de encaminhamento podem ter o mesmo endereço IP externo regional.

A configuração de várias regras de encaminhamento externo regionais pode ser útil nestes casos de uso:

  • Você precisa configurar mais de um endereço IP externo para o mesmo serviço de back-end.
  • Você precisa configurar diferentes protocolos, portas ou intervalos de portas usando o mesmo endereço IP externo.

Ao usar várias regras de encaminhamento, configure o software em execução nas suas VMs de back-end para que ele seja vinculado a todos os endereços IP externos das regras de encaminhamento do balanceador de carga.

Serviço de back-end regional

Cada balanceador de carga de rede tem um serviço de back-end regional que define o comportamento do balanceador de carga e como o tráfego é distribuído para os back-ends. O nome do serviço de back-end é o nome do balanceador de carga da rede mostrado no Console do Google Cloud.

Todo os serviços de back-end definem os seguintes parâmetros de back-end:

  • Protocolo. Um serviço de back-end aceita tráfego TCP ou UDP, mas não ambos, no endereço IP e nas portas especificadas por uma ou mais regras de encaminhamento externo regionais. O serviço de back-end permite que o tráfego seja entregue a VMs de back-end no mesmo endereço IP e portas a que o tráfego foi enviado. O serviço de back-end e todas as regras de encaminhamento associadas precisam usar o mesmo protocolo.

  • Distribuição de tráfego. Com um serviço de back-end, é possível fazer com que o tráfego seja distribuído de acordo com uma afinidade de sessão configurável. Também é possível configurar o serviço de back-end para ativar a diminuição de conexão e designar back-ends de failover para o balanceador de carga.

  • Verificação de integridade. Os serviços de back-end precisam ter uma verificação de integridade vinculada.

Cada serviço de back-end opera em uma única região e distribui o tráfego para a primeira interface de rede (nic0) das VMs de back-end. Os back-ends precisam ser grupos de instâncias na mesma região do serviço de back-end e da regra de encaminhamento. Os back-ends podem ser grupos de instâncias não gerenciadas, gerenciadas por zona ou gerenciadas por região.

Os balanceadores de carga de rede baseados em serviço de back-end aceitam grupos de instâncias com instâncias de membro que usam qualquer rede VPC na mesma região, desde que a rede VPC esteja no mesmo projeto que o serviço de back-end. Todas as VMs em um determinado grupo de instâncias precisam usar a mesma rede VPC.

Grupos de instâncias de back-end

Um balanceador de carga TCP/UDP externo distribui conexões entre as VMs de back-end contidas em grupos de instâncias gerenciadas ou não gerenciadas.

Os grupos de instâncias podem ser regionais ou zonais no escopo. Por design, o balanceador de carga TCP/UDP interno tem alta disponibilidade. Não é necessário realizar etapas especiais para tornar o balanceador de carga altamente disponível porque o mecanismo não depende de um único dispositivo ou instância de VM. Você só precisa garantir que as instâncias de VM de back-end sejam implantadas em várias zonas para que o balanceador de carga possa solucionar possíveis problemas em qualquer zona.

  • Grupos gerenciados de instâncias regionais Use grupos de instâncias regionais gerenciados se puder implantar o software usando modelos de instância. Os grupos de instâncias gerenciadas por região distribuem automaticamente o tráfego entre várias zonas, fornecendo a melhor opção para evitar possíveis problemas em qualquer zona.

    Veja abaixo um exemplo de implantação usando um grupo de instâncias gerenciadas por região. O grupo de instâncias tem um modelo de instância que define como as instâncias devem ser provisionadas e cada grupo implanta instâncias dentro de três zonas da região us-central1.

    Balanceador de carga de rede com grupo de instâncias gerenciadas por região
    Balanceamento de carga de rede com um grupo de instâncias gerenciadas por região
  • Grupos de instâncias gerenciadas ou não gerenciadas por zona. Use grupos de instâncias zonais em diferentes zonas (na mesma região) para se proteger contra possíveis problemas em qualquer zona.

    Veja aqui um exemplo de implantação usando grupos de instâncias zonais. Esse balanceador de carga fornece disponibilidade em duas zonas.

    Balanceador de carga de rede com grupos de instâncias zonais
    Balanceamento de carga de rede com grupos de instâncias zonais

Verificações de integridade

O balanceamento de carga de rede usa verificações de integridade regionais para determinar quais instâncias podem receber novas conexões. Cada serviço de back-end do balanceador de carga de rede precisa estar associado a uma verificação de integridade regional. Os balanceadores de carga usam o status da verificação de integridade para determinar como rotear novas conexões para instâncias de back-end.

Para mais detalhes sobre como as verificações de integridade do Google Cloud funcionam, consulte Como funcionam as verificações de integridade.

O balanceamento de carga de rede é compatível com os seguintes tipos de verificações de integridade:

Verificações de integridade e tráfego UDP

O Google Cloud não oferece uma verificação de integridade que use o protocolo UDP. Ao usar o balanceamento de carga de rede com tráfego UDP, é preciso executar um serviço baseado em TCP nas VMs de back-end para fornecer informações sobre a verificação de integridade.

Nessa configuração, as solicitações de clientes são balanceadas com carga usando o protocolo UDP e um serviço TCP é usado para enviar informações a quem faz as sondagens de verificação de integridade do Google Cloud. Por exemplo, é possível executar um servidor HTTP simples em cada VM de back-end que retorna uma resposta HTTP 200 para as sondagens de verificação de integridade. Neste exemplo, é preciso usar a própria lógica em execução na VM de back-end para garantir que o servidor HTTP exiba 200 apenas se o serviço UDP estiver configurado e em execução corretamente.

Regras de firewall

Como o balanceamento de carga de rede é um balanceador de carga de passagem, você controla o acesso aos back-ends do balanceador de carga usando as regras de firewall do Google Cloud. Para aceitar o tráfego de qualquer endereço IP na Internet, você precisa criar uma regra de firewall de permissão de entrada para o protocolo e as portas relevantes usando o intervalo de origem 0.0.0.0/0. Para permitir apenas o tráfego de determinados intervalos de endereços IP, use intervalos de origem mais restritivos.

Além disso, como o balanceamento de carga de rede usa verificações de integridade do Google Cloud, sempre permita o tráfego dos intervalos de endereços IP da verificação de integridade. Essas regras de firewall de permissão de entrada podem ser específicas ao protocolo e às portas da verificação de integridade do balanceador de carga.

Caminho de retorno

O balanceamento de carga da rede usa rotas especiais fora da rede VPC para direcionar solicitações de entrada e sondagens de verificação de integridade a cada VM de back-end.

O balanceador de carga preserva os endereços IP de origem dos pacotes. As respostas das VMs de back-end vão diretamente para os clientes, e não voltam pelo balanceador de carga. O termo do setor para isso é retorno direto do servidor.

Arquitetura da VPC compartilhada

Todos os componentes de um balanceador de carga de rede precisam existir no mesmo projeto, exceto o endereço IP. A tabela a seguir resume os componentes da VPC compartilhada para o balanceamento de carga de rede:

Endereço IP Regra de encaminhamento Componentes de back-end
Um endereço IP externo regional precisa ser definido no mesmo projeto que o balanceador de carga ou no projeto host da VPC compartilhada. A Uma regra de encaminhamento externo regional precisa ser definida no mesmo projeto que as instâncias no serviço de back-end. O serviço de back-end regional precisa ser definido no mesmo projeto e na mesma região em que estão as instâncias no grupo de instâncias de back-end. As verificações de integridade associadas ao serviço de back-end precisam ser definidas no mesmo projeto e na mesma região do serviço de back-end.

Distribuição de tráfego

A maneira como um balanceador de carga de rede distribui novas conexões depende de você ter configurado o failover:

  • Se você não tiver configurado o failover, um balanceador de carga de rede distribuirá novas conexões para as VMs de back-end íntegras se pelo menos uma VM de back-end estiver íntegra. Quando todas as VMs de back-end não estiverem íntegras, o balanceador de carga distribuirá novas conexões entre todos os back-ends como um último recurso. Nessa situação, o balanceador de carga roteia cada nova conexão para uma VM de back-end não íntegra.

  • Se você tiver configurado o failover, um balanceador de carga de rede distribuirá novas conexões entre VMs no pool ativo, de acordo com uma política de failover que você configurar. Quando todas as VMs de back-end não estiverem íntegras, poderá escolher um dos seguintes comportamentos:

    • (Padrão) O balanceador de carga distribui o tráfego apenas para as VMs primárias. Isso é feito como último recurso. As VMs de backup são excluídas dessa distribuição de conexões mais recente.
    • O balanceador de carga está configurado para descartar o tráfego.

Rastreamento de conexão e hash consistente

O balanceamento de carga de rede usa uma tabela de rastreamento de conexão e um algoritmo de hash consistente configurável para determinar como o tráfego é distribuído para VMs de back-end.

Se o balanceador de carga tiver uma entrada na tabela de rastreamento de conexão para um pacote de entrada que faz parte de uma conexão estabelecida anteriormente, o pacote será enviado à VM de back-end que o balanceador de carga determinou anteriormente. O back-end determinado anteriormente foi gravado na tabela de rastreamento de conexões do balanceador de carga.

Quando o balanceador de carga recebe um pacote que não tem uma entrada de rastreamento de conexão, o balanceador de carga faz o seguinte:

  • Se nenhuma afinidade de sessão foi configurada, o balanceador de carga cria um hash de cinco tuplas do endereço IP de origem do pacote, a porta de origem, o endereço IP de destino, a porta de destino e o protocolo. Ele usa esse hash para selecionar um back-end que está íntegro.
  • Se você tiver configurado uma opção de afinidade de sessão, o balanceador de carga ainda criará um hash, mas com menos informações, conforme descrito em afinidade da sessão.
  • Se o pacote for TCP ou se for um pacote UDP em que a afinidade da sessão esteja definida como algo diferente de NONE, o balanceador de carga registrará o back-end selecionado na tabela de rastreamento de conexão. As entradas da tabela de rastreamento de conexão expiram após 60 segundos se não forem usadas.

Comportamento de conexão persistente

  • Tráfego TCP Para pacotes TCP, o estado de verificação de integridade de uma VM de back-end só controla a distribuição de pacotes para conexões new. Enquanto uma VM de back-end permanecer como membro do grupo de instâncias e, enquanto esse grupo de instâncias permanecer configurado como back-end para o balanceador de carga, os pacotes que fazem parte da mesma conexão TCP serão enviados para o VM de back-end selecionada anteriormente, mesmo se o estado da verificação de integridade dessa VM tiver mudado para não íntegra. Se o back-end não íntegro responder a pacotes, a conexão não será interrompida. Se o back-end não íntegro recusar os pacotes ou não responder a ele, o cliente poderá tentar novamente com uma nova conexão, e um back-end íntegro e diferente poderá ser selecionado para a conexão repetida.

    Se você remover uma VM de back-end do grupo de instâncias ou remover o grupo de instâncias do serviço de back-end, as conexões estabelecidas serão mantidas somente conforme descrito em redução de conexão.

  • Tráfego UDP. Como o tráfego UDP não tem sessão, por padrão, todos os pacotes UDP são processados sem o uso de uma tabela de rastreamento de conexão. As conexões UDP não são mantidas em back-ends não íntegros. Porém, se a afinidade da sessão for definida como qualquer valor diferente de NONE, as conexões UDP serão rastreadas (a exemplo das conexões TCP), mas as conexões UDP não são mantidas em back-ends não íntegros (diferentemente das conexões TCP);

A tabela a seguir resume quando o balanceador de carga emprega o rastreamento de conexão e o comportamento da conexão persistente para cada protocolo.

Protocolo Rastreamento de conexão Manutenção de conexões em back-ends prejudiciais
TCP Sempre ativado SIM
UDP Padrão: DESATIVADO
O acompanhamento de conexões é ATIVADO quando a afinidade da sessão
está definida como um valor diferente de NONE.
NÃO

Opções de afinidade de sessão

A afinidade de sessão controla a distribuição de novas conexões de clientes para as VMs de back-end do balanceador de carga. Por exemplo, é possível direcionar novas conexões do mesmo cliente para a mesma VM de back-end, sujeitas aos conceitos discutidos na seção sobre rastreamento de conexão e hash consistente.

Os balanceadores de carga de rede são compatíveis com as seguintes opções de afinidade de sessão, que você especifica para todo o serviço de back-end externo regional, e não por grupo de instâncias de back-end.

Afinidade da sessão Método de hash consistente Rastreamento de conexão Observações
Nenhum
(NONE)
Hash de 5 tuplas Rastreamento de 5 tuplas somente para TCP Na verdade, é o mesmo que IP do cliente, Porta do cliente, IP de destino, Porta de destino, Protocolo (hash de cinco tuplas).
Para UDP, o rastreamento de conexão está desativado por padrão.
IP do cliente, IP de destino
(CLIENT_IP)
Hash de duas tuplas:
• endereço IP de origem do pacote
• endereço IP de destino do pacote
Rastreamento de cinco tuplas para TCP e UDP Use essa opção quando precisar que todas as conexões do mesmo endereço IP de origem sejam veiculadas pela mesma VM de back-end.
IP do cliente, IP de destino, protocolo
(CLIENT_IP_PROTO)
Hash de três tuplas de:
• endereço IP de origem do pacote
• endereço IP de destino do pacote
• protocolo
Rastreamento de cinco tuplas para TCP e UDP
IP do cliente, porta do cliente, IP de destino, porta de destino, protocolo (5 tuplas)
(CLIENT_IP_PORT_PROTO)
Hash de 5 tuplas Rastreamento de cinco tuplas para TCP e UDP Para TCP, isso é equivalente a NONE.
Para UDP, essa opção ativa o rastreamento de conexão.

Diminuição da conexão

A diminuição da conexão é um processo aplicado a sessões TCP estabelecidas quando você remove uma VM de back-end de um grupo de instâncias ou quando um grupo de instâncias gerenciadas remove uma VM de back-end (por substituição, abandono, durante o lançamento de upgrades ou na redução do escalonamento vertical).

Por padrão, a diminuição de conexão está ativada. Quando ativada, ela permite que as conexões TCP estabelecidas permaneçam até que a VM não exista mais. Se você desativar a diminuição da conexão, as conexões TCP estabelecidas serão encerradas o mais rápido possível.

Para mais detalhes sobre como a diminuição da conexão é acionada e como ativá-la, consulte Como ativar a diminuição da conexão.

Failover

Configure um balanceador de carga TCP/UDP externo para distribuir conexões entre instâncias de máquina virtual (VM, na sigla em inglês) em grupos de instâncias de back-end primário e depois troque para os grupos de instância de back-end, se necessário. Com o failover, você garante um método para aumentar a disponibilidade e ter maior controle sobre como gerenciar a carga de trabalho quando as VMs de back-end principais não estiverem íntegras.

Por padrão, quando você adiciona um back-end ao serviço de back-end de um balanceador de carga de rede, ele é primário. Para designá-lo como back-end de failover, faça isso quando adicioná-lo ao serviço de back-end do balanceador de carga ou edite esse serviço posteriormente.

Para mais detalhes sobre como funciona o failover, consulte a Visão geral do failover para o balanceamento de carga de rede.

Fragmentação UDP

No balanceamento de carga dos pacotes UDP, é importante lembrar que:

  • os pacotes não fragmentados são processados normalmente em todas as configurações;
  • Os pacotes UDP podem se tornar fragmentados antes de entrar em contato com o Google Cloud. As redes que não são do Google Cloud podem atrasar pacotes UDP fragmentados porque aguardam a chegada de todos os fragmentos ou perdem os pacotes fragmentados por completo. As redes do Google Cloud encaminham fragmentos UDP à medida que chegam.

Se você espera pacotes UDP fragmentados, faça o seguinte:

  • Use apenas uma regra de encaminhamento UDP por endereço IP com carga balanceada e configure a regra de encaminhamento para aceitar o tráfego em todas as portas. Isso garante que todos os fragmentos cheguem à mesma regra de encaminhamento, mesmo que não tenham a mesma porta de destino. Para configurar todas as portas, defina --ports=ALL usando gcloud ou defina allPorts como True usando a API.
  • Defina a afinidade da sessão como None (NONE). Isso indica que a manutenção da afinidade não é necessária e, portanto, o balanceador de carga usa hash de cinco tuplas para selecionar um back-end para pacotes não fragmentados, mas hash de três tuplas para pacotes fragmentados.

Com essas configurações, os fragmentos UDP do mesmo pacote são encaminhados para a mesma instância para serem remontados.

Como usar instâncias de destino como back-ends

Se você estiver usando instâncias de destino como back-ends para o balanceador de carga de rede e espera pacotes UDP fragmentados, use apenas uma regra de encaminhamento UDP por endereço IP com carga balanceada. e configure a regra de encaminhamento para aceitar o tráfego em todas as portas. Isso garante que todos os fragmentos cheguem à mesma regra de encaminhamento, mesmo que não tenham a mesma porta de destino. Para configurar todas as portas, defina --ports=ALL usando gcloud ou defina allPorts como True usando a API.

Limitações

  • Os NEGs não são compatíveis como back-ends para balanceadores de carga de rede.
  • Os balanceadores de carga de rede baseados em serviço de back-end não são compatíveis com o Google Kubernetes Engine.
  • Para serviços de back-end associados a balanceadores de carga de rede, a saída do comando gcloud compute backend-services get-health retorna apenas os endereços IP internos dos back-ends, não o endereço IP externo de a regra de encaminhamento atribuída às instâncias.

A seguir