当前位置: 首页 > 工具软件 > OpenDaylight > 使用案例 >

OpenDaylight你不可不知的十大问题——OpenDaylight是什么?

赫连华皓
2023-12-01
一、ODL的诞生背景

随着互联网的普及,用户数量不断攀升,网络不堪重负。移动终端发展势如破竹,智能手机不断更新换代,各种手机软件层出不穷,手机控随时随地上网,导致流量需求与日俱增,负荷过度的网络无法满足用户需求。网络体系庞大,架构臃肿,不够灵活,不能适应不断涌现出的新业务需求,服务质量得不到保证。网络体系复杂,网络操作需要与其他IT操作的集成与协作,导致网络部署困难。网络更新麻烦,动手操作过多,网络管理员分身乏术。改良已经无法解决现有的网络问题,网络改革势在必行,于是SDN应运而生。

SDN是美国斯坦福大学clean slate研究组提出的一种新型网络架构。传统网络采用分布式策略工作,由设备制定转发策略,而SDN架构中设备不运行任何协议,转发表由控制器下发给设备,实现数据平台与控制平台的分离。SDN的核心思想就是控制与转发分离,将软件应用到网络控制中,并起到主导作用,而不是由固定模式的协议控制网络。SDN的目的是提高网络的可控性与可编程性,可以根据用户需求灵活地提供不同质量等级的服务。

二、ODL诞生的利益分析

SDN的提出立刻就在业界引起了轩然大波,尤其是一直被网络设备商压制的网络用户,将其视为摆脱网络设备商牵制,翻身做主人的机会,于是2011年一个以网络用户为主导的非营利性组织ONF就此诞生了。ONF宗旨是制定SDN统一标准,推动SDN产业化。ONF的工作重点是制定唯一的南向接口标准openflow,制定硬件行为转发标准,并且推出了一系列openflow 协议,其中较为稳定的是openflow1.0和openflow1.3版本。ONF从用户的角度制定协议,必然可以维护用户的利益,但是其间也出一些问题。

网络设备的研发十分复杂,是一个系统化工程,需要结合方方面面考虑,需要丰富的实战经验,而这些正是网络用户所缺乏的,因此直接导致openflow协议过于理想化,只能在实验及简单网络环境中应用,无法实现大规模商用。这种情况下ONF不得不接受网络设备商的参与,2013以设备商和软件商为主导的另一SDN组织ODL腾空出世,网络设备商出于自身利益出发,也加入到SDN大军中。并不是网络设备商都不计较利益,不计得失地贡献自己的技术,设备商也有自己的考量,越来越多的人看好SDN,这是一股不可逆转的趋势,与其坐等网络用户摆脱自己,不如化被动为主动积极参与其中,众多设备商联手研发出统一的控制框架,其中可以嵌入一些服务与应用模块,各大设备商都争相在大框架中融入更多的自己的技术,因为贡献越多意味着影响越大,在ODL中争得一席之地,才能为以后的发展留下生机。换句话说,置之死地而后生,贡献出自己的核心技术,这些技术随着SDN的推广被推向世界,说不定柳暗花明又一村呢!无论各自的目的是什么,ODL与ONF有共同的目的,推动SDN和网络功能虚拟化发展,打造统一开放的SDN平台,推动SDN产业化。

由此看来,ODL是SDN大环境下的必然产物,不仅仅得到网络用户的认可,还受到网络设备商的鼎力支持,注定在SDN发展中脱颖而出,成为SDN的灵魂产物之一。

三、ODL开源社区

ODL是由Linux基金会推出的一个开源项目,集聚了行业中领先的供应商和Linux基金会的一些成员。其目的在于通过开源的方式创建共同的供应商支持框架,不依赖于某一个供应商,竭力创造一个供应商中立的开放环境,每个人都可以贡献自己的力量,从而不断推动SDN的部署和创新。打造一个共同开放的SDN平台,在这个平台上进行SDN普及与创新,供开发者来利用、贡献和构建商业产品及技术。ODL的终极目标是建立一套标准化软件,帮助用户以此为基础开发出具有附加值的应用程序。

为了促进SDN发展,让更多的人认可SDN思想,开源社区开发者、开源代码、以及项目管理者组成了ODL开源社区,无论是有进取心的IT人士,网络服务供应商还是云服务供应商都可以加入ODL社区,ODL社区采用开放的管理模式,无论什么人都可以贡献代码,参选加入技术指导委员会,以多种途径参与项目方向走势讨论。

社区领导层主要包括董事会和TSC,董事会和TSC在不违反社区规章制度的条件下有权逐渐改变管理方式。董事会负责项目管理、运行以及市场相关决策。TSC主要负责项目选择、技术决定,保证项目透明度,以及项目生命周期管理。ODL厂商成员分别分为铂金成员、黄金成员、白银成员,会员等级越高会费也就越高。其中铂金会员有Brocade、Cisco、Citrix、Dell、Ericsson、HPE、Intel、Red Hat,黄金会员有NEC,白银会员有6WIND、A10networks、ADVA、Arista Networks等。下图罗列出了会员的图标:


 

四、ODL社区管理

大型社区通常有两类管理模式:业务管理和技术管理,ODL也不例外,其技术指导包含技术指导委员会和主要组件的项目管理者,而业务领导实例化为董事会。

OpenDaylight社区通过“技术指导委员会章程”规定两者的职责和权限,董事会主要负责设定ODL的策略方向(包括ODL的范围、技术愿景、方向),并对TSC提出的项目发布计划进行指导。而TSC则在董事会设定的策略方向内提供技术指导,制定发布规划、确立发布质量标准、挑选最佳的开发程序、监控技术进程,如果提交者和项目负责人之间出现技术冲突,TSC还需要负责调停。不仅如此,TSC还是ODL与其他联盟和组织之间的接口人。

任何组织和个人都有可能成为TSC成员。TSC最初有白金会员分别指定一个代表组成,TSC组织成立后,将会通过投票的方式将一些活跃的代码提交者选举为TSC成员。为了保证ODL的公平性和中立性,任何厂商都不可以控制投票权,如果发现与白金会员有关的非指定TSC成员(新选举出的TSC成员),该白金会员指定的TSC会员代表必须马上辞职。对于TSC成员(包括主席)的选举办法,董事会每年都会重新评估。

ODL包括多个小项目,每个项目的运营都离不开以下几类角色:贡献者(Contributor)、提交者(committer)和项目管理者(project leader)

贡献者负责开发代码或贡献其他成果,通过贡献高质量修补程序和功能优化代码有可能被选举为提交者。提交者负责控制技术方向,决定项目的设计、代码和修补等,具有将代码提交到源代码管理系统的权限,但其权限仅限项目本身,一个项目的提交者通常没有其他项目的提交权限。项目管理者负责制定项目的整体方向并向TSC汇报,项目管理者通常从提交者中通过投票的方式选出。五、ODL社区运营模式

ODL社区的运行模式自主、开放,奉行协作原则,只要你有能力就能参与其中。这是一个开源组织,并不是只有会员才能使用里面的代码,每个人都可以使用ODL的代码,为它做出贡献。这种运行方式激励了更多人参与ODL代码编写,ODL为大家合作、探究、讨论提供了良好的平台。虽然代码本身非常重要,但人们创建这些代码的方式、彼此协作的途径以及代码部署的操作机制同样不容忽视。

ODL的项目并不是一成不变的,而是不断地提出新项目,待项目成熟后即可加入ODL核心项目。项目提出后进入生命周期,做出相对应的模型,解释每个部分实现什么功能,根据模型写代码,用这种方式将项目模块化,大家协同合作,查缺补漏。每个项目需要包括贡献者、社区成员以及一个共同推选出的项目负责人,规定项目负责人是ODL项目的创始成员,这些最熟悉源代码的专家可以给其他项目参与者更好的引导。一个新项目不仅仅需要资深成员,还需要新成员的加入,资深成员需要在项目启动三个月内选拔新成员参与项目,项目才能获得TSC的批准。采取这种方式不但鼓励新成员更加深入地参与进社区项目,同时为社区注入源源不断的新生力量。核心项目的负责人不仅是项目的领导者,也是TSC的组成成员,在TSC中代表自己的项目团队。
ODL董事会与TSC都采用投票制度,无论什么等级的成员最多只有投一票的权利,并且在董事会中任何一个供应商都不可以掌握控制性投票权,没有一家公司可以拥有2个及以上的董事会席位。公开、透明、开放的运行模式保证ODL项目一直沿着SDN的方向发展,而不是取决于某个供应商。

SDN成为网络改革的焦点。与此同时,ODL开源社区愈加受到行业内人士的青睐,ODL集聚了最好的文化资源和最好的人力资源,为社区获得可持续优势提供了有利条件。ODL社区以开源形式推出ODL控制器,具有风险低、产品透明、行业适应能力强等特点,人们可以根据自己的意愿决定是否配置这个框架,以此减小接受新技术的风险,同时,人们可以利用已有的基础设备,实现新的SDN功能。ODL社区的开放性促进了SDN的广泛传播,让更多的人有机会接触到SDN,见证SDN的发展。

六、ODL控制器

ODL拥有一套模块化、可插拔灵活地控制平台作为核心,这个控制平台基于Java开发,理论上可以运行在任何支持Java的平台上,从Helium版本开始其官方文档推荐的最佳运行环境是最新的Linux(Ubuntu 12.04+)及JVM1.7+。

ODL控制器采用OSGi框架,OSGi框架是面向Java的动态模型系统,它实现了一个优雅、完整和动态的组件模型,应用程序(Bundle)无需重新引导可以被远程安装、启动、升级和卸载,通过OSGi捆绑可以灵活地加载代码与功能,实现功能隔离,解决了功能模块可扩展问题,同时方便功能模块的加载与协同工作。自Helium版本开始使用Karaf架构,作为轻量级的OSGi架构,相较于早前版本的OSGi提升了交互体验和效率,当然其特性远不仅仅于此。

ODL控制平台引入了SAL(服务抽象层 ),SAL北向连接功能模块,以插件的形式为之提供底层设备服务,南向连接多种协议,屏蔽不同协议的差异性,为上层功能模块提供一致性服务,使得上层模块与下层模块之间的调用相互隔离。SAL可自动适配底层不同设备,使开发者专注于业务应用的开发。

此外,ODL从Helium开始也逐渐完成了从AD-SAL(Application Driven Service Abstraction Layer)向MD-SAL(Model Driven Service Abstraction Layer)的演进工作,早前的AD-SAL,ODL控制平台采用了Infinispan技术,In nispan是一个高扩展性、高可靠性、键值存储的分布式数据网格平台,选用Infinispan来实现数据的存储、查找及监听,用开源网格平台实现controller的集群。MD-SAL架构中采用Akka实现分布式messageing。

七、ODL控制器设计原则

ODL在设计的时候遵循了六个基本的架构原则(以下来自opendaylight官方文档):

1、运行时模块化和扩展化(Runtime Modularity and Extensibility):支持在控制器运行时进行服务的安装、删除和更新。

2、多协议的南向支持(Multiprotocol Southbound):南向支持多种协议。

3、服务抽象层(Service Abstraction Layer):南向多种协议对上提供统一的北向服务接口。Hydrogen中全线采用AD-SAL,Helium版本AD-SAL和MD-SAL共存,Lithium和Beryllium中已基本使用MD-SAL架构。

4、开放的可扩展北向API(Open Extensible Northbound API):提供可扩展的应用API,通过REST或者函数调用方式。两者提供的功能要一致。

5、支持多租户、切片(Support for Multitenancy/Slicing):允许网络在逻辑上(或物理上)划分成不同的切片或租户。控制器的部分功能和模块可以管理指定切片。控制器根据所管理的分片来呈现不同的控制观测面。

6、一致性聚合(Consistent Clustering):提供细粒度复制的聚合和确保网络一致性的横向扩展(scale-out)。

八、ODL控制器架构

如图1.2所示,ODL控制器主要包括开放的北向API,控制器平面,以及南向接口和协议插件。北向API有OSGI和REST两类,同一地址空间应用使用OSGI类,而不同地址空间的应用则使用REST类。OSGI是有状态的连接,有注册机制,而rest是无状态链接。上层应用程序利用这些北向API获得网络智能信息、运行算法进行分析并且设计部署新的网络策略。

控制器平台包括一系列功能模块,可动态组合提供不同服务。其中主要包括拓扑管理、转发管理、主机监测、交换机管理等模块。服务抽象层SAL是控制器模块化的核心,自动适配底层不同的设备,使开发者专注于业务应用的开发。SAL北向连接功能模块,以插件的形式为之提供底层设备服务。南向连接多种协议插件,屏蔽不同协议的差异性,为北向功能模块提供一致性服务,SAL起到中间调度作用。

南向接口支持多种不同协议,如openflow1.0、openflow1.3、BEG-LS等。底层支持混合模式交换机和经典openflow交换机。

九、ODL的发展

ODL成立不到一年就推出了首个开源版本氢(hydrogen),氢计划中有多个项目,大概有五、六个项目里程碑,发布了基本版,虚拟化版和服务提供商版。基本版有一个标准的控制平台,包括Open Flow的设备,插件覆盖范围很广,有一些可选的设备可以加入进去,可以做交换机的管理,还有其他的功能都能够覆盖到。

虚拟化版增加了一些服务,主要运用了虚拟化技术,主要添加了VTN和open DOVE的相关模块。最大化利用物理设备资源的同时,提高服务人性化程度,用户可以部署自己的虚拟网络而无需了解底层复杂的物理拓扑。

服务提供商版在基本的版本上面增加了一些功能,增加了SNMP、PCEP的协议,在控制器平台里面还加入了一些其他的功能。

2014年9月29日发布了Helium版本,这里面不再需要三层代理,而是OpenDaylight处理三层的路由功能,Lithium版本在2015年发行,2016年2月也发布了Be版本的OpenDaylight。



本文转自d1net(转载)

 类似资料: