微软Azure云服务需要SDN

“微软的云产品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内部开发的Service Fabric来构建这些控制器。Service Fabric有一个基于微服务的架构，能够让客户更新单个应用程序组件，而无需更新整个应用程序。

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

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

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

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

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

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