技术控

    今日:51| 主题:49211
收藏本版 (1)
最新软件应用技术尽在掌握

[其他] Azure networking VNET architecture best practice update (post #MSIgnite 2016)

[复制链接]
九命猫 发表于 2016-10-11 14:12:52
121 2

立即注册CoLaBug.com会员,免费获得投稿人的专业资料,享用更多功能,玩转个人品牌!

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
During Microsoft Ignite 2016 I attended a few Azure networking architecture sessions. Towards the end of the week, though, they did overlap some content which was not ideal. A key message was there though. An interesting bit of reference architecture information.
  Of note and relevant to this blog post:
  
       
  • Migrate and disaster recover Azure workloads using Operations Management Suite by Mahesh Unnifrishan, Microsoft Program Manager   
  • Review ExpressRoute for Office 365 configuration (routing, proxy and network security) by Paul Andrew, Senior Product Marketing Manager   
  • Run highly available solutions on Microsoft Azure by Igal Figlin, Principal PM- Availability, Scalability and Performance on Azure   
  • Gain insight into real-world usage of the Microsoft cloud using Azure ExpressRoute by Bala Natarajan Microsoft Program Manager   
  • Achieve high-performance data centre expansion with Azure Networking by Narayan 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 architecture for VNETs, creating multi tiered solutions was generally not 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)-1 (networking,Microsoft,available,reference,disaster)

  VNet Peering

   At Microsoft Ignite, VNET peering was made generally available on September 28th ( 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 essentially allows 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 Services also 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 achieved with 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 spoke features 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)-2 (networking,Microsoft,available,reference,disaster)

  Larger customers opt 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 example a DMZ segment.
   I repeat: a recommended network design for most environments is generally a hub and spoke leveraging VNET peering and centralising shared resources in the hub VNET.
  Important

  These new possibilities offer awesome 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 most cases these can be raised through discussion with Microsoft.

   The limits on VNET peering applies to two areas. The first is number of networks able to be peering to a single network (currently 50). The second is the number of routes able to be advertised when using ExpressRoute and VNET peering. Review the following Azure documentation article for more info on these 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 implement consistent and proven architecture topologies that leverages on the knowledge and experience of others. Basically, stand on the shoulders of giants .   
  Best,
12下一页
友荐云推荐




上一篇:2016 LiFT Scholarship Winner Lorien Smyer: Bookkeeper Turned Technologist
下一篇:MAHAndroidUpdater
酷辣虫提示酷辣虫禁止发表任何与中华人民共和国法律有抵触的内容!所有内容由用户发布,并不代表酷辣虫的观点,酷辣虫无法对用户发布内容真实性提供任何的保证,请自行验证并承担风险与后果。如您有版权、违规等问题,请通过"联系我们"或"违规举报"告知我们处理。

ccynny 发表于 2016-10-13 08:50:30
成全自己,恶心别人!
回复 支持 反对

使用道具 举报

最妖娆。 发表于 2016-11-20 07:45:11
总有一天我会骄傲的对你说:滚,我不需要你。
回复 支持 反对

使用道具 举报

*滑动验证:
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

我要投稿

推荐阅读

扫码访问 @iTTTTT瑞翔 的微博
回页顶回复上一篇下一篇回列表手机版
手机版/CoLaBug.com ( 粤ICP备05003221号 | 文网文[2010]257号 )|网站地图 酷辣虫

© 2001-2016 Comsenz Inc. Design: Dean. DiscuzFans.

返回顶部 返回列表