Visão geral do balanceador de carga interno do aplicativo

Neste documento, apresentamos os conceitos que você precisa entender para configurar balanceadores de carga de aplicativo internos.

Um Trusted Cloud by S3NS balanceador de carga de aplicativo interno é um balanceador de carga de camada 7 baseado em proxy que permite executar e escalonar seus serviços em um único endereço IP interno. O balanceador de carga de aplicativo interno distribui o tráfego HTTP e HTTPS aos back-ends hospedados em várias plataformas do Trusted Cloud , como o Compute Engine, o Google Kubernetes Engine (GKE) e o Cloud Run. Para mais detalhes, consulte Casos de uso.

Modos de operação

Esse balanceador de carga está disponível no modo regional e será daqui por diante chamado de balanceador de carga de aplicativo interno regional. O balanceador de carga é implementado como um serviço gerenciado baseado no proxy Envoy de código aberto. Ele inclui recursos de gerenciamento avançado de tráfego, como espelhamento de tráfego, divisão de tráfego baseada em peso, transformações de cabeçalho baseadas em solicitação ou resposta e muito mais. O modo regional exige que os back-ends estejam em uma única região Trusted Cloud . Os clientes podem estar limitados a essa região ou em qualquer região, dependendo se o acesso global está desativado ou ativado na regra de encaminhamento.

Arquitetura e recursos

O diagrama a seguir mostra os recursos do Trusted Cloud necessários para balanceadores de carga de aplicativo internos:

Balanceador de carga de aplicativo interno regional

Este diagrama mostra os componentes de uma implantação de balanceador de carga de aplicativo interno regional no nível Premium.

Componentes de um balanceador de carga de aplicativo interno regional.
Componentes de um balanceador de carga de aplicativo interno regional (clique para ampliar).

Os seguintes recursos são necessários para uma implantação interna do balanceador de carga de aplicativo:

Sub-rede somente proxy

A sub-rede somente proxy fornece um conjunto de endereços IP que o Google usa para executar proxies Envoy em seu nome. É necessário criar uma sub-rede somente proxy em cada região de uma rede VPC em que você usa balanceadores de carga de aplicativo internos regionais. A flag --purpose dessa sub-rede somente proxy está definida como REGIONAL_MANAGED_PROXY. Todos os balanceadores de carga regionais baseados no Envoy em uma região e rede VPC compartilham um pool de proxies do Envoy da mesma sub-rede somente proxy.

Além disso:

  • As sub-redes somente proxy são usadas apenas para proxies Envoy, não para seus back-ends.
  • As VMs de back-end ou os endpoints de todos os balanceadores de carga de aplicativo interno em uma região e rede VPC recebem conexões da sub-rede somente proxy.
  • O endereço IP virtual de um balanceador de carga de aplicativo interno não está localizado na sub-rede somente proxy. O endereço IP do balanceador de carga é definido pela regra de encaminhamento gerenciada interna, descrita abaixo.

Regra de encaminhamento e endereço IP

As regras de encaminhamento roteiam o tráfego por endereço IP, porta e protocolo para uma configuração de balanceamento de carga que consiste em proxy de destino e serviço de back-end.

Especificação de endereço IP. Cada regra de encaminhamento referencia um endereço IP regional único que pode ser usado nos registros DNS do aplicativo. É possível reservar um endereço IP estático que possa ser usado ou permitir que o Cloud Load Balancing atribua um para você. Recomendamos reservar um endereço IP estático. Caso contrário, será necessário atualizar o registro DNS com o endereço IP temporário recém-atribuído sempre que uma regra de encaminhamento for excluída e uma nova for criada.

Os clientes usam o endereço IP e a porta para se conectar aos proxies do Envoy relativos ao balanceador de carga. O endereço IP da regra de encaminhamento é o endereço IP do balanceador de carga, que é chamado frequentemente de endereço IP virtual ou VIP. Os clientes que se conectam a um balanceador de carga precisam usar a versão 1.1 ou posterior do HTTP. Para ver a lista completa de protocolos suportados, consulte Comparação de recursos do balanceador 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 back-ends.

Especificação da porta. Cada regra de encaminhamento para um balanceador de carga de aplicativo pode referenciar uma única porta de 1 a 65535. Para permitir várias portas, configure várias regras de encaminhamento. É possível configurar várias regras de encaminhamento para usar o mesmo endereço IP interno (VIP) e ter referência ao mesmo proxy HTTP ou HTTPS de destino, desde que a combinação geral do endereço IP, da porta e do protocolo sejam exclusivos para cada regra de encaminhamento. Dessa forma, é possível usar um único balanceador de carga com um mapa de URL compartilhado como um proxy para vários aplicativos.

O tipo de regra de encaminhamento, o endereço IP e o esquema de balanceamento de carga usado por balanceadores de carga de aplicativo internos depende do modo do balanceador de carga.

Balanceador de carga de aplicativo 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
Roteamento do cliente para o front-end do balanceador de carga

É possível ativar o acesso global para permitir que clientes de qualquer região em uma VPC acessem o balanceador de carga. Os back-ends também precisam estar na mesma região que o balanceador de carga.

Regras de encaminhamento e redes VPC

Esta seção descreve como as regras de encaminhamento usadas por balanceadores de carga de aplicativo internos são associadas às redes VPC.

Modo balanceador de carga Associação de rede VPC
Balanceador de carga de aplicativo interno regional

Os endereços IPv4 internos regionais sempre existem dentro das redes VPC. Ao criar a regra de encaminhamento, é necessário especificar a sub-rede de onde o endereço IP interno é retirado. Essa sub-rede precisa estar na mesma região e rede VPC em que uma sub-rede somente proxy foi criada. Assim, há uma associação de rede implícita.

Proxy de destino

Um proxy HTTP ou HTTPS de destino encerra as conexões HTTP(S) dos clientes. O proxy HTTP(S) consulta o mapa de URLs para determinar como rotear o tráfego para os back-ends. Um proxy HTTPS de destino usa um certificado SSL para fazer a autenticação para os clientes.

O balanceador de carga preserva o cabeçalho Host da solicitação original do cliente. 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 conecta ao balanceador de carga
  • O endereço IP da regra de encaminhamento do balanceador de carga

Se não houver nenhum cabeçalho X-Forwarded-For na solicitação recebida, esses dois endereços IP serão o valor inteiro do cabeçalho. Se a solicitação tiver um cabeçalho X-Forwarded-For, outras informações, como os endereços IP registrados por proxies no caminho até o balanceador de carga, serão preservadas antes dos dois endereços IP. O balanceador de carga não verifica endereços IP que precedem os dois últimos endereços IP nesse cabeçalho.

Se você estiver executando um proxy como servidor de back-end, esse proxy normalmente anexará mais informações ao cabeçalho X-Forwarded-For, e o software poderá precisar considerar isso. As solicitações por proxy do balanceador de carga vêm de um endereço IP na sub-rede somente proxy, e seu proxy na instância de back-end pode registrar esse endereço e o endereço IP da própria instância.

Dependendo do tipo de tráfego que o aplicativo precisa processar, é possível configurar um balanceador de carga com um proxy HTTP ou HTTPS de destino.

A tabela a seguir mostra as APIs de proxy de destino exigidas pelos balanceadores de carga de aplicativo internos:

Modo balanceador de carga Proxy de destino
Balanceador de carga de aplicativo interno regional

Certificados SSL

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

Os balanceadores de carga de aplicativo internos regionais oferecem suporte a certificados SSL autogerenciados do Compute Engine.

Mapas de URL

O proxy HTTP(S) de destino usa mapas de URL para determinar o roteamento com base em atributos HTTP, como o caminho da solicitação, cookies ou cabeçalhos. Com base na decisão de roteamento, o proxy encaminha as solicitações do cliente para serviços de back-end regionais específicos. O mapa de URL pode especificar outras ações a serem tomadas, como regravar cabeçalhos, enviar redirecionamentos a clientes e configurar políticas de tempo limite, entre outras.

A seguinte tabela especifica o tipo de mapa de URL exigido pelos balanceadores de carga de aplicativo internos em cada modo:

Modo balanceador de carga Tipo de mapa de URL
Balanceador de carga de aplicativo interno regional regionUrlMaps

Serviço de back-end

Um serviço de back-end fornece informações de configuração ao balanceador de carga para que ele possa direcionar solicitações aos back-ends, por exemplo, grupos de instâncias do Compute Engine ou grupos de endpoints de rede (NEGs). Para mais informações sobre serviços de back-end, consulte Visão geral dos serviços de back-end.

Escopo do serviço de back-end

A tabela a seguir indica qual recurso e escopo de serviço de back-end são usados pelos balanceadores de carga de aplicativo internos:

Modo balanceador de carga Recurso de serviço de back-end
Balanceador de carga de aplicativo interno regional regionBackendServices

Protocolo para os back-ends

Os serviços de back-end para balanceadores de carga de aplicativo precisam usar um dos seguintes protocolos para enviar solicitações aos 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 criptografia não é compatível).
  • H2C, que usa HTTP/2 sobre TCP. O TLS não é obrigatório. O H2C não é compatível com balanceadores de carga de aplicativo clássicos.

O balanceador de carga usa apenas o protocolo do serviço de back-end especificado para se comunicar com os back-ends. O balanceador de carga não vai recorrer a um protocolo diferente se não conseguir se comunicar com os back-ends usando o protocolo de serviço de back-end especificado.

O protocolo do serviço de back-end não precisa corresponder ao protocolo usado pelos clientes para se comunicar com o balanceador de carga. Por exemplo, os clientes podem enviar solicitações ao balanceador de carga usando HTTP/2, mas o balanceador de carga pode se comunicar com back-ends usando HTTP/1.1 (HTTP ou HTTPS).

Back-ends

Um balanceador de carga de aplicativo externo regional é compatível com os seguintes tipos de back-ends:

  • Grupos de instâncias
  • NEGs por zona
  • NEGs na Internet
  • NEGs híbridos

Back-ends e redes VPC

As restrições de onde os back-ends podem estar localizados dependem do tipo de backend.

  • Para grupos de instâncias, NEGs zonais e NEGs de conectividade híbrida, todos os back-ends precisam estar localizados no mesmo projeto e região do serviço de back-end. No entanto, um balanceador de carga pode referenciar um back-end que usa outra rede VPC no mesmo projeto que o serviço de back-end. A conectividade entre a rede VPC do balanceador de carga e a rede VPC de back-end pode ser configurada usando o peering de rede VPC, túneis da Cloud VPN ou anexos da VLAN do Cloud Interconnect.

    Definição de rede de back-end

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

    Requisitos de rede de back-end

    A rede do seu back-end precisa atender a um dos requisitos de rede a seguir:

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

    • A rede VPC do back-end precisa estar conectada à rede VPC da regra de encaminhamento usando o peering de rede VPC. É necessário configurar as trocas de rotas de sub-rede para permitir a comunicação entre a sub-rede somente proxy na rede VPC da regra de encaminhamento e as sub-redes usadas pelas instâncias ou endpoints de back-end.

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

Back-ends e interfaces de rede

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

Se você usar back-ends de NEG zonal, os pacotes serão enviados para qualquer interface de rede representada pelo endpoint no NEG. Os endpoints do NEG precisam estar na mesma rede VPC que a rede VPC definida explicitamente do NEG.

Subconfiguração de back-ends

A subconfiguração de back-end é um recurso opcional compatível com balanceadores de carga de aplicativo internos regionais que melhora o desempenho e a escalonabilidade por meio da atribuição de um subconjunto de back-ends a cada uma das instâncias de proxy.

Por padrão, a subconfiguração de back-end fica desativada. Para informações sobre como ativar esse recurso, consulte Subagrupamento de back-end para balanceadores de carga de aplicativo internos regionais.

Verificações de integridade

Cada serviço de back-end especifica uma verificação de integridade que monitora periodicamente a prontidão dos back-ends para receber uma conexão do balanceador de carga. Isso reduz o risco de as solicitações serem enviadas para back-ends que não possam atender à solicitação. As verificações de integridade não conferem se o aplicativo está funcionando.

Para realizar sondagens de verificação de integridade com sucesso, é necessário criar uma regra de firewall de permissão do Ingress que permita que as sondagens de verificação de integridade acessem as instâncias de back-end. Normalmente, as sondagens de verificação de integridade são originadas do mecanismo centralizado de verificação de integridade do Google. No entanto, para NEGs híbridos, as verificações de integridade são originadas na sub-rede somente proxy. Para mais detalhes, consulte Verificações de integridade distribuídas do Envoy.

Protocolo de verificação de integridade

Embora não seja obrigatório e nem sempre possível, é recomendável usar uma verificação de integridade que tenha um protocolo que corresponda ao protocolo do serviço de back-end. Por exemplo, uma verificação de integridade HTTP/2 testa com mais precisão a conectividade HTTP/2 aos back-ends. Por outro lado, os balanceadores de carga de aplicativo internos que usam back-ends de NEG híbridos não são compatíveis com verificações de integridade do gRPC. Para ver a lista de protocolos de verificação de integridade compatíveis, consulte os recursos de balanceamento de carga na seção Verificações de integridade.

A tabela a seguir especifica o escopo das verificações de integridade compatíveis com balanceadores de carga de aplicativo internos:

Modo balanceador de carga Tipo de verificação de integridade
Balanceador de carga de aplicativo interno regional regionHealthChecks

Para saber mais sobre verificações de integridade, consulte:

Regras de firewall

Um balanceador de carga de aplicativo interno requer as seguintes regras de firewall:

  • Uma regra de permissão de entrada que permita o tráfego dos intervalos de verificação de integridade central do Google. Para mais informações sobre os intervalos de endereços IP de sondagem de verificação de integridade específicos e por que é necessário permitir o tráfego deles, consulte Intervalos de IP de sondagem e regras de firewall.
  • Uma regra de permissão de entrada que permita o tráfego da sub-rede somente proxy.

Há algumas exceções aos requisitos de regras de firewall para esses intervalos:

  • Não é necessário permitir o tráfego dos intervalos de sondagem de verificação de integridade do Google para NEGs híbridos. No entanto, se você estiver usando uma combinação de NEGs híbridos e zonais em um único serviço de back-end, será necessário permitir o tráfego dos intervalos de sondagem de verificação de integridade do Google para os NEGs zonais.
  • Para NEGs regionais da Internet, as verificações de integridade são opcionais. O tráfego de balanceadores de carga que usam NEGs regionais da Internet é proveniente da sub-rede somente proxy e, em seguida, é convertido por NAT (usando o Cloud NAT) para endereços IP NAT alocados automaticamente ou manualmente. Esse tráfego inclui sondagens de verificação de integridade e solicitações de usuários do balanceador de carga aos back-ends. Para detalhes, consulte NEGs regionais: usar um gateway do Cloud NAT.

Acesso de cliente

Os clientes podem estar na mesma rede ou em uma rede VPC conectada usando o peering de rede VPC.

Para balanceadores de carga de aplicativo internos regionais, os clientes precisam estar, por padrão, na mesma região que o balanceador de carga. É possível ativar o acesso global para permitir que clientes de qualquer região em uma VPC acessem o balanceador de carga.

A seguinte tabela resume o acesso do cliente para balanceadores de carga de aplicativo internos regionais:

Acesso global desativado Acesso global ativado
Os clientes precisam estar na mesma região que o balanceador de carga. Também precisam estar na mesma rede VPC do balanceador de carga ou em uma conectada à do balanceador usando o peering da rede VPC. Os clientes podem estar em qualquer região. Ainda precisam estar na mesma rede VPC do balanceador de carga ou em uma conectada à do balanceador usando peering da rede VPC.
Os clientes locais podem acessar o balanceador de carga por meio de túneis VPN do Cloud ou anexos da VLAN. Esses túneis ou anexos precisam estar na mesma região do balanceador de carga. Os clientes locais podem acessar o balanceador de carga por meio de túneis VPN do Cloud ou anexos da VLAN. Esses túneis ou anexos podem estar em qualquer região.

Suporte do GKE

O GKE usa balanceadores de carga de aplicativo internos das seguintes maneiras:

  • Os gateways internos criados com o controlador de gateway do GKE podem usar qualquer modo de um balanceador de carga de aplicativo interno. Você controla o modo do balanceador de carga escolhendo uma GatewayClass. O controlador de gateway do GKE sempre usa back-ends de NEG zonal GCE_VM_IP_PORT.

  • As entradas internas criadas com o controlador de Entrada do GKE são sempre balanceadores de carga de aplicativo internos regionais. O controlador de entrada do GKE sempre usa back-ends de NEG zonal GCE_VM_IP_PORT.

Arquiteturas de VPC compartilhada

Os balanceadores de carga de aplicativo internos são compatíveis com redes que usam a VPC compartilhada. A VPC compartilhada permite que as organizações conectem recursos de vários projetos a uma rede VPC comum para que eles possam se comunicar uns com os outros com segurança e eficiência usando IPs internos dessa rede. Se você ainda não estiver familiarizado com a VPC compartilhada, leia a documentação de visão geral da VPC compartilhada.

Há muitas maneiras de configurar um balanceador de carga de aplicativo interno em uma rede VPC compartilhada. Independentemente do tipo de implantação, todos os componentes do balanceador de carga precisam estar na mesma organização.

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

Crie a rede e as sub-redes necessárias (incluindo a sub-rede somente proxy) no projeto host da VPC compartilhada.

O endereço IP interno do balanceador de carga pode ser definido no projeto host ou em um projeto de serviço, mas precisa usar uma sub-rede na rede VPC compartilhada desejada no host projeto. O endereço vem 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 URL associado precisam ser definidos no mesmo projeto. Esse projeto pode ser o projeto host ou de serviços. Você tem estas opções:
  • Crie serviços de back-end e back-ends (grupos dex instâncias, NEGs sem servidor ou qualquer outro tipo de back-end compatível) 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 compatíveis) em quantos projetos de serviço forem necessários. Um único mapa de URL pode referenciar serviços de back-end em diferentes projetos. Esse tipo de implantação é conhecido como referência de serviço entre projetos.

Cada serviço de back-end precisa ser definido no mesmo projeto que os back-ends a que ele faz referência. As verificações de integridade associadas aos serviços de back-end também precisam ser definidas no mesmo projeto que o serviço de back-end.

Embora seja possível criar todos os componentes e back-ends de balanceamento de carga no projeto host da VPC compartilhada, esse tipo de implantação não separa as responsabilidades de administração de rede e desenvolvimento de serviços.

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

O diagrama de arquitetura a seguir mostra uma implantação de VPC compartilhada padrão em que todos os componentes e back-ends do balanceador de carga estão em um projeto de serviço. Todos os balanceadores de carga de aplicativo dão suporte a esse tipo de implantação.

O balanceador de carga usa endereços IP e sub-redes a partir do projeto host. Os clientes poderão acessar um balanceador de carga de aplicativo interno se estiverem na mesma região e rede VPC compartilhada que ele. Os clientes podem estar localizados no projeto host, em um projeto de serviço anexado ou em qualquer rede conectada.

Balanceador de carga de aplicativo interno em uma rede VPC compartilhada.
Balanceador de carga de aplicativo interno na rede VPC compartilhada (clique para ampliar).

Back-ends sem servidor em um ambiente de VPC compartilhada

Para um balanceador de carga de aplicativo interno que esteja usando um back-end NEG sem servidor, o serviço de backup do Cloud Run precisa estar no mesmo projeto de serviço que o serviço de back-end e o NEG sem servidor. Os componentes do front-end do balanceador de carga (regra de encaminhamento, proxy de destino, mapa de URL) podem ser criados no projeto host, no mesmo projeto de serviço dos componentes de back-end ou em qualquer outro projeto de serviço no mesmo ambiente de VPC compartilhada.

Referência de serviço entre projetos

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

Com a referência de serviços entre projetos, as organizações podem configurar um balanceador de carga central e direcionar o tráfego para centenas de serviços distribuídos em vários projetos diferentes. É possível gerenciar de maneira centralizada todas as regras e políticas de roteamento de tráfego em um mapa de URL. Também é possível associar o balanceador de carga a um único conjunto de nomes de host e certificados SSL. Portanto, é possível otimizar o número de balanceadores de carga necessários para implantar o aplicativo e reduzir os gerenciamentos, os custos operacionais e os requisitos de cota.

Com projetos diferentes para cada uma das equipes funcionais, também é possível alcançar a separação de papéis dentro da organização. Os proprietários de serviço podem se concentrar na criação de serviços em projetos de serviço, enquanto as equipes de rede podem provisionar e manter os balanceadores de carga em outro projeto. Ambos podem ser conectados por referência de serviço entre projetos.

Os proprietários de serviços podem manter a autonomia sobre a exposição dos próprios serviços e controlar quais usuários podem acessá-los pelo balanceador de carga. Isso é alcançado por um papel especial do IAM chamado função do usuário dos serviços do balanceador de carga do Compute (roles/compute.loadBalancerServiceUser).

Para balanceadores de carga de aplicativo internos, a referência de serviços entre projetos só é compatível em ambientes de VPC compartilhada.

Para saber como configurar a VPC compartilhada para um balanceador de carga de aplicativo interno, com e sem a referência de serviço entre projetos, consulte Configurar um balanceador de carga de aplicativo interno com VPC compartilhada.

Observações de uso para referência de serviço entre projetos

  • Não será possível referenciar um serviço de back-end entre projetos se ele tiver back-ends de NEG da Internet regionais. Há suporte para todos os outros tipos de back-end.
  • OTrusted Cloud não diferencia recursos (por exemplo, serviços de back-end) que usam o mesmo nome em vários projetos. Portanto, ao usar a referência de serviços entre projetos, recomendamos o uso de nomes exclusivos de serviço de back-end em todos os projetos da organização.

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

Veja um exemplo de uma implantação de VPC compartilhada em que o front-end e o mapa de URL do balanceador de carga são criados no projeto de serviço A e o mapa de URL faz referência a um serviço de back-end no projeto de serviço B.

Nesse caso, os administradores de rede ou 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 o papel de usuário de serviços do balanceador de carga do Compute (roles/compute.loadBalancerServiceUser) aos administradores do balanceador de carga no projeto de serviço A que querem referenciar o serviço de back-end no projeto de serviço B.

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

Exemplo 2: front-end do balanceador de carga no projeto host e back-ends em projetos de serviço

Confira um exemplo de implantação de VPC compartilhada em que o front-end e o mapa de URL do balanceador de carga são criados no projeto host, e os serviços de back-end (e back-ends) são criados em projetos de serviço.

Nesse caso, os administradores de rede ou de balanceador de carga no projeto host precisam de acesso aos serviços de back-end no projeto de serviço. Os administradores do projeto de serviço concedem o papel de usuário de serviços do balanceador de carga do Compute (roles/compute.loadBalancerServiceUser) aos administradores do balanceador de carga no projeto host A que querem referenciar o serviço de back-end no projeto de serviço.

Front-end do balanceador de carga e mapa de URL no projeto host.
Front-end do balanceador de carga e mapa de URL no projeto host (clique para ampliar).

Tempo limite e tentativas

Os balanceadores de carga de aplicativo interno são compatíveis com os seguintes tipos de tempo limite:

Tipo e descrição de tempo limite Valores padrão Compatível com valores personalizados
Tempo limite do serviço de back-end

Tempo limite de solicitação e resposta. Representa o tempo máximo permitido entre o momento em que o balanceador de carga envia o primeiro byte de uma solicitação para o back-end e o momento em que o back-end retorna o último byte da resposta HTTP para o balanceador de carga. Se o back-end não retornar toda a resposta HTTP ao balanceador de carga dentro desse limite de tempo, os dados de resposta restantes serão descartados.
  • Para NEGs sem servidor em um serviço de back-end: 60 minutos
  • Para todos os outros tipos de back-end em um serviço de back-end: 30 segundos
Tempo limite do sinal de atividade HTTP do cliente

O tempo máximo que a conexão TCP entre um cliente e o proxy Envoy gerenciado do balanceador de carga pode ficar inativa. A mesma conexão TCP pode ser usada para várias solicitações HTTP.

 610 segundos
Tempo limite do sinal de atividade HTTP do back-end

O tempo máximo que a conexão TCP entre o proxy Envoy gerenciado do balanceador de carga e um back-end pode ficar inativa. A mesma conexão TCP pode ser usada para várias solicitações HTTP.

 10 minutos (600 segundos)

Tempo limite 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 até o back-end processar uma solicitação HTTP e retornar a resposta HTTP correspondente. Exceto para NEGs sem servidor, o valor padrão do tempo limite do serviço de back-end é de 30 segundos.

Por exemplo, se você quiser fazer o download de um arquivo de 500 MB e o valor do tempo limite do serviço de back-end for de 90 segundos, o balanceador de carga aguardará o back-end enviar todo o arquivo de 500 MB em até 90 segundos. É possível configurar o tempo limite do serviço de back-end como insuficiente para que o back-end envie a resposta HTTP completa. Nessa situação, se o balanceador de carga tiver recebido do back-end pelo menos os cabeçalhos de resposta HTTP, ele retornará os cabeçalhos completos e o máximo possível do corpo de resposta dentro do tempo limite do serviço de back-end.

Recomendamos que você defina o tempo limite do serviço de back-end como o período mais longo que espera ser necessário para o back-end processar uma resposta HTTP. Se o software em execução no back-end precisar de mais tempo para processar uma solicitação HTTP e retornar a resposta inteira, recomendamos que você aumente o tempo limite do serviço de back-end.

O tempo limite do serviço de back-end aceita valores entre 1 e 2,147,483,647 segundos. Valores maiores não são opções de configuração possíveis. Além disso, oTrusted Cloud não garante que uma conexão TCP subjacente possa permanecer aberta durante todo o valor do tempo limite do serviço de back-end. Os sistemas clientes precisam implementar a lógica de nova tentativa em vez de depender que uma conexão TCP permaneça aberta por períodos longos.

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

Trusted Cloud reinicia periodicamente ou muda o número de tarefas de software do Envoy em atendimento. Quanto maior o valor do tempo limite do serviço de back-end, maiores as chances de conexões TCP serem encerradas por reiniciações ou substituições de tarefas do Envoy.

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

Console

Modifique o campo Tempo limite 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 de serviço de back-end.

API

Modifique o parâmetro timeoutSec para o recurso regionBackendServices

Tempo limite do sinal de atividade HTTP do cliente

O tempo limite do sinal de atividade HTTP do cliente representa o tempo máximo em que uma conexão TCP pode ficar inativa entre o cliente (downstream) e um proxy Envoy. O valor padrão do tempo limite do sinal de atividade HTTP do cliente é de 610 segundos. É possível configurar o tempo limite com um valor entre 5 e 1.200 segundos.

Um tempo limite do sinal de atividade HTTP também é chamado de tempo limite de inatividade do TCP.

O tempo limite do sinal de atividade do cliente HTTP do balanceador de carga precisa ser maior que o tempo limite do sinal de atividade HTTP (TCP inativo) usado por clientes downstream ou proxies. Se um cliente downstream tiver o tempo limite do sinal de atividade HTTP (TCP inativo) maior do que o tempo limite do sinal de atividade HTTP do cliente do balanceador de carga, ocorrerá uma possível disputa. Da perspectiva de um cliente downstream, uma conexão TCP estabelecida pode ficar inativa por mais tempo do que o balanceador de carga permite. Isso significa que o cliente downstream pode enviar pacotes depois que o balanceador de carga considerar a conexão TCP encerrada. Quando isso acontece, o balanceador de carga responde com um pacote de redefinição (RST) TCP.

Quando o tempo limite do sinal de atividade HTTP do cliente expira, o GFE ou o proxy Envoy envia um TCP FIN ao cliente para fechar a conexão normalmente.

Tempo limite do sinal de atividade HTTP do back-end

Os balanceadores de carga de aplicativo internos são proxies que usam uma primeira conexão TCP entre o cliente (downstream) e um proxy Envoy e uma segunda conexão TCP entre o proxy Envoy e os back-ends.

As conexões TCP secundárias do balanceador de carga talvez não sejam encerradas após cada solicitação. Elas podem permanecer abertas para lidar com várias solicitações e respostas HTTP. O tempo limite do sinal de atividade HTTP do back-end define o tempo limite de inatividade do TCP entre o balanceador de carga e os back-ends. O tempo limite do sinal de atividade HTTP de back-end não se aplica a websockets.

O tempo limite do sinal de atividade do back-end é fixado em 10 minutos (600 segundos) e não pode ser alterado. Isso ajuda a garantir que o balanceador de carga mantenha as conexões ociosas por pelo menos 10 minutos. Depois desse período, o balanceador de carga pode enviar pacotes de encerramento para o back-end a qualquer momento.

O tempo limite do sinal de atividade do back-end do balanceador de carga precisa ser menor que o tempo limite do sinal de atividade usado pelo software em execução nos back-ends. Isso evita uma disputa em que o sistema operacional dos back-ends pode encerrar conexões TCP com uma redefinição (RST) TCP. Como o tempo limite do sinal de atividade do back-end do balanceador de carga não é configurável, é necessário configurar o software do back-end para que o valor de tempo limite do sinal de atividade HTTP (TCP inativo) seja maior que 600 segundos.

Quando o tempo limite do sinal de atividade HTTP do back-end expira, o GFE ou o proxy Envoy envia um TCP FIN para a VM de back-end para fechar a conexão normalmente.

A tabela a seguir lista as alterações necessárias para modificar os valores de tempo limite do sinal de atividade para software servidor da Web comum.

Software servidor da Web Parâmetro Configuração padrão Configuração recomendada
Apache KeepAliveTimeout KeepAliveTimeout 5 KeepAliveTimeout 620
nginx keepalive_timeout keepalive_timeout 75s; keepalive_timeout 620s;

Novas tentativas

Para configurar novas tentativas, use uma política de nova tentativa no mapa de URL. O número padrão de novas tentativas (numRetries) é 1. O perTryTimeout máximo configurável é de 24 horas.

Sem uma política de nova tentativa, solicitações malsucedidas sem um corpo HTTP (por exemplo, solicitações GET) que resultarem em respostas HTTP 502, 503 ou 504 serão repetidas uma vez.

As solicitações HTTP POST não são repetidas.

As solicitações repetidas geram apenas uma entrada de registro para a resposta final.

Para mais informações, consulte Geração de registros e monitoramento do balanceador de carga interno do aplicativo.

Como acessar redes conectadas

Seus clientes podem acessar um balanceador de carga de aplicativo interno na rede VPC de uma rede conectada usando o seguinte:

  • Peering de rede VPC
  • Cloud VPN e Cloud Interconnect

Para exemplos detalhados, consulte Balanceadores de carga de aplicativos internos e redes conectadas.

afinidade da sessão

A afinidade de sessão, configurada no serviço de back-end dos balanceadores de carga de aplicativo, oferece uma tentativa de melhor esforço para enviar solicitações de um cliente específico para o mesmo back-end enquanto o número de instâncias ou endpoints de back-end íntegros permanecer constante e enquanto a instância ou o endpoint de back-end selecionado anteriormente não estiver atingindo a capacidade. A capacidade de destino do modo de balanceamento determina quando o back-end está no limite.

A tabela a seguir descreve os diferentes tipos de opções de afinidade da sessão compatíveis com os diferentes balanceadores de carga de aplicativo. Na seção a seguir, Tipos de afinidade da sessão, cada tipo é discutido em mais detalhes.

Tabela:configurações de afinidade da sessão compatíveis
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 com base em cookie com estado (STRONG_COOKIE_AFFINITY)

Outras observações:

  • O valor padrão efetivo da política de localidade de balanceamento de carga (localityLbPolicy) muda de acordo com as configurações de afinidade da sessão. Se a afinidade da sessão não estiver configurada, ou seja, se a afinidade da sessão permanecer com o valor padrão de NONE, o valor padrão de localityLbPolicy será ROUND_ROBIN. Se a afinidade da sessão for definida como um valor diferente de NONE, o valor padrão de localityLbPolicy será MAGLEV.
  • No caso dos balanceadores de carga de aplicativo internos, não configure a afinidade da sessão se você estiver usando a divisão de tráfego ponderada. Se você fizer isso, a configuração da divisão de tráfego ponderada terá precedência.

Lembre-se do seguinte ao configurar a afinidade da sessão:

  • Não confie na afinidade da sessão para fins de autenticação ou segurança. A afinidade da sessão, exceto a afinidade da sessão baseada em cookie com estado, pode ser interrompida sempre que o número de back-ends de exibição e íntegros muda. Para mais detalhes, consulte Perda de afinidade da sessão.

  • Os valores padrão das sinalizações --session-affinity e --subsetting-policy são NONE, e apenas um por vez pode ser definido como um valor diferente.

Tipos de afinidade da sessão

A afinidade da sessão para balanceadores de carga de aplicativo internos pode ser classificada em uma das seguintes categorias:
  • Afinidade da sessão baseada em hash (NONE, CLIENT_IP)
  • Afinidade da sessão baseada em cabeçalho HTTP (HEADER_FIELD)
  • Afinidade da sessão baseada em cookie (GENERATED_COOKIE, HTTP_COOKIE, STRONG_COOKIE_AFFINITY)

Afinidade da sessão baseada em hash

Para a afinidade da sessão baseada em hash, o balanceador de carga usa o algoritmo de hash consistente para selecionar um back-end qualificado. A configuração de afinidade da sessão determina quais campos do cabeçalho IP são usados para calcular o hash.

Afinidade da sessão baseada em hash pode ser dos seguintes tipos:

Nenhum

Uma configuração de afinidade da sessão de NONE não significa que não há afinidade da sessão. Isso significa que nenhuma opção afinidade da sessão foi configurada explicitamente.

O hash é sempre realizado para selecionar um back-end. Uma configuração de afinidade da sessão de NONE significa que o balanceador de carga usa um hash de cinco tuplas para selecionar um back-end. O hash de 5 tuplas 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 da sessão de NONE é o valor padrão.

Afinidade de IP do cliente

A afinidade da sessão IP do cliente (CLIENT_IP) é um hash de duas tuplas criado com os endereços IP de origem e destino do pacote. A afinidade de IP do cliente encaminha todas as solicitações do mesmo endereço IP do cliente para o mesmo back-end, desde que esse back-end tenha capacidade e se mantenha íntegro.

Ao usar a afinidade de IP do cliente, lembre-se do 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 ao 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 ou sistema de proxy intermediário antes de ser entregue a um balanceador de carga Trusted Cloud . Em situações em que muitos clientes compartilham o mesmo endereço IP de origem efetivo, algumas VMs de back-end podem receber mais conexões ou solicitações do que outras.

Afinidade da sessão baseada em cabeçalho HTTP

Com a afinidade do campo de cabeçalho (HEADER_FIELD), as solicitações são encaminhadas para os back-ends com base no valor do cabeçalho HTTP no campo consistentHash.httpHeaderName do serviço de back-end. Para distribuir solicitações em todos os back-ends disponíveis, cada cliente precisa usar um valor de cabeçalho HTTP diferente.

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

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

Afinidade da sessão baseada em cookies pode ser dos seguintes tipos:

Quando você usa a afinidade baseada em cookie gerado (GENERATED_COOKIE), o balanceador de carga inclui um cookie HTTP no cabeçalho Set-Cookie em resposta à solicitação HTTP inicial.

O nome do cookie gerado varia de acordo com o tipo de balanceador de carga.

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

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

É possível configurar o valor de time to live (TTL) do cookie entre 0 e 1,209,600 segundos (inclusive) usando o parâmetro de serviço de back-end affinityCookieTtlSec. Se affinityCookieTtlSec não for especificado, o valor padrão de TTL será 0.

Quando o cliente inclui o cookie afinidade da sessão gerado no cabeçalho de solicitação Cookie de solicitações HTTP, o balanceador de carga direciona essas solicitações para a mesma instância ou endpoint de back-end, desde que o cookie de afinidade de sessão permaneça válido. Isso é feito mapeando o valor do cookie para um índice que faz referência a uma instância de back-end ou um endpoint específico e garantindo que os requisitos afinidade da sessão do cookie gerado sejam atendidos.

Para usar a afinidade de cookie gerado, configure o seguinte modo de balanceamento e as configurações de localityLbPolicy:

  • Para grupos de instâncias de back-end, use o modo de balanceamento RATE.
  • Para o localityLbPolicy do serviço de back-end, use RING_HASH ou MAGLEV. Se você não definir explicitamente o localityLbPolicy, o balanceador de carga usará MAGLEV como um padrão implícito.

Para mais informações, consulte perda da afinidade de sessão.

Quando você usa a afinidade baseada em cookie HTTP (HTTP_COOKIE), o balanceador de carga inclui um cookie HTTP no cabeçalho Set-Cookie em resposta à solicitação HTTP inicial. Você especifica o nome, o caminho e o time to live (TTL) do cookie.

Todos os balanceadores de carga de aplicativo são compatíveis com a afinidade baseada em cookies HTTP.

É possível configurar os valores de TTL do cookie usando segundos, frações de segundo (como nanossegundos) ou ambos (segundos mais frações de segundo, como nanossegundos) usando os seguintes parâmetros e valores válidos do serviço de back-end:

  • consistentHash.httpCookie.ttl.seconds pode ser definido como um valor entre 0 e 315576000000 (inclusive).
  • consistentHash.httpCookie.ttl.nanos pode ser definido como um valor entre 0 e 999999999 (inclusive). Como as unidades são nanossegundos, 999999999 significa .999999999 segundos.

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

Quando o cliente inclui o cookie afinidade da sessão HTTP no cabeçalho de solicitação Cookie de solicitações HTTP, o balanceador de carga direciona essas solicitações para a mesma instância ou endpoint de back-end, desde que o cookie de afinidade de sessão permaneça válido. Isso é feito mapeando o valor do cookie para um índice que faz referência a uma instância de back-end ou um endpoint específico e garantindo que os requisitos afinidade da sessão do cookie gerado sejam atendidos.

Para usar a afinidade de cookie HTTP, configure o seguinte modo de balanceamento e as configurações de localityLbPolicy:

  • Para grupos de instâncias de back-end, use o modo de balanceamento RATE.
  • Para o localityLbPolicy do serviço de back-end, use RING_HASH ou MAGLEV. Se você não definir explicitamente o localityLbPolicy, o balanceador de carga usará MAGLEV como um padrão implícito.

Para mais informações, consulte perda da afinidade de sessão.

Afinidade da sessão com estado baseada em cookie

Quando você usa a afinidade baseada em cookie com estado (STRONG_COOKIE_AFFINITY), o balanceador de carga inclui um cookie HTTP no cabeçalho Set-Cookie em resposta à solicitação HTTP inicial. Você especifica o nome, o caminho e time to live (TTL) do cookie.

Os seguintes balanceadores de carga são compatíveis com a afinidade com estado baseada em cookies:

  • Balanceadores de carga de aplicativo externos regionais
  • Balanceadores de carga de aplicativo internos regionais

É possível configurar os valores de TTL do cookie usando segundos, frações de um segundo (como nanossegundos) ou ambos. A duração representada por strongSessionAffinityCookie.ttl não pode ser definida como um valor que represente mais de duas semanas (1.209.600 segundos).

O valor do cookie identifica uma instância ou um endpoint de back-end selecionado codificando a instância ou o endpoint selecionado no próprio valor. Enquanto o cookie for válido, se o cliente incluir o cookie afinidade da sessão no cabeçalho de solicitação Cookie de solicitações HTTP subsequentes, o balanceador de carga vai direcionar essas solicitações para a instância ou o endpoint de back-end selecionado.

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

  • A afinidade baseada em cookie com estado não tem requisitos específicos para o modo de balanceamento ou para a política de localidade de balanceamento de carga (localityLbPolicy).

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

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

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

Para mais informações, consulte perda da afinidade de sessão.

Significado de TTL zero para afinidades baseadas em cookies

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

Um TTL de zero segundos significa que o balanceador de carga não atribui um atributo Expires ao cookie. Nesse caso, o cliente trata o cookie como um cookie de sessão. A definição de uma sessão varia de acordo com o cliente:

  • Alguns clientes, como navegadores da Web, retêm o cookie durante toda a sessão de navegação. Isso significa que o cookie persiste em várias solicitações até que o aplicativo seja fechado.

  • Outros clientes tratam uma sessão como uma única solicitação HTTP, descartando o cookie imediatamente depois.

Perda da afinidade da sessão

Todas as opções afinidade da sessão exigem o seguinte:

  • A instância ou o endpoint de back-end selecionado precisa permanecer configurado como um back-end. A afinidade da sessão pode ser interrompida quando um dos seguintes eventos ocorre:
    • Remova a instância selecionada do grupo de instâncias.
    • O escalonamento automático ou a recuperação automática do grupo de instâncias gerenciadas remove a instância selecionada do grupo.
    • Você remove o endpoint selecionado do NEG.
    • Remova do serviço de back-end o grupo de instâncias ou o NEG que contém a instância ou o endpoint selecionado.
  • A instância ou o endpoint de back-end selecionado precisa permanecer íntegro. A afinidade de sessão pode ser interrompida quando a instância ou o endpoint selecionado falha nas verificações de integridade.
Exceto pela afinidade da sessão baseada em cookie com estado, todas as opções de afinidade da sessão têm os seguintes requisitos adicionais:

  • O grupo de instâncias ou NEG que contém a instância ou o endpoint selecionado não pode estar cheio, conforme definido pela capacidade desejada. Para grupos gerenciados de instâncias regionais, o componente zonal do grupo de instâncias que contém a instância selecionada não pode estar cheio. A afinidade da 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. Como o nível de ocupação pode mudar de maneiras imprevisíveis ao usar o modo de balanceamento UTILIZATION, use o modo RATE ou CONNECTION para minimizar situações em que a afinidade da sessão pode ser interrompida.

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

    • Adicionar novas instâncias ou endpoints:

      • Você adiciona instâncias a um grupo de instâncias atual no serviço de back-end.
      • O escalonamento automático de grupos gerenciados de instâncias adiciona instâncias a um grupo gerenciado de instâncias no serviço de back-end.
      • Você adiciona endpoints a um NEG atual no serviço de back-end.
      • Adicione grupos de instâncias ou NEGs não vazios ao serviço de back-end.

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

      • Você remove qualquer instância de um back-end de grupo de instâncias.
      • O escalonamento automático ou a recuperação automática de um grupo de instâncias gerenciadas remove qualquer instância de um back-end grupo gerenciado de instâncias.
      • Você remove qualquer endpoint de um back-end de 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 endpoints de back-end íntegros precisa permanecer constante. Quando pelo menos um dos seguintes eventos ocorre, o número de instâncias ou endpoints de back-end íntegros muda, e a afinidade da sessão pode ser interrompida:

    • Qualquer instância ou endpoint passa na verificação de integridade, fazendo a transição de não íntegro para íntegro.
    • Qualquer instância ou endpoint falha na verificação de integridade, passando de íntegro para não íntegro ou tempo limite.

Failover

Se um back-end não estiver íntegro, o tráfego será redirecionado automaticamente para back-ends íntegros.

A seguinte tabela descreve o comportamento de failover em cada modo:

Modo balanceador de carga Comportamento de failover Comportamento quando nenhum back-end estiver íntegro
Balanceador de carga de aplicativo interno regional

Failover automático em back-ends íntegros na mesma região.

O proxy do Envoy envia o tráfego para back-ends íntegros em uma região com base na distribuição de tráfego configurada.

 Retorna HTTP 503

Alta disponibilidade e failover entre regiões

Para balanceadores de carga de aplicativo internos regionais

Para ter alta disponibilidade, implante vários balanceadores de carga de aplicativo internos regionais individuais nas regiões que melhor oferecem suporte ao tráfego do aplicativo. Em seguida, use uma política de roteamento de geolocalização do Cloud DNS para detectar se um balanceador de carga está respondendo durante uma interrupção regional. Uma política de geolocalização encaminha o tráfego para a próxima região disponível mais próxima com base na origem da solicitação do cliente. A verificação de integridade está disponível por padrão para balanceadores de carga de aplicativo internos.

Suporte a WebSocket

Trusted Cloud Os balanceadores de carga baseados em HTTP(S) oferecem suporte ao protocolo WebSocket quando você usa HTTP ou HTTPS como protocolo para o back-end. O balanceador de carga não exige configuração para representar conexões WebSocket.

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

O protocolo WebSocket funciona da seguinte maneira:

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

Se a instância de back-end retornar um código de status 426 ou 502, o balanceador de carga encerra a conexão.

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

Suporte a HTTP/2

HTTP/2 é uma revisão importante do protocolo HTTP/1. Há dois modos de suporte ao HTTP/2:

  • HTTP/2 por TLS
  • Texto não criptografado HTTP/2 sobre TCP

HTTP/2 por TLS

O HTTP/2 por TLS é compatível com conexões entre clientes e o balanceador de carga de aplicativo externo, e para conexões entre o balanceador de carga e os back-ends dele.

O balanceador de carga negocia o HTTP/2 com clientes como parte do handshake SSL usando a extensão ALPN TLS. Mesmo que um balanceador de carga esteja configurado para usar HTTPS, os clientes modernos usam HTTP/2 como padrão. Isso é controlado no cliente, não no balanceador de carga.

Se um cliente não oferecer suporte a 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 ainda poderá negociar uma conexão HTTPS ou aceitar solicitações HTTP não seguras. Essas solicitações HTTPS ou HTTP são transformadas pelo balanceador de carga para fazer proxy das solicitações por HTTP/2 para as instâncias de back-end.

Para usar HTTP/2 por TLS, ative o TLS nos seus back-ends e defina o protocolo do serviço de back-end como HTTP2. Para mais informações, consulte Criptografia do balanceador de carga nos back-ends.

Máximo de streams simultâneos HTTP/2

A configuração HTTP/2 SETTINGS_MAX_CONCURRENT_STREAMS descreve o número máximo de streams aceitos por um endpoint, iniciado pelo par. O valor divulgado por um cliente HTTP/2 para um balanceador de cargaTrusted Cloud é efetivamente insignificante, porque o balanceador de carga não inicia streams para o cliente.

Nos casos em que o balanceador de carga usa HTTP/2 para se comunicar com um servidor em execução em uma VM, o balanceador de carga respeita o valor SETTINGS_MAX_CONCURRENT_STREAMS anunciado pelo servidor. Se um valor igual a zero for anunciado, o balanceador de carga não poderá encaminhar solicitações para o servidor. Isso poderá gerar erros.

Limitações do HTTP/2

  • O HTTP/2 entre o balanceador de carga e a instância pode exigir muito mais conexões TCP com a instância do que o HTTP ou HTTPS. O pool de conexões, uma otimização que reduz o número dessas conexões com HTTP ou HTTPS, não está disponível com o HTTP/2. Como resultado, talvez você veja altas latências de back-end porque as conexões de back-end são feitas com mais frequência.
  • O HTTP/2 entre o balanceador de carga e o back-end não é compatível com a execução do protocolo WebSocket em um único stream de uma conexão HTTP/2 (RFC 8441).
  • O HTTP/2 entre o balanceador de carga e o back-end não é compatível com push do servidor.
  • A taxa de erros do gRPC e o volume da solicitação não são visíveis na Trusted Cloud API ou no console Trusted Cloud . Se o endpoint do gRPC retornar um erro, os registros do balanceador de carga e os dados de monitoramento vão reportar o código de status HTTP 200 OK.

Texto não criptografado HTTP/2 sobre TCP (H2C)

O HTTP/2 em texto simples via TCP, também conhecido como H2C, permite usar o HTTP/2 sem TLS. O H2C é compatível com as seguintes conexões:

  • Conexões entre clientes e o balanceador de carga. Nenhuma configuração especial é necessária.

  • Conexões entre o balanceador de carga e os back-ends.

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

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

O H2C não é compatível com balanceadores de carga de aplicativo clássicos.

Suporte ao gRPC

O gRPC é um framework de código aberto para chamadas de procedimento remoto. Ele é baseado no padrão HTTP/2. Veja alguns casos de uso do gRPC:

  • Sistemas distribuídos de baixa latência e altamente escalonáveis.
  • Desenvolvimento de clientes de dispositivos móveis que se comunicam com um servidor em nuvem.
  • Criação de novos protocolos que ofereçam precisão, eficiência e não dependam de linguagem.
  • design em camadas que permita extensão, autenticação e geração de registros

Para usar o gRPC com seus aplicativos Trusted Cloud , é necessário enviar solicitações de proxy completas pelo HTTP/2. Para fazer isso, crie um balanceador de carga de aplicativo com uma das seguintes configurações:

  • Para tráfego não criptografado de ponta a ponta (sem TLS): crie um balanceador de carga HTTP (configurado com um proxy HTTP de destino). Além disso, configure o balanceador de carga para usar HTTP/2 em conexões não criptografadas entre o balanceador de carga e os back-ends dele definindo o protocolo do serviço de back-end como H2C.

  • Para tráfego criptografado de ponta a ponta (com TLS): crie um balanceador de carga HTTPS (configurado com um proxy HTTPS de destino e um certificado SSL). O balanceador de carga negocia o HTTP/2 com clientes como parte do handshake SSL usando a extensão ALPN TLS.

    Além disso, verifique se os back-ends podem processar o tráfego TLS e configure o balanceador de carga para usar HTTP/2 em conexões criptografadas entre o balanceador de carga e os back-ends definindo o protocolo do serviço de back-end como HTTP2.

    O balanceador de carga ainda pode negociar HTTPS com alguns clientes ou aceitar solicitações HTTP não seguras em um balanceador de carga configurado para usar HTTP/2 entre o balanceador de carga e as instâncias de back-end. Essas solicitações HTTP ou HTTPS são transformadas pelo balanceador de carga para representar as solicitações por HTTP/2 para as instâncias de back-end.

Suporte TLS

Por padrão, um proxy de destino HTTPS só aceita TLS 1.0, 1.1 e 1.2 e 1.3 ao encerrar solicitações SSL do cliente.

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

Suporte para TLS mútuo

O TLS mútuo, ou mTLS, é um protocolo padrão do setor para autenticação mútua entre um cliente e um servidor. O mTLS ajuda a garantir que o cliente e o servidor se autentiquem mutuamente, verificando se cada um tem um certificado válido emitido por uma autoridade de certificação (CA) confiável. Ao contrário do TLS padrão, em que apenas o servidor é autenticado, o mTLS exige que o cliente e o servidor apresentem certificados, confirmando as identidades de ambas as partes antes que a comunicação seja estabelecida.

Todos os balanceadores de carga de aplicativo oferecem suporte a mTLS. Com o mTLS, o balanceador de carga solicita que o cliente envie um certificado para se autenticar durante o handshake de TLS com o balanceador de carga. É possível configurar um repositório de confiança do Gerenciador de certificados que o balanceador de carga usa para validar a cadeia de confiança do certificado do cliente.

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

Limitações

  • Não há garantia de que uma solicitação de um cliente em uma zona da região seja enviada para um back-end que esteja na mesma zona que o cliente. A afinidade da sessão não reduz a comunicação entre as zonas.

  • Os balanceadores de carga de aplicativo interno não são compatíveis com os seguintes recursos:

  • Para usar certificados do Gerenciador de certificados com balanceadores de carga de aplicativo internos, use a API ou a CLI gcloud. O console Trusted Cloud não é compatível com certificados do Certificate Manager.

  • Um balanceador de carga de aplicativo interno é compatível com HTTP/2 somente por TLS.

  • Os clientes que se conectam a um balanceador de carga interno de aplicativo precisam usar a versão 1.1 ou posterior do HTTP. O HTTP 1.0 não é compatível.

  • OTrusted Cloud não avisa se os endereços IP da sub-rede somente proxy acabarem.

  • A regra de encaminhamento interno usada pelo balanceador de carga interno do aplicativo precisa ter exatamente uma porta.

  • Ao usar um balanceador de carga de aplicativo interno com o Cloud Run em um ambiente de VPC compartilhada, as redes VPC autônomas em projetos de serviço podem enviar tráfego para qualquer outro serviço do Cloud Run implantado em qualquer outro projetos de serviço no mesmo ambiente de VPC compartilhada. Esse é um problema conhecido.

  • Trusted Cloud não garante que uma conexão TCP subjacente possa permanecer aberta durante todo o valor do tempo limite do serviço de back-end. Os sistemas clientes precisam implementar a lógica de nova tentativa em vez de depender que uma conexão TCP permaneça aberta por períodos longos.

A seguir