“微软的云产品Azure遍布在世界各地的22个超大规模的区域。Azure的存储和计算每六个月就会翻一番,Azure每个月新增9万用户。世界500强中有百分之五十七的企业都在使用Azure，主机的数量迅速从10万增长到几百万。” 这是Azure CTO在2015 open networking summit主题演讲中透露的数据。

为了应对快速增长的业务，Azure需要一个通过软件交付的虚拟化的、可扩展性网络架构。但是当微软在做这件事情的时候发现你几乎不能以一个正常人的思维去详细业务规模的增长，这样一套对可扩展性、灵活性以及具备快速交付能力的网络系统需要自己从0开始。于是他们从头开始写了一整套Azure SDN的代码。

微软使用overlay技术和网络功能虚拟化服务软件构建的虚拟网络（Vnets）。Vnets通过Azure控制器进行划分，建立一组相互关联的服务,每个服务再按规模划分，并利用高可用性在多个实例上运行协议。控制器集群所在区域能够部署10万到50万台主机。在这些区域中，又存在小的控制器集群扮演着无状态缓存器的角色，他们能够控制1000台主机。

微软使用Azure内部开发的ServiceFabric来构建这些控制器。Service Fabric有一个基于微服务的架构，能够让客户更新单个应用程序组件，而无需更新整个应用程序。

Azure SDN的可编程在硬件的协助下运行在主机服务器上。Hyper-V主机上的虚拟过滤平台(VFP)能够使Azure的数据平面在网络代理中扮演Hyper-V的虚拟网络可编程交换机的角色，网络代理代表控制器完成Vnet功能和其他功能,如负载均衡。

数据包处理是在能够将Azure的数据平面的规模从1Gbps扩展到40Gbps的主机上进行，这有助于保持客户虚拟主机的CPU周期。

虽然SDN和开源携手并进，但在AzureSDN中并没有开源软件，因为在开源社区中没有提供Azure需要的功能。而且就算有别的途径可以满足这些功能需求，转换的成本也是相当大的。微软考虑将Azure Service Fabric架构贡献给开源社区，但需要建立一些合作关系。

构造Azure SDN的一个挑战在于将现有的控制器改装到Service Fabric，这导致了一些扩展性问题，因为一些原始的控制器没有使用ServiceFabric，所以并不是面向对象的。

另一个挑战是VFP如何处理数据包。我们需要确保在连接建立以后，对每个数据包的处理都是高效的。有效运作、迅速扩展规模、迅速转化功能和服务器的负载均衡都面临挑战,所以我们可以运行虚拟机。

Azure SDN接下来需要更多的爆炸式增长的微软云。从客户API的角度看，我们会在网络层面得到更加丰富和强大的抽象。我们将在几年内看到10倍规模的Azure SDN。

译自：networkworld
本文转载自SDNLAB，原文链接：http://www.sdnlab.com/12118.html