Arquitetura de rede hub-and-spoke

Last reviewed 2024-07-29 UTC

Neste documento, apresentamos duas opções de arquitetura para configurar uma topologia de rede "hub and spoke" no Google Cloud. Uma opção usa o recurso de peering de rede da nuvem privada virtual (VPC) e a outra usa o Cloud VPN.

As empresas podem separar cargas de trabalho em redes VPC individuais para fins de faturamento, isolamento de ambientes e outras considerações. No entanto, elas também precisam compartilhar recursos específicos entre essas redes, como um serviço compartilhado ou uma conexão com o local. Nesses casos, pode ser útil colocar o recurso compartilhado em uma rede do tipo hub e anexar as outras redes VPC como spokes. O diagrama a seguir mostra um exemplo da rede hub-and-spoke resultante, chamada frequentemente de topologia star.

Esquema de rede Hub-and-spoke.

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

Arquitetura usando peering de rede VPC

O diagrama a seguir mostra uma rede hub-and-spoke usando 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
  • Nesta arquitetura, os recursos que precisam do isolamento no nível da rede usam redes VPC spoke separadas. Por exemplo, a arquitetura mostra uma VM do Compute Engine na rede VPC spoke-1. A rede VPC spoke-2 tem uma VM do Compute Engine e um cluster do Google Kubernetes Engine (GKE).
  • Cada rede VPC spoke nessa arquitetura tem uma relação de peering com uma rede VPC hub central.
  • O peering de rede VPC não restringe a largura de banda da VM. Cada VM pode enviar tráfego com a largura de banda total associada a ela.
  • Cada rede VPC spoke tem um gateway NAT do Cloud para comunicação de saída com a Internet.
  • O peering de rede VPC não fornece avisos de rota transitiva. A menos que um mecanismo adicional seja usado, a VM na rede spoke-1 não pode enviar o tráfego para a VM na rede spoke-2. Para contornar essa restrição não transitiva, a arquitetura mostra a opção de usar o Cloud VPN para encaminhar rotas entre as redes. Neste exemplo, os túneis VPN entre a rede VPC spoke-2 e a rede VPC do tipo hub permitem a acessibilidade à rede VPC spoke-2 por meio de outros spokes. Se você precisar de conectividade entre apenas alguns spokes específicos, será possível fazer o peering desses pares de rede VPC diretamente.

Arquitetura usando o Cloud VPN

A escalonabilidade de uma topologia hub-and-spoke que usa peering de rede VPC está sujeita a limites do peering de redes 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. No diagrama a seguir, mostramos 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 recursos que precisam de isolamento em nível de rede usam redes VPC spoke separadas.
  • Os túneis VPN IPSec conectam cada rede VPC spoke a uma rede VPC do tipo hub.
  • Há uma zona particular de DNS na rede hub, uma zona de peering de DNS e uma zona particular em cada rede spoke.
  • A largura de banda entre as redes é limitada pela largura de banda total dos túneis.

Ao escolher entre as duas arquiteturas discutidas até agora, considere os méritos relativos do peering de rede VPC e do Cloud VPN:

  • O peering de redes VPC tem a restrição não transitiva, mas é compatível com a largura de banda total definida pelo tipo de máquina das VMs e outros fatores que determinam a largura de banda da rede. No entanto, é possível adicionar o roteamento transitivo adicionando túneis VPN.
  • O Cloud VPN permite o roteamento transitivo, mas a largura de banda total (entrada e saída) é limitada às larguras de banda dos túneis.

Alternativas de design

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

Conectividade entre spoke usando um gateway na rede VPC hub
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 hub para servir como um gateway para tráfego de spoke-to-spoke.
Peering de rede VPC sem um hub
Se você não precisa de controle centralizado sobre a conectividade local nem para o compartilhamento de serviços entre redes VPC, uma rede VPC hub não é necessária. É possível configurar o peering para os pares de rede VPC que exigem conectividade e gerenciar as interconexões individualmente. Considere os limites no número de relacionamentos de peering por rede VPC.
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 rede VPC compartilhada 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