Vista geral do balanceador de carga de rede de proxy externo

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

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

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

Este equilibrador de carga está disponível no modo regional e, a partir deste momento, é denominado equilibrador de carga de rede de proxy externo regional. O balanceador de carga é implementado como um serviço gerido com base no proxy Envoy de código aberto. O modo regional garante que todos os clientes e backends estão numa região especificada. Use este equilibrador de carga se quiser publicar conteúdo a partir de apenas uma geolocalização (por exemplo, para cumprir os regulamentos de conformidade).

Arquitetura

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

Regional

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

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

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

Sub-rede só de proxy

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

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

Pontos a ter em conta:

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

Regras de encaminhamento e endereços IP

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

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

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

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

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

Modo do balanceador de carga Nível de serviço de rede Regra de encaminhamento, endereço IP e esquema de balanceamento de carga Encaminhamento da Internet para a interface do balanceador de carga
Balanceador de carga de rede de proxy externo regional Nível Premium

Regra de encaminhamento externo regional

Endereço IP externo regional

Esquema de balanceamento de carga: EXTERNAL_MANAGED

 Pedidos encaminhados para os proxies do Envoy na mesma região que o balanceador de carga.

Regras de encaminhamento e redes VPC

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

Modo do balanceador de carga Associação da rede da VPC
Balanceador de carga de rede de proxy externo regional

A rede VPC da regra de encaminhamento é a rede onde a sub-rede só de proxy foi criada. Especifica a rede quando cria a regra de encaminhamento.

Proxies de destino

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

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

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

Modo do balanceador de carga Nível de serviço de rede Proxy de destino
Balanceador de carga de rede de proxy externo regional Nível Premium e Standard regionTargetTcpProxies

Serviços de back-end

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

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

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

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

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

Modo do balanceador de carga Back-ends suportados num serviço de back-end
Grupos de instâncias NEGs zonais NEGs da Internet NEGs sem servidor NEGs híbridos GKE
Balanceador de carga de rede de proxy externo regional Pontos finais do tipo GCE_VM_IP_PORT Apenas NEGs regionais

Back-ends e redes VPC

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

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

    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.

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

Back-ends e interfaces de rede

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

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

Protocolo para comunicar com os back-ends

Quando configura um serviço de back-end para um equilibrador de carga de rede de proxy externo, define o protocolo que o serviço de back-end usa para comunicar com os back-ends. O balanceador de carga usa apenas o protocolo que especificar e não tenta negociar uma ligação com o outro protocolo. Os balanceadores de carga de rede de proxy externos só suportam TCP para comunicar com os back-ends.

Regras de firewall

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

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

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

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

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

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

Endereços IP de origem

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

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

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

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

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

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

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

Portas abertas

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

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

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

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

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

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

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

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

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

Arquitetura de VPC partilhada

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

Endereço IP Regra de encaminhamento Proxy de destino Componentes de back-end
Tem de definir um endereço IP externo no mesmo projeto que o equilibrador de carga. A regra de encaminhamento externo tem de ser definida no mesmo projeto que as instâncias de back-end (o projeto de serviço). O proxy TCP alvo tem de ser definido no mesmo projeto que as instâncias de back-end.

Para os balanceadores de carga de rede de proxy externos regionais, as VMs de back-end estão normalmente localizadas num projeto de serviço. Tem de definir um serviço de back-end regional e uma verificação de estado de funcionamento nesse projeto de serviço.

Distribuição de tráfego

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

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

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

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

Balanceador de carga de rede de proxy externo regional

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

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

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

Para mais informações, consulte o seguinte:

Afinidade de sessão

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

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

  • Nenhum

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

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

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

  • Afinidade de IP do cliente

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

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

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

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

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

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

Perder a afinidade de sessão

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

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

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

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

    • Adicionar novas instâncias ou pontos finais:

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

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

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

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

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

Failover

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

  • Se um back-end ficar em mau estado, o tráfego é automaticamente redirecionado para back-ends em bom estado na mesma região.
  • Se todos os back-ends estiverem em mau estado, o equilibrador de carga rejeita o tráfego.

Balanceamento de carga para aplicações do GKE

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

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

Limitações

  • Não pode criar um Network Load Balancer de proxy externo regional no nível Premium através da Trusted Cloud consola .Em alternativa, use a CLI gcloud ou a API.

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

O que se segue?