“微软的云产品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。
好文章,需要你的鼓励
Snap 推出 Lens Studio 的 iOS 应用和网页工具,让所有技能层次的用户都能通过文字提示和简单编辑,轻松创建 AR 镜头,包括生成 AI 效果和集成 Bitmoji,从而普及 AR 创作,并持续为专业应用提供支持。
SEALQA是维吉尼亚理工大学研究团队开发的新型基准测试,旨在评估搜索增强型语言模型在面对矛盾、嘈杂或无用搜索结果时的推理能力。它包含三种测试:SEAL-0(极具挑战性的核心问题集)、SEAL-HARD(更广泛的困难问题集)和LONGSEAL(测试长上下文多文档推理)。研究发现,即使是前沿模型在这些测试中表现也很差,增加测试时计算资源往往不能带来可靠的性能提升,高级推理模型对嘈杂搜索结果特别敏感,模型在识别大量干扰文档中的相关信息时仍然困难重重。
这篇论文提出了"计划与预算"框架,解决大型语言模型在推理任务中的效率问题。研究者发现模型存在"推理失调"现象——简单问题上过度思考,复杂问题上思考不足。他们开发了贝叶斯预算分配模型(BBAM)作为理论基础,将推理分解为子问题并根据不确定性分配计算资源。实验表明,该方法在不同任务上显著提高推理效率,令牌使用减少39%,E?指标提升187.5%,且能使小型模型达到大型模型的效率水平。