Redes de serviços para aplicações distribuídas na rede entre nuvens

Este documento faz parte de uma série de guias de design para a rede entre nuvens.

A série é composta pelas seguintes partes:

Este documento descreve como montar uma aplicação a partir de um conjunto de serviços de componentes escolhidos ou criados. Recomendamos que leia todo o documento uma vez antes de seguir os passos.

Este documento explica as seguintes decisões:

  • Se cria o serviço individual ou consome um serviço de terceiros
  • Se o serviço está disponível a nível global ou regional
  • Se o serviço é consumido nas instalações, noutras nuvens ou em nenhuma das opções
  • Se acede ao ponto final do serviço através de uma VPC de serviços partilhados ou distribui os pontos finais através de todas as VPCs de aplicações relevantes

Este documento explica os seguintes passos:

  1. Decidir se a sua aplicação é global ou regional
  2. Escolher serviços geridos de terceiros ou criar e publicar os seus próprios serviços
  3. Configurar o acesso privado aos pontos finais de serviço através de um modo partilhado ou dedicado
  4. Reunir os serviços em aplicações para corresponder a um arquétipo global ou regional

Os programadores definem a camada de rede de serviços para a rede entre nuvens. Nesta fase, os administradores conceberam uma camada de conetividade para a rede entre nuvens que permite flexibilidade nas opções de rede de serviços descritas neste documento. Em alguns casos, existem restrições de transitividade entre VPCs limitada. Descrevemos estas restrições quando podem afetar as decisões de design.

Decida se a sua aplicação é regional ou global

Determine se os clientes da aplicação que está a criar precisam de um arquétipo de implementação regional ou global. Pode alcançar a resiliência regional distribuindo as cargas pelas zonas de uma região. Pode alcançar a resiliência global distribuindo as cargas por várias regiões.

Considere os seguintes fatores ao escolher um arquétipo:

  • Os requisitos de disponibilidade da aplicação
  • A localização onde a aplicação é consumida
  • Custo

Para ver detalhes, consulte os Google Cloud arquétipos de implementação.

Este guia de design aborda como suportar os seguintes arquétipos de implementação:

Numa aplicação distribuída em várias nuvens, os diferentes serviços dessa aplicação podem ser fornecidos por diferentes fornecedores de serviços na nuvem (CSPs) ou centros de dados privados. Para ajudar a garantir uma estrutura de resiliência consistente, coloque os serviços alojados em diferentes CSPs em centros de dados de CSPs geograficamente próximos uns dos outros.

O diagrama seguinte mostra uma pilha de aplicações global distribuída por várias nuvens, e os diferentes serviços de aplicações são implementados em diferentes CSPs. Cada serviço de aplicação global tem instâncias de carga de trabalho em diferentes regiões do mesmo CSP.

Pilha de aplicações global distribuída por várias nuvens.

Defina e aceda aos serviços de aplicações

Para montar a sua aplicação, pode usar serviços geridos de terceiros existentes, criar e alojar os seus próprios serviços de aplicações ou usar uma combinação de ambos.

Use serviços geridos de terceiros existentes

Decida que serviços geridos de terceiros pode usar para a sua aplicação. Determine quais são criados como serviços regionais ou serviços globais. Além disso, determine que opções de acesso privado cada serviço suporta.

Quando sabe que serviços geridos pode usar, pode determinar que serviços tem de criar.

Crie e aceda a serviços de aplicações

Cada serviço é alojado por uma ou mais instâncias de carga de trabalho que podem ser acedidas como um único ponto final ou como um grupo de pontos finais.

O padrão geral de um serviço de aplicação é apresentado no diagrama seguinte. O serviço de aplicação é implementado numa coleção de instâncias de carga de trabalho. (Neste caso, uma instância de carga de trabalho pode ser uma VM do Compute Engine, um cluster do Google Kubernetes Engine (GKE) ou outro back-end que execute código.) As instâncias de carga de trabalho estão organizadas como um conjunto de back-ends associados a um balanceador de carga.

O diagrama seguinte mostra um balanceador de carga genérico com um conjunto de back-ends.

Balanceador de carga com back-ends.

Para alcançar a distribuição de carga escolhida e automatizar as comutações por falha, estes grupos de pontos finais usam um equilibrador de carga de front-end. Ao usar grupos de instâncias geridos (MIGs), pode aumentar ou diminuir elasticamente a capacidade do serviço através do dimensionamento automático dos pontos finais que formam o back-end do equilibrador de carga. Além disso, consoante os requisitos do serviço de aplicação, o equilibrador de carga também pode fornecer autenticação, terminação de TLS e outros serviços específicos da ligação.

Determine o âmbito do serviço: regional ou global

Decida se o seu serviço precisa e pode suportar a resiliência regional ou global. Um serviço de software regional pode ser concebido para sincronização dentro de um orçamento de latência regional. Um serviço de aplicação global pode suportar failovers síncronos em nós distribuídos por várias regiões. Se a sua aplicação for global, é recomendável que os serviços que a suportam também sejam globais. No entanto, se o seu serviço exigir sincronização entre as respetivas instâncias para suportar a comutação por falha, tem de considerar a latência entre regiões. Para a sua situação, pode ter de depender de serviços regionais com redundância nas mesmas regiões ou em regiões próximas, o que suporta a sincronização de baixa latência para a comutação por falha.

O Cloud Load Balancing suporta pontos finais alojados numa única região ou distribuídos por várias regiões. Assim, pode criar uma camada global virada para o cliente que se dirija a camadas de serviço globais, regionais ou híbridas. Escolha as implementações de serviços para garantir que a comutação por falha da rede dinâmica (ou o equilíbrio de carga entre regiões) se alinha com o estado de resiliência e as capacidades da lógica da sua aplicação.

O diagrama seguinte mostra como um serviço global criado a partir de equilibradores de carga regionais pode alcançar back-ends noutras regiões, oferecendo assim uma comutação por falha automática entre regiões. Neste exemplo, a lógica da aplicação é global e o back-end escolhido suporta a sincronização entre regiões. Cada balanceador de carga envia principalmente pedidos para a região local, mas pode mudar para regiões remotas.

Balanceadores de carga com back-ends em diferentes regiões.

  • Um back-end global é uma coleção de back-ends regionais aos quais um ou mais balanceadores de carga acedem.
  • Embora os back-ends sejam globais, o front-end de cada equilibrador de carga é regional.
  • Neste padrão de arquitetura, os balanceadores de carga distribuem principalmente o tráfego apenas na respetiva região, mas também podem equilibrar o tráfego para outras regiões quando os recursos na região local estão indisponíveis.
  • Um conjunto de frontends de balanceador de carga regionais, cada um acessível a partir de outras regiões e cada um capaz de alcançar backends noutras regiões, forma um serviço global agregado.
  • Para montar uma pilha de aplicações global, conforme abordado no artigo Crie pilhas de aplicações globais, pode usar o encaminhamento de DNS e as verificações de funcionamento para conseguir uma comutação por falha entre regiões dos front-ends.
  • Os front-ends do balanceador de carga são acessíveis a partir de outras regiões através do acesso global (não mostrado no diagrama).

Este mesmo padrão pode ser usado para incluir serviços publicados com comutação por falha global. O diagrama seguinte representa um serviço publicado que usa back-ends globais.

Balanceadores de carga acessíveis a partir de diferentes regiões.

No diagrama, repare que o serviço publicado tem uma comutação por falha global implementada no ambiente do produtor. A adição da comutação por falha global no ambiente de consumo permite a resiliência a falhas regionais na infraestrutura de equilíbrio de carga de consumo. A comutação por falha entre regiões do serviço tem de ser implementada na lógica da aplicação de serviço e no design de equilíbrio de carga do produtor do serviço. Os produtores de serviços podem implementar outros mecanismos.

Para determinar que produto do Cloud Load Balancing usar, primeiro tem de determinar que tipo de tráfego os equilibradores de carga têm de processar. Considere as seguintes regras gerais:

  • Use um balanceador de carga de aplicações para tráfego HTTP(S).
  • Use um balanceador de carga de rede de proxy para tráfego TCP não HTTP(S). Este equilibrador de carga de proxy também suporta a transferência de TLS.
  • Use um equilibrador de carga de passagem para preservar o endereço IP de origem do cliente no cabeçalho ou para suportar protocolos adicionais, como UDP, ESP e ICMP.

Para orientações detalhadas sobre como selecionar o melhor balanceador de carga para o seu exemplo de utilização, consulte o artigo Escolha um balanceador de carga.

Serviços com back-ends sem servidor

Um serviço pode ser definido através de back-ends sem servidor. O back-end no ambiente do produtor pode ser organizado num NEG sem servidor como back-end de um balanceador de carga. Este serviço pode ser publicado através do Private Service Connect criando uma associação de serviço associada ao front-end do balanceador de carga do produtor. O serviço publicado pode ser consumido através de pontos finais do Private Service Connect ou back-ends do Private Service Connect. Se o serviço exigir ligações iniciadas pelo produtor, pode usar um conector de acesso à VPC sem servidor para permitir que os ambientes do Cloud Run, do App Engine Standard e das funções do Cloud Run enviem pacotes para os endereços IPv4 internos de recursos numa rede VPC. O Acesso a VPC sem servidor também suporta o envio de pacotes para outras redes ligadas à rede VPC selecionada.

Métodos para aceder a serviços de forma privada

A sua aplicação pode consistir em serviços geridos fornecidos pela Google, serviços de terceiros fornecidos por fornecedores externos ou grupos de pares na sua organização e serviços desenvolvidos pela sua equipa. Alguns desses serviços podem estar acessíveis através da Internet com endereços IP públicos. Esta secção descreve os métodos que pode usar para aceder a esses serviços através da rede privada. Existem os seguintes tipos de serviços:

  • APIs públicas Google
  • APIs sem servidor da Google
  • Serviços geridos publicados pela Google
  • Serviços geridos publicados por fornecedores e pares
  • Os seus serviços publicados

Tenha estas opções em atenção ao ler as secções seguintes. Consoante a forma como atribui os seus serviços, pode usar uma ou mais das opções de acesso privado descritas.

A organização (ou o grupo numa organização) que reúne, publica e gere um serviço é denominada produtor do serviço. A sua aplicação e você são referidos como o consumidor do serviço.

Alguns serviços geridos são publicados exclusivamente através do acesso a serviços privados. Os designs de rede recomendados em Conetividade interna e rede VPC acomodam serviços publicados com acesso a serviços privados e Private Service Connect.

Para uma vista geral das opções de acesso privado aos serviços, consulte o artigo Opções de acesso privado aos serviços.

Recomendamos que use o Private Service Connect para estabelecer ligação a serviços geridos sempre que possível. Para mais informações sobre os padrões de implementação do Private Service Connect, consulte os padrões de implementação do Private Service Connect.

Existem dois tipos de Private Service Connect, e os diferentes serviços podem ser publicados como qualquer um dos tipos:

Os serviços publicados como pontos finais do Private Service Connect podem ser consumidos diretamente por outras cargas de trabalho. Os serviços baseiam-se na autenticação e na capacidade de recuperação fornecidas pelo produtor do serviço. Se quiser ter um controlo adicional sobre a autenticação e a resiliência do serviço, pode usar back-ends do Private Service Connect para adicionar uma camada de equilíbrio de carga para autenticação e resiliência na rede do consumidor.

O diagrama seguinte mostra os serviços acedidos através de pontos finais do Private Service Connect:

Aceder a serviços através de pontos finais do Private Service Connect.

O diagrama mostra o seguinte padrão:

  • Um ponto final do Private Service Connect é implementado na VPC do consumidor, o que torna o serviço de produtor disponível para VMs e nós do GKE.
  • As redes de consumidor e produtor têm de ser implementadas na mesma região.

O diagrama anterior mostra os pontos finais como recursos regionais. Os pontos finais são acessíveis a partir de outras regiões devido ao acesso global.

Para mais informações sobre padrões de implementação, consulte os padrões de implementação do Private Service Connect.

Os back-ends do Private Service Connect usam um balanceador de carga configurado com back-ends do grupo de pontos finais da rede (NEG) do Private Service Connect. Para ver uma lista dos balanceadores de carga suportados, consulte o artigo Acerca dos back-ends do Private Service Connect.

Os back-ends do Private Service Connect permitem-lhe criar as seguintes configurações de back-end:

  • Domínios e certificados pertencentes ao cliente à frente dos serviços geridos
  • Comutação por falha controlada pelo consumidor entre serviços geridos em diferentes regiões
  • Configuração de segurança centralizada e controlo de acesso para serviços geridos

No diagrama seguinte, o balanceador de carga global usa um NEG do Private Service Connect como um back-end que estabelece comunicação com o fornecedor de serviços. Não é necessária nenhuma configuração de rede adicional e os dados são transferidos através da estrutura SDN da Google.

Balanceador de carga global que usa um grupo de pontos finais da rede.

A maioria dos serviços é concebida para ligações iniciadas pelo consumidor. Quando os serviços precisam de iniciar ligações a partir do produtor, use as interfaces do Private Service Connect.

Uma consideração importante ao implementar o acesso privado aos serviços ou o Private Service Connect é a transitividade. Os pontos de acesso do consumidor do Private Service Connect são acessíveis através do Network Connectivity Center. Os serviços publicados não são acessíveis através de uma ligação de interligação de redes VPC para o Private Service Connect nem para os pontos de acesso do consumidor de acesso a serviços privados. Na ausência de transitividade entre VPCs para todos os pontos de acesso do consumidor de serviços, a localização da sub-rede de acesso ao serviço ou dos pontos finais na topologia de VPC determina se cria a rede para implementação de serviços partilhada ou dedicada.

As opções, como a VPN de alta disponibilidade e os proxies geridos pelo cliente, oferecem métodos para permitir a comunicação transitiva entre VPCs.

Os pontos finais do Private Service Connect não estão acessíveis através do peering de redes VPC. Se precisar deste tipo de conetividade, implemente um balanceador de carga interno e um NEG do Private Service Connect como back-end, conforme mostrado no diagrama seguinte:

Usar NEGs para fornecer acessibilidade.

Pode aceder às APIs Google de forma privada através de pontos finais e back-ends do Private Service Connect. Geralmente, recomenda-se a utilização de pontos finais, uma vez que o produtor da API Google oferece resiliência e autenticação baseada em certificados.

Crie um ponto final do Private Service Connect em cada VPC na qual o serviço tem de ser acedido. Uma vez que o endereço IP do consumidor é um endereço IP global privado, é necessário um único mapeamento de DNS para cada serviço, mesmo que existam instâncias de pontos finais em várias VPCs, conforme mostrado no seguinte diagrama:

Private Service Connect com APIs Google.

Defina padrões de consumo para serviços publicados

Os serviços publicados podem ser executados em várias localizações: na sua rede VPC, noutra rede VPC, num centro de dados nas instalações ou na nuvem. Independentemente do local onde a carga de trabalho do serviço é executada, a sua aplicação consome esses serviços através de um ponto de acesso, como um dos seguintes:

  • Um endereço IP numa sub-rede de acesso a serviços privados
  • Um ponto final do Private Service Connect
  • Um IP virtual para um balanceador de carga que usa NEGs do Private Service Connect

Os pontos de acesso do consumidor podem ser partilhados entre redes ou dedicados a uma única rede. Decida se quer criar pontos de acesso do consumidor partilhados ou dedicados com base no facto de a sua organização delegar a tarefa de criar pontos de acesso do serviço ao consumidor a cada grupo de aplicações ou gerir o acesso aos serviços de forma consolidada.

A gestão do acesso ao serviço envolve as seguintes atividades:

  • Criar os pontos de acesso
  • Implementar os pontos de acesso numa VPC de acesso a serviços, que é uma VPC com o tipo de acessibilidade adequado
  • Registar os endereços IP e os URLs dos pontos de acesso do consumidor no DNS
  • Gerir certificados de segurança e resiliência para o serviço no espaço do consumidor, quando adiciona o equilíbrio de carga à frente dos pontos de acesso do consumidor

Para algumas organizações, pode ser viável atribuir a gestão do acesso aos serviços a uma equipa central, enquanto outras podem estar estruturadas para dar mais independência a cada equipa de consumidores ou de aplicações. Um subproduto do funcionamento no modo dedicado é que alguns dos elementos são replicados. Por exemplo, um serviço é registado com vários nomes de DNS por cada grupo de aplicações e gere vários conjuntos de certificados TLS.

A conceção da VPC descrita no artigo Segmentação de rede e conetividade para aplicações distribuídas na rede entre nuvens permite a acessibilidade para implementar pontos de acesso a serviços num modo partilhado ou dedicado. Os pontos de acesso do consumidor partilhados são implementados em VPCs de acesso ao serviço, que podem ser acedidas a partir de qualquer outra VPC ou rede externa. Os pontos de acesso de consumidor dedicados são implementados em VPCs de aplicações, às quais só é possível aceder a partir de recursos nessa VPC de aplicações.

A principal diferença entre uma VPC de acesso ao serviço e uma VPC de aplicação é a conetividade transitiva do ponto de acesso ao serviço que uma VPC de acesso ao serviço permite. As VPCs de acesso aos serviços não se limitam ao alojamento de pontos de acesso do consumidor. Uma VPC pode alojar recursos de aplicações, bem como pontos de acesso de consumidores partilhados. Nesse caso, a VPC deve ser configurada e tratada como uma VPC de serviço.

Acesso partilhado aos serviços geridos

Para todos os métodos de consumo de serviços, incluindo o Private Service Connect, certifique-se de que realiza as seguintes tarefas:

  • Implemente os pontos de acesso do consumidor de serviços numa VPC de serviços. As VPCs de serviço têm acessibilidade transitiva a outras VPCs.
  • Se a VPC de acesso ao serviço estiver ligada à VPN de alta disponibilidade, anuncie a sub-rede do ponto de acesso do consumidor como um anúncio de rota personalizada do Cloud Router que estabelece peering com outras redes através da VPN de alta disponibilidade. Para as APIs Google, anuncie o endereço IP do anfitrião da API.
  • Atualize as regras de firewall de várias nuvens para permitir a sub-rede de acesso a serviços privados.

Especificamente para o acesso a serviços privados, certifique-se de que consegue cumprir os seguintes requisitos adicionais:

  • Exporte encaminhamentos personalizados para a rede do produtor do serviço. Para mais informações, consulte o artigo Os anfitriões no local não conseguem comunicar com a rede do produtor do serviço
  • Crie regras de firewall de entrada para permitir que a sub-rede de acesso a serviços privados entre nas VPCs da aplicação
  • Crie regras de firewall de entrada para permitir que a sub-rede de acesso a serviços privados entre na VPC de serviços

Para o acesso ao serviço sem servidor, certifique-se de que consegue cumprir os seguintes requisitos:

  • O conector de acesso requer uma sub-rede normal /28 dedicada
  • O Cloud Router anuncia sub-redes normais por predefinição
  • Crie regras de firewall de entrada para permitir o acesso à sub-rede da VPC nas VPCs
  • Atualize as regras de firewall multinuvem para permitir a sub-rede do conetor de acesso à VPC
  • Crie regras de firewall de entrada para permitir que a sub-rede de acesso a serviços privados entre nas VPCs da aplicação

Acesso dedicado a serviços geridos

Certifique-se de que realiza as seguintes tarefas:

  • Em cada VPC de aplicação onde o acesso é necessário, implemente uma regra de encaminhamento para o serviço criar um ponto de acesso.
  • Para o acesso a serviços privados, crie regras de firewall de entrada para permitir que a sub-rede de acesso a serviços privados entre nas VPCs da aplicação.

Para o acesso ao serviço sem servidor, certifique-se de que consegue cumprir os seguintes requisitos:

  • O conector de acesso requer uma sub-rede normal /28 dedicada
  • Crie regras de firewall de entrada para permitir a sub-rede do conetor de acesso à VPC nas VPCs da aplicação

Monte a pilha de aplicações

Esta secção descreve a montagem de uma pilha de aplicações regional ou global.

Crie pilhas de aplicações regionais

Quando uma aplicação segue os arquétipos de implementação regional ou multirregional, use pilhas de aplicações regionais. As pilhas de aplicações regionais podem ser consideradas uma concatenação de camadas de serviços de aplicações regionais. Por exemplo, uma camada de serviço Web regional que comunica com uma camada de aplicação na mesma região, que, por sua vez, comunica com uma camada de base de dados na mesma região, é uma pilha de aplicações regional.

Cada camada de serviço de aplicação regional usa balanceadores de carga para distribuir o tráfego pelos pontos finais da camada nessa região. A fiabilidade é alcançada através da distribuição dos recursos de back-end por três ou mais zonas na região.

As camadas de serviços de aplicações noutros CSPs ou centros de dados nas instalações devem ser implementadas em regiões equivalentes nas redes externas. Além disso, disponibilize os serviços publicados na região da pilha. Para alinhar a pilha de aplicações numa região, os URLs da camada de serviço de aplicações têm de ser resolvidos para o endereço IP regional específico do front-end do balanceador de carga. Estes mapeamentos de DNS estão registados na zona de DNS relevante para cada serviço de aplicação.

O diagrama seguinte mostra uma pilha regional com resiliência ativa/em espera:

Conjunto regional com resiliência ativa/em espera.

É implementada uma instância completa da pilha de aplicações em cada região nos diferentes centros de dados na nuvem. Quando ocorre uma falha regional em qualquer uma das camadas de serviço de aplicações, a pilha na outra região assume a entrega de toda a aplicação. Esta comutação por falha é feita em resposta à monitorização fora da banda das diferentes camadas de serviço da aplicação.

Quando é comunicado um erro para uma das camadas de serviço, o front-end da aplicação é reancorado à pilha de cópia de segurança. A aplicação é escrita para referenciar um conjunto de registos de nomes regionais que refletem a pilha de endereços IP regionais no DNS, para que cada camada da aplicação mantenha as respetivas ligações na mesma região.

Conceba stacks de aplicações globais

Quando uma aplicação segue o arquétipo de implementação de aplicações global, cada camada de serviço de aplicações inclui back-ends em várias regiões. A inclusão de back-ends em várias regiões expande o conjunto de resiliência para a camada de serviço de aplicações além de uma única região e permite a deteção e a reconvergência automáticas de ativação pós-falha.

O diagrama seguinte mostra uma pilha de aplicações global:

Stack global que usa um projeto de hub e um projeto de aplicação.

O diagrama anterior mostra uma aplicação global criada a partir dos seguintes componentes:

  • Serviços executados em centros de dados no local com front-ends de balanceadores de carga. Os pontos de acesso do balanceador de carga são acessíveis através do Cloud Interconnect a partir da VPC de trânsito.
  • Uma VPC de trânsito aloja ligações híbridas entre o centro de dados externo e a VPC da aplicação.
  • Uma VPC de aplicações que aloja a aplicação principal em execução em instâncias de carga de trabalho. Estas instâncias de carga de trabalho estão atrás de balanceadores de carga. Os balanceadores de carga são acessíveis a partir de qualquer região na rede e podem alcançar back-ends em qualquer região na rede.
  • Uma VPC de serviços que aloja pontos de acesso para serviços executados noutras localizações, como em VPCs de terceiros. Estes pontos de acesso ao serviço são acessíveis através da ligação VPN de alta disponibilidade entre a VPC de serviços e a VPC de trânsito.
  • VPCs de produtores de serviços alojadas por outras organizações ou pela organização principal e aplicações executadas noutras localizações. Os serviços relevantes são acessíveis através de back-ends do Private Service Connect implementados como back-ends globais para balanceadores de carga regionais alojados na VPC de serviços. Os balanceadores de carga regionais são acessíveis a partir de qualquer outra região.

Se quiser que a aplicação criada seja acessível a partir da Internet, pode adicionar um Application Load Balancer externo global que aponte para as cargas de trabalho da aplicação na VPC da aplicação (não mostrado no diagrama).

Para suportar uma pilha de aplicações global, usámos back-ends globais para cada camada de aplicação. Isto permite a recuperação de uma falha de todos os pontos finais de back-end numa região. Cada região tem um front-end do balanceador de carga regional para cada camada de serviço de aplicação. Quando ocorre uma comutação por falha regional, é possível aceder aos front-ends do balanceador de carga regional interno em todas as regiões, porque usam acesso global. Uma vez que a pilha de aplicações é global, as políticas de encaminhamento de geolocalização de DNS são usadas para selecionar o front-end regional mais adequado para um pedido ou um fluxo específico. Em caso de falha do front-end, as verificações de estado do DNS podem ser usadas para automatizar a comutação por falha de um front-end para outro.

Os serviços publicados através de back-ends do Private Service Connect beneficiam do acesso global do Private Service Connect. Esta funcionalidade permite que um back-end do Private Service Connect seja acessível a partir de qualquer região e reduz as interrupções devido a falhas na camada de serviço da aplicação. Isto significa que os back-ends do Private Service Connect podem ser usados como back-ends globais, conforme descrito em Determine o âmbito do serviço: regional ou global.

Forneça acesso privado a serviços alojados em redes externas

Pode querer publicar um ponto de acesso local para um serviço alojado noutra rede. Nestes casos, pode usar um balanceador de carga de proxy TCP regional interno com NEGs híbridos. Pode criar um produtor de serviços alojado no local ou noutros ambientes de nuvem que estejam disponíveis para os consumidores de serviços (clientes) na sua rede VPC, conforme mostrado no diagrama seguinte:

Ponto de acesso local através de NEGs híbridos.

Se quiser disponibilizar o serviço híbrido numa rede VPC diferente da que aloja o equilibrador de carga, pode usar o Private Service Connect para publicar o serviço. Ao colocar uma associação de serviço à frente do seu equilibrador de carga do proxy TCP regional interno, pode permitir que os clientes noutras redes VPC alcancem os serviços híbridos em execução nas instalações ou noutros ambientes na nuvem.

Num ambiente de várias nuvens, a utilização de um NEG híbrido permite uma comunicação segura entre aplicações.

Quando uma organização diferente publica um serviço de aplicação, use um NEG híbrido para estender as abstrações de acesso privado para esse serviço. O diagrama seguinte ilustra este cenário:

NEGs híbridos em frente de serviços noutras redes.

No diagrama anterior, a camada de serviço de aplicação é totalmente composta no CSP vizinho, que está realçado nas partes do diagrama que não estão a cinzento. Os balanceadores de carga híbridos são usados em conjunto com associações do serviço Private Service Connect como um mecanismo para publicar o serviço de aplicação externo para consumo privado noGoogle Cloud. Os balanceadores de carga híbridos com NEGs híbridos e associações de serviços do Private Service Connect estão numa VPC que faz parte de um projeto de produtor de serviços. Normalmente, este projeto de produtor de serviços pode ser uma VPC diferente da VPC de trânsito, porque está no âmbito administrativo da organização ou do projeto do produtor e, por isso, separado dos serviços de trânsito comuns. A VPC do produtor não precisa de estar ligada através do peering de VPC ou da VPN de alta disponibilidade com a VPC do consumidor (que é a VPC partilhada de serviços no diagrama).

Centralize o acesso aos serviços

O acesso ao serviço pode ser centralizado numa rede VPC e acedido a partir de outras redes de aplicações. O diagrama seguinte mostra o padrão comum que permite a centralização dos pontos de acesso:

VPC de serviços dedicados.

O diagrama seguinte mostra todos os serviços a serem acedidos a partir de uma VPC de serviços dedicada:

VPC de serviços dedicados com balanceadores de carga centralizados.

Quando os serviços são apresentados com balanceadores de carga de aplicações, pode consolidar em menos balanceadores de carga usando mapas de URLs para direcionar o tráfego para diferentes back-ends de serviços, em vez de usar diferentes balanceadores de carga para cada serviço. Em princípio, uma pilha de aplicações pode ser totalmente composta usando um único balanceador de carga de aplicações, além de back-ends de serviços e mapeamentos de URLs adequados.

Nesta implementação, tem de usar NEGs híbridos em várias VPCs para a maioria dos tipos de back-end. A exceção é um NEG ou um back-end do Private Service Connect, conforme descrito no artigo Encadeamento explícito de Google Cloud balanceadores de carga de nível 7 com o Private Service Connect.

A utilização de NEGs híbridos em VPCs implica a renúncia à recuperação automática e ao escalamento automático para os back-ends. Os serviços publicados já têm um equilibrador de carga no inquilino do produtor que oferece o dimensionamento automático. Por conseguinte, só encontra as limitações dos NEGs híbridos se centralizar a função de equilíbrio de carga para as camadas de serviço que estão a ser compostas nativamente em vez de consumidas a partir da publicação.

Quando usar este padrão de rede de serviços, lembre-se de que os serviços são consumidos através de uma camada adicional de equilíbrio de carga.

Os pontos finais de serviço do Private Service Connect são acessíveis nas VPCs spoke do Network Connectivity Center.

O modo centralizado adiciona uma camada de equilíbrio de carga no lado do consumidor do serviço. Quando usa este modo, também tem de gerir os certificados, a resiliência e os mapeamentos de DNS adicionais no projeto de consumidor.

Outras considerações

Esta secção contém considerações para produtos e serviços comuns não explicitamente abordados neste documento.

Considerações sobre o plano de controlo do GKE

O plano de controlo do GKE é implementado num projeto de inquilino gerido pela Google que está ligado à VPC do cliente através do intercâmbio de redes VPC. Uma vez que o intercâmbio das redes da VPC não é transitivo, a comunicação direta com o plano de controlo através de uma topologia de rede com intercâmbio das redes da VPC de hub e spoke não é possível.

Ao considerar as opções de design do GKE, como centralizadas ou descentralizadas, o acesso direto ao plano de controlo a partir de origens multicloud é uma consideração fundamental. Se o GKE for implementado numa VPC centralizada, o acesso ao plano de controlo está disponível em todas as nuvens e dentro de Google Cloud. No entanto, se o GKE for implementado em VPCs descentralizadas, a comunicação direta com o plano de controlo não é possível. Se os requisitos de uma organização exigirem o acesso ao plano de controlo do GKE, além de adotar o padrão de design descentralizado, os administradores de rede podem implementar um agente de ligação que atua como um proxy, superando assim a limitação de peering não transitivo ao plano de controlo do GKE.

Segurança – VPC Service Controls

Para cargas de trabalho que envolvam dados sensíveis, use os VPC Service Controls para configurar perímetros de serviço em torno dos seus recursos de VPC e serviços geridos pela Google, e controlar a movimentação de dados no limite do perímetro. Com os VPC Service Controls, pode agrupar projetos e a sua rede no local num único perímetro que impede o acesso a dados através de serviços geridos pela Google. As regras de entrada e saída dos VPC Service Controls podem ser usadas para permitir que projetos e serviços em diferentes perímetros de serviço comuniquem (incluindo redes VPC que não estão dentro do perímetro).

Para ver arquiteturas de implementação recomendadas, um processo de integração abrangente e práticas recomendadas operacionais, consulte as práticas recomendadas para os VPC Service Controls para empresas e o projeto de base de segurança.

DNS para APIs/serviços

Os produtores de serviços podem publicar serviços através do Private Service Connect. O produtor do serviço pode, opcionalmente, configurar um nome de domínio DNS para associar ao serviço. Se um nome de domínio estiver configurado e um consumidor de serviços criar um ponto final que tenha como destino esse serviço, o Private Service Connect e o Service Directory criam automaticamente entradas DNS para o serviço numa zona DNS privada na rede VPC do consumidor de serviços.

O que se segue?

Colaboradores

Autores:

Outros colaboradores: