云环境下大规模分布式计算数据感知的调度系统.docx

云环境下大规模分布式计算数据感知的调度系统.docx

《云环境下大规模分布式计算数据感知的调度系统.docx》由会员分享，可在线阅读，更多相关《云环境下大规模分布式计算数据感知的调度系统.docx（22页珍藏版）》请在冰豆网上搜索。

云环境下大规模分布式计算数据感知的调度系统

摘要：

介绍了新的调度系统，包括资源调度、应用编排、配置标签中心、云网络和云存储服务等子系统。

系统通过数据拓扑感知能力保证了计算和数据的局部性，节约网络I/O开销；通过优化点对点大数据量读取的资源调度，解决网络风暴造成的影响；通过网络和磁盘隔离技术以及可抢占的方式来保证服务等级协议。

关键词：

 云计算 ; 调度系统 ; 大数据 ; AI平台 ; 数据局部性 ; 分布式计算 ; 抢占

1引言

随着云计算、大数据与人工智能（artificialintelligence，AI）技术的发展以及行业对这3种技术的综合应用需求，目前国内外出现了大数据、云计算、人工智能三者相互融合的技术发展趋势。

中国计算机学会大数据专家委员会在2019年大数据发展趋势调查报告中指出：

人工智能、大数据、云计算将高度融合为一体化系统。

2006年Hadoop项目的诞生标志着大数据技术时代的开始，而亚马逊云计算服务（Amazonwebservices，AWS）商用则标志着云计算正式迈出了改变信息时代的步伐。

自此之后，大数据和云计算成为最近十几年十分火热的技术，学术界和工业界都大力投入相关技术研发和落地应用中，并且创造了几个学术界和工业界协作的经典之作。

如2012年加州大学伯克利分校推出的新型计算引擎Spark技术迅速被工业界接受，并成为新一代的标准计算引擎。

在云计算领域，更多的是企业级应用推动了技术的发展，如2014年开始兴起的容器技术和编排系统，最终推进了新一代原生云平台的快速发展，Docker和Kubernetes技术则成为新一代原生云的标准。

基础软件的研发不是简单的功能堆积，必须经过详细的架构设计和功能验证。

大数据和AI计算都是典型的分布式计算模型，是基于有向无环图（directedacyclicgraph，DAG）或者大规模并行处理（massiveparallelprogramming，MPP）迭代的计算模式，意味着计算任务都是运行时才能生成的，因而难以进行预先调度，而分布式的特点又要求调度系统有更高的灵活性和自适应性。

目前工业界在努力尝试将大数据平台和AI技术部署在原生云上，以做到更大的弹性和可扩展性。

但是，目前全球范围内在这个领域取得的突破性成就还比较少。

本文将介绍核心创新：

云平台中的核心调度系统如何在原生云平台上管理和调度大数据和AI应用。

2云原生

云原生（cloudnative）是指在应用开发时，以云作为其生产部署方式，从而充分利用云的弹性、可扩展、自愈等核心优势。

区别于传统的臃肿的单体应用开发模式，云原生应用因为其有效的协同开发、测试和运维，极大地提高了软件开发效率和质量，支持产品快速地上线和迭代，已经成为当前主流的应用开发模式。

通常称能够有效支撑云原生应用的平台为原生云平台，其主要特点是容器化的封装、自动化的管理以及面向微服务的体系。

Docker直接使用LinuxCgroup等技术提供逻辑上的虚拟化，因其系统开销小、启动快、隔离性较好、方便应用封装等特点，Docker已经成为首选的应用容器技术。

此外Docker技术支持跨平台部署，能够实现“一次编译，多次部署”。

基于虚拟机的技术对高负载的应用可能有30%的性能损耗，而Docker技术没有硬件虚拟化，跟裸机相比几乎没有性能损耗，因此也可以用于部署类似大数据和AI应用的计算或者I/O资源密集型的应用。

一个大的云平台可能需要高效稳定地运行数万个容器，这就需要非常强大的服务编排系统。

为了满足日益增多的服务和任务的资源需求，Borg、Mesos、Omega等一系列的集群资源调度系统相继出现。

其中，Borg是集中式调度器的代表，其作为集群调度器的鼻祖，在Google公司有超过10年的生产经验，其上运行了GFS、BigTable、Gmail、MapReduce等各种类型的任务。

Mesos是双层调度器的代表，可以让多个框架公平地共享集群资源。

Omega则是共享状态调度器的代表，它的特点是支持使用不同的调度器调度不同类型的任务，解决资源请求冲突的问题。

Kubernetes是Google开源用来管理Docker集群的项目，继承了Borg的优点，实现了编排、部署、运行以及管理容器应用的目的，Kubernetes的总体架构如图1所示。

Kubernetes提供资源池化管理，可以将整个集群内的中央处理器（centerprocessingunit，CPU）、图形处理器（graphicprocessingunit，GPU）、内存、网络和硬盘等资源抽象为一个资源池，可以根据应用的资源需求、资源池中的实时资源情况进行灵活调度；Kubernetes包含一个统一的调度框架，最多可以管理数千个服务器和数万个容器，同时提供插件化的接口，让第三方来定制和扩展新的调度系统；此外Kubernetes支持通过ConfigMap等方式动态地调整应用配置，从而具备动态调配的基础能力。

本文基于这些基础技术开发了支持复杂应用平台的调度系统。

图1   Kubernetes的总体架构

3大数据和AI计算模型

分布式计算在复杂的工业应用需求下快速迭代和发展，从离线处理的MapReduce计算模型开始，逐渐发展出了以Spark为代表的在线计算（Spark、Tez、Druid等）以及实时计算模型（Flink、SparkStreaming等）。

新的分布式计算模型开拓了新的应用领域，同时也对大规模系统的管理、调度和运维提出了较大的挑战。

3.1MapReduce

MapReduce框架是Hadoop技术的核心，它的出现在计算模式历史上是一个重大事件，在此之前行业内主要通过MPP的方式增强系统的计算能力，一般是利用复杂而昂贵的硬件加速计算，如高性能计算机和数据库一体机等。

而MapReduce是通过分布式计算来提高计算速度的，并且只需要廉价的硬件就可以实现可扩展的、高并行的计算能力。

3.2Spark

随着大量的企业开始使用Hadoop构建企业应用，MapReduce性能慢的问题逐渐成为研究瓶颈，MapReduce只能用于离线数据处理，而不能用于对性能要求高的计算场景，如在线交互式分析、实时分析等。

在此背景下，Spark计算模型诞生了。

虽然本质上Spark仍然是一个MapReduce计算模式，但是几个核心的创新使得Spark的性能在迭代计算应用中比MapReduce快一个数量级以上：

第一，数据尽量通过内存进行交互，相比基于磁盘的交换，能够避免I/O带来的性能问题；第二，采用延时评估（lazyevaluation）的计算模型和基于DAG的执行模式，可以生成更好的执行计划。

此外，通过有效的检查点（checkpointing）机制可以实现良好的容错机制，避免内存失效带来的计算问题。

3.3TensorFlow

TensorFlow是Google公司开发的第二代人工智能学习系统，它可以将复杂的数据结构传输至人工智能神经网络中进行分析和处理，可用于语音识别、图像识别等多项机器学习和深度学习任务，并且完全开源，目前也是开源社区活跃的开发项目之一。

TensorFlow支持异构设备的分布式计算，可以在各个平台上自动运行模型，支持在手机、单个CPU/GPU、大型数据中心服务器等各种设备上运行。

4原生云与大数据、AI融合的技术难点和解决思路

4.1基于容器云开发大数据或AI产品的技术难点

原生云平台的一个主要特点是面向微服务设计，使用容器的方式编排普通的Web应用或者微服务。

但是大数据或者AI计算平台本身并没有采用微服务设计，各个系统都采用自身的分布式系统设计完成服务的管理和调度，并且执行时服务会一直变化。

以MapReduce为例，每个MR程序启动Map或者Reduce工作任务的数量是由应用本身来指定的（通过参数setmapreduce.reduce.tasks=N），调度器通过解析相关的参数来生成给定数量的工作任务，并在相关的任务完成后立即销毁。

大数据系统内的服务有自己的服务重启或者迁移逻辑，并且其配置或参数可能会随着应用或用户的输入而变化，而很多组件之间有很长的依赖链，如何及时地将某个参数的变化推送到所有的下游服务中，是调度系统的一个重要挑战。

对于没有数据存储的无状态服务，容器有多种编排方式进行编排和管理。

但是对于有数据状态的服务，如数据库（MySQL）或者分布式存储服务（Hadoopdistributedfilesystem，HDFS），由于容器内的数据会随着容器的销毁而销毁，因此采用传统的编排方式无法保证数据状态的一致性和数据持久化。

大数据和AI计算都涉及大量的数据和复杂的迭代运算，为了达到更好的性能，MapReduce、Spark和TensorFlow在架构中都特别注重“计算贴近数据”设计，一般会根据数据的位置选择启动相应的计算服务，尽量让计算任务和数据节点在同一个节点上，这样就可以避免网络带宽带来的性能损失。

而在容器模式下，不同的服务封装在不同的容器内，并且使用容器自身的网络；而容器网络一般采用重叠网络（overlaynetwork）模式，因此容器内的应用并不能感知调度容器的机器的物理拓扑，因此也就无法确定从哪个节点调度计算任务所在的容器。

为此，重新设计了云网络服务，以有效解决相应的调度信息缺失问题。

另外，大数据或者AI应用都是资源密集型应用，在运行时会对CPU、GPU、内存、磁盘、网络等资源进行动态申请和释放。

如某个应用可能会根据用户的输入生成一个Spark的机器学习任务，在大数据平台上生成若干个执行任务（executor），并申请一定的CPU和内存资源。

及时地响应这些短生命周期服务的资源需求，是当前各种原生云的调度系统无法有效支持的功能。

4.2融合大数据和AI的云调度系统的设计考量

为了有效解决各种实际技术难题，重新设计云平台的调度系统成为必须考虑和完成的工作。

相较于原生的Kubernetes调度系统，云平台的调度系统需要从以下方面重新设计。

（1）基于资源需求的调度能力整个云平台的资源从逻辑上被抽象为一个大的资源池，按照CPU、GPU、内存、存储和网络进行分类管理。

一个容器在被调度的时候，通过编排文件或者配置来描述相应的资源需求。

调度器需要根据资源池的实际资源情况和各个主机的物理资源情况，在毫秒级时延内找到合适的物理节点来调度当前容器。

在超大规模的云集群里，调度器的效率、性能和负载均衡是重要的技术指标，最终会影响云平台的资源使用率。

（2）支持本地存储并基于存储感知的容器调度为了有效支持有状态的服务，如数据库服务（MySQL）、分布式存储服务，本文设计了基于本地存储的存储服务。

云储存将所有的存储资源抽象为一个存储池，每个节点的本地存储抽象为若干持久化存储池（persistencevolumegroup），而单个可以被容器申请的存储资源定义为存储卷（persistencevolume，PV）。

每个PV只能被一个容器挂载，可以是任意大小，支持硬盘驱动器（harddiskdrive，HDD）或固态硬盘（solidstatedrive，SSD），也支持HDD与SSD组成的分层式存储。

有状态的容器服务在启动时会申请需要的PV资源（如大小、IOPS要求、SSD或HDD），调度器需要在毫秒内从平台内找到合适的机器，从而将容器调度起来；如果容器因为各种原因不能正常工作，调度器能够检测到不健康的状态，同时根据数据的物理拓扑情况，选择合适的机器重启相应的容器。

（3）网络物理拓扑的感知与实时调度能力为了支持灵活弹性的调度，一般情况下云原生平台为容器设计专门的网络空间，并且一般与主机网络保持透明。

通常一个服务器节点上会有多个容器服务，因此主机IP的数量远小于容器IP的数量。

在MapReduce、Spark和TensorFlow的设计中，在启动计算任务时，会根据数据存储的物理拓扑决定最终服务启动在哪个服务器上。

但是在容器平台上，所有的任务都只能感知容器网络，而不能感知物理机器的IP，无法了解数据分布的物理拓扑，因此也就无法保证计算和数据的局部性。

为了解决这个问题，在调度系统内增加了网络物理拓扑模块，实时地维护物理IP和容器IP的映射关系表。

当有状态服务在申请调度的时候，可以通过IP映射表找到可用于最终调度的物理机器。

（4）动态标签能力与基于标签的调度能力复杂的应用系统对调度系统有更多细节的要求，如多租户业务系统往往要求一个租户的所有服务尽量调度在同一批物理机器中；支持高可用的服务往往要求调度系统有反亲和性（anti-affinity）要求，即将一个服务的多个实例调度到不同的物理机器上，这样就不会发生一个物理机器宕机后影响多个高可用实例，进而导致服务不可用的情况。

因此在调度系统中增加了动态标签能力和基于标签的调度能力，调度模块可以根据运行时的数据给物理机器和容器应用动态增加或删除标签，而调度系统根据标签的匹配度选择更合适的调度策略。

（5）应用依赖运行参数的感知以及基于参数的调度能力分布式应用在微服务拆分后，每个服务都有比较复杂的依赖服务链以及影响的服务链，而每个微服务在运行时都可能发生运行参数变化、服务启停、重新调度等操作，这些变化不仅影响当前的微服务，还可能影响所有的依赖链的服务。

因此调度系统中增加了应用配置感知模块，通过与全局的配置中心的数据交互，调度系统能够实时地感知一个应用变化的事件的所有影响情况，并根据多个可能的状态迁移图选择最合适的调度策略。

（6）不同优先级下基于抢占的调度能力在业务负载比较重并可能超过云系统内资源总量的时候，需要有机制保证高优先级的服务正常运行，牺牲低优先级应用的服务质量，也就是服务质量等级保证（servicelevelagreement，SLA），这是云平台的一个重要特性。

在调度系统内增加了基于抢占的调度模式，将服务和资源按照优先级进行区分，如果出现资源不足以调度高优先级应用的情况，则通过抢占的方式调度低优先级应用的资源。

5融合大数据和AI的云调度系统的实现

类似于操作系统的调度模块，云平台的调度是整个云平台能够有效运行的关键技术。

云平台的总体架构如图2所示，最底层是Kubernetes服务，其上层运行着自研的几个产品或服务。

其中，配置中心用于实时地收集和管理云平台内运行的所有服务的配置参数，支持运维人员手动地对一些服务进行参数设置或管理；物理资源池是通过各个服务进行池化后的逻辑资源，应用申请的物理资源都会从这个资源池中逻辑地划分出去，在应用使用完结后再返还给资源池，平台会给不同的租户做资源配额限制；云存储服务是基于本地存储开发的分布式存储服务，会保留状态服务的数据，保证应用数据的最终持久化和灾备能力；云网络服务是自研的网络服务，提供应用和租户类似虚拟私有云（virtualprivatecloud，VPC）的网络能力，可以做到完整的资源隔离和服务等级协议（servicelevelagreement，SLA）管控；标签中心用于实时地收集和管理各个应用、主机、资源的标签，支持动态的标签修改与实时调度触发。

在此之上是云调度系统，它接收应用的输入，从配置中心、标签中心、云存储服务和云网络服务中实时获取平台运行指标，并从物理资源池中获取资源的使用情况，从而根据运行时的信息进行精确的调度决策。

云调度系统之上是各类应用服务，包括大数据、AI、数据库类以及各种微服务。

图2   调度系统的总体架构

5.1调度系统架构

本文设计的云平台的调度系统的内部架构如图3所示，包含元信息模块、对外服务模块以及调度决策模块。

当一个应用通过KubernetesAPI或者命令行（基于Kubectl）的方式启动时，它会传入一个指定服务编排方式的yaml文件以及启动应用需要的容器镜像（dockerimage）。

在yaml文件中会指定当前应用需要的资源、与调度相关的标注信息（或标签信息）以及对其他应用的依赖关系。

对外服务模块负责解析编排文件，同时负责完成应用的依赖解析和管理，生成对服务的依赖图；参数计算模块负责编排文件中与配置变量相关的计算，并生成最终的资源需求；实例渲染模块最终生成一个完整的应用描述，并将这个描述文件提交给调度决策模块。

元信息模块负责与Kubernetes平台交互，实时地维护用于调度的各种元数据。

资源池数据主要包括当前集群的各种资源总量以及当前的使用情况，并可以精细到各个节点和硬盘级别；网络拓扑模块负责与容器网络进行交互，实时地维护当前容器网络与主机网络的拓扑；存储拓扑模块负责与云存储服务交互，实时记录当前存储池的各个存储卷（PV）的容量使用情况和每秒进行读写操作的次数（input/outputoperationspersecond，IOPS）；服务运行指标主要同步当前集群各个物理节点上各个容器的运行指标以及各个物理机的各项资源的使用指标；配置元数据模块主要协助配置中心维护各个应用的实时配置参数。

因此，通过元信息模块，调度器能够维护当前云平台的各种调度决策数据，从而实时地根据运行数据进行最优化调度。

在对外服务模块提交了实时渲染的应用描述请求后，调度决策模块会根据请求中的资源大小，通过内部的6个调度器进行调度目标的选择。

依赖调度器会解析应用的需求，同时遍历当前的服务元数据，查找是否有已经运行的可以给当前应用依赖的微服务。

如果有，则直接使用该服务，并更新相应的配置参数；如果没有，则解析被依赖的服务的参数，同时选择运行一遍完整的调度流程。

如果有嵌套服务依赖，则递归调用相关的调度逻辑，直至所有依赖链的服务都处于运行状态。

存储调度器提供基于存储感知的容器调度能力，它会解析应用是否有明确的本地数据的要求，如果有，则从存储拓扑中找到合适的物理节点组，并将其他节点标记为此次调度无效；资源调度器负责找到有足够资源启动应用或者容器的物理节点组；网络调度器负责根据应用的网络IP要求选择满足网络规则的物理节点组；标签调度器负责选择满足各种标签规则的物理节点组。

通过这5个调度器选择的物理节点如果有多个，调度器则根据负载均衡的原则选择合适的物理节点，从而启动这个容器；如果没有任何节点有足够的资源，SLA调度器会遍历被选择指定节点上已经在运行的所有容器，找到当前被优先级更低的应用占用的容器，并选择kill等机制，循环此操作，直到资源满足本次调度为止，从而实现高优先级应用的抢占式调度策略。

图3   调度系统的内部架构

5.2服务的编排系统

应用服务的调度需求包含依赖的服务、服务自身的Docker镜像、资源需求、网络与存储需求、配置参数等各个方面的属性，因此选择Jsonnet语言进行应用的资源描述文件。

Jsonnet是Google公司开源的新一代JSON协议，支持引用、算术运算、条件操作符、函数、变量、继承等强大的计算能力，可以描述多样化的需求。

一个简单的基于Jsonnet的资源编排文件示例如图4所示。

其中app.yaml描述依赖关系和依赖变量，config.jsonnet描述配置参数和定义输入，而customizemain.jsonnet定义模板入口和输出变量。

在运行时，通过服务模块的实例渲染组件即可将这些编排文件和当前平台内的运行参数进行实例化，渲染出一个可以被Kubernetes调度的service/replicationcontroller或者deployment的描述文件。

图4   基于Jsonnet的资源编排文件示例

5.3配置标签中心

由于每个服务运行时都可能发生重启或者迁移，且API网关等可能会动态地设置运行参数，为了让服务能够及时地感知各种运行参数，创建了一个统一的配置标签中心作为中心化的服务，提供配置和标签元数据的管理和查询。

应用程序使用的配置基于KubernetesConfigMap的方式来实现配置与容器镜像的解耦。

ConfigMap的示例如图5所示，包含了标签和数据属性，都是以键-值数据对的方式来保存的。

容器可以直接引用相应的ConfigMap中的数据，而这些配置数据则存储在配置标签中心服务中。

用户可以通过界面或者命令行的方式修改配置的数值或者增加新的键-值对，并且当有任何配置数据修改后，Kubernetes会动态地修改每个节点的ConfigMap文件，并在短时间内让容器知晓相应的数据变化，从而实现中心化的动态配置和标签修改。

由于配置和标签中心服务中包含了运行时的各种配置和标签数据，因此调度器通过与配置标签中心交互就可以获取整个云平台的标签和配置元数据，从而可以支持基于标签的调度能力。

图5   ConfigMap的示例

5.4云存储服务

云平台中的存储服务Warpdrive提供一个中心化的RESTful服务，可以支持外部服务对存储卷的实际使用情况的实时查询，因此调度器通过监听相关的接口来实时感知每个主机的存储卷使用情况以及每个容器与物理节点的绑定关系。

5.5云网络服务

网络服务也同样提供RESTfulAPI查询服务，使得调度器可以知晓各个容器IP和物理IP的使用情况以及各个容器的网络防火墙规则等实时数据，因此调度器能够实时地感知云平台内的网络和存储实际运行情况。

5.6计算调度过程中的数据拓扑感知

在容器云计算环境下，分布式网络中的各个主机可以是一个或多个独立的网络，每个网络都可以包括一个或多个子网络，网络地址从该主机上的子网络中获得。

当容器销毁时，容器的网络地址被回收，等待下次使用。

应用感知数据拓扑的方式如图6所示，当容器中的数据应用（如Spark应用）需要启动计算任务时，调度器首先根据该服务的依赖关系找到其需要的数据应用的容器（如HDFS数据节点），然后通过元信息模块查询其所在的物理节点的网络和存储信息。

元信息模块通过对存储服务和网络服务的实时查询来获取和维护最新的元数据。

一般情况下，分布式存储有多个存储副本，会通过调度器的反亲和性保证调度在不同的物理节点上，因此调度器会得到一个物理节点的列表。

然后根据这几个节点的实际资源使用负载情况，选择当前资源负载最低的节点来启动对应的计算服务容器。

由于两个容器都在一个主机上，计算服务可以与存储服务通过本地网络进行数据传输，或者创建域套接字（domainsocket）等机制来提高数据读取速度，增强性能。

在云平台集群规模比较大的情况下，网络IP数量和网段数量都比较大，而应用查询的请求也有很高的并发度。

为了保证高速的网络检索能力，使用基数树（radixtree）对各个应用的网络配置信息进行缓存，基于基数树的快速匹配方法如图7所示。

查询网络地址172.16.1.23，对应的二进制是10101100000100000000000100010111，在基数树中可以很快匹配到对应的子网为172.16.1.0/24，并从该子网获取所有必需的网络信息，包括容器网段、主机信息、交换机号以及机架位等。

图6   应用感知数据拓扑的方式

图7   基于RadixTree的快速匹配方法

5.7调度的总体流程

对于调度策略模块，它的输入是应用的资源需求、标签属性、依赖关系和输入输出参数等信息，输出是选定的物理节点或者节点组以及对应的容器的优先级信息，同时，依赖元数据模块提供的平台运行数据进行调度决策支撑。

调度器的决策流程如图8所示。

调度器从任务调度队列获取待调度的任务，形成节点-任务映射表。

其中，调度器持续对API服务器中创建的任务进行监听，并读取新的任务形成任务调度队列。

（1）筛选阶段调度器根据映射表以及预设筛选条件确定一组符合条件的目标物理节点。

其中，预设筛选条件可以是当前任务所需的资源与物理节点上的剩余资源之间的匹配条件、当前任务所需的端口与物理节点上的端口之间的匹配条件以及是否带有特殊标签等。

如果当前任务配置了对持久化存储的需求或者对数据拓扑的感知，调度器也会考虑满足这些条件的节点。

最终调度器会将满足上述所有筛选条件的节点整理出来进行下一步处理。

（2）优选阶段调度器根据筛选阶段拿到的节点以及预设优选条件对各个物理节点进行评分，最终选择分数最高的作为目标物理节点。

其中优选条件包括：

节点空闲资源越多，评分越高；