ONOS系统架构之高可用实现方案的演进

上篇文章《ONOS高可用性和可扩展性实现初探》讲到了ONOS系统架构在高可用、可扩展方面技术概况,提到了系统在分布式集群中如何保证数据的一致性。在数据最终一致性方面,ONOS采用了Gossip协议,这一部分的变化不大,而在强一致性方案的选择方面则在不断进行调整,其主要原因是分布式系统中强一致性对系统性能影响较大,而且现有的支持Paxos算法的实现不多。本文承接上一篇提出的一个问题:ONOS为什么从开始使用ZooKeeper转到Hazelcast,而最终选择了Raft?是不是之前的选择导致系统缺陷?亦或是在某些条件下无法满足性能需求?且看下文为你慢慢道来。

在开始之前,先简单的介绍一下ZooKeeper、Hazelcast和Raft,提供一些资料方便大家阅读。

ZooKeeper,Hadoop生态系统中知名的分布式协作系统, 是Google的Chubby一个开源的实现,以C/S方式提供服务,应用场景包括配置维护、名字服务、分布式同步、组服务等 。客户端 与服务器(Follower/Leader)以Watch/Callback的方式进行交互,如图1所示流程,可参考相关实例代码。

Hazelcast是一种内存数据网格(IMDG: In-Memory Data Grid),网格中所有的节点是以Peer-to-Peer的方式组建集群,并且所有数据置于内存中以提高访问性能[ Hadelcast架构介绍文档]。Hazelcast提供了通用的数据结构(如Map, List, Queue等)和简单的API进行数据操作,可以直接引入jar包进行实现,可以参考下文提供的相关实例代码。

Raft是为了解决Paxos算法的可读性以及实现中抛弃一些细节形成的等价于Multi-Paxos算法。它依赖于复制状态机(Replicated State Machine),通过Replicated Log将操作指令复制到各个节点,然后各节点在本地按相同的顺序执行相同的命令,产生一致的状态,图2展示的是Raft状态机。

根据上面的介绍,我们对这些方案有了初步的了解。现在假设我们是该系统的设计者,面临对这三个方案技术方案进行选型,我们首先需要对这些方案进行对比,具体如表1所示:

从解决问题的角度来说,这三个方案都可以解决ONOS在分布式一致性协作方面的问题,因为算法证明了这些方案都是“正确”的,除非实现上有Bug。就算法的性能来说,差异不是很大。Paxos算法(一种基于消息传递模型的一致性算法),它能保证在一个分布式数据库系统中,如果各节点的初始状态一致,每个节点都执行相同的操作序列,那么他们最后能得到一个一致的状态。而Raft算法是等价于Multi-Paxos的算法,它主要解决的是Paxos晦涩的描述,以及Paxos的实现不能真正意义上的完全正确(实现上无法用公式证明)。这两个算法虽然在实现上差别很大,比如一致性实现中角色的定义,比如ZooKeeper中定义了Leader/Follower,Raft定义了Candidate/Leader/Follower角色,但其最核心的两个关键活动,一个是选举,其目的就是从分布的节点中选出Leader节点作为一致性的参考标杆,其它的Follower就成为“镜像”。选举只有在初始化或有Leader退出/失效时才发生,在分布式系统中,节点失效出现的频次很低,而且选举动作都是可以在秒级别能完成的,对系统的性能影响不大,不明显,实际情况中与系统节点数的奇/偶性更相关,比如4个节点或6个节点选举时间可能比13个节点选举时间更长。另外一个是同步,其目的是通过复制数据/操作来达到所有的Follower都能产生一致的结果,只要状态有更新(比如写操作),那么就会触发同步动作,同步意味着数据的复制以及消息的传递,从分布式架构来说,在读写IO方面这三种实现方式都相差不多。从这个角度来说,算法不是决定因素。

大家可能会问:既然算法都差不多了,就没有必要在ONOS实现上大动手脚了。其实,从上表我们可以知道,当初选择ZooKeeper作为Prototype 1的首选,主要是因为ZooKeeper成熟稳定,它在Hadoop生态圈是鼎鼎有名的高性能、分布式的应用协调服务的首选。从ONOS的Prototype 1的实现来看,ZooKeeper确实满足了分布式集中控制的需求,另外一方面,在其实验过程中,验证系统的性能时,很多数据是全局静态的,比如Flow Rule在实际的应用中是通过控制器以Lazy的方式下发到交换设备中,那么这些数据可以提前在ZooKeeper中准备好,只要实验中不进行交换设备的动态增加或者移除,不会影响到整体性能。也就是说,在Prototype 1中主要关注SDN的概念在ONOS上能发挥到何种程度,而不关心交换设备动态增加、删除等场景。

也就是说当有数据大量更新时,ZooKeeper则会出现性能问题,这主要因为ZooKeeper是以服务的形式来保障数据的一致性的。相对于ONOS来说,ZooKeeper是它的一个依赖子系统,因此在部署ONOS之外还要单独部署ZooKeeper服务,如图3所示的Client与Server之间的读写模型。由于ZooKeeper中所有的数据都以ZNode表示,这些ZNode存储在ZooKeeper的Server上,Client要读的数据需要跨JVM访问Server。这样ONOS Instance就变成了zClient,那么当ONOS不同实例间需要同步数据时,需要通过TCP的方式从zServer上请求数据,这就导致了ONOS的性能会急剧下降,另外,ZooKeeper的zNode对数据大小有限制(zNode数据大小不能超过1M)。所以说ZooKeeper以服务的模式提供分布式一致性,对于ONOS有太多限制,而这时Hazelcast解决了这些问题。

Hazelcast是peer-to-peer的模式,直接应用其library以embedded的方式来实现,也就是每个ONOS Instance可以作为一个peer,ONOS的业务数据就在同一个JVM中,如图4所示(Hazelcast也能提供C/S模式的服务)。更重要的是,Hazelcast是一个IMDG(In-Memory Data Grid),提供了很方便的接口进行数据操作,在性能上得到了很大的提升。但是,Hazelcast有个致命的问题,它还很不成熟,在版本升级中可能会不兼容。比如在ONOS1.1.0中依然有很多Hazelcast相关的Bug,这就意味着ONOS依赖于一个不成熟的库,风险会很大。实际上关键的因素是:Hazelcast是否能正确地实现Paxos算法还是一个未知数,包括ZooKeeper的实现也不能被证明在算法上正确的,因为Paxos实在是太复杂了,能正确理解算法的人不多,更别谈实现了。有人会觉得,不管怎样Hazelcast会不断改进的,如果有问题直接提交Bug给Hazelcast不就解决了?或者说咱们也是做开源的,帮Hazelcast改进为什么不行?原因是当ONOS有了Hazelcast的Bug后就成了ONOS的Bug,解决这样的Bug一方面是存在时间上的风险,另外一方面也取决于Hazelcast是否会因为支持ONOS而进行升级。万一版本升级,出现不兼容现象,那么已经部署的ONOS风险就更大了。把风险控制在自己能掌控的范围之中才是ONOS社区首先考虑的。在这种情况下,Raft就成了不二之选了。

Raft是Multi-Paxos的一种等价算法,其实现可以通过状态机(一种容错机制)、日志副本和一致性模块(Raft协议)之间的协同完成,这种简单的模型抽象容易实现客户端和数据在同一个JVM上,以实现Embedded的方案,具体架构如图5所示。由于目前在ONOS代码中还没有与Raft相关的实现,但我们可以从ONOS项目的Sprint可以看出,在ONOS中首先需要解决的是替换掉Hazelcast,并且保留可扩展的强一致性的存储。另外,在维护设备的主从关系上,也需要Raft来实现,因为选举服务是Raft必备的功能。上篇文章也提到过Intent需要强一致性来保障,Intent数据是通过分布式队列发送,因此也需要支持基于Raft的数据库服务。

到目前为止,我们了解到了ONOS系统架构中的高可用方案演进的整个过程。在系统POC初期,ONOS关注的是SDN概念上的验证,选择了ZooKeeper满足了基本的需求;接下来发现在HA方面存在性能问题,为了保证与ZooKeeper有同样功能,而且性能优先的原则,选择了Hazelcast,而且它确实做到了。而Hazelcast的问题在于它是一个没有被广泛验证过、不成熟的、还在不断改进的方案,ONOS不能依赖于这样的一个方案,因此最终选择了Raft。虽然要在ONOS中全面实现Raft还需要时日,但在这个时候选择Raft是正确的、合理的。

ONOS已经将Raft的实现提上日程,请参考官方的任务列表,我们共同期待ONOS中的Raft实现吧!个人认为,ONOS在项目管理上做得非常优秀,这也是ONOS脱颖而出的原因。 如果您有兴趣,也加入到ONOS的开源社区吧,关注ONOS的成长,一起推动SDN的发展!

参考资料

ZooKeeper官方网站:http://zookeeper.apache.org/

ZooKeeper相关介绍:http://www.oschina.net/p/zookeeper

ZooKeeper的客户端Kazoo:http://openinx.github.io/2014/06/07/learning-from-kazoo/

ZooKeeper分布式锁实例代码:http://ifeve.com/zookeeper-lock/

Hazelcast官方网站:http://hazelcast.org/

Hadelcast架构介绍文档:http://docs.hazelcast.org/docs/latest/manual/html/overview.html

时间: 2024-08-10 17:35:18

ONOS系统架构之高可用实现方案的演进的相关文章

jeesz分布式架构-分布式高可用

版权声明:本文为博主原创文章,未经博主允许不得转载. 什么是高可用 高可用HA(High Availability)是分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计减少系统不能提供服务的时间. 假设系统一直能够提供服务,我们说系统的可用性是100%. 如果系统每运行100个时间单位,会有1个时间单位无法提供服务,我们说系统的可用性是99%. 很多公司的高可用目标是4个9,也就是99.99%,这就意味着,系统的年停机时间为8.76个小时. 如何保障系统的高可用 我们都知道,单点是系统

分布式集群系统下的高可用session解决方案

目前,为了使web能适应大规模的访问,需要实现应用的集群部署. 而实现集群部署首先要解决session的统一,即需要实现session的共享机制. 目前,在集群系统下实现session统一的有如下几种方案: (1) 应用服务器间的session复制共享(如tomcat session共享) (2) 基于cache DB缓存的session共享 应用服务器间的session复制共享 session复制共享,主要是指集群环境下,多台应用服务器之间同步session,使session保持一致,对外透明

MMM高可用mysql方案

MMM高可用mysql方案是一个通过Perl编写的.基于MySQL主从复制的.成熟完善的MySQL高可用集群解决方案,有一个管理端(monitor)和多个代理端(agent)构成.通过MMM可以实现监控和管理MySQL主主复制和服务状态,同时也可以监控多个slave节点的复制以及运行状态,并且可以做到任意节点发生故障时实现自动切换的功能.在整个集群中,同一时刻只有一个master是可写的.MMM套件主要的功能是通过三个脚本来实现的:1.mmm_mond这是一个监控进程,运行在管理节点上,主要负责

开源jms服务ActiveMQ的负载均衡+高可用部署方案探索

一个文件(或目录)拥有若干个属性,包括(r/w/x)等基本属性,以及是否为目录(d)与文件(-)或连接文件(l)等属性.此外,Linux还可以设置其他系统安全属性,使用chattr来设置,以lsattr来查看,最重要的是可以设置其不可修改的特性,即便是文件的拥有者都不能进行修改.这个属性相当重要,尤其是在安全机制方面(security). 文件默认权限:umask 当建立一个新的文件或目录时,它的默认属性是与umask有关的.通常,umask就是指定当前用户在建立文件或目录时的属性默认值.那么,

Centos7.2 下DNS+NamedManager高可用部署方案完整记录

Centos7.2 下DNS+NamedManager高可用部署方案完整记录 之前说到了NamedManager单机版的配置,下面说下DNS+NamedManager双机高可用的配置方案: 1)机器环境 主机名            ip地址 dns01.kevin.cn   172.22.51.65 dns02.kevin.cn   172.22.51.74 VIP地址:172.22.51.75 两台机器做好主机名及hosts绑定 [[email protected] ~]# vim /etc

高可用开源方案Heartbeat vs Keepalived

转:http://www.kuqin.com/shuoit/20140623/340745.html 最近因为项目需要,简单的试用了两款高可用开源方案:Keepalived和Heartbeat.两者都很流行,但差异还是很大的,现将试用过程中的感受以及相关知识点简单总结一下,供大家选择方案的时候参考. 1)Keepalived使用更简单:从安装.配置.使用.维护等角度上对比,Keepalived都比Heartbeat要简单得多,尤其是Heartbeat2.1.4后拆分成3个子项目,安装.配置.使用

Apache shiro集群实现 (六)分布式集群系统下的高可用session解决方案---Session共享

Apache shiro集群实现 (一) shiro入门介绍 Apache shiro集群实现 (二) shiro 的INI配置 Apache shiro集群实现 (三)shiro身份认证(Shiro Authentication) Apache shiro集群实现 (四)shiro授权(Authentication)--访问控制 Apache shiro集群实现 (五)分布式集群系统下的高可用session解决方案 Apache shiro集群实现 (六)分布式集群系统下的高可用session

eql高可用部署方案

运行环境 服务器两台(后面的所有配置案例都是以10.96.0.64和10.96.0.66为例) 操作系统CentOS release 6.2 必须要有共同的局域网网段 两台服务器都要安装keepalived(双机热备)和eql服务 软件部署 keepalived 部分 keepalived是一个用于做双机热备(HA)的软件,常和haproxy联合起来做热备+负载均衡,达到高可用. keepalived通过选举(看服务器设置的权重)挑选出一台热备服务器做MASTER机器,MASTER机器会被分配到

高可用开源方案 Keepalived VS Heartbeat对比

最近因为项目需要,简单的试用了两款高可用开源方案:Keepalived和Heartbeat.两者都很流行,但差异还是很大的,现将试用过程中的感受以及相关知识点简单总结一下,供大家选择方案的时候参考. 1)Keepalived使用更简单:从安装.配置.使用.维护等角度上对比,Keepalived都比Heartbeat要简单得多,尤其是Heartbeat2.1.4后拆分成3个子项目,安装.配置.使用都比较复杂,尤其是出问题的时候,都不知道具体是哪个子系统出问题了:而Keepalived只有1个安装文