文章目录
1 SDN介绍
SDN:Software-Defined Networking 软件定义网络
1.1 SDN起源
Clean Slate课题:2006年,美国斯坦福大学启动了一个名叫Clean Slate的研究课题。当时网络从最初的小型专用局域网络,变成了空前庞大和复杂的世界级网络。网络规模的持续扩张,网络设备的不断增加,超过了早期设计的承受能力,也使得网络维护变得举步维艰。由此设立了Clean Slate课题,来解决这些问题,探讨未来网络的可能性架构。
2011年,由Google、Facebook、微软等公司共同发起成立了一个对SDN影响深远的组织,那就是ONF(Open Networking Foundation,开放网络基金会)。ONF的主要发起成员是德国电信、Facebook、Google、微软、雅虎等公司。这些公司要么是网络服务提供商,要么是运营商,没有一个是来自设备商的。他们成立ONF的目的,是为了推动SDN和OpenFlow协议的发展。他们希望SDN这个网络新技术不要被设备商控制,成为设备商的赚钱工具。上述发起人里面,最值得一提的是Google。
2010年,Google开始将数据中心与数据中心之间的网路连线(G-scale),转换成SDN架构。整个改造分为三个阶段。到了2012年,整个Google B4网络完全切换到了OpenFlow网络。改造之后,Google B4网络的链路带宽利用率提高了3倍以上,接近100%。
2013年4月8日,在Linux基金会的支持下,作为网络设备商中的领导者,Cisco与IBM、微软等公司一起,发起成立了开源组织OpenDaylight,共同开发SDN控制器。OpenDaylight强调SDN控制器不仅仅局限于OpenFlow,而是应该支持多种南向协议。同时,OpenDaylight还强调,应该用分布式的控制平台,取代单实例的控制器。这样可以管理更大的网络,提供更强劲的性能,还能增强系统的安全性和可靠性。由此诞生了一些列厂家自研发的SDN控制器。
未来发展:
未来,随着网络规模的扩大,SDN控制器肯定会继续往分布式的方向发展。控制器之间的分工协作会更加深入,甚至可能出现集群。控制器也会引入NFV虚拟化技术,与OpenStack等云平台进行整合。
1.2 什么是SDN?
即把控制面从转发面分离出来,控制面控制多台设备。 SDN是新兴的网络技术构架,具有动态可管理,高适应性,以及优秀的成本效益,以满足今天高带宽应用的动态需求。SDN架构解耦网络控制层和转发层,通过对网络控制的直接编程,使得基础网络承载可以被抽象成各种可为上层应用调用的服务。 OpenFlow® 协议是SDN解决方案的基本要素。
传统网络中,各个转发节点都是独立工作的,内部管理命令和接口也是厂商私有的,不对外开放,各个节点各自实现自己对数据的控制转发。
SDN网络,就是在网络之上建立了一个SDN控制器节点,统一管理和控制下层设备的数据转发。所有的下级节点,管理功能被剥离(交给了SDN控制器),只剩下转发功能。
控制和转发分离之后,借助规范化的API接口,用户可以通过编写软件的方式,对网络进行管理。整个网络,就像个完整的机器人一样可供驱使。
1.3 SDN三层架构
上北下南,SDN控制器向上与应用平面进行通信的接口,叫做北向接口,也叫NBI接口(northbound interface)。SDN控制器向下与数据平面进行通信的接口,叫做南向接口,也叫CDPI接口(control-data-plane interface,控制数据平面接口)。
北向接口相对来说比较好搞,麻烦的是南向接口及其协议。因为它直接影响到SDN控制器的命令能否准确下达到无数的底层网络设备。
因此,SDN技术的发展史,简而言之,就是围绕SDN控制器和南向接口的“王位争夺史”。
2 OpenDaylight介绍
2.1 什么是OpenDaylight
2013年,由Linux Foundation和多家网络巨头如Cisco、Juniper和Broadcom 等公司一起创立开源项目OpenDaylight (ODL), OpenDaylight是SDN开发及运行的平台。
2.2 ODL发布的版本
https://wiki.opendaylight.org/view/Release_Plan
2.3 ODL平台架构
南向通过 plugin 的方式来支持多种协议,包括OpenFlow1.0、1.3,BGP-LS 等。这些模块被动态挂载到服务抽象层(SAL),SAL 为上层提供服务,将来自上层的调用封装为适合底层网络设备的协议格式。
控制器为应用(App)提供开放的北向 API。支持 OSGI 框架和双向的 REST 接口。OSGI框架提供给与控制器运行在同一地址空间的应用,而 REST API 则提供给运行在不同地址空间的应用。所有的逻辑和算法都运行在应用中。
2.4 ODL各子项目依赖关系
- 确定项目类型是平台架构部分、还是南向插件部分、还是业务功能部分
- 如何使用这些项目
- 项目是需要依赖哪些项目的
2.5 ODL架构特点
- 基于OSGi的模块化设计
- 多南向协议-OpenFlow,Netconf,OVSDB…
- 模型驱动的业务抽象层(MD-SAL)是ODL的核心
- 全分布式的消息及存储机制
3 OpenDaylight初步实践
3.1 实验环境
两台互通的虚机:一台Ubuntu 16.04桌面版,上面已经下载了ODL Oxygen-SR1版本karaf-0.8.1(OpenDaylight控制平台),另一台Ubuntu 14.04版本,已经安装了mininet 2.2.0版本(虚拟网络设备资源)
3.2 实验目的
- 了解并掌握ODL的启动方式,JVM的参数配置
- 了解并掌握bundle,feature,log等基本的命令使用
- 了解并掌握karaf的基本配置
3.3 ODL的下载和运行
下载:
已发布最新版本下载地址:http://docs.opendaylight.org/en/latest/downloads.html
运行:
启动参数配置:修改Java虚拟机运行内存,karaf启动方式,启动参数(clean,debug…)
4 代码层面知识
4.1 OSGI(规范)
OSGi(Open Service Gateway Initiative,直译为“开放服务网关”)实际上是一个由OSGi联盟发起的以Java为技术平台的动态模块化规范,OSGi不是一个应用层面的框架,而是设计层面的规范。软件设计就不外乎复用、内聚、耦合三个主题,OSGi作为Java的模块化规范,也是为了更好地解决Java在这三个主题的问题。OSGi规定了如何定义一个Module以及这些模块之间如何交互。在OSGi规范中,Java模块被称为Bundle,OSGi规范就是指导怎么令这些Bundle能更好的有高内聚性、有松耦性,能更好地被复用。基于OSGi的应用,就是由一个一个Bundle组成的,通过OSGi把这些Bunde组织在一起,就形成了系统。
OSGI框架
4.2 Bundle
4.2.1 概念
Bundle是OSGi中最基本的单位,通俗地讲,如果说OSGi是基于Java平台的“模块化开发体系”,那么Bundle便是其中的“模块”
一个符合OSGi规范的Bundle首先必须是一个符合JAR文件格式规范的JAR包,JAR文件格式规范里定义的/META-INF/MANIFEST.MF文件用于描述JAR包的元数据信息,如JAR包的版本、数字签名信息等,Bundle在MANIFEST.MF文件中添加了大量扩展定义,如描述该Bundle可以提供哪些资源、依赖哪些其他Bundle、启动或卸载时要执行哪些动作等
4.2.2 Bundle生命周期
4.2.3 Bundle间的依赖
OSGi对Java平台的类加载机制的一个重要改进就是支持包级别的类导入和导出。在OSGi中,每个Bundle都有自己的类加载器,完成内部类和外部类的隔离。该加载器能够看到Bundle Jar文件内部的类和资源。Bundle通过配置jar包中的MANIFEST.MF,可以控制从Bundle导出的包,而没有导出的包,则在Bundle外部是不能够访问的。这样就很好地完成了内部类和外部类的隔离。
Import-Package:引用其他Bundle的接口
Export-Package:暴露给其他Bundle接口访问
4.3 Karaf(类似于OSGI的一个发行版本)
提供了更丰富的功能
Karaf, 一个基于OSGi的运行环境, 提供了一个轻量级的OSGi容器,可以用于部署各种组件和应用程序
Karaf容器的特点:
- 系统服务:
自带service wraper功能,把karaf包装成系统服务,设置为守护进程,karaf项目可以一直运转 - 热部署
尽管OSGi支持热部署,但并不是自动热部署,需要调用一些API去执行插拔的动作。 - 动态配置
Karaf在$KARAF_HOME/etc文件夹中存储配置文件。这些配置内容可以在Karaf运行时动态修改。 - 日志处理
基于Log4J的日志系统,同时支持多种日志API,如JDK 1.4, JCL, SLF4J, Avalon, Tomcat, OSGi等。 - 控制台
可以在控制台进行服务管理、安装bundle等操作。还可以扩展自己的控制台命令。可以通过SSH远程访问其他服务器上的Karaf控制台。 - 多实例管理
一个服务器上可以运行多个Karaf实例。对实例的管理可以在Karaf控制台中进行。 - Bundle仓库
Karaf中内置了Pax URL的MVN协议,可以从Maven中央仓库安装bundle。 - Bundle集合(Feature)
类似于Eclipse的Feature,Karaf中也支持Feature,即bundle的集合。使用Feature可以简化OSGi应用的部署。
4.4 Feature概念
feature屏蔽了bundle之间的复杂的依赖关系