Quando cria a sua zona de destino, tem de escolher um design de rede adequado para a sua organização. Este documento descreve quatro designs de rede comuns e ajuda a escolher a opção que melhor satisfaz os requisitos da sua organização e a preferência da sua organização por um controlo centralizado ou descentralizado. Destina-se a engenheiros de rede, arquitetos e profissionais técnicos envolvidos na criação da arquitetura de rede para a zona de destino da sua organização.
Este artigo faz parte de uma série sobre as zonas de destino.
Escolha o design da rede
O design de rede que escolher depende principalmente dos seguintes fatores:
- Controlo centralizado ou descentralizado: consoante as preferências da sua organização, tem de escolher uma das seguintes opções:
- Centralize o controlo sobre a rede, incluindo o endereçamento IP, o encaminhamento e a configuração de firewall entre diferentes cargas de trabalho.
- Dê às suas equipas maior autonomia na execução dos seus próprios ambientes e na criação de elementos de rede nos respetivos ambientes.
- Opções de conetividade no local ou na nuvem híbrida: todas as conceções de rede abordadas neste documento oferecem acesso de ambientes no local a ambientes na nuvem através do Cloud VPN ou do Cloud Interconnect. No entanto, alguns designs requerem que configure várias ligações em paralelo, enquanto outros usam a mesma ligação para todas as cargas de trabalho.
- Requisitos de segurança: a sua organização pode exigir que o tráfego entre diferentes cargas de trabalho no Google Cloud passe por dispositivos de rede centralizados, como firewalls de nova geração (NGFW). Esta restrição influencia o design da rede da nuvem virtual privada (VPC).
- Escalabilidade: alguns designs podem ser mais adequados para a sua organização do que outros, com base no número de cargas de trabalho que quer implementar e no número de máquinas virtuais (VMs), equilibradores de carga internos e outros recursos que vão consumir.
Pontos de decisão para o design da rede
O seguinte fluxograma mostra as decisões que tem de tomar para escolher o melhor design de rede para a sua organização.
O diagrama anterior explica as seguintes perguntas:
- Precisa de inspeção da camada 7 com aparelhos de rede entre diferentes cargas de trabalho noGoogle Cloud?
- Se sim, consulte o artigo Topologia de hub e raios com dispositivos centralizados.
- Em caso negativo, avance para a pergunta seguinte.
- Muitas das suas cargas de trabalho requerem conetividade no local?
- Em caso afirmativo, avance para o ponto de decisão 4.
- Em caso negativo, avance para a pergunta seguinte.
- As suas cargas de trabalho podem comunicar através de pontos finais privados num modelo de produtor e consumidor de serviços?
- Se sim, consulte o artigo Exponha serviços num modelo de consumidor-produtor com o Private Service Connect.
- Em caso negativo, avance para a pergunta seguinte.
- Quer administrar o encaminhamento e a configuração de firewalls de forma centralizada?
- Em caso afirmativo, consulte o artigo Rede VPC partilhada para cada ambiente.
- Se não, consulte a secção Topologia de hub e raios sem eletrodomésticos.
Este gráfico destina-se a ajudar a tomar uma decisão. No entanto, muitas vezes, vários designs podem ser adequados para a sua organização. Nestes casos, recomendamos que escolha o design que melhor se adapta ao seu exemplo de utilização.
Opções de design de rede
As secções seguintes descrevem quatro opções de design comuns. Recomendamos a opção 1 para a maioria dos exemplos de utilização. Os outros designs abordados nesta secção são alternativas que se aplicam a requisitos específicos de casos extremos organizacionais.
A melhor opção para o seu exemplo de utilização também pode ser uma rede que combine elementos de várias opções de design abordadas nesta secção. Por exemplo, pode usar redes de VPC partilhada em topologias de hub e spoke para uma melhor colaboração, controlo centralizado e para limitar o número de spokes de VPC. Em alternativa, pode conceber a maioria das cargas de trabalho numa topologia de VPC partilhada, mas isolar um pequeno número de cargas de trabalho em redes VPC separadas que apenas expõem serviços através de alguns pontos finais definidos com o Private Service Connect.
Opção 1: rede de VPC partilhada para cada ambiente
Recomendamos este design de rede para a maioria dos exemplos de utilização. Este design usa redes VPC partilhadas separadas para cada ambiente de implementação que tem noGoogle Cloud (desenvolvimento, testes e produção). Este design permite-lhe gerir centralmente os recursos de rede numa rede comum e oferece isolamento de rede entre os diferentes ambientes.
Use este design quando o seguinte for verdadeiro:
- Quer ter controlo central sobre as regras de firewall e encaminhamento.
- Precisa de uma infraestrutura simples e escalável.
- Precisa de uma gestão centralizada do espaço de endereços IP.
Evite este design quando o seguinte for verdadeiro:
- Quer que as equipas de programadores tenham total autonomia, incluindo a capacidade de gerir as suas próprias regras de firewall, encaminhamento e interconexão com outras redes de equipas.
- Precisa de inspeção da camada 7 com dispositivos NGFW.
O diagrama seguinte mostra um exemplo de implementação desta estrutura.
O diagrama anterior mostra o seguinte:
- A rede no local está distribuída por duas localizações geográficas.
- A rede no local liga-se através de instâncias do Cloud Interconnect redundantes a duas redes da VPC partilhada separadas, uma para produção e outra para desenvolvimento.
- Os ambientes de produção e desenvolvimento estão ligados a ambas as instâncias do Cloud Interconnect com diferentes associações de VLAN.
- Cada VPC partilhada tem projetos de serviço que alojam as cargas de trabalho.
- As regras de firewall são administradas centralmente no projeto anfitrião.
- O ambiente de desenvolvimento tem a mesma estrutura de VPC que o ambiente de produção.
Por predefinição, o tráfego de um ambiente não pode alcançar outro ambiente. No entanto, se cargas de trabalho específicas tiverem de comunicar entre si, pode permitir a transferência de dados através de canais controlados no local ou pode partilhar dados entre aplicações com serviços como o Cloud Storage ou o Pub/Sub. Google Cloud Recomendamos que evite ligar diretamente ambientes separados através da interligação de redes VPC, uma vez que aumenta o risco de misturar acidentalmente dados entre os ambientes. A utilização do intercâmbio da rede da VPC entre ambientes grandes também aumenta o risco de atingir as quotas da VPC em torno do intercâmbio e dos grupos de intercâmbio.
Para mais informações, consulte o seguinte:
- Vista geral da VPC partilhada
- Arquitetura de VPC partilhada no guia de bases empresariais
- Arquitetura de referência nas práticas recomendadas de design de VPC
- Fase de implementação do Terraform: rede com ambientes separados como parte da estrutura Fabric FAST
- Fase de rede para a base de exemplo do Terraform usando o Cloud Foundation Toolkit
Para implementar esta opção de design, consulte o artigo Opção 1: crie uma rede VPC partilhada para cada ambiente.
Opção 2: topologia de hub e raios com dispositivos centralizados
Este design de rede usa a topologia de hub e spoke. Uma rede VPC de hub contém um conjunto de VMs de dispositivo, como NGFWs, que estão ligadas às redes VPC spoke que contêm as cargas de trabalho. O tráfego entre as cargas de trabalho, as redes nas instalações ou a Internet é encaminhado através de VMs de dispositivo para inspeção e filtragem.
Use este design quando o seguinte for verdadeiro:
- Precisa de inspeção da camada 7 entre diferentes cargas de trabalho ou aplicações.
- Tem um mandato corporativo que especifica o fornecedor do dispositivo de segurança para todo o tráfego.
Evite este design quando o seguinte for verdadeiro:
- Não precisa de inspeção da camada 7 para a maioria das suas cargas de trabalho.
- Quer que as cargas de trabalho em Google Cloud não comuniquem de todo entre si.
- Só precisa da inspeção da camada 7 para o tráfego que se destina a redes no local.
O diagrama seguinte mostra um exemplo de implementação deste padrão.
O diagrama anterior mostra o seguinte:
- Um ambiente de produção que inclui uma rede VPC de hub e várias redes VPC spoke que contêm as cargas de trabalho.
- As redes VPC spoke estão ligadas à rede VPC hub através do intercâmbio das redes da VPC.
- A rede VPC do hub tem várias instâncias de um dispositivo virtual num grupo de instâncias gerido. O tráfego para o grupo de instâncias gerido passa por um balanceador de carga de rede de passagem interno.
- As redes VPC spoke comunicam entre si através dos dispositivos virtuais usando rotas estáticas com o balanceador de carga interno como o salto seguinte.
- O Cloud Interconnect liga as redes VPC de trânsito a localizações nas instalações.
- As redes no local estão ligadas através das mesmas interligações do Google Cloud usando anexos de VLAN separados.
- As redes VPC de trânsito estão ligadas a uma interface de rede separada nos dispositivos virtuais, o que lhe permite inspecionar e filtrar todo o tráfego para e a partir destas redes através do seu dispositivo.
- O ambiente de desenvolvimento tem a mesma estrutura de VPC que o ambiente de produção.
- Esta configuração não usa a tradução de endereços de rede de origem (SNAT). O SNAT não é necessário porque o Google Cloud usa a aplicação de hash simétrica. Para mais informações, consulte o artigo Função hash simétrica.
Por predefinição, o tráfego de uma rede spoke não pode alcançar outra rede spoke. No entanto, se cargas de trabalho específicas tiverem de comunicar entre si, pode configurar o intercâmbio direto entre as redes spoke através do intercâmbio da rede da VPC ou pode partilhar dados entre aplicações com Google Cloud serviços como o Cloud Storage ou o Pub/Sub.
Para manter uma latência baixa quando o dispositivo comunica entre cargas de trabalho, o dispositivo tem de estar na mesma região que as cargas de trabalho. Se usar várias regiões na sua implementação na nuvem, pode ter um conjunto de dispositivos e uma VPC do hub para cada ambiente em cada região. Em alternativa, pode usar etiquetas de rede com trajetos para que todas as instâncias comuniquem com o aparelho mais próximo.
As regras de firewall podem restringir a conetividade nas redes VPC spoke que contêm cargas de trabalho. Muitas vezes, as equipas que administram as cargas de trabalho também administram estas regras de firewall. Para políticas centrais, pode usar políticas de firewall hierárquicas. Se precisar que uma equipa de rede central tenha controlo total sobre as regras de firewall, considere implementar essas regras centralmente em todas as redes VPC através de uma abordagem GitOps. Neste caso, restrinja as autorizações da IAM apenas aos administradores que podem alterar as regras da firewall. As redes VPC spoke também podem ser redes VPC partilhadas se várias equipas fizerem a implementação nos spokes.
Neste design, recomendamos que use o intercâmbio da rede da VPC para ligar a rede da VPC do hub e as redes da VPC spoke, porque adiciona uma complexidade mínima. No entanto, o número máximo de raios está limitado pelo seguinte:
- O limite de ligações de intercâmbio da rede da VPC de uma única rede da VPC.
- Limites do grupo de peering, como o número máximo de regras de encaminhamento para o balanceamento de carga de TCP/UDP interno para cada grupo de peering.
Se espera atingir estes limites, pode ligar as redes spoke através da Cloud VPN. A utilização do Cloud VPN adiciona custos e complexidade adicionais, e cada túnel do Cloud VPN tem um limite de largura de banda.
Para mais informações, consulte o seguinte:
- Arquitetura de transitividade de hub e raios no guia de bases empresariais
- Fase de implementação do Terraform: rede com o dispositivo virtual de rede como parte da estrutura Fabric FAST
- Módulo de transitividade hub-and-spoke do Terraform como parte da base de exemplo
Para implementar esta opção de design, consulte o artigo Crie a opção 2: topologia de hub e raios com dispositivos centralizados.
Opção 3: topologia de hub e raios sem eletrodomésticos
Esta arquitetura de rede também usa uma topologia de hub-and-spoke, com uma rede VPC de hub que se liga a redes nas instalações e redes VPC de spoke que contêm as cargas de trabalho. Uma vez que o intercâmbio das redes da VPC não é transitivo, as redes spoke não podem comunicar entre si diretamente.
Use este design quando o seguinte for verdadeiro:
- Quer que as cargas de trabalho ou os ambientes em Google Cloud não comuniquem entre si de todo através de endereços IP internos, mas quer que partilhem a conetividade no local.
- Quer dar autonomia às equipas na gestão das respetivas regras de firewall e de encaminhamento.
Evite este design quando o seguinte for verdadeiro:
- Precisa de inspeção da camada 7 entre cargas de trabalho.
- Quer gerir centralmente as regras de encaminhamento e de firewall.
- Precisa de comunicações de serviços no local para serviços geridos que estão ligados aos raios através de outro intercâmbio das redes da VPC, porque o intercâmbio das redes da VPC não é transitivo.
O diagrama seguinte mostra um exemplo de implementação desta estrutura.
O diagrama anterior mostra o seguinte:
- Um ambiente de produção que inclui uma rede VPC de hub e várias redes VPC spoke que contêm as cargas de trabalho.
- As redes VPC spoke estão ligadas à rede VPC hub através do intercâmbio das redes da VPC.
- A conetividade com localizações nas instalações passa por ligações do Cloud Interconnect na rede VPC do hub.
- As redes no local estão ligadas através das instâncias do Cloud Interconnect com associações de VLAN separadas.
- O ambiente de desenvolvimento tem a mesma estrutura de VPC que o ambiente de produção.
Por predefinição, o tráfego de uma rede spoke não pode alcançar outra rede spoke. No entanto, se cargas de trabalho específicas tiverem de comunicar entre si, pode configurar o intercâmbio direto entre as redes spoke através do intercâmbio da rede da VPC ou pode partilhar dados entre aplicações com Google Cloud serviços como o Cloud Storage ou o Pub/Sub.
Este design de rede é frequentemente usado em ambientes onde as equipas atuam de forma autónoma e não existe controlo centralizado sobre as regras de firewall e encaminhamento. No entanto, a escala deste design está limitada pelo seguinte:
O limite de ligações de intercâmbio da rede da VPC a partir de uma única rede da VPC
Limites do grupo de peering, como o número máximo de regras de encaminhamento para o Network Load Balancer de passagem interno para cada grupo de peering
Por conseguinte, este design não é normalmente usado em grandes organizações que têm muitas cargas de trabalho separadas no Google Cloud.
Como variação do design, pode usar a VPN do Google Cloud em vez da interligação de redes VPC. A VPN na nuvem permite aumentar o número de raios, mas adiciona um limite de largura de banda para cada túnel e aumenta a complexidade e os custos. Quando usa rotas anunciadas personalizadas, a VPN na nuvem também permite a transitividade entre os raios sem que tenha de ligar diretamente todas as redes de raios.
Para mais informações, consulte o seguinte:
- Arquitetura de rede centralizada
- Arquitetura de hub e raios no guia de bases empresariais
- Fase de implementação do Terraform: trabalho em rede com o intercâmbio da rede da VPC como parte da estrutura Fabric FAST
- Fase de implementação do Terraform: redes com a Cloud VPN como parte da estrutura Fabric FAST
Para implementar esta opção de design, consulte o artigo Crie a opção 3: topologia de hub e raios sem eletrodomésticos.
Opção 4: exponha serviços num modelo de consumidor-produtor com o Private Service Connect
Neste design de rede, cada equipa ou carga de trabalho tem a sua própria rede VPC, que também pode ser uma rede VPC partilhada. Cada rede VPC é gerida de forma independente e usa o Private Service Connect para expor todos os serviços que precisam de ser acedidos a partir do exterior da rede VPC.
Use este design quando o seguinte for verdadeiro:
- As cargas de trabalho só comunicam entre si e com o ambiente no local através de pontos finais definidos.
- Quer que as equipas sejam independentes entre si e geram o seu próprio espaço de endereços IP, firewalls e regras de encaminhamento.
Evite este design quando o seguinte for verdadeiro:
- A comunicação entre serviços e aplicações usa muitas portas ou canais diferentes, ou as portas e os canais mudam com frequência.
- A comunicação entre cargas de trabalho usa protocolos diferentes de TCP ou UDP.
- Precisa de inspeção da camada 7 entre cargas de trabalho.
O diagrama seguinte mostra um exemplo de implementação deste padrão.
O diagrama anterior mostra o seguinte:
- As cargas de trabalho separadas estão localizadas em projetos e redes VPC separados.
- Uma VM cliente numa rede VPC pode ligar-se a uma carga de trabalho noutra rede VPC através de um ponto final do Private Service Connect.
- O ponto final está anexado a uma associação de serviço na rede VPC onde o serviço está localizado. A associação de serviço pode estar numa região diferente da do ponto final se o ponto final estiver configurado para acesso global.
- A associação do serviço liga-se à carga de trabalho através do Cloud Load Balancing.
- Os clientes na VPC da carga de trabalho podem alcançar cargas de trabalho localizadas nas instalações da seguinte forma:
- O ponto final está ligado a uma associação de serviço numa rede VPC de trânsito.
- A associação de serviço está ligada à rede no local através do Cloud Interconnect.
- Um Application Load Balancer interno está associado à associação de serviço e usa um grupo de pontos finais da rede híbrida para equilibrar a carga de tráfego entre os pontos finais localizados no local.
- Os clientes no local também podem alcançar pontos finais na rede VPC de trânsito que se ligam a anexos de serviços nas redes VPC de cargas de trabalho.
Para mais informações, consulte o seguinte:
- Publique serviços geridos através do Private Service Connect
- Aceda a serviços publicados através de pontos finais
Para implementar esta opção de design, consulte o artigo Crie a opção 4: exponha serviços num modelo de consumidor-produtor com o Private Service Connect.
Práticas recomendadas para a implementação de redes
Depois de escolher o melhor design de rede para o seu exemplo de utilização, recomendamos que implemente as seguintes práticas recomendadas:
- Use redes VPC no modo personalizado e elimine a rede predefinida para ter um melhor controlo sobre os endereços IP da sua rede.
Limite o acesso externo usando o Cloud NAT para recursos que precisam de acesso à Internet e reduzindo a utilização de endereços IP públicos para recursos acessíveis através do Cloud Load Balancing. Para mais informações, consulte o artigo sobre como criar conetividade à Internet para VMs privadas.
Se usar o Cloud Interconnect, certifique-se de que segue as topologias recomendadas para aplicações não críticas ou ao nível da produção. Use ligações redundantes para cumprir o SLA do serviço. Em alternativa, pode estabelecer ligação Google Cloud a redes no local através do Cloud VPN.
Aplique as políticas introduzidas em limite o acesso externo através de uma política da organização para restringir o acesso direto à Internet a partir da sua VPC.
Use políticas de firewall hierárquicas para herdar políticas de firewall de forma consistente na sua organização ou pastas.
Siga as práticas recomendadas de DNS para o DNS híbrido entre a sua rede no local e Google Cloud.
Para mais informações, consulte o artigo Práticas recomendadas e arquiteturas de referência para o design de VPC.
O que se segue?
- Implemente o design da rede da zona de destino do Google Cloud
- Decida a segurança da sua Google Cloud zona de destino (próximo documento desta série).
- Leia o artigo Práticas recomendadas para o design de redes VPC.
- Leia mais acerca do Private Service Connect.