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.

Important

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 .

Best,


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

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

主题: ScalaOfficeSG
分页:12
转载请注明
本文标题:Azure networking VNET architecture best practice update (post #MSIgnite 2016)
本站链接:http://www.codesec.net/view/482674.html
分享请点击:


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 系统(windows) | 评论(0) | 阅读(36)