Vista geral do balanceador de carga de rede de encaminhamento externo baseado em serviços de back-end

Os balanceadores de carga de rede de encaminhamento externo são balanceadores de carga regionais de camada 4 que distribuem o tráfego externo entre back-ends (grupos de instâncias ou grupos de pontos finais da rede [NEGs]) na mesma região que o balanceador de carga. Estes back-ends têm de estar na mesma região e projeto, mas podem estar em redes VPC diferentes. Estes balanceadores de carga são criados com base no Maglev e na pilha de virtualização de rede do Andromeda.

Os balanceadores de carga de rede de passagem externos podem receber tráfego de:

  • Qualquer cliente na Internet
  • Google Cloud VMs com IPs externos
  • Google Cloud VMs que têm acesso à Internet através do Cloud NAT ou do NAT baseado em instâncias

Os balanceadores de carga de rede de encaminhamento externo não são proxies. O equilibrador de carga em si não termina as ligações dos utilizadores. Os pacotes com balanceamento de carga são enviados para as VMs de back-end com os respetivos endereços IP de origem e destino, protocolo e, se aplicável, portas inalterados. Em seguida, as VMs de back-end terminam as ligações dos utilizadores. As respostas das VMs de back-end vão diretamente para os clientes e não regressam através do balanceador de carga. Este processo é conhecido como retorno direto do servidor (DSR).

Os balanceadores de carga de rede de encaminhamento externo baseados em serviços de back-end suportam as seguintes funcionalidades:

  • Back-ends de grupos de instâncias geridas e não geridas. Os balanceadores de carga de rede de encaminhamento externo baseados em serviços de back-end suportam grupos de instâncias geridos e não geridos como back-ends. Os grupos de instâncias geridas automatizam determinados aspetos da gestão de back-end e oferecem melhor escalabilidade e fiabilidade em comparação com os grupos de instâncias não geridas.
  • Back-ends de NEG zonal. Os balanceadores de carga de rede de encaminhamento externo baseados em serviços de back-end suportam a utilização de NEGs zonais com pontos finais GCE_VM_IP. Os pontos finais de GCE_VM_IPNEG zonalGCE_VM_IP permitem-lhe fazer o seguinte:
    • Encaminhar pacotes para qualquer interface de rede e não apenas para nic0.
    • Colocar o mesmo ponto final GCE_VM_IP em dois ou mais NEGs zonais ligados a diferentes serviços de back-end.
  • Suporte de vários protocolos. Os balanceadores de carga de rede de encaminhamento externo baseados em serviços de back-end podem equilibrar a carga do tráfego TCP, UDP, ESP, GRE, ICMP e ICMPv6.
  • Suporte para conetividade IPv6. Os balanceadores de carga de rede de encaminhamento externo baseados em serviços de back-end podem processar tráfego IPv4 e IPv6.
  • Controlo detalhado da distribuição de tráfego. Um serviço de back-end permite que o tráfego seja distribuído de acordo com a afinidade de sessão configurada, a política de acompanhamento de ligações e as definições de balanceamento de carga ponderado. O serviço de back-end também pode ser configurado para ativar a drenagem de ligações e designar back-ends de comutação por falha para o balanceador de carga. A maioria destas definições tem valores predefinidos que lhe permitem começar rapidamente. Para mais informações, consulte o artigo Distribuição de tráfego para balanceadores de carga de passagem externos.
  • Compatibilidade com verificações de funcionamento não antigas. Os balanceadores de carga de rede de passagem externos baseados em serviços de back-end permitem-lhe usar verificações de funcionamento que correspondem ao tipo de tráfego (TCP, SSL, HTTP, HTTPS ou HTTP/2) que estão a distribuir.
  • Integração do Google Cloud Armor. O Cloud Armor suporta proteção avançada contra DDoS de rede para balanceadores de carga de rede de encaminhamento externo. Para mais informações, consulte o artigo Configure a proteção avançada contra DDoS de rede.

  • Integração do GKE. Se estiver a criar aplicações no GKE, recomendamos que use o controlador de serviços do GKE integrado, que implementaGoogle Cloud equilibradores de carga em nome dos utilizadores do GKE. Isto é igual à arquitetura de equilíbrio de carga autónoma descrita nesta página, exceto que o respetivo ciclo de vida é totalmente automatizado e controlado pelo GKE.

    Documentação do GKE relacionada:

Arquitetura

O diagrama seguinte ilustra os componentes de um balanceador de carga de rede de encaminhamento externo:

Balanceador de carga de rede de passagem externo com um serviço de back-end regional
Balanceador de carga de rede de encaminhamento externo com um serviço de back-end regional

O balanceador de carga é composto por 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 externas regionais
  • Um serviço de back-end externo regional
  • Um ou mais back-ends: todos os grupos de instâncias ou todos os back-ends NEG zonais (GCE_VM_IP pontos finais)
  • Verificação de funcionamento associada ao serviço de back-end

Além disso, tem de criar regras de firewall que permitam que o tráfego de balanceamento de carga e as sondas de verificação de funcionamento alcancem as VMs de back-end.

Endereço IP

Um Network Load Balancer de encaminhamento externo requer, pelo menos, uma regra de encaminhamento. A regra de encaminhamento faz referência a um endereço IP externo regional acessível em qualquer lugar na Internet.

Use um endereço IP reservado para a regra de encaminhamento se precisar de manter o endereço associado ao seu projeto para reutilização depois de eliminar uma regra de encaminhamento ou se precisar que várias regras de encaminhamento referenciem o mesmo endereço IP.

Os balanceadores de carga de rede de encaminhamento externo suportam o nível Standard e o nível Premium para endereços IPv4 externos regionais. O endereço IP e a regra de encaminhamento têm de usar o mesmo nível de rede. Os endereços IPv6 externos regionais só estão disponíveis no nível Premium.

Regra de encaminhamento

Uma regra de encaminhamento externa regional especifica o protocolo e as portas nas quais o balanceador de carga aceita tráfego. Uma vez que os equilibradores de carga de encaminhamento externos não são proxies, encaminham o tráfego para back-ends no mesmo protocolo e portas, se o pacote tiver informações de portas. 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 recebidos. O endereço IP de destino dos pacotes recebidos é um endereço IP associado à regra de encaminhamento do balanceador de carga.

O tráfego de entrada é associado a uma regra de encaminhamento, que é uma combinação de um endereço IP específico (um endereço IPv4 ou um intervalo de endereços IPv6), um protocolo e, se o protocolo for baseado em portas, uma ou mais portas, um intervalo de portas ou todas as portas. Em seguida, 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, a regra de encaminhamento não está associada a nenhuma sub-rede. Ou seja, o respetivo endereço IP é proveniente de fora de qualquerGoogle Cloud intervalo de sub-rede.

  • Se a regra de encaminhamento fizer referência a um /96 intervalo de endereços IPv6, a regra de encaminhamento tem de estar associada a uma sub-rede, e essa sub-rede tem de ser (a) de pilha dupla e (b) ter um intervalo de sub-rede IPv6 externo (--ipv6-access-type definido como EXTERNAL). A sub-rede à qual a regra de encaminhamento faz referência pode ser a mesma sub-rede usada pelas instâncias de back-end. No entanto, as instâncias de back-end podem usar uma sub-rede separada, se assim o escolher. Quando as instâncias de back-end usam uma sub-rede separada, tem de se verificar o seguinte:

Um Network Load Balancer de encaminhamento externo 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 detalhes, consulte o artigo sobre a direção do tráfego. Pode definir várias regras de encaminhamento para o mesmo equilibrador de carga, conforme descrito em Várias regras de encaminhamento.

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.

Protocolos de regras de encaminhamento

Os balanceadores de carga de encaminhamento externos suportam 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 de TCP ou UDP. A opção de protocolo L3_DEFAULT permite que um balanceador de carga de rede de passagem externo faça o balanceamento de carga do tráfego TCP, UDP, ESP, GRE, ICMP e ICMPv6.

Além de suportar protocolos que não sejam TCP e UDP, o L3_DEFAULTpermite que uma única regra de encaminhamento sirva vários protocolos. Por exemplo, os serviços IPsec processam normalmente alguma combinação de tráfego ESP e IKE e NAT-T baseado em UDP. A opção L3_DEFAULT permite configurar uma única regra de encaminhamento 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 usando 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 fazer referência a um serviço de back-end com 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 TCP TCP ou UNSPECIFIED
L3_DEFAULT UNSPECIFIED
UDP UDP UDP ou UNSPECIFIED
L3_DEFAULT UNSPECIFIED
ESP, GRE, ICMP/ICMPv6 (apenas pedido de eco) L3_DEFAULT UNSPECIFIED

Várias regras de encaminhamento

Pode configurar várias regras de encaminhamento externas regionais para o mesmo Network Load Balancer de passagem externa. 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 para estes exemplos de utilização:

  • Tem de configurar mais do que um endereço IP externo para o mesmo serviço de back-end.
  • Tem de configurar protocolos diferentes ou portas ou intervalos de portas que não se sobreponham para o mesmo endereço IP externo.
  • Tem de direcionar o tráfego de determinados endereços IP de origem para back-ends de balanceadores de carga específicos.

Google Cloud requer que os pacotes recebidos correspondam a, no máximo, uma regra de encaminhamento. Exceto para as regras de encaminhamento de direcionamento, que são abordadas na secção seguinte, duas ou mais regras de encaminhamento que usam o mesmo endereço IP externo regional têm de ter combinações de protocolo e porta exclusivas 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 que usem o mesmo protocolo e endereço IP. As regras de encaminhamento que usam os protocolos TCP ou UDP podem ser configuradas para usar todas as portas ou podem ser configuradas para portas específicas. Por exemplo, se criar uma regra de encaminhamento com o endereço IP 198.51.100.1, o protocolo TCP e todas as portas, não pode criar outra regra de encaminhamento com o endereço IP 198.51.100.1 e o protocolo TCP. Pode criar duas regras de encaminhamento, ambas com o endereço IP 198.51.100.1e o protocolo TCP, se cada uma tiver portas exclusivas ou intervalos de portas que não se sobreponham. Por exemplo, pode criar duas regras de encaminhamento com o endereço IP198.51.100.1 e o protocolo TCP, em que as portas de uma regra de encaminhamento são 80,443 e a outra usa o intervalo de portas 81-442.
  • Só é possível criar uma regra de encaminhamento L3_DEFAULTpor endereço IP. Isto deve-se ao facto de o protocolo L3_DEFAULT usar todas as portas por definição. Neste contexto, o termo todas as portas inclui protocolos sem informações de portas.

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

    Para ilustrar isto, considere estes dois cenários. As regras de encaminhamento em ambos os cenários 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 portas de destino diferentes, são processados pela primeira regra de encaminhamento.

Seleção de regras de encaminhamento

Google Cloud seleciona uma ou zero regras de encaminhamento para processar um pacote recebido através deste processo de eliminação, começando pelo conjunto de candidatos a regras de encaminhamento que correspondem ao endereço IP de destino do pacote:

  • Elimine as regras de encaminhamento cujo protocolo não corresponda 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 este passo 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 são eliminadas.

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

  • Se os candidatos a regras de encaminhamento restantes incluírem regras de encaminhamento específicas do protocolo L3_DEFAULT e L3_DEFAULT, elimine as regras de encaminhamento L3_DEFAULT. Se os restantes candidatos a regras de encaminhamento forem todos L3_DEFAULT regras de encaminhamento, nenhum é eliminado neste passo.

  • Neste ponto, os restantes candidatos a regras de encaminhamento enquadram-se numa das seguintes categorias:

    • Permanece uma única regra de encaminhamento que corresponde ao endereço IP de destino, ao protocolo e à porta do pacote, e é usada para encaminhar o pacote.
    • Permanecem dois ou mais candidatos a regras de encaminhamento que correspondem ao endereço IP, ao protocolo e à porta de destino do pacote. Isto significa que os restantes candidatos a regras de encaminhamento incluem regras de encaminhamento de direcionamento (abordadas na secção seguinte). Selecione a regra de encaminhamento de direcionamento cuja gama de origem inclui o CIDR mais específico (correspondência de prefixo mais longo) que contém o endereço IP de origem do pacote. Se nenhuma regra de encaminhamento de direcionamento tiver um intervalo de origem que inclua o endereço IP de origem do pacote, selecione a regra de encaminhamento principal.
    • Não restam candidatos a regras de encaminhamento e o pacote é rejeitado.

Quando usar várias regras de encaminhamento, certifique-se de que configura o software em execução nas VMs de back-end para que seja associado a todos os endereços IP externos das regras de encaminhamento do balanceador de carga.

Encaminhamento de tráfego

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

O encaminhamento de tráfego é útil para a resolução de problemas e para configurações avançadas. Com o encaminhamento de tráfego, pode direcionar determinados clientes para um conjunto diferente de back-ends, uma configuração de serviço de back-end diferente ou ambos. Por exemplo:

  • O encaminhamento de tráfego permite-lhe criar duas regras de encaminhamento que direcionam o tráfego para o mesmo back-end (grupo de instâncias ou NEG) através de dois serviços de back-end. Os dois serviços de back-end podem ser configurados com verificações de estado diferentes, afinidades de sessão diferentes ou políticas de controlo de distribuição de tráfego diferentes (monitorização de ligações, esgotamento de ligações e comutação por falha).
  • O encaminhamento de tráfego permite-lhe criar uma regra de encaminhamento para redirecionar o tráfego de um serviço de back-end de largura de banda baixa para um serviço de back-end de largura de banda alta. Ambos os serviços de back-end contêm o mesmo conjunto de VMs ou pontos finais de back-end, mas o balanceamento de carga é feito com pesos diferentes através do balanceamento de carga ponderado.
  • O encaminhamento de tráfego permite-lhe criar duas regras de encaminhamento que direcionam o tráfego para diferentes serviços de back-end, com diferentes back-ends (grupos de instâncias ou NEGs). Por exemplo, um back-end pode ser configurado com diferentes tipos de máquinas para processar melhor o tráfego de determinados endereços IP de origem.

A gestão do encaminhamento de tráfego é configurada com um parâmetro da API de regra de encaminhamento denominado sourceIPRanges. As regras de encaminhamento que têm, pelo menos, um intervalo de IPs de origem configurado são denominadas regras de encaminhamento de direcionamento.

Uma regra de encaminhamento de direcionamento pode usar o parâmetro sourceIPRanges para especificar uma lista separada por vírgulas de até 64 endereços IP de origem ou intervalos de endereços IP. Pode atualizar esta lista de intervalos de endereços IP de origem em qualquer altura.

Cada regra de encaminhamento de direcionamento requer que crie primeiro uma regra de encaminhamento principal. As regras de encaminhamento principal e de encaminhamento partilham o mesmo endereço IP externo regional, protocolo IP e informações de porta. No entanto, a regra de encaminhamento principal não tem informações de endereço IP de origem. Por exemplo:

  • Regra de encaminhamento principal: 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 principal 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 principal, duas ou mais regras de encaminhamento de direcionamento podem ter intervalos de endereços IP de origem e endereços IP sobrepostos, mas não idênticos. Por exemplo, uma regra de encaminhamento de direcionamento pode ter o intervalo de IP de origem 203.0.113.0/24 e outra regra de encaminhamento de direcionamento para o mesmo elemento principal pode ter o endereço IP de origem 203.0.113.0.

Tem de eliminar todas as regras de encaminhamento de direcionamento antes de poder eliminar a regra de encaminhamento principal da qual dependem.

Para saber como os pacotes recebidos são processados quando são usadas regras de encaminhamento de direcionamento, consulte o artigo Seleção de regras de encaminhamento.

Comportamento da afinidade de sessão nas alterações de encaminhamento

Esta secção descreve as condições em que a afinidade de sessão pode ser interrompida quando os intervalos de endereços IP de origem configurados para uma regra de encaminhamento de direcionamento são atualizados:

Preservar a afinidade de sessão nas alterações de encaminhamento

Esta secção descreve como evitar a quebra da afinidade de sessão quando os intervalos de IP de origem das regras de encaminhamento de direcionamento são atualizados:

  • Regras de encaminhamento de direcionamento que apontam para serviços de back-end. Se a regra de encaminhamento principal e a regra de encaminhamento de direcionamento apontarem para serviços de back-end, tem de se certificar manualmente de que as definições de afinidade de sessão e política de monitorização de ligações são idênticas. OGoogle Cloud não rejeita automaticamente as configurações se não forem idênticas.
  • Encaminhamento de regras de encaminhamento que apontam para instâncias de destino. Uma regra de encaminhamento principal 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. Neste caso, a regra de encaminhamento de direcionamento herda as definições de afinidade de sessão e política de acompanhamento de ligações da regra de encaminhamento principal.

Para ver instruções sobre como configurar o encaminhamento de tráfego, consulte o artigo Configure o encaminhamento de tráfego.

Serviço de back-end regional

Cada Network Load Balancer de passagem externo tem um serviço de back-end regional que define o comportamento do balanceador de carga e como o tráfego é distribuído pelos respetivos back-ends. O nome do serviço de back-end é o nome do balanceador de carga de rede de encaminhamento externo 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 aceita tráfego no endereço IP e nas portas (se configurado) especificados por uma ou mais regras de encaminhamento externo regionais. O serviço de back-end passa pacotes para VMs de back-end, preservando os endereços IP de origem e destino, o protocolo e, se o protocolo for baseado em portas, as portas de origem e destino do pacote.

    Os serviços de back-end usados com balanceadores de carga de rede de encaminhamento externo suportam 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, independentemente do protocolo da regra de encaminhamento. 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 referir-se a serviços de back-end com o protocolo UNSPECIFIED.

    Consulte a especificação do protocolo de regra de encaminhamento para ver uma tabela com as possíveis combinações de protocolos de regras de encaminhamento e serviços de back-end.

  • Distribuição de tráfego. Um serviço de back-end permite que o tráfego seja distribuído de acordo com a afinidade de sessão configurada, a política de acompanhamento de ligações e as definições de balanceamento de carga ponderado. O serviço de back-end também pode ser configurado para ativar a drenagem de ligações e designar back-ends de comutação por falha para o balanceador de carga. A maioria destas definições tem valores predefinidos que lhe permitem começar rapidamente. Para mais informações, consulte o artigo Distribuição de tráfego para balanceadores de carga de passagem externos.

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

  • Backends. Cada serviço de back-end opera numa única região e distribui o tráfego para grupos de instâncias ou NEGs zonais na mesma região. Pode usar grupos de instâncias ou NEGs zonais, mas não uma combinação de ambos, como back-ends para um equilibrador de carga de rede de encaminhamento externo:

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

    Cada grupo de instâncias ou back-end do NEG tem uma rede VPC associada, mesmo que esse grupo de instâncias ou NEG ainda não tenha sido ligado a um serviço de back-end. Para mais informações sobre como uma rede está associada a cada tipo de back-end, consulte os artigos Back-ends de grupos de instâncias e interfaces de rede e Back-ends de NEG zonais e interfaces de rede.

Grupos de instâncias

Um Network Load Balancer de encaminhamento externo distribui as ligações entre VMs de back-end contidas em grupos de instâncias geridos ou não geridos. Os grupos de instâncias podem ter âmbito regional ou zonal.

Cada grupo de instâncias tem uma rede da VPC associada, mesmo que esse grupo de instâncias ainda não tenha sido ligado a um serviço de back-end. Para mais informações sobre como uma rede está associada a grupos de instâncias, consulte o artigo Back-ends de grupos de instâncias e interfaces de rede.

O balanceador de carga de encaminhamento externo está altamente disponível por predefinição. Não são necessários passos especiais para tornar o equilibrador de carga altamente disponível, uma vez que o mecanismo não depende de um único dispositivo ou instância de VM. Só tem de se certificar de que as instâncias de VM de back-end estão implementadas em várias zonas para que o balanceador de carga possa contornar potenciais problemas em qualquer zona.

  • Grupos de instâncias geridas regionais. Use grupos de instâncias geridos 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 específica.

    Aqui pode ver um exemplo de implementação que usa um grupo de instâncias gerido regional. O grupo de instâncias tem um modelo de instância que define como as instâncias devem ser aprovisionadas, e cada grupo implementa instâncias em três zonas da região us-central1.

    Balanceador de carga de rede de encaminhamento externo com um grupo de instâncias gerido regional
    Balanceador de carga de rede de encaminhamento externo com um grupo de instâncias gerido regional

  • Grupos de instâncias geridos ou não geridos zonais. Use grupos de instâncias zonais em zonas diferentes (na mesma região) para se proteger contra potenciais problemas em qualquer zona específica.

    Aqui pode ver um exemplo de implementação com grupos de instâncias zonais. Este balanceador de carga oferece disponibilidade em duas zonas.

    Balanceador de carga de rede de encaminhamento externo com grupos de instâncias zonais
    Balanceador de carga de rede de encaminhamento externo com grupos de instâncias zonais

NEGs zonais

Um Network Load Balancer de encaminhamento externo distribui as ligações entre GCE_VM_IP pontos finais contidos em grupos de pontos finais da rede zonais. Estes pontos finais têm de estar localizados na mesma região que o equilibrador de carga. Para alguns exemplos de utilização de NEG zonais recomendados, consulte a vista geral dos grupos de pontos finais de rede zonais.

Os pontos finais no NEG têm de ser endereços IPv4 internos principais de interfaces de rede de VMs que estejam na mesma sub-rede e zona que o NEG zonal. O endereço IPv4 interno principal de qualquer interface de rede de uma instância de VM com várias NICs pode ser adicionado a um NEG, desde que esteja na sub-rede do NEG.

Os NEGs zonais suportam VMs IPv4 e de pilha dupla (IPv4 e IPv6). Para VMs IPv4 e de pilha dupla, basta especificar apenas a instância de VM quando anexar um ponto final a um NEG. Não precisa de especificar o endereço IP do ponto final. A instância de VM tem de estar sempre na mesma zona que o NEG.

Cada NEG zonal tem uma rede da VPC e uma sub-rede associadas, mesmo que esse NEG zonal ainda não tenha sido ligado a um serviço de back-end. Para mais informações sobre como uma rede está associada a NEGs zonais, consulte o artigo Interfaces de rede e back-ends de NEG zonais.

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
Os serviços de back-end não podem distribuir tráfego para VMs de membros do grupo de instâncias em interfaces que não sejam nic0. Se quiser receber tráfego numa interface de rede não nic0 (vNICs ou interfaces de rede dinâmicas), tem de usar NEGs zonais com GCE_VM_IPendpoints.

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.

Serviços de back-end e redes VPC

O serviço de back-end não está associado a nenhuma rede VPC; no entanto, cada grupo de instâncias de back-end ou NEG zonal está associado a uma rede VPC, conforme mencionado anteriormente. Desde que todos os back-ends estejam localizados na mesma região e projeto, e desde que todos os back-ends sejam do mesmo tipo (grupos de instâncias ou NEGs zonais), pode adicionar back-ends que usem a mesma rede VPC ou redes VPC diferentes.

Para distribuir pacotes para uma interface não nic0, tem de usar back-ends de NEG zonais (com pontos finais GCE_VM_IP).

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 EXTERNAL ou INTERNAL. Se o ipv6-access-type da sub-rede de back-end estiver definido como INTERNAL, tem de usar uma sub-rede apenas IPv6 diferente ou uma sub-rede de pilha dupla com o ipv6-access-type definido como EXTERNAL para a regra de encaminhamento externo do balanceador de carga.
  • 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 ver instruçõ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 INTERNAL, tem de usar uma sub-rede apenas IPv6 diferente com o ipv6-access-type definido como EXTERNAL para a regra de encaminhamento externo 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 ver instruçõ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.

Verificações de funcionamento

Os equilibradores de carga de encaminhamento externo usam verificações de funcionamento regionais para determinar que instâncias podem receber novas ligações. Cada serviço de back-end do balanceador de carga de rede de encaminhamento externo tem de estar associado a uma verificação de estado regional. Os equilibradores de carga usam o estado da verificação de estado para determinar como encaminhar novas ligações para instâncias de back-end.

Para mais detalhes sobre o funcionamento das Google Cloud verificações de saúde, consulte o artigo Como funcionam as verificações de saúde.

Os balanceadores de carga de rede de encaminhamento externo suportam os seguintes tipos de verificações de funcionamento:

Verificações de funcionamento para outro tráfego de protocolo

Google Cloud não oferece verificações de estado específicas do protocolo além das indicadas na secção Verificações de estado, anteriormente nesta página. Quando usa um Network Load Balancer de passagem externo para fazer o balanceamento de carga de um protocolo que não seja TCP, tem de executar um serviço baseado em TCP nas suas VMs de back-end para fornecer as informações de verificação de funcionamento necessárias.

Por exemplo, se estiver a fazer o balanceamento de carga do tráfego UDP, os pedidos do cliente são balanceados de carga através do protocolo UDP, e tem de executar um serviço TCP para fornecer informações aos verificadores de funcionamento. Google Cloud Para tal, pode executar um servidor HTTP em cada VM de back-end que devolva uma resposta HTTP 200 aos sondadores de verificação de estado. Deve usar a sua própria lógica executada na VM de back-end para garantir que o servidor HTTP devolve 200 apenas se o serviço UDP estiver corretamente configurado e em execução.

Regras de firewall

Uma vez que os balanceadores de carga de rede de encaminhamento externo são balanceadores de carga de encaminhamento, controla o acesso aos back-ends do balanceador de carga através de regras de firewall. Google Cloud Tem de criar regras de firewall de permissão de entrada ou uma política de firewall hierárquica de permissão de entrada para permitir verificações de funcionamento e o tráfego que está a balancear a carga.

As regras de encaminhamento e as regras de firewall de entrada permitidas ou as políticas de firewall hierárquicas funcionam em conjunto da seguinte forma: uma regra de encaminhamento especifica o protocolo e, se definidos, os requisitos de porta que um pacote tem de cumprir para ser encaminhado para uma VM de back-end. As regras de firewall de autorização de entrada controlam se os pacotes encaminhados são entregues à VM ou rejeitados. Todas as redes VPC têm uma regra de firewall de negação implícita de entrada que bloqueia pacotes recebidos de qualquer origem. A rede de VPC Google Cloud predefinida inclui um conjunto limitado de regras de firewall de autorização de entrada pré-preenchidas.

  • Para aceitar tráfego de qualquer endereço IP na Internet, tem de criar uma regra de firewall de autorização de entrada com o intervalo de origem 0.0.0.0/0. Para permitir apenas tráfego de determinados intervalos de endereços IP, use intervalos de origem mais restritivos.

  • Como prática recomendada de segurança, as regras de firewall de permissão de entrada devem apenas permitir os protocolos e as portas IP de que precisa. Restringir a configuração do protocolo (e, se possível, da porta) é especialmente importante quando usar regras de encaminhamento cujo protocolo esteja definido como L3_DEFAULT. L3_DEFAULT regras de encaminhamento encaminham pacotes para todos os protocolos IP suportados (em todas as portas se o protocolo e o pacote tiverem informações de portas).

  • Os balanceadores de carga de rede de encaminhamento externo usam Google Cloud verificações de funcionamento. Por conseguinte, tem de permitir sempre o tráfego dos intervalos de endereços IP de verificação de funcionamento. Estas regras de firewall de permissão de entrada podem ser específicas do protocolo e das portas da verificação de estado do balanceador de carga.

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 endereço IP externo associado a uma Google Cloud VM ou um endereço IP encaminhável pela Internet de um sistema que se liga ao equilibrador de carga.
  • Destino: o endereço IP da regra de encaminhamento do balanceador de carga.

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, o ESP, o GRE e o ICMP não têm ligação. 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 a qualquer endereço IP externo 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, ESP, GRE, ICMP 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 solicitação.

1 Quando uma VM tem um endereço IP externo ou quando está a usar o Cloud NAT, também é possível definir o endereço IP de origem do pacote de resposta para o endereço IPv4 interno principal da NIC da VM. Google Cloud Em alternativa, o Cloud NAT altera o endereço IP de origem do pacote de resposta para o endereço IPv4 externo da NIC ou um endereço IPv4 externo do Cloud NAT para 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 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 para o qual enviou um pacote de pedido.

Caminho de retorno

Os balanceadores de carga de rede de encaminhamento externo usam rotas especiais fora da sua rede VPC para direcionar os pedidos recebidos e as sondas de verificação de funcionamento para 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 a passar pelo equilibrador de carga. O termo da indústria para isto é devolução direta do servidor.

Conetividade de Internet de saída a partir de back-ends

As instâncias de VM configuradas como pontos finais de back-end de um equilibrador de carga de rede de encaminhamento externo podem iniciar ligações à Internet através do endereço IP da regra de encaminhamento do equilibrador de carga como o endereço IP de origem da ligação de saída.

Geralmente, uma instância de VM usa sempre o seu próprio endereço IP externo ou o Cloud NAT para iniciar ligações. Usa o endereço IP da regra de encaminhamento para iniciar ligações a partir de pontos finais de back-end apenas em cenários especiais, como quando precisa que as instâncias de VMs originem e recebam ligações no mesmo endereço IP externo, e também precisa da redundância de back-end fornecida pelo equilibrador de carga de rede de passagem externa para ligações de entrada.

Os pacotes de saída enviados das VMs de back-end diretamente para a Internet não têm restrições nos protocolos e nas portas de tráfego. Mesmo que um pacote de saída use o endereço IP da regra de encaminhamento como origem, o protocolo e a porta de origem do pacote não têm de corresponder ao protocolo e à especificação da porta da regra de encaminhamento. No entanto, os pacotes de resposta de entrada têm de corresponder ao endereço IP, ao protocolo e à porta de destino da regra de encaminhamento. Para mais informações, consulte Caminhos para balanceadores de carga de rede de encaminhamento direto externos e encaminhamento de protocolos externos.

Além disso, todas as respostas às ligações de saída da VM estão sujeitas ao equilíbrio de carga, tal como todos os outros pacotes recebidos destinados ao equilibrador de carga. Isto significa que as respostas podem não chegar à mesma VM de back-end que iniciou a ligação à Internet. Se as ligações de saída e as ligações de entrada com balanceamento de carga partilharem protocolos e portas comuns, pode experimentar uma das seguintes sugestões:

  • Sincronizar o estado da ligação de saída nas VMs de back-end, para que as ligações possam ser processadas mesmo que as respostas cheguem a uma VM de back-end diferente da que iniciou a ligação.

  • Use uma configuração de failover com uma única VM principal e uma única VM de cópia de segurança. Em seguida, a VM de back-end ativa que inicia as ligações de saída recebe sempre os pacotes de resposta.

Este caminho para a conetividade à Internet a partir dos back-ends de um Network Load Balancer de passagem externo é o comportamento pretendido predefinido de acordo com as regras de firewall implícitas do Google Cloud. No entanto, se tiver preocupações de segurança sobre deixar este caminho aberto, pode usar regras de firewall de saída segmentadas para bloquear o tráfego de saída não solicitado para a Internet.

Arquitetura de VPC partilhada

Exceto o endereço IP, todos os componentes de um balanceador de carga de rede de encaminhamento externo têm de existir no mesmo projeto. A tabela seguinte resume os componentes da VPC partilhada para balanceadores de carga de rede de encaminhamento externo:

Endereço IP Regra de encaminhamento Componentes de back-end
Um endereço IP externo regional tem de ser definido no mesmo projeto que o balanceador de carga ou o projeto anfitrião da VPC partilhada. Uma regra de encaminhamento externo regional tem de ser definida no mesmo projeto que as instâncias no serviço de back-end.

O serviço de back-end regional tem de ser definido no mesmo projeto e na mesma região onde existem os back-ends (grupo de instâncias ou NEG zonal).

As verificações de estado de funcionamento associadas ao serviço de back-end têm de ser definidas no mesmo projeto e na mesma região que o serviço de back-end.

Distribuição de tráfego

Os balanceadores de carga de encaminhamento externo suportam várias opções de personalização da distribuição de tráfego, incluindo afinidade de sessão, acompanhamento de ligações, balanceamento de carga ponderado e comutação por falha. Para ver detalhes sobre como os balanceadores de carga de rede de encaminhamento externo 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 externo.

Limitações

  • Não pode usar a Google Cloud consola para realizar as seguintes tarefas:

    • Crie ou modifique um balanceador de carga de rede de encaminhamento externo cuja regra de encaminhamento use o protocolo L3_DEFAULT.
    • Crie ou modifique um balanceador de carga de rede de passagem externo cujo protocolo de serviço de back-end esteja definido como UNSPECIFIED.
    • Crie ou modifique um Network Load Balancer de encaminhamento externo que configure uma política de acompanhamento de ligações.
    • Crie ou modifique o encaminhamento de tráfego baseado no IP de origem para uma regra de encaminhamento.

    Em alternativa, use a CLI do Google Cloud ou a API REST.

  • Os balanceadores de carga de rede de passagem externos não suportam o intercâmbio da rede da VPC.

Preços

Para ver informações de preços, consulte a secção Preços.

O que se segue?