CN107066319B - 一种面向异构资源的多维调度系统 - Google Patents

Abstract

本发明公开了一种面向异构资源的多维调度系统，包括：集群管理模块、容器管理模块、资源统调模块、硬件抽象模块、关系数据库及组件通信模块；资源统调模块包括集群资源分配组件，用于管理接入集群的各个二级调度框架和主机资源管理组件，并将主机资源管理组件上的资源按照预设的策略分配给二级调度框架；主机资源管理组件，用于接收并执行来自集群资源分配组件的命令、管理节点上的容器任务，并为各个容器分配资源；所述集群管理模块用于管理系统中的集群资源。所述面向异构资源的多维调度系统通过将资源调度设计为两级调度架构，对集群资源进行统一调度和管理。该系统能够优化资源配置以及调度结构，进而提高异构资源调度的效率和效果。

Description

一种面向异构资源的多维调度系统

技术领域

本发明涉及数据通信及处理技术领域，特别是指一种面向异构资源的多维调度系统。

背景技术

近几年，科学家和学者在跨域资源调度方面进行了大量的研究，目的是提高资源的利用率、避免造成资源浪费、提高资源的管理和应用效率。通常资源池中包括计算资源、存储资源、网络资源等多种资源，各种资源的硬件及软件都涉及多个厂家多种产品。通过资源调度管理技术，能够兼容各种资源和设备，对包括虚拟化后的计算资源、分布式存储资源以及传统的物理机资源、磁盘阵列资源、网络资源以及他们之下的物理设备、第三方软件、用户的私有应用软件等进行统一调度、管理、监控。此外，资源管理还使得资源池上的各种应用平台，能够按照需要灵活地申请或释放资源，统一管理调度，按需分配。

目前的调度方法要么是提供虚机资源的虚拟化和调度，要么是提供容器资源，无法实现面向异构资源的多维度调度，并同时提供虚拟主机和容器资源。传统虚拟化技术解决了基于资源需求驱动的单资源池的资源调度问题。这种模式较为粗放，不能从应用角度解决应用的实际资源需求，也不能在更大资源规模上实现分布式资源调度。因此，在实现本发明的过程中，发明人发现现有技术中至少存在以下具体技术难点：虚拟资源无法在运行时进行调度和重新划分、不同类型的应用框架资源难以共享和资源调度局限于单个集群或者数据中心等问题。

发明内容

有鉴于此，本发明的目的在于提出一种面向异构资源的多维调度系统，能够优化资源配置以及调度结构，进而提高异构资源调度的效率和效果。

基于上述目的本发明提供的一种面向异构资源的多维调度系统，包括：集群管理模块、容器管理模块、资源统调模块、硬件抽象模块、关系数据库以及组件通信模块；所述资源统调模块分别与集群管理模块、容器管理模块、硬件抽象模块、关系数据库、组件通信模块连接。

所述资源统调模块包括集群资源分配组件、主机资源管理组件；且所述集群资源分配组件用于管理接入集群的各个二级调度框架和主机资源管理组件，并将主机资源管理组件上的资源按照预设的策略分配给二级调度框架；所述主机资源管理组件用于接收并执行来自集群资源分配组件的命令、管理节点上的容器任务，并为各个容器分配资源。

所述集群管理模块用于管理系统中的集群资源；所述容器管理模块用于管理系统中的容器资源；所述硬件抽象模块用于为系统提供硬件支撑，包括物理服务器和虚拟服务器；所述组件通信模块用于为系统提供通信。

可选的，所述集群资源分配组件采用master-slave主从结构，其中，Master的守护进程为第一级调度，用于管理集群中所有服务器节点上运行的Slave守护进程；任务调度器为第二级调度。

可选的，主Master服务器节点用于协调所有从Slave服务器节点，并确定每个服务器节点的可用资源，聚合跨服务器节点的所有可用计算资源，然后向注册到Master的二级调度框架发出资源邀约；

所述二级调度框架根据应用程序的需求，选择接受或拒绝来自Master的资源邀约；若接受邀约，则Master将协调二级调度框架和Slave，调度参与节点上的任务，并在容器中执行该任务，使多种类型的任务在同一个节点上同时运行。

可选的，所述二级调度框架包括资源调度器和执行器进程，其中，所述执行器运行在每个服务器节点上；所述资源调度器用于与不同类型的二级调度框架进行通信。

可选的，所述资源调度器采用数据一致性组件，用于防止集群资源分配组件出现单点故障。

可选的，所述资源统调模块还包括：

框架管理组件，用于管理系统的二层调度框架；所述二层调度框架包括资源统调模块中的一级调度框架和容器管理模块中的二级调度框架，且所述二级调度框架用于调度和管理不同类型的容器任务；所述一级调度框架和所述二级调度框架均需要向所述框架管理组件注册，且所述一级调度框架向注册的二级框架提供资源供给。

可选的，所述一级调度框架采用RDF算法为接入的不同二级调度框架分配资源。

可选的，所述集群资源分配组件为一级调度框架中的master，所述主机资源管理组件为一级调度框架中的slave；所述主机资源管理组件定期向所述集群资源分配组件汇报本机资源使用情况，若所述集群资源分配组件在预设的时间阈值内没有收到所述主机资源管理组件的汇报，则剔除该服务器节点的资源。

可选的，所述集群资源分配组件具备过滤器机制和撤销机制；所述过滤器机制是指集群资源分配组件和二级调度框架通信时，如果某些框架总是拒绝资源供给，则只向二级调度框架发送符合资源要求的资源供给；所述撤销机制是指如果某个二级调度框架在一定时间内没有为分配的资源返回对应的容器任务，则要自动回收其资源量，并将这些资源分配给其他框架。

可选的，所述资源统调模块还包括：

集群资源监控组件，用于采集集群资源的监控信息；

容器沙盒，用于为容器资源隔离提供底层支撑；

容器执行器，用于与容器调度配合，容器调度指定具体的容器运行任务到计算节点，由容器执行器负责与容器后台服务通信，实现对容器的创建、停止、删除操作；

容器状态监控组件，用于采集主机上的容器状态监控信息；

高可用服务组件，用于为系统中有高可用要求的组件提供一致性服务。

从上面所述可以看出，本发明提供的面向异构资源的多维调度系统，通过将资源调度设计为两级调度架构，使得调度系统能够调度多种类型任务；实现了分布式计算框架的集群资源管理、资源调度框架的调度算法以及二级框架管理等功能。其中，以资源统调层中的集群资源分配组件作为核心组件，对集群资源进行统一调度和管理。因此，本申请所述的面向异构资源的多维调度系统能够优化资源配置以及调度结构，进而提高异构资源调度的效率和效果。

附图说明

图1为本发明提供的面向异构资源的多维调度系统的结构示意图；

图2为本发明提供的集群资源调度架构设计图；

图3为本发明提供的Resource Offer(资源供给)调度架构图；

图4为本发明提供的资源统调层结构示意图；

图5为本发明提供的云操作系统资源调度框架架构示意图；

图6为本发明提供的资源调度框架调用时序图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本发明进一步详细说明。

需要说明的是，本发明实施例中所有使用“第一”和“第二”的表述均是为了区分两个相同名称非相同的实体或者非相同的参量，可见“第一”“第二”仅为了表述的方便，不应理解为对本发明实施例的限定，后续实施例对此不再一一说明。

在企业的应用云化实践中，常常要求建设覆盖全种类计算资源的私有云基础设施。但是基于企业级应用具有的典型特征，使得对计算资源提供了苛刻的要求。特征如下：(1)应用供应商众多、技术架构不统一；由此导致应用系统很难步调一致的进行云化应用的改造，企业信息化体系中集中式、分布式、松耦合、紧耦合的应用系统会长期共存。(2)企业级应用的需求复杂，难以用一种资源来满足所有服务与组件的资源需求。另外，很多应用开发和部署依然采用传统的方式，即软件和其运行环境强绑定。软件严重依赖底层的硬件性能，不同的应用直接资源基本不能共享。竖井化的建设随处可见，应用和平台的耦合非常严重，系统云化程度低又造成了资源利用率低，结果导致长期总体TCO(Total cost ofownership)的失控。

因此，对于企业级数据中心，为了简化管理，提高资源效率，设计一种覆盖全种类计算资源的异构资源调度引擎作为数据中心操作系统就成为企业信息化基础设施的核心。具体要求可以并行调度Power计算资源、x86物理服务器资源、KVM虚拟主机、商业虚拟主机、容器等所有企业应用的资源需求。分布式计算框架从传统的集中式计算框架发展而来，因此在概念上与传统计算也有清晰的类比关系。分布式计算框架分为以下几个层面，包括资源的调度、业务的编排和应用的封装。本发明通过研究基于应用需求驱动的分布式跨域计算框架，实现资源根据应用运行状态按需调整、统一适配的分布式框架实现资源共享和高效的跨域资源调度。依托Openstack、Docker和Mesos等开源技术进行企业级增强和自主研发。通过对数据中心混合资源(服务器、磁盘阵列、网络设备等物理资源和虚拟机、容器等虚拟资源)的标准化封装和分布式调度，为业务应用提供“多合一”的IT运行环境，实现基础资源的统一管理、弹性调配。本发明具有如下重要意义：

(1)资源根据应用运行状态按需调整。例如：随着公司承载的应用越来越多样化，特别是大数据这种消耗资源大，或者潮汐性明显的分布式应用，资源的弹性扩缩需求强烈。虽然依赖虚拟化等技术能够进行底层资源重新规划，但无法在应用运行过程中进行资源调动，只能等待所有任务完成之后重新切分部署。应用的资源划分基本是按照资源峰值进行估算，同时结合运行时观察的数据，定期进行调整。随着公司互联网应用的增多，部分业务的资源需求呈现明显波峰波谷，间或出现突发性增长，传统估算方法造成巨大的资源浪费。通过研究基于应用需求驱动的分布式跨域计算框架，能够实现应用运行状态下的资源再分配，在统一适配的分布式框架下实现资源共享，避免资源浪费，降低使用成本。

(2)统一适配的分布式框架实现资源共享。通过研究统一适配的分布式框架，使得多种应用框架能够进行资源共享，打破多种应用框架在云上形成资源竖井，实现资源利用率的提升，降低资源使用成本，避免资源浪费。同时，统一适配的分布式框架也能对未来新建应用系统的应用框架设计提供指导作用，使得计算类型不同的多种应用之间更好的进行资源共享，支撑基础资源的更快速灵活交付，推动基础资源供应由按需配置向按需供应转变。

(3)高效的跨域资源调度。公司目前的应用调度框架针对的是单个集群或数据中心设计，所以这个的局限性也阻碍了跨数据中心调度的实现。通过研究基于应用需求驱动的分布式跨域计算框架，调动全局资源，实现应用的就近访问。

参照图1所示，为本发明提供的面向异构资源的多维调度系统的结构示意图。所述面向异构资源的多维调度系统包括：集群管理模块、容器管理模块、资源统调模块、硬件抽象模块、关系数据库以及组件通信模块；所述资源统调模块分别与集群管理模块、容器管理模块、硬件抽象模块、关系数据库、组件通信模块连接；所述资源统调模块包括集群资源分配组件、主机资源管理组件；且所述集群资源分配组件用于管理接入集群的各个二级调度框架和主机资源管理组件，并将主机资源管理组件上的资源按照预设的策略分配给二级调度框架；所述主机资源管理组件用于接收并执行来自集群资源分配组件的命令、管理节点上的容器任务，并为各个容器分配资源；所述集群管理模块用于管理系统中的集群资源；所述容器管理模块用于管理系统中的容器资源；所述硬件抽象模块用于为系统提供硬件支撑，包括物理服务器和虚拟服务器；所述组件通信模块用于为系统提供通信。

由上述实施例可知，本发明提供的面向异构资源的多维调度系统，通过将资源调度设计为两级调度架构，使得调度系统能够调度多种类型任务；实现了分布式计算框架的集群资源管理、资源调度框架的调度算法以及二级框架管理等功能。其中，以资源统调层中的集群资源分配组件作为核心组件，对集群资源进行统一调度和管理。因此，本申请所述的面向异构资源的多维调度系统能够优化资源配置以及调度结构，进而提高异构资源调度的效率和效果。

可选的，参照图2所示，为集群资源调度架构设计图。如图所述，资源统调层由两个核心组件组成，分别是集群资源分配组件(Master)，主机资源管理组件(Slave)。也即，使得所述集群资源分配组件采用master-slave主从结构，其中，Master的守护进程为第一级调度，用于管理集群中所有服务器节点上运行的Slave守护进程；任务调度器为第二级调度。所述集群由物理服务器或虚拟服务器组成，用于运行应用程序的任务。可选的，第二级调度由被称作Framework的任务调度器组成。其中，应用调度器和任务调度器作为容器的管理和调度核心，在集群资源分配组件之上，将集群资源分配给相应的应用、定时任务和一次性任务。集群资源分配组件能够很好的适应容器，同时云操作系统的功能组件自身都通过数据一致性组件进行高可用部署，以确保系统本身的可靠。

进一步，主Master服务器节点用于协调所有从Slave服务器节点，并确定每个服务器节点的可用资源，聚合计算跨服务器节点的所有可用资源，然后向注册到Master的二级调度框架发出资源邀约；所述二级调度框架根据应用程序的需求，选择接受或拒绝来自Master的资源邀约；若接受邀约，则Master将协调二级调度框架和Slave，调度参与节点上的任务，并在容器中执行该任务，使多种类型的任务在同一个节点上同时运行。其中，任务包括web应用和大数据应用。所述二级调度框架作为master的客户端。

可选的，所述二级调度框架包括资源调度器(Scheduler)和执行器(Executor)进程，其中，所述执行器运行在每个服务器节点上；所述资源调度器用于与不同类型的二级调度框架进行通信。且每种二级框架由相应的应用集群管理。进一步，所述资源调度器采用数据一致性组件，用于防止集群资源分配组件出现单点故障。

可选的，参照图3所示，为本发明提供的Resource Offer(资源供给)调度架构图。所述集群资源分配组件是整个系统的核心，负责管理接入集群的各个二级调度框架和主机资源管理组件，并将主机资源管理组件上的资源按照Resource Offer策略分配给二级调度框架。

可选的，任务调度作为核心部件，主要负责将各个主机资源管理组件上资源分配给各个二级调度任务，常见的调度机制有FIFO，Fair Scheduler，Capacity Scheduler，Quincy，Condor等。

参照图4所示，为本发明提供的资源统调层结构示意图。也即，本申请中资源统调模块对应的资源统调层结构采用两级调度模式，利用主节点管理各类调度任务以及从节点的任务处理。具体的，所述资源统调模块还包括：框架管理组件，用于管理系统的二层调度框架；所述二层调度框架包括资源统调模块中的一级调度框架和容器管理模块中的二级调度框架，且所述二级调度框架用于调度和管理不同类型的容器任务；所述一级调度框架和所述二级调度框架均需要向所述框架管理组件注册，且所述一级调度框架向注册的二级框架提供资源供给。由于采用两级调度结构，资源统调层负责集群资源的管理和调度，包含了一级调度框架，而容器管理层负责应用容器的管理和调度，容器管理层中的应用容器调度组件和任务容器调度组件都属于二级调度框架，每种二级调度框架分别调度和管理不同类型的容器任务，这些框架都需要向框架管理组件注册，一级调度框架会向注册的二级调度框架提供资源供给。通过框架管理组件管理二级调度框架的状态、注册时间以及框架的资源申请量；通过一级调度框架API，实现针对不同的任务类型的二级调度框架，例如长服务任务调度框架、周期性任务调度框架、Hadoop任务调度框架、Spark任务调度框架等。可选的，在接入多种二级调度框架时，一级调度框架采用RDF算法为这些框架分配资源，实现多种类型任务的统一资源分配和调度，做到资源的混合部署和充分利用。

在进一步的实施例中，集群资源分配组件属于一级调度框架，主要用于调度集群资源。集群资源分配组件为一级调度框架的Master，从Slave获得主机资源使用情况，形成集群总体资源，以资源供给的形式向二级调度框架提供资源。主机资源管理组件属于一级调度框架中的Slave，定期向Master汇报本机的资源使用情况，如果Master一定时间内收不到Slave的汇报，则认为该节点丢失，并剔除该节点的资源。可选的，集群资源分配组件采用最大-最小公平分配策略。此外，可选的，集群资源分配组件可以根据需要设置过滤器机制和撤销机制。其中，过滤器机制是指集群资源分配组件和二级调度框架通信时，如果有些框架总是拒绝资源供给，那么由于额外的通信开销会使得调度性能低效，为避免不必要的通信，通过过滤器机制只向二级调度框架发送符合资源要求的资源供给；撤销机制是指如果某个二级调度框架在一定时间内没有为分配的资源返回对应的容器任务，则要自动回收其资源量，并将这些资源分配给其他框架。进一步，集群资源分配组件通过高可用服务组件实现高可用，避免单点故障造成的系统失效。

在本发明一些可选的实施例中，所述资源统调模块还包括：集群资源监控组件，用于采集集群资源的监控信息；其中，所述监控信息主要包括两部分，一部分是集群组件状态信息，另一部分是集群资源的使用量。该集群资源监控组件采集信息，通过分布式通信组件传输给集群管理模块，用于实现系统前端的管理需求。可选的，该集群资源监控组件采用轻量级设计，不允许过多占用主机资源，为主机提供更大余量。

容器沙盒，用于为容器资源隔离提供底层支撑；其中，容器沙盒直接调用操作系统cgroup服务，为容器分配CPU、内存等资源，同时在指定目录下创建以容器ID为名的子目录，用于存放容器运行过程中所产生的数据。该目录作为容器的持久化数据，即使容器停止也会继续保留，只要在彻底删除容器时，才会删除该目录及目录中的数据。

容器执行器，用于与容器调度配合，容器调度指定具体的容器运行任务到计算节点，由容器执行器负责与容器后台服务通信，实现对容器的创建、停止、删除等操作；且容器执行器需要参考容器后台服务API，相当于容器调度和容器后台服务之间的桥梁。容器运行过程中，容器执行器获取到容器状态信息以及容器服务日志，收集并上报给集群管理节点。

容器状态监控组件，用于采集主机上的容器状态监控信息；其中，所述监控信息主要包括两部分，一部分是容器的运行状态，另一部分是容器的资源使用量。容器状态监控组件采集信息，通过分布式通信组件传输给集群管理组件，用于实现系统前端的管理需求。可选的，容器状态监控组件需采用轻量级设计，不允许过多占用主机资源。

高可用服务组件，用于为系统中有高可用要求的组件提供一致性服务。高可用服务组件通过选举机制产生Leader，某节点获得选票过半数可成为Leader，其他节点以Follower形式跟随，因此，部署高可用服务组件时，以奇数节点进行部署，以保证有某一个或几个节点宕机后，能够通过选举产生新的Leader。容器管理模块的高可用服务组件主要用于确保资源统调层组件的高可用。

参照图5所示，为本发明提供的云操作系统资源调度框架架构示意图。资源调度框架用于进行虚拟化和容器异构资源调度。资源调度框架支持Docker Swarm、Apache Mesos、Google Kubernetes三种COEs(Container Orchestration Engine，容器编排引擎)。云操作系统通过插件方式基于资源调度框架进行扩展，添加对COE的支持，通过资源调度框架界面实现对异构资源容器进行管理。资源调度框架包括两个子模块：资源调度框架API和资源调度框架Conductor，其中，资源调度框架API负责接收REST API请求；Conductor负责与资源编排系统及COE交互，创建容器集群。进一步，参照图6所示，为本发明提供的资源调度框架调用时序图，由图可知，用户能够通过资源调度框架创建所需的容器集群和容器应用。

由此，通过云操系统的资源调度框架实现容器编排集群管理，终端用户通过命令行或界面，通过资源调度框架快速创建出容器编排集群，并能获取集群状态，部署成功后，可动态调整集群大小，新增slave节点数量，可删除集群。通过资源调度框架和资源编排系统对容器应用管理，用户在创建出的编排集群之上通过资源编排系统+COE创建容器应用。实现容器应用自动扩缩功能：用户可对容器应用设置阈值，如CPU/内存使用率等，COE系统对应用状态进行监测，达到阈值后，COE自动创建出更多数量的应用实例。同时容器COE集群节点自动扩缩。用户可设置阈值，如集群容器/节点数量比等，可根据设定的条件，动态资源调度调整COE节点规模。

此外，资源调度框架在安全方面通过在云操作系统已有的多租户网络隔离以及其它现有安全机制之上，用户可以用安全的方式去访问容器管理REST API，进行集群管理和容器管理。资源调度框架对容器持久化数据进行管理，实现容器删除后数据将被删除，用户可使用持久化存储机制来保存数据、重用数据以及在不同容器之间共享数据，可利用云操作系统已有的丰富的块存储接口，把云操作系统的块数据管理能力用于容器持久化数据。资源调度框架调度云操作系统网络提供给容器网络保证连通，保证用户可灵活自定义和管理容器网络拓扑，可把云平台下已有的SDN等基础设施应用到容器。

综上可知，本发明涉及一种面向异构资源的多为调度算法框架设计，通过任务之间进行资源隔离，减少资源争抢。任务分配调度时结合资源分配，各个任务分配合理的资源，充分利用系统资源，减少资源利用不充分的问题。资源调度结合优先级，优先级高的分配更多的资源。提高全系统的资源利用率。各个子系统，存在不同时期，对资源需求不一样的情况，平滑系统资源的利用。支持动态调整切分资源，增强系统扩展性。系统对资源的规划很难一次性准确，通过分级调度和运行时资源调度，实现了动态扩展，提高了资源的灵活性。

因此，本发明的关键点和保护点在于：(1)采用分布式资源调度：为虚拟机、大数据集群、数据库集群、容器集群按需调度资源，支撑集群的按需扩展。(2)实现动态任务调度：采用任务调度器实现自动化容器调度、应用管理、动态部署应用和服务，并提供应用运行监控。(3)实现弹性扩展：提供物理集群、虚拟主机、虚拟硬盘、网络等资源的在线弹性调整。(4)实现在线迁移：采用高性能分布式存储，实现虚拟主机的安全热迁移，保证业务不中断。(5)实现跨数据中心管理：支持不同数据中心的云资源统一管理，可根据应用需求进行分区域运行。

所属领域的普通技术人员应当理解：以上任何实施例的讨论仅为示例性的，并非旨在暗示本公开的范围(包括权利要求)被限于这些例子；在本发明的思路下，以上实施例或者不同实施例中的技术特征之间也可以进行组合，步骤可以以任意顺序实现，并存在如上所述的本发明的不同方面的许多其它变化，为了简明它们没有在细节中提供。

另外，为简化说明和讨论，并且为了不会使本发明难以理解，在所提供的附图中可以示出或可以不示出与集成电路(IC)芯片和其它部件的公知的电源/接地连接。此外，可以以框图的形式示出装置，以便避免使本发明难以理解，并且这也考虑了以下事实，即关于这些框图装置的实施方式的细节是高度取决于将要实施本发明的平台的(即，这些细节应当完全处于本领域技术人员的理解范围内)。在阐述了具体细节(例如，电路)以描述本发明的示例性实施例的情况下，对本领域技术人员来说显而易见的是，可以在没有这些具体细节的情况下或者这些具体细节有变化的情况下实施本发明。因此，这些描述应被认为是说明性的而不是限制性的。

尽管已经结合了本发明的具体实施例对本发明进行了描述，但是根据前面的描述，这些实施例的很多替换、修改和变型对本领域普通技术人员来说将是显而易见的。例如，其它存储器架构(例如，动态RAM(DRAM))可以使用所讨论的实施例。

本发明的实施例旨在涵盖落入所附权利要求的宽泛范围之内的所有这样的替换、修改和变型。因此，凡在本发明的精神和原则之内，所做的任何省略、修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (9)

1.一种面向异构资源的多维调度系统，其特征在于，包括：集群管理模块、容器管理模块、资源统调模块、硬件抽象模块、关系数据库以及组件通信模块；所述资源统调模块分别与集群管理模块、容器管理模块、硬件抽象模块、关系数据库、组件通信模块连接；

所述资源统调模块包括集群资源分配组件、主机资源管理组件；且所述集群资源分配组件用于管理接入集群的各个二级调度框架和主机资源管理组件，并将主机资源管理组件上的资源按照预设的策略分配给二级调度框架；所述主机资源管理组件用于接收并执行来自集群资源分配组件的命令、管理节点上的容器任务，并为各个容器分配资源；所述二级调度框架包括资源调度器和执行器进程，其中，所述执行器运行在每个服务器节点上；所述资源调度器用于与不同类型的二级调度框架进行通信；

所述集群管理模块用于管理系统中的集群资源；所述容器管理模块用于管理系统中的容器资源；所述硬件抽象模块用于为系统提供硬件支撑，包括物理服务器和虚拟服务器；所述组件通信模块用于为系统提供通信。

2.根据权利要求1所述的面向异构资源的多维调度系统，其特征在于，所述集群资源分配组件采用master-slave主从结构，其中，Master的守护进程为第一级调度，用于管理集群中所有服务器节点上运行的Slave守护进程；任务调度器为第二级调度。

3.根据权利要求2所述的面向异构资源的多维调度系统，其特征在于，主Master服务器节点用于协调所有从Slave服务器节点，并确定每个服务器节点的可用资源，聚合跨服务器节点的所有可用计算资源，然后向注册到Master的二级调度框架发出资源邀约；

所述二级调度框架根据应用程序的需求，选择接受或拒绝来自Master的资源邀约；若接受邀约，则Master将协调二级调度框架和Slave，调度参与节点上的任务，并在容器中执行该任务，使多种类型的任务在同一个节点上同时运行。

4.根据权利要求1所述的面向异构资源的多维调度系统，其特征在于，所述资源调度器采用数据一致性组件，用于防止集群资源分配组件出现单点故障。

5.根据权利要求1所述的面向异构资源的多维调度系统，其特征在于，所述资源统调模块还包括：

框架管理组件，用于管理系统的二层调度框架；所述二层调度框架包括资源统调模块中的一级调度框架和容器管理模块中的二级调度框架，且所述二级调度框架用于调度和管理不同类型的容器任务；所述一级调度框架和所述二级调度框架均需要向所述框架管理组件注册，且所述一级调度框架向注册的二级框架提供资源供给。

6. 根据权利要求5所述的面向异构资源的多维调度系统，其特征在于，所述一级调度框架采用 RDF 算法为接入的不同二级调度框架分配资源。

7.根据权利要求5所述的面向异构资源的多维调度系统，其特征在于，所述集群资源分配组件为一级调度框架中的master，所述主机资源管理组件为一级调度框架中的slave；所述主机资源管理组件定期向所述集群资源分配组件汇报本机资源使用情况，若所述集群资源分配组件在预设的时间阈值内没有收到所述主机资源管理组件的汇报，则剔除该服务器节点的资源。

8.根据权利要求1所述的面向异构资源的多维调度系统，其特征在于，所述集群资源分配组件具备过滤器机制和撤销机制；所述过滤器机制是指集群资源分配组件和二级调度框架通信时，如果某些框架总是拒绝资源供给，则只向二级调度框架发送符合资源要求的资源供给；所述撤销机制是指如果某个二级调度框架在一定时间内没有为分配的资源返回对应的容器任务，则要自动回收其资源量，并将这些资源分配给其他框架。

9.根据权利要求1所述的面向异构资源的多维调度系统，其特征在于，所述资源统调模块还包括：

集群资源监控组件，用于采集集群资源的监控信息；

容器沙盒，用于为容器资源隔离提供底层支撑；

容器执行器，用于与容器调度配合，容器调度指定具体的容器运行任务到计算节点，由容器执行器负责与容器后台服务通信，实现对容器的创建、停止、删除操作；

容器状态监控组件，用于采集主机上的容器状态监控信息；

高可用服务组件，用于为系统中有高可用要求的组件提供一致性服务。

Images