OpenDaylight的运维数据采集系统设计与实现

随着新的网络架构软件定义网络概念的提出，NFV、IOT、云计算Paas层，等很多领域都在进行着技术变迁与改革。而且根据调研，软件定义网络目前已成为当前全球网络领域最热门的研究方向，在权威机构IT领域预测未来五年十大关键趋势和技术影响中排名第二。互联网公司均在软件定义网络领域投入了大量的科研力量；传统网络服务公司，比如华为、思科、爱立信、IBM、惠普等也正在研制软件定义网络控制器和交换机。软件定义网络的核心思想是分离设备的转发层和控制层，控制层从设备侧抽象出，具体化为控制器。设备不再执行复杂的网络转发，路径计算等任务。
在软件定义网络开源控制器中，OpenDaylight作为最大的开源组织推出了OpenDaylight控制器，代码贡献者来自于知名网络公司思科、DELL、NEC、Juniper等。虽然是开源平台，各大厂商已经通过内部的扩展研发，让OpenDaylight控制器功能更大强大、应用领域更广。对OpenDaylight控制器，笔者已有两年的研发经验，项目开发中经过了很多思考。从OpenDaylight控制器中学习到了很多，但是也看到了一些不足或者说是亟待增强的功能。此次的研究内容为开发时间序列数据仓库模块，作为OpenDaylight的大数据平台，具体工作包括采集OpenDaylight控制器中平台运行数据、协议运维数据、网络流量监控数据；构造数据模型，融合、存储运维数据。本次系统设计的意义为增加智能属性于OpenDaylight控制器，后期应用机器学习或者人工智能技术。
实验结果表明，加载时间序列数据模块后，OpenDaylight控制器内部数据状况对于开发者来说不再是一个空洞，不论是第三方插件，还是数据库的查询更加直观地将OpenDaylight控制器的运维信息展现出来。
随着软件定义网络(SDN)的出现，不同的SDN平台如雨后春笋般涌现出来。包括各种开源组织，例如OpenDaylight、FloodLight、Beacon、Ryu；当然也包括各大厂商私有的，例如APIC(Cisco)、Active Fabric Controller(Dell)、Smart Network Controller(Huawei)等等。各种控制器都是为了实现SDN这种新网络架构的理念，并且各具特色[1]。在此，主要研究的为OpenDaylight控制器[2]。
时间序列数据是指在不同时间点上收集到的数据，这类数据反映了某一事物、现象等随时间的变化状态或程度[3]。时间序列仓库(Time Series Data Repository)是OpenDaylight控制器增强型模块。目前OpenDaylight控制器采集了OpenFlow的状态数据，并且存储在MD-SAL的数据库中。这限制了获取大量时间序列数据，并且也对北向应用不可用[4]。进行客户端获取时间序列数据操作时，对OpenDaylight控制器带来了性能上的损耗。
OpenDaylight的数据库比较封闭，当然在已

知的具体的数据节点的条件下，可以访问到数据。虽然增加了安全性，但是又不够灵活[5]。
1.2 课题研究目的和意义
时间序列仓库模块的设计是为了解决此类问题。采集并且存储不同的类型的时间序列数据，包括OpenFlow、Snmp、流量统计信息、日志信息等等。并且TSDR相对于OpenDaylight来说是一个可插拔的模块，数据库也是可选的，客户端可以按需自由选择。
TSDR模块的设计目的是为实现收集、存储、查询、维护OpenDaylight控制器中的状态数据，包括配置数据和操作数据。例如，目前OpenFlow协议插件提供了收集OpenFlow协议的状态数据，状态数据的获取是通过与OpenDaylight控制器相连并且支持OpenFlow协议的交换机发送的。OpenDaylight控制器将这些数据存储在状态数据库中[6]。TSDR运维数据收集可以按照固定的时间将ODL的状态数据库中的OpenFlow运维数据拉取出，附加时间段属性，存储在该模块的数据仓库中。
随着OpenDaylight已经广泛地应用于网络业务处理中[7]，据此，TSDR可以被应用到的领域有：IoT(物联网)应用、NFV案例、软件定义数据中心的分析与自动化等等[8]。例如，能应用于IoT数据分析的应用的原因是由于TSDR具有通用性、开放性、弹性的、可扩展的特点。应用于NFV数据分析与自动化的原因，同样是因为TSDR采用一套通用的数据模型，基于通用的时间序列数据平台。应用于软件定义数据中心的分析是因为TSDR可以防范DDos的攻击[9]。
1.3 国内外研究概况
SDN的前身最早可追朔到“可编程网络”的概念，此后陆续有学者提出相应的可编程网络思想和方法。2004年，4D Project项目提出了一种Clean-Slate的网络设计方案[10]，该方案重点突出了网元之间的交互协议与路由决策逻辑的分离[11]。2011年，McKeown 等研究者组织成立了开放式网络基金会(Open Networking Foundation，简称ONF)[12]，专门负责相关标准的制定和推广，包括OpenFlow 标准、OpenFlow 配置协议和SDN 白皮书，这大大推进了OpenFlow 和SDN 的标准化工作，也使其成为了全球开放网络架构和网络虚拟化领域的研究热点[13]。
在学术界，美国GENI、Internet2、欧洲OFELIA和日本的JGN2plus先后展开对SDN 的研究和部署[14]，国内由清华大学牵头，中科院计算所、北邮、东南大学、北京大学等单位参与开展了类SDN思想的”未来网络体系结构和创新环境”863项目研究[15]。
在标准化方面，除了ONF的标准化工作，IETF（互联网工程任务组）、IRTF（互联网研究任务组）、ITU-T（国际电信联盟电信标准化部门）、ETSI（欧洲电信标准化协会）等也已成立相应的工作组，围绕各自领域的SDN应用和架构展开标准研究和制定工作[16]。
SDN领域的技术成果、水平方面

，国外还是走在国内的前面。从2006年，SDN的理念提出之后，国外已经开始了这方面的研究。随后诞生了很多SDN控制器，如开源的Ryu、FloodLight、NOX等等[17]。在编程语言发面，开发了新的声明式编程语言P4[18]。P4用于编程程序已下达命令给数据转发面的设备[19]。如今，设计一款高性能的网络设备是相当的痛苦，你要确定你所需要的设备有哪些特性，然后你要找到一块最符合特性需求的交换机芯片。接着你要签署一份保密协议获得软件开发工具包(SDK)，最后调用合适的API进行编程使芯片满足你的系统需求[20]。但是由于你系统取决于SDK，所以设计是被芯片厂商锁定的[21]。P4试图在从根本上改变我们设计网络系统的方式。
目前国内对SDN的研究主要集中在华为、H3C、盛科网络等公司，华为也开发了ONOS，应用于电信网的SDN控制器，并部署了T-SDN(传输SDN)网络。笔者研究生阶段的基于SDN的流量调度项目部署到了金融业的数据中心，虽然国内开展SDN的研究时间较短，但是成果显著。SDNLAB作为国内最大的SDN社区，提供了一个平台供相关研究者相互交流，并且也有国外专家参与进来。总的来看，国内SDNers对于这项新技术都报以很大的兴趣，和很高的热情。
1.4 论文主要研究内容
虽然OpenDaylight控制器内部已有数据库，且可以存储状态数据和操作数据。但是TSDR模块内部创建了时间序列数据仓库，提供大量用于收集、存储、查询与SDN网络相关的运维数据服务。TSDR在OpenDaylight控制器中所处的位置与MD-SAL等价。运行环境的数据是指DataStore中的状态与配置数据。例如，南向协议插件OpenFlow Plugin收集OpenFlow交换机发送的packet-in报文，解封装后存储至OpenDaylight的状态数据库。在TSDR的数据采集机制中，TSDR会定期地从OpenDaylight的状态数据库中拉取数据，并存储起来；基于Notification机制的数据采集插件，不仅采集了包括OpenFlow的状态数据，而且MD-SAL中间件的消息传递中可使用这些数据。另外，在TSDR的采集机制中，模块会订阅、存储MD-SAL消息总线中传递的数据。
TSDR充分利用MD-SAL的Akka集群能力来处理时间序列数据的处理性能和可扩展性。在大型部署方案，如数以万计的流量被推送到TSDR模块，用于时间序列数据处理的一个或多个MD-SAL实例被创建，形成一个分布式体系结构。通过这种设计，时间序列数据处理从逻辑与OpenDaylight控制器分离，控制器可以把重点放在控制流量的核心功能。
当TSDR模块部署至OpenDaylight平台后，北向各种应用程序利用将时间序列数据存储在TSDR在时间，捕获OpenDaylight的性能数据、ODL业务配置数据。这包括应用程序的安全风险检测，性能分析，操作配置优化

，流量工程，和网络分析与自动化智能。
TSDR在功能上主要为，运维数据采集、运维数据合并、运维数据存储、冗余运维数据清除、运维数据查询。从TSDR模块的设计上，为了保持通用性和可扩展性，设计了具有相应特点的数据模型，封装数据存储的接口；TSDR的定位为数据存储的中间件，不同的数据库需要相应的存储插件，目前已经完成的数据存储插件有HBase、Cassandra和基于Hibernate框架的H2插件。

2 关键技术分析
本章介绍了运维数据采集系统设计所需要的开发平台、核心技术、协议。运维数据的产生来源包括协议产生、SDN控制器捕获、SDN控制器产生三个方面，为了实现该模块功能，我们采用以下设计思想和技术来实现。
2.1 OpenFlow协议
2.1.1 起源
OpenFlow起源于斯坦福大学的Clean Slate项目，CleanSlate项目的最终目的是要重新发明英特网[22]。此发明旨在改变设计已略显不合时宜，且难以进化发展的现有网络基础架构。在2006年，斯坦福的学生Martin Casado领导了一个关于网络安全与管理的项目Ethane，该项目试图通过一个集中式的控制器，让网络管理员可以方便地定义基于网络流的安全控制策略，并将这些安全策略应用到各种网络设备中，从而实现对整个网络通讯的安全控制[23]。
于是，他们便提出了OpenFlow的概念，并且Nick McKeown等人于2008年在ACM SIGCOMM发表了题为OpenFlow: Enabling Innovation in Campus Networks的论文[24]。首次详细地介绍了OpenFlow的概念，该篇论文除了阐述OpenFlow的工作原理外，还列举了OpenFlow几大应用场景[25]。包括：(1)校园网络中对实验性通讯协议的支持（如其标题所示）；(2)网络管理和访问控制；(3)网络隔离和VLAN；(4)基于WiFi的移动网络；(5)非IP网络；(6)基于网络包的处理。当然，目前关于OpenFlow的研究已经远远超出了这些领域[26]。
2.1.2 标准
自2010年初发布第一个版本（v1.0）以来，OpenFlow规范已经经历了1.1、1.2以及最近发布的1.3等版本[27]。同时，今年年初OpenFlow管理和配置协议也发布了第一个版本(OF-CONFIG 1.0 & 1.1)。列出了OF和OF-CONFIG规范各个版本的发展历程及变化，从图中可以看到目前使用和支持最多的仍然是1.0和1.1版本。
基于OpenFlow为网络带来的可编程的特性，Nick和他的团队（包括加州大学伯克利分校的Scott Shenker教授）进一步提出了SDN（Software Defined Network, 目前国内多直译为“软件定义网络”）的概念。其实，SDN的概念据说最早是由KateGreene于2009年在TechnologyReview网站上评选年度十大前沿技术时提出[28]。
如果将网络中所有的网络设备视为被管理的资源，那么参考操作系统的原理，可以抽象出一个网络操作系统（Network OS）的概念—

这个网络操作系统一方面抽象了底层网络设备的具体细节，同时还为上层应用提供了统一的管理视图和编程接口[29]。这样，基于网络操作系统这个平台，用户可以开发各种应用程序，通过软件来定义逻辑上的网络拓扑，以满足对网络资源的不同需求，而无需关心底层网络的物理拓扑结构。关于SDN的概念和原理，可以参考开放网络基金会（Open NetworkingFoundation）于今年4月份发表的SDN白皮书Software Defined Networking：The New Norm forNetworks[30]。
从上面的描述中，可以看出OpenFlow/SDN的原理其实并不复杂，从严格意义上讲也很难算是具有革命性的创新。然而OpenFlow/SDN却引来了业界越来越多的关注，成为近年来名副其实的热门技术。目前，包括国外的惠普、IBM、思科、NEC和国内的华为、华三、中兴等传统或者新生的网络设备制造商都已纷纷加入到OpenFlow的阵营，相继开发出了支持OpenFlow协议标准的交换机。
2.1.3 原理
网络设备维护一个FlowTable并且只按照FlowTable进行转发，Flowtable本身的生成、维护、下发完全由外置的Controller来实现，注意这里的FlowTable并非是指IP五元组，事实上OpenFlow 1.0定义的了包括端口号、VLAN、L2/L3/L4信息的10个关键字，但是每个字段都是可以通配的，网络的运营商可以决定使用何种粒度的流，比如运营商只需要根据目的IP进行路由，那么流表中就可以只有目的IP字段是有效的，其它全为通配[31]。
流表由很多个流表项组成，每个流表项就是一个转发规则。进入交换机的数据包通过查询流表来获得转发的目的端口。流表项由头域、计数器和操作组成；其中头域是个十元组，是流表项的标识；计数器用来计数流表项的统计数据；操作标明了与该流表项匹配的数据包应该执行的操作。
控制层与转发层相分离的架构对于网络二层交换机来说，意味着MAC地址的学习完全由Controller来实现，VLan和三层路由器的配置工作也交由Controller下发相应的配置给交换机。对于网络三层设备，各类IGP/EGP路由器运行在Controller之下，Controller根据需要下发相应的配置给对应的路由器。流表的下发可以是主动的，也可以是被动的，主动模式下，Controller将自己采集的流表信息主动下发给网络设备，随后网络设备可以直接根据流表进行转发，被动模式是指网络设备收到一个报文没有匹配的FlowTable记录时，将该报文转发给Controller，由后者进行决策该如何转发，并下发相应的流表，被动模式的好处是网络设备无需维护全部的流表，只有当实际的流量产生时才向Controller获取流表记录并存储，当老化定时器超时后可以删除相应的流表，故可以大大节省TCAM空间[32]。
2.2 OpenDaylight控制