O balanceador de carga de rede de passagem interno é regional e permite executar e escalonar os serviços por trás de um endereço IP interno. É possível usar um balanceador de carga de rede de passagem interna como o próximo salto para o qual os pacotes são encaminhados ao longo do caminho até o destino final. Para fazer isso, defina o balanceador de carga como o próximo salto em uma rota estática.
Antes de analisar as informações desta página, você precisa já ter familiaridade com os conceitos a seguir:
Um próximo salto do balanceador de carga de rede interno de passagem é útil nos seguintes casos:
Para balancear a carga do tráfego em várias VMs que estão funcionando como VMs de gateway ou de roteador.
Para usar dispositivos virtuais de gateway como o próximo salto de uma rota padrão. Com essa configuração, as instâncias de máquina virtual (VM) na rede de nuvem privada virtual (VPC) enviam tráfego para a Internet por meio de um conjunto de VMs de gateway virtual com balanceamento de carga.
Para enviar tráfego por meio de vários balanceadores de carga em duas ou mais direções usando o mesmo conjunto de gateways de multi-NIC ou VMs de roteador como back-ends. Para isso, é preciso criar um balanceador de carga para usar como o próximo salto de uma rota estática em cada rede VPC. Cada balanceador de carga de rede de passagem interno opera em uma única rede VPC, distribuindo o tráfego para as interfaces de rede das VMs de back-end dessa rede.
Arquitetura
No diagrama a seguir, um grupo de instâncias de VM de VMs de roteador serve como back-end para dois balanceadores de carga diferentes.
O primeiro balanceador de carga de rede de passagem interna envia pacotes para nic0 das VMs de back-end, e o segundo balanceador de carga de rede envia pacotes para nic1 nos mesmos back-ends.
Benefícios do uso do balanceador de carga de rede de passagem interna como próximo salto
Quando o balanceador de carga for o próximo salto de uma rota estática, nenhuma configuração especial será necessária nos sistemas operacionais convidados das VMs cliente da rede VPC em que a rota está definida. As VMs do cliente enviam pacotes aos back-ends do balanceador de carga por meio de roteamento de rede VPC em um modo bump-in-the-wire.
Usar um balanceador de carga de rede de passagem interna como um próximo salto para uma rota estática fornece os mesmos benefícios de um balanceador de carga de rede de passagem interna independente. A verificação de integridade do balanceador de carga garante que novas conexões sejam roteadas para VMs de back-end íntegras. Usar um grupo de instâncias gerenciadas como back-end, possibilita configurar o escalonamento automático para aumentar ou diminuir o conjunto de VMs com base na demanda de serviço.
Especificações
Veja a seguir especificações para usar balanceadores de carga de rede de passagem interna como próximos saltos.
Rotas
Crie uma rota estática para transmitir TCP, UDP e outro tráfego de protocolo
a um balanceador de carga de rede de passagem interno, em que o balanceador de carga seja o
próximo salto da rota estática. Ela pode ser um prefixo CIDR externo (publicamente roteável) ou um prefixo CIDR interno, desde que ele não entre em conflito com uma rota de sub-rede. Por exemplo, é possível substituir a rota padrão (0.0.0.0/0) por uma que direcione o tráfego para VMs de back-end de terceiros no processamento de pacotes.
Opções para especificar o próximo salto
É possível especificar o próximo salto do balanceador de carga de rede de passagem interna de duas maneiras:
- Usando o nome e a região da regra de encaminhamento
- Usando o endereço IP da regra de encaminhamento
Para detalhes sobre o projeto e a rede VPC em que pode residir um próximo salto do balanceador de carga de rede de passagem interna, consulte Próximos saltos e recursos.
É possível trocar rotas estáticas com os próximos saltos do balanceador de carga de rede de passagem interna usando o peering de rede VPC. Para mais detalhes, consulte Opções para trocar rotas estáticas.
Afinidade da sessão do IP do cliente
Os balanceadores de carga de rede de passagem interna oferecem duas opções de afinidade de sessão semelhantes de "endereço IP do cliente":
- IP do cliente (
CLIENT_IP): um hash de tupla dupla do endereço IP de origem e destino do pacote. Quando um balanceador de carga de rede 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 compartilham um endereço IP de destino em comum: o endereço IP da regra de encaminhamento. Nessa situação, um dos endereços usados pelo hash de duas tuplas permanece constante. Assim, se o número de back-ends configurados e íntegros não mudar e os pacotes tiverem endereços IP de origem idênticos, essa opção de afinidade de sessão de duas tuplas selecionará 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. Ao usar um balanceador de carga de rede de passagem interno como próximo salto, o endereço IP de destino geralmente varia porque os endereços IP de destino são aqueles especificados pelo atributo de destino da rota. Nesse caso, a afinidade da sessão do IP do cliente (CLIENT_IP) de duas tuplas não pode selecionar o mesmo back-end, mesmo quando o número de back-ends configurados e íntegros não mudar e os pacotes tiverem endereços IP de origem idênticos. (Uma exceção a essa regra é quando apenas um back-end está configurado). Se você precisar que pacotes com endereços IP de origem idênticos sejam roteados para o mesmo back-end, use 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. Observe que mais específico significa que a máscara de sub-rede é mais longa. Essa regra se aplica a todas as rotas estáticas,
incluindo quando o próximo salto é um balanceador de carga de rede de passagem interno. Por exemplo, suponha que a rota de sub-rede seja 10.140.0.0/20. O destino de uma rota estática não pode
ser o mesmo (10.140.0.0/20) e não pode ser mais específico, como em
10.140.0.0/22.
Mesma região e rede VPC
Rotas estáticas que usam balanceadores de carga de rede de passagem internos como próximos saltos são limitadas ao seguinte:
Uma única rede VPC. O balanceador de carga e a rota estática precisam estar na mesma rede VPC.
Uma única região ou todas as regiões. A menos que você configure o acesso global, a rota estática ficará disponível apenas para recursos que estiverem na mesma região que o balanceador de carga. Essa restrição regional é aplicada mesmo que a própria rota faça parte da tabela de roteamento de toda a rede VPC. Se o acesso global for ativado, a rota estática ficará disponível para os recursos em qualquer região.
Divulgando a rota estática
Para divulgar o prefixo (destino) da rota estática, use o modo de divulgação personalizada do Cloud Router. O escopo da divulgação de rota depende da configuração de acesso global do balanceador de carga, da seguinte maneira:
Quando o acesso global é desativado, o balanceador de carga de rede de passagem interno fica disponível apenas para VMs, túneis do Cloud VPN e anexos do Cloud Interconnect (VLANs) que estão na mesma região que o balanceador de carga. Consequentemente, uma divulgação de rota para o prefixo de uma rota estática personalizada só faz sentido se o Cloud Router e o balanceador de carga estiverem na mesma região.
Quando o acesso global está ativado, o balanceador de carga de rede de passagem interno fica disponível para VMs, túneis do Cloud VPN e anexos do Cloud Interconnect (VLANs) que estão em qualquer região. Com o roteamento dinâmico global, os sistemas no local podem usar a rota estática de qualquer região conectada.
A tabela a seguir resume a acessibilidade do balanceador de carga.
| Acesso global | Modo de roteamento dinâmico da rede VPC | Acesso do balanceador de carga |
|---|---|---|
| Desativado | Regional | Acessível por roteadores na mesma região |
| Desativado | Global | Acessível por roteadores na mesma região |
| Ativado | Regional | Acessível por todos os roteadores em qualquer região |
| Ativado | Global | Acessível por todos os roteadores em qualquer região |
Para mais informações, consulte Passbacks de carga de rede interna e redes conectadas.
Ordem de operações
É preciso criar um balanceador de carga de rede de passagem interno antes de criar uma rota estática que o use como próximo salto. O balanceador de carga precisa existir antes da criação da rota. Se você tentar criar uma rota que se refere a um balanceador de carga que não existe, o Google Cloud retornará um erro.
Para especificar um próximo salto do balanceador de carga de rede interno, use o nome da regra de encaminhamento e a região do balanceador de carga ou use o endereço IP interno associado à regra de encaminhamento.
Depois de criar uma rota com um próximo salto que se refere a um balanceador de carga de rede de passagem interno, não é possível excluir o balanceador de carga, a menos que a rota seja excluída antes. Especificamente, não é possível excluir uma regra de encaminhamento interna até que nenhuma rota estática use esse balanceador de carga como próximo salto.
Requisitos de back-end
É preciso configurar todas as VMs de back-end do balanceador de carga de rede de passagem interno para permitir o encaminhamento de IP (
--can-ip-forward = True). Para mais informações, consulte Considerações comuns sobre próximos saltos do balanceador de carga de rede de passagem interno e da instância.Balanceadores de carga de rede de passagem internos com nós do Google Kubernetes Engine (GKE) como back-ends não podem ser usados como próximo salto de rotas estáticas. O software dos nós só pode rotear o tráfego para os pods se o destino corresponder a um endereço IP gerenciado pelo cluster, não a um destino arbitrário.
Processamento de TCP, UDP e outros tráfegos de protocolo
Quando um balanceador de carga de rede de passagem interno é implantado como um próximo salto, o Google Cloud encaminha todo o tráfego em todas as portas para as VMs de back-end, independentemente do seguinte:
- O protocolo e a configuração de porta da regra de encaminhamento
- Configuração de protocolo do serviço de back-end
O balanceador de carga de rede de passagem interno, que é o próximo salto da rota, oferece suporte perfeitamente ao encaminhamento de todo o tráfego para protocolos compatíveis com as redes VPC do Google Cloud (como TCP, UDP e ICMP).
Outras considerações
Regras de encaminhamento compatíveis. O Google Cloud é compatível apenas com regras de encaminhamento do balanceador de carga de rede de passagem interna de próximo salto. O Google Cloud não é compatível com regras de encaminhamento de próximo salto usadas por outros balanceadores de carga, encaminhamento de protocolo ou como endpoints do Private Service Connect.
Métodos de especificação e rede e projeto de regras de encaminhamento. É possível especificar uma regra de encaminhamento de próximo salto usando um dos três métodos a seguir. O método de especificação usado determina se a rede da regra de encaminhamento precisa corresponder à rede da rota e em qual projeto a regra de encaminhamento pode estar localizada:
Por nome (
--next-hop-ilb) e região (--next-hop-ilb-region) da regra de encaminhamento: ao especificar uma regra de encaminhamento de próximo salto por nome e região, a rede da regra de encaminhamento precisa corresponder à rede VPC da rota. A regra de encaminhamento precisa estar localizada no mesmo projeto que contém a rede dela (um projeto independente ou um projeto host de VPC compartilhada).Por link de recurso da regra de encaminhamento: um link de recurso da regra de encaminhamento usa o formato
/projects/PROJECT_ID/regions/REGION/forwardingRules/FORWARDING_RULE_NAME, em que 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. Ao especificar uma regra de encaminhamento do próximo salto pelo link do recurso, a rede da regra de encaminhamento precisa corresponder à rede VPC da rota. A regra de encaminhamento pode estar localizada em um destes projetos: no projeto que contém a rede dela (um projeto independente ou um projeto host de VPC compartilhada) ou em um projeto de serviço de VPC compartilhada.Por endereço IPv4 da regra de encaminhamento: ao especificar uma regra de encaminhamento de próximo salto pelo respectivo endereço IPv4, a rede dela pode ser uma destas: a rede VPC da rota ou uma rede VPC com peering. A regra de encaminhamento pode estar localizada em um destes projetos: no projeto que contém a rede dela (um projeto independente ou um projeto host de VPC compartilhada) ou em um projeto de serviço de VPC compartilhada.
Efeito do acesso global. As rotas estáticas personalizadas que usam os próximos saltos do balanceador de carga de rede interno são programadas em todas as regiões. O uso do próximo salto depende da configuração de acesso global do balanceador de carga. Com o acesso global ativado, o próximo salto do balanceador de carga pode ser acessado em todas as regiões da rede VPC. Com o acesso global desativado, o próximo salto do balanceador de carga só poderá ser acessado na mesma região que o balanceador de carga. Com o acesso global desativado, os pacotes enviados de outra região para uma rota usando um próximo salto do balanceador de carga de rede de passagem interno são descartados.
Quando nenhum back-end é íntegro. Quando todos os back-ends de um balanceador de carga de rede de passagem interno falharem nas verificações de integridade, as rotas que usam esse próximo salto ainda estarão 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.
Não é possível usar regras de encaminhamento que usam um endereço IP interno comum (
--purpose=SHARED_LOADBALANCER_VIP). Os balanceadores de carga internos de passagem de salto e as regras de encaminhamento do balanceador de carga de rede de passagem interno com um endereço IP comum são recursos mutuamente exclusivos. Um balanceador de carga de rede de passagem interna do próximo salto precisa usar um endereço IP exclusivo para a regra de encaminhamento do balanceador de carga para que apenas um serviço de back-end (um balanceador de carga) seja referenciado sem ambiguidade. É possível que as regras de encaminhamento que usam um endereço IP interno comum se refiram a diferentes serviços de back-end (diferentes balanceadores de carga de rede de passagem internos).Várias rotas com os mesmos destinos e prioridades, mas diferentes balanceadores de carga de rede de passagem interna de próximo salto. O Google Cloud nunca distribui o tráfego entre dois ou mais balanceadores de carga de rede de passagem interna de próximo salto usando o ECMP. Em vez disso, o Google Cloud seleciona apenas um balanceador de carga de rede de passagem interna de próximo salto usando um algoritmo interno determinístico. Para evitar essa ambiguidade, use tags de rede exclusivas para cada rota.
O Google Cloud seleciona um único próximo salto quando rotas estáticas com diferentes saltos internos do balanceador de carga de rede de passagem interna têm a mesma prioridade e destino. Várias rotas com os mesmos destinos, prioridades e balanceadores de carga de rede de passagem interna de próximo salto. Sem uma tag de rede, o Google Cloud não permite criar várias rotas estáticas que tenham a mesma combinação de destino, prioridade e próximo salto do balanceador de carga de rede de passagem interna. Com as tags de rede, é possível 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.
Casos de uso
É possível usar um balanceador de carga de rede de passagem interna como um próximo salto em várias implantações e topologias.
Para cada exemplo, observe as seguintes diretrizes:
Cada interface de VM precisa estar em uma rede VPC separada.
Não é possível usar VMs de back-end ou balanceadores de carga para encaminhar o tráfego entre sub-redes na mesma rede VPC. Isso acontece porque não é possível modificar as rotas das sub-redes.
O balanceador de carga de rede de passagem interna é um balanceador de carga de passagem definido por software. os pacotes são entregues às VMs de back-end sem alterações nas informações de origem ou destino (endereços ou endereços e portas).
O roteamento, a filtragem de pacotes, o proxy e a conversão de endereços são responsabilidades das VMs de dispositivos virtuais que servem como back-ends para o balanceador de carga de rede de passagem interno.
Como usar um balanceador de carga de rede de passagem interna como o próximo salto para um gateway NAT
Neste caso de uso, é feito o balanceamento de carga do tráfego de VMs internas para várias instâncias de gateway NAT que encaminham esse tráfego para a Internet.
Hub and spoke: troca de rotas de próximo salto usando peering de rede VPC
Além de trocar rotas de sub-redes, é possível configurar o peering de rede VPC para exportar e importar rotas estáticas e dinâmicas personalizadas. As rotas estáticas que têm um próximo salto do gateway de Internet padrão são excluídas. Rotas estáticas personalizadas que usam balanceadores de carga de rede de passagem interna de próximo salto estão incluídas.
Para configurar uma topologia hub and spoke com os dispositivos virtuais de firewall do próximo salto localizados na rede VPC hub, faça o seguinte:
- Na rede VPC
hub, crie um balanceador de carga de rede de passagem interna com dispositivos virtuais de firewall como os back-ends. - Na rede VPC
hub, crie uma rota estática e defina o próximo salto como o balanceador de carga de rede de passagem interno. - Conecte a rede VPC
huba cada uma das redes VPCspokeusando peering de rede VPC. - Para cada peering, configure a rede
hubpara exportar as rotas personalizadas e a redespokecorrespondente para importar rotas personalizadas. A rota com o próximo salto do balanceador de carga é uma das rotas que a redehubexporta.
Sujeito à ordem de roteamento, o balanceador de carga do dispositivo de firewall do próximo salto da rede VPC hub está disponível nas redes spoke:
- para clientes na mesma região que o balanceador de carga, se o acesso global estiver desativado
- para clientes em todas as regiões, se o acesso global estiver ativado, de acordo com a ordem de roteamento.
Balanceamento de carga para várias NICs
No caso de uso a seguir, as VMs de back-end são instâncias virtuais de dispositivos (por exemplo, inspeção de pacotes, roteamento ou VMs de gateway) com NICs em várias redes VPC. Essas instâncias de dispositivo virtual podem ser soluções comerciais de terceiros ou soluções criadas por você. Os dispositivos virtuais são VMs do Compute Engine com várias NICs.
Neste exemplo, vemos um único conjunto de dispositivos virtuais de back-end em um grupo de instâncias de VMs gerenciadas.
Na rede VPC testing, o balanceador de carga de rede de passagem interna tem uma regra de encaminhamento chamada fr-ilb1. No exemplo, esse balanceador de carga
distribui o tráfego para a interface nic0.
Na rede VPC production, um balanceador de carga de rede de passagem interna diferente tem uma regra de encaminhamento chamada fr-ilb2. Esse balanceador de carga distribui o tráfego para uma interface diferente, nic1 neste exemplo.
Para ver uma configuração detalhada, consulte Balanceamento de carga para várias NICs de back-end.
Hash simétrico
No exemplo anterior, não usamos a conversão de endereços de rede de origem (SNAT, na sigla em inglês). O SNAT não é necessário porque o Google Cloud usa hash simétrico. Isso significa que, quando os pacotes pertencem ao mesmo fluxo, o Google Cloud calcula o mesmo hash. Em outras palavras, o hash não muda quando o endereço IP de origem:porta é trocado pelo endereço IP de destino:porta.
Observações:
O hash simétrico é ativado automaticamente quando você cria a regra de encaminhamento do balanceador de carga interno de rede de passagem a partir de 22 de junho de 2021.
Para ativar o hash simétrico em balanceadores de carga de rede de passagem internos, é necessário recriar a regra de encaminhamento e a rota do próximo salto, conforme descrito em Como ativar o hash simétrico.
O hash simétrico é compatível apenas com balanceadores de carga de rede de passagem interna.
O hash simétrico é compatível 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, protocolo e porta do cliente (
CLIENT_IP_PORT_PROTO)
Para mais informações sobre essas configurações, consulte Opções de afinidade de sessão.
- IP do cliente (
É possível usar o SNAT se seu caso de uso exigir por algum motivo.
A seguir
- Para configurar um balanceador de carga de rede de passagem interna como um próximo salto, consulte Configurar um balanceador de carga de rede de passagem interna para dispositivos de terceiros ou Implantar um hub e uma rede usando um balanceador de carga como o próximo salto.
- Para configurar e testar um balanceador de carga de rede de passagem interna, consulte Configurar um balanceador de carga de rede de passagem interna com back-ends de grupos de instâncias de VM.
- Para resolver problemas do próximo salto com o balanceador de carga de rede de passagem interna, consulte esta página.