Balanceadores de carga de rede de encaminhamento interno como saltos seguintes

Um balanceador de carga de rede de encaminhamento interno é um balanceador de carga regional que lhe permite executar e dimensionar os seus serviços através de um endereço IP interno. Pode usar um Network Load Balancer de encaminhamento interno como o próximo salto para o qual os pacotes são encaminhados ao longo do caminho para o respetivo destino final. Para o fazer, define o equilibrador de carga como o salto seguinte numa rota estática.

Antes de rever as informações nesta página, já deve estar familiarizado com os conceitos das seguintes áreas:

• Vista geral dos trajetos
• Vista geral do balanceador de carga de rede de encaminhamento interno

O salto seguinte de um balanceador de carga de rede de encaminhamento interno é útil nos seguintes casos:

• Para equilibrar a carga do tráfego em várias VMs que funcionam como VMs de gateway ou router.

• Para usar dispositivos virtuais de gateway como o próximo salto para uma rota predefinida. Com esta configuração, as instâncias de máquinas virtuais (VMs) na sua rede da nuvem virtual privada (VPC) enviam tráfego para a Internet através de um conjunto de VMs de gateway virtual com equilíbrio de carga.

• Para enviar tráfego através de vários equilibradores de carga em duas ou mais direções usando o mesmo conjunto de VMs de gateway ou router com várias interfaces de rede como back-ends. Para o fazer, crie um equilibrador de carga e use-o como o próximo salto para uma rota estática em cada rede VPC. Cada Network Load Balancer de encaminhamento interno opera numa única rede VPC, distribuindo o tráfego para as interfaces de rede das VMs de back-end nessa rede.

Arquitetura

No diagrama seguinte, um grupo de instâncias de VMs de router funciona como o back-end para dois balanceadores de carga diferentes. O primeiro balanceador de carga de rede de encaminhamento interno envia pacotes para nic0 das VMs de back-end e o segundo balanceador de carga de rede de encaminhamento interno envia pacotes para nic1 nos mesmos back-ends.

Balanceamento de carga para várias NICs (clique para aumentar).

Vantagens de usar o seu balanceador de carga de encaminhamento interno como um salto seguinte

Quando o balanceador de carga é um próximo salto para uma rota estática, não é necessária nenhuma configuração especial nos sistemas operativos convidados das VMs cliente na rede VPC onde a rota está definida. As VMs cliente enviam pacotes para os back-ends do balanceador de carga através do encaminhamento da rede VPC, de forma bump-in-the-wire.

A utilização de um balanceador de carga de encaminhamento interno como salto seguinte para uma rota estática oferece as mesmas vantagens que um balanceador de carga de encaminhamento interno autónomo. A verificação do estado do balanceador de carga garante que as novas ligações são encaminhadas para VMs de back-end em bom estado. Ao usar um grupo de instâncias gerido como back-end, pode configurar a escala automática para aumentar ou diminuir o conjunto de VMs com base na procura de serviços.

Especificações

Seguem-se as especificações para usar balanceadores de carga de rede de encaminhamento interno como saltos seguintes.

Trajetos

Pode criar uma rota estática para transmitir tráfego de TCP, UDP e outros protocolos para um balanceador de carga de rede de passagem interna em que o balanceador de carga é o salto seguinte para a rota estática. A rota pode ser um prefixo CIDR externo (encaminhável publicamente) ou um prefixo CIDR interno, se o prefixo não entrar em conflito com uma rota de sub-rede. Por exemplo, pode substituir a sua rota predefinida (0.0.0.0/0) por uma rota que direcione o tráfego para VMs de back-end de terceiros para processamento de pacotes.

Aviso: quando enviar tráfego para APIs e serviços Google, não encaminhe o tráfego através de uma VM de próximo salto nem através de um Network Load Balancer de passagem interna de próximo salto. Em vez disso, encaminhe esse tráfego através de um gateway de Internet predefinido de salto seguinte. Isto inclui o tráfego para as APIs e os serviços Google enviados através do acesso privado à Google.

Opções para especificar o salto seguinte

Pode especificar um próximo salto do balanceador de carga de encaminhamento interno de uma de duas formas:

• Usando o nome e a região da regra de encaminhamento
• Usando o endereço IP da regra de encaminhamento

Para ver detalhes sobre o projeto e a rede VPC em que um salto seguinte do Network Load Balancer de encaminhamento interno pode residir, consulte Saltos seguintes e funcionalidades.

Pode trocar rotas estáticas com os próximos saltos do Network Load Balancer de encaminhamento interno através do VPC Network Peering. Para ver os detalhes, consulte Opções para trocar rotas estáticas.

Nota: um balanceador de carga cuja regra de encaminhamento usa o protocolo L3_DEFAULT não pode ser o próximo salto para uma rota estática. Se esta rota estática for criada, o tráfego é ignorado silenciosamente.

Afinidade de sessão de IP do cliente

Os balanceadores de carga de rede de encaminhamento interno oferecem duas opções de afinidade de sessão "endereço IP do cliente" semelhantes:

• IP do cliente (CLIENT_IP): um hash de 2 tuplos do endereço IP de origem de um pacote e do endereço IP de destino. Quando um balanceador de carga de passagem interno não é o próximo salto de uma rota, os pacotes enviados para o endereço IP da regra de encaminhamento do balanceador de carga partilham um endereço IP de destino comum, ou seja, o endereço IP da regra de encaminhamento. Nesta situação, um dos endereços usados pelo hash de 2 tuplos permanece constante. Assim, se o número de back-ends configurados e em bom estado não mudar e os pacotes tiverem endereços IP de origem idênticos, esta opção de afinidade de sessão de 2 tuplos seleciona o mesmo back-end.
• IP do cliente, sem destino (CLIENT_IP_NO_DESTINATION): um hash de uma tupla do endereço IP de origem de um pacote. Quando usa um Network Load Balancer de encaminhamento interno como o próximo salto, o endereço IP de destino varia frequentemente porque os endereços IP de destino são os especificados pelo atributo de destino da rota. Nesta situação, o hash de 2 tuplos IP do cliente (CLIENT_IP) da afinidade de sessão não pode selecionar o mesmo back-end mesmo quando o número de back-ends configurados e em bom estado não se altera e os pacotes têm endereços IP de origem idênticos. (Uma exceção a esta regra ocorre quando apenas um back-end está configurado.) Se precisar que os pacotes com endereços IP de origem idênticos sejam encaminhados para o mesmo back-end, tem de usar a opção de afinidade de sessão IP do cliente, sem destino (CLIENT_IP_NO_DESTINATION).

Intervalo de destino

O destino de uma rota estática não pode ser igual ou mais específico do que uma rota de sub-rede. Tenha em atenção que mais específico significa que a máscara de sub-rede é mais longa. Esta regra aplica-se a todas as rotas estáticas, incluindo quando o próximo salto é um Network Load Balancer de encaminhamento interno. Por exemplo, suponhamos que a sua rota de sub-rede é 10.140.0.0/20. O destino de uma rota estática não pode ser o mesmo (10.140.0.0/20) nem mais específico, como em 10.140.0.0/22.

Mesma rede de VPC e região

As rotas estáticas que usam equilibradores de carga de rede de passagem interna como saltos seguintes estão limitadas ao seguinte:

• Uma única rede VPC. O balanceador de carga e a rota estática têm de estar na mesma rede de VPC.

• Uma única região ou todas as regiões. A menos que configure o acesso global, a rota estática só está disponível para recursos na mesma região que o equilibrador de carga. Esta restrição regional é aplicada mesmo que a própria rota faça parte da tabela de encaminhamento para toda a rede VPC. Se ativar o acesso global, a rota estática fica disponível para recursos em qualquer região.

Anunciar a rota estática

Para anunciar o prefixo (destino) da rota estática, pode usar o modo de anúncio personalizado do Cloud Router. O âmbito do anúncio de rota depende da definição de acesso global do balanceador de carga, da seguinte forma:

• Quando o acesso global está desativado, o balanceador de carga de rede de passagem interno só está disponível para VMs, túneis da Cloud VPN e anexos do Cloud Interconnect (VLANs) que se encontram na mesma região que o balanceador de carga. Consequentemente, um anúncio de rota personalizada para o prefixo de uma rota estática só faz sentido se o Cloud Router e o equilibrador de carga estiverem na mesma região.

• Quando o acesso global está ativado, o balanceador de carga de passagem interno está disponível para VMs, túneis de VPN do Google Cloud e anexos do Cloud Interconnect (VLANs) que se encontram em qualquer região. Com o encaminhamento dinâmico global, os sistemas no local podem usar a rota estática de qualquer região ligada.

A tabela seguinte resume a acessibilidade do equilibrador de carga.

Acesso global	Modo de encaminhamento dinâmico da rede VPC	Acesso ao balanceador de carga
Desativado	Regional	Acessível por routers na mesma região
Desativado	Global	Acessível por routers na mesma região
Ativado	Regional	Acessível por todos os routers em qualquer região
Ativado	Global	Acessível por todos os routers em qualquer região

Para mais informações, consulte o artigo Balanceadores de carga de rede de encaminhamento interno e redes ligadas.

Ordem das operações

Tem de criar um Network Load Balancer de encaminhamento interno antes de poder criar uma rota estática que o use como um próximo salto. O balanceador de carga tem de existir antes de poder criar a rota. Se tentar criar uma rota que faça referência a um balanceador de carga inexistente, Google Cloud é devolvido um erro.

Especifica um próximo salto do balanceador de carga de rede de passagem interno através do nome da regra de encaminhamento e da região do balanceador de carga, ou através do endereço IP interno associado à regra de encaminhamento.

Depois de criar uma rota com um próximo salto que se refere a um Network Load Balancer de passagem interno, não pode eliminar o balanceador de carga, a menos que elimine primeiro a rota. Especificamente, não pode eliminar uma regra de encaminhamento interno até que nenhuma rota estática use esse equilibrador de carga como um próximo salto.

Requisitos de back-end

• Tem de configurar todas as VMs de back-end do balanceador de carga de rede de encaminhamento direto interno para permitir o encaminhamento de IP (--can-ip-forward = True). Para mais informações, consulte Considerações comuns aos saltos seguintes do balanceador de carga de rede de encaminhamento direto interno e de instâncias.

• Não pode usar um Network Load Balancer de passagem interno cujos back-ends sejam nós do Google Kubernetes Engine (GKE) como um próximo salto para uma rota estática. O software nos nós só pode encaminhar tráfego para Pods se o destino corresponder a um endereço IP gerido pelo cluster e não a um destino arbitrário.

Processamento de tráfego TCP, UDP e de outros protocolos

Importante: as informações nesta secção aplicam-se apenas a rotas personalizadas criadas antes de 15 de maio de 2021.

Se tiver sido criado um Network Load Balancer de passagem interno como rota de próximo salto antes de 15 de maio de 2021, o balanceador de carga encaminha apenas tráfego TCP e UDP em todas as portas para as VMs de back-end, independentemente da regra de encaminhamento ou da configuração do serviço de back-end. Todo o outro tráfego, como pings ICMP, é processado pela rota mais específica seguinte na sua rede VPC.

Se uma rota criada antes de 15 de maio de 2021 ainda estivesse em funcionamento a 16 de agosto de 2021, foi migrada automaticamente para encaminhar todo o tráfego de protocolo a partir de 16 de agosto de 2021.

Quando um balanceador de carga de rede de encaminhamento interno é implementado como um próximo salto, Google Cloud encaminha todo o tráfego em todas as portas para as VMs de back-end, independentemente do seguinte:

• A configuração da porta e do protocolo da regra de encaminhamento
• A configuração do protocolo do serviço de back-end

O balanceador de carga de rede de passagem interno, que é o próximo salto da rota, suporta perfeitamente o encaminhamento de todo o tráfego para os protocolos suportados pelas Google Cloud redes VPC (como TCP, UDP e ICMP).

Considerações adicionais

• Regras de encaminhamento suportadas. Google Cloud suporta apenas regras de encaminhamento do balanceador de carga de rede de passagem interna de próximo salto. Google Cloud Não suporta regras de encaminhamento de próximo salto usadas por outros balanceadores de carga, encaminhamento de protocolos ou como pontos finais do Private Service Connect.

• Métodos de especificação e rede e projeto da regra de encaminhamento. Pode especificar uma regra de encaminhamento do próximo salto através de um dos três métodos seguintes. O método de especificação que usa determina se a rede da regra de encaminhamento tem de corresponder à rede da rota e em que projeto a regra de encaminhamento pode estar localizada.

  Escolha um dos seguintes métodos e certifique-se de que a versão IP da sua regra de encaminhamento corresponde à versão IP da rota estática que criar:

  • Pelo nome da regra de encaminhamento (--next-hop-ilb) e pela região (--next-hop-ilb-region): quando especifica uma regra de encaminhamento de próximo salto pelo nome e pela região, a rede da regra de encaminhamento tem de corresponder à rede de VPC da rota. A regra de encaminhamento tem de estar localizada no mesmo projeto que contém a rede da regra de encaminhamento (um projeto autónomo ou um projeto anfitrião da VPC partilhada).

  • Por link de recurso da regra de encaminhamento: um link de recurso de uma regra de encaminhamento usa o formato /projects/PROJECT_ID/regions/REGION/forwardingRules/FORWARDING_RULE_NAME, onde PROJECT_ID é o ID do projeto que contém a regra de encaminhamento, REGION é a região da regra de encaminhamento e FORWARDING_RULE_NAME é o nome da regra de encaminhamento. Quando especifica uma regra de encaminhamento do próximo salto através do respetivo link de recurso, a rede da regra de encaminhamento tem de corresponder à rede da VPC da rota. A regra de encaminhamento pode estar localizada no projeto que contém a rede da regra de encaminhamento (um projeto autónomo ou um projeto anfitrião de VPC partilhada) ou num projeto de serviço de VPC partilhada.

  • Pelo endereço IP de uma regra de encaminhamento: quando especifica uma regra de encaminhamento de próximo salto pelo respetivo endereço IPv4 ou IPv6, a rede da regra de encaminhamento pode ser a rede VPC da rota ou uma rede VPC que esteja ligada à rede VPC da rota através do peering de redes VPC ou do Network Connectivity Center. O Network Connectivity Center suporta um balanceador de carga de rede de passagem interno de próximo salto num raio da VPC sujeito aos requisitos do Network Connectivity Center para conetividade. A regra de encaminhamento pode estar localizada no projeto que contém a rede da regra de encaminhamento (um projeto autónomo ou um projeto anfitrião de VPC partilhada) ou num projeto de serviço de VPC partilhada.

• Efeito do acesso global. As rotas estáticas personalizadas que usam saltos seguintes do Network Load Balancer de passagem interna são programadas em todas as regiões. A usabilidade do próximo salto depende da definição de acesso global do balanceador de carga. Com o acesso global ativado, o próximo salto do balanceador de carga é acessível em todas as regiões da rede VPC. Com o acesso global desativado, o próximo salto do balanceador de carga só é acessível na mesma região que o balanceador de carga. Com o acesso global desativado, os pacotes enviados de outra região para um encaminhamento que use um próximo salto do Network Load Balancer de passagem interno são ignorados.

• Quando todos os back-ends estão em mau estado de funcionamento. Quando todos os back-ends de um balanceador de carga de encaminhamento interno falham nas verificações de funcionamento, as rotas que usam o próximo salto desse balanceador de carga continuam em vigor. Os pacotes processados pela rota são enviados para um dos back-ends do balanceador de carga do próximo salto de acordo com a distribuição de tráfego.

• As regras de encaminhamento que usam um endereço IP interno comum (--purpose=SHARED_LOADBALANCER_VIP) não são suportadas. O próximo salto dos balanceadores de carga de rede de encaminhamento interno e das regras de encaminhamento do balanceador de carga de rede de encaminhamento interno com um endereço IP comum são funcionalidades mutuamente exclusivas. Um Network Load Balancer de passagem interno de salto seguinte tem de usar um endereço IP exclusivo da regra de encaminhamento do balanceador de carga para que apenas um serviço de back-end (um balanceador de carga) seja referenciado de forma inequívoca. É possível que as regras de encaminhamento que usam um endereço IP interno comum façam referência a diferentes serviços de back-end (diferentes equilibradores de carga de rede de passagem interna).

• Vários trajetos com os mesmos destinos e prioridades, mas diferentes balanceadores de carga de rede de passagem interna de salto seguinte. Google Cloud Nunca distribui tráfego entre dois ou mais balanceadores de carga de rede de passagem interna de salto seguinte através do ECMP. Em alternativa, o Google Cloud seleciona apenas um encaminhamento interno de próximo salto do balanceador de carga de rede através de um algoritmo interno determinístico.Google Cloud Para evitar esta ambiguidade, pode usar etiquetas de rede únicas para cada trajeto.

  

  Google Cloud seleciona um único próximo salto quando as rotas estáticas com diferentes próximos saltos do equilibrador de carga de rede de passagem interna têm a mesma prioridade e destino.

• Várias rotas com os mesmos destinos, prioridades e próximo salto Equilibradores de carga de rede de encaminhamento interno. Sem uma etiqueta de rede, Google Cloud não lhe permite criar várias rotas estáticas com a mesma combinação de destino, prioridade e próximo salto do equilibrador de carga de rede de encaminhamento interno. Com as etiquetas de rede, pode criar várias rotas estáticas com a mesma combinação de destino, prioridade e próximo salto do balanceador de carga de rede de passagem interna.

Exemplos de utilização

Pode usar um Network Load Balancer de encaminhamento interno como um próximo salto em várias implementações e topologias.

Para cada exemplo, tenha em atenção as seguintes diretrizes:

• Cada interface de VM tem de estar numa rede VPC separada.

• Não pode usar VMs de back-end nem equilibradores de carga para encaminhar tráfego entre sub-redes na mesma rede VPC porque não é possível substituir as rotas de sub-rede.

• O balanceador de carga de rede de encaminhamento interno é um balanceador de carga de encaminhamento definido por software. Os pacotes são entregues às VMs de back-end sem alterações às informações de origem ou destino (endereços ou endereços e portas).

  O encaminhamento, a filtragem de pacotes, o uso de proxy e a tradução de endereços são da responsabilidade das VMs do dispositivo virtual que servem como back-ends para o balanceador de carga de rede de passagem interna.

Usar um balanceador de carga de passagem interno como o salto seguinte para um gateway NAT

Este exemplo de utilização equilibra a carga do tráfego de VMs internas para várias instâncias de gateway NAT que encaminham o tráfego para a Internet.

Exemplo de utilização de NAT (clique para aumentar).

Hub and spoke: trocar trajetos de próximo salto através do intercâmbio da rede da VPC

Além de trocar encaminhamentos de sub-redes, pode configurar o VPC Network Peering para exportar e importar rotas estáticas e dinâmicas personalizadas. As rotas estáticas que têm um salto seguinte do gateway de Internet predefinido são excluídas. Os encaminhamentos estáticos personalizados que usam balanceadores de carga de transferência interna de próximo salto estão incluídos.

Pode configurar uma topologia de hub e raios com os seus dispositivos virtuais de firewall de próximo salto localizados na rede VPC hub fazendo o seguinte:

• Na hubrede VPC, crie um balanceador de carga de rede de encaminhamento interno com dispositivos virtuais de firewall como back-ends.
• Na hubrede de VPC, crie uma rota estática e defina o próximo salto como o balanceador de carga de encaminhamento interno.
• Associe a rede da VPC hub a cada uma das redes da VPC spoke através do intercâmbio da rede da VPC.
• Para cada peering, configure a rede hub para exportar os respetivos encaminhamentos personalizados e configure a rede spoke correspondente para importar encaminhamentos personalizados. O trajeto com o próximo salto do balanceador de carga é um dos trajetos que a rede hub exporta.

Sujeito à ordem de encaminhamento, o balanceador de carga do dispositivo de firewall de próximo salto na rede VPC hub está disponível nas redes spoke:

• A clientes na mesma região que o equilibrador de carga, se o acesso global estiver desativado
• Aos clientes em todas as regiões, se o acesso global estiver ativado, de acordo com a ordem de encaminhamento.

Hub and spoke (clique para aumentar).

Balanceamento de carga para várias NICs

No seguinte exemplo de utilização, as VMs de back-end são instâncias de dispositivos virtuais (por exemplo, VMs de inspeção de pacotes, encaminhamento ou gateway) com NICs em várias redes VPC. Estas instâncias de dispositivos virtuais podem ser soluções comerciais de terceiros ou soluções que cria. Os dispositivos virtuais são VMs do Compute Engine com várias NICs.

Este exemplo mostra um único conjunto de dispositivos virtuais de back-end num grupo de instâncias de VMs geridas.

Na rede VPC denominada testing, o Network Load Balancer de passagem interno tem uma regra de encaminhamento denominada fr-ilb1. No exemplo, este equilibrador de carga distribui o tráfego para a interface nic0.

Na rede VPC denominada production, um Network Load Balancer de passagem interno diferente tem uma regra de encaminhamento denominada fr-ilb2. Este balanceador de carga distribui o tráfego para uma interface diferente, nic1 neste exemplo.

Tráfego com equilíbrio de carga de várias NICs (clique para aumentar).

Para uma configuração detalhada, consulte o artigo Equilíbrio de carga para várias NICs de back-end.

Aplicação de hash simétrica

O exemplo anterior não usa a tradução de endereços de rede de origem (SNAT). O SNAT não é necessário porque o Google Cloud usa hash simétrico. Isto significa que, quando os pacotes pertencem ao mesmo fluxo, o algoritmo Google Cloud calcula o mesmo hash. Por outras palavras, o hash não se altera quando o endereço IP de origem:porta é trocado pelo endereço IP de destino:porta.

Notas:

• A hash simétrica é ativada automaticamente quando cria a regra de encaminhamento do Network Load Balancer de passagem interna a 22 de junho de 2021 ou após essa data.

• Para ativar a hash simétrica em balanceadores de carga de rede de passagem interna existentes, tem de recriar a regra de encaminhamento e a rota de salto seguinte, conforme descrito em Ativar a hash simétrica.

• A hash simétrica só é suportada com equilibradores de carga de encaminhamento interno.

• A aplicação de hash simétrica é suportada com os seguintes tipos de afinidade de sessão para os protocolos TCP e UDP:

  • IP do cliente (CLIENT_IP)
  • IP e protocolo do cliente (CLIENT_IP_PROTO)
  • IP do cliente, protocolo e porta (CLIENT_IP_PORT_PROTO)

  Para mais informações sobre estas definições, consulte as opções de afinidade de sessão.

• Opcionalmente, pode usar o SNAT se o seu exemplo de utilização o exigir por algum motivo.

O que se segue?

• Para configurar um balanceador de carga de rede de passagem interno como um salto seguinte, consulte o artigo Configure um balanceador de carga de rede de passagem interno para dispositivos de terceiros ou Implemente uma rede de hub e raios usando um balanceador de carga como o salto seguinte.
• Para configurar e testar um balanceador de carga de rede de encaminhamento direto interno, consulte o artigo Configure um balanceador de carga de rede de encaminhamento direto interno com back-ends de grupos de instâncias de VMs.
• Para resolver problemas de salto seguinte com o balanceador de carga de rede de passagem interno, consulte o artigo Resolva problemas de balanceadores de carga de rede de passagem internos.