Topologia de rede plana de carga de trabalho única

Uma rede plana é a topologia de rede Azure mais simples: uma rede virtual com múltiplas sub-redes que alojam uma única carga de trabalho. Este artigo explica quando usar este padrão e como implementá-lo.

O que este artigo aborda

Este artigo descreve a topologia de rede Azure mais simples: uma única rede virtual com múltiplas sub-redes que aloja uma carga de trabalho. Use este padrão quando tiver uma única aplicação gerida por uma equipa e não precisar de serviços partilhados como um firewall central ou gateway VPN.

Quem precisa deste artigo

Leia este artigo se:

  • Estás a implementar a tua primeira carga de trabalho no Azure.
  • Uma única equipa detém e gere todos os recursos.
  • Não precisas de serviços de rede partilhados (firewall, Bastion, gateway) entre várias cargas de trabalho.
  • Queres a rede mais simples que ainda forneça isolamento e segurança ao nível da sub-rede.

Foco em levantar e deslocar: Um único VNet plano com uma sub-rede por componente é frequentemente o primeiro passo certo para realojar uma carga de trabalho numa região.

Foco na modernização: Utilize uma rede plana para um projeto-piloto inicial de PaaS ou uma única carga de trabalho modernizada e conceba as sub-redes de forma a que a rede possa evoluir sem dificuldades para uma topologia em hub-and-spoke quando adicionar serviços partilhados ou uma segunda região.

Foco multicloud: Utilize uma VNet plana como ponto de entrada único no Azure durante a migração entre clouds: implemente primeiro a carga de trabalho e, em seguida, planeie o respetivo espaço de endereçamento e a segmentação, para que possa integrar-se num hub ou no WAN Virtual à medida que a arquitetura evolui.

Serviços e funcionalidades do Azure

A topologia de rede plana utiliza estes serviços centrais do Azure:

Serviço Papel nesta topologia
Rede Virtual do Azure Fornece um espaço de endereçamento privado e isolado para sua carga de trabalho. Uma rede virtual é limitada a uma única região Azure.
Sub-redes + Grupos de Segurança de Rede (NSGs) Sub-redes separam as camadas de aplicação. Os NSGs filtram o tráfego de entrada e saída em cada limite de subrede. Os NSGs são com estado: o tráfego de retorno para ligações permitidas é automaticamente permitido.
Azure zona DNS privada Fornece resolução interna de nomes para recursos dentro da rede virtual. Liga a zona com o auto-registo ativado para que as VMs recebam automaticamente registos DNS.
Sub-rede de gateway(opcional) Aloja um gateway VPN ou ExpressRoute se precisar de uma única ligação a uma rede local.

Como escolher: manter uma estrutura plana ou passar para um modelo hub-and-spoke?

Use a tabela de decisão seguinte para determinar se a topologia plana é adequada para o seu ambiente ou se deve adotar uma topologia hub-and-spoke em vez disso.

Condição Recommendation
Carga de trabalho única, equipa única, sem serviços partilhados Permaneça na horizontal: este artigo aplica-se
Uma segunda carga de trabalho independente necessita do seu próprio isolamento de rede Passar para topologia hub-and-spoke
Precisas de um firewall partilhado, gateway VPN ou Azure Bastion entre cargas de trabalho Migrar para a topologia hub-and-spoke
As políticas de segurança devem ser geridas centralmente em várias cargas de trabalho Migrar para a topologia hub-and-spoke

Dica

Se prevê vir a adicionar uma segunda workload dentro de seis a doze meses, considere adotar uma arquitetura hub-and-spoke desde o primeiro dia. A sobrecarga é mínima porque só adicionas uma rede virtual extra e uma ligação de peering. Esta abordagem evita uma migração disruptiva mais tarde.

Considerações de design

Foco na conceção de redes planas para lift-and-shift

  • Use um VNet com uma sub-rede para cada componente da aplicação (web, app, dados) para espelhar um layout típico de três níveis on-premises com redesenho mínimo.
  • Aplique NSGs entre sub-redes para recriar a sua segmentação atual e mantenha o espaço de endereçamento alinhado com os intervalos do ambiente local para evitar sobreposições.
  • Mantenha uma estrutura plana enquanto uma única equipa é responsável pela carga de trabalho e não precisa de uma firewall partilhada, um gateway ou serviços Bastion.
  • Planeie a mudança para uma arquitetura hub-and-spoke antes de adicionar uma segunda carga de trabalho, para que os serviços partilhados sejam implementados num hub em vez de serem integrados posteriormente.

Modernizar o foco do design de redes planas

  • Use uma rede plana para um piloto PaaS inicial ou uma única carga de trabalho modernizada: coloque as camadas de aplicação em sub-redes e aceda ao Azure PaaS através de endpoints privados numa sub-rede dedicada.
  • Reserve subredes dedicadas desde o início para os serviços da plataforma que irá adicionar, como o Application Gateway e endpoints privados, para que a rede cresça sem necessidade de reendereçamento.
  • Aplique NSGs e grupos de segurança das aplicações por camada, para que a segmentação já esteja implementada caso a carga de trabalho venha mais tarde a tornar-se um elemento periférico numa arquitetura em estrela.
  • Mantém o espaço de endereçamento não sobreposto com as tuas outras regiões e VNets para poderes fazer peering ou evoluir para um hub mais tarde sem renumeração.

Foco na conceção de uma rede plana entre clouds

  • Utilize uma VNet plana como ponto de apoio único no Azure durante a migração entre nuvens: implemente primeiro a carga de trabalho e, em seguida, estabeleça a conectividade a partir de um hub, à medida que a arquitetura evolui.
  • Planeie o espaço de endereçamento plano do VNet para evitar sobreposição com as VPCs AWS e as redes Google Cloud, para que possa juntar-se ao encaminhamento IPsec ou interligar mais tarde sem tradução.
  • Mantenha a segmentação de níveis com os NSGs para que a postura de segurança da carga de trabalho se mantenha quando esta se torna um raio atrás de um hub WAN Virtual seguro.
  • Padronize a nomeação e a etiquetagem das subredes para corresponder às outras clouds, para que a carga de trabalho fique fácil de correlacionar durante e após a migração.

Pré-requisitos

Antes de implementar esta topologia:

  • Uma subscrição do Azure com permissões para criar redes virtuais e NSGs.
  • Um espaço de endereços IP planeado. Um espaço de endereçamento /16 fornece 65.536 endereços, o que é um ponto de partida comum para uma única carga de trabalho. O Azure reserva 5 endereços por sub-rede para uso interno. Para orientações detalhadas, consulte Planear o endereçamento IP.
  • Uma compreensão das camadas da sua aplicação (por exemplo, camada web, de aplicação e de dados), para que as possa mapear para sub-redes. Para orientações sobre design de sub-redes, consulte Projetar redes virtuais e sub-redes.

Layout de rede

Diagrama que mostra uma topologia de rede plana com sub-redes web, aplicação e camada de dados, cada uma protegida por um NSG, dentro de uma única rede virtual.

Uma topologia de rede plana segue esta estrutura:

  • Uma rede virtual com um único espaço de endereçamento (por exemplo, 10.0.0.0/16).
  • Múltiplas sub-redes: uma por cada nível ou componente da aplicação:
    • Subnet de nível web (por exemplo, 10.0.1.0/24).
    • Subrede do nível de aplicação (por exemplo, 10.0.2.0/24).
    • Subrede de nível de dados (por exemplo, 10.0.3.0/24).
    • Sub-rede de gateway (opcional, por exemplo, 10.0.255.0/27).
  • NSGs ligados a cada sub-rede com regras que permitem apenas o tráfego de que cada nível precisa.
  • Uma zona DNS Privado ligada à rede virtual com o auto-registo ativado.

Note

Planeie cuidadosamente os intervalos dos seus endereços IP. Se mais tarde migrar para uma topologia hub-and-spoke, as redes virtuais spoke têm de ter intervalos CIDR que não se sobreponham aos do hub. Escolher um esquema de endereços bem estruturado evita agora conflitos durante a migração.

Considerações de segurança

Aplique estas práticas de segurança à sua rede plana:

  • NSGs em todas as sub-redes. Comece com uma configuração base de bloqueio de todo o tráfego de entrada e adicione regras específicas para permitir o tráfego legítimo entre camadas. Por exemplo, permitir HTTPS da camada web para a camada de aplicação, e permitir SQL da camada de aplicação para a camada de dados.
  • Não há IPs públicos diretamente nas VMs. Disponibilize serviços através de um balanceador de carga ou de um Application Gateway. Use Azure Bastion para acesso administrativo.
  • DNS Privado para resolução interna. As zonas DNS Privado impedem a exposição dos nomes internos através de consultas DNS públicas.
  • Isolamento da sub-rede de gateway. Se adicionar uma VPN ou gateway ExpressRoute, coloque-a numa sub-rede dedicada (chamada GatewaySubnet). Não há suporte para NSGs na sub-rede do gateway. Associar um NSG a esta sub-rede pode fazer com que o seu gateway de rede virtual deixe de funcionar como esperado.

Importante

Quando removes uma regra NSG que permite uma ligação, as ligações ativas existentes continuam sem interrupções. Apenas novas ligações que correspondam à regra removida são bloqueadas.

Os artigos seguintes fornecem orientações mais profundas sobre temas relacionados:

Saiba mais

Para mais informações sobre os serviços Azure usados nesta topologia, veja:

Passos seguintes

Dica

Explorar sozinho? Volte ao navegador de visão geral para encontrar o seu próximo artigo por capacidade.

A seguir na sua jornada de levantar e deslocar:

Desenhe a sua topologia de hub-and-spoke: A maioria das migrações lift-and-shift ultrapassa rapidamente uma rede plana. Planeie serviços partilhados centralizados desde o início.

Próximo passo na sua jornada de modernização:

Projete a sua topologia hub-and-spoke: As cargas de trabalho modernizadas com múltiplos serviços, controlos de segurança e equipas precisam de uma topologia hub-and-spoke desde o primeiro dia.

A seguir na sua jornada através da cloud:

Planeie a sua arquitetura de conectividade multicloud: Os ambientes multicloud precisam de uma arquitetura de trânsito, não de redes planas. Desenhe o seu modelo de conectividade multicloud.

  • Last updated on