Vista geral dos grupos de pontos finais de rede de conetividade híbrida

O Cloud Load Balancing suporta o tráfego de balanceamento de carga para pontos finais que se estendem além Google Cloud, como centros de dados nas instalações e outras nuvens públicas que pode usar a conetividade híbrida para alcançar.

Uma estratégia híbrida é uma solução pragmática para se adaptar às exigências do mercado em constante mudança e modernizar as suas aplicações de forma incremental. Esta pode ser uma implementação híbrida temporária para permitir a migração para uma solução moderna baseada na nuvem ou uma funcionalidade permanente da infraestrutura de TI da sua organização.

A configuração do balanceamento de carga híbrido também lhe permite usufruir das vantagens das capacidades de rede do Cloud Load Balancing para serviços executados na sua infraestrutura existente fora do Google Cloud.

O balanceamento de carga híbrido é suportado nos seguintes Google Cloud balanceadores de carga:

Os serviços no local e outros serviços na nuvem são tratados como qualquer outro back-end do Cloud Load Balancing. A principal diferença é que usa um NEG de conetividade híbrida para configurar os pontos finais destes back-ends. Os pontos finais têm de ser combinações IP:portválidas que o balanceador de carga pode alcançar através de produtos de conetividade híbrida, como o Cloud VPN, o Cloud Interconnect ou as VMs do dispositivo de encaminhamento.

Exemplo de utilização: encaminhar tráfego para uma localização nas instalações ou outra nuvem

O exemplo de utilização mais simples de NEGs híbridos é o encaminhamento de tráfego de um Google Cloud equilibrador de carga para uma localização no local ou para outro ambiente de nuvem. Os clientes podem originar tráfego a partir da Internet pública, a partir de Google Cloudou a partir de um cliente no local.

Clientes públicos

Pode usar um Application Load Balancer externo com um back-end de NEG híbrido para encaminhar o tráfego de clientes externos para um back-end no local ou noutra rede na nuvem. Também pode ativar as seguintes capacidades de rede de valor acrescentado para os seus serviços nas instalações ou noutras redes de nuvem:

  • Com o balanceador de carga de aplicações externo global e o balanceador de carga de aplicações clássico, pode:

    • Use a infraestrutura global de limite da Google para terminar as ligações dos utilizadores mais perto do utilizador, diminuindo assim a latência.
    • Proteja o seu serviço com o Google Cloud Armor, um produto de segurança de defesa contra DDoS/WAF de limite disponível para todos os serviços acedidos através de um Application Load Balancer externo.
    • Ative o seu serviço para otimizar o fornecimento através do Cloud CDN. Com o Cloud CDN, pode colocar conteúdo em cache perto dos seus utilizadores. A RFC de multimédia na nuvem oferece capacidades como a invalidação da cache e URLs assinados da RFC de multimédia na nuvem.
    • Use certificados SSL geridos pela Google. Pode reutilizar certificados e chaves privadas que já usa para outros Google Cloud produtos. Isto elimina a necessidade de gerir certificados separados.

    O diagrama seguinte demonstra uma implementação híbrida com um Application Load Balancer externo.

    Conetividade híbrida com um Application Load Balancer externo global.
    Conetividade híbrida com um Application Load Balancer externo global (clique para aumentar).

    Neste diagrama, o tráfego de clientes na Internet pública entra na sua rede privada no local ou na nuvem através de um balanceador de carga, como o Application Load Balancer externo. Google Cloud Quando o tráfego atinge o balanceador de carga, pode aplicar serviços de limite de rede, como a proteção contra DDoS do Cloud Armor ou a autenticação de utilizadores do Identity-Aware Proxy (IAP).

  • Com o balanceador de carga de aplicações externo regional, pode encaminhar o tráfego externo para pontos finais que se encontram na mesma Google Cloud região que os recursos do balanceador de carga. Use este equilibrador de carga se precisar de publicar conteúdo a partir de apenas uma geolocalização (por exemplo, para cumprir os regulamentos de conformidade) ou se quiser usar o nível do serviço de rede padrão.

O modo como o pedido é encaminhado (se para um Google Cloud back-end ou para um ponto final no local/na nuvem) depende da forma como o mapa de URLs está configurado. Consoante o seu mapa de URLs, o balanceador de carga seleciona um serviço de back-end para o pedido. Se o serviço de back-end selecionado tiver sido configurado com um NEG de conetividade híbrida (usado apenas para pontos finais não pertencentes ao Google Cloud), o balanceador de carga encaminha o tráfego através da VPN do Google Cloud, do Cloud Interconnect ou das VMs do dispositivo Router para o destino externo pretendido.Google Cloud

Clientes internos (na rede Google Cloud ou no local)

Também pode configurar uma implementação híbrida para clientes internos à Google Cloud. Neste caso, o tráfego do cliente tem origem na Google Cloud rede VPC, na sua rede nas instalações ou noutra nuvem, e é encaminhado para pontos finais nas instalações ou noutras redes na nuvem.

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

O diagrama seguinte demonstra uma implementação híbrida com um Application Load Balancer interno regional.

Conetividade híbrida com balanceadores de carga de aplicações internos regionais.
Conetividade híbrida com equilibradores de carga de aplicações internos regionais (clique para aumentar).

Exemplo de utilização: migrar para a nuvem

A migração de um serviço existente para a nuvem permite-lhe libertar capacidade no local e reduzir o custo e o encargo da manutenção da infraestrutura no local. Pode configurar temporariamente uma implementação híbrida que lhe permita encaminhar tráfego para o seu serviço no local atual e para umGoogle Cloud ponto final de serviço correspondente.

O diagrama seguinte demonstra esta configuração com um Application Load Balancer interno.

Migre para Google Cloud.
Migrar para Google Cloud (clique para aumentar).

Se estiver a usar um Application Load Balancer interno para processar clientes internos, pode configurar o Google Cloud balanceador de carga para usar a divisão de tráfego com base no peso para dividir o tráfego entre os dois serviços. A divisão de tráfego permite-lhe começar por enviar 0% do tráfego para o serviço Google Cloud e 100% para o serviço local. Em seguida, pode aumentar gradualmente a proporção de tráfego enviado para o serviço Google Cloud . Eventualmente, envia 100% do tráfego para o serviço Google Cloud e pode desativar o serviço no local.

Arquitetura híbrida

Esta secção descreve a arquitetura de balanceamento de carga e os recursos necessários para configurar uma implementação de balanceamento de carga híbrido.

Os serviços no local e outros serviços na nuvem são como qualquer outro back-end do Cloud Load Balancing. A principal diferença é que usa um NEG de conetividade híbrida para configurar os pontos finais destes back-ends. Os pontos finais têm de ser combinações IP:portválidas que os seus clientes podem alcançar através da conetividade híbrida, como o Cloud VPN, o Cloud Interconnect ou uma VM de dispositivo de router.

Os diagramas seguintes mostram os Google Cloud recursos necessários para ativar o balanceamento de carga híbrido para balanceadores de carga de aplicações externos e balanceadores de carga de aplicações internos regionais.

HTTP(S) externo global

Recursos do balanceador de carga de aplicações externo global para conetividade híbrida.
Recursos do Application Load Balancer externo global para conectividade híbrida (clique para aumentar).

HTTP(S) externo regional

Recursos do Application Load Balancer externo regional para conetividade híbrida.
Recursos do balanceador de carga de aplicações externo regional para conetividade híbrida (clique para aumentar).

HTTP(S) interno regional

Recursos do balanceador de carga de aplicações interno regional para conetividade híbrida.
Recursos do balanceador de carga de aplicações interno regional para conetividade híbrida (clique para aumentar).

Proxy interno regional

Recursos do balanceador de carga de rede de proxy interno regional para conetividade híbrida.
Recursos do Network Load Balancer de proxy interno regional para conetividade híbrida (clique para aumentar).

Regional versus global

O encaminhamento do Cloud Load Balancing depende do âmbito do equilibrador de carga configurado:

Balanceador de carga de aplicações externo e balanceador de carga de rede de proxy externo. Estes equilibradores de carga podem ser configurados para encaminhamento global ou regional, consoante o nível de rede usado. Cria o back-end do NEG híbrido do balanceador de carga na mesma rede e região onde a conetividade híbrida foi configurada. Os pontos finais que não sejamGoogle Cloud também têm de ser configurados em conformidade para tirar partido do equilíbrio de carga baseado na proximidade.

Balanceador de carga de aplicações interno entre regiões e balanceador de carga de rede de proxy interno entre regiões. Este é um balanceador de carga multirregião que pode equilibrar a carga do tráfego para serviços de back-end distribuídos globalmente. Cria o back-end do NEG híbrido do balanceador de carga na mesma rede e região onde a conetividade híbrida foi configurada. Os pontos finais que não sejamGoogle Cloud também têm de ser configurados em conformidade para tirar partido do equilíbrio de carga baseado na proximidade.

Balanceador de carga de aplicações interno regional e balanceador de carga de rede de proxy interno regional. Estes são balanceadores de carga regionais. Ou seja, só podem encaminhar tráfego para pontos finais na mesma região que o balanceador de carga. Os componentes do equilibrador de carga têm de ser configurados na mesma região onde a conetividade híbrida foi configurada. Por predefinição, os clientes que acedem ao balanceador de carga também têm de estar na mesma região. No entanto, se ativar o acesso global, os clientes de qualquer região podem aceder ao balanceador de carga.

Por exemplo, se o gateway da Cloud VPN ou a associação de VLAN do Cloud Interconnect estiver configurada em REGION_A, os recursos necessários pelo balanceador de carga (como um serviço de back-end, um NEG híbrido ou uma regra de encaminhamento) têm de ser criados na região REGION_A. Por predefinição, os clientes que acedem ao balanceador de carga também têm de estar na região REGION_A. No entanto, se ativar o acesso global, os clientes de qualquer região podem aceder ao balanceador de carga.

Requisitos de conetividade de rede

Antes de configurar uma implementação de equilíbrio de carga híbrido, tem de ter os seguintes recursos configurados:

  • Google Cloud Rede da VPC. Uma rede VPC configurada no interior de Google Cloud. Esta é a rede VPC usada para configurar o Cloud Interconnect/Cloud VPN e o Cloud Router. Esta é também a mesma rede onde cria os recursos de balanceamento de carga (regra de encaminhamento, proxy de destino, serviço de back-end, etc.). Os endereços IP no local, noutra nuvem e Google Cloud os intervalos de endereços IP e os endereços IP de sub-rede não podem sobrepor-se. Quando os endereços IP se sobrepõem, os encaminhamentos de sub-rede têm prioridade sobre a conetividade remota.

  • Conetividade híbrida. Os seus Google Cloud e os ambientes nas instalações ou noutras nuvens têm de estar ligados através de conetividade híbrida, usando anexos de VLAN do Cloud Interconnect, túneis do Cloud VPN com o Cloud Router ou VMs do dispositivo de router. Recomendamos que use uma ligação de alta disponibilidade. Um Cloud Router ativado com encaminhamento dinâmico global sabe mais sobre o ponto final específico através do BGP e programa-o na sua Google Cloud rede VPC. O encaminhamento dinâmico regional não é suportado. As rotas estáticas também não são suportadas.

    O Cloud Interconnect/Cloud VPN/dispositivo de router tem de ser configurado na mesma rede VPC que pretende usar para a implementação do balanceamento de carga híbrido. O Cloud Router também tem de anunciar as seguintes rotas ao seu ambiente no local:

    • Intervalos usados pelas sondas de verificação de funcionamento da Google: 35.191.0.0/16 e 130.211.0.0/22. Isto é necessário para os balanceadores de carga de aplicações externos globais, os balanceadores de carga de aplicações clássicos, os balanceadores de carga de rede de proxy externos globais e os balanceadores de carga de rede de proxy clássicos.

    • O intervalo da sub-rede só de proxy da região: para balanceadores de carga baseados no Envoy: balanceadores de carga de aplicações externos regionais, balanceadores de carga de aplicações internos regionais, balanceadores de carga de aplicações internos entre regiões, balanceadores de carga de rede de proxy externos regionais, balanceadores de carga de rede de proxy internos entre regiões e balanceadores de carga de rede de proxy internos regionais.

      A sub-rede apenas de proxy da região de publicidade também é necessária para que as verificações de funcionamento do Envoy distribuído funcionem. A verificação de funcionamento do Envoy distribuído é o mecanismo de verificação de funcionamento predefinido para NEGs de conetividade híbrida zonal (ou seja, pontos finais NON_GCP_PRIVATE_IP_PORT) atrás de balanceadores de carga baseados no Envoy.

    Pode usar a mesma rede ou uma rede VPC diferente no mesmo projeto para configurar a rede híbrida (Cloud Interconnect ou Cloud VPN) e o balanceador de carga. Tenha em conta o seguinte:

    • Se usar redes VPC diferentes, as duas redes têm de estar ligadas através do peering de redes VPC ou têm de ser raios VPC no mesmo hub do Network Connectivity Center.

    • Se usar a mesma rede VPC, certifique-se de que os intervalos CIDR da sub-rede da rede VPC não entram em conflito com os intervalos CIDR remotos. Quando os endereços IP se sobrepõem, os caminhos de sub-rede têm prioridade sobre a conetividade remota.

  • Pontos finais de rede (IP:Port) nas instalações ou noutras nuvens. Um ou mais pontos finais de rede IP:Port configurados nos seus ambientes nas instalações ou noutra nuvem, encaminháveis através do Cloud Interconnect, do Cloud VPN ou de uma VM de dispositivo de encaminhamento. Se existirem vários caminhos para o ponto final de IP, o encaminhamento segue o comportamento descrito na vista geral dos encaminhamentos de VPC e na vista geral do Cloud Router.

  • Regras de firewall nas suas instalações ou noutra nuvem. As seguintes regras de firewall têm de ser criadas no seu ambiente nas instalações ou noutro ambiente na nuvem:

    • Regras de firewall de permissão de entrada para permitir o tráfego das sondas de verificação de estado da Google para os seus pontos finais. Os intervalos a permitir são: 35.191.0.0/16 e 130.211.0.0/22. Tenha em atenção que estes intervalos também têm de ser anunciados pelo Cloud Router à sua rede no local. Para mais detalhes, consulte os Intervalos de IPs de sondagem e as regras de firewall.
    • Regras de firewall de permissão de entrada para permitir que o tráfego que está a ser equilibrado em carga alcance os pontos finais.
    • Para balanceadores de carga baseados no Envoy: balanceadores de carga de aplicações externos regionais, balanceadores de carga de aplicações internos regionais, balanceadores de carga de aplicações internos entre regiões,balanceadores de carga de rede de proxy externos regionais, balanceador de carga de rede de proxy interno entre regiões e balanceadores de carga de rede de proxy internos regionais, também tem de criar uma regra de firewall para permitir que o tráfego da sub-rede apenas de proxy da região alcance os pontos finais que estão no local ou noutros ambientes de nuvem.

Componentes do balanceador de carga

Consoante o tipo de equilibrador de carga, pode configurar uma implementação de equilíbrio de carga híbrido através dos níveis de serviço de rede Standard ou Premium.

Um balanceador de carga híbrido requer uma configuração especial apenas para o serviço de back-end. A configuração da interface é igual à de qualquer outro balanceador de carga. Os balanceadores de carga baseados no Envoy, ou seja, os balanceadores de carga de aplicações externos regionais, os balanceadores de carga de aplicações internos regionais, os balanceadores de carga de aplicações internos entre regiões, os balanceadores de carga de rede de proxy externos regionais, o balanceador de carga de rede de proxy interno entre regiões e os balanceadores de carga de rede de proxy internos regionais, requerem uma sub-rede apenas de proxy para executar proxies do Envoy em seu nome.

Configuração da interface

Não é necessária nenhuma configuração especial do front-end para o equilíbrio de carga híbrido. As regras de encaminhamento são usadas para encaminhar o tráfego por endereço IP, porta e protocolo para um proxy de destino. Em seguida, o target_proxy termina as ligações dos clientes.

Os mapas de URLs são usados pelos balanceadores de carga de HTTP(S) para configurar o encaminhamento baseado em URL de pedidos para os serviços de back-end adequados.

Para mais detalhes sobre cada um destes componentes, consulte as secções de arquitetura das descrições gerais específicas do equilibrador 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 num serviço de back-end para direcionar o tráfego recebido para um ou mais back-ends anexados.

Para configurar uma implementação de balanceamento de carga híbrido, configura o balanceador de carga com back-ends que estão dentro Google Cloud, bem como fora Google Cloud.

  • Back-ends nãoGoogle Cloud (no local ou noutra nuvem)

    Qualquer destino que possa alcançar através dos produtos de conetividade híbrida da Google (Cloud VPN ou Cloud Interconnect ou VMs de dispositivo de encaminhamento) e que possa ser alcançado com uma combinação IP:Port válida, pode ser configurado como um ponto final para o equilibrador de carga.

    Configure os seus back-ends nãoGoogle Cloud da seguinte forma:

    1. Adicione a combinação deGoogle Cloud pontos finais que não sejam de redeIP:Port de cada instância a um grupo de pontos finais da rede (NEG) de conetividade híbrida. Certifique-se de que este endereço IP e porta são acessíveis a partir de Google Cloud através da conetividade híbrida (através do Cloud VPN ou do Cloud Interconnect ou das VMs do dispositivo de encaminhamento). Para os NEGs de conetividade híbrida, define o tipo de ponto final de rede como NON_GCP_PRIVATE_IP_PORT.
    2. Ao criar o NEG, especifique uma Google Cloud zona que minimize a distância geográfica entre Google Cloud e o seu ambiente nas instalações ou noutra nuvem. Por exemplo, se estiver a alojar um serviço num ambiente no local em Frankfurt, na Alemanha, pode especificar a zona europe-west3-a Google Cloud quando criar o NEG.

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

      Um NEG de conetividade híbrida só pode incluir pontos finais nãoGoogle Cloud O tráfego pode ser ignorado se um NEG híbrido incluir pontos finais para recursos numa rede VPC, como endereços IP de regras de encaminhamento para equilibradores de carga de rede de passagem interna. Google Cloud Configure os Google Cloud pontos finais conforme indicado na secção seguinte.

  • Google Cloud backends

    Configure os seus Google Cloud pontos finais da seguinte forma:

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

Pontos adicionais a considerar:

  • Cada NEG de conetividade híbrida só pode conter pontos finais de rede do mesmo tipo (NON_GCP_PRIVATE_IP_PORT).

  • Pode usar um único serviço de back-end para referenciar back-ends baseados emGoogle Cloud(usando NEGs zonais com pontos finais GCE_VM_IP_PORT) e back-ends no local ou noutra nuvem (usando NEGs de conetividade híbrida com pontos finais NON_GCP_PRIVATE_IP_PORT). Não é permitida nenhuma outra combinação de tipos de back-end mistos. O Cloud Service Mesh não suporta tipos de back-end mistos num único serviço de back-end.

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

    • EXTERNAL_MANAGED para balanceadores de carga de aplicações externos globais, balanceadores de carga de aplicações externos regionais, balanceadores de carga de rede de proxy externos globais e balanceadores de carga de rede de proxy externos regionais

    • EXTERNAL para balanceadores de carga de aplicações clássicos e balanceadores de carga de rede de proxy clássicos

    • INTERNAL_MANAGED para balanceadores de carga de aplicações internos e balanceadores de carga de rede de proxy internos

    INTERNAL_SELF_MANAGED é suportado para implementações de vários ambientes do Cloud Service Mesh com grupos de pontos finais de rede (NEGs) de conetividade híbrida.

  • O protocolo de serviço de back-end tem de ser HTTP, HTTPS ou HTTP2 para os balanceadores de carga de aplicações e TCP ou SSL para os balanceadores de carga de rede de proxy. Para ver a lista de protocolos de serviço de back-end suportados por cada balanceador de carga, consulte o artigo Protocolos do balanceador de carga para o back-end.

  • O modo de balanceamento do back-end do NEG híbrido tem de ser RATE para balanceadores de carga de aplicações e CONNECTION para balanceadores de carga de rede de proxy. Para ver detalhes sobre os modos de balanceamento, consulte a vista geral dos serviços de back-end.

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

  • Se estiver a usar verificações de estado do Envoy distribuídas com back-ends de NEG de conetividade híbrida (suportados apenas para balanceadores de carga baseados no Envoy), certifique-se de que configura pontos finais de rede únicos para todos os NEGs anexados ao mesmo serviço de back-end. Adicionar o mesmo ponto final de rede a vários NEGs resulta num comportamento indefinido.

Verificações de funcionamento centralizadas

As verificações de funcionamento centralizadas, quando usa NEGs híbridos, são necessárias para balanceadores de carga de aplicações externos globais, balanceadores de carga de aplicações clássicos, balanceadores de carga de rede de proxy externos globais e balanceadores de carga de rede de proxy clássicos. Outros balanceadores de carga baseados no Envoy usam verificações de funcionamento do Envoy distribuídas, conforme descrito na secção seguinte.

Para os pontos finais NON_GCP_PRIVATE_IP_PORTfora Google Cloud, crie regras de firewall nas suas instalações e noutras redes de nuvem. Contacte o seu administrador de rede para o fazer. O Cloud Router usado para a conetividade híbrida também tem de anunciar os intervalos usados pelas sondas de verificação do estado da Google. Os intervalos a anunciar 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 no Google Cloud , conforme demonstrado neste exemplo.

Documentação relacionada:

Verificações de funcionamento do Envoy distribuídas

A configuração da verificação de funcionamento varia consoante o tipo de balanceador de carga:

  • Balanceador de carga de aplicações externo global, balanceador de carga de aplicações clássico, balanceador de carga de rede de proxy externo global e balanceador de carga de rede de proxy clássico. Estes balanceadores de carga não suportam verificações de estado do Envoy distribuídas. Usam o mecanismo de verificação do estado de funcionamento centralizado da Google, conforme descrito na secção Verificações do estado de funcionamento centralizadas.

  • Balanceador de carga de aplicações externo regional, balanceador de carga de aplicações interno regional, balanceador de carga de rede de proxy externo regional, balanceador de carga de rede de proxy interno regional , balanceador de carga de rede de proxy interno entre regiões e balanceador de carga de aplicações interno entre regiões. Estes balanceadores de carga usam verificações de funcionamento do Envoy distribuídas para verificar o funcionamento dos NEGs híbridos. As sondas de verificação de funcionamento têm origem no próprio software do proxy Envoy. Cada serviço de back-end tem de estar associado a uma verificação de funcionamento que verifique o funcionamento dos back-ends. As sondas de verificação de estado têm origem nos proxies Envoy na sub-rede apenas de proxy na região. Para que as sondas de verificação de estado funcionem corretamente, tem de criar regras de firewall no ambiente externo que permitam que o tráfego da sub-rede só de proxy alcance os seus back-ends externos.

    Para os NON_GCP_PRIVATE_IP_PORTpontos finais externos Google Cloud, tem de criar estas regras de firewall nas suas redes no local e noutras nuvens. Contacte o administrador da rede para tal. O Cloud Router que usa para a conetividade híbrida também tem de anunciar o intervalo de sub-rede apenas de proxy da região.

As verificações de funcionamento do Envoy distribuídas são criadas através dos mesmos Google Cloud processos da consola, da CLI gcloud e da API que as verificações de funcionamento centralizadas. Não é necessária nenhuma outra configuração.

Aspetos a ter em conta:

  • As verificações de estado gRPC não são suportadas.
  • As verificações de estado com o protocolo PROXY v1 ativado não são suportadas.
  • Se usar NEGs mistos em que um único serviço de back-end tem uma combinação de NEGs zonais (GCE_VM_IP_PORT pontos finais dentro de Google Cloud) e NEGs híbridos (NON_GCP_PRIVATE_IP_PORT pontos finais fora de Google Cloud), tem de configurar regras de firewall para permitir o tráfego de intervalos de IP de sondagem de verificação de estado da Google (130.211.0.0/22 e 35.191.0.0/16) para os pontos finais de NEG zonais em Google Cloud. Isto deve-se ao facto de os NEGs zonais usarem o sistema de verificação de estado centralizado da Google.

  • Uma vez que o plano de dados do Envoy processa as verificações de estado, não pode usar a Google Cloud consola, a API nem a CLI gcloud para verificar o estado de funcionamento destes pontos finais externos. Para NEGs híbridos com balanceadores de carga baseados no Envoy, a consola mostra o estado da verificação de funcionamento como N/A. Google Cloud Isto é normal.

  • Cada proxy Envoy atribuído à sub-rede apenas de proxy na região na rede VPC inicia verificações de estado de funcionamento de forma independente. Por conseguinte, pode verificar um aumento no tráfego de rede devido à verificação do estado. O aumento depende do número de proxies Envoy atribuídos à sua rede VPC numa região, da quantidade de tráfego recebido por estes proxies e do número de pontos finais que cada proxy Envoy tem de verificar o estado. No pior dos cenários, o tráfego de rede devido às verificações de estado aumenta a uma taxa (O(n^2)) quadrática.

  • Os registos de verificações de funcionamento para verificações de funcionamento do Envoy distribuídas não incluem estados de funcionamento detalhados. Para ver detalhes sobre o que é registado, consulte o artigo Registo de verificação de estado. Para resolver problemas de conetividade dos proxies Envoy para os seus pontos finais do NEG, também deve verificar os registos do equilibrador de carga respetivo.

Documentação relacionada:

Limitações

  • O Cloud Router usado para a conetividade híbrida tem de estar ativado com a rotagem dinâmica global. O encaminhamento dinâmico regional e as rotas estáticas não são suportados.
  • Para os balanceadores de carga regionais baseados no Envoy (balanceadores de carga de aplicações 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 aplicações internos regionais), a conetividade híbrida tem de ser configurada na mesma região que o balanceador de carga. Se estiverem configurados em regiões diferentes, pode ver os back-ends como estando em bom estado, mas os pedidos de clientes não são encaminhados para os back-ends.

  • As considerações para ligações encriptadas do balanceador de carga aos servidores de back-end documentadas aqui também se aplicam a pontos finais deGoogle Cloud back-end não configurados no NEG de conetividade híbrida.

    Certifique-se de que também revê as definições de segurança na configuração de conetividade híbrida. As ligações de VPN de alta disponibilidade são encriptadas por predefinição (IPsec). As ligações do Cloud Interconnect não estão encriptadas por predefinição. Para mais detalhes, consulte o documento técnico Encriptação em trânsito.

Registo

Os pedidos enviados por proxy para um ponto final num NEG híbrido são registados no Cloud Logging da mesma forma que os pedidos para outros back-ends. Se ativar o Cloud CDN para o seu Application Load Balancer externo global, os resultados positivos da cache também são registados.

Para mais informações, consulte:

Quota

Pode configurar o número de NEGs híbridos com pontos finais de rede permitidos pela quota de grupos de pontos finais de rede existente. Para mais informações, consulte os artigos Back-ends do NEG e Pontos finais por NEG.

O que se segue?