Padrões de Implantação de VNET
3 min read

Padrões de Implantação de VNET

Padrões de Implantação de VNET

Visão geral

No Azure, é de conhecimento geral a possibilidade de criar redes virtuais. No entanto uma coisa que sempre deixa dúvidas é: como garantir a melhor topologia de rede?

Pensando nisso, é importante entender o porquê de planejar a sua topologia de rede quando for trabalhar nas suas implantações.

Somente com planejamento, e entendimento correto sobre a arquitetura do Azure, podemos ter em mente como montar uma topologia que seja viável começando pequeno e que permita escalabilidade.

Padrões de Implantação

Hoje os principais padrão de implantação utilizados no Microsoft Azure são:

  • Hub-spoke;
  • Daisy Chain;
  • FullMesh;

Topologia Hub-Spoke

A Topologia Hub-spoke é caracterizada por conter uma rede dedicada para serviços compartilhados (hub) e redes isoladas para workloads. O Tráfego entre on-premises e Hub pode ser estabelecido usando ExpressRoute ou VPN Gateway.

Você irá ter bastante proveito deste tipo de topologia se quiser trabalhar com o isolamento de múltiplas workloads trabalhando na nuvem. Comunicação bi-direcional não é obrigatória, mas normalmente é implementada. Quando você quer centralizar recursos compartilhados, como servidores DNS, NTP, AD DS, ADFS, esta topologia também pode ser muito útil.

Você pode ter muitos benefícios nessa implementação por estes aspectos

  • Redução de custos centralizando workloads compartilhadas;
  • Superar limites de assinaturas realizandos o peering de VNETs;
  • Separação de atividades: entre TI Central (InfraOps e SecOps) e as workloads (DevOps).

O Centro de Arquitetura Do Azure traz uma documentação bastante rica sobre como fazer a implementação de uma arquitetura hub spoke, bem como referências em PowerShell.

Fonte: https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/hybrid-networking/hub-spoke

Topologia Daisy-Chain

A topologia Daisy-chain trabalha com o conceito de rede transitória. Diferente da topologia Hub-spoke, é possível estabelecer comunicação entre outras redes, porém a rota sempre irá passar por uma rede central. Pense desta forma, você tem 3 redes virtuais: vnet1, vnet2 e vnet3 e a vnet 2 é sua vnet central. Se a vnet1 quiser conversar com a vnet3, o pacote precisará primeiramente passar pela vnet2. O mesmo precisa acontecer quando a vnet3 quiser se comunicar com a vnet1.

O principal benefício nessa frente é poder se aproveitar do fato de já existir uma rota estabelecida entre 2 redes para comunicações entre outras redes.

Por outro lado, se sua rede transitória estiver fora do ar, você perderá conectividade entre todas as outras redes

Topologia FullMesh

Por fim temos a topologia de FullMesh, sendo uma das mais conhecidas e utilizadas nos dias de hoje. Nesta topologia, todas as suas redes virtuais se comunicam em todas as direções e isso garante bastante resiliência em termos de conectividade. Tratando-se nas práticas de implementação no Azure, esta topologia pode trazer alguns desafios, porque você deve:

  • Ou criar uma única rede virtual e tratar várias ranges de subnet e “tratar” estas subnets como redes separadas. O desafio aqui é tratar filtragem / isolamento de workloads mais críticas.
  • Ou criar várias redes virtuais e conectar utilizando VNET Peering ou VPN Gateway. Em ambas situações custos com tráfego são esperados, e na segunda opção tem um custo adicional com o Gateway VPN.

Dicas de design e implantação

Dentre as topologias que mostrei, a mais utilizada como padrão de implantação na nuvem é a topologia Hub-spoke. A Microsoft tem uma arquitetura e modelo de implementação muito bem documentado e o principal apresentado é a possibilidade de isolar workloads de recursos compartilhados.

Por trazer vantagens no isolamento lógico dos recursos temos nesta topologia um modelo que é simples de implementar e ao mesmo tempo escalável. Desta forma, aqui vão algumas dicas para quando for implementar sua arquitetura Hub-Spoke:

  • Definir serviços compartilhados e serviços especializados;
  • Atenção às limitações do recurso por assinatura (500 peerings por assinatura);
  • Se tiver interesse em trabalhar com uma DMZ (pública ou privada), implemente um NVA;

Conclusão

Aqui fechamos o tópico sobre padrões de implementação de Redes no Azure. O assunto as vezes pode gerar muitas dúvidas, mas como passei, é muito importante ter a visão de arquiteto em mente, porque suas implantações precisam ser escaláveis e permissíveis de repetição.

Referências:


Quer mais informações? Acompanhe o primeiro episódio do Pé na nuvem onde eu falo sobre Padrões de VNET!