Arquitetura de rede hub-and-spoke

Este documento apresenta três opções de arquitetura para configurar uma topologia de rede hub and spoke em Google Cloud. A primeira opção usa o Network Connectivity Center, a segunda usa o peering de rede VPC e a terceira usa o Cloud VPN.

Uma empresa pode separar cargas de trabalho em redes VPC individuais para fins de faturamento, isolamento de ambientes e outras considerações. No entanto, a empresa também pode precisar compartilhar recursos específicos entre essas redes, como um serviço compartilhado ou uma conexão local. Nesses casos, pode ser útil colocar o recurso compartilhado em uma rede hub (chamada de rede de roteamento no restante deste documento) e anexar as outras redes VPC como redes spoke (chamadas de redes de carga de trabalho no restante deste documento). O diagrama a seguir mostra uma rede hub-and-spoke com duas VPCs de carga de trabalho, mas é possível adicionar mais VPCs de carga de trabalho.

Esquema de rede Hub-and-spoke.

Neste exemplo, as redes VPC de carga de trabalho separadas são usadas para as cargas de trabalho de unidades de negócios individuais em uma grande empresa. Cada rede VPC de carga de trabalho está conectada a uma rede VPC de roteamento central que contém serviços compartilhados e pode servir como o único ponto de entrada para a nuvem da rede local da empresa.

Resumo das opções

Ao escolher uma das arquiteturas discutidas neste documento, considere os méritos relativos do Network Connectivity Center, do peering de rede VPC e do Cloud VPN:

  • O Network Connectivity Center oferece largura de banda total entre VPCs de carga de trabalho e transitividade entre VPCs de carga de trabalho.
  • O peering de rede VPC fornece largura de banda total entre as VPCs de carga de trabalho e a VPC de roteamento. Ele não oferece transitividade entre VPCs de carga de trabalho. O peering de rede VPC oferece suporte ao roteamento para NVAs em outras VPCs.
  • O Cloud VPN permite o roteamento transitivo, mas a largura de banda total (entrada e saída) entre as redes é limitada às larguras de banda dos túneis. É possível adicionar outros túneis para aumentar a largura de banda.

Arquitetura usando a central de conectividade de rede

O diagrama a seguir mostra uma rede hub-and-spoke que usa a Central de conectividade de rede.

Arquitetura hub-and-spoke usando o Network Connectivity Center.

O Network Connectivity Center tem um recurso de hub que fornece gerenciamento do plano de controle, mas não é uma rede hub para o plano de dados.

  • O Network Connectivity Center pode conectar as redes usando uma topologia em estrela (hub e spoke) ou de malha. O uso de uma topologia em estrela impede a comunicação entre spokes de VPC (VPC de carga de trabalho), enquanto a topologia de malha não impede.
  • A rede VPC de roteamento (hub) tem uma conexão local usando conexões do Cloud VPN ou do Cloud Interconnect.
  • As rotas dinâmicas podem ser propagadas em redes VPC.
  • As rotas do Private Service Connect são transitivas entre as VPCs de workloads.
  • As rotas de acesso a serviços particulares são transitivas entre VPCs de workloads pelo uso de raios de produtores para muitos serviços fornecidos pelo Google. Para serviços em que as rotas não são transitivas, uma solução alternativa é conectar a rede VPC do consumidor à rede VPC de roteamento usando o Cloud VPN em vez do Network Connectivity Center.
  • Todas as VMs nas redes com peering podem se comunicar com a largura de banda total delas.
  • Cada VPC de carga de trabalho e a rede VPC de roteamento têm um gateway do Cloud NAT para comunicação de saída com a Internet.
  • O peering e o encaminhamento de DNS são configurados para que as cargas de trabalho nas VPCs de carga de trabalho possam ser acessadas localmente.

Arquitetura usando peering de rede VPC

O diagrama a seguir mostra uma rede hub and spoke que usa o peering de rede VPC. O peering de rede VPC permite a comunicação por endereços IP internos entre recursos em redes VPC separadas. O tráfego permanece na rede interna do Google e não passa pela Internet pública.

Arquitetura "hub and spoke" usando o peering de rede VPC

  • Cada rede VPC de carga de trabalho (spoke) nessa arquitetura tem uma relação de peering com uma rede VPC de roteamento central (hub).
  • A rede VPC de roteamento tem uma conexão local usando conexões do Cloud VPN ou do Cloud Interconnect.
  • Todas as VMs nas redes com peering podem se comunicar com a largura de banda total delas.
  • As conexões de peering de rede VPC não são transitivas. Nessa arquitetura, as redes VPC locais e de carga de trabalho podem trocar tráfego com a rede de roteamento, mas não entre si. Para fornecer serviços compartilhados, coloque-os na rede de roteamento ou conecte-os à rede de roteamento usando o Cloud VPN.
  • Cada VPC de carga de trabalho e a rede VPC de roteamento têm um gateway do Cloud NAT para comunicação de saída com a Internet.
  • O peering e o encaminhamento de DNS são configurados para que as cargas de trabalho nas VPCs de cargas de trabalho possam ser acessadas localmente.

Arquitetura usando o Cloud VPN

A escalonabilidade de uma topologia hub and spoke que usa o peering de rede VPC está sujeita a limites do peering de rede VPC. E, como observado anteriormente, as conexões de peering de rede VPC não permitem tráfego transitivo além das duas redes VPC que estão em uma relação de peering. O diagrama a seguir mostra uma arquitetura de rede hub-and-spoke alternativa que usa o Cloud VPN para superar as limitações do peering de rede VPC.

Arquitetura "hub and spoke" usando o Cloud VPN

  • Os túneis VPN IPsec conectam cada rede VPC de carga de trabalho (spoke) a uma rede VPC de roteamento (hub).
  • Há uma zona particular de DNS na rede de roteamento e uma zona de peering de DNS e uma zona particular em cada rede de carga de trabalho.
  • As conexões são transitivas. As redes VPC locais e spoke podem se conectar pela rede de roteamento, embora isso possa ser restrito.
  • A largura de banda entre as redes é limitada pela largura de banda total dos túneis.
  • Cada VPC de carga de trabalho (spoke) e a rede VPC de roteamento têm um gateway do Cloud NAT para comunicação de saída com a Internet.
  • O peering de rede VPC não fornece avisos de rota transitiva.
  • O peering e o encaminhamento de DNS são configurados para que as cargas de trabalho em VPCs de carga de trabalho possam ser acessadas localmente.

Alternativas de design

Considere as seguintes alternativas arquiteturais para recursos de interconexão que são implantados em redes VPC separadas em Google Cloud:

Conectividade entre spokes usando um gateway na rede VPC de roteamento

Para ativar a comunicação entre spoke, implante um dispositivo virtual de rede (NVA) ou um firewall de última geração (NGFW) na rede VPC de roteamento para servir como um gateway para tráfego de spoke para spoke.

Várias redes VPC compartilhadas

Crie uma rede VPC compartilhada para cada grupo de recursos que você quer isolar no nível da rede. Por exemplo, para separar os recursos usados nos ambientes de produção e desenvolvimento, crie uma rede VPC compartilhada para produção e outra para desenvolvimento. Em seguida, faça o peering das duas redes VPC para ativar a comunicação entre redes VPC. Os recursos em projetos individuais para cada aplicativo ou departamento podem usar serviços da rede VPC compartilhada apropriada.

Para conectividade entre as redes VPC e sua rede local, é possível usar túneis VPN separados para cada rede VPC ou anexos da VLAN separados na mesma conexão da Interconexão dedicada.

A seguir