Este documento faz parte de uma série de guias de design para a rede entre nuvens.
A série consiste nas partes a seguir:
- Cross-Cloud Network para aplicativos distribuídos
- Segmentação de rede e conectividade para aplicativos distribuídos em rede entre nuvens
- Rede de serviços para aplicativos distribuídos em rede entre nuvens (este documento)
- Segurança de rede para aplicativos distribuídos em redes entre nuvens
Este documento descreve como montar um aplicativo a partir de um conjunto de serviços de componentes escolhidos ou criados. Recomendamos que você leia todo o documento antes de seguir as etapas.
Este documento orienta você nas seguintes decisões:
- Se você cria o serviço individual ou consome um serviço de terceiros
- Se o serviço está disponível globalmente ou regionalmente
- Se o serviço é consumido no local, em outras nuvens ou em nenhum dos dois
- Se você acessa o endpoint do serviço por uma VPC de serviços compartilhados ou distribui os endpoints por todas as VPCs de aplicativos relevantes
Este documento orienta você nas seguintes etapas:
- Como decidir se o aplicativo é global ou regional
- Como escolher serviços gerenciados de terceiros ou criar e publicar seus próprios serviços
- Como configurar o acesso privado aos endpoints de serviço usando um modo compartilhado ou dedicado
- Montagem dos serviços em aplicativos para corresponder a um arquétipo global ou regional
Os desenvolvedores definem a camada de rede de serviços para a rede entre nuvens. Nesta fase, os administradores projetaram uma camada de conectividade 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 limitada entre VPCs. Descrevemos essas restrições quando elas podem afetar as decisões de design.
Decidir se o aplicativo é regional ou globall
Determine se os clientes do aplicativo que você está criando precisam de um arquétipo de implantação regional ou global. É possível alcançar a resiliência regional distribuindo cargas entre as zonas de uma região. É possível alcançar a resiliência global distribuindo cargas entre as regiões.
Considere os seguintes fatores ao escolher um arquétipo:
- Os requisitos de disponibilidade do aplicativo
- O local em que o aplicativo é consumido
- Custo
Para mais detalhes, consulte Arquétipos de implantação do Google Cloud.
Este guia de design discute como oferecer suporte aos seguintes arquétipos de implantação:
- Arquétipo de implantação multirregional do Google Cloud
- Arquétipo de implantação global do Google Cloud
Em um aplicativo distribuído entre nuvens, diferentes serviços desse aplicativo podem ser entregues por diferentes provedores de serviços em nuvem (CSPs) ou data centers particulares. Para garantir uma estrutura de resiliência consistente, coloque serviços hospedados em CSPs diferentes em data centers CSPs que estejam geograficamente próximos uns dos outros.
O diagrama a seguir mostra uma pilha de aplicativos global distribuída entre nuvens, e diferentes serviços de aplicativos são implantados em diferentes CSPs. Cada serviço de aplicativo global tem instâncias de carga de trabalho em diferentes regiões do mesmo CSP.
Definir e acessar serviços de aplicativos
Para montar seu aplicativo, você pode usar serviços gerenciados de terceiros, criar e hospedar seus próprios serviços de aplicativos ou usar uma combinação dos dois.
Usar serviços gerenciados de terceiros
Decida quais serviços gerenciados de terceiros você pode usar no seu aplicativo. Determine quais foram criados como serviços regionais ou globais. Além disso, determine quais opções de acesso particular cada serviço oferece suporte.
Depois de saber quais serviços gerenciados você pode usar, é possível determinar quais serviços você precisa criar.
Criar e acessar serviços de aplicativos
Cada serviço é hospedado por uma ou mais instâncias de carga de trabalho que podem ser acessadas como um único endpoint ou como um grupo de endpoints.
O padrão geral de um serviço de aplicativo é mostrado no diagrama a seguir. O serviço do aplicativo é implantado em uma coleção de instâncias de carga de trabalho. Nesse caso, uma instância de carga de trabalho pode ser uma VM do Compute Engine, um cluster do Google Kubernetes Engine (GKE) ou algum outro back-end que execute código. As instâncias de carga de trabalho são organizadas como um conjunto de back-ends associados a um balanceador de carga.
O diagrama a seguir mostra um balanceador de carga genérico com um conjunto de back-ends.
Para alcançar a distribuição de carga escolhida e automatizar as failovers, esses grupos de endpoints usam um balanceador de carga de front-end. Ao usar grupos de instâncias gerenciadas (MIGs, na sigla em inglês), é possível aumentar ou diminuir a capacidade do serviço de forma elástica, escalonando automaticamente os endpoints que formam o back-end do balanceador de carga. Além disso, dependendo dos requisitos do serviço do aplicativo, o balanceador de carga também pode fornecer autenticação, terminação TLS e outros serviços específicos de conexão.
Determinar o escopo do serviço: regional ou global
Decida se o serviço precisa e pode oferecer resiliência regional ou global. Um serviço de software regional pode ser projetado para sincronização dentro de um orçamento de latência regional. Um serviço de aplicativo global pode oferecer suporte a failovers síncronos em nós distribuídos entre regiões. Se o aplicativo for global, talvez você queira que os serviços que o suportam também sejam globais. No entanto, se o serviço exigir sincronização entre as instâncias para oferecer suporte ao failover, considere a latência entre as regiões. Na sua situação, talvez seja necessário usar serviços regionais com redundância nas mesmas regiões ou em regiões próximas, com suporte à sincronização de baixa latência para failover.
O Cloud Load Balancing oferece suporte a endpoints hospedados em uma única região ou distribuídos entre regiões. Assim, é possível criar uma camada global voltada ao cliente que se comunica com camadas de serviço globais, regionais ou híbridas. Escolha as implantações de serviço para garantir que o failover de rede dinâmico (ou balanceamento de carga entre regiões) esteja alinhado com o estado de resiliência e os recursos da lógica do aplicativo.
O diagrama a seguir mostra como um serviço global criado com base em balanceadores de carga regionais pode alcançar back-ends em outras regiões, oferecendo failover automático entre regiões. Neste exemplo, a lógica do aplicativo é global, e o back-end escolhido oferece suporte à sincronização entre regiões. Cada balanceador de carga envia solicitações principalmente para a região local, mas pode fazer failover para regiões remotas.
- Um back-end global é uma coleção de back-ends regionais acessados por um ou mais balanceadores de carga.
- Embora os back-ends sejam globais, o front-end de cada balanceador de carga é regional.
- Nesse padrão de arquitetura, os balanceadores de carga distribuem o tráfego apenas dentro da 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 front-ends de balanceadores de carga regionais, cada um acessível de outras regiões e capaz de alcançar back-ends em outras regiões, forma um serviço global agregado.
- Para montar uma pilha de aplicativos global, conforme discutido em Projetar pilhas de aplicativos globais, é possível usar o roteamento de DNS e as verificações de integridade para conseguir failover entre regiões dos front-ends.
- Os front-ends do balanceador de carga podem ser acessados de outras regiões usando o acesso global (não mostrado no diagrama).
Esse mesmo padrão pode ser usado para incluir serviços publicados com failover global. O diagrama a seguir mostra um serviço publicado que usa back-ends globais.
No diagrama, observe que o serviço publicado tem failover global implementado no ambiente do produtor. A adição de failover global no ambiente do consumidor permite a resiliência a falhas regionais na infraestrutura de balanceamento de carga do consumidor. O failover entre regiões do serviço precisa ser implementado na lógica do aplicativo de serviço e no design de balanceamento de carga do produtor de serviços. Outros mecanismos podem ser implementados pelos produtores de serviços.
Para determinar qual produto do Cloud Load Balancing deve ser usado, primeiro você precisa determinar que tipo de tráfego seus balanceadores de carga devem gerenciar. Considere as seguintes regras gerais:
- Use um balanceador de carga de aplicativo para tráfego HTTP(S).
- Use um balanceador de carga de rede proxy para tráfego TCP que não seja HTTP(S). Esse balanceador de carga de proxy também oferece suporte ao TLS offload.
- Use um balanceador de carga de rede de passagem para preservar o endereço IP de origem do cliente no cabeçalho ou para oferecer suporte a outros protocolos, como UDP, ESP e ICMP.
Para orientações detalhadas sobre como selecionar o melhor balanceador de carga para seu caso de uso, consulte Escolher um balanceador de carga.
Serviços com back-ends sem servidor
Um serviço pode ser definido usando back-ends sem servidor. O back-end no ambiente do produtor pode ser organizado em um NEG sem servidor como back-end para um balanceador de carga. Esse serviço pode ser publicado usando o Private Service Connect criando um anexo de serviço associado ao front-end do balanceador de carga do produtor. O serviço publicado pode ser consumido por endpoints ou back-ends do Private Service Connect. Se o serviço exigir conexões iniciadas pelo produtor, use um conector de acesso VPC sem servidor para permitir que os ambientes do Cloud Run, do App Engine padrão e do Cloud Run Functions enviem pacotes para os endereços IPv4 internos dos recursos em uma rede VPC. O acesso VPC sem servidor também oferece suporte ao envio de pacotes a outras redes conectadas à rede VPC selecionada.
Métodos para acessar serviços de maneira particular
O aplicativo pode consistir em serviços gerenciados fornecidos pelo Google, serviços de terceiros fornecidos por fornecedores externos ou grupos de pares na sua organização e serviços desenvolvidos pela sua equipe. Alguns desses serviços podem ser acessados pela Internet usando endereços IP públicos. Esta seção descreve os métodos que podem ser usados para acessar esses serviços usando a rede privada. Os seguintes tipos de serviço existem:
- APIs públicas do Google
- APIs sem servidor do Google
- Serviços gerenciados publicados pelo Google
- Serviços gerenciados publicados de fornecedores e colegas
- Seus serviços publicados
Tenha essas opções em mente ao ler as seções seguintes. Dependendo de como você aloca seus serviços, é possível usar uma ou mais das opções de acesso particular descritas.
A organização (ou grupo dentro de uma organização) que monta, publica e gerencia um serviço é chamada de produtora de serviços. Você e seu app são chamados de consumidor de serviço.
Alguns serviços gerenciados são publicados exclusivamente usando o acesso a serviços privados. Os designs de rede recomendados em Conectividade interna e rede VPC acomodam serviços publicados com acesso a serviços particulares e Private Service Connect.
Para ter uma visão geral das opções de acesso privado a serviços, consulte Opções de acesso privado a serviços.
Recomendamos o uso do Private Service Connect para se conectar a serviços gerenciados sempre que possível. Para mais informações sobre padrões de implantação do Private Service Connect, consulte Padrões de implantação do Private Service Connect.
Há dois tipos de Private Service Connect, e os diferentes serviços podem ser publicados como um dos dois:
Os serviços publicados como endpoints do Private Service Connect podem ser consumidos diretamente por outras cargas de trabalho. Os serviços dependem da autenticação e resiliência provisionadas pelo produtor do serviço. Se você quiser mais controle sobre a autenticação e a resiliência do serviço, use os back-ends do Private Service Connect para adicionar uma camada de balanceamento de carga para autenticação e resiliência na rede do consumidor.
O diagrama a seguir mostra os serviços sendo acessados por endpoints do Private Service Connect:
O diagrama mostra o seguinte padrão:
- Um endpoint do Private Service Connect é implantado na VPC do consumidor, o que disponibiliza o serviço do produtor para VMs e nós do GKE.
- As redes do consumidor e do produtor precisam ser implantadas na mesma região.
O diagrama anterior mostra os endpoints como recursos regionais. Os endpoints podem ser acessados de outras regiões devido ao acesso global.
Para mais informações sobre padrões de implantação, consulte Padrões de implantação do Private Service Connect.
Os back-ends do Private Service Connect usam um balanceador de carga configurado com back-ends de grupo de endpoints da rede (NEG, na sigla em inglês) do Private Service Connect. Para conferir uma lista de balanceadores de carga compatíveis, consulte Sobre back-ends do Private Service Connect.
Os back-ends do Private Service Connect permitem criar as seguintes configurações de back-end:
- Domínios e certificados do cliente na frente de serviços gerenciados
- Failover controlado pelo consumidor entre serviços gerenciados em diferentes regiões
- Configuração centralizada de segurança e controle de acesso para serviços gerenciados
No diagrama a seguir, o balanceador de carga global usa um NEG do Private Service Connect como um back-end que estabelece a comunicação com o provedor de serviços. Nenhuma outra configuração de rede é necessária, e os dados são transmitidos pelo fabric de SDN do Google.
A maioria dos serviços é projetada para conexões iniciadas pelo consumidor. Quando os serviços precisam iniciar conexões do produtor, use interfaces do Private Service Connect.
Uma consideração importante ao implantar o acesso a serviços particulares ou o Private Service Connect é a transitividade. Geralmente, não é possível acessar os serviços publicados em uma conexão de peering de rede VPC ou pelo Network Connectivity Center. A localização da sub-rede de acesso a serviços ou dos endpoints na topologia da VPC determina se você projeta a rede para implantação de serviços compartilhada ou dedicada.
Opções como VPN de alta disponibilidade e proxies gerenciados pelo cliente fornecem métodos para permitir comunicação transitiva entre VPCs.
Os endpoints do Private Service Connect não podem ser acessados pelo peering de rede VPC. Se você precisar desse tipo de conectividade, implante um balanceador de carga interno e um NEG do Private Service Connect como back-end, conforme mostrado no diagrama a seguir:
As APIs do Google podem ser acessadas de forma privada usando endpoints e back-ends do Private Service Connect. O uso de endpoints geralmente é recomendado, já que o produtor de API do Google oferece resiliência e autenticação baseada em certificado.
Crie um endpoint do Private Service Connect em cada VPC em que o serviço precisa ser acessado. Como o endereço IP do consumidor é um endereço IP global particular, é necessário um único mapeamento de DNS para cada serviço, mesmo que haja instâncias de endpoint em várias VPCs, conforme mostrado no diagrama abaixo:
Definir padrões de consumo de serviço
Os serviços podem ser executados em vários locais: sua rede VPC, outra rede VPC, um data center local ou na nuvem. Independentemente de onde a carga de trabalho do serviço é executada, o aplicativo consome esses serviços usando um ponto de acesso, como um destes:
- Um endereço IP em uma sub-rede de acesso a serviços particulares
- Um endpoint do Private Service Connect
- Um VIP para um balanceador de carga que usa NEGs do Private Service Connect
Os pontos de acesso do consumidor podem ser compartilhados entre redes ou dedicados a uma única rede. Decida se você vai criar pontos de acesso compartilhados ou dedicados de consumidores com base na delegação da tarefa de criar pontos de acesso de serviço de consumidores para cada grupo de aplicativos ou no gerenciamento do acesso a serviços de maneira consolidada.
O gerenciamento do acesso a serviços envolve as seguintes atividades:
- Como criar os pontos de acesso
- Implantar os pontos de acesso em uma VPC com o tipo de acessibilidade adequado
- Como registrar os endereços IP e URLs dos pontos de acesso do consumidor no DNS
- Gerenciar certificados de segurança e resiliência para o serviço no espaço do consumidor, ao adicionar balanceamento de carga na frente dos pontos de acesso do consumidor
Para algumas organizações, pode ser viável atribuir o gerenciamento de acesso a um serviço a uma equipe central, enquanto outras podem ser estruturadas para dar mais independência a cada equipe de consumidor ou aplicativo. Um subproduto de operar no modo dedicado é que alguns dos elementos são replicados. Por exemplo, um serviço é registrado com vários nomes DNS por cada grupo de aplicativos e gerencia vários conjuntos de certificados TLS.
O design da VPC descrito em Segmentação de rede e conectividade para aplicativos distribuídos em rede entre nuvens permite a acessibilidade para implantar pontos de acesso de serviço no modo compartilhado ou dedicado. Os pontos de acesso compartilhados do consumidor são implantados em VPCs de serviço, que podem ser acessados de qualquer outra VPC ou rede externa. Os pontos de acesso dedicados do consumidor são implantados em VPCs de aplicativos, que só podem ser acessados por recursos dentro dessa VPC.
A principal diferença entre uma VPC de serviço e uma VPC de aplicativo é a conectividade transitiva do ponto de acesso a serviços que uma VPC de serviço permite. As VPCs de serviço não são limitadas a hospedar pontos de acesso do consumidor. Uma VPC pode hospedar recursos de aplicativos, bem como pontos de acesso de consumidor compartilhados. Nesse caso, a VPC precisa ser configurada e gerenciada como uma VPC de serviço.
Acesso compartilhado a serviços gerenciados
Para todos os métodos de consumo de serviço, incluindo o Private Service Connect, faça o seguinte:
- Implante os pontos de acesso do consumidor de serviços em uma VPC de serviços. As VPCs de serviço têm acessibilidade transitiva a outras VPCs.
- Divulgue a sub-rede do ponto de acesso do consumidor como uma divulgação de rota personalizada do Cloud Router que faz peering com outras redes por HA-VPN. Para APIs do Google, anuncie o endereço IP do host da API.
- Atualize as regras de firewall multicloud para permitir que a sub-rede de acesso a serviços particulares seja acessada.
Para o Acesso privado a serviços, confira se você pode atender aos seguintes requisitos:
- Exporte rotas personalizadas para a rede do produtor de serviço. Para mais informações, consulte Hosts locais não podem se comunicar com a rede do produtor de serviço.
- Crie regras de firewall de entrada para permitir que a sub-rede de acesso a serviços particulares entre nas VPCs do aplicativo
- Crie regras de firewall de entrada para permitir que a sub-rede de acesso a serviços privados acesse a VPC de serviços
Para o acesso a serviços sem servidor, verifique se você atende aos seguintes requisitos:
- O conector de acesso requer uma sub-rede normal /28 dedicada
- O Cloud Router anuncia sub-redes normais por padrão
- Crie regras de firewall de entrada para permitir a sub-rede de acesso da VPC nas VPCs.
- Atualizar as regras de firewall multicloud para permitir a sub-rede do conector de acesso à VPC
- Crie regras de firewall de entrada para permitir que as sub-redes de acesso a serviços particulares entrem nas VPCs do aplicativo.
Acesso a serviços gerenciados dedicados
Faça o seguinte:
- Em cada VPC de aplicativo em que o acesso é necessário, implante uma regra de encaminhamento para o serviço criar um ponto de acesso.
- Para o acesso a serviços particulares, crie regras de firewall de entrada para permitir que a sub-rede de acesso a serviços particulares entre nas VPCs do aplicativo.
Para o acesso a serviços sem servidor, verifique se você atende aos 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 conector de acesso à VPC nas VPCs do aplicativo.
Montar a pilha de aplicativos
Esta seção descreve como montar uma pilha de aplicativos regional ou global.
Projetar pilhas de aplicativos regionais
Quando um aplicativo segue os arquétipos de implantação regional ou multirregional, use pilhas de aplicativos regionais. As pilhas de aplicativos regionais podem ser consideradas uma concatenação de camadas de serviço de aplicativos regionais. Por exemplo, uma camada de serviço da Web regional que se comunica com uma camada de aplicativo na mesma região, que, por sua vez, se comunica com uma camada de banco de dados na mesma região, é uma pilha de aplicativos regional.
Cada camada de serviço de aplicativo regional usa balanceadores de carga para distribuir o tráfego entre os endpoints da camada nessa região. A confiabilidade é conseguida distribuindo os recursos de back-end em três ou mais zonas na região.
As camadas de serviço de aplicativo em outros CSPs ou data centers locais precisam ser implantadas 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 aplicativos em uma região, os URLs da camada de serviço do aplicativo precisam ser resolvidos para o endereço IP regional do front-end do balanceador de carga específico. Esses mapeamentos DNS são registrados na zona DNS relevante para cada serviço de aplicativo.
O diagrama a seguir mostra uma pilha regional com resiliência ativo-standby:
Uma instância completa da pilha de aplicativos é implantada em cada região nos diferentes data centers de nuvem. Quando ocorre uma falha regional em qualquer uma das camadas de serviço do aplicativo, a pilha na outra região assume a entrega de todo o aplicativo. Esse failover é feito em resposta ao monitoramento fora da banda das diferentes camadas de serviço do aplicativo.
Quando uma falha é informada para uma das camadas de serviço, o front-end do aplicativo é reancorado na pilha de backup. O aplicativo é escrito para referenciar um conjunto de registros de nome regional que refletem a pilha de endereços IP regional no DNS para que cada camada do aplicativo mantenha as conexões na mesma região.
Projetar pilhas de aplicativos globais
Quando um aplicativo segue o arquétipo de implantação global, cada camada de serviço do aplicativo inclui back-ends em várias regiões. A inclusão de back-ends em várias regiões expande o pool de resiliência para a camada de serviço do aplicativo além de uma única região e permite a detecção e reconvergência automática de failover.
O diagrama a seguir mostra uma pilha de aplicativos global:
O diagrama anterior mostra um aplicativo global montado com os seguintes componentes:
- Serviços em execução em data centers locais com front-ends de balanceadores de carga. Os pontos de acesso do balanceador de carga podem ser acessados pelo Cloud Interconnect da VPC de trânsito.
- Uma VPC de trânsito hospeda conexões híbridas entre o data center externo e a VPC do aplicativo.
- Uma VPC de aplicativo que hospeda o aplicativo principal em execução nas instâncias de carga de trabalho. Essas instâncias de carga de trabalho estão por trás dos balanceadores de carga. Os balanceadores de carga podem ser acessados de qualquer região da rede e podem alcançar back-ends em qualquer região da rede.
- Uma VPC de serviços que hospeda pontos de acesso para serviços em execução em outros locais, como em VPCs de terceiros. Esses pontos de acesso a serviços podem ser acessados pela conexão VPN de alta disponibilidade entre a VPC de serviços e a VPC de trânsito.
- VPCs de produtores de serviços hospedados por outras organizações ou pela organização principal e aplicativos executados em outros locais. Os serviços relevantes podem ser acessados por back-ends do Private Service Connect implantados como back-ends globais para balanceadores de carga regionais hospedados na VPC de serviços. Os balanceadores de carga regionais podem ser acessados de qualquer outra região.
Se você quiser que o aplicativo criado seja acessível pela Internet, adicione um balanceador de carga de aplicativo externo global que aponte para as cargas de trabalho do aplicativo na VPC do aplicativo (não mostrada no diagrama).
Para oferecer suporte a uma pilha de aplicativos global, usamos back-ends globais para cada camada do aplicativo. Isso permite a recuperação de uma falha de todos os endpoints de back-end em uma região. Cada região tem um front-end do balanceador de carga regional para cada camada de serviço do aplicativo. Quando ocorre um failover regional, os front-ends regionais do balanceador de carga podem ser acessados em todas as regiões, porque eles usam o acesso global. Como a pilha de aplicativos é global, as políticas de roteamento de geolocalização de DNS são usadas para selecionar o front-end regional mais adequado para uma solicitação ou fluxo específico. Em caso de falha no front-end, as verificações de integridade do DNS podem ser usadas para automatizar o failover de um front-end para outro.
Os serviços publicados usando back-ends do Private Service Connect se beneficiam do acesso global do Private Service Connect. Esse recurso permite que um back-end do Private Service Connect seja acessível de qualquer região e reduz as interrupções causadas por falhas na camada de serviço do aplicativo. Isso significa que os back-ends do Private Service Connect podem ser aproveitados como back-ends globais, conforme descrito em Determinar o escopo do serviço: regional ou global.
Fornecer acesso particular a serviços hospedados em redes externas
Talvez você queira publicar um ponto de acesso local para um serviço hospedado em outra rede. Nesses casos, é possível usar um balanceador de carga de proxy TCP regional interno com NEGs híbridos. É possível criar um serviço hospedado no local ou em outros ambientes de nuvem disponíveis para clientes na sua rede VPC, conforme mostrado no diagrama a seguir:
Se você quiser disponibilizar o serviço híbrido em uma rede VPC diferente da que hospeda o balanceador de carga, use o Private Service Connect para publicar o serviço. Ao colocar um anexo de serviço na frente do balanceador de carga do proxy TCP regional externo, é possível permitir que clientes em outras redes VPC alcancem os serviços híbridos executados no local ou em outros ambientes de nuvem.
Em um ambiente de várias nuvens, o uso de um NEG híbrido permite uma comunicação segura entre aplicativos.
Quando uma organização diferente publica um serviço de aplicativo, use um NEG híbrido para estender as abstrações de acesso particular para esse serviço. O diagrama a seguir ilustra esse cenário:
No diagrama anterior, a camada de serviço do aplicativo é totalmente composta no CSP vizinho, que é destacado nas partes do diagrama que não estão esmaecidas. Os balanceadores de carga híbridos são usados em conjunto com anexos de serviço do Private Service Connect como um mecanismo para publicar o serviço de aplicativo externo para consumo privado no Google Cloud. Os balanceadores de carga híbridos com NEGs híbridos e anexos de serviço do Private Service Connect estão em uma VPC que faz parte de um projeto de produtor de serviços. Esse projeto de produtor de serviços geralmente pode ser uma VPC diferente da VPC de trânsito, porque está no escopo administrativo da organização ou do projeto do produtor e, portanto, separado dos serviços de trânsito comuns. A VPC do produtor não precisa estar conectada por peering de VPC ou VPN de alta disponibilidade com a VPC do consumidor (que é a VPC compartilhada de serviços no diagrama).
Centralizar o acesso a serviços
O acesso ao serviço pode ser centralizado em uma rede VPC e acessado de outras redes de aplicativos. O diagrama a seguir mostra o padrão comum que permite a centralização dos pontos de acesso:
O diagrama a seguir mostra todos os serviços que estão sendo acessados de uma VPC de serviços dedicados:
Quando os serviços são apresentados com balanceadores de carga de aplicativo, é possível consolidar em menos balanceadores de carga usando mapas de URL para direcionar o tráfego de diferentes back-ends de serviço em vez de usar balanceadores de carga diferentes para cada serviço. Em princípio, uma pilha de aplicativos pode ser totalmente composta usando um único balanceador de carga de aplicativo, além de back-ends de serviço e mapeamentos de URL adequados.
Nesta implementação, é necessário usar NEGs híbridas nas VPCs para a maioria dos tipos de back-end. A exceção é um NEG ou back-end do Private Service Connect, conforme descrito em Vinculação explícita de balanceadores de carga L7 do Google Cloud com o Private Service Connect.
O uso de NEGs híbridas nas VPCs é feito à custa de desconsiderar o autohealing e o escalonamento automático dos back-ends. Os serviços publicados já têm um balanceador de carga no locatário do produtor que oferece escalonamento automático. Portanto, você só vai encontrar as limitações dos NEGs híbridos se centralizar a função de balanceamento de carga para camadas de serviço sendo compostas de forma nativa, em vez de consumir da publicação.
Ao usar esse padrão de rede de serviços, lembre-se de que os serviços são consumidos por uma camada adicional de balanceamento de carga.
Use o balanceamento de carga de proxy para aproveitar os benefícios de escalonamento da conectividade de spoke do Network Connectivity Center em várias VPCs, além de fornecer conectividade transitiva para serviços publicados pelos balanceadores de carga de proxy.
Os endpoints de serviço do Private Service Connect e as regras de encaminhamento para acesso a serviços particulares não podem ser acessados nas VPCs de aro do Network Connectivity Center. Da mesma forma, as redes por trás de conexões híbridas (Cloud Interconnect ou VPN de alta disponibilidade) não podem ser alcançadas nas VPCs de spoke do Network Connectivity Center, porque as rotas dinâmicas não são propagadas pelo Network Connectivity Center.
Essa falta de transitividade pode ser superada com a implantação de balanceadores de carga de proxy com os recursos não transitivos processados como NEGs híbridos. Assim, podemos implantar balanceadores de carga de proxy na frente dos front-ends do serviço e dos workloads acessíveis nas conexões híbridas.
Os front-ends do proxy do balanceador de carga são implantados em sub-redes VPC que são propagadas entre VPCs spoke do Network Connectivity Center. Essa propagação permite a acessibilidade no Network Connectivity Center dos recursos não transitivos pelos balanceadores de carga de proxy.
O modo centralizado adiciona uma camada de balanceamento de carga no lado do consumidor do serviço. Ao usar esse modo, você também precisa gerenciar certificados, resiliência e mapeamentos de DNS adicionais no projeto do consumidor.
Outras considerações
Esta seção contém considerações sobre produtos e serviços comuns que não são explicitamente abordados neste documento.
Considerações sobre o plano de controle do GKE
O plano de controle do GKE é implantado em um projeto de locatário gerenciado pelo Google conectado à VPC do cliente usando o peering de rede VPC. Como o peering de rede VPC não é transitivo, não é possível estabelecer comunicação direta com o plano de controle por meio de uma topologia de rede VPC hub e spoke.
Ao considerar opções de design do GKE, como centralizada ou descentralizada, o acesso direto ao plano de controle de fontes multi-cloud é uma consideração importante. Se o GKE for implantado em uma VPC centralizada, o acesso ao plano de controle estará disponível em todas as nuvens e no Google Cloud. No entanto, se o GKE for implantado em VPCs descentralizadas, não será possível a comunicação direta com o plano de controle. Se os requisitos de uma organização exigirem acesso ao plano de controle do GKE, além de adotar o padrão de design descentralizado, os administradores de rede poderão implantar um agente de conexão que atua como um proxy, superando a limitação de peering não transitivo para o plano de controle do GKE.
Segurança - VPC Service Controls
Para cargas de trabalho que envolvem dados confidenciais, use o VPC Service Controls para configurar os perímetros de serviço em torno dos recursos VPC e dos serviços gerenciados pelo Google e para controlar a movimentação de dados no limite do perímetro. Com o VPC Service Controls, é possível agrupar projetos e sua rede local em um único perímetro que impede o acesso a dados por meio de serviços gerenciados pelo Google. As regras de entrada e saída do VPC Service Controls podem ser usadas para permitir que projetos e serviços em diferentes perímetros de serviço se comuniquem (incluindo redes VPC que não estão dentro do perímetro).
Para arquiteturas de implantação recomendadas, um processo de integração abrangente e práticas recomendadas operacionais, consulte as Práticas recomendadas do VPC Service Controls para empresas e o Blueprint de bases de segurança.
DNS para APIs/serviços
Os produtores de serviços podem publicar serviços usando o Private Service Connect. O produtor de serviços tem a opção de 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ço criar um endpoint para esse serviço, o Private Service Connect e o Diretório de serviços vão criar automaticamente entradas DNS para o serviço em uma zona DNS particular na rede VPC do consumidor de serviço.
A seguir
- Projete a segurança de rede para aplicativos de rede entre nuvens.
- Saiba mais sobre os produtos do Google Cloud usados neste guia de design:
- Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.
Colaboradores
Autores:
- Victor Moreno | Gerente de produtos, Cloud Networking
- Ghaleb Al-habian | Especialista em rede
- Deepak Michael | Engenheiro de clientes especialista em rede
- Osvaldo Costa | Engenheiro de clientes especialista em rede
- Jonathan Almaleh | Consultor de soluções técnicas da equipe
Outros colaboradores:
- Zach Seils | Especialista em rede
- Christopher Abraham | Engenheiro de clientes especialista em rede
- Emanuele Mazza | Especialista em produtos de rede
- Aurélien Legrand | Engenheiro de nuvem estratégico
- Eric Yu | Engenheiro de clientes especialista em rede
- Kumar Dhanagopal | Desenvolvedor de soluções para vários produtos
- Mark Schlagenhauf | Redator técnico, Rede
- Marwan Al Shawi | Engenheiro de clientes do parceiro
- Ammett Williams | Engenheiro de relações com desenvolvedores