Topologias de rede híbridas e em várias nuvens

Este artigo é a terceira parte de uma série em que discutimos implementações híbridas e em várias nuvens, padrões de arquitetura e topologias de rede. Esta parte explora as topologias de rede comuns que você pode usar para configurações híbridas e em várias nuvens. O artigo descreve em quais cenários e padrões de arquitetura essas topologias são mais adequadas e fornece práticas recomendadas para implementá-las usando o Google Cloud Platform (GCP).

A série consiste nestas partes:

Conectar ambientes de computação particulares ao GCP de maneira segura e confiável é fundamental para qualquer implantação híbrida ou em várias nuvens bem-sucedida. A topologia de rede escolhida para uma configuração híbrida e em várias nuvens precisa atender aos requisitos exclusivos de suas cargas de trabalho corporativas e aos padrões de arquitetura que você pretende aplicar. Cada topologia pode precisar de adaptações, mas há topologias comuns que podem ser usadas como blueprint.

Espelhada

A ideia da topologia espelhada é fazer com que o ambiente de computação em nuvem e o ambiente de computação particular se espelhem mutuamente. Essa topologia se aplica principalmente a configurações que seguem o padrão de ambiente híbrido, em que você executa cargas de trabalho de desenvolvimento e teste em um ambiente enquanto executa cargas de trabalho de preparo e produção no outro.

As cargas de trabalho de teste e produção não devem se comunicar diretamente umas com as outras. No entanto, é preciso que você possa gerenciar e implantar os dois grupos de cargas de trabalho de maneira consistente. Assim, você conecta os dois ambientes de computação de maneira a atender aos seguintes requisitos:

  • A integração contínua/implantação contínua (CI/CD, na sigla em inglês) e os sistemas administrativos podem implantar e gerenciar cargas de trabalho em ambientes de computação.
  • O monitoramento e outras ferramentas administrativas funcionam entre os dois ambientes de computação.
  • As cargas de trabalho não podem se comunicar entre os ambientes de computação.

Arquitetura de referência

O diagrama a seguir mostra uma arquitetura de referência que atende a esses requisitos.

arquitetura de referência que atende aos requisitos anteriores

  • No GCP, você usa duas nuvens privadas virtuais (VPCs, na sigla em inglês) separadas: uma VPC compartilhada para cargas de trabalho de desenvolvimento e teste e outra VPC para todas as ferramentas administrativas e de CI/CD. As duas VPCs têm peering, o que permite a comunicação entre as VPCs com endereços IP internos. O peering permite que a CI/CD e os sistemas administrativos implantem e gerenciem cargas de trabalho de desenvolvimento e teste.
  • Além disso, você conecta a VPC de CI/CD à rede que executa as cargas de trabalho de produção no ambiente de computação particular. Para estabelecer essa conexão, use o Cloud Interconnect ou o Cloud VPN. Essa conexão permite implantar e gerenciar cargas de trabalho de produção.
  • Como o peering de VPC não é transitivo, as cargas de trabalho de produção e as de desenvolvimento e teste não podem se comunicar entre si.
  • Todos os ambientes compartilham um espaço de endereços IP RFC 1918 comum e sem sobreposições.

Variações

Uma variação dessa topologia é usar VPCs separadas para desenvolvimento e diferentes estágios de teste, todas em peering com a VPC de CI/CD.

Ao executar cargas de trabalho baseadas em VM, também pode ser útil executar agentes de CI em cada ambiente que assume a função de conduzir implantações. Dependendo dos recursos do seu sistema de CI, o uso de agentes pode permitir que você bloqueie ainda mais a comunicação entre os ambientes e reforce o controle sobre quais sistemas podem se comunicar uns com os outros.

O diagrama a seguir mostra um exemplo dessa variação.

Topologia espelhada com agentes

Ao executar exclusivamente cargas de trabalho do Kubernetes, talvez não seja preciso fazer peering das duas VPCs. Como o plano de controle do Google Kubernetes Engine (GKE) é público, você pode usar o recurso de redes mestre autorizadas e o RBAC para garantir que somente os sistemas de CI tenham permissão para realizar implantações. O diagrama a seguir mostra essa topologia.

Topologia espelhada

Práticas recomendadas

  • Garanta que todos os sistemas de CI/CD necessários para implantar ou reconfigurar implantações de produção sejam implementados com alta disponibilidade. Além disso, pense em usar links de rede privada virtual (VPN) redundantes ou de interconexão para aumentar a disponibilidade.
  • Configure as instâncias de VM na VPC de desenvolvimento e teste para que tenham endereços IP públicos, de modo que essas instâncias possam acessar a Internet diretamente. Como alternativa, implante gateways NAT na mesma VPC para lidar com o tráfego de saída.
  • Para usar redes públicas, use o Acesso particular do Google para evitar a comunicação entre as cargas de trabalho de VPC e as APIs do Google.
  • Siga também as práticas recomendadas gerais para topologias de rede híbridas e em várias nuvens.

Em malha

A ideia da topologia em malha é estabelecer uma rede simples que abranja vários ambientes de computação e em que todos os sistemas possam se comunicar entre si. Esta topologia aplica-se principalmente a configurações em níveis, particionadas ou de bursting e exige que você conecte ambientes de computação de maneira a atender aos seguintes requisitos:

  • As cargas de trabalho podem se comunicar entre si nos limites do ambiente por UDP ou TCP, usando endereços IP privados RFC 1918.

  • Você pode usar regras de firewall para restringir fluxos de tráfego de maneira refinada, entre ambientes de computação e dentro deles.

Arquitetura de referência

O diagrama a seguir mostra uma arquitetura de referência que atende a esses requisitos.

arquitetura de referência em malha

  • No lado do GCP, as cargas de trabalho são implantadas em uma única VPC compartilhada.

  • A VPC se conecta à rede no ambiente de computação particular por meio do Cloud Interconnect ou do Cloud VPN. Essa configuração garante que a comunicação entre os ambientes possa ser realizada com endereços IP privados.

  • O Cloud Router é usado para trocar rotas dinamicamente entre ambientes.

  • Todos os ambientes compartilham um espaço de endereços IP RFC 1918 comum e sem sobreposições.

Variações

Você pode implementar outra inspeção profunda de pacotes ou mecanismos avançados de firewall que excedam os recursos das regras de firewall do GCP. Para implementar esses mecanismos, estenda a topologia para passar todo o tráfego entre ambientes por meio de um dispositivo de firewall, conforme mostrado no diagrama a seguir.

topologia em malha estendida

  • Você estabelece a VPN ou o link de interconexão entre uma VPC de trânsito dedicada e a VLAN no ambiente de computação particular.

  • Estabeleça a conexão entre a VPC de trânsito e a VPC do aplicativo por meio das VMs que executam o dispositivo de firewall. Configure essas VMs para encaminhamento de IP. As VMs usam mais de uma interface de rede: uma conectada à VPC de trânsito e uma à VPC do aplicativo.

  • O dispositivo de firewall também pode servir como um gateway NAT para as instâncias de VM que são implantadas na VPC do aplicativo. Esse gateway permite que as instâncias acessem a Internet sem precisar de endereços IP públicos.

Práticas recomendadas

Saída controlada

A ideia da topologia de saída controlada é expor as APIs selecionadas do ambiente de computação particular às cargas de trabalho implantadas no GCP sem expô-las à Internet pública. Você pode facilitar essa exposição limitada por meio de um gateway de API que serve como fachada para as cargas de trabalho existentes. O gateway é implantado em uma DMZ durante a implantação das cargas de trabalho reais em uma rede dedicada e altamente segura no ambiente de computação particular.

A topologia de saída controlada se aplica principalmente às configurações em níveis e requer que os ambientes de computação sejam conectados de maneira a atender aos seguintes requisitos:

  • As cargas de trabalho implantadas no GCP podem se comunicar com o gateway de API usando endereços IP privados. Outros sistemas no ambiente de computação particular não podem ser acessados de dentro do GCP.

  • Não é permitida a comunicação do ambiente de computação particular com nenhuma carga de trabalho implantada no GCP.

Arquitetura de referência

O diagrama a seguir mostra uma arquitetura de referência que atende a esses requisitos:

topologia de saída controlada

  • No lado do GCP, as cargas de trabalho são implementadas em uma VPC compartilhada.

  • A VPC é conectada a um DMZ no ambiente de computação particular usando o Cloud Interconnect ou o Cloud VPN, permitindo chamadas para o gateway de API.

  • As conexões de entrada com a VPC são bloqueadas por meio de regras de firewall.

  • Opcionalmente, use o Cloud Router para trocar rotas dinamicamente entre ambientes.

  • Todos os ambientes compartilham um espaço de endereços IP RFC 1918 comum e sem sobreposições.

Variações

Para acessar a Internet, as instâncias de VM implantadas na VPC do aplicativo precisam ter endereços IP externos. Para evitar definir esses endereços externos, você pode implantar gateways NAT na mesma VPC, como mostra o diagrama a seguir.

variações na topologia de saída controlada

Práticas recomendadas

Entrada controlada

A ideia da topologia de entrada controlada é expor as APIs selecionadas de cargas de trabalho em execução no GCP ao ambiente de computação particular sem expô-las à Internet pública. Essa topologia é a contrapartida do cenário de saída controlada e é adequada para cenários híbridos de borda.

Você expõe APIs selecionadas por meio de um gateway de API acessível para o ambiente de computação particular, da seguinte maneira:

  • As cargas de trabalho implantadas no ambiente de computação particular podem se comunicar com o gateway de API usando endereços IP privados. Não é possível acessar outros sistemas implantados no GCP.

  • Não é permitida a comunicação do GCP com o ambiente de computação particular.

Arquitetura de referência

O diagrama a seguir mostra uma arquitetura de referência que atende a esses requisitos.

topologia de entrada controlada

  • No lado do GCP, as cargas de trabalho são implantadas em uma VPC de aplicativo.

  • Uma conexão do Cloud Interconnect ou Cloud VPN é estabelecida entre uma VPC de trânsito dedicada e o ambiente de computação particular.

  • Estabeleça a conexão entre a VPC de trânsito e a VPC do aplicativo por meio das VMs que executam o gateway de API. Essas VMs usam duas interfaces de rede: uma conectada à VPC de trânsito, e outra à VPC do aplicativo. Para equilibrar o tráfego entre várias instâncias de gateway de API, configure um balanceador de carga interno na VPC de trânsito.

  • Implante um gateway NAT na VPC de aplicativo para permitir que as cargas de trabalho acessem a Internet. Esse gateway evita a necessidade de equipar instâncias de VMs com endereços IP externos, o que não é desejável em sistemas implantados por trás de um gateway de API.

  • Você também pode usar o Cloud Router para trocar rotas dinamicamente entre ambientes.

  • Todos os ambientes compartilham um espaço de endereços IP RFC 1918 comum e sem sobreposições.

Práticas recomendadas

Entrada e saída controladas

Combinar entrada e saída controladas permite o uso bidirecional de APIs selecionadas entre cargas de trabalho em execução no GCP e em um ambiente de computação particular. Em ambos os lados, você usa gateways de API para expor APIs selecionadas e, opcionalmente, autenticar, autorizar e auditar chamadas.

A comunicação da API funciona da seguinte maneira:

  • As cargas de trabalho implantadas no GCP podem se comunicar com o gateway de API usando endereços IP privados. Não é possível acessar outros sistemas implantados no ambiente de computação particular.

  • Por outro lado, as cargas de trabalho implantadas no ambiente de computação particular podem se comunicar com o gateway de API no lado do GCP usando endereços IP privados. Não é possível acessar outros sistemas implantados no GCP.

Arquitetura de referência

O diagrama a seguir mostra uma arquitetura de referência para a topologia de entrada e saída controladas.

topologia de entrada e saída controladas

  • No lado do GCP, as cargas de trabalho são implantadas em uma VPC compartilhada e não são expostas à Internet.

  • Uma conexão do Cloud Interconnect ou Cloud VPN é estabelecida entre uma VPC de trânsito dedicada e o ambiente de computação particular.

  • Estabeleça a conexão entre a VPC de trânsito e a VPC do aplicativo por meio das VMs que executam o gateway de API. Essas VMs usam duas interfaces de rede: uma conectada à VPC de trânsito, e outra à VPC do aplicativo. Para equilibrar o tráfego entre várias instâncias de gateway de API, configure um balanceador de carga interno na VPC de trânsito.

  • Também são usadas instâncias de VM que servem como um gateway NAT que se conecta a ambas as VPCs. Essas instâncias permitem que cargas de trabalho acessem a Internet e se comuniquem com o gateway de API que está sendo executado no ambiente de computação particular.

  • Você também pode usar o Cloud Router para trocar rotas dinamicamente entre ambientes.

  • Todos os ambientes compartilham um espaço de endereços IP RFC 1918 comum e sem sobreposições.

Práticas recomendadas

Handover

A ideia da topologia de handover é usar os serviços de armazenamento oferecidos pelo GCP para conectar um ambiente de computação particular a projetos no GCP. Essa topologia se aplica principalmente a configurações que seguem o padrão de análise, em que:

  • As cargas de trabalho em execução em um ambiente de computação particular fazem upload dos dados para locais de armazenamento compartilhado. Dependendo dos casos de uso, os uploads podem ocorrer em massa ou em pequenas mensagens.

  • As cargas de trabalho hospedadas pelo GCP consomem dados desses locais e os processam por streaming ou em lote.

Arquitetura de referência

O diagrama a seguir mostra uma arquitetura de referência para a topologia de handover.

arquitetura de referência para a topologia de handover

  • No lado do GCP, as cargas de trabalho são implantadas em uma VPC de aplicativo. Elas podem incluir aplicativos front-end de processamento de dados, análise e relativos a análises.

  • Para expor aplicativos front-end com segurança a usuários corporativos, você pode usar o Cloud Identity-Aware Proxy.

  • Use um conjunto de intervalos do Cloud Storage ou do Cloud Pub/Sub para carregar dados do ambiente de computação particular e disponibilizá-los para processamento adicional pelas cargas de trabalho implantadas no GCP. Com as políticas de IAM, você pode restringir o acesso a cargas de trabalho confiáveis.

  • Como não há conectividade de rede privada entre os ambientes, os espaços de endereço IP RFC 1918 podem se sobrepor entre os ambientes.

Práticas recomendadas

Práticas recomendadas para topologias de rede híbridas e em várias nuvens

  • No lado do Google Cloud Platform, use VPCs compartilhadas. Uma VPC compartilhada é uma VPC que pode ser usada em vários projetos do Google Cloud Platform, evitando a necessidade de manter várias VPCs individuais. As VPCs compartilhadas também permitem gerenciar configurações de peering, sub-redes, regras de firewall e permissões de maneira centralizada.

  • Ao gerenciar regras de firewall, prefira usar a filtragem baseada em conta de serviço em vez da filtragem baseada em tag de rede.

  • Evite usar VPCs para isolar cargas de trabalho individuais umas das outras. Em vez disso, prefira usar sub-redes e regras de firewall. Ao usar o GKE, você pode complementar essa abordagem usando políticas de rede.

  • O Cloud VPN garante a criptografia do tráfego entre ambientes, mas o Cloud Interconnect não. Para proteger a comunicação entre cargas de trabalho, use TLS (Transport Layer Security).

  • Siga nossas práticas recomendadas para criar VPNs de alta capacidade.

  • Reserve espaço suficiente do intervalo de endereços IP RFC 1918 existente para acomodar todos os sistemas hospedados em nuvem.

  • Ao usar o GKE, pense em usar clusters particulares e esteja atento aos requisitos de tamanho da rede.

  • Use o Acesso particular do Google para que não seja necessário que as instâncias de VMs em execução no GCP tenham um endereço IP externo atribuído para acessar os serviços do Google.

A seguir

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…