Algumas ou todas as informações nesta página podem não se aplicar ao Cloud de Confiance by S3NS. Consulte o artigo Diferenças em relação ao Google Cloud para mais detalhes.

Esta página foi traduzida pela API Cloud Translation.

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

O balanceamento de carga híbrido é suportado nos seguintes Cloud de Confiance by S3NS 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:port válidas que o balanceador de carga possa 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 Cloud de Confiance 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 Cloud de Confianceou 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 regional, pode encaminhar o tráfego externo para pontos finais que se encontram na mesma Cloud de Confiance 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 Cloud de Confiance 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 Google Cloud Interconnect ou das VMs do dispositivo Router para o destino externo pretendido.Cloud de Confiance

Clientes internos (na rede Cloud de Confiance ou no local)

Também pode configurar uma implementação híbrida para clientes internos à Cloud de Confiance. Neste caso, o tráfego do cliente tem origem na Cloud de Confiance 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 Cloud de Confiance região que os recursos do balanceador de carga.

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 umCloud de Confiance ponto final de serviço correspondente.

Se estiver a usar um Application Load Balancer interno para processar clientes internos, pode configurar o Cloud de Confiance 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 Cloud de Confiance e 100% para o serviço local. Em seguida, pode aumentar gradualmente a proporção de tráfego enviado para o serviço Cloud de Confiance . Eventualmente, envia 100% do tráfego para o serviço Cloud de Confiance 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 Cloud de Confiance recursos necessários para ativar o equilíbrio de carga híbrido.

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

Encaminhamento do Cloud Load Balancing

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

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.

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.

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:

Cloud de Confiance Rede da VPC. Uma rede VPC configurada no interior de Cloud de Confiance. 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 Cloud de Confiance os intervalos de endereços IP e de 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 Cloud de Confiance 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 Cloud de Confiance rede VPC. O encaminhamento dinâmico regional não é suportado. As rotas estáticas também não são suportadas.

O Cloud Router também tem de anunciar as seguintes rotas para o 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.
- 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 rede de proxy externos regionais, 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 estado do Envoy distribuídas 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 rede de proxy externos regionais, 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

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 rede de proxy externos regionais, 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 Cloud de Confiance, bem como fora Cloud de Confiance.

Back-ends nãoCloud de Confiance (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ãoCloud de Confiance da seguinte forma:
1. Adicione a combinação deCloud de Confiance 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 Cloud de Confiance 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 Cloud de Confiance zona que minimize a distância geográfica entre Cloud de Confiance 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 Cloud de Confiance 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ãoCloud de Confiance 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. Cloud de Confiance Configure os Cloud de Confiance pontos finais conforme indicado na secção seguinte.
Cloud de Confiance backends

Configure os seus Cloud de Confiance pontos finais da seguinte forma:
1. Crie um serviço de back-end separado para os Cloud de Confiance 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 emCloud de Confiance(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.

Nota: para implementações do GKE, os back-ends de NEG mistos só são suportados com NEGs autónomos.

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

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 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 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 . 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 Cloud de Confiance, 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 só de proxy da região.

As verificações de funcionamento do Envoy distribuídas são criadas através dos mesmos Cloud de Confiance 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 saúde 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 deCloud de Confiance) e NEGs híbridos (NON_GCP_PRIVATE_IP_PORT pontos finais fora de Cloud de Confiance), 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 emCloud de Confiance. Isto deve-se ao facto de os NEGs zonais usarem o sistema de verificação de estado de funcionamento centralizado da Google.
Uma vez que o plano de dados do Envoy processa as verificações de estado, não pode usar a Cloud de Confiance 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 Cloud de Confiance consola mostra o estado da verificação de funcionamento como N/A. 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 deCloud de Confiance 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.

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.