Visão geral dos grupos de endpoints da rede de conectividade híbrida

O Cloud Load Balancing é compatível com o tráfego de balanceamento de carga para endpoints que se estendem além do Google Cloud, como data centers locais e outras nuvens públicas que podem ser acessadas utilizando a conectividade híbrida.

Uma estratégia híbrida é uma solução pragmática para você se adaptar às demandas do mercado em constante mudança e modernizar gradualmente os aplicativos. Essa pode ser uma implantação híbrida temporária para permitir a migração para uma solução moderna baseada na nuvem ou uma instalação permanente da infraestrutura de TI da sua organização.

A configuração do balanceamento de carga híbrido também permite trazer os benefícios dos recursos de rede do Cloud Load Balancing para serviços em execução na infraestrutura atual fora do Google Cloud.

O balanceamento de carga híbrido é compatível com estes balanceadores de carga do Google Cloud:

Serviços locais e outros serviços de nuvem são tratados como qualquer outro back-end do Cloud Load Balancing. A principal diferença é que você usa um NEG de conectividade híbrida para configurar os endpoints desses back-ends. Os endpoints precisam ser combinações IP:port válidas que seu balanceador de carga possa alcançar usando produtos de conectividade híbrida, como o Cloud VPN ou o Cloud Interconnect.

Caso de uso: rotear o tráfego para um local ou outra nuvem

O caso de uso mais simples para NEGs híbridos é rotear o tráfego de um balanceador de carga do Google Cloud para um local ou para outro ambiente de nuvem. Os clientes podem originar o tráfego da Internet pública, do Google Cloud ou de um cliente local.

Clientes públicos

É possível usar um balanceador de carga de aplicativo externo com um back-end NEG híbrido para rotear o tráfego de clientes externos para um back-end no local ou em outra rede de nuvem. Também é possível ativar os seguintes recursos de rede de valor agregado para seus serviços no local ou em outras redes de nuvem:

  • Com o balanceador de carga de aplicativo externo global e o balanceador de carga de aplicativo clássico, é possível:

    • usar a infraestrutura de borda global do Google para encerrar as conexões do usuário que estão mais próximas do usuário, diminuindo assim a latência;
    • Proteger o serviço com o Google Cloud Armor, um produto de borda de segurança de WAF e defesa contra DDoS disponível para todos os serviços acessados por um balanceador de carga de aplicativo externo.
    • Ative seu serviço para otimizar os envios usando o Cloud CDN. Com o Cloud CDN, é possível armazenar conteúdo em cache próximo aos usuários. O Cloud CDN fornece recursos como invalidação de cache e URLs assinados do Cloud CDN.
    • usar certificados SSL gerenciados pelo Google. É possível reutilizar certificados e chaves privadas que você já usa para outros produtos do Google Cloud. Isso elimina a necessidade de gerenciar certificados separados.

    O diagrama a seguir demonstra uma implantação híbrida com um balanceador de carga de aplicativo externo.

    Conectividade híbrida com um balanceador de carga de aplicativo externo global.
    Conectividade híbrida com um balanceador de carga de aplicativo externo global (clique para ampliar)

    Neste diagrama, o tráfego de clientes na Internet pública entra na rede particular local ou na nuvem por um balanceador de carga do Google Cloud, como o balanceador de carga de aplicativo externo. Quando o tráfego chega ao balanceador de carga, é possível aplicar serviços de borda de rede, como a proteção contra DDoS do Google Cloud Armor ou a autenticação do usuário do Identity-Aware Proxy (IAP).

  • Com o balanceador de carga de aplicativo externo regional, é possível rotear o tráfego externo para endpoints que estão na mesma região do Google Cloud que os recursos do balanceador de carga. Use esse balanceador de carga se precisar exibir conteúdo de apenas uma geolocalização (por exemplo, para atender às regulamentações de conformidade) ou se você quiser usar o nível de serviço de rede Standard.

A maneira como a solicitação é encaminhada (para um back-end do Google Cloud ou para um endpoint local/na nuvem) depende de como o mapa de URL está configurado. Dependendo do mapa de URL, o balanceador de carga seleciona um serviço de back-end para a solicitação. Se o serviço de back-end selecionado tiver sido configurado com um NEG de conectividade híbrida (usado apenas para endpoints que não são do Google Cloud), o balanceador de carga encaminhará o tráfego pelo Cloud VPN ou pelo Cloud Interconnect para o destino pretendido.

Clientes internos (no Google Cloud ou no local)

Também é possível configurar uma implantação híbrida para clientes internos do Google Cloud. Nesse caso, o tráfego do cliente se origina da rede VPC do Google Cloud, da rede local ou de outra nuvem e é roteado para endpoints no local ou em outras redes na nuvem.

O balanceador de carga de aplicativo interno é regional, o que significa que ele só pode rotear tráfego para endpoints na mesma região do Google Cloud que os recursos do balanceador de carga. O balanceador de carga de aplicativo interno entre regiões é um balanceador de carga multirregional que pode balancear a carga do tráfego para serviços de back-end que são distribuídos globalmente.

O diagrama a seguir demonstra uma implantação híbrida com um balanceador de carga regional interno.

Conectividade híbrida com balanceadores de carga de aplicativo regionais internos.
Conectividade híbrida com balanceadores de carga de aplicativo internos (clique para ampliar)

Caso de uso: migrar para o Cloud

A migração de um serviço atual para o Cloud permite liberar a capacidade no local e reduzir o custo e a carga da manutenção da infraestrutura no local. É possível configurar temporariamente uma implantação híbrida que permite rotear o tráfego para o serviço local atual e para um endpoint de serviço do Google Cloud correspondente.

O diagrama a seguir demonstra essa configuração com um balanceador de carga de aplicativo interno.

Migre para o Google Cloud
Migrar para o Google Cloud (clique para ampliar).

Se você estiver usando um balanceador de carga de aplicativo interno para lidar com clientes internos, configure o balanceador de carga do Google Cloud para usar a divisão de tráfego baseada em peso para dividir o tráfego entre os dois serviços. A divisão de tráfego permite que você comece enviando 0% do tráfego para o serviço do Google Cloud e 100% para o serviço local. Em seguida, é possível aumentar gradualmente a proporção de tráfego enviado para o serviço do Google Cloud. Em algum momento, você enviará 100% do tráfego para o serviço do Google Cloud e poderá desativar o serviço local.

Arquitetura híbrida

Nesta seção, descrevemos a arquitetura e os recursos de balanceamento de carga necessários para configurar uma implantação de balanceamento de carga híbrida.

Serviços locais e outros serviços de nuvem são como qualquer outro back-end do Cloud Load Balancing. A principal diferença é que você usa um NEG de conectividade híbrida para configurar os endpoints desses back-ends. Os endpoints precisam ser combinações IP:port válidas que os clientes possam acessar com a conectividade híbrida, como o Cloud VPN ou o Cloud Interconnect.

Os diagramas a seguir mostram os recursos do Google Cloud necessários para ativar o balanceamento de carga híbrido para balanceadores de carga de aplicativo externos e internos.

HTTP(S) externo global

Recursos globais do balanceador de carga de aplicativo externo para conectividade híbrida.
Recursos do balanceador de carga de aplicativo externo global para conectividade híbrida (clique para ampliar)

HTTP(S) externo regional

Recursos regionais do balanceador de carga de aplicativo externo para conectividade híbrida.
Recursos do balanceador de carga de aplicativo externo regional para conectividade híbrida (clique para ampliar)

HTTP(S) interno regional

Recursos regionais do balanceador de carga de aplicativo interno para conectividade híbrida.
Recursos regionais do balanceador de carga regional para conectividade híbrida (clique para ampliar)

Proxy interno regional

Recursos do balanceador de carga de rede de proxy interno regional para conectividade híbrida.
Recursos do balanceador de carga de rede de proxy interno regional para conectividade híbrida (clique para ampliar)

Regional versus global

O roteamento do Cloud Load Balancing depende do escopo do balanceador de carga configurado:

Balanceador de carga de aplicativo externo e balanceador de carga de rede de proxy externo. Eles podem ser configurados para roteamento global ou regional, dependendo do nível de rede usado. Crie o back-end NEG híbrido do balanceador de carga na mesma região em que a conectividade híbrida foi configurada. Os endpoints que não são do Google Cloud também precisam ser configurados de acordo para aproveitar o balanceamento de carga baseado em proximidade.

Balanceador de carga de aplicativo interno entre regiões e balanceador de carga de rede de proxy interno entre regiões. Este é um balanceador de carga multirregional que pode balancear a carga do tráfego para serviços de back-end que são distribuídos globalmente. Crie o back-end NEG híbrido do balanceador de carga na mesma região em que a conectividade híbrida foi configurada. Os endpoints que não são do Google Cloud também precisam ser configurados de acordo para aproveitar o balanceamento de carga baseado em proximidade.

Balanceador de carga de aplicativo interno e balanceador de carga de rede de proxy interno regional. Esses são balanceadores de carga regionais. Ou seja, eles só podem rotear o tráfego para endpoints na mesma região do balanceador de carga. Os componentes do balanceador de carga precisam ser configurados na mesma região em que a conectividade híbrida foi configurada. Por padrão, os clientes que acessam o balanceador de carga também precisam estar na mesma região. No entanto, se você ativar o acesso global, os clientes de qualquer região poderão acessar o balanceador de carga.

Por exemplo, se o gateway da VPN do Cloud ou o anexo da VLAN do Cloud Interconnect estiverem configurados em us-central1, os recursos exigidos pelo balanceador de carga (como um serviço de back-end, NEG híbrido ou regra de encaminhamento) precisa ser criado na região us-central1. Por padrão, os clientes que acessam o balanceador de carga também precisam estar na região us-central1. No entanto, se você ativar o acesso global, os clientes de qualquer região poderão acessar o balanceador de carga.

Requisitos de conectividade de rede

Antes de configurar uma implantação de balanceamento de carga híbrida, é preciso ter os seguintes recursos configurados:

  • Rede VPC do Google Cloud. Uma rede VPC configurada no Google Cloud. Essa é a rede VPC usada para configurar o Cloud Interconnect/Cloud VPN e o Cloud Router. Essa também é a mesma rede em que você criará os recursos de balanceamento de carga (regra de encaminhamento, proxy de destino, serviço de back-end etc.). Os endereços IP locais, de outra nuvem e de sub-rede do Google Cloud e os intervalos de endereços IP não devem se sobrepor. Quando os endereços IP se sobrepõem, as rotas de sub-rede são priorizadas em relação à conectividade remota.

  • Conectividade híbrida. O Google Cloud e os ambientes locais ou em nuvem precisam ser conectados por uma conectividade híbrida usando anexos da VLAN do Cloud Interconnect ou túneis do Cloud VPN com o Cloud Router. Recomendamos que você use uma conexão de alta disponibilidade. Um Cloud Router ativado com roteamento dinâmico global aprende sobre o endpoint específico pelo BGP e o programa na rede VPC do Google Cloud. O roteamento dinâmico regional não é compatível. Rotas estáticas também não são compatíveis.

    O Cloud Interconnect/Cloud VPN e o Cloud Router precisam ser configurados na mesma rede VPC que você pretende usar para a implantação híbrida do balanceamento de carga. O Cloud Router também precisa anunciar as seguintes rotas para seu ambiente local:

    • Intervalos usados pelas sondagens de verificação de integridade do Google: 35.191.0.0/16 e 130.211.0.0/22. Isso é necessário para balanceadores de carga de aplicativo externos globais, balanceadores de carga de aplicativo clássicos, balanceadores de carga de rede de proxy externo global e balanceador de carga de rede de proxy clássico.

    • O intervalo da sub-rede somente proxy da região: para balanceadores de carga regionais baseados no Envoy (balanceadores de carga de aplicativo externos regionais, balanceadores de carga de rede de proxy externos regionais, balanceadores de carga de rede de proxy internos regionais e balanceadores de carga de aplicativo internos).

      A sub-rede somente proxy da região de publicidade também é necessária para que as verificações de integridade distribuídas do Envoy funcionem. A verificação de integridade distribuída do Envoy é o mecanismo padrão para os NEGS zonais de conectividade híbrida (ou seja, endpoints NON_GCP_PRIVATE_IP_PORT) dos balanceadores de carga baseados no Envoy.

  • Endpoints de rede (IP:Port) no local ou em outras nuvens. Um ou mais endpoints de rede IP:Port configurados nos ambientes locais ou outras nuvens, roteáveis pelo Cloud Interconnect ou Cloud VPN. Se houver vários caminhos para o endpoint do IP, o roteamento seguirá o comportamento descrito na Visão geral das rotas da VPC e na Visão geral do Cloud Router.

  • Regras de firewall no local ou em outras nuvens. As regras de firewall a seguir precisam ser criadas no ambiente local ou em outro ambiente de nuvem:

    • A entrada permite regras de firewall para permitir o tráfego das sondagens de verificação de integridade do Google para os endpoints. Os intervalos a serem permitidos são 35.191.0.0/16 e 130.211.0.0/22. Esses intervalos também precisam ser divulgados pelo Cloud Router para sua rede local. Para mais detalhes, consulte Intervalos de IP de sondagem e regras de firewall.
    • A entrada permite regras de firewall para permitir que o tráfego que está sendo balanceado para chegar aos endpoints.
    • Para balanceadores de carga baseados no Envoy: balanceadores de carga de aplicativo externos regionais, balanceadores de carga de rede de proxy externo regionais, balanceadores de carga de rede de proxy interno regional, balanceadores de carga de rede de proxy interno entre regiões e balanceadores de carga de aplicativo internos , também é necessário criar uma regra de firewall para permitir que o tráfego da sub-rede somente proxy da região alcance os endpoints no local ou em outros ambientes de nuvem.

Componentes do balanceador de carga

Dependendo do tipo de balanceador de carga, é possível configurar uma implantação híbrida de balanceamento de carga usando os níveis de serviço de rede Standard ou Premium.

Um balanceador de carga híbrido requer uma configuração especial somente para o serviço de back-end. A configuração do front-end é a mesma que qualquer outro balanceador de carga. Os balanceadores de carga baseados no Envoy (balanceadores de carga de aplicativo externos regionais, balanceadores de carga de rede de proxy externo regionais, balanceadores de carga de rede de proxy interno regional, balanceadores de carga de rede de proxy interno entre regiões e balanceadores de carga de aplicativo internos) exigem uma sub-rede somente proxy extra para executar proxies Envoy em seu nome.

Configuração de front-end

Nenhuma configuração de front-end especial é necessária para o balanceamento de carga híbrido. Regras de encaminhamento são usadas para rotear o tráfego por endereço IP, porta e protocolo para um proxy de destino. O proxy de destino encerra as conexões dos clientes.

Os mapas de URL são usados por balanceadores de carga HTTP(S) para configurar o roteamento baseado em URL de solicitações para os serviços de back-end apropriados.

Para mais detalhes sobre cada um desses componentes, consulte as seções de arquitetura de visões gerais específicas do balanceador de carga:

Serviço de back-end

Os serviços de back-end fornecem informações de configuração ao balanceador de carga. Os balanceadores de carga usam as informações de um serviço de back-end para direcionar o tráfego de entrada para um ou mais back-ends anexados.

Para configurar uma implantação de balanceamento de carga híbrido, configure o balanceador de carga com back-ends que estão dentro e fora do Google Cloud.

  • Back-ends que não são do Google Cloud (no local ou em outra nuvem)

    Qualquer destino que você possa alcançar usando os produtos de conectividade híbrida do Google (Cloud VPN ou Cloud Interconnect) e que possa ser alcançado com uma combinação IP:Port válida pode ser configurado como um endpoint para o balanceador de carga.

    Configure os back-ends que não são do Google Cloud da seguinte maneira:

    1. Adicione cada combinação de IP:Port do endpoint da rede que não seja do Google Cloud a um grupo de endpoints de rede (NEG) de conectividade híbrida. Verifique se esse endereço IP e porta podem ser acessados pelo Google Cloud usando conectividade híbrida (pelo Cloud VPN ou pelo Cloud Interconnect). Para conectividade híbrida, defina o tipo de endpoint de rede como NON_GCP_PRIVATE_IP_PORT.
    2. Ao criar o NEG, especifique uma zona do Google Cloud que minimiza a distância geográfica entre o Google Cloud e o ambiente local ou de outra nuvem. Por exemplo, se você estiver hospedando um serviço em um ambiente local em Frankfurt, na Alemanha, será possível especificar a zona europe-west3-a do Google Cloud ao criar o NEG.

    3. Adicione este NEG de conectividade híbrida como um back-end para o serviço de back-end.

      Um NEG de conectividade híbrida só pode incluir endpoints que não são do Google Cloud. O tráfego poderá ser descartado se um NEG híbrido incluir endpoints para recursos em uma rede VPC do Google Cloud, como endereços IP de regra de encaminhamento para balanceadores de carga de rede de passagem interna. Configure os endpoints do Google Cloud conforme indicado na próxima seção.

  • Back-ends do Google Cloud

    Configure os endpoints do Google Cloud da seguinte maneira:

    1. Crie um serviço de back-end separado para os back-ends do Google Cloud.
    2. Configure vários back-ends (NEGs zonais GCE_VM_IP_PORT ou grupos de instâncias) na mesma região em que você configurou a conectividade híbrida.

Pontos adicionais a serem considerados:

  • Cada NEG de conectividade híbrida só pode conter endpoints de rede do mesmo tipo (NON_GCP_PRIVATE_IP_PORT).

  • É possível usar um único serviço de back-end para fazer referência a back-ends baseados no Google Cloud (usando NEGs zonais com endpoints GCE_VM_IP_PORT) e back-ends locais ou de outras nuvens (usando NEGs de conectividade híbrida com endpoints NON_GCP_PRIVATE_IP_PORT). Nenhuma outra combinação de tipos de back-end mistos é permitida. O Traffic Director não é compatível com tipos de back-end mistos em um serviço de back-end.

  • O esquema de balanceamento de carga do serviço de back-end precisa ser um dos seguintes:

    • EXTERNAL_MANAGED para balanceadores de carga de aplicativo globais externos, balanceadores de carga de aplicativo regionais externos, balanceadores de carga de rede de proxy externo global e balanceadores de carga de rede de proxy externo regionais
    • EXTERNAL para balanceadores de carga de aplicativo clássicos e balanceadores de carga de proxy clássicos
    • INTERNAL_MANAGED para balanceadores de carga de aplicativo internos, balanceador de carga de rede de proxy interno entre regiões, balanceadores de carga de rede de proxy interno entre regiões e balanceadores de carga de rede de proxy interno regional

    INTERNAL_SELF_MANAGED é compatível com implantações de vários ambientes do Traffic Director com NEGs de conectividade híbrida.

  • O protocolo de serviço de back-end precisa ser HTTP, HTTPS ou HTTP2 para os balanceadores de carga de aplicativo e TCP ou SSL para os balanceadores de carga de rede de proxy externos e os balanceadores de carga de rede de proxy internos regionais. Para ver a lista de protocolos de serviço de back-end compatíveis com cada balanceador de carga, consulte Protocolos do balanceador de carga para o back-end.

  • O modo de balanceamento do back-end de NEG híbrido precisa ser RATE para balanceadores de carga de aplicativo internos e externos e CONNECTION para balanceadores de carga de rede de proxy internos regionais e balanceadores de carga de rede de proxy externos. Para detalhes sobre os modos de balanceamento, consulte Visão geral dos serviços de back-end.

  • Para adicionar mais endpoints de rede, atualize os back-ends anexados ao serviço de back-end.

  • Se você estiver usando verificações de integridade distribuídas do Envoy com NEGS de conectividade híbrida zonal (ou seja, NON_GCP_PRIVATE_IP_PORT) por trás de balanceadores de carga baseados no Envoy, não configure a mesma rede em vários NEGs anexados a um serviço de back-end. Isso resulta em um comportamento indefinido.

Verificações de integridade centralizadas

As verificações de integridade centralizadas, ao usar NEGs híbridos, são necessárias para balanceadores de carga de aplicativo externos globais, balanceadores de carga de aplicativo clássicos, balanceadores de carga de rede de proxy externo global e balanceadores de carga de rede de proxy clássico. Outros balanceadores de carga baseados no Envoy usam verificações de integridade distribuídas do Envoy, conforme descrito na seção a seguir.

Para endpoints NON_GCP_PRIVATE_IP_PORT fora do Google Cloud, crie regras de firewall no local e nas redes em nuvem. Para fazer isso, entre em contato com o administrador da rede. O Cloud Router usado para conectividade híbrida também precisa divulgar os intervalos usados pelas sondagens do Google. Os intervalos a serem divulgados são 35.191.0.0/16 e 130.211.0.0/22.

Para outros tipos de back-ends no Google Cloud, crie regras de firewall conforme demonstrado neste exemplo.

Documentação relacionada:

Verificações de integridade distribuídas do Envoy

A configuração da verificação de integridade varia de acordo com o tipo de balanceador de carga:

  • Balanceador de carga de aplicativo externo global, balanceador de carga de aplicativo clássico, balanceador de carga de rede de proxy externo global e balanceador de carga de rede de proxy clássico. Estes balanceadores não têm suporte para as verificações de integridade distribuídas do Envoy. Eles ainda usam o mecanismo centralizado do Google, conforme descrito na seção Verificações de integridade centralizadas.

  • Balanceador de carga de aplicativo externo regional, balanceador de carga de aplicativo interno (entre regiões e regional), balanceador de carga de rede de proxy externo regional, balanceador de carga de rede de proxy interno entre regiões e balanceador de carga de rede de proxy interno regional. Esses balanceadores de carga usam verificações de integridade do Envoy distribuídas para conferir a integridade dos NEGs híbridos. As sondagens de verificação de integridade se originam do próprio software de proxy Envoy. Cada serviço de back-end precisa estar associado a uma verificação de integridade que verifique a integridade dos back-ends. As sondagens de verificação de integridade são originadas dos proxies Envoy na sub-rede somente proxy da região. Para que as sondagens da verificação de integridade funcionem corretamente, crie regras de firewall no ambiente externo que permitam que o tráfego da sub-rede somente proxy alcance seus back-ends externos.

    Para endpoints NON_GCP_PRIVATE_IP_PORT fora do Google Cloud, crie regras de firewall no local e nas redes em nuvem. Para fazer isso, entre em contato com o administrador da rede. O Cloud Router usado para conectividade híbrida também precisa divulgar o intervalo da sub-rede somente proxy da região.

As verificações de integridade do Envoy distribuídas são criadas usando os mesmos processos do console do Google Cloud, da CLI gcloud e da API que as verificações de integridade centralizadas. Nenhuma outra configuração é necessária.

Observações:

  • As verificações de integridade do gRPC não são suportadas.
  • As verificações de integridade com o protocolo PROXY v1 ativado não são suportadas.
  • Se você usa NEGs mistos em que um único serviço de back-end tem uma combinação de NEGs zonais (endpoints GCE_VM_IP_PORT no Google Cloud) e NEGs híbridos (endpoints NON_GCP_PRIVATE_IP_PORT fora do Google Cloud), configure regras de firewall para autorizar o tráfego de Intervalos de IP da sondagem de verificação de integridade do Google (130.211.0.0/22 e 35.191.0.0/16) a alcançar os endpoints dos NEGs zonais no Google Cloud. Isso ocorre porque os NEGs zonais usam o sistema centralizado de verificação de integridade do Google.

  • Como o plano de dados do Envoy processa verificações de integridade, não é possível usar o console do Google Cloud, a API ou a CLI gcloud para verificar o status de integridade desses endpoints externos. Nos NEGs híbridos com balanceadores de carga baseados no Envoy, o console do Google Cloud mostra o status da verificação de integridade como N/A. Isso já era esperado.

  • Cada proxy Envoy atribuído à sub-rede somente proxy da região na rede VPC inicia verificações de integridade de maneira independente. Portanto, talvez você perceba um aumento no tráfego de rede devido a uma verificação de integridade. O aumento depende do número de proxies Envoy atribuídos à sua rede VPC em uma região, da quantidade de tráfego recebida por esses proxies e do número de endpoints que cada proxy Envoy precisa verificar. Na pior das hipóteses, o tráfego de rede aumenta a uma taxa quadrática (O(n^2)) devido às verificações.

  • Os registros das verificações de integridade distribuídas do Envoy não incluem estados de integridade detalhados. Para detalhes sobre o que é registrado, consulte Geração de registros de verificação de integridade. Para uma melhor resolução de problemas de conectividade via proxies do Envoy com os endpoints do NEG, verifique também os respectivos registros do balanceador de carga.

Documentação relacionada:

Limitações

  • O Cloud Router usado para conectividade híbrida precisa ser ativado com o roteamento dinâmico global. O roteamento dinâmico regional e as rotas estáticas não são compatíveis.
  • Para os balanceadores de carga regionais baseados no Envoy (balanceadores de carga de aplicativo externos regionais, balanceadores de carga de rede de proxy externos regionais, balanceadores de carga de rede de proxy internos regionais e balanceador de carga de aplicativo internos), a conectividade híbrida precisa estar configurada na mesma região do balanceador de carga. Se eles estiverem configurados em regiões diferentes, você verá back-ends como íntegros, mas as solicitações do cliente não serão encaminhadas para os back-ends.

  • As considerações para conexões criptografadas do balanceador de carga para os back-ends documentados aqui também se aplicam aos endpoints de back-end que não são do Google Cloud configurados no NEG de conectividade híbrida.

    Verifique também as configurações de segurança da sua configuração de conectividade híbrida. Atualmente, as conexões da VPN de alta disponibilidade são criptografadas por padrão (IPSec). As conexões do Cloud Interconnect não são criptografadas por padrão. Para mais detalhes, consulte o artigo sobre criptografia em trânsito.

Geração de registros

As solicitações encaminhadas por proxy para um endpoint em um NEG híbrido são registradas no Cloud Logging da mesma forma que as solicitações de outros back-ends. Se você ativar o Cloud CDN para o balanceador de carga de aplicativo externo global, as ocorrências em cache também serão registradas.

Veja mais informações em:

Cota

É possível configurar quantos NEGs híbridos com endpoints de rede conforme forem permitidos pela cota de grupo de endpoints de rede existente. Para mais informações, consulte Back-ends de NEG e Endpoints por NEG.

A seguir