Algumas ou todas as informações nesta página podem não se aplicar à nuvem confiável da S3NS.

Esta página foi traduzida pela API Cloud Translation.

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 Trusted Cloud by S3NS, 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 Trusted Cloud.

O balanceamento de carga híbrido é compatível com os seguintes Trusted Cloud by S3NS balanceadores de carga:

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, o Cloud Interconnect ou as VMs de dispositivo roteador.

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 doTrusted Cloud para um local ou para outro ambiente de nuvem. Os clientes podem originar o tráfego da Internet pública, do Trusted Cloudou 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 regional, é possível rotear o tráfego externo para endpoints que estão na mesma Trusted Cloud região 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 compliance) ou se quiser usar o nível de serviço de rede Standard.

A maneira como a solicitação é encaminhada (para um back-end Trusted 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ãoTrusted Cloud ), o balanceador de carga encaminhará o tráfego pelo Cloud VPN, Cloud Interconnect ou VMs do dispositivo roteador para o destino externo pretendido.

Clientes internos (no Trusted Cloud ou no local)

Também é possível configurar uma implantação híbrida para clientes internos do Trusted Cloud. Nesse caso, o tráfego do cliente se origina da rede VPCTrusted 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 é regional, o que significa que ele só pode rotear tráfego para endpoints na mesma região Trusted Cloud que os recursos do balanceador de carga.

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 Trusted Cloud correspondente.

Se você estiver usando um balanceador de carga de aplicativo interno para lidar com clientes internos, configure o Trusted Cloud balanceador de carga 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 Trusted 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 Trusted Cloud . Em algum momento, você enviará 100% do tráfego para o serviço Trusted 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, o Cloud Interconnect ou uma VM de dispositivo roteador.

Os diagramas a seguir mostram os recursos do Trusted Cloud necessários para ativar o balanceamento de carga híbrido.

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

Roteamento do Cloud Load Balancing

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

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.

Por exemplo, se o gateway da VPN do Cloud ou o anexo da VLAN do Cloud Interconnect estiverem configurados em REGION_A, 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 REGION_A. Por padrão, os clientes que acessam o balanceador de carga também precisam estar na região REGION_A.

Requisitos de conectividade de rede

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

Trusted Cloud Rede VPC. Uma rede VPC configurada em Trusted 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 Trusted Cloud e os intervalos de endereços IP não podem 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 Trusted Cloud e os ambientes locais ou de outra nuvem precisam estar conectados por uma conectividade híbrida usando anexos da VLAN do Cloud Interconnect, túneis do Cloud VPN com o Cloud Router ou VMs do dispositivo roteador. 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 usando o BGP e o programa na sua rede VPCTrusted 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/dispositivo roteador precisa ser configurado 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.
- 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 aplicativo internos regionais, balanceadores de carga de rede de proxy externos regionais, e balanceadores de carga de rede de proxy internos regionais).
  
  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.
É possível 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. Observe o seguinte:
- Se você usar redes VPC diferentes, elas precisarão estar conectadas usando o peering de rede VPC ou serem spokes VPC no mesmo hub do Network Connectivity Center.
- Se você usar a mesma rede VPC, verifique se os intervalos de CIDR da sub-rede da rede VPC não entram em conflito com os intervalos de CIDR remotos. Quando os endereços IP se sobrepõem, as rotas de sub-rede são priorizadas em relação à conectividade remota.
Endpoints de rede (IP:Port) no local ou em outras nuvens. Um ou mais endpoints de rede IP:Port configurados nos ambientes locais ou em outras nuvens roteáveis usando o Cloud Interconnect Cloud VPN ou uma VM do dispositivo roteador. 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 aplicativo internos regionais, balanceadores de carga de rede de proxy externos regionais, e balanceadores de carga de rede de proxy internos regionais), você também precisa criar uma regra de firewall para permitir que o tráfego da sub-rede somente proxy da região alcance os endpoints locais ou em outros ambientes de nuvem.

Componentes do balanceador de carga

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 regionais baseados no Envoy (balanceadores de carga de aplicativo externos regionais, balanceadores de carga de aplicativo internos regionais, balanceadores de carga de rede de proxy externos regionais, e balanceadores de carga de rede de proxy internos regionais) 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 Trusted Cloud. Trusted Cloud

Back-ends que não são doTrusted 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, Cloud Interconnect ou VMs de dispositivo roteador) 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 doTrusted Cloud da seguinte maneira:
1. Adicione cada combinação de IP:Port do endpoint de rede que não seja doTrusted 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 Trusted Cloud usando conectividade híbrida (pelo Cloud VPN ou pelo Cloud Interconnect ou VMs de dispositivo roteador). Para NEGs de conectividade híbrida, defina o tipo de endpoint de rede como NON_GCP_PRIVATE_IP_PORT.
2. Ao criar o NEG, especifique uma Trusted Cloud zona que minimize a distância geográfica entre Trusted Cloud e seu 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 Trusted 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 doTrusted Cloud. O tráfego poderá ser descartado se um NEG híbrido incluir endpoints para recursos em uma rede VPC do Trusted Cloud , como endereços IP de regra de encaminhamento para balanceadores de carga de rede de passagem interna. Configure os endpoints Trusted Cloud conforme indicado na próxima seção.
Trusted Cloud backends

Configure os endpoints do Trusted Cloud da seguinte maneira:
1. Crie um serviço de back-end separado para os back-ends Trusted 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 referenciar back-ends baseados em Trusted 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.

Observação: em implantações do GKE, back-ends de NEGs mistos são compatíveis apenas com NEGs independentes.

O esquema de balanceamento de carga do serviço de back-end é INTERNAL_MANAGED para balanceadores de carga de aplicativo internos regionais e balanceadores de carga de rede de proxy internos regionais.

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. 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 e CONNECTION para balanceadores de carga de rede de proxy. 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 back-ends de NEG de conectividade híbrida (compatíveis apenas com balanceadores de carga baseados no Envoy), configure endpoints de rede exclusivos para todos os NEGs anexados ao mesmo serviço de back-end. Adicionar o mesmo endpoint de rede a vários NEGs resulta em um comportamento indefinido.

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 regional, balanceador de carga de aplicativo interno regional, balanceador de carga de rede de proxy externo regional, 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 Trusted 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 doTrusted Cloud console, 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ê usar NEGs mistos em que um único serviço de back-end tem uma combinação de NEGs zonais (endpoints GCE_VM_IP_PORT emTrusted Cloud) e NEGs híbridos (endpoints NON_GCP_PRIVATE_IP_PORT fora de Trusted Cloud), configure regras de firewall para permitir o tráfego dos intervalos de IP de sondagem de verificação de integridade do Google (130.211.0.0/22 e 35.191.0.0/16) para os endpoints de NEG zonal emTrusted 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 doTrusted Cloud , a API ou a CLI gcloud para verificar o status de integridade desses endpoints externos. Para NEGs híbridos com balanceadores de carga baseados no Envoy, o console Trusted Cloud mostra o status da verificação de integridade comoN/A. Isso já é 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 doTrusted 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. 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.

Logging

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.

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.