ODL中拓扑展现功能总结

前言

一直有很多朋友在使用ODL做实验时很好奇ODL的拓扑是怎么来的,其实这个拓扑模块的后台数据的组成是由topology-manager来实现的,当然还会结合inventory-manager模块以及LLDP模块。这里只讲topology-manager模块,该模块是在openflowplugin-release-lithium-sr3大工程中的applications文件夹下。

topology-manager模块是作为openflowplugin的应用层程序(APP),负责处理operational数据库下network-topology:network-topology数据节点(datastore数据库)的增删改查,例如odl控制器发现添加一台主机host、新加主机与交换机的link链接等。显示拓扑的前端需要从该数据节点上获取主机或者交换机节点数据才能绘制网络拓扑图,构成拓扑图来源有两方面,一方面是通过LLDP发现的switch设备以及相关link连接,另一外面是通过L2switch的hosttracker模块发现的下挂在switch上的host主机以及相关连接。

首先从YANG模型上分析topology-manager模块,由于拓扑显示的前台数据跟network-topology的YANG树形模型关系紧密,所以直接看network-topology。

一、拓扑的数据模型

network-topology:network-topology数据节点是直接使用了外部ietf-topology定义的yang文件,主要的数据树结构为:

从中可以看到network-topology的container放的是一个topology列表,而每一个topology都是由node列表与link列表组成,也就是说web页面上的拓扑由交换机、主机节点以及对应的链接组成。

二、Topology-manager与其他模块的依赖

在topology-manager的处理流程需要依赖两条主线,第一是在applications文件夹下的topology-lldp-discovery模块会处理交换机与交换机的link连接(大概流程是lldp-speaker发送lldp报文探测新加入的设备是否为openflow交换机,如果是交换机则由topology-lldp-discovery处理并发出link发现的通告),因此topology-lldp-discovery模块会发出以下两类通告FlowTopologyDiscoveryListener:

第二是topology-manager需要监听Nodes/Node/NodeConnector/FlowCapableNodeConnector和Nodes/Node/NodeConnector/FlowCapableNode数据的变化,此数据就是在inventory-manager模块添加的交换机信息节点,所以当inventory-manager模块新加或者移除一台交换机节点时,会触发Nodes/Node/NodeConnector/FlowCapableNodeConnector
以及Nodes/Node/NodeConnector/FlowCapableNode数据节点的变化,进而引起topology-manager模块进入

处理流程。

三、Topology-manager流程

topology-manager的入口在TopologyLldpDiscoveryImplModule.java文件的createInstance()函数,进入该函数后new出FlowCapableTopologyProvider对象,然后注册FlowTopologyDiscoveryListener通告的接收器FlowCapableTopologyExporter,同时设置监听Nodes/Node/NodeConnector/FlowCapableNodeConnector
以及Nodes/Node/NodeConnector/FlowCapableNode的数据变化,
先分析FlowTopologyDiscoveryListener通告的接收器FlowCapableTopologyExporter。

3.1 onLinkDiscovered事件

当控制器通过LLDP发现新加的设备与现有设备存在一条链路时(交换机与交换机之间的链路),会触发onLinkDiscovered函数的调用,将该link保存在数据库当中。

3.2 onLinkRemoved事件

当上述链接断开之后,就会触发onLinkRemoved函数的调用,将之前保存在数据库当中的link信息删除。

3.3 FlowCapableNode数据变化事件

再来分析监听Nodes/Node/NodeConnector/FlowCapableNode的数据变化的NodeChangeListenerImpl,当Nodes/Node/NodeConnector/FlowCapableNode的数据发生变化(inventory-manager当中新加/删除一台交换机节点),会触发NodeChangeListenerImpl的onDataChanged函数调用,在该函数当中调用了以下两个函数

两个函数在自己内部判断是否是节点添加/删除事件,最终将交换机节点信息写入network-topology数据树当中。

3.4 FlowCapableNodeConnector数据变化事件

最后分析Nodes/Node/NodeConnector/FlowCapableNodeConnector的数据监听类TerminationPointChangeListenerImpl,当Nodes/Node/NodeConnector/FlowCapableNodeConnector数据发生变化时,会触发onDataChanged函数调用

类似的,上述3个函数也是内部判断是否是数据新加/更新/删除事件,假如是新加事件,则调用createData函数将TerminationPoint写入network-topology数据树。

四、总结

ODL的前端显示需要后台数据支撑,当前版本的ODL对于前端需要显示的拓扑信息是由network-topology数据节点提供的,在network-topology数据节点下存在两类数据,一种是Link,一种是node,此时的node包括主机host和switch节点,host节点id是以host:开头,而switch节点的id是以openflow:开头,这个跟inventory数据节点的node是不一样的。

另外当switch设备(node)down掉之后,NodeChangeListenerImpl的processRemovedNode函数会将该node节点移除,同时与之相关的link(比如之前已在该node下发现host主机),并且会引起hosttracker当中的HostTrackerImpl删除该switch下的host主机,这样在拓扑上就不会有孤立的主机节点,但是该hosttracker还存在bug(已提交到odlbug系统,https://bugs.opendaylight.org/show_bug.cgi?id=7254,但迟迟没有人来解决,也没有回复,在此也求助大神们,谁能帮忙看下这个问题?或者怎么联系ODL组织?),使用mininet测试,一旦模拟的host数量过多(200多个)时,down掉switch,会有1-2个host节点残余在拓扑上,通过代码和log查看,并不是调用删除处有问题,好像是调用的odl基础框架有问题,还在进一步跟踪当中。

作者简介:鸿哥,硕士研究生,国内某通信设备公司软件研发工程师,主要从事云计算、SDN技术开发


  • 本站原创文章仅代表作者观点,不代表SDNLAB立场。所有原创内容版权均属SDNLAB,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用,转载须注明来自 SDNLAB并附上本文链接。 本站中所有编译类文章仅用于学习和交流目的,编译工作遵照 CC 协议,如果有侵犯到您权益的地方,请及时联系我们。
  • 本文链接https://www.sdnlab.com/18534.html
分享到:
相关文章
条评论

登录后才可以评论

wellbeing 发表于17-02-07
1