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 externo entre instâncias de máquina virtual (VM) na mesma região.

É possível configurar um balanceador de carga de rede para tráfego TCP, UDP, ESP, GRE, ICMP e ICMPv6.

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 balanceamento de carga são recebidos por VMs de back-end com os endereços IP de origem e destino do pacote e, se o protocolo for baseado em portas, as portas de origem e de destino inalteradas.
  • 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 (DSR, na sigla em inglês).

Os balanceadores de carga de rede com base em serviço de back-end têm as seguintes características:

• Back-ends de grupos gerenciados de instâncias. Os balanceadores de carga de rede baseados em serviço de back-end são compatíveis com o uso de grupos gerenciados de instâncias 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.
• Compatível com conectividade IPv6. Os balanceadores de carga de rede baseados em serviço de back-end podem processar tráfego IPv4 e IPv6.
• Controle de distribuição de tráfego detalhado. Uma configuração de serviço de back-end contém um conjunto de valores, como verificações de integridade, afinidade da sessão e rastreamento de conexão, políticas de drenagem da conexão e failover. A maioria dessas configurações tem valores padrão que permitem começar rapidamente.
• Verificações de integridade. 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.
• Integração com o Google Cloud Armor. O Google Cloud Armor é compatível com a proteção avançada contra DDoS de rede para balanceadores de carga de rede. Para mais informações, consulte Configurar proteção avançada contra DDoS de rede.

Balanceamento de carga para aplicativos do GKE

Se você estiver criando aplicativos no GKE, recomendamos usar o controlador de serviços do GKE integrado, que implanta balanceadores de carga do Google Cloud em nome dos usuários do GKE. Isso é o mesmo que a arquitetura de balanceamento de carga independente descrita nesta página, exceto pelo fato de o ciclo de vida dela ser totalmente automatizado e controlado pelo GKE.

Documentação relacionada do GKE:

• Conceitos do serviço LoadBalancer
• Como exibir aplicativos que usam serviços

Arquitetura

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

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 que permitam que o tráfego de balanceamento de carga e as sondagens de verificação de integridade alcancem as VMs de back-end.

Endereço IP

Um balanceador de carga de rede requer pelo menos uma regra de encaminhamento. A regra de encaminhamento faz referência a um endereço IP externo regional que pode ser acessado em qualquer lugar da Internet.

• Para o Tráfego IPv4, a regra de encaminhamento faz referência a um único endereço IPv4 externo regional. Os endereços IPv4 externos regionais vêm de um pool exclusivo para cada região do Google Cloud. O endereço IP pode ser um endereço estático reservado ou um endereço temporário.

• Para tráfego IPv6, a regra de encaminhamento faz referência a um intervalo /96 de endereços IP do intervalo /64 de endereços IPv6 externos da sub-rede. A sub-rede precisa ser uma sub-rede de pilha dupla com o ipv6-access-type definido como EXTERNAL. Os endereços IPv6 externos estão disponíveis apenas no nível Premium. A reserva de um endereço IPv6 externo regional é compatível apenas com instâncias. Portanto, use um endereço IPv6 temporário para a regra de encaminhamento.

  Observação: Para mais detalhes sobre a compatibilidade com IPv6, consulte a documentação da VPC sobreIntervalos de sub-rede IPv6 e Endereços IPv6.

Use um endereço IP reservado para regra de encaminhamento 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 é compatível com os níveis Standard e Premium para endereços IPv4 externos regionais. O endereço IP e a regra de encaminhamento precisam usar o mesmo nível de rede. Os endereços IPv6 externos regionais estão disponíveis apenas no nível Premium.

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 transmitem o tráfego para back-ends no mesmo protocolo e na mesma porta se o pacote transportar informações de 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 é um endereço associado à regra de encaminhamento do balanceador de carga.

O tráfego de entrada é combinado com uma regra de encaminhamento, que é uma combinação de um determinado endereço IP (seja um endereço IPv4 ou um intervalo de endereços IPv6), protocolo e, se o protocolo for baseado em portas, uma das portas, um intervalo de portas ou todas as portas. A regra de encaminhamento direciona o tráfego para o serviço de back-end do balanceador de carga.

• Se a regra de encaminhamento fizer referência a um endereço IPv4, ela não estará associada a nenhuma sub-rede. Ou seja, o endereço IP dela vem de fora de qualquer intervalo de sub-rede do Google Cloud.

• Se a regra de encaminhamento fizer referência a um endereço IPv6, ela precisará ser associada a uma sub-rede, e essa sub-rede precisa (a) ser de pilha dupla e (b) ter --ipv6-access-type definido comoEXTERNAL.

Um balanceador de carga de rede requer pelo menos uma regra de encaminhamento. As regras de encaminhamento podem ser configuradas para direcionar o tráfego proveniente de um intervalo específico de endereços IP de origem para um serviço de back-end específico (ou instância de destino). Para ver mais detalhes, consulte Direcionamento de tráfego. Defina várias regras de encaminhamento para o mesmo balanceador de carga, conforme descrito em Várias regras de encaminhamento.

Se você quiser que o balanceador de carga processe tráfego IPv4 e IPv6, crie duas regras de encaminhamento: uma regra para tráfego IPv4 que aponte para back-ends de IPv4 (ou pilha dupla) e uma regra para tráfego IPv6 que aponte somente para back-ends de pilha dupla. É possível ter uma regra de encaminhamento IPv4 e uma de IPv6 para fazer referência ao mesmo serviço de back-end, mas ele precisa fazer referência aos back-ends de pilha dupla.

Protocolos da regra de encaminhamento

O balanceamento de carga de rede é compatível com as seguintes opções de protocolo para cada regra de encaminhamento: TCP, UDP e L3_DEFAULT.

Use as opções TCP e UDP para configurar o balanceamento de carga TCP ou UDP. A opção de protocolo L3_DEFAULT permite que um balanceador de carga de rede faça o balanceamento de carga de tráfego TCP, UDP, ESP, ICMP e ICMPv6.

Além da compatibilidade com protocolos diferentes de TCP e UDP, L3_DEFAULT possibilita que uma única regra de encaminhamento exiba vários protocolos. Por exemplo, os serviços IPSec geralmente processam alguma combinação de tráfego IKE e NAT-T baseado em ESP e UDP. A opção L3_DEFAULT permite que uma única regra de encaminhamento seja configurada para processar todos esses protocolos.

As regras de encaminhamento que usam os protocolos TCP ou UDP podem fazer referência a um serviço de back-end que usa o mesmo protocolo que a regra de encaminhamento ou um serviço de back-end cujo protocolo seja UNSPECIFIED. As regras de encaminhamento L3_DEFAULT só podem referenciar um serviço de back-end com protocolo UNSPECIFIED.

Se você estiver usando o protocolo L3_DEFAULT, vai precisar configurar a regra de encaminhamento para aceitar o tráfego em todas as portas. Para configurar todas as portas, defina --ports=ALL usando a CLI do Google Cloud ou defina allPorts como True usando a API.

A tabela a seguir resume como usar essas configurações para protocolos diferentes.

Tráfego para balanceamento de carga	Protocolo da regra de encaminhamento	Protocolo do serviço de back-end
TCP	TCP	TCP ou UNSPECIFIED
	L3_DEFAULT	UNSPECIFIED
UDP	UDP	UDP ou UNSPECIFIED
	L3_DEFAULT	UNSPECIFIED
ESP, GRE, ICMP/ICMPv6 (somente solicitação de eco)	L3_DEFAULT	UNSPECIFIED

Várias regras de encaminhamento

É possível configurar várias regras de encaminhamento externo regionais para o mesmo balanceador de carga de rede. 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 protocolos diferentes e portas ou intervalos de portas não sobrepostos para o mesmo endereço IP externo.
• Você precisa direcionar o tráfego de determinados endereços IP de origem para back-ends específicos do balanceador de carga.

O Google Cloud exige que os pacotes de entrada não correspondam a mais de uma regra de encaminhamento. Exceto pelas regras de encaminhamento de disco, que serão discutidas na próxima seção, duas ou mais regras de encaminhamento que usam o mesmo endereço IP externo regional precisam ter combinações exclusivas de protocolo e porta de acordo com estas restrições:

• Uma regra de encaminhamento configurada para todas as portas de um protocolo impede a criação de outras regras de encaminhamento usando o mesmo protocolo e endereço IP. As regras de encaminhamento usando protocolos TCP ou UDP podem ser configuradas para usar todas as portas ou podem ser configuradas para portas específicas. Por exemplo, se você criar uma regra de encaminhamento usando endereços IP198.51.100.1 , oTCP e todas as portas, não é possível criar outra regra de encaminhamento usando endereços IP. 198.51.100.1 eTCP protocolo. É possível criar duas regras de encaminhamento, usando o endereço IP 198.51.100.1 e o protocolo TCP, se cada uma tiver portas únicas ou intervalos de portas não sobrepostos. Por exemplo, é possível criar duas regras de encaminhamento usando o endereço IP 198.51.100.1 e o protocolo TCP, em que uma porta da regra de encaminhamento é 80,443 e a outra usa o intervalo de portas 81-442.
• Apenas uma regra de encaminhamento L3_DEFAULT pode ser criada por endereço IP. Isso ocorre porque o protocolo L3_DEFAULT usa todas as portas por definição. Nesse contexto, o termo "todas as portas" inclui protocolos sem informações de porta.

• Uma única regra de encaminhamento L3_DEFAULT pode coexistir com outras regras que usam protocolos específicos (TCP ou UDP). A regra de encaminhamento L3_DEFAULT pode ser usada como último recurso ao encaminhar regras usando o mesmo endereço IP, mas existirem protocolos mais específicos. Uma regra de encaminhamento L3_DEFAULT processará pacotes enviados para o endereço IP de destino se e somente se o endereço IP, o protocolo e a porta de destino do pacote não corresponderem a uma regra de encaminhamento específica do protocolo.
  

  Para ilustrar isso, considere estes dois cenários. Nas duas situações, as regras de encaminhamento usam o mesmo endereço IP 198.51.100.1.

  • Cenário 1. A primeira regra de encaminhamento usa o protocolo L3_DEFAULT. A segunda regra de encaminhamento usa o protocolo TCP e todas as portas. Os pacotes TCP enviados para qualquer porta de destino de 198.51.100.1 são processados pela segunda regra de encaminhamento. Os pacotes que usam protocolos diferentes são processados pela primeira regra de encaminhamento.
  • Cenário 2. A primeira regra de encaminhamento usa o protocolo L3_DEFAULT. A segunda regra de encaminhamento usa o protocolo TCP e a porta 8080. Os pacotes TCP enviados para 198.51.100.1:8080 são processados pela segunda regra de encaminhamento. Todos os outros pacotes, incluindo pacotes TCP enviados para diferentes portas de destino, são processados pela primeira regra de encaminhamento.

Seleção de regra de encaminhamento

O Google Cloud seleciona uma ou nenhuma regra de encaminhamento para processar um pacote recebido usando esse processo de eliminação, começando pelo conjunto de candidatos de regra de encaminhamento que correspondem ao endereço IP de destino do pacote:

• Elimine as regras de encaminhamento que não correspondem ao protocolo do pacote, exceto as regras de encaminhamento L3_DEFAULT. As regras de encaminhamento que usam o protocolo L3_DEFAULT nunca são eliminadas por esta etapa porque L3_DEFAULT corresponde a todos os protocolos. Por exemplo, se o protocolo do pacote for TCP, apenas as regras de encaminhamento que usam o protocolo UDP serão eliminadas.

• Elimine as regras de encaminhamento cuja porta não corresponde à do pacote. As regras de encaminhamento configuradas para todas as portas nunca são eliminadas nesta etapa, porque uma regra corresponde a qualquer porta.

• Se as outras regras de encaminhamento incluirem L3_DEFAULT e regras de encaminhamento específicas do protocolo, elimine as regras de encaminhamento L3_DEFAULT. Se todos os candidatos restantes forem L3_DEFAULT, nenhuma será eliminada nesta etapa.

• Neste momento, os candidatos restantes da regra de encaminhamento se enquadram em uma das seguintes categorias:

  • Uma única regra de encaminhamento permanece, que corresponde ao endereço IP, ao protocolo e à porta do pacote do pacote, e é usada para rotear o pacote.
  • Dois ou mais candidatos de regra de encaminhamento permanecem correspondentes ao endereço IP, ao protocolo e à porta do pacote. Isso significa que os candidatos restantes da regra de encaminhamento incluem guiar as regras de encaminhamento (discutidas na próxima seção). Selecione a regra de encaminhamento de direcionamento cujo intervalo origem inclui o CIDR mais específico (correspondência de prefixo mais longa) que contém o endereço IP de origem do pacote. Se nenhuma regra de encaminhamento de direcionamento tiver um intervalo de origem, incluindo o endereço IP de origem do pacote, selecione a regra de encaminhamento principal.
  • Os candidatos da regra de encaminhamento zero permanecem e o pacote é descartado.

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.

Direcionamento de tráfego.

Visualização

Este produto ou recurso é coberto pelos Termos de ofertas pré-GA dos Termos de Serviço do Google Cloud. Os produtos e recursos pré-GA podem ter suporte limitado, e as mudanças neles podem não ser compatíveis com outras versões pré-GA. Para mais informações, consulte as descrições da fase de lançamento.

As regras de encaminhamento para balanceadores de carga de rede podem ser configuradas para direcionar o tráfego proveniente de um intervalo específico de endereços IP de origem para um serviço de back-end específico (ou instância de destino).

O direcionamento de tráfego é útil para solucionar problemas e configurações avançadas. Com o direcionamento de tráfego, é possível direcionar determinados clientes para um conjunto diferente de back-ends, uma configuração diferente para os serviços de back-end ou ambos. Exemplo:

• O direcionamento de tráfego permite criar duas regras de encaminhamento que direcionam o tráfego para o mesmo grupo de instâncias de back-end por meio de dois serviços de back-end. Os dois serviços de back-end podem ser configurados com diferentes verificações de integridade, afinidades de sessão ou políticas de controle de distribuição de tráfego distintas (rastreamento de conexão, diminuição de conexão e failover).
• O direcionamento de tráfego permite criar duas regras de encaminhamento que direcionam o tráfego para diferentes serviços de back-end, com diferentes grupos de instâncias de back-end. Por exemplo, um grupo de instâncias pode ser configurado usando diferentes tipos de máquina para processar melhor o tráfego de um determinado conjunto de endereços IP de origem.

O direcionamento de tráfego é configurado com um parâmetro de API de regra de encaminhamento chamado sourceIPRanges. As regras de encaminhamento que têm pelo menos um intervalo de IP de origem configurado são chamadas de regras de encaminhamento de direcionamento.

Uma regra de encaminhamento de direção pode ter uma lista de até 64 intervalos de IP de origem. É possível atualizar a lista de intervalos de IP de origem configurados para uma regra de encaminhamento de direcionamento a qualquer momento.

Cada regra de encaminhamento de direcionamento exige que você primeiro crie uma regra de encaminhamento mãe. As regras de encaminhamento pai e direcionamento compartilham o mesmo endereço IP externo regional, protocolo IP e informações da porta. No entanto, a regra de encaminhamento pai não tem informações de endereço IP de origem. Exemplo:

• Regra de encaminhamento pai: endereço IP: 198.51.100.1, protocolo IP: TCP, portas: 80
• Regra de encaminhamento de direcionamento: endereço IP: 198.51.100.1, protocolo IP: TCP, portas: 80, sourceIPRanges: 203.0.113.0/24

Uma regra de encaminhamento pai que aponta para um serviço de back-end pode ser associada a uma regra de encaminhamento de direcionamento que aponta para um serviço de back-end ou uma instância de destino.

Para uma determinada regra de encaminhamento pai, duas ou mais regras de encaminhamento podem ter intervalos de IP de origem sobrepostos, mas não idênticos. Por exemplo, uma regra de encaminhamento pode ter o intervalo de IP de origem 203.0.113.0/24 e outra regra de encaminhamento pode ter o intervalo de IP de origem 203.0.113.0.

Exclua todas as regras de encaminhamento de direcionamento antes de excluir a regra de encaminhamento principal de que elas dependem.

Para saber como os pacotes de entrada são processados ao controlar as regras de encaminhamento, consulte Seleção da regra de encaminhamento.

Comportamento de afinidade da sessão nas mudanças de direção

Nesta seção, descrevemos as condições em que a afinidade da sessão pode ser interrompida quando os intervalos de IP de origem das regras de encaminhamento de direção são atualizados:

• Se uma conexão atual continuar a corresponder à mesma regra de encaminhamento depois que você alterar os intervalos de IP de origem de uma regra de encaminhamento de direcionamento, a afinidade de sessão não será interrompida. Se a mudança resultar em uma conexão existente correspondente a uma regra de encaminhamento diferente, faça o seguinte:
• A afinidade da sessão sempre é interrompida nestas circunstâncias:
  • A regra de encaminhamento recém-correspondida direciona uma conexão estabelecida para um serviço de back-end (ou instância de destino) que não faz referência à VM de back-end selecionada anteriormente.
  • A regra de encaminhamento recém-correspondida direciona uma conexão estabelecida para um serviço de back-end que faz referência à VM de back-end selecionada anteriormente, mas o serviço de back-end não está configurado para manter conexões quando os back-ends não forem íntegros e a VM de back-end falha na verificação de integridade do serviço de back-end.
• A afinidade de sessão pode ser interrompida quando a regra de encaminhamento recém-correspondida direciona uma conexão estabelecida para um serviço de back-end e esse serviço faz referência à VM selecionada anteriormente, mas a combinação do serviço de back-end de afinidade de sessão e modo de rastreamento de conexão resulta em um hash diferente do acompanhamento de conexões.

Como manter a afinidade da sessão em todas as mudanças de direção

Veja nesta seção como evitar a interrupção da afinidade de sessão quando os intervalos de IP de origem das regras de encaminhamento de direção forem atualizados:

• Direcionamento de regras de encaminhamento que apontam para serviços de back-end. Se a regra mãe e a de encaminhamento de apontarem para serviços de back-end, você precisará verificar manualmente se as configurações de afinidade da sessão e política de rastreamento de conexão sãoidênticos. O Google Cloud não rejeitará automaticamente as configurações se elas não forem idênticas.
• Direcionamento de regras de encaminhamento que apontam para instâncias de destino. Uma regra de encaminhamento pai que aponta para um serviço de back-end pode ser associada a uma regra de encaminhamento de direcionamento que aponta para uma instância de destino. Nesse caso, a regra de encaminhamento principal herda as configurações de afinidade da sessão e de política de rastreamento de conexão da regra de encaminhamento pai.

Para ver instruções sobre como configurar o direcionamento de tráfego, consulte Configurar o direcionamento de tráfego.

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 no endereço IP e nas portas (se configurado) especificadas por uma ou mais regras de encaminhamento externo regionais. O serviço de back-end transmite pacotes para as VMs de back-end enquanto preserva os endereços IP de origem e destino do pacote, o protocolo e, se o protocolo for baseado em porta, as portas de origem e de destino.

  Os serviços de back-end usados com balanceadores de carga de rede são compatíveis com as seguintes opções de protocolo: TCP, UDP ou UNSPECIFIED.

  Os serviços de back-end com o protocolo UNSPECIFIED podem ser usados com qualquer regra de encaminhamento, não importa qual seja o protocolo da regra. Os serviços de back-end com um protocolo específico (TCP ou UDP) só podem ser referenciados por regras de encaminhamento com o mesmo protocolo (TCP ou UDP). As regras de encaminhamento com o protocolo L3_DEFAULT só podem referenciar serviços de back-end com o protocolo UNSPECIFIED.

  Consulte Especificação de protocolo de regra de encaminhamento para ver uma tabela com possíveis combinações de regra de encaminhamento e protocolo de serviço de back-end.

• Distribuição de tráfego. Com um serviço de back-end, é possível distribuir o tráfego de acordo com as políticas configuráveis de afinidade da sessão e rastreamento de conexão. Também é possível configurar o serviço de back-end para ativar a diminuição da 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.

Se você quiser que o balanceador de carga seja compatível com o tráfego IPv6, o serviço de back-end precisará fazer referência aos back-ends que atendam aos requisitos para processar tráfego IPv6.

Grupos de instâncias de back-end

Um balanceador de carga de rede distribui conexões entre as VMs de back-end contidas em grupos de instâncias gerenciados ou não gerenciados. Os grupos de instâncias podem ser regionais ou zonais no escopo.

Observação: por design, o balanceador de carga de rede tem alta disponibilidade. Não há etapas especiais para deixar 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.

  

  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.

  

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

Se você quiser que o balanceador de carga seja compatível com o tráfego IPv6, os back-ends precisarão atender a estes requisitos:

• Os back-ends precisam ser configurados em sub-redes de pilha dupla que estejam na mesma região da que a regra de encaminhamento IPv6 do balanceador de carga. Para os back-ends, é possível usar uma sub-rede com o ipv6-access-type definido como EXTERNAL ou INTERNAL. Para usar uma sub-rede com ipv6-access-type definido como INTERNAL, é preciso usar uma sub-rede de pilha dupla separada com ipv6-access-type definido como EXTERNAL para a regra de encaminhamento externo do balanceador de carga. Para ver instruções, consulte Adicionar uma sub-rede de pilha dupla.
• Os grupos de instâncias de back-end precisam ser configurados como pilhas duplas, com o --ipv6-network-tier definido como PREMIUM. Para instruções, consulte Criar um modelo de instância com endereços IPv6.

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:

• HTTP, HTTPS ou HTTP/2. Se as VMs de back-end veicularem tráfego usando HTTP, HTTPS ou HTTP/2, é melhor usar uma verificação de integridade correspondente a esse protocolo. Para detalhes, consulte Critérios de sucesso para verificações de integridade HTTP, HTTPS e HTTP/2.
• SSL ou TCP. ou : se suas VMs de back-end não veicularem tráfego do tipo HTTP, você deverá usar uma verificação de integridade de SSL ou TCP. Para mais detalhes, consulte Critérios de sucesso para verificações de integridade de SSL e TCP.

Verificações de integridade para outros tráfegos de protocolo

O Google Cloud não oferece verificações de integridade específicas de protocolo além das que são listadas aqui. Ao usar o balanceamento de carga de rede para balancear a carga de um protocolo que não seja TCP, ainda é necessário executar um serviço baseado em TCP nas VMs de back-end para fornecer as informações necessárias de verificação de integridade.

Por exemplo, se você estiver balanceando a carga do tráfego UDP, as solicitações de clientes passarão pelo balanceamento de carga usando o protocolo UDP e será necessário executar um serviço TCP para fornecer informações às sondagens de verificação de integridade do Google Cloud. Para isso, execute um servidor HTTP simples em cada VM de back-end que retorna uma resposta HTTP 200 para as sondagens de verificação de integridade. É 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. Crie regras de firewall de permissão de entrada ou política de firewall hierárquica de permissão de entrada para permitir verificações de integridade e o tráfego com balanceamento de carga.

As regras de encaminhamento e de entrada permitem que as regras de firewall ou as políticas hierárquicas de firewall funcionem juntas da seguinte maneira: uma regra de encaminhamento especifica o protocolo e, se definido, os requisitos de porta que um pacote precisa atender para ser encaminhado para uma VM de back-end. As regras de firewall de permissão de entrada controlam se os pacotes encaminhados são entregues à VM ou descartados. Todas as redes VPC têm uma regra de firewall de entrada de negação implícita que bloqueia pacotes de entrada de qualquer origem. A rede VPC padrão do Google Cloud inclui um conjunto limitado de regras de firewall de permissão de entrada pré-preenchida.

• Para aceitar o tráfego de qualquer endereço IP na Internet, crie uma regra de firewall de permissão de entrada com 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.

• Como prática recomendada de segurança, a entrada permitida pelas regras de firewall só permite os protocolos e portas IP necessários. Restringir a configuração do protocolo (e, se possível, porta) é especialmente importante ao usar regras de encaminhamento cujo protocolo está definido como L3_DEFAULT. As regras de encaminhamento L3_DEFAULT encaminham pacotes para todos os protocolos IP compatíveis (em todas as portas se o protocolo e o pacote tiverem informações de porta).

• O balanceamento de carga de rede usa verificações de integridade do Google Cloud. Portanto, 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 para o protocolo e as portas da verificação de integridade do balanceador de carga.

Endereços IP para pacotes de solicitação e retorno

Quando uma VM de back-end recebe um pacote com carga balanceada de um cliente, a origem e o destino do pacote são os seguintes:

• Origem: o endereço IP externo associado a uma VM do Google Cloud ou um endereço IP roteável pela Internet de um sistema que se conecta ao balanceador de carga.
• Destino: o endereço IP da regra de encaminhamento do balanceador de carga.

Como o balanceador de carga é um balanceador de carga de transmissão, e não um proxy, os pacotes chegam carregando o endereço IP de destino da regra de encaminhamento do balanceador de carga. O software em execução nas VMs de back-end precisa ser configurado para fazer o seguinte:

• Detectar (vincular) o endereço IP da regra de encaminhamento do balanceador de carga ou qualquer endereço IP (0.0.0.0 ou ::).
• Se o protocolo da regra de encaminhamento do balanceador de carga suportar portas: detectar em (vincular) uma porta incluída na regra de encaminhamento do balanceador de carga

Os pacotes de retorno são enviados diretamente das VMs de back-end do balanceador de carga para o cliente. Os endereços IP de origem e de destino do pacote de retorno dependem do protocolo:

• O TCP é orientado por conexão. Assim, as VMs de back-end respondem com pacotes cujos endereços IP de origem correspondam ao endereço IP da regra de encaminhamento para que o cliente possa associar os pacotes de resposta à conexão TCP apropriada.
• UDP, ESP, GRE e ICMP não têm conexão. As VMs de back-end podem enviar pacotes de resposta com endereços IP de origem que correspondam ao endereço IP da regra de encaminhamento ou a qualquer endereço IP externo atribuído à VM. Na prática, a maioria dos clientes espera que a resposta seja do mesmo endereço IP que enviou os pacotes.

Nesta tabela, há um resumo das origens e dos destinos dos pacotes de resposta:

Tipo de tráfego	Origem	Destino
TCP	O endereço IP da regra de encaminhamento do balanceador de carga	A origem do pacote solicitante
UDP, ESP, GRE, ICMP	Na maioria dos casos de uso, o endereço IP da regra de encaminhamento do balanceador de carga ^†	A origem do pacote solicitante

^† Quando uma VM tem um endereço IP externo ou quando você está usando o Cloud NAT, também é possível definir o endereço IP de origem do pacote de resposta como o endereço IPv4 interno principal da VM de dados. O Google Cloud ou o Cloud NAT altera o endereço IP de origem do pacote de resposta para o endereço IPv4 externo da placa de rede (NIC, na sigla em inglês) ou o endereço IPv4 externo do Cloud NAT a fim de enviar o pacote de resposta para o endereço IP externo do cliente. Não usar o endereço IP da regra de encaminhamento como uma origem é um cenário avançado, porque o cliente recebe um pacote de resposta de um endereço IP externo que não corresponde ao endereço IP a que ele enviou um pacote de solicitação.

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.	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 de back-end íntegras, de acordo com uma política de failover que você configurar. Quando todas as VMs de back-end não estiverem íntegras, será possível 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 descarta o tráfego.

Para detalhes sobre como as conexões são distribuídas, consulte a próxima seção Seleção de back-end e rastreamento de conexão.

Para detalhes sobre o funcionamento do failover, consulte a seção Failover.

Seleção de back-ends e rastreamento de conexão

O balanceamento de carga de rede usa seleção configurável de back-end e algoritmos de rastreamento de conexão para determinar como o tráfego é distribuído para as VMs de back-end.

O balanceamento de carga de rede usa o algoritmo a seguir para distribuir pacotes entre as VMs de back-end (no pool ativo, se você tiver configurado o failover):

1. Se o balanceador de carga tiver uma entrada na tabela de rastreamento de conexão correspondente às características de um pacote de entrada, o pacote será enviado ao back-end especificado pela entrada da tabela de rastreamento de conexão. O pacote é considerado como parte de uma conexão estabelecida anteriormente. Portanto, o pacote é enviado à VM de back-end que o balanceador de carga determinou e registrou anteriormente na tabela de rastreamento de conexão.

2. 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:

   1. O balanceador de carga seleciona um back-end. O balanceador de carga calcula um hash com base na afinidade da sessão configurada. Ele usa esse hash para selecionar um back-end entre aqueles que são atualmente íntegros (a menos que todos os back-ends não estejam íntegros, caso em que todos os back-ends são considerados desde que política de failover não tenha sido configurada para descartar o tráfego nessa situação. A afinidade da sessão padrão, NONE, usa os seguintes algoritmos de hash:

      • Para pacotes UDP não fragmentados e TCP, um hash de cinco tuplas do endereço IP de origem do pacote, porta de origem, endereço IP de destino, porta de destino e protocolo
      • Para pacotes UDP fragmentados e todos os outros protocolos, um hash de três tuplas do endereço IP de origem do pacote, do endereço IP de destino e do protocolo

      A seleção de back-end pode ser personalizada com o uso de um algoritmo de hash que usa menos informações. Para todas as opções compatíveis, consulte opções de afinidade da sessão.

   2. O balanceador de carga adiciona uma entrada à tabela de rastreamento de conexão. Essa entrada registra o back-end selecionado para a conexão do pacote, de modo que todos os pacotes futuros dessa conexão sejam enviados para o mesmo back-end. O uso do rastreamento de conexão depende do protocolo:

      • Pacotes TCP. O rastreamento de conexão está sempre ativado e não pode ser desativado. Por padrão, o rastreamento de conexão é de cinco tuplas, mas pode ser configurado para ser menor que cinco tuplas. Quando é de cinco tuplas, os pacotes TCP SYN são tratados de maneira diferente. Ao contrário dos pacotes não SYN, eles descartam qualquer entrada de rastreamento de conexão correspondente e sempre selecionam um novo back-end.
        
        O rastreamento de conexão padrão de cinco tuplas é usado quando:

        • o modo de acompanhamento é PER_CONNECTION (todas as afinidades da sessão), ou,
        • o modo de acompanhamento é PER_SESSION e a afinidade da sessão é NONE, ou,
        • o modo de acompanhamento é PER_SESSION e a afinidade da sessão é CLIENT_IP_PORT_PROTO.

      • Pacotes UDP, ESP e GRE. O rastreamento de conexão é ativado somente se a afinidade da sessão estiver definida como algo diferente de NONE.

      • Pacotes ICMP e ICMPv6. Não é possível usar o rastreamento de conexão.

      Para mais detalhes sobre quando o acompanhamento de conexão é ativado e qual método de acompanhamento é usado, consulte Modo de rastreamento de conexão.

      Além disso, observe o seguinte:

      • Uma entrada na tabela de rastreamento de conexão expira 60 segundos após o balanceador de carga processar o último pacote que corresponde à entrada. Esse valor de tempo limite de inatividade de 60 segundos não é configurável.
      • Dependendo do protocolo, o balanceador de carga pode remover entradas da tabela de rastreamento de conexão quando os back-ends não estiverem íntegros. Para detalhes e como personalizar esse comportamento, consulte Persistência de conexão em back-ends não íntegros.

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. A afinidade da sessão é especificada para todo o serviço de back-end externo regional, não por grupo de instâncias de back-end.

O balanceamento de carga de rede é compatível com as seguintes opções de afinidade de sessão:

• Nenhum (NONE). Hash de cinco tuplas do endereço IP de origem, porta de origem, protocolo, endereço IP de destino e porta de destino
• IP do cliente, IP de destino (CLIENT_IP). Hash de duas tuplas de endereço IP de origem e endereço IP de destino
• IP do cliente, IP de destino, protocolo (CLIENT_IP_PROTO). Hash de três tuplas do endereço IP de origem, do endereço IP de destino e do protocolo
• IP do cliente, Porta do cliente, IP de destino, Porta de destino, Protocolo (CLIENT_IP_PORT_PROTO). Hash de cinco tuplas do endereço IP de origem, porta de origem, protocolo, endereço IP de destino e a porta de destino

Para saber como essas opções de afinidade de sessão afetam os métodos de rastreamento de conexão e seleção de back-end, consulte esta tabela.

Modo de rastreamento de conexão

A ativação do rastreamento de conexão depende apenas do protocolo do tráfego com carga balanceada e das configurações de afinidade da sessão. O modo de rastreamento especifica o algoritmo de rastreamento de conexão a ser usado quando o rastreamento de conexão está ativado. Há dois modos de acompanhamento: PER_CONNECTION (padrão) e PER_SESSION.

• PER_CONNECTION (padrão). Esse é o modo de acompanhamento padrão. Com esse modo de rastreamento de conexão, o tráfego TCP é sempre rastreado por cinco tuplas, independentemente da configuração de afinidade da sessão. Para o tráfego UDP, ESP e GRE, o acompanhamento de conexão é ativado quando a afinidade de sessão selecionada não é NONE. Os pacotes UDP, ESP e GRE são rastreados usando os métodos de rastreamento descritos nesta tabela.

• PER_SESSION. Se a afinidade da sessão for CLIENT_IP ou CLIENT_IP_PROTO, a configuração desse modo resultará em rastreamento de conexão de duas e três tuplas, respectivamente, para todos os protocolos, exceto ICMP que não é rastreável por conexão. Para outras configurações de afinidade da sessão, o modoPER_SESSION se comporta de maneira idêntica ao modo PER_CONNECTION.

Para saber como esses modos de rastreamento funcionam com diferentes configurações de afinidade de sessão para cada protocolo, consulte a tabela a seguir.

Seleção de back-end		Modo de rastreamento de conexão
Configuração de afinidade da sessão	Método de hash para seleção de back-end	PER_CONNECTION (padrão)	PER_SESSION
Padrão: sem afinidade da sessão (NONE)	TCP e UDP não fragmentado: hash de cinco tuplas UDP fragmentado e todos os outros protocolos: hash de três tuplas	TCP: rastreamento de conexão de cinco tuplas Todos os outros protocolos: rastreamento de conexão desativado	TCP: rastreamento de conexão de cinco tuplas Todos os outros protocolos: rastreamento de conexão desativado
IP do cliente, IP de destino (CLIENT_IP)	Todos os protocolos: hash de duas tuplas	TCP e UDP não fragmentado: rastreamento de conexão de cinco tuplas Fragmentação de UDP, ESP e GRE: rastreamento de conexão de três tuplas Todos os outros protocolos: rastreamento de conexão desativado	TCP, UDP, ESP, GRE: rastreamento de conexão de duas tuplas Todos os outros protocolos: rastreamento de conexão desativado
IP do cliente, IP de destino, protocolo (CLIENT_IP_PROTO)	Todos os protocolos: hash de três tuplas	TCP e UDP não fragmentado: rastreamento de conexão de cinco tuplas Fragmentação de UDP, ESP e GRE: rastreamento de conexão de três tuplas Todos os outros protocolos: rastreamento de conexão desativado	TCP, UDP, ESP, GRE: rastreamento de conexão de três tuplas Todos os outros protocolos: rastreamento de conexão desativado
IP do cliente, porta do cliente, IP de destino, porta de destino, protocolo (CLIENT_IP_PORT_PROTO)	TCP e UDP não fragmentado: hash de cinco tuplas UDP fragmentado e todos os outros protocolos: hash de três tuplas	TCP e UDP não fragmentado: rastreamento de conexão de cinco tuplas Fragmentação de UDP, ESP e GRE: rastreamento de conexão de três tuplas Todos os outros protocolos: rastreamento de conexão desativado	TCP e UDP não fragmentado: rastreamento de conexão de cinco tuplas Fragmentação de UDP, ESP e GRE: rastreamento de conexão de três tuplas Todos os outros protocolos: rastreamento de conexão desativado

Para saber como alterar o modo de rastreamento de conexão, consulte Configurar uma política de rastreamento de conexão.

Persistência de conexão em back-ends não íntegros

As configurações de persistência de conexão controlam se uma conexão existente persiste em um back-end selecionado depois que esse back-end se tornar não íntegro (contanto que o back-end permaneça no grupo de instâncias de back-end configurado do balanceador de carga).

O comportamento descrito nesta seção não se aplica aos casos em que você remove uma VM de back-end do grupo de instâncias ou remove o grupo de instâncias do serviço de back-end. Nesses casos, as conexões estabelecidas persistem apenas conforme descrito na diminuição de conexão.

As seguintes opções de persistência de conexão estão disponíveis:

• DEFAULT_FOR_PROTOCOL (padrão)
• NEVER_PERSIST
• ALWAYS_PERSIST

A tabela a seguir resume as opções de persistência de conexão e como as conexões persistem para diferentes protocolos, opções de afinidade da sessão e modos de rastreamento.

Persistência de conexão em back-ends não íntegros	Modo de rastreamento de conexão
	PER_CONNECTION	PER_SESSION
DEFAULT_FOR_PROTOCOL	TCP: as conexões permanecem em back-ends não íntegros (todas as afinidades da sessão) Todos os outros protocolos: as conexões nunca permanecem em back-ends não íntegros	TCP: conexões persistem em back-ends não íntegros se a afinidade da sessão é NONE ou CLIENT_IP_PORT_PROTO Todos os outros protocolos: as conexões nunca persistem em back-ends não íntegros.
NEVER_PERSIST	Todos os protocolos: as conexões nunca permanecem em back-ends não íntegros
ALWAYS_PERSIST	TCP: as conexões permanecem em back-ends não íntegros (todas as afinidades da sessão) ESP, GRE, UDP: as conexões permanecem em back-ends não íntegros se a afinidade da sessão não for NONE ICMP, ICMPv6:não aplicável porque não é possível acompanhar a conexão. Essa opção só deve ser usada para casos de uso avançados.	Não é possível configurar

Observação: quando o balanceador de carga move uma conexão de um back-end não íntegro, o balanceador de carga cria uma nova entrada na tabela de rastreamento. A nova entrada mapeia a conexão para um back-end diferente com base na afinidade da sessão configurada. A nova entrada permanece válida como qualquer outra entrada. Se o back-end não íntegro retornar como íntegro, isso sozinho não fará com que a entrada da tabela de rastreamento de conexão seja removida, a menos que acione um failback e diminuição da conexão em failover e failback tenha sido desativada).

Comportamento de persistência de conexão TCP em back-ends não íntegros

Sempre que uma conexão TCP com rastreamento de cinco tuplas persiste em um back-end não íntegro:

• Se o back-end não íntegro continuar a responder aos pacotes, a conexão continuará até que seja redefinida ou fechada (pelo back-end não íntegro ou pelo cliente).
• Se o back-end não íntegro enviar um pacote de redefinição de TCP (RST) ou não responder aos pacotes, o cliente poderá tentar novamente com uma nova conexão, permitindo que o balanceador de carga selecione um back-end íntegro e diferente. Os pacotes TCP SYN sempre selecionam um back-end novo e íntegro.

Para saber como alterar o comportamento de persistência de conexão, consulte Configurar uma política de rastreamento de conexão.

Diminuição da conexão

A diminuição da conexão é um processo aplicado a sessões estabelecidas quando:

• uma VM de back-end é removida de um grupo de instâncias; ou
• quando um grupo gerenciado de instâncias remove uma VM de back-end (por substituição, abandono, durante upgrades contínuos ou redução vertical); ou
• quando um grupo de instâncias é removido de um serviço de back-end.

Por padrão, a diminuição de conexão está desativada. Quando desativadas, as conexões estabelecidas são encerradas o mais rápido possível. Quando a diminuição da conexão estiver ativada, as conexões estabelecidas poderão persistir por um tempo limite configurável, após o qual a instância da VM de back-end será encerrada.

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.

Fragmentação UDP

Observação: as recomendações a seguir sobre como lidar com pacotes UDP fragmentados com balanceadores de carga de rede baseados em serviço de back-end são diferentes das recomendações para balanceadores herdados de carga de rede baseados em pool de destino.

Os balanceadores de carga de rede baseados em serviço de back-end podem processar pacotes UDP fragmentados e não fragmentados. Se o aplicativo usar pacotes UDP fragmentados, lembre-se do seguinte:

• Os pacotes UDP podem se tornar fragmentados antes de chegar a uma rede VPC do Google Cloud.
• As redes VPC do Google Cloud encaminham fragmentos UDP à medida que chegam (sem esperar que todos os fragmentos cheguem).
• As redes que não são do Google Cloud e os equipamentos de rede locais podem encaminhar fragmentos UDP assim que chegarem, atrasar pacotes UDP fragmentados até que todos os fragmentos tenham chegado ou descartar pacotes UDP fragmentados. Para ver mais detalhes, consulte a documentação do provedor de rede ou equipamento de rede.

Se você espera pacotes UDP fragmentados e precisa encaminhá-los para os mesmos back-ends, use as seguintes regras de encaminhamento e parâmetros de configuração do serviço de back-end:

• Configuração da regra de encaminhamento: use apenas uma regra de encaminhamento UDP ou L3_DEFAULT por endereço IP com balanceamento de carga 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 os pacotes fragmentados (exceto o primeiro fragmento) não tenham uma porta de destino, a configuração da regra de encaminhamento para processar o tráfego para todas as portas também a configura para receber fragmentos UDP que não têm informações de porta. Para configurar todas as portas, use a Google Cloud CLI para definir --ports=ALL ou use a API para definir allPorts como True

• Configuração do serviço de back-end: defina a afinidade da sessão do serviço de back-end como CLIENT_IP (hash de duas tuplas) ou CLIENT_IP_PROTO (três tuplas) hash) para que o mesmo back-end seja selecionado para pacotes UDP que incluem informações de porta e fragmentos UDP (que não sejam o primeiro fragmento) sem informações de porta. Defina o modo de rastreamento de conexão do serviço de back-end como PER_SESSION para que as entradas da tabela de rastreamento de conexão sejam criadas usando os mesmos hashes de duas ou três tuplas.

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 ou L3_DEFAULT por endereço IP 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.

Failover

Configure um balanceador de carga de rede para distribuir conexões entre instâncias de máquina virtual (VM) nos grupos de instâncias do back-end primário e depois troque para os grupos de instância de back-end de failover, 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.

Limitações

• Os NEGs não são compatíveis como back-ends para balanceadores de carga de rede.

• Não é possível usar o Console do Google Cloud para:

  • Criar ou modificar um balanceador de carga de rede em que a regra de encaminhamento use o protocolo L3_DEFAULT.
  • Criar ou modificar um balanceador de carga de rede em que o protocolo do serviço de back-end esteja definido como UNSPECIFIED.
  • Crie ou modifique um balanceador de carga de rede que configure uma política de rastreamento de conexão.
  • Criar ou modificar o direcionamento de tráfego baseado em IP de origem para uma regra de encaminhamento.

  Use a CLI do Google Cloud ou a API REST.

• Os balanceadores de carga da rede não são compatíveis com o peering de rede VPC.

A seguir

• Para configurar um balanceador de carga de rede com um serviço de back-end somente para tráfego TCP ou UDP, compatível com tráfego IPv4 e IPv6, consulteComo configurar um balanceador de carga de rede com um serviço de back-end.
• Para configurar um balanceador de carga de rede para vários protocolos IP, compatíveis com tráfego IPv4 e IPv6, consulte Como configurar um balanceador de carga de rede para vários protocolos IP.
• Para configurar um balanceador de carga de rede com um pool de destino, consulte Como configurar um balanceador de carga de rede com um pool de destino.
• Para saber como fazer a transição de um balanceador de carga de rede de um back-end de pool de destino para um serviço de back-end regional, consulte Como fazer a transição de um balanceador de carga de rede de um pool de destino para um serviço de back-end.