Gravity 海量闲置算力的调度设计与实现

自从有了计算机以来，算力的角逐就已经开始，从1942 年 Atanasoff-Berry Computer（ABC）第一台超级计算机出现，几十年来计算在规模、性能以及计算的通用性等各个方面都有了突飞猛进的发展。从企业内部的单机系统，私有云、公有云，算力从各个分散的点逐渐整合为规格更为统一的数据中心，同时分布式计算也逐步发展为解决如何处理互联网产生的大量数据的重要途径。

公有云等云计算基础设施和服务出现以后，对于有计算和存储需求的用户来说，越来越不关心底层网络，服务器等硬件基础设施，只需要根据使用云计算服务，按使用量或者是使用时长付费，不断降低用户的使用门槛，同时集中统一化的云服务为用户提供了更加稳定的环境。在上云趋势之下，越来越多的私有云和中小企业用户逐渐把服务迁移到公有云，公有云成为企业级 OS 的趋势。通过云上的各种服务，对于初创公司相比自建私有云，产品研发周期大大缩短，可能直接影响着用户商业化周期。

从数据中心出现开始，私有云到公有云，数据和计算逐渐越来越往中心靠拢，云服务逐渐从以人为中心设计的云（例如：web service ）发展到下一个时代，设计以机器为中心云（如：边缘计算、IOT PAAS），以支持更大规模计算和调度。和公有云互补的是边缘计算，边缘计算在网关层面做简单处理之后，大部分数据还是会回归中心的公有云，是中心云的扩展，思想为把中心云服务部分计算推到边缘，网关节点一般为更靠近某个区域的数据中心服务器。

在大量智能设备出现和大量空闲算力的今天，Gravity 把空闲算力整合成标准化的计算单元VCU，通过 P2P 的 NFV 网络，把异构的算力组成虚拟数据中心，通过一个去中心化的调度网络在异构的节点（包括：手机、智能设备、矿机、PC、路由器等）组成一个更为分散和具有资源和作业调度能力的边缘云基础设施，把边缘设备组成一个具有大数据计算和存储能力的分布式计算网络，把数据中心的计算拓展到边缘云，也是现有云计算的强有力互补。

在整合闲置算力提供大数据计算的过程中，我们面临着几大挑战

1. 计算节点平台，OS和计算能力异构
2. 节点分散在距离用户较近的位置，没有数据中心级别的网络环境
3. 未来的节点规模大，百万级
4. 动态化的节点拓扑（相对数据中心节点拓扑来说）

在业界也出现了很多 benchmark 来测评相关指标。比如 Sort Benchmark 中的 TeraByte Sort，主要面向大数据领域，曾经是巨头们争相追逐的指标。这种评测是典型考验调度能力的方法，优异的调度能力会在指定数据和算法任务中胜出。我们从现在主流的计算和资源调度进行一个对比，来说明我们是怎么解决以上问题的。

常见的调度模型分为：

                                                                            来源：Omega

Monolithic 统一调度架构

单一的调度器通过集群状态信息，负责统一的资源和任务的调度，许多调度系统最初被设计为这种模式，这种架构一致性强，扩展性较差，在集群规模增大时，可用性和处理能力可能会随之下降。

Two-Level 两级调度

通过资源动态划分，使用中央协调器来确定每个子集群可以分配的资源，每个子调度器不具备全局资源视图，可能造成资源使用量不均衡等问题。代表性的两级调度有 Mesos 和 Yarn (有争议）

Shared State 共享状态调度

调度系统同时存在多个调度器，调度器共享全局资源视图，通过乐观锁机制，调度冲突概率大，比如 Borg 和 Omega.

 

主流开源调度器的横向对比

Yarn

Yarn 是 Hadoop 里的调度系统，主要面向大数据计算。由 Resource Manager、NodeManager、Container 和 Application Master 组成，是一个典型的多级调度。来源于早期的原生 MapReduce 任务的调度，目前可以支持 Spark、Flink 等运行在 Hadoop 集群。

Yarn 的 NodeManager 复杂宿主机管理，其中的 Container 主要是进程级的管理，运行MapReduce 任务时会启动 TaskManager 和 TaskExector 进程。

Yarn 启动任务时会由 Resource Manager 指定一个 Node 启动 Application Master,成为二级管理者，来负责子作业运行管理，比如 MapReduce 的 JobManager 或者 Spark 的 Master.

Yarn 默认使用公平调度策略，用队列形式管理任务，队列可以嵌套，也可以配置优先级。总体来说 Yarn 适合大数据场景，管理迭代计算比较有优势。

通过 federation 支持节点量级 10k~100k（理论值）

                                              图片来源：https://hadoop.apache.org/

Mesos

通过将机器、CPU、内存和存储等其他计算资源抽象出来，agent 向 master 汇报节点资源情况， Master 根据策略决定将 Resource Office 给不同的调度框架。

可以采用一主多备，通过 Zookeeper 来做分布式协调，节点通过 Slave 的方式加入到集群中，支持大约 10K 级别节点规模。

                                    图片来源：http://mesos.apache.org/

Kubenetes

通过 Minon 节点汇报节点资源状态到 Master, Controller Manager 负责管理 Cluster 的各种资源，Scheduler 通过 Cluster 的拓扑结构进行 Pod 调度，无状态 ApiServer 则 负责对外进行调用理论支持 5K 节点规模。

                                        图片来源：https://kubernetes.io/

上述的调度系统都是假设节点都在数据中心，网络和设备可用性很高，而且都是 G 以上网络互连且能 IP 直通的环境，节点拓扑相对静态，扩展性都是在 10K 规模的节点集群，不能满足我们边缘云计算的业务背景。

而 Gravity 需要解决节点平台和 OS 算力异构的问题（比如：PC、手机、矿机、智能盒子等），节点动态加入动态扩容和离开（共享设备随时可能加入和离开网络），由于边缘和闲散算力计算资源都相对较弱，需要满足海量设备的资源和作业调度。

以下是 Gravity 的实现方案及相关产品：

Gravity PMR(PMR)

PMR 是我们目前已经实现，并且提供公测的调度，面向 MapReduce 大数据处理任务，适合迭代的批量计算。由于 Gravity 是利用公网的共享设备组成计算网络，网络和设备稳定性以及异构情况都会很复杂，支持的单集群节点规模也会提升两个数量级。

 

Gravity MapReduce 的实现方案

• 节点比较分散，一般家用PC 或者手机网络都是在路由器 NAT 之后，没有对外固定的公网 IP，同时数据中心之外的闲置或边缘设备数量很大

我们通过节点间的 P2P 网络，对于在同一个局域网内的节点通过广播互相通信，对于不在同一个网络中的其他对等点通过 NAT 穿透，构建一个去中心化的计算网络，降低了通信成本，不需要使用固定的公网 IP，通过节点 id 唯一标示一个节点，节点网络统一，局部是自治网络，通过平衡策略，每一个点不会接收大量节点的连入，横向扩展能力强。

• 动态化的节点拓扑和自平衡网络

节点启动时，节点根据 VRF 和 Bully 选举算法，会有部分节点自动竞选成为作业调度节点，其他节点成为作业执行节点。

首先网络中所有 Node 都具备任务执行和调度能力，所有节点都是普通的 Node 角色，在启动过程中，自动转化为 Idle，在 Idle 状态下，根据 VRF 和 Bully 选举算法，在一个随机超时之后，手中持有大部分选票的节点胜出，进入 GP-Mid 状态。此阶段是一个中间状态，节点只具有参与第二轮选举的权利，其余节点回到 Node 状态，第二轮在 GP-Mid 选中节点中，通过 VRF 生成的选票，通过 Bully 选举，选出满足网络初始状态的所有 Ggroup，其余节点进入 Gant 状态。所有 Group 状态的节点，在当选之后，会受到随机选择的多个备选 Ggroup 检测，同步状态信息。当 Group 宕机，所有备选会重新选举，并接管状态。在新的节点加入过程中，如果没有找到相应的 Group 节点接受，则和其他没有被接受的节点进入选举状态，最终产生新的 Group 节点。

 

网络自平衡策略，红色为 Job 调度节点，蓝色为作业 Task 执行节点，当 Job 提交较多，用户等待时间较长时，所有 Job 调度器会通过协调者从 Task 执行节点中选举出新的 Job 调度节点。当 Job 减少 Task 较多的情况下，超过一定时间没有接收到 Job 的调度节点，会自动转换为Task 执行节点。

 

• 工作量验证机制和容错机制

 

其中红色节点为当前 Job 分发节点，蓝色节点为当前 Job 执行 task 节点，黄色节点为红色节点的检测者，黄色节点之间互相不知道彼此的作业信息，他们并行从红色节点获取作业的状态汇报，当检测到当前 Job 调度器宕机或者停止响应时，黄色节点之间通过选举模块，选出接管者和检测者。

蓝色节点彼此之间不知道互相的状态信息，如果检测者或者 Job 调度器发现其中部分节点作业心跳异常或者执行速度慢于其他蓝色节点很多，则会推迟执行，选择一个蓝色节点并执行此 Task ,最后谁最快返回谁获得计算证明。

• 解决设备和节点计算能力异构的问题

我们通过一个标准化的 benchmark 测试，评估不同设备的算力级别，根据我们逻辑划分的最小计算单元 VCU，来预估一个设备所能并发接收的 Task 数量和每个 Task 所能执行的数据量。用户可以通过参数修改并发量，但是在常规情况下不建议用户修改，修改可能导致节点负载过大等，在 task 执行过程中相比其他节点慢，导致推测执行，拿不到响应的计算激励。

关键点

在我们整个网络中，所有节点都为全功能节点，在通过相应的任务负载的情况下，网络中的调度器数量和计算节点是动态调整的（适者生存），没有一个全局中心节点，可以水平扩展。

网络中所有调度器通过 DHT 方式寻址，每个调度器负责一定数量的计算节点，并且能达到跨调度器的资源请求。同时所有调度节点都受多个备用调度节点监测（局部共识）。

任务计算节点如果存在异常，比如并发设置不合理等，会通过推测执行，选择其他节点同时计算，先完成的将取代慢的（弱肉强食）。

要解决边缘云计算的问题，利用闲置算力组成计算网络，现有的数据中心级别的作业和资源调度是很难解决大规模，动态节点拓扑，网络节点异构的问题，以上就是我们的一些思考和实践。基于 Gravity 作业调度之上，已经支持了 MapReduce 作业调度，跨手机、PC、盒子等异构分散设备的计算网络，欢迎大家关注公众号参与测试。