ONOS集群管理架构分析

前言:
众所周知,ONOS是一款面向运营商的开源SDN网络操作系统,主要面向服务提供商和企业骨干网等重要的生产环境。为了满足对可靠性、灵活度的需求,ONOS采取了分布式而非集中式的控制。本文就对ONOS的集群管理机制等内容进行介绍。


集群协调:

通常,一套ONOS集群会包含多个ONOS实例(或节点),每个节点拥有一个唯一的NodeID,每一个节点都可以感知网络的一部分状态,本地的状态分段由节点管理,在集群中以事件传播。事件被Store生成,它们通过分布式储存与集群中的所有节点共享。

除了分发数据,ONOS集群还要负责以下的任务:
1.检测和处理集群节点的加入和离开(由Cluster Subsystem管理)
2.为每一个设备提供一个主Controller

ONOS集群协调的一个重要工具便是Store,Store生成事件,事件被分布式储存持久化,在集群中共享。

根据具体服务的需求,储存的内容可以有不同的特征,如强一致性或最终一致性,这使得每个服务的储存根据需求采用合适的分布机制。

目前ONOS主控部分采用Hazelcast以达到强一致性,而Device、Link等部分的管理使用乐观的复制技术辅以gossip协议以确保最终一致性。

如果两个不同节点上的子系统是相同的,子系统将会直接通过Store与另一个进行同步。但是同步的只是一部分的状态,如,对于DeviceStore,它只知道设备的状态而不了解其他无关的信息。目前除了拓扑管理这部分,其他所有服务都要访问分布式储存。

下图展示了两个子系统间的同步:

事件排序:
ONOS使用一个类似向量时钟的手段以达到最终一致性。

Q:什么是向量时钟?
A:向量时钟是一种在分布式环境中为各种操作或事件产生偏序值的技术,它可以检测操作或事件的并行冲突,用来保持系统的一致性。

在ONOS中,被DeviceStore和LinkStore所使用的逻辑时钟(logical clock)实际上是一个设备自发现以来的主控权交接数组成。同时本地还有一个顺序数字,每观察到一个事件就递增一次。至于HostStore则依赖于系统时间,但由于Host对象的特性,阻止了他们被特定的设备所绑定。

集群管理:
Cluster subsystem要处理的任务有:

  • 1.保持对集群中的成员的跟踪
  • 2.为节点授权标识符(即NodeID)
  • 3.提供本地节点的概念,如“localhost”

目前ONOS主要依靠Hazelcast实现这部分的功能。

设备控制管理:
设备可以自由地连接到一个或多个集群中的节点,node可以有以下几种角色:

  • 1.NONE:这意味着node并不了解该设备,或仅仅是无法与其交互
  • 2.STANDBY:此时node已经有对设备的认识,并可以读取其状态,但无法管理、控制该设备
  • 3.MASTER:此时node认识设备并对其有完全的控制权

这三种角色对应OpenFlow中的NONE、SLAVE和MASTER角色。ONOS中的mastership subsystem负责保证在给出的任意时刻,每一个设备都只有一个MASTER,而其他的则为STANDBY或NONE状态。


节点控制周期:
一个node一开始可能是NONE角色。现在会有如下几种情况:
1.设备没有master绑定
2.有一个控制channel连接到设备上,并成为其master。若后面有其他node发现该设备,如果node与设备
间有连接,则成为STANDBY,否则为NONE。

如果面临下面几种情况,已经拥有的角色可能会被改变:
1.人为干预:管理员手动为设备设置角色
2.从设备断开:node与设备间的控制channel断开
3.从集群中断开:集群分裂为两个部分
MastershipManager通过角色的放弃(relinquishment)和再选(reelection )确保每个设备至多有一个master。并且确保如果一个node无法正确处理设备时不参加reelection。

角色放弃:
如果遇到以下状况,node会放弃其角色并回到NONE:
1.与设备断开,或设备失效
2.当集群分裂时,为较小的集群的成语
3.人为设定,强制修改其角色为NONE
4.一致性检查的失败,如OpenFlow设备对RoleRequest返回一个错误

重新选举:
如果遇到以下状况,会重新进入选举机制:
1.一个Master的失效(如放弃角色)
2.Master node与设备间断开连接
3.人为对master的降级,降到STANDBY或NONE

候选节点是从现有的standby节点中选择的,节点根据NodeID排序,这样是为了方便放弃角色的节点能直接选择下一个节点成为候选节点。候选节点可以选择成为master,或选下一个候选节点。同时ONOS提供了机制去阻止无限选举的问题。

处理集群分裂的问题:
如果集群分裂为两个不同尺寸的部分,位于较小的集群的nodes会放弃自己的角色(或者无法放弃角色)。而位于较大的集群的node会强制为其master位于小集群的设备执行改选。但目前ONOS无法处理两个相同尺寸的,并且依然连接到网络的集群。


思考:
ONOS在设备管理上的选举机制基本上和Raft算法类似,在Raft同样也存在三个角色,follower,leader,candidate。这样的选举机制理解起来非常容易(比PAXOS容易多了)。

通过node间不同状态间的转换,确保每一个设备都能有一个主控node,大大地提高了系统的可靠性。

至于ONOS中通过事件来同步状态,这种事件驱动的设计在某种程度上比起命令式的更有优势。如果节点间不是通过传播事件而是单纯靠RPC调用交互,在效率和稳定性上一定会打折扣。

对于分布式系统来说,Actor是一种可行的架构。ONOS目前的架构一定程度上有Actor模型的影子,关于Actor模型,可以参考这篇资料:
http://www.infoq.com/cn/articles/reactive-cloud-actors,这篇资料也介绍了响应式架构的优点。

而ONOS通过分布式储存保存事件,则是另一种能提高稳定性的手段。LMAX(一种新型零售金融交易平台)的架构就实现了这一点:

“使用基于内存的模型有一个重要问题:万一崩溃怎么办?电源掉电也是可能发生的,“事件”概念是问题解决的核心,业务逻辑处理器的状态是由输入事件驱动的,只要这些输入事件被持久化保存起来,你就总是能够在崩溃情况下,根据事件重演重新获得当前状态。很明显,ONOS通过持久化事件,可以获得更高的稳定性,实为明智的选择。

总结:本文介绍了ONOS集群管理的多个方面,并对其设计进行了思考。希望本文能让各位在了解ONOS的内部机制的同时,领略到其设计的巧妙之处。

作者简介:何智刚,2015至今,现为广东的一名在校高三学生,在学习之余,主要研究Docker,OpenStack,SDN,对各种领域都有所涉猎,目标是迈向full stack。

参考资料:
https://www.sdnlab.com/13862.html

https://wiki.onosproject.org/display/ONOS/Cluster+Coordination

http://www.infoq.com/cn/articles/reactive-cloud-actors

http://ifeve.com/lmax/


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

登录后才可以评论

Hochikong 发表于16-01-13
2