ONOS系统架构演进,实现高可用性解决方案
上一篇文章《ONOS高可用性和可扩展性实现初探》讲到了ONOS系统架构在高可用、可扩展方面技术概况,提到了系统在分布式集群中怎样保证数据的一致性。在数据终于一致性方面,ONOS採用了Gossip协议。这一部分的变化不大,而在强一致性方案的选择方面则在不断进行调整,其主要原因是分布式系统中强一致性对系统性能影响较大,并且现有的支持Paxos算法的实现不多。
本文承接上一篇提出的一个问题:ONOS为什么从開始使用ZooKeeper转到Hazelcast,而终于选择了Raft?是不是之前的选择导致系统缺陷?亦或是在某些条件下无法满足性能需求?且看下文为你慢慢道来。
在開始之前,先简单的介绍一下ZooKeeper、Hazelcast和Raft,提供一些资料方便大家阅读。
ZooKeeper,Hadoop生态系统中知名的分布式协作系统,是Google的Chubby一个开源的实现,以C/S方式提供服务。应用场景包含配置维护、名字服务、分布式同步、组服务等 。client 与server(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协议)之间的协同完毕,这样的简单的模型抽象easy实现client和数据在同一个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的clientKazoo: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
版权声明:本文博客原创文章,博客,未经同意,不得转载。
转载于:https://www.cnblogs.com/hrhguanli/p/4755829.html
ONOS系统架构演进,实现高可用性解决方案相关推荐
- 美团配送系统架构演进实践
写在前面 美团配送自成立以来,业务经历了多次跨越式的发展.业务的飞速增长,对系统的整体架构和基础设施提出了越来越高的要求,同时也不断驱动着技术团队深刻理解业务.准确定位领域模型.高效支撑系统扩展.如何 ...
- 腾讯海外计费系统架构演进
作者简介:abllen,2008年加入腾讯,一直专注于腾讯计费平台建设,主导参与了腾讯充值中心.计费开放平台.统一计费米大师等项目,见证了米大师从0到1,业务营收从PC到移动多终端再到全球化的跨越过程 ...
- 京东到家搜索系统架构演进
目录 一. 前言 二. 搜索系统架构演进 2.1 到家搜索系统1.0 基于LBS搜索召回场景 建立"可用"的搜索系统 小结 2.2 到家搜索系统2.0 重构召回 排序模型小试牛刀 ...
- 直播系统聊天技术(四):百度直播的海量用户实时消息系统架构演进实践
本文原题"百度直播消息服务架构实践",由百度APP消息中台团队原创分享于"百度Geek说"公众号,为了让文章内容更通俗易懂,本次已做排版优化和内容重新划分,原文 ...
- 【美团 · 北京沙龙报名】运营效率系统架构演进之道
[美团技术沙龙]由美团技术团队和美团科协主办,每期沙龙邀请美团及其他互联网公司的技术专家分享来自一线的实践经验,覆盖各主要技术领域. 活动时间:2018年12月8日 14:00-17:30 活动地址: ...
- 百度直播的海量用户实时消息系统架构演进实践
1.引言 一套完整的直播系统核心功能有两个: 1)实时音视频的推拉流: 2)直播间消息流的收发(包括聊天消息.弹幕.指令等). 本文主要分享的是百度直播的消息系统的架构设计实践和演进过程. 实际上:直 ...
- 亿级流量系统架构演进之路
海量用户同时进行高频访问对任何平台都是难题,也是行业乐此不疲的研究方向.但值得庆幸的是,虽然业务场景不同,设计和优化的思想却是万变不离宗.本文将结合业务与高并发系统设计的核心技术点,对系统架构调优方案 ...
- SpringCloud(一)系统架构演进
概述:随着互联网的发展,网站应用的规模不断扩大,常规的垂直应用架构已无法应对,分布式服务架构以及流动计算架构势在必行,亟需一个治理系统确保架构有条不紊的演进.如下为整理的一个系统架构演进思维导图.主要 ...
- 去哪儿网支付系统架构演进
作者简介:吕博,去哪儿网金融事业部研发工程师,毕业于吉林大学,2012年加入去哪儿网. 致力于支付平台研发和支付环节的基础服务建设. 正文 去哪儿支付系统自 2011 年搭建以来,在五年的时间里逐渐从 ...
最新文章
- iOS - UIAlertController
- 会议室管理前端页面_福州会议室钟联系方式
- Linux下运行C语言程序
- [JavaME]解决来电问题(Incoming Call)
- 第三章 PLSQL Developer 安装前oracleclient客户端的配置,在用plsql 连接oracle服务器
- javascript BOM对象详解
- 【工具】公网临时大文件传输工具
- Docker file 搭建 Nginx镜像
- CodeIgniter2.0中sqlserver驱动返回受影响行数问题解决
- 建立ssh无密码登录环境
- mac升级php后旧版本还在,Mac下更新自带的PHP版本
- 第八章应用安全工程备考要点及真题分布
- APP签名MD5获取
- 【Kafka】使用confluent本地安装和使用kafka
- mysql查询临时表是否存在_[转]SQL判断临时表是否存在
- python之show、hide、slidedonw、slideup方法实例
- 如何修复“您的系统已耗尽应用程序内存”错误
- BI项目经理入门指南:用最详细的图解,带你落地企业自助分析项目
- Hadoop生态圈之即席查询工具Presto
- Netcfg.service failing.
热门文章
- 大数据数据量估算_如何估算数据科学项目的数据收集成本
- mongdb 群集_通过对比群集分配进行视觉特征的无监督学习
- 发布HTML 7-3
- 红外传感器型号和参数_红外传感器参数|热释电红外传感器参数
- C语言中字符型和浮点型能否相加,C语言中数据结构的基本类型(整型、浮点型和字符型)...
- java wordcount程序_[java]wordcount程序
- linux安装nginx1.9,CentOS7.2安装Nginx 1.9
- umi权限路由_Umi 小白纪实(三)—— 震惊!路由竟然如此强大!
- mysql数据库整体备份和恢复_MySQL 数据库的备份和恢复
- git clone时出现 error:inflate:data stream error(incorrect data check)