During Microsoft Ignite 2016 I attended a few Azure networking architecturesessions. Towards the end of the week, though, they did overlap some content which was not ideal. A key message was there though. Aninteresting bit of reference architectureinformation.

Of note and relevant to this blog post:

Migrate and disaster recover Azure workloads using Operations Management Suite byMahesh Unnifrishan, Microsoft Program Manager Review ExpressRoute for Office 365 configuration (routing, proxy and network security) byPaul Andrew, Senior Product Marketing Manager Run highly available solutions on Microsoft Azure byIgal Figlin, Principal PM- Availability, Scalability and Performance on Azure Gain insight into real-world usage of the Microsoft cloud using Azure ExpressRoute byBala NatarajanMicrosoft Program Manager Achieve high-performance data centreexpansion with Azure Networking byNarayan Annamalai, Principal PM Manager, Microsoft Background

For the last few years there has been one piece of design around Azure Virtual Networks (VNETs) that caused angst. When designing a reference architecturefor VNETs, creating multi tiered solutions was generallynot recommended. For the most part, a single VNET with multiple subnets (from Microsoft solution architects I spoke with) was the norm. This didn’t scale well across regions and required multiple and repetitive configurations when working at scale; or Microsoft’s buzz words from the conference: hyper-scale .

Azure networking VNET architecture best practice update (post #MSIgnite 2016)
VNet Peering

At Microsoft Ignite, VNET peering was made generallyavailable on September28th ( reference and official statement ). VNET peering allows for the connectivity of VNETs in the same region without the need of a gateway. It extends the network segment to essentiallyallows for all communication between the VNETs as if they were a single network. Each VNET is still managed independently of one another; so NSG’s, for example, would need to be managed on each VNET.

Extending across regions VNET peering across regions is still the biggest issue. When this feature comes, it will be another game changer.Amazon Web Servicesalso has VPC peering, but, is also limited to a single region. Microsoft has caught up in this regard.

Interesting and novel designs can now be achievedwith VNET peering.

Hub and spoke

I’m not a specialist network guy. I’ve done various Cisco studies and never committed to getting certified, but, did enough to be dangerous !

VNET peering has one major advantage: the ability to centralise shared resources, like for example networking virtual appliances.

A standard network topology design known as hub and spokefeatures centralised provisioning of core components in a hub network with additional networks in spokes stemming from the core.

Azure networking VNET architecture best practice update (post #MSIgnite 2016)

Larger customersopt to use virtual firewall (Palo Alto or F5 firewall appliances) or load balancers (F5 BigIP’s) as network teams are generally well skilled in these and re-learning practices in Azure is time-consuming and costly.

Now Microsoft, via program managers on several occasions, recommends a new standard practice of using the hub and spoke network topology and leveraging the ability to centrally store network components that are shared. This could even extend to centrally store certain logical segmented areas, for examplea DMZ segment.

I repeat: a recommended network design for mostenvironmentsis generally a hub and spoke leveraging VNET peering and centralising shared resources in the hub VNET.


These new possibilities offerawesome network architecture designs that can now be achieved. Important to note though, is that there are limits imposed.

Speaking with various program managers, limits in most services are there are a guide and form a logical understanding of what can be achieved. However, in mostcases these can be raised throughdiscussion with Microsoft.

The limits on VNET peering applies to two areas. The first isnumber of networks able to be peering to a single network (currently 50). The second is thenumber of routes able to be advertised when using ExpressRoute and VNET peering. Review the followingAzure documentation article for more info onthese limits: https://azure.microsoft.com/en-us/documentation/articles/azure-subscription-service-limits/#networking-limits .

Finally, it’s important to note that not every network is identical and requirements change from customer to customer. What is additionally as important is to implementconsistent and proven architecture topologies that leverages on the knowledge and experience of others. Basically, stand on the shoulders of giants .


Azure networking VNET architecture best practice update (post #MSIgnite 2016)

本文系统(windows)相关术语:三级网络技术 计算机三级网络技术 网络技术基础 计算机网络技术

主题: ScalaOfficeSG
本文标题:Azure networking VNET architecture best practice update (post #MSIgnite 2016)

技术大类 技术大类 | 系统(windows) | 评论(0) | 阅读(20)