OpenDaylight Helium版本与Hydrogen版本比较

1 OpenDaylight Helium版本

业界组织OpenDaylight联盟最近发布了其开源SDN软件的2.0版本,即Helium(氦)版本,该2.0版本加入了一些有关Helium和OpenDaylight未来发展方向的新理念,致力于研发出“开放、易懂”的SDN解决方案。且更多新厂商的加入对OpenDaylight 项目的支持,印证了OpenDaylight目前的发展和进步。

1.1 Helium版本变化

Helium版本相较于1.0氢版本的一些变化:

(1)OpenDaylight结合OpenStack。在Helium版本中最明显的特征是OpenDaylight与OpenStack之间整合的方式,其中包括在Open vSwitch数据库整合项目中一些明显的改善,以及高级的OpenStack特征(如安全小组、分布式虚拟路由器和负载均衡即服务)的技术预览。

(2)组策略插件(Group Policy Plugin)。能够在以策略为重点的北向API中提供比Affinity更好的体验,提供多样性选择,可以实行单一的模型也可以同时实行两种模型。

(3)DLUX(openDayLight User eXperience)。通过更多拖放功能的图形用户界面增强用户体验,更易拖拽,且设备图形显示更美观。

(4)NFV(网络功能虚拟化)。推动SDN与NFV的发展,重新构建网络,且新增11个新的协议、应用及技术到SDN和NFV平台中,使之更灵活的、互操作性更可用。

(5)变化最大的是配备了一个新的用户界面和一个更简单并可定制的功能安装过程,并使用了Apache Karaf容器,提供开发者更方便测试和管理SDN生产环境的平台。使用Karaf容器后,OpenDaylight的启动方式也有了很大的改变,如进入OpenDaylight目录,切换到bin目录下,执行启动命令:

Shell

./karaf 或 ./karaf clean

1

./karaf 或 ./karaf clean

启动成功后安装各功能模块也较简单,直接通过feature命令进行安装,如安装L2switch功能:

Shell

feature:install odl-l2switch-switch

1

feature:install odl-l2switch-switch

新的用户界面显示相比较1.0版本完全变化,直接将Nodes、YangUI、Topology、Network、Connection manager、Flows等模块功能显示,更显直观,如下图部分功能显示:

(6)更高的可用性,以及加强和增加新的协议,如OpenFlow的表格型模式、PacketCable多媒体、应用程序的策略框架和工具、服务功能链接等。

(7)安全性以及授权功能方面有所增强。拥有更出色的集群化故障转移机制,新的Secure Network Bootstrapping Infrastructure(即安全网络引导基础设施,简称SNBI)允许用户对一整套控制器与网络设备安全集进行定义与启用。

(8)利用BGP实现的控制器交叉联合机制通过SDNi(软件定义网络接口)在项目中同样得以实现。

(9)模型驱动的服务抽象层在OpenDaylight SDN中扮演一个关键角色,其可以通过自动化减少人类的干预和人为错误。与此同时,自动化还可以帮助为南向和北向接口提供更好的一致性。

2  OpenDaylight Hydrogen版本

OpenDaylight氢版本提供了三种不同的版本,可以帮助用户广泛地学习,并尽可能快地运行。OpenDaylight使用的1.0氢版本,主要是AD-SAL模型以及release版本的Yang工具相关的MD-SAL模型、OF1.0协议的支持以及SNMP4SDN项目。下图展示了OpenDaylight的架构,可看出OpenDaylight是一个可插拔的控制器平台,它提供北向API和南向服务抽象层(SAL)。下面具体谈一下此版本的优缺点。

2.1 Hydrogen版本优点

在主要的设计原则和开源项目方面,OpenDaylight 1.0版本的主要优点是:

(1)OSGi体系结构。采用OSGi体系结构,可对功能进行隔离,可以动态的加载和卸载,解决了可扩展、热部署等问题,实现了一个优雅、完整和动态的组件模型,应用程序(Bundle)无需重新引导可以动态地被远程安装、启动、升级和卸载,给使用者提供了方便。框架分为模块层、生命周期层和服务层三个层次。

(2)SAL(服务抽象层)。整个架构中引入了服务抽象层,使得北向REST API和南向接口之间的调用相互隔离,支持南向插件通过各种协议(包括OpenFlow)与网络设备通信,并能够像整合模块一样整合控制器应用程序,以及一组提供控制器功能的REST API。

(3)MD(Model Drive)。使用Yang工具,使用业务驱动模型工具来设计接口、实现业务功能,根据yang文件,Yang工具可直接生成业务管理的“骨架”,使开发者真正专注于具体业务。

(4)Infinispan(分布式内存数据网格)。实现数据的存储、查找及监听,用开源的数据网格平台实现Controller的集群。它公开了一个简单的数据结构(一个Cache)来存储对象,可以本地模式下运行,但其最大的特点在于支持分布式。

(5)Netty。南向使用Netty来管理底层的并发IO,监听消息服务。

2.2 Hydrogen版本一些缺点

OpenDaylight 1.0版本存在的一些问题:

(1)版本演进过程没有清晰的说明,且存在很多废弃的代码,使开发者耗费大量精力,二次开发较困难。

(2)版本功能较多,没有如何定制和研究的相关说明,整个ODL给人很难研究和很茫然的感觉。

(3)官方提供的文档不够完善,且文档较少,看代码等分析非常困难。

(4)相关的测试环境、工具等还不够成熟,需待提升和完善。

(5)基本上还是处于研究阶段,没有基于此平台的原型或者示例,很难直观的感受SDN。

3 总结

OpenDaylight Helium版本在Hydrogen版本的基础上提升优化了很多,提供开发者更方便测试和管理SDN生产环境的平台。氦版本在项目中提到协作开发的重要性,培养协作精神以实现SDN平台和相关组件,如果能够在大多案例中被多数人应用到实际生产环境当中,将具有重大的意义。此外测试自动化是基础设施中的优秀组成部分,也是最先进的开源项目,对于OpenDaylight来说也非常关键,希望将尽早引入测试自动化,促进OpenDaylight项目的发展。

如有理解不到位或有不正确的地方,敬请谅解多指正!谢谢!

文章来自http://www.sdnlab.com/3258

时间: 2024-10-20 04:13:33

OpenDaylight Helium版本与Hydrogen版本比较的相关文章

git基础①创建版本库和版本回退

集中式版本控制系统:版本是集中存放在中央服务器的,做项目的时候要先从中央服务器里面取得最新版本,做完项目然后在推送上传到中央服务器进行储存.缺点是没有网络或者是网速不够快,上传和下载文件要很长时间,不方便也不安全. 分布式版本控制系统:在自己电脑上创建一个本地版本库,修改,上传在本地进行就可以,方便快捷,2人协作,可以直接相互推送给对方,就可以看到各自的修改,多人协作 通常也建立个一个中央服务器,但是这个服务器的作用仅仅是用来方便大家的修改,没有也可以一样的工作,只是没有那么方便而已 安装git

CMD命令:开始->运行->键入cmd或command(在命令行里可以看到系统版本、文件系统版本)

CMD命令 CMD命令:开始->运行->键入cmd或command(在命令行里可以看到系统版本.文件系统版本) appwiz.cpl:程序和功能 calc:启动计算器 certmgr.msc:证书管理实用程序 charmap:启动字符映射表 chkdsk.exe:Chkdsk磁盘检查(管理员身份运行命令提示符) cleanmgr: 打开磁盘清理工具 cliconfg:SQL SERVER 客户端网络实用工具 cmstp:连接管理器配置文件安装程序 cmd.exe:CMD命令提示符 自动关机命令

GBK版本和UTF-8版本的区别

GBK版本与UTF-8版本功能是一样的.只不过编码方式不同.UTF-8比较“国际化”吧. GBK的文字编码是双字节来表示的,即不论中.英文字符均使用双字节来表示,只不过为区分中文,将其最高位都定成1.至于UTF-8编码则是用以解决国际上字符的一种多字节编码,它对英文使用8位(即一个字节),中文使用24位(三个字节)来编码.对于英文字符较多的网站则用UTF-8节省空间.UTF8编码的优点:优点1:外国人的英文IE上也能显示中文,无需下载IE的中文语言支持包.香港台湾无需安装简体中文支持就能正常观看

数据库低版本附加高版本的问题

我的机房收费系统是在自己笔记本上敲的,敲完了以后把本上数据库拷了出来,放到台式机上,准备通过台式机来验收系统.当我附加数据库的时候,提示 "数据库'charge_sys'的版本为661,无法打开.此服务器支持655版及更低版本.不支持降级路径." 这是因为我本上的SQL是2008R2版的,而机房的电脑上的数据库是2008版的(当然,2008版以下的也会出现这种情况).暂时我知道的解决方法只有 两种: 一.就是把低版本电脑的SQL升级,升到高版本就可以了.但这样不仅浪费时间,而且很麻烦.

nodejs高版本转低版本

需要安装 第一步: npm install --save-dev babel-register npm install --save-dev babel-polyfill //由于只安装babel-register,无法解决低版本问题所以需要这个 npm install --save-dev babel-preset-latest //高版本到低版本js的一条路需要指定babelrc 最后需要创建文件: .babelrc//无扩展名 { "presets": ["latest

理解Maven中的SNAPSHOT版本和正式版本

Maven中建立的依赖管理方式基本已成为Java语言依赖管理的事实标准,Maven的替代者Gradle也基本沿用了Maven的依赖管理机制.在Maven依赖管理中,唯一标识一个依赖项是由该依赖项的三个属性构成的,分别是groupId.artifactId以及version.这三个属性可以唯一确定一个组件(Jar包或者War包). 其实在Nexus仓库中,一个仓库一般分为public(Release)仓和SNAPSHOT仓,前者存放正式版本,后者存放快照版本.如果在项目配置文件中(无论是build

Android SDK版本和ADT版本

Android SDK版本和ADT版本 Android早期的版本号有点“混乱”,比如Android 2.2对应的ADT版本为ADT-0.9.9而Android 2.3对应的的ADT版本则突然“跃迁”为 ADT-8.0.0.zip. 而且Android SDK还包含SDK Tools和SDK Platform两个东西,它们的意义也不同,它们也有各自的版本号,因此有些人在此处容易混淆,下面将它们之间的对应关系进行一下简单的归纳: Android平台与SDK Tools版本.ADT版本的对应关系 An

获取当前的版本代码和版本名称

我们在清单文件中都会写上版本名和版本号,版本名是给用户和商店看的,一般是几点几,比如1.2版本,版本号是给程序看的,可以来设置数据库更新或者是更改缓存. <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.kale.mycmcc" android:versionCode="5" android:versionName="

Ubuntu下gcc多版本共存和版本切换

https://my.oschina.net/u/2306127/blog/538139 摘要: Ubuntu系统使用的gcc版本随着发布版本的不同而不同,在编译android系统时不同的版本推荐用不同的gcc去编译,那么可不可以改变系统的gcc来适应android编译环境的需求呢?答案是可以的. Ubuntu系统使用的gcc版本随着发布版本的不同而不同,在编译android系统时不同的版本推荐用不同的gcc去编译,那么可不可以改变系统的gcc来适应android编译环境的需求呢?答案是可以的.