Vista geral do balanceador de carga de rede de encaminhamento interno

Um balanceador de carga de rede de encaminhamento interno é um balanceador de carga regional criado na pilha de virtualização de rede Andromeda.

Os equilibradores de carga de rede de passagem internos distribuem o tráfego entre instâncias de máquinas virtuais (VM) internas na mesma região numa rede da nuvem virtual privada (VPC). Permite-lhe executar e dimensionar os seus serviços através de um endereço IP interno que só é acessível a sistemas na mesma rede VPC ou a sistemas ligados à sua rede VPC.

Use um balanceador de carga de rede de passagem interno nas seguintes circunstâncias:

  • Precisa de um balanceador de carga de passagem da camada 4 de alto desempenho para os protocolos TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH e GRE.
  • Se publicar tráfego através de TLS (SSL), é aceitável que o tráfego SSL seja terminado pelos seus back-ends em vez de pelo balanceador de carga. O balanceador de carga de encaminhamento interno não pode terminar o tráfego SSL.
  • Tem de encaminhar os pacotes originais sem proxy. Por exemplo, se precisar que o endereço IP de origem do cliente seja preservado.
  • Tem uma configuração existente que usa um equilibrador de carga de passagem e quer migrá-la sem alterações.

Os balanceadores de carga de encaminhamento interno resolvem muitos exemplos de utilização. Para ver alguns exemplos de alto nível, consulte a vista geral do balanceador de carga de rede de passagem.

Como funcionam os balanceadores de carga de rede de encaminhamento interno

Um Network Load Balancer de encaminhamento interno tem um front-end (a regra de encaminhamento) e um back-end (o serviço de back-end). Pode usar grupos de instâncias ou NEGs zonais do GCE_VM_IP como back-ends no serviço de back-end. Este exemplo mostra back-ends de grupos de instâncias.

Exemplo de balanceador de carga de rede de encaminhamento interno de alto nível.
Exemplo de balanceador de carga de passagem interno de alto nível (clique para aumentar).

Ao contrário de um equilibrador de carga de proxy, um Network Load Balancer de encaminhamento interno não termina as ligações dos clientes e, em seguida, abre novas ligações aos back-ends. Em alternativa, um Network Load Balancer de encaminhamento interno encaminha as ligações diretamente dos clientes para os back-ends em bom estado, sem qualquer interrupção. As respostas das VMs de back-end em bom estado de funcionamento vão diretamente para os clientes e não voltam a passar pelo equilibrador de carga. As respostas TCP usam o retorno direto do servidor. Para mais informações, consulte os pacotes de pedido e retorno de TCP e UDP.

O equilibrador de carga monitoriza o estado do back-end através de sondas de verificação de funcionamento. Para mais informações, consulte a secção Verificação de estado.

O Google Cloud ambiente convidado do Linux, o ambiente convidado do Windows ou um processo equivalente configura cada VM de back-end com o endereço IP do balanceador de carga. Para VMs criadas a partir de Google Cloud imagens, o agente convidado (anteriormente, o ambiente convidado do Windows ou o ambiente convidado do Linux) instala a rota local para o endereço IP do equilibrador de carga. As instâncias do Google Kubernetes Engine baseadas no SO otimizado para contentores implementam esta funcionalidade através de iptables.

AGoogle Cloud rede virtual gere a entrega de tráfego e o dimensionamento, conforme adequado.

Protocolos, esquema e âmbito

Cada balanceador de carga de encaminhamento interno suporta o seguinte:

  • Um serviço de back-end com esquema de balanceamento de carga INTERNAL e um protocolo suportado. Para mais informações, consulte o artigo Serviço de back-end.
  • As VMs de back-end são especificadas como uma das seguintes:
  • Suporte para tráfego IPv4 e IPv6 quando usar back-ends de grupos de instâncias. Os grupos de pontos finais da rede (NEGs) zonais com pontos finais GCE_VM_IP só suportam tráfego IPv4.
  • Uma ou mais regras de encaminhamento, cada uma a usar o protocolo TCP, UDP ou L3_DEFAULT que corresponda ao protocolo do serviço de back-end.
  • Cada regra de encaminhamento com o seu próprio endereço IP exclusivo ou várias regras de encaminhamento que partilham um endereço IP comum.
  • Cada regra de encaminhamento com até cinco portas ou todas as portas.
  • Se o acesso global estiver ativado, os clientes em qualquer região.
  • Se o acesso global estiver desativado, os clientes estão na mesma região que o equilibrador de carga.

Um Network Load Balancer de encaminhamento interno não suporta o seguinte:

Acesso de cliente

Por predefinição, o balanceador de carga só suporta clientes que se encontram na mesma região que o balanceador de carga. Os clientes podem estar na mesma rede que o equilibrador de carga ou numa rede VPC ligada através do intercâmbio da rede VPC. Pode ativar o acesso global para permitir que clientes de qualquer região acedam ao seu Network Load Balancer de encaminhamento interno.

Balanceador de carga de rede de encaminhamento interno com acesso global.
Balanceador de carga de passagem interno com acesso global (clique para aumentar).

A tabela seguinte resume o acesso do cliente.

Acesso global desativado Acesso global ativado
Os clientes têm de estar na mesma região que o equilibrador de carga. Também têm de estar na mesma rede VPC que o balanceador de carga ou numa rede VPC que esteja ligada à rede VPC do balanceador de carga através do peering de redes VPC. Os clientes podem estar em qualquer região. Continuam a ter de estar na mesma rede VPC que o balanceador de carga ou numa rede VPC que esteja ligada à rede VPC do balanceador de carga através do peering de redes VPC.
Os clientes no local podem aceder ao balanceador de carga através de túneis da VPN na nuvem ou anexos de VLAN. Estes túneis ou anexos têm de estar na mesma região que o balanceador de carga. Os clientes no local podem aceder ao balanceador de carga através de túneis da VPN na nuvem ou anexos de VLAN. Estes túneis ou anexos podem estar em qualquer região.

Endereços IP para pacotes de pedidos e de retorno

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

  • Origem: o IPv4 ou o IPv6 interno do cliente, ou o endereço IPv4 de um dos intervalos IPv4 de alias do cliente.
  • Destino: o endereço IP da regra de encaminhamento do balanceador de carga. A regra de encaminhamento usa um único endereço IPv4 interno ou um intervalo IPv6 interno.

Uma vez que o balanceador de carga é um balanceador de carga de passagem (não um proxy), os pacotes chegam com o endereço IP de destino da regra de encaminhamento do balanceador de carga. Configure o software executado nas VMs de back-end para fazer o seguinte:

  • Ouvir (associar a) 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: ouça (associe-se a) 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 destino do pacote de retorno dependem do protocolo:

  • O TCP é orientado para a ligação, pelo que as VMs de back-end têm de responder 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 à ligação TCP adequada.
  • O UDP não tem ligação, pelo que as VMs de back-end podem enviar pacotes de resposta cujos endereços IP de origem correspondem ao endereço IP da regra de encaminhamento ou correspondem a qualquer endereço IP atribuído à VM. Na prática, a maioria dos clientes espera que a resposta seja proveniente do mesmo endereço IP para o qual enviaram pacotes.

A tabela seguinte resume as origens e os destinos dos pacotes de respostas:

Tipo de tráfego Origem Destino
TCP O endereço IP da regra de encaminhamento do balanceador de carga A origem do pacote de pedido
UDP Para a maioria dos exemplos de utilização, o endereço IP da regra de encaminhamento do balanceador de carga 1 A origem do pacote de pedido

1 É possível definir a origem do pacote de resposta para o endereço IPv4 interno principal da NIC da VM ou um intervalo de endereços IP de alias. Se a VM tiver o reencaminhamento de IP ativado, também podem ser usadas origens de endereços IP arbitrárias. Não usar o endereço IP da regra de encaminhamento como origem é um cenário avançado porque o cliente recebe um pacote de resposta de um endereço IP interno que não corresponde ao endereço IP para o qual enviou um pacote de pedido.

Arquitetura

Um Network Load Balancer de passagem interno com vários back-ends distribui as ligações entre todos esses back-ends. Para obter informações acerca do método de distribuição e das respetivas opções de configuração, consulte o artigo Distribuição de tráfego.

Pode usar grupos de instâncias ou NEGs zonais, mas não uma combinação de ambos, como back-ends para um Network Load Balancer de passagem interno:

  • Se escolher grupos de instâncias, pode usar grupos de instâncias não geridos, grupos de instâncias geridos zonais, grupos de instâncias geridos regionais ou uma combinação de tipos de grupos de instâncias.
  • Se optar por NEGs zonais, tem de usar GCE_VM_IP NEGs zonais.

A alta disponibilidade descreve como conceber um equilibrador de carga interno que não dependa de uma única zona.

As instâncias que participam como VMs de back-end para equilibradores de carga de rede de passagem interna têm de estar a executar o ambiente convidado do Linux ou do Windows adequado, ou outros processos que ofereçam uma funcionalidade equivalente. Este ambiente convidado tem de poder contactar o servidor de metadados (metadata.google.internal, 169.254.169.254) para ler os metadados da instância, de modo a poder gerar rotas locais para aceitar o tráfego enviado para o endereço IP interno do balanceador de carga.

Este diagrama mostra a distribuição do tráfego entre VMs localizadas em dois grupos de instâncias separados. O tráfego enviado da instância do cliente para o endereço IP do balanceador de carga (10.10.10.9) é distribuído entre as VMs de back-end em qualquer um dos grupos de instâncias. As respostas enviadas a partir de qualquer uma das VMs de back-end de publicação são entregues diretamente à VM do cliente.

Pode usar um Network Load Balancer de passagem interno com uma rede VPC no modo personalizado ou no modo automático. Também pode criar balanceadores de carga de rede de encaminhamento interno com uma rede antiga existente.

Um Network Load Balancer de encaminhamento interno não suporta o seguinte:

Endereço IP interno

Os equilibradores de carga de rede de passagem interna suportam sub-redes apenas IPv4, de pilha dupla e apenas IPv6. Para mais informações sobre cada uma, consulte Tipos de sub-redes.

Um Network Load Balancer de encaminhamento interno requer, pelo menos, uma regra de encaminhamento. A regra de encaminhamento faz referência ao endereço IP interno:

  • Para o tráfego IPv4, a regra de encaminhamento faz referência a um endereço IPv4 do intervalo de sub-rede IPv4 principal.

  • Para o tráfego IPv6, a regra de encaminhamento faz referência a um intervalo de /96 endereços IPv6 internos do intervalo de endereços IPv6 internos da sub-rede /64. A sub-rede tem de ser uma sub-rede de pilha dupla ou de pilha única apenas IPv6 com um intervalo de endereços IPv6 internos (ipv6-access-type definido como INTERNAL). O intervalo de endereços IPv6 pode ser um endereço estático reservado ou um endereço efémero.

    Para mais informações sobre o suporte de IPv6, consulte a documentação da VPC acerca dos intervalos de sub-redes IPv6 e dos endereços IPv6.

Configuração da firewall

Os balanceadores de carga de rede de encaminhamento interno requerem a seguinte configuração para políticas de firewall hierárquicas e regras de firewall da VPC:

Para mais informações, consulte o artigo Configurar regras de firewall.

Regras de encaminhamento

Uma regra de encaminhamento especifica o protocolo e as portas nas quais o balanceador de carga aceita tráfego. Uma vez que os equilibradores de carga de passagem internos não são proxies, transmitem tráfego para back-ends no mesmo protocolo e porta.

Um Network Load Balancer de encaminhamento interno requer, pelo menos, uma regra de encaminhamento interno. Pode definir várias regras de encaminhamento para o mesmo equilibrador de carga.

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

A regra de encaminhamento tem de fazer referência a uma sub-rede específica na mesma rede e região da VPC que os componentes de back-end do balanceador de carga. Este requisito tem as seguintes implicações:

  • A sub-rede que especificar para a regra de encaminhamento não tem de ser igual a nenhuma das sub-redes usadas pelas VMs de back-end. No entanto, a sub-rede tem de estar na mesma região que a regra de encaminhamento.
  • Para o tráfego IPv4, a regra de encaminhamento interno faz referência a um endereço IPv4 interno regional do intervalo de endereços IPv4 principal da sub-rede que selecionar. Este endereço IPv4 pode ser selecionado automaticamente ou pode usar um endereço IPv4 estático (reservado).
  • Para o tráfego IPv6, a regra de encaminhamento faz referência a um intervalo de /96 endereços IPv6 do intervalo de endereços IPv6 internos da /64 sub-rede. A sub-rede tem de ser uma sub-rede de pilha dupla com o ipv6-access-type definido como INTERNAL. O intervalo de endereços IPv6 é atribuído automaticamente ou pode usar um endereço IP interno reservado./96

Protocolos de regras de encaminhamento

Os balanceadores de carga de rede de passagem interna suportam as seguintes opções de protocolo IPv4 para cada regra de encaminhamento: TCP, UDP ou L3_DEFAULT.

Os balanceadores de carga de rede de passagem interna suportam as seguintes opções de protocolo IPv6 para cada regra de encaminhamento: TCP ou UDP.

A opção L3_DEFAULT permite-lhe equilibrar a carga dos protocolos TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH e GRE.

Além de suportar protocolos que não sejam TCP e UDP, a opção L3_DEFAULT permite que uma única regra de encaminhamento encaminhe simultaneamente o tráfego para vários protocolos. Por exemplo, além de fazer pedidos HTTP, também pode enviar um ping para o endereço IP do balanceador de carga.

As regras de encaminhamento que usam os protocolos TCP ou UDP podem fazer referência a um serviço de back-end usando o mesmo protocolo que a regra de encaminhamento ou um serviço de back-end que usa o protocolo UNSPECIFIED.

Se estiver a usar o protocolo L3_DEFAULT tem de configurar a regra de encaminhamento para aceitar tráfego em todas as portas. Para configurar todas as portas, defina --ports=ALL através da CLI do Google Cloud ou defina allPorts como True através da API.

A tabela seguinte resume como usar estas definições para diferentes protocolos:

Tráfego a ser balanceado de carga Protocolo de regra de encaminhamento Protocolo de serviço de back-end
TCP (IPv4 ou IPv6) TCP TCP or UNSPECIFIED
UDP (IPv4 ou IPv6) UDP UDP or UNSPECIFIED
TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH e GRE L3_DEFAULT UNSPECIFIED

Regras de encaminhamento e acesso global

As regras de encaminhamento de um Network Load Balancer de encaminhamento interno são regionais, mesmo quando o acesso global está ativado. Depois de ativar o acesso global, a flag allowGlobalAccess da regra de encaminhamento interno regional é definida como true.

Regras de encaminhamento e especificações de portas

Quando cria uma regra de encaminhamento interno, tem de escolher uma das seguintes especificações de porta:

  • Especifique, pelo menos, uma e, no máximo, cinco portas, por número.
  • Especifique ALL para encaminhar o tráfego em todas as portas.

Uma regra de encaminhamento interna que suporta todas as portas TCP ou todas as portas UDP permite que as VMs de back-end executem várias aplicações, cada uma na sua própria porta. O tráfego enviado para uma determinada porta é entregue à aplicação correspondente e todas as aplicações usam o mesmo endereço IP.

Quando precisa de encaminhar tráfego em mais de cinco portas específicas, combine as regras de firewall com as regras de encaminhamento. Quando criar a regra de encaminhamento, especifique todas as portas e, em seguida, crie regras de firewall de entrada que permitam apenas o tráfego para as portas pretendidas.allow Aplicar as regras de firewall às VMs de back-end.

Não pode modificar uma regra de encaminhamento depois de a criar. Se precisar de alterar as portas especificadas ou o endereço IP interno de uma regra de encaminhamento interno, tem de a eliminar e recriar.

Várias regras de encaminhamento para um único serviço de back-end

Pode configurar várias regras de encaminhamento interno que referenciam todas o mesmo serviço de back-end interno. Um Network Load Balancer de encaminhamento interno requer, pelo menos, uma regra de encaminhamento interno.

A configuração de várias regras de encaminhamento para o mesmo serviço de back-end permite-lhe fazer o seguinte:

  • Atribua vários endereços IP ao balanceador de carga. Pode criar várias regras de encaminhamento, cada uma com um endereço IP único. Cada regra de encaminhamento pode especificar todas as portas ou um conjunto de até cinco portas.

  • Atribua um conjunto específico de portas, usando o mesmo endereço IP, ao equilibrador de carga. Pode criar várias regras de encaminhamento que partilham o mesmo endereço IP, em que cada regra de encaminhamento usa um conjunto específico de até cinco portas. Esta é uma alternativa à configuração de uma única regra de encaminhamento que especifica todas as portas.

Para mais informações sobre cenários que envolvem duas ou mais regras de encaminhamento interno que partilham um endereço IP interno comum, consulte o artigo Várias regras de encaminhamento com o mesmo endereço IP.

Quando usar várias regras de encaminhamento interno, certifique-se de que configura o software executado nas VMs de back-end para associar a todos os endereços IP das regras de encaminhamento ou a qualquer endereço (0.0.0.0/0 para IPv4 ou ::/0 para IPv6). O endereço IP de destino de um pacote entregue através do balanceador de carga é o endereço IP interno associado à regra de encaminhamento interno correspondente. Para mais informações, consulte os pacotes de pedido e retorno de TCP e UDP.

Serviço de back-end

Cada Network Load Balancer de encaminhamento interno tem um serviço de back-end interno regional que define os parâmetros e o comportamento do back-end. O nome do serviço de back-end é o nome do balanceador de carga de rede de passagem interno apresentado na Google Cloud consola.

Cada serviço de back-end define os seguintes parâmetros de back-end:

  • Protocolo. Um serviço de back-end suporta tráfego IPv4 e IPv6. Se o protocolo tiver um conceito de porta (como TCP ou UDP), o serviço de back-end envia pacotes para VMs de back-end na mesma porta de destino para a qual o tráfego foi enviado.

    Os serviços de back-end suportam as seguintes opções do protocolo IPv4: TCP, UDP ou UNSPECIFIED.

    Os serviços de back-end suportam as seguintes opções de protocolo IPv6: TCP ou UDP. O protocolo de serviço de back-end tem de ser coordenado com o protocolo da regra de encaminhamento.

    Para uma tabela com possíveis combinações de protocolos de regras de encaminhamento e serviços de back-end, consulte a especificação do protocolo de regras de encaminhamento.

  • Distribuição de tráfego. Um serviço de back-end permite que o tráfego seja distribuído de acordo com uma afinidade de sessão configurável.

  • Verificação de saúde. Um serviço de back-end tem de ter uma verificação de estado associada.

Cada serviço de back-end opera numa única região e distribui o tráfego para VMs de back-end numa única rede VPC:

Back-ends de grupos de instâncias e interfaces de rede

Num determinado grupo de instâncias (gerido ou não gerido), todas as instâncias de VM têm de ter as respetivas nic0 interfaces de rede na mesma rede de VPC.

  • Para grupos de instâncias geridas (MIGs), a rede VPC do grupo de instâncias é definida no modelo de instância.
  • Para grupos de instâncias não geridos, a rede VPC do grupo de instâncias é definida como a rede VPC usada pela interface de rede da primeira instância de VM que adiciona ao grupo de instâncias não gerido.nic0
Cada VM membro pode ter, opcionalmente, interfaces de rede adicionais (vNICs ou interfaces de rede dinâmicas), mas cada interface de rede tem de ser anexada a uma rede VPC diferente. Estas redes também têm de ser diferentes da rede de VPC associada ao grupo de instâncias.

Uma NIC dinâmica pode ser eliminada se a NIC dinâmica pertencer a uma VM que seja membro de um grupo de instâncias com balanceamento de carga.

Interfaces de rede e back-ends de NEG zonais

Quando cria um NEG zonal com pontos finais GCE_VM_IP, tem de associar explicitamente o NEG a uma sub-rede de uma rede de VPC antes de poder adicionar pontos finais ao NEG. Não é possível alterar a sub-rede nem a rede VPC após a criação do NEG.

Num determinado NEG, cada ponto final GCE_VM_IP representa, na verdade, uma interface de rede. A interface de rede tem de estar na sub-rede associada ao NEG. Do ponto de vista de uma instância do Compute Engine, a interface de rede pode usar qualquer identificador. Do ponto de vista de ser um ponto final num NEG, a interface de rede é identificada através do respetivo endereço IPv4 interno principal.

Existem duas formas de adicionar um ponto final GCE_VM_IP a um NEG:

  • Se especificar apenas um nome de VM (sem um endereço IP) quando adicionar um ponto final, Google Cloud é necessário que a VM tenha uma interface de rede na sub-rede associada ao NEG. O endereço IP que Google Cloud escolhe para o ponto final é o endereço IPv4 interno principal da interface de rede da VM na sub-rede associada ao NEG.
  • Se especificar um nome de VM e um endereço IP ao adicionar um ponto final, o endereço IP que indicar tem de ser um endereço IPv4 interno principal para uma das interfaces de rede da VM. Essa interface de rede tem de estar na sub-rede associada ao NEG. Tenha em atenção que a especificação de um endereço IP é redundante, uma vez que só pode existir uma única interface de rede na sub-rede associada ao NEG.

Não é possível eliminar uma NIC dinâmica se esta for um ponto final de um grupo de pontos finais de rede com balanceamento de carga.

Especificação de rede do serviço de back-end

Pode associar explicitamente uma rede de VPC a um serviço de back-end através da flag --network quando cria o serviço de back-end. As regras de rede do serviço de back-end entram em vigor imediatamente.

Se omitir a flag --network quando cria um serviço de back-end, oGoogle Cloud usa um dos seguintes eventos de qualificação para definir implicitamente a rede VPC associada do serviço de back-end. Depois de configurada, não é possível alterar a rede da VPC associada ao serviço de back-end:

  • Se o serviço de back-end ainda não tiver back-ends associados e configurar a primeira regra de encaminhamento para referenciar o serviço de back-end, oGoogle Cloud define a rede VPC associada do serviço de back-end como a rede VPC que contém a sub-rede usada por esta regra de encaminhamento.

  • Se o serviço de back-end ainda não tiver uma regra de encaminhamento que faça referência ao mesmo e adicionar o primeiro back-end do grupo de instâncias ao serviço de back-end, oGoogle Cloud define a rede VPC do serviço de back-end como a rede VPC associada a esse primeiro back-end do grupo de instâncias. Isto significa que a rede VPC associada ao serviço de back-end é a rede usada pela interface de rede nic0 de cada VM no primeiro back-end do grupo de instâncias.

  • Se o serviço de back-end ainda não tiver uma regra de encaminhamento que faça referência ao mesmo e adicionar o primeiro back-end do NEG zonal (com GCE_VM_IP pontos finais) ao serviço de back-end, oGoogle Cloud define a rede VPC do serviço de back-end como a rede VPC associada a esse primeiro back-end do NEG.

Depois de a rede VPC do serviço de back-end ter sido definida por um evento elegível, quaisquer regras de encaminhamento, grupos de instâncias de back-end ou NEGs zonais de back-end adicionais que adicionar têm de seguir as regras de rede do serviço de back-end.

Regras de rede do serviço de back-end

As seguintes regras aplicam-se depois de um serviço de back-end ser associado a uma rede VPC específica:

  • Quando configurar uma regra de encaminhamento para referenciar o serviço de back-end, a regra de encaminhamento tem de usar uma sub-rede da rede VPC do serviço de back-end. A regra de encaminhamento e o serviço de back-end não podem usar redes da VPC diferentes, mesmo que essas redes estejam ligadas, por exemplo, através do intercâmbio das redes da VPC.

  • Ao adicionar back-ends de grupos de instâncias, uma das seguintes condições tem de ser verdadeira:

    • A rede VPC associada ao grupo de instâncias, ou seja, a rede VPC usada pela interface de rede de cada VM no grupo de instâncias, tem de corresponder à rede VPC associada do serviço de back-end.nic0
    • Cada VM de back-end tem de ter uma interface nãonic0 na rede VPC associada ao serviço de back-end.

  • Quando adicionar back-ends de NEG zonais com pontos finais GCE_VM_IP, a rede VPC associada ao NEG tem de corresponder à rede VPC associada ao serviço de back-end.

Back-ends de pilha dupla (IPv4 e IPv6)

Se quiser que o balanceador de carga use back-ends de pilha dupla que processam o tráfego IPv4 e IPv6, tenha em atenção os seguintes requisitos:

  • Os back-ends têm de ser configurados em sub-redes de pilha dupla que estejam na mesma região que a regra de encaminhamento IPv6 do balanceador de carga. Para os back-ends, pode usar uma sub-rede com o ipv6-access-type definido como INTERNAL ou EXTERNAL. Se o ipv6-access-typeda sub-rede de back-endEXTERNAL estiver definido como ipv6-access-type, tem de usar uma sub-rede de pilha dupla ou apenas IPv6 diferente com ipv6-access-type definido como INTERNAL para a regra de encaminhamento interno do balanceador de carga. Para mais informações, consulte o artigo Adicione uma sub-rede de pilha dupla.
  • Os back-ends têm de ser configurados para serem de pilha dupla com stack-type definido como IPV4_IPV6. Se o ipv6-access-type da sub-rede de back-end estiver definido como EXTERNAL, também tem de definir o --ipv6-network-tier como PREMIUM. Para mais informações, consulte o artigo Crie um modelo de instância com endereços IPv6.

Back-ends apenas IPv6

Se quiser que o balanceador de carga use back-ends apenas IPv6, tenha em atenção os seguintes requisitos:

  • As instâncias apenas IPv6 só são suportadas em grupos de instâncias não geridos. Nenhum outro tipo de back-end é suportado.
  • Os back-ends têm de ser configurados em pilha dupla ou sub-redes apenas IPv6 que estejam na mesma região que a regra de encaminhamento IPv6 do equilibrador de carga. Para os back-ends, pode usar uma sub-rede com o ipv6-access-type definido como INTERNAL ou EXTERNAL. Se o ipv6-access-type da sub-rede de back-end estiver definido como EXTERNAL, tem de usar uma sub-rede apenas IPv6 diferente com o ipv6-access-type definido como INTERNAL para a regra de encaminhamento interno do equilibrador de carga.
  • Os back-ends têm de ser configurados para serem apenas IPv6 com a VM stack-type definida como IPV6_ONLY. Se o ipv6-access-type da sub-rede de back-end estiver definido como EXTERNAL, também tem de definir o --ipv6-network-tier como PREMIUM. Para mais informações, consulte o artigo Crie um modelo de instância com endereços IPv6.

Tenha em atenção que as VMs apenas com IPv6 podem ser criadas em sub-redes de pilha dupla e apenas com IPv6, mas as VMs de pilha dupla não podem ser criadas em sub-redes apenas com IPv6.

Subconjunto de back-end

A subdivisão de back-ends é uma funcionalidade opcional que melhora o desempenho limitando o número de back-ends para os quais o tráfego é distribuído.

Recomendamos que ative a criação de subconjuntos apenas se precisar de suportar mais de 250 VMs de back-end num único balanceador de carga. Para mais informações, consulte o artigo Subconjuntos de back-end para o balanceador de carga de rede de encaminhamento interno.

Verificação de funcionamento

O serviço de back-end do balanceador de carga tem de estar associado a uma verificação de estado global ou regional. As rotas especiais fora da rede VPC facilitam a comunicação entre os sistemas de verificação de funcionamento e os back-ends.

Pode usar uma verificação de estado existente ou definir uma nova. Os balanceadores de carga de rede de transferência interna usam o estado da verificação de estado para determinar como encaminhar novas ligações, conforme descrito em Distribuição de tráfego.

Pode usar qualquer um dos seguintes protocolos de verificação de estado; o protocolo da verificação de estado não tem de corresponder ao protocolo do equilibrador de carga:

  • HTTP, HTTPS ou HTTP/2. Se as VMs de back-end publicarem tráfego através de HTTP, HTTPS ou HTTP/2, é melhor usar uma verificação de estado que corresponda a esse protocolo, porque as verificações de estado baseadas em HTTP oferecem opções adequadas a esse protocolo. A publicação de tráfego do tipo HTTP através de um balanceador de carga de rede de passagem interno significa que o protocolo do balanceador de carga é TCP.
  • SSL ou TCP. Se as VMs de back-end não publicarem tráfego do tipo HTTP, recomendamos que use uma verificação de estado SSL ou TCP.

Independentemente do tipo de verificação de funcionamento que criar, Google Cloud envia sondas de verificação de funcionamento para o endereço IP da regra de encaminhamento do balanceador de carga de rede de passagem interna, para a interface de rede na rede VPC selecionada pelo serviço de back-end do balanceador de carga. Isto simula a forma como o tráfego com balanceamento de carga é enviado. O software executado nas VMs de back-end tem de responder ao tráfego com balanceamento de carga e às sondas de verificação do estado de funcionamento enviadas para o endereço IP de cada regra de encaminhamento (o software tem de ouvir em 0.0.0.0:_port_ e não num endereço IP específico atribuído a uma interface de rede). Para mais informações, consulte o artigo Destino dos pacotes de sondagem.

Verificações de funcionamento e tráfego UDP

Google Cloud não oferece uma verificação de funcionamento que use o protocolo UDP. Quando usa um balanceador de carga de rede de encaminhamento interno com tráfego UDP, tem de executar um serviço baseado em TCP nas suas VMs de back-end para fornecer informações de verificação de funcionamento.

Nesta configuração, os pedidos do cliente são equilibrados através do protocolo UDP e é usado um serviço TCP para fornecer informações aos verificadores de Google Cloud estado de funcionamento. Por exemplo, pode executar um servidor HTTP simples em cada VM de back-end que devolve um código de estado HTTP 200 para Google Cloud. Neste exemplo, recomendamos que use a sua própria lógica executada na VM de back-end para ajudar a garantir que o servidor HTTP devolve 200 apenas se o serviço UDP estiver configurado e em execução corretamente.

Arquitetura de alta disponibilidade

O balanceador de carga de encaminhamento interno está concebido para ter uma elevada disponibilidade. Não existem passos especiais para tornar o balanceador de carga altamente disponível, uma vez que o mecanismo não depende de um único dispositivo ou instância de VM.

Para implementar as instâncias de VM de back-end em várias zonas, siga estas recomendações de implementação:

  • Use grupos de instâncias geridas regionais se puder implementar o seu software através de modelos de instâncias. Os grupos de instâncias geridos regionais distribuem automaticamente o tráfego por várias zonas, oferecendo a melhor opção para evitar potenciais problemas em qualquer zona.

  • Se usar grupos de instâncias geridos zonais ou grupos de instâncias não geridos, use vários grupos de instâncias em zonas diferentes (na mesma região) para o mesmo serviço de back-end. A utilização de várias zonas protege contra potenciais problemas em qualquer zona.

Arquitetura de VPC partilhada

A tabela seguinte resume os requisitos dos componentes para equilibradores de carga de passagem internos usados com redes VPC partilhadas. Para ver um exemplo, consulte a secção criar um balanceador de carga de rede de encaminhamento interno na página de aprovisionamento da VPC partilhada.

Endereço IP Regra de encaminhamento Componentes de back-end
Tem de definir um endereço IP interno no mesmo projeto que as VMs de back-end.

Para que o balanceador de carga esteja disponível numa rede de VPC partilhada, o Google Cloud endereço IP interno tem de ser definido no mesmo projeto de serviço onde se encontram as VMs de back-end e tem de fazer referência a uma sub-rede na rede de VPC partilhada pretendida no projeto anfitrião. A própria morada provém do intervalo de IP principal da sub-rede referenciada.

Se criar um endereço IP interno num projeto de serviço e a sub-rede do endereço IP estiver na rede VPC do projeto de serviço, o seu Network Load Balancer de passagem interno é local para o projeto de serviço. O seu Network Load Balancer de passagem interno não é local para nenhum projeto anfitrião da VPC partilhada.		 Tem de definir uma regra de encaminhamento interna no mesmo projeto que as VMs de back-end.

Para que o balanceador de carga esteja disponível numa rede de VPC partilhada, a regra de encaminhamento interno tem de ser definida no mesmo projeto de serviço onde as VMs de back-end estão localizadas e tem de fazer referência à mesma sub-rede (na rede de VPC partilhada) à qual o endereço IP interno associado faz referência.

Se criar uma regra de encaminhamento interno num projeto de serviço e a sub-rede da regra de encaminhamento estiver na rede VPC do projeto de serviço, o seu Network Load Balancer de passagem interno é local para o projeto de serviço. O seu Network Load Balancer de passagem interno não é local para nenhum projeto anfitrião da VPC partilhada.		 Num cenário de VPC partilhada, as VMs de back-end estão localizadas num projeto de serviço. Um serviço de back-end interno regional e uma verificação de estado têm de ser definidos nesse projeto de serviço.

Distribuição de tráfego

Os equilibradores de carga de rede de encaminhamento interno suportam várias opções de personalização da distribuição de tráfego, incluindo afinidade de sessão, acompanhamento de ligações e comutação por falha. Para ver detalhes sobre como os balanceadores de carga de rede de encaminhamento interno distribuem o tráfego e como estas opções interagem entre si, consulte o artigo Distribuição de tráfego para balanceadores de carga de rede de encaminhamento interno.

Quotas e limites

Para ver informações sobre quotas e limites, consulte o artigo Quotas de recursos de balanceamento de carga.

Limitações

  • Não pode usar a Google Cloud consola para criar um Network Load Balancer de encaminhamento interno com back-ends NEG zonais.

O que se segue?