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

本文主要是介绍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是正确的、合理的。