概述
在过去的一段时间里,我们一直在测试OpenDaylight Helium SR3(主要通过博科Vyatta控制器集成OpenDaylight的1.2版本)和ONOS的1.2版本——Cardinal。在这篇文章中,我们会 对这两个控制器进行比较,着重比较两者的规模,特别是可以处理的交换机数量,我们采用IXIA和Pica8交换机来模拟OpenFlow 1.0和1.3交换机。
注意:ONOS的最新版本(Cardinal)v1.2有一个问题就是处理IXIA模拟的OpenFlow v1.3交换机,因此所有对ONOS规模的测试都使用OpenFlow 1.0交换机。此外,ONOS术语“node”指ONOS的拷贝(我们测试的时候运行了两个节点),而在OpenDaylight中,“node”是指一 个OpenFlow交换机。
用户界面
ONOS和OpenDaylight/BVC一个主要的不同点在于从用户图形界面(GUI)可以直接获取的控制装置和信息。
ONOS
ONOS的GUI包括Summary, Node(s)和Controls在内的多个窗口。

ONOS GUI陈列了轮廓分明的终端主机,你可以看到它们连接在了交换机上。

OpenDaylight
默认的OpenDaylight GUI上会有一些功能,包括:陈列node的窗口,Yang界面和Yang可视化工具。

当试图陈列终端主机的时候,会发现OpenDaylight GUI不像ONOS那样清晰,主机是交错地连接在交换机上的。

Brocade Vyatta Controller
Brocade Vyatta Controller(BVC)的GUI要比OpenDaylight GUI清晰,而且还具有额外的模块Vyatta vRouter 5600 EMS和“PathExplorer” 应用。

当前在OpenDaylight/BVC呈现的主机和交换机操作起来不是很容易,也不能很好地测量规模。
规模
在规模测试中,我们由100个交换机扩大到400个交换机,每台交换机上连接12台主机。当OpenDaylight(采用BVC)能够将交换机数量扩大到400时,ONOS已经在采用400台交换机之前就停止运转了。
这是BVC的GUI,展示了彼此互通的400台交换机、800个连接和许多主机。


下图是ONOS达到处理交换机/连接/主机的极限的实验结果:

该截图展示了两个ONOS节点的400个交换机、800个连接和0个主机(我们试图在48个主机间发送数据流)。当设备(交换机)在数据库中时,主机就不在数据库中,GUI变得不稳定,不再展示任何信息。
思考
当作为具有许多南向和北向接口的SDN控制器时,ONOS和OpenDaylight都是固体产物。这里的测试只关注OpenFlow和具体规模。 OpenDaylight的Brocade版本打包得很好,也有一些不错的附加条件,如Brocade Vyatta vRouter 5600上的EMS应用程序。ONOS继续专注于在它们的GUI上提供工具和信息,300台交换机是一个完全合理的数量,当然任何人都应该添加一个或两个 控制器。
好文章,需要你的鼓励
很多人担心被AI取代,陷入无意义感。按照杨元庆的思路,其实无论是模型的打造者,还是模型的使用者,都不该把AI放在人的对立面。
MIT研究团队提出递归语言模型(RLM),通过将长文本存储在外部编程环境中,让AI能够编写代码来探索和分解文本,并递归调用自身处理子任务。该方法成功处理了比传统模型大两个数量级的文本长度,在多项长文本任务上显著优于现有方法,同时保持了相当的成本效率,为AI处理超长文本提供了全新解决方案。
谷歌宣布对Gmail进行重大升级,全面集成Gemini AI功能,将其转变为"个人主动式收件箱助手"。新功能包括AI收件箱视图,可按优先级自动分组邮件;"帮我快速了解"功能提供邮件活动摘要;扩展"帮我写邮件"工具至所有用户;支持复杂问题查询如"我的航班何时降落"。部分功能免费提供,高级功能需付费订阅。谷歌强调用户数据安全,邮件内容不会用于训练公共AI模型。
华为研究团队推出SWE-Lego框架,通过混合数据集、改进监督学习和测试时扩展三大创新,让8B参数AI模型在代码自动修复任务上击败32B对手。该系统在SWE-bench Verified测试中达到42.2%成功率,加上扩展技术后提升至49.6%,证明了精巧方法设计胜过简单规模扩展的技术理念。