Vista geral do balanceador de carga de rede de proxy externo

Este documento apresenta os conceitos que tem de compreender para configurar um balanceador de carga de rede de proxy externo. Google Cloud

O balanceador de carga de rede de proxy externo é um balanceador de carga de proxy inverso que distribui o tráfego TCP proveniente da Internet para instâncias de máquinas virtuais (VM) na sua rede de nuvem virtual privada (VPC).Google Cloud Quando usa um balanceador de carga de rede de proxy externo, o tráfego TCP ou SSL recebido é terminado no balanceador de carga. Em seguida, uma nova ligação encaminha o tráfego para o back-end disponível mais próximo através de TCP ou SSL (recomendado). Para mais exemplos de utilização, consulte a vista geral do balanceador de carga de rede de proxy.

Os balanceadores de carga de rede de proxy externos permitem-lhe usar um único endereço IP para todos os utilizadores a nível mundial. O balanceador de carga encaminha automaticamente o tráfego para os back-ends mais próximos do utilizador.

Neste exemplo, o tráfego SSL dos utilizadores na cidade A e na cidade B é terminado na camada de equilíbrio de carga, e é estabelecida uma ligação separada ao back-end selecionado.

Cloud Load Balancing com terminação SSL (clique para aumentar).

Nota: embora os balanceadores de carga de rede de proxy externos possam suportar tráfego HTTPS, deve usar um balanceador de carga de aplicações externo para o tráfego HTTPS. Os balanceadores de carga de aplicações externos suportam várias funcionalidades específicas de HTTP, incluindo o encaminhamento por caminho de pedido HTTP e o balanceamento por taxa de pedidos. Para mais detalhes, consulte a vista geral do balanceador de carga de aplicações externo.

Modos de funcionamento

Pode configurar um equilibrador de carga de rede de proxy externo nos seguintes modos:

• Um balanceador de carga de rede de proxy clássico é implementado em Google Front Ends (GFEs) distribuídos globalmente. Este balanceador de carga pode ser configurado para processar tráfego TCP ou SSL através de um proxy TCP de destino ou um proxy SSL de destino, respetivamente. Com o nível Premium, este balanceador de carga pode ser configurado como um serviço de balanceamento de carga global. Com o nível padrão, este balanceador de carga é configurado como um serviço de balanceamento de carga regional. Os Network Load Balancers de proxy clássicos também podem ser usados para outros protocolos que usam SSL, como WebSockets e IMAP sobre SSL.
• Um balanceador de carga de rede de proxy externo global é implementado em GFEs distribuídos globalmente e suporta capacidades de gestão de tráfego avançada. Este balanceador de carga pode ser configurado para processar tráfego TCP ou SSL através de um proxy TCP de destino ou um proxy SSL de destino, respetivamente. Este balanceador de carga está configurado como um serviço de balanceamento de carga global com o nível Premium. Os balanceadores de carga de rede de proxy externos globais também podem ser usados para outros protocolos que usam SSL, como WebSockets e IMAP através de SSL.
• Um balanceador de carga de rede de proxy externo regional é implementado na pilha de software de proxy Envoy de código aberto. Só pode processar tráfego TCP. Este balanceador de carga está configurado como um serviço de balanceamento de carga regional que pode usar o nível Premium ou Standard.

Identifique o modo

Para determinar o modo de um equilibrador de carga, conclua os passos seguintes.

Consola

1. Na Google Cloud consola, aceda à página Equilíbrio de carga.

   Aceda a Balanceamento de carga

2. No separador Balanceadores de carga, são apresentados o tipo, o protocolo e a região do balanceador de carga. Se a região estiver em branco, o balanceador de carga é global.

   A tabela seguinte resume como identificar o modo do equilibrador de carga.

   Modo do balanceador de carga	Tipo de balanceador de carga	Tipo de acesso	Região
   Balanceador de carga de rede de proxy clássico	Rede (proxy clássico)	Externo
   Balanceador de carga de rede de proxy externo global	Rede (proxy)	Externo
   Balanceador de carga de rede de proxy externo regional	Rede (proxy)	Externo	Especifica uma região

gcloud

1. Use o comando gcloud compute forwarding-rules describe:

   gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
   

2. Na saída do comando, verifique o esquema de balanceamento de carga, a região e o nível de rede. A tabela seguinte resume como identificar o modo do equilibrador de carga.

   Modo do balanceador de carga	Esquema de balanceamento de carga	Regra de encaminhamento	Nível da rede
   Balanceador de carga de rede de proxy clássico	EXTERNO	Global	Standard ou Premium
   Balanceador de carga de rede de proxy externo global	EXTERNAL_MANAGED	Global	Premium
   Balanceador de carga de rede de proxy externo regional	EXTERNAL_MANAGED	Regional	Standard ou Premium

Importante: depois de criar um equilibrador de carga, não pode editar o respetivo modo. Em alternativa, tem de eliminar o balanceador de carga e criar um novo.

Arquitetura

Os diagramas seguintes mostram os componentes dos balanceadores de carga de rede de proxy externos.

Global

Este diagrama mostra os componentes de uma implementação de um balanceador de carga de rede de proxy externo global. Esta arquitetura aplica-se ao balanceador de carga de rede de proxy externo global e ao balanceador de carga de rede de proxy clássico no nível Premium.

Componentes do Network Load Balancer do proxy externo global (clique para aumentar).

Regional

Este diagrama mostra os componentes de uma implementação de um balanceador de carga de rede de proxy externo regional.

Componentes do balanceador de carga de rede de proxy externo regional (clique para aumentar).

Seguem-se os componentes dos balanceadores de carga de rede de proxy externos.

Sub-rede só de proxy

Nota: as sub-redes só de proxy só são necessárias para balanceadores de carga de rede de proxy externos regionais.

A sub-rede só de proxy fornece um conjunto de endereços IP que a Google usa para executar proxies do Envoy em seu nome. Tem de criar uma sub-rede apenas de proxy em cada região de uma rede VPC onde usa equilibradores de carga. A flag --purpose para esta sub-rede só de proxy está definida como REGIONAL_MANAGED_PROXY. Todos os equilibradores de carga baseados no Envoy regionais na mesma região e rede VPC partilham um conjunto de proxies do Envoy da mesma sub-rede apenas de proxy.

As VMs ou os pontos finais de back-end de todos os equilibradores de carga numa região e numa rede VPC recebem ligações da sub-rede apenas de proxy.

Pontos a ter em conta:

• As sub-redes apenas de proxy são usadas apenas para proxies do Envoy e não para os seus back-ends.
• O endereço IP do balanceador de carga não está localizado na sub-rede só de proxy. O endereço IP do balanceador de carga é definido pela respetiva regra de encaminhamento gerida externa.

Regras de encaminhamento e endereços IP

As regras de encaminhamento encaminham o tráfego por endereço IP, porta e protocolo para uma configuração de equilíbrio de carga que consiste num proxy de destino e num serviço de back-end.

Especificação do endereço IP. Cada regra de encaminhamento faz referência a um único endereço IP que pode usar nos registos DNS da sua aplicação. Pode reservar um endereço IP estático que pode usar ou permitir que o Cloud Load Balancing lhe atribua um. Recomendamos que reserve um endereço IP estático. Caso contrário, tem de atualizar o registo DNS com o endereço IP efémero recém-atribuído sempre que eliminar uma regra de encaminhamento e criar uma nova.

Especificação da porta. As regras de encaminhamento externas usadas na definição deste equilibrador de carga podem referenciar exatamente uma porta de 1 a 65535. Se quiser suportar várias portas consecutivas, tem de configurar várias regras de encaminhamento. É possível configurar várias regras de encaminhamento com o mesmo endereço IP virtual e portas diferentes. Por conseguinte, pode usar proxy de várias aplicações com portas personalizadas separadas para o mesmo endereço IP virtual do proxy TCP. Para mais detalhes, consulte as Especificações de portas para regras de encaminhamento.

Para suportar várias portas consecutivas, tem de configurar várias regras de encaminhamento. É possível configurar várias regras de encaminhamento com o mesmo endereço IP virtual e portas diferentes. Por conseguinte, pode usar proxy de várias aplicações com portas personalizadas separadas para o mesmo endereço IP virtual do proxy TCP.

A tabela seguinte mostra os requisitos das regras de encaminhamento para balanceadores de carga de rede de proxy externos.

Modo do balanceador de carga	Nível de serviço de rede	Regra de encaminhamento, endereço IP e esquema de balanceamento de carga	Encaminhamento da Internet para a interface do balanceador de carga
Balanceador de carga de rede de proxy clássico	Nível premium	Regra de encaminhamento externo global Global endereço IP externo Esquema de balanceamento de carga: EXTERNAL	Pedidos encaminhados para os GFEs mais próximos do cliente na Internet.
	Nível Standard	Regra de encaminhamento externo regional Endereço IP externo regional Esquema de balanceamento de carga: EXTERNAL	Pedidos encaminhados para um GFE na região do balanceador de carga.
Balanceador de carga de rede de proxy externo global	Nível premium	Regra de encaminhamento externo global Global endereço IP externo Esquema de balanceamento de carga: EXTERNAL_MANAGED	Pedidos encaminhados para os GFEs mais próximos do cliente na Internet.
Balanceador de carga de rede de proxy externo regional	Nível Premiume Standard	Regra de encaminhamento externo regional Endereço IP externo regional Esquema de balanceamento de carga: EXTERNAL_MANAGED	Pedidos encaminhados para os proxies do Envoy na mesma região que o balanceador de carga.

Regras de encaminhamento e redes VPC

Esta secção descreve como as regras de encaminhamento usadas por equilibradores de carga de aplicações externos estão associadas a redes VPC.

Modo do balanceador de carga	Associação da rede da VPC
Balanceador de carga de rede de proxy externo global Balanceador de carga de rede de proxy clássico	Nenhuma rede de VPC associada. A regra de encaminhamento usa sempre um endereço IP que está fora da rede VPC. Por conseguinte, a regra de encaminhamento não tem nenhuma rede de VPC associada.
Balanceador de carga de rede de proxy externo regional	A rede VPC da regra de encaminhamento é a rede onde a sub-rede só de proxy foi criada. Especifica a rede quando cria a regra de encaminhamento.

Proxies de destino

Os equilibradores de carga de rede de proxy externos terminam as ligações do cliente e criam novas ligações aos back-ends. O proxy de destino encaminha estas novas ligações para o serviço de back-end.

Consoante o tipo de tráfego que a sua aplicação tem de processar, pode configurar um balanceador de carga de rede de proxy externo com um proxy TCP de destino ou um proxy SSL de destino.

• Proxy TCP de destino: configure o balanceador de carga com um proxy TCP de destino se estiver à espera de tráfego TCP.
• Alvo do proxy SSL: configure o equilibrador de carga com um proxy SSL de destino se esperar tráfego de cliente encriptado. Este tipo de balanceador de carga destina-se apenas ao tráfego não HTTP(S). Para o tráfego HTTP(S), recomendamos que use um balanceador de carga de aplicações externo.

Por predefinição, o proxy de destino não preserva o endereço IP do cliente original e as informações da porta. Pode preservar estas informações ativando o protocolo PROXY no proxy de destino.

A tabela seguinte mostra os requisitos de proxy de destino para equilibradores de carga de rede de proxy externos.

Modo do balanceador de carga	Nível de serviço de rede	Proxy de destino
Balanceador de carga de rede de proxy clássico	Nível premium	targetTcpProxies ou targetSslProxies
	Nível Standard	targetTcpProxies ou targetSslProxies
Balanceador de carga de rede de proxy externo global	Nível premium	targetTcpProxies ou targetSslProxies
Balanceador de carga de rede de proxy externo regional	Nível Premium e Standard	regionTargetTcpProxies

Certificados SSL

Os certificados SSL só são necessários se estiver a implementar um balanceador de carga de rede de proxy externo global e um balanceador de carga de rede de proxy clássico com um proxy SSL de destino.

Os balanceadores de carga de rede de proxy externos que usam proxies SSL de destino requerem chaves privadas e certificados SSL como parte da configuração do balanceador de carga.

• OGoogle Cloud oferece dois métodos de configuração para atribuir chaves privadas e certificados SSL a proxies SSL de destino: certificados SSL do Compute Engine e Certificate Manager. Para ver uma descrição de cada configuração, consulte os métodos de configuração de certificados na vista geral dos certificados SSL.

• Google Cloud oferece dois tipos de certificados: autogerido e gerido pela Google. Para uma descrição de cada tipo, consulte Tipos de certificados na vista geral dos certificados SSL.

Serviços de back-end

Os serviços de back-end direcionam o tráfego de entrada para um ou mais back-ends anexados. Cada back-end é composto por um grupo de instâncias ou um grupo de pontos finais de rede e informações sobre a capacidade de publicação do back-end. A capacidade de publicação de back-end pode basear-se na CPU ou nos pedidos por segundo (RPS).

Cada balanceador de carga tem um único recurso de serviço de back-end que especifica a verificação de estado a realizar para os back-ends disponíveis.

As alterações feitas ao serviço de back-end não são instantâneas. Pode demorar vários minutos para que as alterações se propaguem para os GFEs. Para garantir interrupções mínimas aos seus utilizadores, pode ativar a drenagem de ligações nos serviços de back-end. Essas interrupções podem ocorrer quando um back-end é terminado, removido manualmente ou removido por um escalador automático. Para saber mais sobre a utilização da drenagem de ligações para minimizar as interrupções do serviço, consulte o artigo Ativar a drenagem de ligações.

Para mais informações acerca do recurso de serviço de back-end, consulte o artigo Vista geral dos serviços de back-end.

A tabela seguinte especifica os diferentes back-ends suportados no serviço de back-end dos balanceadores de carga de rede de proxy externo.

Modo do balanceador de carga	Back-ends suportados num serviço de back-end
	Grupos de instâncias	NEGs zonais	NEGs da Internet	NEGs sem servidor	NEGs híbridos	NEGs do Private Service Connect	GKE
Balanceador de carga de rede de proxy clássico		Use NEGs zonais autónomos
Balanceador de carga de rede de proxy externo global	^*	GCE_VM_IP_PORT type endpoints ^*
Balanceador de carga de rede de proxy externo regional		Pontos finais do tipo GCE_VM_IP_PORT	Apenas NEGs regionais			Adicione um NEG do Private Service Connect

^* Os balanceadores de carga de rede de proxy externos globais suportam grupos de instâncias IPv4 e IPv6 (duplo stack) e back-ends NEG zonais com pontos finais GCE_VM_IP_PORT.

Back-ends e redes VPC

Para back-ends do balanceador de carga de rede de proxy externo global e do balanceador de carga de rede de proxy clássico, todas as instâncias de back-end de back-ends do grupo de instâncias e todos os pontos finais de back-end de back-ends do NEG têm de estar localizados no mesmo projeto. No entanto, um back-end de grupo de instâncias ou um NEG pode usar uma rede VPC diferente nesse projeto. Não é necessário ligar as diferentes redes VPC através do intercâmbio das redes da VPC, uma vez que os GFEs comunicam diretamente com os back-ends nas respetivas redes VPC.

Para back-ends de balanceadores de carga de rede de proxy externos regionais, aplica-se o seguinte:

• Para grupos de instâncias, NEGs zonais e NEGs de conetividade híbrida, todos os back-ends têm de estar localizados no mesmo projeto e região que o serviço de back-end. No entanto, um equilibrador de carga pode fazer referência a um back-end que usa uma rede VPC diferente no mesmo projeto que o serviço de back-end. A conetividade entre a rede VPC do balanceador de carga e a rede VPC de back-end pode ser configurada através do intercâmbio da rede VPC, de túneis do Cloud VPN, de anexos de VLAN do Cloud Interconnect ou de uma framework do Network Connectivity Center.

  Definição da rede de back-end

  • Para NEGs zonais e NEGs híbridos, especifica explicitamente a rede VPC quando cria o NEG.
  • Para grupos de instâncias geridas, a rede VPC é definida no modelo de instância.
  • Para grupos de instâncias não geridos, a rede VPC do grupo de instâncias é definida para corresponder à rede VPC da interface nic0 para a primeira VM adicionada ao grupo de instâncias.

  Requisitos de rede de back-end

  A rede do seu back-end tem de cumprir um dos seguintes requisitos de rede:

  • A rede da VPC do back-end tem de corresponder exatamente à rede da VPC da regra de encaminhamento.

  • A rede da VPC do back-end tem de estar ligada à rede da VPC da regra de encaminhamento através do intercâmbio das redes da VPC. Tem de configurar as trocas de trajetos de sub-rede para permitir a comunicação entre a sub-rede apenas de proxy na rede VPC da regra de encaminhamento e as sub-redes usadas pelas instâncias ou os pontos finais de back-end.

• Tanto a rede de VPC do back-end como a rede de VPC da regra de encaminhamento têm de ter raios de VPC anexados ao mesmo hub do Network Connectivity Center. Os filtros de importação e exportação têm de permitir a comunicação entre a sub-rede apenas de proxy na rede VPC da regra de encaminhamento e as sub-redes usadas por instâncias ou pontos finais de back-end.

• Para todos os outros tipos de back-end, todos os back-ends têm de estar localizados na mesma rede e região da VPC.

Back-ends e interfaces de rede

Se usar back-ends de grupos de instâncias, os pacotes são sempre entregues a nic0. Se quiser enviar pacotes para interfaces não nic0 (vNICs ou interfaces de rede dinâmicas), use backends de NEG.

Se usar back-ends de NEG zonais, os pacotes são enviados para qualquer interface de rede representada pelo ponto final no NEG. Os pontos finais do NEG têm de estar na mesma rede VPC que a rede VPC definida explicitamente do NEG.

Protocolo para comunicar com os back-ends

Quando configura um serviço de back-end para um equilibrador de carga de rede de proxy externo, define o protocolo que o serviço de back-end usa para comunicar com os back-ends.

• Para balanceadores de carga de rede de proxy clássicos, pode escolher TCP ou SSL.
• Para balanceadores de carga de rede de proxy externos globais, pode escolher TCP ou SSL.
• Para balanceadores de carga de rede de proxy externos regionais, pode usar o TCP.

O balanceador de carga usa apenas o protocolo que especificar e não tenta negociar uma ligação com o outro protocolo.

Regras de firewall

As seguintes regras de firewall são obrigatórias:

• Para os balanceadores de carga de rede de proxy clássicos, uma regra de firewall de allowentrada para permitir que o tráfego dos GFEs alcance os seus back-ends.

• Para balanceadores de carga de rede de proxy externo globais, uma regra de firewall de allowentrada para permitir o tráfego de GFEs para alcançar os seus back-ends.

• Para balanceadores de carga de rede de proxy externo regionais, uma regra de firewall de entrada para permitir tráfego da sub-rede só de proxy para alcançar os seus back-ends.

• Uma regra de firewall de allow entrada para permitir que o tráfego dos intervalos de sondas de verificação de estado alcance os seus back-ends. Para mais informações sobre as sondas de verificação de funcionamento e o motivo pelo qual é necessário permitir o tráfego das mesmas, consulte o artigo Intervalos de IPs de sondas e regras da firewall.

As regras de firewall são implementadas ao nível da instância de VM e não ao nível dos proxies do GFE. Não pode usar regras de firewall para impedir que o tráfego chegue ao equilibrador de carga.

As portas destas regras de firewall têm de ser configuradas da seguinte forma:

• Permita o tráfego para a porta de destino da verificação do estado de funcionamento de cada serviço de back-end.
• Para back-ends de grupos de instâncias: determine as portas a configurar através do mapeamento entre a porta com nome do serviço de back-end e os números das portas associados a essa porta com nome em cada grupo de instâncias. Os números das portas podem variar entre grupos de instâncias atribuídos ao mesmo serviço de back-end.
• Para back-ends de NEG zonais: permita o tráfego para os números de porta dos pontos finais.GCE_VM_IP_PORT NEG

A tabela seguinte resume os intervalos de endereços IP de origem necessários para as regras de firewall.

Modo do balanceador de carga	Intervalos de origens de verificações de funcionamento	Intervalos de origens dos pedidos
Balanceador de carga de rede de proxy externo global	35.191.0.0/16 130.211.0.0/22 Para o tráfego IPv6 para os back-ends: 2600:2d00:1:b029::/64	A origem do tráfego do GFE depende do tipo de back-end: Grupos de instâncias e NEGs zonais (GCE_VM_IP_PORT): 130.211.0.0/22 35.191.0.0/16 Para o tráfego IPv6 para os back-ends: 2600:2d00:1:1::/64
Balanceador de carga de rede de proxy clássico	35.191.0.0/16 130.211.0.0/22	Estes intervalos aplicam-se a pedidos e sondagens de verificação de funcionamento do GFE.
Balanceador de carga de rede de proxy externo regional ^*, †	35.191.0.0/16 130.211.0.0/22 Para o tráfego IPv6 para os back-ends: 2600:2d00:1:b029::/64	Estes intervalos aplicam-se a sondas de verificações de funcionamento.

^* Não é necessário permitir tráfego dos intervalos de sondagem de verificação de estado da Google para NEGs híbridos. No entanto, se estiver a usar uma combinação de NEGs híbridos e zonais num único serviço de back-end, tem de permitir o tráfego dos intervalos de sondas de verificação de estado da Google para os NEGs zonais.

^† Para NEGs de Internet regionais, as verificações de saúde são opcionais. O tráfego dos balanceadores de carga que usam NEGs de Internet regionais tem origem na sub-rede apenas de proxy e, em seguida, é traduzido pela NAT (através da NAT da nuvem) para endereços IP da NAT alocados manual ou automaticamente. Este tráfego inclui sondagens de verificação de funcionamento e pedidos de utilizadores do equilibrador de carga para os back-ends. Para ver detalhes, consulte o artigo NEGs regionais: use um gateway NAT da nuvem.

Importante: certifique-se de que permite pacotes dos intervalos de verificação de estado completos. Se a sua regra de firewall permitir pacotes apenas de um subconjunto dos intervalos, pode ver falhas na verificação de estado porque o balanceador de carga não consegue comunicar com os seus back-ends. Isto provoca limites de tempo de ligação.

Endereços IP de origem

O endereço IP de origem dos pacotes, conforme visto pelos back-ends, não é o Google Cloud endereço IP externo do balanceador de carga. Por outras palavras, existem duas ligações TCP.

Para os balanceadores de carga de rede de proxy clássicos e os balanceadores de carga de rede de proxy externos globais:

• Ligação 1, do cliente original ao balanceador de carga (GFE):

  • Endereço IP de origem: o cliente original (ou o endereço IP externo se o cliente estiver atrás de um gateway NAT ou de um proxy de encaminhamento).
  • Endereço IP de destino: o endereço IP do seu equilibrador de carga.

• Ligação 2, do equilibrador de carga (GFE) à VM ou ao ponto final do back-end:

  • Endereço IP de origem: um endereço IP num dos intervalos especificados nas Regras de firewall.

  • Endereço IP de destino: o endereço IP interno da VM ou do contentor de back-end na rede VPC.

Para os equilibradores de carga de rede de proxy externos regionais:

• Ligação 1, do cliente original ao equilibrador de carga (sub-rede apenas de proxy):

  • Endereço IP de origem: o cliente original (ou o endereço IP externo se o cliente estiver atrás de um gateway NAT ou de um proxy de encaminhamento).
  • Endereço IP de destino: o endereço IP do seu equilibrador de carga.

• Ligação 2, do balanceador de carga (sub-rede apenas de proxy) à VM ou ao ponto final de back-end:

  • Endereço IP de origem: um endereço IP na sub-rede só de proxy que é partilhado entre todos os balanceadores de carga baseados no Envoy implementados na mesma região e rede que o balanceador de carga.

  • Endereço IP de destino: o endereço IP interno da VM ou do contentor de back-end na rede VPC.

Portas abertas

Os balanceadores de carga de rede de proxy externos são balanceadores de carga de proxy inverso. O balanceador de carga termina as ligações recebidas e, em seguida, abre novas ligações do balanceador de carga aos back-ends. Estes balanceadores de carga são implementados através de proxies do Google Front End (GFE) em todo o mundo.

Os GFEs têm várias portas abertas para suportar outros serviços Google que são executados na mesma arquitetura. Quando executa uma análise de portas, pode ver outras portas abertas para outros serviços Google em execução em GFEs.

A execução de uma análise de portas no endereço IP de um equilibrador de carga baseado no GFE não é útil do ponto de vista da auditoria pelos seguintes motivos:

• Uma análise de portas (por exemplo, com nmap) geralmente não espera um pacote de resposta ou um pacote TCP RST quando realiza a sondagem TCP SYN. Os GFEs enviam pacotes SYN-ACK em resposta a sondagens SYN apenas para portas nas quais configurou uma regra de encaminhamento. Os GFEs só enviam pacotes para os seus back-ends em resposta a pacotes enviados para o endereço IP do seu equilibrador de carga e a porta de destino configurada na respetiva regra de encaminhamento. Os pacotes enviados para um endereço IP ou uma porta diferentes não são enviados para os seus back-ends.

  Os GFEs implementam funcionalidades de segurança, como o Google Cloud Armor. Com o Cloud Armor Standard, os GFEs oferecem proteção sempre ativada contra ataques DDoS volumétricos e baseados em protocolos e ataques SYN "flood". Esta proteção está disponível mesmo que não tenha configurado explicitamente o Cloud Armor. A cobrança só é feita se configurar políticas de segurança ou se se inscrever na Proteção gerida Plus.

• Os pacotes enviados para o endereço IP do seu equilibrador de carga podem ser respondidos por qualquer GFE na frota da Google. No entanto, a análise de um endereço IP do equilibrador de carga e de uma combinação de porta de destino apenas interroga um único GFE por ligação TCP. O endereço IP do seu equilibrador de carga não está atribuído a um único dispositivo ou sistema. Assim, a análise do endereço IP de um equilibrador de carga baseado no GFE não analisa todos os GFEs na frota da Google.

Com isto em mente, seguem-se algumas formas mais eficazes de auditar a segurança das suas instâncias de back-end:

• Um auditor de segurança deve inspecionar a configuração das regras de encaminhamento da configuração do equilibrador de carga. As regras de encaminhamento definem a porta de destino para a qual o balanceador de carga aceita pacotes e os encaminha para os back-ends. Para balanceadores de carga baseados no GFE, cada regra de encaminhamento externo só pode referenciar uma única porta TCP de destino.

• Um auditor de segurança deve inspecionar a configuração das regras da firewall aplicáveis às VMs de back-end. As regras de firewall que define bloqueiam o tráfego das GFEs para as VMs de back-end, mas não bloqueiam o tráfego de entrada para as GFEs. Para ver as práticas recomendadas, consulte a secção de regras da firewall.

Arquitetura de VPC partilhada

Os balanceadores de carga de rede de proxy externos regionais e os balanceadores de carga de rede de proxy clássicos suportam implementações que usam redes VPC partilhadas. A VPC partilhada permite-lhe manter uma separação clara de responsabilidades entre os administradores de rede e os programadores de serviços. As suas equipas de desenvolvimento podem concentrar-se na criação de serviços em projetos de serviços, e as equipas de infraestrutura de rede podem aprovisionar e administrar o equilíbrio de carga. Se ainda não conhece a VPC partilhada, leia a documentação de vista geral da VPC partilhada.

Endereço IP	Regra de encaminhamento	Proxy de destino	Componentes de back-end
Tem de definir um endereço IP externo no mesmo projeto que o equilibrador de carga.	A regra de encaminhamento externo tem de ser definida no mesmo projeto que as instâncias de back-end (o projeto de serviço).	O proxy TCP ou SSL alvo tem de ser definido no mesmo projeto que as instâncias de back-end.	Para os balanceadores de carga de rede de proxy clássicos, tem de definir um serviço de back-end global no mesmo projeto que as instâncias de back-end. Estas instâncias têm de estar em grupos de instâncias anexados ao serviço de back-end como back-ends. As verificações de estado de funcionamento associadas aos serviços de back-end têm de ser definidas no mesmo projeto que o serviço de back-end. Para os balanceadores de carga de rede de proxy externos regionais, as VMs de back-end estão normalmente localizadas num projeto de serviço. Tem de definir um serviço de back-end regional e uma verificação de estado de funcionamento nesse projeto de serviço.

Nota: os equilibradores de carga de rede de proxy externos globais não suportam implementações que usam redes de VPC partilhadas.

Distribuição de tráfego

Quando adiciona um grupo de instâncias de back-end ou um NEG a um serviço de back-end, especifica um modo de balanceamento de carga, que define um método que mede a carga de back-end e a capacidade de destino.

Para balanceadores de carga de rede de proxy externos, o modo de balanceamento pode ser CONNECTION ou UTILIZATION:

• Se o modo de balanceamento de carga for CONNECTION, a carga é distribuída com base no número total de ligações que o back-end pode processar.
• Se o modo de balanceamento de carga for UTILIZATION, a carga é distribuída com base na utilização de instâncias num grupo de instâncias. Este modo de equilíbrio aplica-se apenas a back-ends do grupo de instâncias de VMs.

A distribuição do tráfego pelos back-ends é determinada pelo modo de balanceamento do balanceador de carga.

Balanceador de carga de rede de proxy clássico

Para o balanceador de carga de rede de proxy clássico, o modo de balanceamento é usado para selecionar o back-end mais favorável (grupo de instâncias ou NEG). Em seguida, o tráfego é distribuído de forma rotativa entre as instâncias ou os pontos finais no back-end.

Como são distribuídas as associações

Um Network Load Balancer proxy clássico pode ser configurado como um serviço de balanceamento de carga global com o nível Premium e como um serviço regional no nível Standard.

O modo de equilíbrio e a escolha do destino determinam a capacidade de back-end do ponto de vista de cada NEG zonal GCE_VM_IP_PORT, grupo de instâncias zonais ou zona de um grupo de instâncias regionais. Em seguida, o tráfego é distribuído numa zona através da hash consistente.

Para o nível premium

• Só pode ter um serviço de back-end, e o serviço de back-end pode ter back-ends em várias regiões. Para o balanceamento de carga global, implementa os seus back-ends em várias regiões, e o balanceador de carga direciona automaticamente o tráfego para a região mais próxima do utilizador. Se uma região estiver no limite da capacidade, o balanceador de carga encaminha automaticamente novas ligações para outra região com capacidade disponível. As associações de utilizadores existentes permanecem na região atual.

• A Google anuncia o endereço IP do balanceador de carga a partir de todos os pontos de presença a nível mundial. Cada endereço IP do balanceador de carga é anycast global.

• Se configurar um serviço de back-end com back-ends em várias regiões, os front-ends da Google (GFEs) tentam direcionar as solicitações para grupos de instâncias de back-end ou NEGs em bom estado na região mais próxima do utilizador.

Para o nível Standard

• A Google anuncia o endereço IP do seu equilibrador de carga a partir de pontos de presença associados à região da regra de encaminhamento. O balanceador de carga usa um endereço IP externo regional.

• Só pode configurar back-ends na mesma região que a regra de encaminhamento. O balanceador de carga apenas direciona pedidos para back-ends em bom estado nessa região.

Balanceador de carga de rede de proxy externo global

Para o balanceador de carga de rede de proxy externo global, a distribuição de tráfego baseia-se no modo de balanceamento de carga e na política de localidade do balanceamento de carga.

O modo de equilíbrio determina a ponderação e a fração do tráfego a enviar para cada grupo (grupo de instâncias ou NEG). A política de localidade do balanceamento de carga (LocalityLbPolicy) determina como os back-ends no grupo são balanceados de carga.

Quando um serviço de back-end recebe tráfego, primeiro direciona o tráfego para um back-end (grupo de instâncias ou NEG) de acordo com o modo de balanceamento do back-end. Depois de selecionar um back-end, o tráfego é distribuído entre instâncias ou pontos finais nesse grupo de back-end de acordo com a política de localidade de equilíbrio de carga.

Para mais informações, consulte o seguinte:

• Modo equilibrado.
• Política de localidade de equilíbrio de carga (documentação da API de serviço de back-end global).

Como são distribuídas as associações

Um Network Load Balancer de proxy externo global pode ser configurado como um serviço de balanceamento de carga global com o Nível Premium

O modo de equilíbrio e a escolha do destino determinam a capacidade de back-end na perspetiva de cada NEG zonal GCE_VM_IP_PORT ou grupo de instâncias zonais. Em seguida, o tráfego é distribuído numa zona através da hash consistente.

• Só pode ter um serviço de back-end, e o serviço de back-end pode ter back-ends em várias regiões. Para o balanceamento de carga global, implementa os seus back-ends em várias regiões, e o balanceador de carga direciona automaticamente o tráfego para a região mais próxima do utilizador. Se uma região estiver no limite da capacidade, o balanceador de carga encaminha automaticamente novas ligações para outra região com capacidade disponível. As associações de utilizadores existentes permanecem na região atual.

• A Google anuncia o endereço IP do balanceador de carga a partir de todos os pontos de presença a nível mundial. Cada endereço IP do balanceador de carga é anycast global.

• Se configurar um serviço de back-end com back-ends em várias regiões, os front-ends da Google (GFEs) tentam direcionar as solicitações para grupos de instâncias de back-end ou NEGs em bom estado na região mais próxima do utilizador.

Balanceador de carga de rede de proxy externo regional

Para os balanceadores de carga de rede de proxy externos regionais, a distribuição de tráfego baseia-se no modo de balanceamento de carga e na política de localidade do balanceamento de carga.

O modo de equilíbrio determina a ponderação e a fração do tráfego que deve ser enviada para cada back-end (grupo de instâncias ou NEG). A política de localidade do balanceamento de carga (LocalityLbPolicy) determina como os back-ends no grupo são balanceados de carga.

Quando um serviço de back-end recebe tráfego, primeiro direciona o tráfego para um back-end (grupo de instâncias ou NEG) de acordo com o respetivo modo de balanceamento. Depois de selecionar um back-end, o tráfego é distribuído entre instâncias ou pontos finais nesse grupo de back-end de acordo com a política de localidade de equilíbrio de carga.

Para mais informações, consulte o seguinte:

• Modos de equilíbrio
• Política de localidade de equilíbrio de carga (documentação da API de serviço de back-end regional)

Afinidade de sessão

A afinidade de sessão permite-lhe configurar o serviço de back-end do balanceador de carga para enviar todos os pedidos do mesmo cliente para o mesmo back-end, desde que o back-end esteja em bom estado e tenha capacidade.

Os balanceadores de carga de rede de proxy externos oferecem os seguintes tipos de afinidade de sessão:

• Nenhum

  Uma definição de afinidade de sessão de NONE não significa que não existe afinidade de sessão. Significa que não está configurada explicitamente nenhuma opção de afinidade de sessão.

  A aplicação de hash é sempre realizada para selecionar um back-end. Uma definição de afinidade de sessão de NONE significa que o balanceador de carga usa um hash de 5 tuplos para selecionar um back-end. O hash de 5 tuplos consiste no endereço IP de origem, na porta de origem, no protocolo, no endereço IP de destino e na porta de destino.

  Uma afinidade de sessão de NONE é o valor predefinido.

• Afinidade de IP do cliente

  A afinidade de sessão do IP do cliente (CLIENT_IP) é um hash de 2 tuplos criado a partir dos endereços IP de origem e destino do pacote. A afinidade de IP do cliente encaminha todos os pedidos do mesmo endereço IP do cliente para o mesmo back-end, desde que esse back-end tenha capacidade e permaneça em bom estado.

  Quando usa a afinidade de IP do cliente, tenha em atenção o seguinte:

  • O endereço IP de destino do pacote só é igual ao endereço IP da regra de encaminhamento do balanceador de carga se o pacote for enviado diretamente para o balanceador de carga.
  • O endereço IP de origem do pacote pode não corresponder a um endereço IP associado ao cliente original se o pacote for processado por um NAT intermédio ou um sistema de proxy antes de ser entregue a um equilibrador de carga. Google Cloud Em situações em que muitos clientes partilham o mesmo endereço IP de origem efetivo, algumas VMs de back-end podem receber mais ligações ou pedidos do que outras.

Tenha em atenção o seguinte quando configurar a afinidade de sessão:

• Não confie na afinidade de sessão para fins de autenticação ou segurança. A afinidade de sessão pode ser interrompida sempre que o número de back-ends de publicação e em bom estado de funcionamento muda. Para mais detalhes, consulte o artigo Perder a afinidade da sessão.

• Os valores predefinidos das flags --session-affinity e --subsetting-policy são ambos NONE, e só é possível definir um deles de cada vez para um valor diferente.

Perder a afinidade de sessão

Todas as opções de afinidade de sessão requerem o seguinte:

• A instância ou o ponto final do back-end selecionado tem de permanecer configurado como um back-end. A afinidade de sessão pode ser interrompida quando ocorre um dos seguintes eventos:
  • Remove a instância selecionada do respetivo grupo de instâncias.
  • O dimensionamento automático ou a autorreparação do grupo de instâncias geridas remove a instância selecionada do respetivo grupo de instâncias geridas.
  • Remove o ponto final selecionado do respetivo NEG.
  • Remove o grupo de instâncias ou o NEG que contém a instância ou o ponto final selecionado do serviço de back-end.
• A instância ou o ponto final do back-end selecionado tem de permanecer em bom estado. A afinidade de sessão pode ser interrompida quando a instância ou o ponto final selecionado falha nas verificações de estado.
• Para equilibradores de carga de rede de proxy externos globais e equilibradores de carga de rede de proxy clássicos, a afinidade de sessão pode falhar se for usado um Google Front End (GFE) de primeira camada diferente para pedidos ou ligações subsequentes após a alteração no caminho de encaminhamento. Pode ser selecionada uma GFE de primeira camada diferente se o caminho de encaminhamento de um cliente na Internet para a Google mudar entre pedidos ou ligações.

Todas as opções de afinidade de sessão têm os seguintes requisitos adicionais:

• O grupo de instâncias ou o NEG que contém a instância ou o ponto final selecionado não pode estar cheio, conforme definido pela respetiva capacidade alvo. (Para grupos de instâncias geridas regionais, o componente zonal do grupo de instâncias que contém a instância selecionada não pode estar cheio.) A afinidade de sessão pode ser interrompida quando o grupo de instâncias ou o NEG está cheio e outros grupos de instâncias ou NEGs não estão. Uma vez que a capacidade pode mudar de formas imprevisíveis quando usa o modo de balanceamento UTILIZATION, deve usar o modo de balanceamento RATE ou CONNECTION para minimizar as situações em que a afinidade de sessão pode ser interrompida.

• O número total de instâncias ou pontos finais de back-end configurados tem de permanecer constante. Quando ocorre, pelo menos, um dos seguintes eventos, o número de instâncias ou pontos finais de back-end configurados é alterado e a afinidade de sessão pode ser interrompida:

  • Adicionar novas instâncias ou pontos finais:

    • Adiciona instâncias a um grupo de instâncias existente no serviço de back-end.
    • O dimensionamento automático do grupo de instâncias geridas adiciona instâncias a um grupo de instâncias geridas no serviço de back-end.
    • Adiciona pontos finais a um NEG existente no serviço de back-end.
    • Adiciona grupos de instâncias ou NEGs não vazios ao serviço de back-end.

  • Remover qualquer instância ou ponto final, não apenas a instância ou o ponto final selecionado:

    • Remover qualquer instância de um back-end de grupo de instâncias.
    • O dimensionamento automático ou a autorreparação do grupo de instâncias geridas remove qualquer instância de um back-end do grupo de instâncias geridas.
    • Remover qualquer ponto final de um back-end do NEG.
    • Remova qualquer grupo de instâncias de back-end ou NEG existente e não vazio do serviço de back-end.

• O número total de instâncias ou pontos finais de back-end saudáveis tem de permanecer constante. Quando ocorre, pelo menos, um dos seguintes eventos, o número de instâncias ou pontos finais de back-end íntegros muda e a afinidade de sessão pode ser interrompida:

  • Qualquer instância ou ponto final passa na respetiva verificação de estado, passando de não saudável para saudável.
  • Qualquer instância ou ponto final falha na respetiva verificação de estado, passando de em bom estado para em mau estado ou tempo limite.

Failover

A comutação por falha para balanceadores de carga de rede de proxy externos funciona da seguinte forma:

• Se um back-end ficar em mau estado, o tráfego é automaticamente redirecionado para back-ends em bom estado na mesma região.

• Se todos os back-ends numa região estiverem em mau estado, o tráfego é distribuído para back-ends em bom estado noutras regiões (apenas nos modos global e clássico).

• Se todos os back-ends estiverem em mau estado, o equilibrador de carga rejeita o tráfego.

Balanceamento de carga para aplicações do GKE

Se estiver a criar aplicações no Google Kubernetes Engine, pode usar NEGs autónomos para equilibrar a carga do tráfego diretamente para contentores. Com os NEGs autónomos, é responsável por criar o objeto Service que cria o NEG e, em seguida, associar o NEG ao serviço de back-end para que o balanceador de carga possa estabelecer ligação aos pods.

Para ver documentação relacionada, consulte o artigo Balanceamento de carga nativa do contentor através de NEGs zonais autónomos.

Limitações

• Não pode criar um Network Load Balancer de proxy externo regional no nível Premium através da Google Cloud consola .Além disso, apenas as regiões que suportam o nível Standard estão disponíveis para estes balanceadores de carga na Google Cloud consola .Em alternativa, use a CLI gcloud ou a API.

• Google Cloud não oferece garantias sobre a duração das ligações TCP quando usa balanceadores de carga de rede de proxy externos. Os clientes devem ser resilientes a ligações interrompidas, tanto devido a problemas mais amplos da Internet como devido a reinícios agendados regularmente dos proxies que gerem as ligações.

• As seguintes limitações aplicam-se apenas aos balanceadores de carga de rede de proxy clássicos e ao balanceador de carga de rede de proxy externo global implementado com um proxy de destino SSL:

  • Os balanceadores de carga de rede de proxy clássicos e os balanceadores de carga de rede de proxy externos globais não suportam a autenticação baseada em certificados de cliente, também conhecida como autenticação TLS mútua.

  • Os equilibradores de carga de rede de proxy clássicos e os equilibradores de carga de rede de proxy externos globais suportam apenas carateres em minúsculas em domínios num atributo de nome comum (CN) ou num atributo de nome alternativo do assunto (SAN) do certificado. Os certificados com carateres maiúsculos nos domínios só são devolvidos quando definidos como o certificado principal no proxy de destino.

O que se segue?

• Configure um balanceador de carga de rede de proxy TCP clássico.
• Configure um balanceador de carga de rede de proxy clássico (proxy SSL).
• Configure um balanceador de carga de rede de proxy externo global (proxy TCP).
• Configure um balanceador de carga de rede de proxy externo global (proxy SSL).

• Configure um balanceador de carga de rede de proxy externo regional (proxy TCP).
• Registo e monitorização do Proxy Network Load Balancer.

• Usar políticas de SSL.

• Localizações do GFE.