Vista geral do balanceador de carga de aplicações interno

Este documento apresenta os conceitos que tem de compreender para configurar os balanceadores de carga de aplicações internos.

Um Google Cloud balanceador de carga de aplicações interno é um balanceador de carga da camada 7 baseado em proxy que lhe permite executar e dimensionar os seus serviços através de um único endereço IP interno. O balanceador de carga de aplicações interno distribui o tráfego HTTP e HTTPS para back-ends alojados numa variedade de plataformas, como o Compute Engine, o Google Kubernetes Engine (GKE) e o Cloud Run. Google Cloud Para ver detalhes, consulte a secção Exemplos de utilização.

Modos de funcionamento

Pode configurar um Application Load Balancer interno nos seguintes modos:

  • Balanceador de carga de aplicações interno entre regiões. Este é um equilibrador de carga multirregião que é implementado como um serviço gerido com base no proxy Envoy de código aberto. O modo entre regiões permite equilibrar a carga do tráfego para serviços de back-end distribuídos globalmente, incluindo a gestão de tráfego que ajuda a garantir que o tráfego é direcionado para o back-end mais próximo. Este balanceador de carga também permite a elevada disponibilidade. A colocação de back-ends em várias regiões ajuda a evitar falhas numa única região. Se os back-ends de uma região estiverem inativos, o tráfego pode ser transferido para outra região.

  • Balanceador de carga de aplicações interno regional. Este é um balanceador de carga regional que é implementado como um serviço gerido com base no proxy Envoy de código aberto. O modo regional requer que os back-ends estejam numa única Google Cloud região. Os clientes podem estar limitados a essa região ou podem estar em qualquer região, consoante o acesso global esteja desativado ou ativado na regra de encaminhamento. Este balanceador de carga está ativado com capacidades de controlo de tráfego avançadas baseadas em parâmetros HTTP ou HTTPS. Depois de configurar o balanceador de carga, este atribui automaticamente proxies Envoy para satisfazer as suas necessidades de tráfego.

    A tabela seguinte descreve as diferenças importantes entre os modos multirregiões e regionais:

    Modo do balanceador de carga Funcionalidade
    Endereço IP virtual (VIP) do balanceador de carga Acesso de cliente Back-ends com balanceamento de carga Alta disponibilidade e ativação pós-falha
    Balanceador de carga de aplicações interno entre regiões Atribuído a partir de uma sub-rede numa Google Cloud região específica.

    Os endereços VIP de várias regiões podem partilhar o mesmo serviço de back-end global. Pode configurar o equilíbrio de carga global baseado em DNS através de políticas de encaminhamento de DNS para encaminhar pedidos de clientes para o endereço VIP mais próximo.

    		 Sempre acessível a nível global. Os clientes de qualquer Google Cloud região numa VPC podem enviar tráfego para o balanceador de carga. Back-ends globais.
    O balanceador de carga pode enviar tráfego para back-ends em qualquer região.    		 Comutação automática para back-ends em bom estado nas mesmas regiões ou em regiões diferentes.
    Balanceador de carga de aplicações interno regional Atribuído a partir de uma sub-rede numa Google Cloud região específica. Não acessível globalmente por predefinição.
    Opcionalmente, pode ativar o acesso global.    		 Back-ends regionais.
    O balanceador de carga só pode enviar tráfego para back-ends que estejam na mesma região que o proxy do balanceador de carga.    		 Comutação automática por falha para back-ends em bom estado de funcionamento na mesma região.

Identifique o modo

Consola

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

    Aceda a Balanceamento de carga

  2. No separador Balanceadores de carga, pode ver o tipo de balanceador de carga, o protocolo e a região. Se a região estiver em branco, o balanceador de carga está no modo entre regiões. 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 aplicações interno entre regiões Aplicação Internos
    Balanceador de carga de aplicações interno regional Aplicação Internos Especifica uma região

gcloud

  1. Para determinar o modo de um equilibrador de carga, execute o seguinte comando:

    gcloud compute forwarding-rules describe FORWARDING_RULE_NAME

    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
    Balanceador de carga de aplicações interno entre regiões INTERNAL_MANAGED Global
    Balanceador de carga de aplicações interno regional INTERNAL_MANAGED Regional

Arquitetura e recursos

O diagrama seguinte mostra os Google Cloud recursos necessários para equilibradores de carga de aplicações internos:

Balanceador de carga de aplicações interno entre regiões

Este diagrama mostra os componentes de uma implementação do Application Load Balancer interno em várias regiões no Nível Premium na mesma rede VPC. Cada regra de encaminhamento global usa um endereço IP regional que os clientes usam para estabelecer ligação.

Componentes do balanceador de carga de aplicações interno entre regiões.
Componentes do balanceador de carga de aplicações interno entre regiões (clique para aumentar).

Balanceador de carga de aplicações interno regional

Este diagrama mostra os componentes de uma implementação do Application Load Balancer interno regional no nível Premium.

Componentes do balanceador de carga de aplicações interno regional.
Componentes do balanceador de carga da aplicação interno regional (clique para aumentar).

Os seguintes recursos são necessários para uma implementação do balanceador de carga da aplicação interno:

Sub-rede só de proxy

No diagrama anterior, a sub-rede apenas 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 de aplicações internos.

A tabela seguinte descreve as diferenças entre as sub-redes apenas de proxy nos modos regional e entre regiões. Os balanceadores de carga regionais e entre regiões não podem partilhar as mesmas sub-redes.

Modo do balanceador de carga Valor da flag --purpose da sub-rede só de proxy
Balanceador de carga de aplicações interno entre regiões

GLOBAL_MANAGED_PROXY

O equilibrador de carga baseado no Envoy entre regiões tem de ter uma sub-rede apenas de proxy em cada região na qual o equilibrador de carga está configurado. Os proxies do balanceador de carga entre regiões na mesma região e rede partilham a mesma sub-rede apenas de proxy.
Balanceador de carga de aplicações interno regional

REGIONAL_MANAGED_PROXY

Todos os balanceadores de carga baseados no Envoy numa região e na rede VPC partilham a mesma sub-rede só de proxy.

Além disso:

  • As sub-redes apenas de proxy são usadas apenas para proxies do Envoy e não para os seus back-ends.
  • As VMs ou os pontos finais de back-end de todos os equilibradores de carga de aplicações internos numa região e numa rede VPC recebem ligações da sub-rede apenas de proxy.
  • O endereço IP virtual de um Application Load Balancer interno não está localizado na sub-rede apenas de proxy. O endereço IP do balanceador de carga é definido pela respetiva regra de encaminhamento gerida interna, que é descrita abaixo.

Regra de encaminhamento e endereço IP

As regras de encaminhamento encaminham o tráfego por endereço IP, porta e protocolo para uma configuração de balanceamento 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 regional 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 atribua um por si. 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.

Os clientes usam o endereço IP e a porta para estabelecer ligação aos proxies Envoy do balanceador de carga. O endereço IP da regra de encaminhamento é o endereço IP do balanceador de carga (por vezes, denominado endereço IP virtual ou VIP). Os clientes que se ligam a um balanceador de carga têm de usar a versão 1.1 ou posterior do HTTP. Para ver a lista completa de protocolos suportados, consulte o artigo Comparação de funcionalidades do equilibrador de carga.

O endereço IP interno associado à regra de encaminhamento pode ser proveniente de uma sub-rede na mesma rede e região que os seus back-ends.

Especificação da porta. Cada regra de encaminhamento para um Application Load Balancer pode fazer referência a uma única porta de 1 a 65535. Para suportar várias portas, tem de configurar várias regras de encaminhamento. Pode configurar várias regras de encaminhamento para usar o mesmo endereço IP interno (VIP) e para referenciar o mesmo proxy HTTP ou HTTPS de destino, desde que a combinação geral de endereço IP, porta e protocolo seja exclusiva para cada regra de encaminhamento. Desta forma, pode usar um único equilibrador de carga com um mapa de URLs partilhado como um proxy para várias aplicações.

O tipo de regra de encaminhamento, endereço IP e esquema de balanceamento de carga usados pelos balanceadores de carga de aplicações internos dependem do modo do balanceador de carga.

Balanceador de carga de aplicações interno entre regiões
Regra de encaminhamento

Método globalForwardingRules.insert
Endereço IP regional

Método addresses.insert
Esquema de balanceamento de carga

INTERNAL_MANAGED
Endereço IP (opcional)

SHARED_LOADBALANCER_VIP
Encaminhamento do cliente para a interface do balanceador de carga

O acesso global está ativado por predefinição para permitir que os clientes de qualquer região numa VPC acedam ao seu equilibrador de carga. Os backends podem estar em várias regiões.
Balanceador de carga de aplicações interno regional
Regra de encaminhamento

Método forwardingRules.insert
Endereço IP regional

Método addresses.insert
Esquema de balanceamento de carga

INTERNAL_MANAGED
Endereço IP (opcional)

SHARED_LOADBALANCER_VIP
Encaminhamento do cliente para a interface do balanceador de carga

Pode ativar o acesso global para permitir que os clientes de qualquer região numa VPC acedam ao seu equilibrador de carga. Os back-ends também têm de estar 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 pelos equilibradores de carga de aplicações internos estão associadas a redes VPC.

Modo do balanceador de carga Associação da rede da VPC
Balanceador de carga de aplicações interno entre regiões

Balanceador de carga de aplicações interno regional

Os endereços IPv4 internos regionais existem sempre em redes VPC. Quando cria a regra de encaminhamento, tem de especificar a sub-rede a partir da qual o endereço IP interno é retirado. Esta sub-rede tem de estar na mesma região e na rede VPC onde foi criada uma sub-rede apenas de proxy. Assim, existe uma associação de rede implícita.

Proxy de destino

Um proxy HTTP ou HTTPS de destino termina as ligações HTTP(S) dos clientes. O proxy HTTP(S) consulta o mapa de URLs para determinar como encaminhar o tráfego para os servidores de back-end. Um proxy HTTPS de destino usa um certificado SSL para se autenticar junto dos clientes.

O balanceador de carga preserva o cabeçalho Host do pedido do cliente original. O balanceador de carga também anexa dois endereços IP ao cabeçalho X-Forwarded-For:

  • O endereço IP do cliente que se liga ao equilibrador de carga
  • O endereço IP da regra de encaminhamento do balanceador de carga

Se não existir um cabeçalho X-Forwarded-For no pedido recebido, estes dois endereços IP são o valor total do cabeçalho. Se o pedido tiver um cabeçalho X-Forwarded-For, outras informações, como os endereços IP registados por proxies no caminho para o equilibrador de carga, são preservadas antes dos dois endereços IP. O balanceador de carga não valida nenhum endereço IP que preceda os dois últimos endereços IP neste cabeçalho.

Se estiver a executar um proxy como servidor de back-end, este proxy normalmente anexa mais informações ao cabeçalho X-Forwarded-For, e o seu software pode ter de ter isso em conta. Os pedidos enviados através de proxy do balanceador de carga são provenientes de um endereço IP na sub-rede só de proxy, e o seu proxy na instância de back-end pode registar este endereço, bem como o endereço IP da própria instância de back-end.

Consoante o tipo de tráfego que a sua aplicação tem de processar, pode configurar um equilibrador de carga com um proxy HTTP de destino ou um proxy HTTPS de destino.

A tabela seguinte mostra as APIs de proxy de destino necessárias pelos equilibradores de carga de aplicações internos:

Modo do balanceador de carga Proxy de destino
Balanceador de carga de aplicações interno entre regiões
Balanceador de carga de aplicações interno regional

Certificados SSL

Os balanceadores de carga de aplicações internos que usam proxies HTTPS de destino requerem chaves privadas e certificados SSL como parte da configuração do balanceador de carga.

A tabela seguinte especifica o tipo de certificados SSL necessários pelos equilibradores de carga de aplicações internos em cada modo:

Modo do balanceador de carga Tipo de certificado SSL
Balanceador de carga de aplicações interno entre regiões

Gestor de certificados certificados autogeridos e certificados geridos pela Google.

Os seguintes tipos de certificados geridos pela Google são suportados com o Gestor de certificados:

Os certificados geridos pela Google com autorização do equilibrador de carga não são suportados.

Os certificados SSL do Compute Engine não são suportados.
Balanceador de carga de aplicações interno regional

Certificados SSL regionais do Compute Engine

Gestor de certificados certificados autogeridos regionais e certificados geridos pela Google.

Os seguintes tipos de certificados geridos pela Google são suportados com o Gestor de certificados:

Os certificados geridos pela Google com autorização do equilibrador de carga não são suportados.

Mapas de URLs

O proxy HTTP(S) de destino usa mapas de URLs para tomar uma decisão de encaminhamento com base em atributos HTTP (como o caminho do pedido, cookies ou cabeçalhos). Com base na decisão de encaminhamento, o proxy encaminha os pedidos do cliente para serviços de back-end específicos. O mapa de URLs pode especificar ações adicionais a realizar, como reescrever cabeçalhos, enviar redirecionamentos para clientes e configurar políticas de limite de tempo (entre outras).

A tabela seguinte especifica o tipo de mapa de URLs exigido pelos balanceadores de carga de aplicações internos em cada modo:

Modo do balanceador de carga Tipo de mapa de URL
Balanceador de carga de aplicações interno entre regiões urlMaps
Balanceador de carga de aplicações interno regional regionUrlMaps

Serviço de back-end

Um serviço de back-end fornece informações de configuração ao equilibrador de carga para que possa direcionar pedidos para os respetivos back-ends, por exemplo, grupos de instâncias do Compute Engine ou grupos de pontos finais de rede (NEGs). Para mais informações sobre os serviços de back-end, consulte a vista geral dos serviços de back-end.

Âmbito do serviço de back-end

A tabela seguinte indica o recurso e o âmbito do serviço de back-end usados pelos balanceadores de carga de aplicações internos:

Modo do balanceador de carga Recurso de serviço de back-end
Balanceador de carga de aplicações interno entre regiões backendServices
Balanceador de carga de aplicações interno regional regionBackendServices

Protocolo para os back-ends

Os serviços de back-end para balanceadores de carga de aplicações têm de usar um dos seguintes protocolos para enviar pedidos para back-ends:

  • HTTP, que usa HTTP/1.1 e não usa TLS
  • HTTPS, que usa HTTP/1.1 e TLS
  • HTTP/2, que usa HTTP/2 e TLS (o HTTP/2 sem encriptação não é suportado).
  • H2C, que usa HTTP/2 sobre TCP. O TLS não é obrigatório. O H2C não é suportado para balanceadores de carga de aplicações clássicos.

O balanceador de carga usa apenas o protocolo de serviço de back-end que especificar para comunicar com os respetivos back-ends. O balanceador de carga não recorre a um protocolo diferente se não conseguir comunicar com os back-ends através do protocolo de serviço de back-end especificado.

O protocolo do serviço de back-end não tem de corresponder ao protocolo usado pelos clientes para comunicar com o balanceador de carga. Por exemplo, os clientes podem enviar pedidos ao balanceador de carga através de HTTP/2, mas o balanceador de carga pode comunicar com os back-ends através de HTTP/1.1 (HTTP ou HTTPS).

Back-ends

A tabela seguinte especifica as funcionalidades de back-end suportadas pelos equilibradores de carga de aplicações internos em cada modo.


Modo do balanceador de carga 		Back-ends suportados num serviço de back-end1 Suporta contentores de back-end Suporta o Cloud Armor Suporta o Cloud CDN Suporta CNA Suporta extensões de serviços
Grupos de instâncias2 NEGs zonais3 NEGs da Internet NEGs sem servidor NEGs híbridos NEGs do Private Service Connect
Balanceador de carga de aplicações interno entre regiões
Cloud Run
Balanceador de carga de aplicações interno regional
Cloud Run

1 Os back-ends num serviço de back-end têm de ser do mesmo tipo: todos os grupos de instâncias ou todos do mesmo tipo de NEG. Uma exceção a esta regra é que os NEGs zonais e os NEGs híbridos podem ser usados no mesmo serviço de back-end para suportar uma arquitetura híbrida.GCE_VM_IP_PORT

2 As combinações de grupos de instâncias geridos zonais, não geridos zonais e regionais são suportadas no mesmo serviço de back-end. Quando usar o dimensionamento automático para um grupo de instâncias gerido que seja um back-end para dois ou mais serviços de back-end, configure a política de dimensionamento automático do grupo de instâncias para usar vários sinais.

Os NEGs zonais 3 têm de usar pontos finais GCE_VM_IP_PORT.

Back-ends e redes VPC

As restrições sobre a localização dos back-ends dependem do tipo de back-end.

  • 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.

Subconjunto de back-end

A divisão em subconjuntos no back-end é uma funcionalidade opcional suportada pelos equilibradores de carga de aplicações internos regionais que melhora o desempenho e a escalabilidade ao atribuir um subconjunto de back-ends a cada uma das instâncias de proxy.

Por predefinição, a restrição de subconjuntos de back-end está desativada. Para ver informações sobre como ativar esta funcionalidade, consulte o artigo Subconjunto de back-end para balanceadores de carga de aplicações internos regionais.

Verificações de funcionamento

Cada serviço de back-end especifica uma verificação de estado que monitoriza periodicamente a disponibilidade dos back-ends para receber uma ligação do equilibrador de carga. Isto reduz o risco de os pedidos serem enviados para back-ends que não podem processar o pedido. As verificações de estado não verificam se a própria aplicação está a funcionar.

Para que as sondas de verificação de funcionamento sejam bem-sucedidas, tem de criar uma regra de firewall de permissão de entrada que permita que as sondas de verificação de funcionamento alcancem as instâncias de back-end. Normalmente, as sondas de verificação de funcionamento têm origem no mecanismo de verificação de funcionamento centralizado da Google. No entanto, para NEGs híbridos, as verificações de funcionamento têm origem na sub-rede apenas de proxy. Para obter detalhes, consulte o artigo Verificações de estado do Envoy distribuído.

Protocolo de verificação de funcionamento

Embora não seja obrigatório e nem sempre seja possível, é uma prática recomendada usar uma verificação de estado cujo protocolo corresponda ao protocolo do serviço de back-end. Por exemplo, uma verificação de funcionamento de HTTP/2 testa com maior precisão a conetividade HTTP/2 aos back-ends. Por outro lado, os balanceadores de carga de aplicações internos que usam back-ends de NEG híbridos não suportam verificações de funcionamento de gRPC. Para ver a lista de protocolos de verificação de funcionamento suportados, consulte as funcionalidades de balanceamento de carga na secção Verificações de funcionamento.

A tabela seguinte especifica o âmbito das verificações de funcionamento suportadas pelos balanceadores de carga de aplicações internos:

Modo do balanceador de carga Tipo de verificação de funcionamento
Balanceador de carga de aplicações interno entre regiões healthChecks
Balanceador de carga de aplicações interno regional regionHealthChecks

Para mais informações sobre as verificações de funcionamento, consulte o seguinte:

Regras de firewall

Um Application Load Balancer interno requer as seguintes regras de firewall:

  • Uma regra de permissão de entrada que permite o tráfego dos intervalos de verificação de estado centrais da Google. Para mais informações sobre os intervalos de endereços IP de sondagem de verificação de estado específicos e o motivo pelo qual é necessário permitir o tráfego proveniente dos mesmos, consulte o artigo Intervalos de IP de sondagem e regras de firewall.
  • Uma regra de permissão de entrada que permite o tráfego da sub-rede só de proxy.

Existem determinadas exceções aos requisitos das regras de firewall para estes intervalos:

  • Não é necessário permitir tráfego dos intervalos de sondas 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 estado 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.

Acesso de cliente

Os clientes podem estar na mesma rede ou numa rede VPC ligada através do intercâmbio da rede da VPC.

Para balanceadores de carga de aplicações internos entre regiões, o acesso global está ativado por predefinição. Os clientes de qualquer região numa VPC podem aceder ao seu balanceador de carga.

Para equilibradores de carga de aplicações internos regionais, os clientes têm de estar na mesma região que o equilibrador de carga por predefinição. Pode ativar o acesso global para permitir que os clientes de qualquer região numa VPC acedam ao seu equilibrador de carga.

A tabela seguinte resume o acesso do cliente para balanceadores de carga de aplicações internos regionais:

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

Apoio técnico do GKE

O GKE usa balanceadores de carga de aplicações internos das seguintes formas:

  • Os gateways internos criados com o controlador GKE Gateway podem usar qualquer modo de um equilibrador de carga de aplicações interno. Controla o modo do balanceador de carga escolhendo uma GatewayClass. O controlador do GKE Gateway usa sempre back-ends de GCE_VM_IP_PORTNEG zonaisGCE_VM_IP_PORT.

  • Os Ingresses internos criados com o controlador GKE Ingress são sempre balanceadores de carga de aplicações internos regionais. O controlador de entrada do GKE usa sempre back-ends de NEG zonais GCE_VM_IP_PORT.

Arquiteturas de VPC partilhada

Os balanceadores de carga de aplicações internos suportam redes que usam a VPC partilhada. A VPC partilhada permite que as organizações liguem recursos de vários projetos a uma rede VPC comum para que possam comunicar entre si de forma segura e eficiente através de IPs internos dessa rede. Se ainda não conhece a VPC partilhada, leia a documentação de vista geral da VPC partilhada.

Existem muitas formas de configurar um balanceador de carga de aplicações interno numa rede VPC partilhada. Independentemente do tipo de implementação, todos os componentes do equilibrador de carga têm de estar na mesma organização.

Sub-redes e endereço IP Componentes da interface Componentes de back-end

Crie a rede e as sub-redes necessárias (incluindo a sub-rede apenas de proxy) no projeto anfitrião da VPC partilhada.

O endereço IP interno do balanceador de carga pode ser definido no projeto anfitrião ou num projeto de serviço, mas tem de usar uma sub-rede na rede de VPC partilhada pretendida no projeto anfitrião. A própria morada é proveniente do intervalo de IP principal da sub-rede referenciada.

 O endereço IP interno regional, a regra de encaminhamento, o proxy HTTP(S) de destino e o mapa de URLs associado têm de ser definidos no mesmo projeto. Este projeto pode ser o projeto anfitrião ou um projeto de serviço. Pode efetuar uma das seguintes ações:
  • Crie serviços de back-end e back-ends (grupos de instâncias, NEGs sem servidor ou quaisquer outros tipos de back-end suportados) no mesmo projeto de serviço que os componentes de front-end.
  • Crie serviços de back-end e back-ends (grupos de instâncias, NEGs sem servidor ou quaisquer outros tipos de back-end suportados) em tantos projetos de serviço quanto necessário. Um único mapa de URLs pode fazer referência a serviços de back-end em diferentes projetos. Este tipo de implementação é conhecido como referência de serviços entre projetos.

Cada serviço de back-end tem de ser definido no mesmo projeto que os back-ends aos quais faz referência. As verificações de estado de funcionamento associadas aos serviços de back-end também têm de ser definidas no mesmo projeto que o serviço de back-end.

Embora possa criar todos os componentes de equilíbrio de carga e back-ends no projeto anfitrião da VPC partilhada, este tipo de implementação não separa as responsabilidades de administração de rede e desenvolvimento de serviços.

Todos os componentes do balanceador de carga e back-ends num projeto de serviço

O diagrama de arquitetura seguinte mostra uma implementação padrão de VPC partilhada em que todos os componentes do equilibrador de carga e os back-ends estão num projeto de serviço. Este tipo de implementação é suportado por todos os equilibradores de carga de aplicações.

O balanceador de carga usa endereços IP e sub-redes do projeto anfitrião. Os clientes podem aceder a um balanceador de carga de aplicações interno se estiverem na mesma rede e região da VPC partilhada que o balanceador de carga. Os clientes podem estar localizados no projeto anfitrião, num projeto de serviço associado ou em quaisquer redes ligadas.

Balanceador de carga de aplicações interno na rede de VPC partilhada.
Balanceador de carga de aplicações interno na rede VPC partilhada (clique para aumentar).

Back-ends sem servidor num ambiente de VPC partilhada

Para um Application Load Balancer interno que esteja a usar um back-end do NEG sem servidor, o serviço do Cloud Run de apoio tem de estar no mesmo projeto de serviço que o serviço de back-end e o NEG sem servidor. Os componentes de front-end do equilibrador de carga (regra de encaminhamento, proxy de destino, mapa de URLs) podem ser criados no projeto anfitrião, no mesmo projeto de serviço que os componentes de back-end ou em qualquer outro projeto de serviço no mesmo ambiente de VPC partilhada.

Referência de serviços entre projetos

A referência de serviços entre projetos é um modelo de implementação em que o front-end e o mapa de URLs do balanceador de carga estão num projeto, e o serviço de back-end e os back-ends do balanceador de carga estão num projeto diferente.

A referência de serviços entre projetos permite que as organizações configurem um balanceador de carga central e encaminhem o tráfego para centenas de serviços distribuídos por vários projetos diferentes. Pode gerir centralmente todas as regras de encaminhamento de tráfego e políticas num único mapa de URLs. Também pode associar o equilibrador de carga a um único conjunto de nomes de anfitriões e certificados SSL. Por conseguinte, pode otimizar o número de equilibradores de carga necessários para implementar a sua aplicação e reduzir a capacidade de gestão, os custos operacionais e os requisitos de quota.

Ao ter projetos diferentes para cada uma das suas equipas funcionais, também pode alcançar a separação de funções na sua organização. Os proprietários de serviços podem concentrar-se na criação de serviços em projetos de serviços, enquanto as equipas de rede podem aprovisionar e manter equilibradores de carga noutro projeto. Ambos podem ser ligados através da referência de serviços entre projetos.

Os proprietários de serviços podem manter a autonomia sobre a exposição dos respetivos serviços e controlar os utilizadores que podem aceder aos respetivos serviços através do balanceador de carga. Isto é conseguido através de uma função IAM especial denominada função de utilizador dos serviços do balanceador de carga do Compute (roles/compute.loadBalancerServiceUser).

Para equilibradores de carga de aplicações internos, a referência de serviços entre projetos só é suportada em ambientes de VPC partilhada.

Para saber como configurar a VPC partilhada para um balanceador de carga de aplicações interno, com e sem referências de serviços entre projetos, consulte o artigo Configure um balanceador de carga de aplicações interno com a VPC partilhada.

Notas de utilização para referências de serviços entre projetos

  • Não pode fazer referência a um serviço de back-end entre projetos se o serviço de back-end tiver back-ends de NEG de Internet regionais. Todos os outros tipos de back-end são compatíveis.
  • Google Cloud não faz a distinção entre recursos (por exemplo, serviços de back-end) que usam o mesmo nome em vários projetos. Por conseguinte, quando usar referências de serviços entre projetos, recomendamos que use nomes de serviços de back-end exclusivos entre projetos na sua organização.

Exemplo 1: front-end e back-end do balanceador de carga em diferentes projetos de serviço

Segue-se um exemplo de uma implementação de VPC partilhada em que o front-end e o mapa de URLs do equilibrador de carga são criados no projeto de serviço A, e o mapa de URLs faz referência a um serviço de back-end no projeto de serviço B.

Neste caso, os administradores de rede ou os administradores do balanceador de carga no projeto de serviço A precisam de acesso aos serviços de back-end no projeto de serviço B. Os administradores do projeto de serviço B concedem a função de utilizador dos serviços de equilibrador de carga de computação (roles/compute.loadBalancerServiceUser) aos administradores do equilibrador de carga no projeto de serviço A que querem fazer referência ao serviço de back-end no projeto de serviço B.

Interface e mapa de URLs do balanceador de carga no projeto de serviço.
Front-end e back-end do balanceador de carga em diferentes projetos de serviço (clique para aumentar).

Exemplo 2: front-end do equilibrador de carga no projeto anfitrião e back-ends em projetos de serviço

Segue-se um exemplo de uma implementação de VPC partilhada em que o front-end e o mapa de URLs do equilibrador de carga são criados no projeto anfitrião, e os serviços de back-end (e os back-ends) são criados em projetos de serviço.

Neste caso, os administradores de rede ou os administradores do equilibrador de carga no projeto anfitrião precisam de acesso aos serviços de back-end no projeto de serviço. Os administradores do projeto de serviço concedem a função de utilizador dos serviços de equilibrador de carga de computação (roles/compute.loadBalancerServiceUser) aos administradores do equilibrador de carga no projeto anfitrião A que querem fazer referência ao serviço de back-end no projeto de serviço.

Interface de balanceamento de carga e mapa de URLs no projeto anfitrião.
Front-end do balanceador de carga e mapa de URLs no projeto anfitrião (clique para aumentar).

Limites de tempo e novas tentativas

Os balanceadores de carga de aplicações internos suportam os seguintes tipos de limites de tempo:

Tipo de limite de tempo e descrição Valores predefinidos Suporta valores personalizados
Entre regiões Regional
Limite de tempo do serviço de back-end

Um limite de tempo do pedido e da resposta. Representa o tempo máximo permitido entre o balanceador de carga enviar o primeiro byte de um pedido para o back-end e o back-end devolver o último byte da resposta HTTP ao balanceador de carga. Se o back-end não tiver devolvido a resposta HTTP completa ao equilibrador de carga dentro deste limite de tempo, os dados de resposta restantes são ignorados.
  • Para NEGs sem servidor num serviço de back-end: 60 minutos
  • Para todos os outros tipos de back-end num serviço de back-end: 30 segundos
Limite de tempo de manutenção ativa do HTTP do cliente

O período máximo durante o qual a ligação TCP entre um cliente e o proxy Envoy gerido do balanceador de carga pode ficar inativa. (A mesma ligação TCP pode ser usada para vários pedidos HTTP.)

 610 segundos
Tempo limite de manutenção ativa do HTTP de back-end

O tempo máximo que a ligação TCP entre o proxy Envoy gerido do equilibrador de carga e um back-end pode ficar inativa. (A mesma ligação TCP pode ser usada para vários pedidos HTTP.)

 10 minutos (600 segundos)

Limite de tempo do serviço de back-end

O tempo limite do serviço de back-end configurável representa o tempo máximo que o balanceador de carga aguarda que o back-end processe um pedido HTTP e devolva a resposta HTTP correspondente. Exceto para NEGs sem servidor, o valor predefinido para o limite de tempo do serviço de back-end é de 30 segundos.

Por exemplo, se quiser transferir um ficheiro de 500 MB e o valor do limite de tempo do serviço de back-end for de 90 segundos, o equilibrador de carga espera que o back-end forneça o ficheiro completo de 500 MB no prazo de 90 segundos. É possível configurar o tempo limite do serviço de back-end para que seja insuficiente para o back-end enviar a respetiva resposta HTTP completa. Nesta situação, se o balanceador de carga tiver recebido, pelo menos, cabeçalhos de resposta HTTP do back-end, o balanceador de carga devolve os cabeçalhos de resposta completos e a maior parte do corpo da resposta que conseguiu obter dentro do tempo limite do serviço de back-end.

Recomendamos que defina o limite de tempo do serviço de back-end para o período mais longo que espera que o back-end precise para processar uma resposta HTTP. Se o software em execução no seu back-end precisar de mais tempo para processar um pedido HTTP e devolver a resposta completa, recomendamos que aumente o limite de tempo do serviço de back-end.

O limite de tempo do serviço de back-end aceita valores entre 1 e 2,147,483,647 segundos. No entanto, os valores mais elevados não são opções de configuração práticas. Além disso,Google Cloud não garante que uma ligação TCP subjacente possa permanecer aberta durante todo o valor do limite de tempo do serviço de back-end. Os sistemas cliente têm de implementar uma lógica de repetição em vez de dependerem de uma ligação TCP para estarem abertos durante longos períodos.

Para ligações de websocket usadas com balanceadores de carga de aplicações internos, as ligações de websocket ativas não seguem o limite de tempo do serviço de back-end. As ligações WebSocket inativas são fechadas após o limite de tempo do serviço de back-end.

Google Cloud reinicia periodicamente ou altera o número de tarefas de software do Envoy de publicação. Quanto maior for o valor de tempo limite do serviço de back-end, maior é a probabilidade de os reinícios ou as substituições de tarefas do Envoy terminarem as ligações TCP.

Para configurar o limite de tempo do serviço de back-end, use um dos seguintes métodos:

Consola

Modifique o campo Timeout do serviço de back-end do balanceador de carga.

gcloud

Use o comando gcloud compute backend-services update para modificar o parâmetro --timeout do recurso backend service.

API

Modifique o parâmetro timeoutSec para o recurso regionBackendServices

Tempo limite de keep-alive de HTTP do cliente

O tempo limite de manutenção HTTP do cliente representa o período máximo durante o qual uma ligação TCP pode estar inativa entre o cliente (a jusante) e um proxy Envoy. O valor de tempo limite de manutenção ativa HTTP do cliente predefinido é de 610 segundos. Pode configurar o limite de tempo com um valor entre 5 e 1200 segundos.

Um limite de tempo de manutenção ativa de HTTP também é denominado limite de tempo de inatividade de TCP.

O limite de tempo limite de manutenção ativa do HTTP do cliente do equilibrador de carga tem de ser superior ao limite de tempo limite de manutenção ativa do HTTP (inativo do TCP) usado por clientes ou proxies a jusante. Se um cliente a jusante tiver um limite de tempo limite de manutenção ativo de HTTP (TCP inativo) superior ao limite de tempo limite de manutenção ativo de HTTP do cliente do balanceador de carga, é possível que ocorra uma condição de corrida. Do ponto de vista de um cliente a jusante, é permitido que uma ligação TCP estabelecida fique inativa durante mais tempo do que o permitido pelo equilibrador de carga. Isto significa que o cliente a jusante pode enviar pacotes depois de o equilibrador de carga considerar a ligação TCP fechada. Quando isso acontece, o balanceador de carga responde com um pacote de reposição de TCP (RST).

Quando o limite de tempo limite de manutenção HTTP do cliente expira, o GFE ou o proxy Envoy envia um TCP FIN ao cliente para fechar corretamente a ligação.

Limite de tempo de manutenção ativa de HTTP do back-end

Os equilibradores de carga de aplicações internos são proxies que usam uma primeira ligação TCP entre o cliente (a jusante) e um proxy Envoy, e uma segunda ligação TCP entre o proxy Envoy e os seus back-ends.

As ligações TCP secundárias do equilibrador de carga podem não ser fechadas após cada pedido. Podem permanecer abertas para processar vários pedidos e respostas HTTP. O tempo limite de manutenção ativa de HTTP do back-end define o tempo limite de inatividade de TCP entre o balanceador de carga e os seus back-ends. O limite de tempo limite de manutenção ativo HTTP do back-end não se aplica a websockets.

O limite de tempo limite de manutenção ativo do back-end é fixo em 10 minutos (600 segundos) e não pode ser alterado. Isto ajuda a garantir que o balanceador de carga mantém as ligações inativas durante, pelo menos, 10 minutos. Após este período, o balanceador de carga pode enviar pacotes de terminação para o back-end em qualquer altura.

O limite de tempo limite de manutenção ativo do back-end do equilibrador de carga tem de ser inferior ao limite de tempo limite de manutenção ativo usado pelo software em execução nos seus back-ends. Isto evita uma condição de corrida em que o sistema operativo dos seus back-ends pode fechar as ligações TCP com uma reposição de TCP (RST). Uma vez que o tempo limite de manutenção ativo do back-end para o equilibrador de carga não é configurável, tem de configurar o software de back-end para que o respetivo valor de tempo limite de manutenção ativo de HTTP (inativo de TCP) seja superior a 600 segundos.

Quando o limite de tempo de manutenção ativo do HTTP de back-end expira, o GFE ou o proxy do Envoy envia um TCP FIN para a VM de back-end para fechar corretamente a ligação.

A tabela seguinte apresenta as alterações necessárias para modificar os valores de tempo limite de manutenção ativa para software de servidor Web comum.

Software de servidor Web Parâmetro Predefinição Definição recomendada
Apache KeepAliveTimeout KeepAliveTimeout 5 KeepAliveTimeout 620
nginx keepalive_timeout keepalive_timeout 75s; keepalive_timeout 620s;

Novas tentativas

Para configurar novas tentativas, pode usar uma política de novas tentativas no mapa de URLs. O número predefinido de tentativas (numRetries) é 1. O perTryTimeout máximo configurável é de 24 horas.

Sem uma política de repetição, as solicitações sem êxito que não têm um corpo HTTP (por exemplo, solicitações GET) que resultam em respostas HTTP 502, 503 ou 504 são repetidas uma vez.

Não são repetidos pedidos HTTP POST.

As solicitações repetidas só geram uma entrada de registo para a resposta final.

Para mais informações, consulte o artigo Registo e monitorização do balanceador de carga de aplicações interno.

Aceder a redes ligadas

Os seus clientes podem aceder a um Application Load Balancer interno na sua rede VPC a partir de uma rede ligada através do seguinte:

  • Intercâmbio de redes da VPC
  • Cloud VPN e Cloud Interconnect

Para ver exemplos detalhados, consulte o artigo Equilibradores de carga de aplicações internos e redes ligadas.

Afinidade de sessão

A afinidade de sessão, configurada no serviço de back-end dos equilibradores de carga de aplicações, faz uma tentativa de melhor esforço para enviar pedidos de um cliente específico para o mesmo back-end, desde que o número de instâncias ou pontos finais de back-end em bom estado permaneça constante e que a instância ou o ponto final de back-end selecionado anteriormente não esteja no limite da capacidade. A capacidade alvo do modo de equilíbrio determina quando o back-end está na capacidade máxima.

A tabela seguinte descreve os diferentes tipos de opções de afinidade de sessão suportados para os diferentes equilibradores de carga de aplicações. Na secção que se segue, Tipos de afinidade de sessão, cada tipo de afinidade de sessão é abordado mais detalhadamente.

Tabela: definições de afinidade de sessão suportadas
Produto Opções de afinidade de sessão
  • Nenhum (NONE)
  • IP do cliente (CLIENT_IP)
  • Cookie gerado (GENERATED_COOKIE)
  • Campo de cabeçalho (HEADER_FIELD)
  • Cookie HTTP (HTTP_COOKIE)
  • Afinidade baseada em cookies com estado (STRONG_COOKIE_AFFINITY)

Tenha também em atenção:

  • O valor predefinido eficaz da política de localidade de equilíbrio de carga (localityLbPolicy) muda de acordo com as definições de afinidade de sessão. Se a afinidade de sessão não estiver configurada, ou seja, se a afinidade de sessão permanecer no valor predefinido de NONE, o valor predefinido para localityLbPolicy é ROUND_ROBIN. Se a afinidade da sessão estiver definida para um valor diferente de NONE, o valor predefinido de localityLbPolicy é MAGLEV.
  • Para o Application Load Balancer interno, não configure a afinidade de sessão se estiver a usar a divisão de tráfego ponderada. Se o fizer, a configuração de divisão de tráfego ponderada tem precedência.

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, exceto a afinidade de sessão baseada em cookies com estado, pode ser interrompida sempre que o número de back-ends de serviço e em bom estado for alterado. 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.

Tipos de afinidade de sessão

A afinidade de sessão para balanceadores de carga de aplicações internos pode ser classificada numa das seguintes categorias:
  • Afinidade de sessão baseada em hash (NONE e CLIENT_IP)
  • Afinidade de sessão baseada em cabeçalhos HTTP (HEADER_FIELD)
  • Afinidade de sessão baseada em cookies (GENERATED_COOKIE, HTTP_COOKIE e STRONG_COOKIE_AFFINITY)

Afinidade de sessão baseada em hash

Para a afinidade de sessão baseada em hash, o balanceador de carga usa o algoritmo de hash consistente para selecionar um back-end elegível. A definição de afinidade de sessão determina os campos do cabeçalho IP que são usados para calcular o hash.

A afinidade de sessão baseada em hash pode ser dos seguintes tipos:

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.

Afinidade de sessão baseada em cabeçalhos HTTP

Com a afinidade do campo de cabeçalho (HEADER_FIELD), os pedidos são encaminhados para os back-ends com base no valor do cabeçalho HTTP no campo consistentHash.httpHeaderName do serviço de back-end. Para distribuir pedidos por todos os back-ends disponíveis, cada cliente tem de usar um valor de cabeçalho HTTP diferente.

A afinidade do campo de cabeçalho é suportada quando as seguintes condições são verdadeiras:

  • A política de localidade de balanceamento de carga é RING_HASH ou MAGLEV.
  • O elemento consistentHash do serviço de back-end especifica o nome do cabeçalho HTTP (httpHeaderName).

A afinidade de sessão baseada em cookies pode ser dos seguintes tipos:

Quando usa a afinidade baseada em cookies gerados (GENERATED_COOKIE), o balanceador de carga inclui um cookie HTTP no cabeçalho Set-Cookie em resposta ao pedido HTTP inicial.

O nome do cookie gerado varia consoante o tipo de equilibrador de carga.

Produto Nome do cookie
Balanceadores de carga de aplicações internos entre regiões GCILB
Balanceadores de carga de aplicações internos regionais GCILB

O atributo de caminho do cookie gerado é sempre uma barra (/), pelo que se aplica a todos os serviços de back-end no mesmo mapa de URLs, desde que os outros serviços de back-end também usem a afinidade de cookie gerado.

Pode configurar o valor do tempo de vida (TTL) do cookie entre 0 e 1,209,600 segundos (inclusive) através do parâmetro do serviço de back-end affinityCookieTtlSec. Se affinityCookieTtlSec não for especificado, o valor TTL predefinido é 0.

Quando o cliente inclui o cookie de afinidade de sessão gerado no cabeçalho do pedido de pedidos HTTP, o equilibrador de carga direciona esses pedidos para a mesma instância ou ponto final de back-end, desde que o cookie de afinidade de sessão permaneça válido.Cookie Isto é feito através do mapeamento do valor do cookie para um índice que faz referência a uma instância específica do back-end ou a um ponto final, e garantindo que os requisitos de afinidade de sessão de cookies gerados são cumpridos.

Para usar a afinidade de cookies gerada, configure o seguinte modo de equilíbrio de carga e definições localityLbPolicy:

  • Para grupos de instâncias de back-end, use o RATEmodo de balanceamento.
  • Para o localityLbPolicy do serviço de back-end, use RING_HASH ou MAGLEV. Se não definir explicitamente o localityLbPolicy, o balanceador de carga usa MAGLEV como predefinição implícita.

Para mais informações, consulte o artigo sobre perder a afinidade da sessão.

Quando usa a afinidade baseada em cookies HTTP (HTTP_COOKIE), o balanceador de carga inclui um cookie HTTP no cabeçalho Set-Cookie em resposta ao pedido HTTP inicial. Especifica o nome, o caminho e o tempo de vida (TTL) do cookie.

Todos os balanceadores de carga de aplicações suportam a afinidade baseada em cookies HTTP.

Pode configurar os valores de TTL do cookie através de segundos, frações de segundo (como nanosegundos) ou ambos, segundos mais frações de segundo (como nanosegundos), usando os seguintes parâmetros do serviço de back-end e valores válidos:

  • consistentHash.httpCookie.ttl.seconds pode ser definido para um valor entre 0 e 315576000000 (inclusive).
  • consistentHash.httpCookie.ttl.nanos pode ser definido para um valor entre 0 e 999999999 (inclusive). Uma vez que as unidades são nanosegundos, 999999999 significa .999999999 segundos.

Se consistentHash.httpCookie.ttl.seconds e consistentHash.httpCookie.ttl.nanos não forem especificados, é usado o valor do parâmetro do serviço de back-end affinityCookieTtlSec. Se affinityCookieTtlSec não for especificado, o valor TTL predefinido é 0.

Quando o cliente inclui o cookie de afinidade de sessão HTTP no cabeçalho do pedido de pedidos HTTP, o balanceador de carga direciona esses pedidos para a mesma instância ou ponto final de back-end, desde que o cookie de afinidade de sessão permaneça válido.Cookie Isto é feito através do mapeamento do valor do cookie para um índice que faz referência a uma instância específica do back-end ou a um ponto final, e garantindo que os requisitos de afinidade de sessão de cookies gerados são cumpridos.

Para usar a afinidade de cookies HTTP, configure o seguinte modo de equilíbrio de carga e definições localityLbPolicy:

  • Para grupos de instâncias de back-end, use o RATEmodo de balanceamento.
  • Para o localityLbPolicy do serviço de back-end, use RING_HASH ou MAGLEV. Se não definir explicitamente o localityLbPolicy, o balanceador de carga usa MAGLEV como predefinição implícita.

Para mais informações, consulte o artigo sobre perder a afinidade da sessão.

Afinidade de sessão baseada em cookies com estado

Quando usa a afinidade baseada em cookies com estado (STRONG_COOKIE_AFFINITY), o balanceador de carga inclui um cookie HTTP no cabeçalho Set-Cookie em resposta ao pedido HTTP inicial. Especifica o nome, o caminho e o tempo de vida (TTL) do cookie.

Todos os balanceadores de carga de aplicações, exceto os balanceadores de carga de aplicações clássicos, suportam a afinidade baseada em cookies com estado.

Pode configurar os valores de TTL do cookie usando segundos, frações de segundo (como nanosegundos) ou ambos os segundos mais frações de segundo (como nanosegundos). A duração representada por strongSessionAffinityCookie.ttl não pode ser definida para um valor que represente mais de duas semanas (1 209 600 segundos).

O valor do cookie identifica uma instância ou um ponto final de back-end selecionado através da codificação da instância ou do ponto final selecionado no próprio valor. Enquanto o cookie for válido, se o cliente incluir o cookie de afinidade de sessão no cabeçalho do pedido Cookie de pedidos HTTP subsequentes, o balanceador de carga direciona esses pedidos para a instância ou o ponto final de back-end selecionado.

Ao contrário de outros métodos de afinidade de sessão:

  • A afinidade baseada em cookies com estado não tem requisitos específicos para o modo de equilíbrio de carga nem para a política de localidade de equilíbrio de carga (localityLbPolicy).

  • A afinidade baseada em cookies com estado não é afetada quando o dimensionamento automático adiciona uma nova instância a um grupo de instâncias gerido.

  • A afinidade baseada em cookies com estado não é afetada quando o dimensionamento automático remove uma instância de um grupo de instâncias gerido, a menos que a instância selecionada seja removida.

  • A afinidade baseada em cookies com estado não é afetada quando a autocorreção remove uma instância de um grupo de instâncias gerido a menos que a instância selecionada seja removida.

Para mais informações, consulte o artigo sobre perder a afinidade da sessão.

Significado de TTL zero para afinidades baseadas em cookies

Todas as afinidades de sessão baseadas em cookies, como a afinidade de cookie gerado, a afinidade de cookie HTTP e a afinidade baseada em cookies com estado, têm um atributo TTL.

Um TTL de zero segundos significa que o equilibrador de carga não atribui um Expiresatributo ao cookie. Neste caso, o cliente trata o cookie como um cookie de sessão. A definição de uma sessão varia consoante o cliente:

  • Alguns clientes, como os navegadores de Internet, retêm o cookie durante toda a sessão de navegação. Isto significa que o cookie persiste em vários pedidos até que a aplicação seja fechada.

  • Outros clientes tratam uma sessão como um único pedido HTTP, rejeitando o cookie imediatamente a seguir.

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.
Exceto para a afinidade de sessão baseada em cookies com estado, 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

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

A tabela seguinte descreve o comportamento de comutação por falha em cada modo:

Modo do balanceador de carga Comportamento de comutação por falha Comportamento quando todos os back-ends estão em mau estado
Balanceador de carga de aplicações interno entre regiões

Comutação automática para back-ends em bom estado na mesma região ou noutras regiões.

O tráfego é distribuído entre back-ends em bom estado que abrangem várias regiões com base na distribuição de tráfego configurada.

 Devolve HTTP 503
Balanceador de carga de aplicações interno regional

Comutação automática por falha para back-ends em bom estado de funcionamento na mesma região.

O proxy Envoy envia tráfego para back-ends em bom estado numa região com base na distribuição de tráfego configurada.

 Devolve HTTP 503

Alta disponibilidade e comutação por falha entre regiões

Para balanceadores de carga de aplicações internos regionais

Para alcançar uma elevada disponibilidade, implemente vários Application Load Balancers internos regionais individuais em regiões que melhor suportem o tráfego da sua aplicação. Em seguida, usa uma política de encaminhamento de geolocalização do Cloud DNS para detetar se um equilibrador de carga está a responder durante uma interrupção regional. Uma política de geolocalização encaminha o tráfego para a região disponível mais próxima com base na origem do pedido do cliente. A verificação de saúde está disponível por predefinição para equilibradores de carga de aplicações internos.

Para balanceadores de carga de aplicações internos entre regiões

Pode configurar um Application Load Balancer interno entre regiões em várias regiões para obter as seguintes vantagens:

  1. Se o Application Load Balancer interno entre regiões numa região falhar, as políticas de encaminhamento de DNS encaminham o tráfego para um Application Load Balancer interno entre regiões noutra região.

    O exemplo de implementação de alta disponibilidade mostra o seguinte:

    • Um Application Load Balancer interno entre regiões com um endereço IP virtual (VIP) de front-end nas regiões RegionA e RegionB na sua rede VPC. Os seus clientes estão localizados na região de RegionA.
    • Pode tornar o equilibrador de carga acessível através de VIPs de front-end de duas regiões e usar políticas de encaminhamento de DNS para devolver o VIP ideal aos seus clientes. Use políticas de encaminhamento de geolocalização se quiser que os seus clientes usem o VIP geograficamente mais próximo.
    • As políticas de encaminhamento de DNS podem detetar se um VIP não está a responder durante uma interrupção regional e devolver o VIP seguinte mais adequado aos seus clientes, garantindo que a sua aplicação permanece ativa mesmo durante interrupções regionais.
    Balanceador de carga de aplicações interno entre regiões com implementação de alta disponibilidade.
    Balanceador de carga de aplicações interno entre regiões com implementação de alta disponibilidade (clique para aumentar).

  2. Se os back-ends numa determinada região estiverem inativos, o tráfego do Application Load Balancer interno entre regiões é transferido sem problemas para os back-ends noutra região.

    O exemplo de implementação de comutação por falha entre regiões mostra o seguinte:

    • Um balanceador de carga de aplicações interno entre regiões com um endereço VIP de front-end na RegionA região da sua rede VPC. Os seus clientes também estão localizados na região RegionA.
    • Um serviço de back-end global que faz referência aos back-ends nas regiões RegionA e RegionB Google Cloud .
    • Quando os back-ends na região RegionA estão inativos, o tráfego é redirecionado para a região RegionB.
    Balanceador de carga de aplicações interno entre regiões com uma implementação de comutação por falha entre regiões.
    Balanceador de carga de aplicações interno entre regiões com uma implementação de comutação por falha entre regiões (clique para aumentar).

Suporte do WebSocket

Google Cloud Os balanceadores de carga baseados em HTTP(S) suportam o protocolo WebSocket quando usa HTTP ou HTTPS como protocolo para o back-end. O equilibrador de carga não requer qualquer configuração para usar proxy de ligações WebSocket.

O protocolo WebSocket fornece um canal de comunicação full duplex entre os clientes e o balanceador de carga. Para mais informações, consulte o RFC 6455.

O protocolo WebSocket funciona da seguinte forma:

  1. O balanceador de carga reconhece um pedido de websocket Upgrade de um cliente HTTP ou HTTPS. O pedido contém os cabeçalhos Connection: Upgrade e Upgrade: websocket, seguidos de outros cabeçalhos de pedidos relacionados com o websocket relevantes.
  2. O back-end envia uma resposta Upgrade do WebSocket. A instância de back-end envia uma resposta 101 switching protocol com os cabeçalhos Connection: Upgrade e Upgrade: websocket e outros cabeçalhos de resposta relacionados com o WebSocket.
  3. O balanceador de carga encaminha o tráfego bidirecional durante a ligação atual.

Se a instância de back-end devolver um código de estado 426 ou 502, o balanceador de carga fecha a ligação.

A afinidade de sessão para websockets funciona da mesma forma que para qualquer outro pedido. Para mais informações, consulte o artigo Afinidade de sessões.

Compatibilidade com HTTP/2

O HTTP/2 é uma revisão importante do protocolo HTTP/1. Existem 2 modos de suporte do HTTP/2:

  • HTTP/2 sobre TLS
  • HTTP/2 em texto simples através de TCP

HTTP/2 sobre TLS

O HTTP/2 sobre TLS é suportado para ligações entre clientes e o balanceador de carga de aplicações externo, e para ligações entre o balanceador de carga e os respetivos back-ends.

O balanceador de carga negoceia automaticamente o HTTP/2 com os clientes como parte da negociação TLS através da extensão TLS ALPN. Mesmo que um balanceador de carga esteja configurado para usar HTTPS, os clientes modernos usam o HTTP/2 por predefinição. Isto é controlado no cliente e não no equilibrador de carga.

Se um cliente não suportar HTTP/2 e o balanceador de carga estiver configurado para usar HTTP/2 entre o balanceador de carga e as instâncias de back-end, o balanceador de carga pode negociar uma ligação HTTPS ou aceitar pedidos HTTP não seguros. Esses pedidos HTTPS ou HTTP são, em seguida, transformados pelo balanceador de carga para encaminhar os pedidos através de HTTP/2 para as instâncias de back-end.

Para usar o HTTP/2 sobre TLS, tem de ativar o TLS nos seus back-ends e definir o protocolo de serviço de back-end como HTTP2. Para mais informações, consulte o artigo Encriptação do equilibrador de carga para os back-ends.

Streams simultâneas máximas de HTTP/2

A definição HTTP/2 SETTINGS_MAX_CONCURRENT_STREAMS descreve o número máximo de streams que um ponto final aceita, iniciado pelo par. O valor anunciado por um cliente HTTP/2 a um equilibrador de carga é efetivamente insignificante porque o equilibrador de carga não inicia streams para o cliente.Google Cloud

Nos casos em que o balanceador de carga usa o HTTP/2 para comunicar com um servidor que está a ser executado numa VM, o balanceador de carga respeita o valor SETTINGS_MAX_CONCURRENT_STREAMS anunciado pelo servidor, até um valor máximo de 100. Na direção do pedido (Google Cloud equilibrador de carga → servidor gRPC), o equilibrador de carga usa a frame SETTINGS inicial do servidor gRPC para determinar quantos streams por ligação podem estar em uso simultaneamente. Se o servidor anunciar um valor superior a 100, o equilibrador de carga usa 100 como o número máximo de streams simultâneas. Se for anunciado um valor de zero, o balanceador de carga não pode encaminhar pedidos para o servidor e isto pode resultar em erros.

Tamanho da tabela de cabeçalhos dinâmicos HTTP/2

O HTTP/2 melhora significativamente o HTTP/1.1 com funcionalidades como a multiplexagem e a compressão de cabeçalhos HPACK. O HPACK usa uma tabela dinâmica que melhora a compressão de cabeçalhos, tornando tudo mais rápido. Para compreender o impacto das alterações dinâmicas ao tamanho da tabela de cabeçalhos no HTTP/2, como esta funcionalidade pode melhorar o desempenho e como um erro específico em várias bibliotecas de clientes HTTP pode causar problemas na compressão de cabeçalhos HPACK, consulte o artigo da comunidade.

Limitações do HTTP/2

  • O HTTP/2 entre o balanceador de carga e a instância pode exigir significativamente mais ligações TCP à instância do que o HTTP ou o HTTPS. A partilha de ligações, uma otimização que reduz o número destas ligações com HTTP ou HTTPS, não está disponível com HTTP/2. Consequentemente, pode observar latências elevadas no back-end, uma vez que as ligações ao back-end são feitas com maior frequência.
  • O HTTP/2 entre o balanceador de carga e o back-end não suporta a execução do protocolo WebSocket numa única stream de uma ligação HTTP/2 (RFC 8441).
  • O HTTP/2 entre o balanceador de carga e o back-end não suporta o push de servidor.
  • A taxa de erros e o volume de pedidos do gRPC não estão visíveis naGoogle Cloud API nem na Google Cloud consola. Se o ponto final gRPC devolver um erro, os registos do equilibrador de carga e os dados de monitorização comunicam o código de estado HTTP 200 OK.

HTTP/2 em texto não cifrado através de TCP (H2C)

O HTTP/2 de texto não cifrado através de TCP, também conhecido como H2C, permite-lhe usar o HTTP/2 sem TLS. O H2C é suportado para ambas as seguintes ligações:

  • Ligações entre os clientes e o balanceador de carga. Não é necessária nenhuma configuração especial.

  • Ligações entre o balanceador de carga e os respetivos back-ends.

    Para configurar o H2C para ligações entre o balanceador de carga e os respetivos back-ends, defina o protocolo do serviço de back-end como H2C.

O suporte de H2C também está disponível para balanceadores de carga criados com o controlador do GKE Gateway e o Cloud Service Mesh.

O H2C não é suportado para balanceadores de carga de aplicações clássicos.

Compatibilidade com gRPC

O gRPC é uma framework de código aberto para chamadas de procedimento remoto. Baseia-se na norma HTTP/2. Seguem-se alguns exemplos de utilização do gRPC:

  • Sistemas distribuídos de baixa latência e altamente escaláveis
  • Desenvolver clientes para dispositivos móveis que comunicam com um servidor na nuvem
  • Conceber novos protocolos que têm de ser precisos, eficientes e independentes do idioma
  • Design em camadas para permitir a extensão, a autenticação e o registo

Para usar o gRPC com as suas Google Cloud aplicações, tem de encaminhar os pedidos de extremo a extremo através de HTTP/2. Para o fazer, crie um balanceador de carga da aplicação com uma das seguintes configurações:

  • Para tráfego não encriptado ponto a ponto (sem TLS): cria um balanceador de carga HTTP (configurado com um proxy HTTP de destino). Além disso, configura o balanceador de carga para usar o HTTP/2 para ligações não encriptadas entre o balanceador de carga e os respetivos back-ends definindo o protocolo do serviço de back-end como H2C.

  • Para tráfego encriptado ponto a ponto (com TLS): cria um balanceador de carga HTTPS (configurado com um proxy HTTPS de destino e um certificado SSL). O equilibrador de carga negoceia o HTTP/2 com os clientes como parte do handshake SSL através da extensão TLS ALPN.

    Além disso, tem de se certificar de que os backends conseguem processar o tráfego TLS e configurar o balanceador de carga para usar o HTTP/2 para ligações encriptadas entre o balanceador de carga e os respetivos backends, definindo o protocolo do serviço de backend como HTTP2.

    O balanceador de carga ainda pode negociar HTTPS com alguns clientes ou aceitar pedidos HTTP não seguros num balanceador de carga configurado para usar HTTP/2 entre o balanceador de carga e as instâncias de back-end. Esses pedidos HTTP ou HTTPS são transformados pelo equilibrador de carga para encaminhar os pedidos através de HTTP/2 para as instâncias de back-end.

Suporte de TLS

Por predefinição, um proxy de destino HTTPS aceita apenas TLS 1.0, 1.1, 1.2 e 1.3 quando termina pedidos SSL de clientes.

Quando o balanceador de carga de aplicações interno usa HTTPS como o protocolo de serviço de back-end, pode negociar TLS 1.2 ou 1.3 para o back-end.

Suporte de TLS mútuo

O TLS mútuo, ou mTLS, é um protocolo da norma da indústria para a autenticação mútua entre um cliente e um servidor. O mTLS ajuda a garantir que o cliente e o servidor se autenticam entre si, verificando se cada um tem um certificado válido emitido por uma autoridade de certificação (AC) fidedigna. Ao contrário do TLS padrão, em que apenas o servidor é autenticado, o mTLS requer que o cliente e o servidor apresentem certificados, confirmando as identidades de ambas as partes antes de a comunicação ser estabelecida.

Todos os balanceadores de carga de aplicações suportam mTLS. Com o mTLS, o equilibrador de carga pede ao cliente que envie um certificado para se autenticar durante o handshake TLS com o equilibrador de carga. Pode configurar um arquivo de confiança do gestor de certificados que o equilibrador de carga usa para validar a cadeia de confiança do certificado de cliente.

Para mais informações sobre o mTLS, consulte o artigo Autenticação TLS mútua.

Limitações

  • Não existe garantia de que um pedido de um cliente numa zona da região seja enviado para um back-end que esteja na mesma zona que o cliente. A afinidade de sessão não reduz a comunicação entre zonas.

  • Os balanceadores de carga de aplicações internos não são compatíveis com as seguintes funcionalidades:

  • Para usar certificados do Gestor de certificados com equilibradores de carga de aplicações internos, tem de usar a API ou a CLI gcloud. A consolaGoogle Cloud não suporta certificados do Certificate Manager.

  • Um balanceador de carga de aplicações interno suporta HTTP/2 apenas através de TLS.

  • Os clientes que se ligam a um balanceador de carga de aplicações interno têm de usar a versão 1.1 do HTTP ou posterior. O HTTP 1.0 não é suportado.

  • Google Cloud não envia um aviso se o seu proxy-only subnet ficar sem endereços IP.

  • A regra de encaminhamento interno que o Application Load Balancer interno usa tem de ter exatamente uma porta.

  • Quando usa um Application Load Balancer interno com o Cloud Run num ambiente de VPC partilhada, as redes VPC autónomas nos projetos de serviço podem enviar tráfego para quaisquer outros serviços do Cloud Run implementados noutros projetos de serviço no mesmo ambiente de VPC partilhada. Este é um problema conhecido.

  • Google Cloud não garante que uma ligação TCP subjacente possa permanecer aberta durante todo o valor do limite de tempo do serviço de back-end. Os sistemas cliente têm de implementar uma lógica de repetição em vez de dependerem de uma ligação TCP para estarem abertos durante longos períodos.

O que se segue?