ONOS集群选举分析

首先简单介绍下自己,之前是做 floodlight 控制器开发的,鉴于 ODL 和 onos 的如火如荼的发展,如果不对了解点就感觉自己 OUT 了,因此忙里偷闲,看了点 onos的源码收获颇丰,不敢私藏,也算是抛砖引玉。

对于 onos,我认真读的也就是集群这块,也大概浏览了下其他模块的源码。onos中有些精巧的代码完全可以用于其他项目,比如,最短路径算法, floodligth的实现嵌入到了具体模块,而且不支持多路径, 而 onos提供了三种最短路径算法,而且原生支持多路径,而且模块化做的非常好。我也参考 onos 的部分设计,并且应用于公司项目中。此外,Java 8 的表达力比 Java 7 的表达力的提升在 onos 中体现的淋漓尽致,比如在有些功能相近的模块,floodlight 的实现比 onos 要冗余很多。

总之,onos 整体代码质量要远高于 floodligth。

打算写成一个系列。大体列下提纲:

  1. 集群选举
  2. onos 中 Raft 协议实现概论
  3. onos 中 gossip 协议的实现
  4. 集群基本原语支持,onos 支持分布式的 ConcurrentHashMap,AtomicCount,Set 等等
  5. 可以用于其他项目的设计,代码。

本篇主要分析 onos 集群选举的代码路径。

集群协议概述

集群选举, onos 用的 Raft 协议。至于为什么不用 poxos, 我不清楚, 但现在越来越多出现一个趋势,就是大家偏向于用 Raft 代替 Poxos。 原因就是 Raft比较简单。

这里说趋势, 是基于目前 Raft 算法实现和 poxos 协议实现的数量。另外, 我也发现 Harvard,Standford 和 CMU 已经在他们的分布式课程中将原来的 Paxos 替换为 Raft,原因可用参见这里, 而且 Raft 还有官网, 里面包含丰富的资源,而 Paxos 只有论文。所以, 总体趋势上看 Raft 已经渐渐变为主流。

基于 paxos 的实现,我们目前知道的就是 zookeeper, ceph 都实现了 paxos,而 zookeeper 实际并不是精确的 paxos 实现,而是经过修改的 ZAB 协议。最近,腾讯开源了他们的 paxos 实现 phxpaxos,因此,大量的分布式项目依赖 zookeeper 不足为奇。

而 Raft 协议,我大体了解 Raft 的官方网站 Raft 协议的实现情况, 发现基于 java 完整实现的只有copycat, jraft, jgroups-raft, RaftKVDatabase/JSimpleDB, C5 replicator。(其中 C++ 和 Go 的也都有 5 个)

  • Jraft : 缺少文档,
  • jsimpledb : 并不是只实现 Raft
  • C5 replicator : 实现了 Raft 协议
  • jgropu-raft : 实现了 Raft 协议

需要说明的是这些项目的 star 都很低,应该没有成熟到可以应用到生产中。相较于其他实现, copycat 还通过Jepsen 来测试 Raft 协议,而其他项目没有。 由此可见, 实现一个完整的可用的 Raft 目前来说还是非常有挑战的。

onos 选择 copycat 作为其 Raft 协议的实现, 从上面分析来说, copycat 的选择是没有问题的。

ONOS 集群选举

注: 本文基于 onos 1.6 分支来进行分析。

ONOS 对集群的选举暴露出了一组接口,如下所示。

即 run, withdraw, anoint, promote, evict, 关于它们的用法, 文档解释得非常清楚,这里就直接搬运过来。

创建一个选举器的流程

在 NewDistributedLeadershipStore.java 文件中有这样一段代码

这里创建了一个 leaderElector, 后面代码都是对该段代码的注解。StorageManager 实现了 StorageService 接口。

StorageManager.leaderElectorBuilder() 调用了 new DefaultLeaderElectorBuilder(federatedPrimitiveCreator)

此外,DefaultLeaderElectorBuilder 继承了 LeaderElectorBuilder:

leaderElectorBuilder.withName(“onos-leadership-elections”).build() 返回 AsyncLeaderElector 类型对象 asyncLeaderElector

AsyncLeaderElector 的 asLeaderElector() 调用了它的 asLeaderElector(long timeoutMillis) 方法,asyncLeaderElector.asLeaderElector(Long.MAX_VALUE) //任务超时时间为 Long.MAX_VALUE。AsyncLeaderElector 的 asLeaderElector(Long.MAX_VALUE) 方法调用了 DefaultLeaderElector 构造函数 DefaultLeaderElector(AsyncLeaderElector asyncElector, long operationTimeoutMillis)。

new DefaultLeaderElector(this, timeoutMillis),其中 this 为 AsyncLeaderElector 的实例化对象 asyncLeaderElector。

注: DefaultLeaderElector 将 LeaderElector 的所有方法通过 CompletableFuture 变为异步操作。

其中 DefaultLeaderElector 实现了 LeaderElector,而 DefaultLeaderElector 实现所有 LeaderElector 的方法依赖构造函数 AsyncLeaderElector, 因此, 问题回到了 leaderElectorBuilder.withName(“onos-leadership-elections”).build()
实际实例化的对象。即 new DefaultLeaderElectorBuilder(federatedPrimitiveCreator).withName(“onos-leadership-elections”).build() 到底做了什么, 其中

因此, 决定于 new FederatedDistributedPrimitiveCreator(partitionMap).newAsyncLeaderElector(“onos-leadership-elections”)

其中 PartitionedAsyncLeaderElector 实现如下

因此, 一个 LeaderElector 实际调用的是实现了 AsyncLeaderElector 接口的 PartitionedAsyncLeaderElector,至此, 一个选举器实现貌似已经完成了。 当你准备研究 onos 是如何实现选举过程时,看看 withdraw, anoint, promote 的实现, 你心中一定是”万马奔腾”的。

那么, 下面我们就继续看看选举过程的具体方法是如何实现的, 实现细节藏在哪里。对于 AsyncLeaderElector 定义的所有接口, 都通过 getLeaderElector(String topic) 来实现。

那 partitions 到底包含什么? 由上面 StorageManager 分析知道, partitions 的实参是 partitionMap。而 partitionMap 又由 PartitionService partitionService 来提供, PartitionManager 实现了接口 PartitionService。

这样说来, partitions.get(topicHasher.hash(topic)),实际对象为 toragePartition 了。

参考 StorageManager activate() 方法可知, partitionMap 的 value 为 StoragePartition 的 client()方法返回值,由上 StoragePartition 的 client() 和 openClient 可知 client() 返回的实际是StoragePartitionClient, 那 StoragePartitionClient 又是什么?

至此, 终于明白 partitionMap 的 value 为 StoragePartitionClient。

由 FederatedDistributedPrimitiveCreator 的 newAsyncLeaderElector 得知, LeaderElectors 为partitionMap 的 value 的 newAsyncLeaderElector(name) 返回值, 即 StoragePartitionClient的 newAsyncLeaderElector(name) 方法。

由 newAsyncLeaderElector() 及 open() 可知, client.getResource(name, AtomixLeaderElector.class).join() 最终 AsyncLeaderElector 的实例化是 AtomixLeaderElector。

因此, client.getResource(name, AtomixLeaderElector.class).join() 实际为 ResourceClient(copycatClient).getResource(name, AtomixLeaderElector.class, new Resource.Config(), new Resource.Options()).join()。

这里不再过多解释, 总之, 最后为

终于 withdraw, anoint, promote 的实现浮出水面, 即 AtomixLeaderElectorCommands 来实现,而实现 io.atomix.copycat.Command, 到此远远没有完, 因为 Command 仅仅是个接口。

至此,我们基本可以确定, onos 并没有实现 Raft 协议,而是通过第三方库 atomix 下的 copycat 实现了 Raft协议。关于具体实现,下篇见分晓。

作者简介:

文刀旋子, 目前工作主要是 floodligth 控制器开发, 主要关注 sdn 控制器, 内核网络协议栈, 分布式系统设计与实现,高性能服务器如 nginx, redis, haproxy 的设计与实现.


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

登录后才可以评论

文刀旋子 发表于16-08-19
4