时间:2024-07-28
李心舒(南京师范大学,江苏南京210023)
经过几年的探索,软件定义网络(SDN)已经从概念逐步走向实用。特别是近年来由于开源社区的贡献,SDN 的应用得到了迅速发展。本文将介绍当前主要的开源SDN开发资源,并探讨编程实现SDN控制器的思路。
SDN是在服务器虚拟化和云计算技术逐步成熟的基础上提出的,以平台化思想提供网络业务的技术。SDN 采用将网络控制逻辑和数据转发功能分离的思路,并保证网络控制逻辑的可编程性和开放架构,实现通过软件对网络业务的灵活控制和快速提供。
SDN架构包括应用层、控制层和基础设备层(见图1)。
SDN 应用层提供具体的业务功能和操作界面,它通过调用SDN控制器的北向接口API实现对网络设备的控制。
SDN 控制层的核心是SDN 控制器,它负责接收应用层的服务请求,并对各网络服务进行处理,然后通过控制器的南向接口向下传达给基础设备层。同时SDN控制层为应用层提供一个关于物理网络的抽象视图,对应用层屏蔽具体的设备实现细节。
基础设备层由网络中的物理设备组成,实现控制器下发的控制命令,完成具体的转发任务。
图1 SDN架构
SDN的快速发展和各个开源社区有着不可分割的紧密联系,而且随着各类开源社区的不断发展,开源项目也在不断增多。目前开源控制器资源主要有Open⁃Daylight、ONOS、Floodlight等。
a)OpenDaylight是Linux基金会的协作项目,是一个开放的平台,可以通过网络编程实现SDN并为NFV提供一个稳固的基础。
b)ONOS 是由ON.Lab 使用Java 及Apache 实现的主要面向服务提供商的高可靠性开源架构。
c)Floodlight 是由包括来自Big Switch Networks 的工程师实现的Apache 许可、基于Java 语言的企业级OpenFlow控制器。
其中以设备提供商为代表的OpenDaylight 和以服务提供商为首的ONOS 发展势头强劲,成为两大主流控制器开发资源,故下文仅对这两者作一简单比较。
OpenDaylight架构共分为3个层次,分别是网络应用与业务流程(即应用层)、控制平台(即控制层)和物理与虚拟网络设备(即基础设备层),其中核心的模块化、可添加功能插件的平台直接由自带的Java 虚拟机实现,可以运行在任何操作系统上,实现功能模块的灵活加载和屏蔽下层协议的差异性。
ONOS 是由ON.Lab 推出的开放网络操作系统,它的设计理念是能够在任何硬件上灵活地创建服务并且大规模部署,同样提供一个SDN 控制平面(南向和北向API),以及一系列的管理、控制和服务应用程序。
OpenDaylight与ONOS所面向的对象不同,前者由厂商主导,后者由运营商主导。而最大的不同在于OpenDaylight增加了服务抽象层SAL,它负责南向连接多种协议,即除了支持OpenFlow 协议之外,还能够处理不同的标准协议,屏蔽不同协议之间的差异性,为上层模块提供一致性服务。
OpenDaylight 可以使用户通过在服务抽象层上编写运行在不同硬件设备和南向协议上的应用,方便地进行网络部署,故下文中主要介绍OpenDaylight 的主要组成和用法。
OpenDaylight 控制器是纯软件并且可以运行在任意操作系统上,它的结构如图2所示。
图2 OpenDaylight结构
OpenDaylight控制器平台中的服务抽象层SAL,能够支持多种标准协议、控制模块间数据交互、数据存储读取和API 调用,是控制器平台中最核心的模块。在OpenDaylight 控制器的南向平面中可以支持多种协议,这些协议作为南向Plugin 动态连接在抽象服务层(SAL)中。SAL向上提供服务而不考虑在控制器和网络设备之间使用的协议,这在协议变化的情况下向应用提供了有价值的保护。
控制器为了管理设备,将设备的容量、可达性等信息存储在拓扑结构管理模块中,其他的组件如ARP处理模块、交换机管理模块等帮助生成拓扑结构数据。
OpenDaylight 控制器提供应用可使用的开放的北向API,它支持OSGi 框架和REST,和控制器运行在同一地址空间的应用使用OSGi框架。
在进行开发时,根据分析得到的设计目标进行不同层次的开发。当所需要的服务已由SAL提供而只需要修改数据显示等时,可以直接调用OpenDayligt REST API进行开发,而不关注底层的功能实现。但当现有的OpenDaylight 没有提供所需要的特定功能时,就要进行OpenDaylight 控制器组件的开发,即借助已经实现的功能或模块在服务抽象层(SAL)上开发Plu⁃gin 实现具体的服务。本章先介绍开发相关的基本概念,接着重点介绍开发的基本步骤。
OpenDaylight 控制器平台中的核心模块——服务抽象层SAL,又分为AD-SAL(API Driven-SAL)和MDSAL(Model Driven-SAL),但因在AD-SAL 中南北向API 是一一映射关系,同一API 无法被复用,造成SAL模块复杂化,而MD-SAL 可使南北向接口和SDN 控制器中服务或组件用到的数据结构统一,前者逐渐被后者取代。
Plugin 是通过SAL 实现的ODL 控制器的功能模块,南向Plugin 向SAL 提供管理南向设备或服务的操作接口,应用可以通过北向API 查询需要使用的南向Plugin并和网络设备交互来实现统一的抽象服务。
根据Plugin 和MD-SAL 的关联方式,Plugin 分为BA(Binding-Aware)和BI(Binding-Independent),前者指使用根据Yang Model 定义而自动生成的Java Bind⁃ings 的Plugin,后者指使用DOM 格式编程接口的API。Yang是一种数据模型语言,被用来定义ODL中全部的API,相比而言更加抽象、具有更好的可扩展性和更高的开发效率。故本文仅介绍BA 类的MD-SAL Plugin开发。
开发过程主要分为3个步骤,首先用Yang语言对需要的功能进行建模,然后实现Plugin 所要提供的服务,最后定义REST API接口使得能够通过北向接口调用服务。
首先要定义能够从Yang 建模文件自动生成API的Yang项目。需要创建Yang项目并在项目目录下创建Yang建模文件定义北向数据模型,指定该模块的命名空间,导入需要使用的其他Yang 模块,定义RPC 调用方法和输入输出信息及相应的数据类型。若新创建的Yang 模型和已存在的Yang 模型位于同一目录下,则只需继承最上层的pom.xml并配置编译打包的形式和编译工具信息,否则还需要创建最上层的Maven pom.xm l,在其中配置自动生成的Java 源文件的路径、配置文件的目录路径、OSGI Bundle的依赖关系和编译工具信息,并指定关联创建的其他模块。编译Yang模型文件,并根据pom.xml中的配置信息自动生成API和OSGI Bundle。
接下来要实现Plugin所提供的具体服务。因为配置子系统能够对服务的生命周期进行管理,所以利用它来将实现的服务实例化并和MD-SAL 连接。为此,首先需要创建Yang 文件描述所实现服务的配置信息和需要的其他服务,并设定该模块的识别字符和对应的分支操作。implementation模块的pom.xml文件中除需和上述类似的配置信息外,还要指定依赖已定义的model 模块。根据pom.xm l 中的配置将该模块自动生成Java Bindings,并在其中创建Impl.java文件实现Plu⁃gin的具体服务。Impl类需要实现由Yang建模文件生成的Service接口,并且根据建模中定义的输入输出信息在操作中接收和返回数据。然后为了在MD-SAL唤醒bundle时能够实例化服务,需要在自动生成的Mod⁃ule.java文件中添加一个logger和Impl服务的实例并用配置变量赋值然后写入到MD-SAL。打开karaf 控制器,将生成的2 个jar 文件(model and provider)复制到karaf 的配置目录下,创建配置文件描述注入对象Plu⁃gin的信息,定义注入数据。
以上2 个步骤所有的设置都完成后,就可以通过自动生成的Rest API调用定义的服务。
所以基于OpenDaylight 可以轻松地实现扩展SDN控制器的功能模块,只需要专注于提供北向服务的Yang model 的设计实现,南向可直接调用已经实现的功能或模块,主要是南向对不同协议的支持,如已经实现的OPENFLOW 可以用于LAN 控制器的开发、PCEP可以用于WAN控制器的开发等。
可编程的、灵活的SDN是现今网络技术发展的重要方向。目前,在许多开源资源的支持下,已经可以比较快速地开发SDN 控制器。在目前的众多开源项目中,OpenDaylight利用易于掌握的服务抽象层(SAL)编程思想和已实现的实用功能模块,提供了简单易用的开发工具。希望本文介绍的开发方法,能给SDN控制器的开发者带来有益的帮助。
[1] SDN Defined[EB/OL].[2015-06-11].https://www.opennetworking.org/sdn-resources/sdn-definition.
[2] Software-defined networking[EB/OL].[2015-06-11]. https://en.wikipedia.org/wiki/Software-defined_netWorking.
[3] 张朝昆,崔勇,唐翯祎,等.软件定义网络(SDN)研究进展[J].软件学报,2015,26(1):62-81.
[4] SDN 你必须知道的十大问题——SDN 有哪些开源项目[EB/OL].[2015-06-11].http://www.sdnlab.com/8091.htm l.
[5] 左青云,陈鸣,赵广松,等.基于OpenFlow的SDN技术研究[J].软件学报,2013(5).
[6] OpenDaylight Controller:MD-SAL:Toaster Stop-By-Step[EB/OL].[2015-06-11].https://www.opendaylight.org/.
[7] Controller Projects′Modules/bundles and Interfaces[EB/OL].[2015-06-11]. https://wiki.opendaylight.org/view/GettingStarted:Develop⁃er_Main.
[8] ONOS 预热篇之ONOS 与OpenDaylight 比较[EB/OL].[2015-06-11].http://www.sdnlab.com/4309.htm l.
[9] ODL MD-SAL APP 架 构 入 门-Final[EB/OL].[2015-06-11].http://pan.baidu.com/s/1c0ddUW4.
[10]郝鹏. 浅谈OpenDaylight 的二次开发[EB/OL].[2015-06-11].http://www.sdnlab.com/11587.html.
[11]OpenDaylight 学习文档及开发初级教程[EB/OL].[2015-06-11].http://www.sdnap.com/sdnap-post/4370.htm l.
[12]基于OpenDayLight 的SDN 网络转发机制研究[EB/OL].[2015-06-11].http://network.51cto.com/art/201312/422938.htm.
[13]OpenDaylight 学习[EB/OL].[2015-06-11]. http://blog.csdn.net/quqi99/article/details/9156497.
[14]源码解读ODL 与OpenFlow 交换机建立过程[EB/OL].[2015-06-11].http://www.sdnlabcom/12035.htm l.
[15]ODL 应用开发之MD-SAL 中级教程[EB/OL].[2015-06-11].http://www.sdnlab.com/11995.htm l.
[16]ODL学习笔记基础之模块开发篇[EB/OL].[2015-06-11].http://www.sdnlab.com/11456.htm l.
李心舒,现就读于南京师范大学计算机科学与技术专业。
我们致力于保护作者版权,注重分享,被刊用文章因无法核实真实出处,未能及时与作者取得联系,或有版权异议的,请联系管理员,我们会立即处理! 部分文章是来自各大过期杂志,内容仅供学习参考,不准确地方联系删除处理!