CN110493317B - 处理云平台资源碎片的方法及相关设备 - Google Patents

处理云平台资源碎片的方法及相关设备 Download PDF

Info

Publication number
CN110493317B
CN110493317B CN201910662073.XA CN201910662073A CN110493317B CN 110493317 B CN110493317 B CN 110493317B CN 201910662073 A CN201910662073 A CN 201910662073A CN 110493317 B CN110493317 B CN 110493317B
Authority
CN
China
Prior art keywords
resource
node
current
resource allocation
allocation rate
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201910662073.XA
Other languages
English (en)
Other versions
CN110493317A (zh
Inventor
陈新荃
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to CN201910662073.XA priority Critical patent/CN110493317B/zh
Publication of CN110493317A publication Critical patent/CN110493317A/zh
Application granted granted Critical
Publication of CN110493317B publication Critical patent/CN110493317B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1012—Server selection for load balancing based on compliance of requirements or conditions with available server resources

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本公开的实施例提供了一种处理云平台资源碎片的方法及相关设备，属于计算机和通信技术领域。所述云平台包括多个节点，各节点包括第一资源和第二资源；其中，所述方法包括：获取各节点的当前第一资源分配率和当前第二资源分配率；根据各节点的当前第一资源分配率和当前第二资源分配率，确定各节点当前处于资源平衡状态、第一资源失衡状态或者第二资源失衡状态其中之一；将处于第一资源失衡状态下的节点中导致第一资源分配失衡的存量寄主，迁移至处于第二资源失衡状态或者资源平衡状态下的节点中。本公开实施例的技术方案提供了处理云平台资源碎片的方法，能够有效地减少云平台的资源碎片，提高资源利用率。

Description

处理云平台资源碎片的方法及相关设备
技术领域
本公开涉及计算机和通信技术领域，具体而言，涉及一种处理云平台资源碎片的方法及相关设备。
背景技术
随着网络的发展，支撑大数据计算的人工智能云平台的使用越来越广泛，例如，人工智能云平台可以为多个作业同时提供运行资源，例如图形处理器GPU(GraphicsProcessing Unit)计算资源等。
但是，若云平台中的资源分配不平衡，会产生较多的资源碎片，从而导致剩余资源无法分配出去，降低了资源的利用率。
因此，需要一种新的处理云平台资源碎片的方法及相关设备。
需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。
发明内容
本公开实施例提供一种处理云平台资源碎片的方法及装置、推荐方法、计算机可读存储介质及电子设备，能够有效地减少云平台的资源碎片，提高资源利用率。
本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。
根据本公开的一个方面，提供一种处理云平台资源碎片的方法，所述云平台包括多个节点，各节点包括第一资源和第二资源；其中，所述方法包括：获取各节点的当前第一资源分配率和当前第二资源分配率；根据各节点的当前第一资源分配率和当前第二资源分配率，确定各节点当前处于资源平衡状态、第一资源失衡状态或者第二资源失衡状态其中之一；将处于第一资源失衡状态下的节点中导致第一资源分配失衡的存量寄主，迁移至处于第二资源失衡状态或者资源平衡状态下的节点中。
根据本公开的一个方面，提供一种处理云平台资源碎片的装置，所述云平台包括多个节点，各节点包括第一资源和第二资源；其中，所述装置包括：当前资源分配率获取单元，配置为获取各节点的当前第一资源分配率和当前第二资源分配率；当前资源分配状态确定单元，配置为根据各节点的当前第一资源分配率和当前第二资源分配率，确定各节点当前处于资源平衡状态、第一资源失衡状态或者第二资源失衡状态其中之一；存量寄主定向迁移单元，配置为将处于第一资源失衡状态下的节点中导致第一资源分配失衡的存量寄主，迁移至处于第二资源失衡状态或者资源平衡状态下的节点中。
根据本公开实施例的一方面，提供了一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时实现如上述实施例中所述的处理云平台资源碎片的方法。
根据本公开实施例的一方面，提供了一种电子设备，包括：一个或多个处理器；存储装置，配置为存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如上述实施例中所述的处理云平台资源碎片的方法。
在本公开的一些实施例所提供的技术方案中，云平台可以包括多个节点，各节点可以包括第一资源和第二资源，通过获取各节点的当前第一资源分配率和当前第二资源分配率，并根据各节点的当前第一资源分配率和当前第二资源分配率，确定各节点当前处于资源平衡状态、第一资源失衡状态或者第二资源失衡状态其中之一，从而可以将处于第一资源失衡状态下的节点中导致第一资源分配失衡的存量寄主，迁移至处于第二资源失衡状态或者资源平衡状态下的节点中。一方面，可以实现存量寄主的定向迁移，从而能够同时改善第一资源分配失衡和第二资源分配失衡的节点的资源分配平衡程度，降低因各节点的资源分配失衡而产生资源碎片，减少资源碎片，提高资源利用率；另一方面，利用定向迁移方式，在缓解云平台资源碎片的同时，可以减少存量寄主的迁移次数，提高迁移效率。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：
图1示出了可以应用本公开实施例的处理云平台资源碎片的方法或处理云平台资源碎片的装置的示例性系统架构的示意图；
图2示出了适于用来实现本公开实施例的电子设备的计算机系统的结构示意图；
图3示意性示出了根据本公开的一实施例的处理云平台资源碎片的方法的流程图；
图4示出了图3中所示的步骤S330在一实施例中的处理过程示意图；
图5示出了图4中所示的步骤S334在一实施例中的处理过程示意图；
图6示意性示出了根据本公开的一实施例的事先预防资源分配策略的示意图；
图7示意性示出了根据本公开的另一实施例的处理云平台资源碎片的方法的流程图；
图8示意性示出了根据本公开的一实施例的资源分配分类的示意图；
图9示意性示出了根据本公开的一实施例的资源分配平衡调度的示意图；
图10示出了图7中所示的步骤S730在一实施例中的处理过程示意图；
图11示出了图10中所示的步骤S733在一实施例中的处理过程示意图；
图12示出了图11中所示的步骤S7333在一实施例中的处理过程示意图；
图13示意性示出了根据本公开的一实施例的负载平衡调度的示意图；
图14示意性示出了根据本公开的又一实施例的处理云平台资源碎片的方法的流程图；
图15示意性示出了根据本公开的一实施例的处理云平台资源碎片的装置的框图；
图16示意性示出了根据本公开的另一实施例的处理云平台资源碎片的装置的框图。
具体实施方式
现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。
此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本公开的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而没有特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知方法、装置、实现或者操作以避免模糊本公开的各方面。
附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。
附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。
图1示出了可以应用本公开实施例的处理云平台资源碎片的方法或处理云平台资源碎片的装置的示例性系统架构100的示意图。
如图1所示，系统架构100可以包括终端设备101、102、103中的一种或多种，网络104和服务器105。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。
应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。比如服务器105可以是多个服务器组成的服务器集群等。
用户可以使用终端设备101、102、103通过网络104与服务器105交互，以接收或发送消息等。终端设备101、102、103可以是具有显示屏的各种电子设备，包括但不限于智能手机、平板电脑、便携式计算机和台式计算机、数字电影放映机等等。
服务器105可以是提供各种服务的服务器。例如用户利用终端设备103(也可以是终端设备101或102)向服务器105发送各种请求。服务器105可以基于该请求中携带的相关信息，获取响应于所述请求的反馈信息给终端设备103，进而用户可以在终端设备103上查看显示的反馈信息。
又如终端设备103(也可以是终端设备101或102)可以是智能电视、VR(VirtualReality，虚拟现实)/AR(Augmented Reality，增强现实)头盔显示器、或者其上安装有即时通讯、视频应用程序(application，APP)等的移动终端例如智能手机、平板电脑等，用户可以通过该智能电视、VR/AR头盔显示器或者该即时通讯、视频APP向服务器105发送各种请求。服务器105可以基于该请求，获取响应于所述请求的反馈信息返回给该智能电视、VR/AR头盔显示器或者该即时通讯、视频APP，进而通过该智能电视、VR/AR头盔显示器或者该即时通讯、视频APP将返回的反馈信息显示。
图2示出了适于用来实现本公开实施例的电子设备的计算机系统的结构示意图。
需要说明的是，图2示出的电子设备的计算机系统200仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。
如图2所示，计算机系统200包括中央处理单元(CPU，Central Processing Unit)201，其可以根据存储在只读存储器(ROM，Read-Only Memory)202中的程序或者从储存部分208加载到随机访问存储器(RAM，Random Access Memory)203中的程序而执行各种适当的动作和处理。在RAM 203中，还存储有系统操作所需的各种程序和数据。CPU 201、ROM 202以及RAM 203通过总线204彼此相连。输入/输出(I/O)接口205也连接至总线204。
以下部件连接至I/O接口205：包括键盘、鼠标等的输入部分206；包括诸如阴极射线管(CRT，Cathode Ray Tube)、液晶显示器(LCD，Liquid Crystal Display)等以及扬声器等的输出部分207；包括硬盘等的储存部分208；以及包括诸如LAN(Local Area Network，局域网)卡、调制解调器等的网络接口卡的通信部分209。通信部分209经由诸如因特网的网络执行通信处理。驱动器210也根据需要连接至I/O接口205。可拆卸介质211，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器210上，以便于从其上读出的计算机程序根据需要被安装入储存部分208。
特别地，根据本公开的实施例，下文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读存储介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分209从网络上被下载和安装，和/或从可拆卸介质211被安装。在该计算机程序被中央处理单元(CPU)201执行时，执行本申请的方法和/或装置中限定的各种功能。
需要说明的是，本公开所示的计算机可读存储介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM(Erasable Programmable Read Only Memory，可擦除可编程只读存储器)或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本公开中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读存储介质，该计算机可读存储介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读存储介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF(RadioFrequency，射频)等等，或者上述的任意合适的组合。
附图中的流程图和框图，图示了按照本公开各种实施例的方法、装置和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
描述于本公开实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现，所描述的单元也可以设置在处理器中。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定。
作为另一方面，本申请还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被一个该电子设备执行时，使得该电子设备实现如下述实施例中所述的方法。例如，所述的电子设备可以实现如图3或图4或图5或图7或图10或图11或图12或图14所示的各个步骤。
相关技术中，对云平台上的资源碎片产生问题采用的事先预防方式，主要分为两种：1、空闲优先，即将新增寄主优先部署到云平台上当前最空闲的节点上；2、饱和优先，即将新增寄主优先布满云平台上的某一节点。
图3示意性示出了根据本公开的一实施例的处理云平台资源碎片的方法的流程图。
本公开实施例中，所述云平台可以包括多个节点(node，这里也可以称之为宿主机)，若新增寄主是容器，则各个节点可以是物理机(例如，服务器)作为宿主机，也可以是虚拟机作为宿主机。其中，容器是一种轻量级、可移植、自包含的软件打包技术，使应用程序可以在几乎任何地方以相同的方式运行。若新增寄主是虚拟机，则各个节点可以是虚拟机作为宿主机。宿主机，是指容器所部署的物理机或虚拟机，或者虚拟机所部署的物理机，一个宿主机可部署多个容器或者多台虚拟机。云平台包含大量宿主机。
其中，各节点可以包括第一资源和第二资源，但本公开并不限定于此，各节点例如还可以包括第三资源，第四资源等各种资源，各种资源可以包括计算资源(例如CPU、GPU)、存储资源(例如内存、RAM、ROM、磁盘等)等。在下面的举例说明中，以第一资源为CPU，第二资源为内存为例进行举例说明，但本领域技术人员可以理解的是，本公开实施例提供的技术方案可以应用于任意其他的资源类型，且还可以拓展至三种或者以上种资源。
本公开实施例中，所述云平台还可以包括计算组件和寄主管理器，所述计算组件和/或所述寄主管理器可以用于执行本公开实施例提供的方法，例如所述计算组件接收新增寄主创建的请求，响应于该请求选择目标节点作为该新增寄主的宿主机，之后由所述寄主管理器来选择具体的目标节点执行创建操作。
本公开实施例中，资源碎片是指由于容器或者虚拟机部署不合理，导致宿主机中的资源例如CPU或内存资源无法继续分配给其它容器或者虚拟机，这些无法分配出去的资源即资源碎片。资源平衡是指宿主机的资源碎片较少，各类资源的分配率例如CPU分配率和内存分配率相差不大，即资源平衡，反之则失衡。
如图3所示，本公开实施例提供的处理云平台资源碎片的方法可以包括以下步骤。
在步骤S310中，获取各节点的当前第一资源分配率和当前第二资源分配率。
本公开实施例中，所述当前第一资源分配率是指节点上已经分配给其上部署的各个存量寄主的第一资源之和与该节点的整机具有的第一资源的比值。所述当前第二资源分配率是指节点上已经分配给其上部署的各个存量寄主的第二资源之和与该节点的整机具有的第二资源的比值。
例如，假设第一资源为CPU，第二资源为内存，则可以获取各个节点当前的CUP分配率和内存分配率。其中，对每个节点而言，其上已经部署了至少一个存量寄主(这里以容器为例)，每个存量容器已经分配到了固定大小的CPU资源(也称之为容器的CPU配额，即CPU时间片)和内存资源(也称之为容器的内存配额)，则对某个节点而言，其当前CPU分配率Utilcpu可以通过以下公式(1)计算获得：
Utilcpu＝该节点上已经部署的所有存量容器的CPU配额之和/该节点的整机CPU资源 (1)
类似的，对该节点而言，其当前内存分配率Utilmem可以通过以下公式(2)计算获得：
Utilmem＝该节点上已经部署的所有存量容器的内存配额之和/该节点的整机内存资源的比值 (2)
在步骤S320中，获取新增寄主所需的第一资源额度和第二资源额度。
例如，该新增寄主需要分配的CPU资源额度记为Limcpu和内存资源额度记为Limmem。
在步骤S330中，根据各节点的当前第一资源分配率和当前第二资源分配率以及所述第一资源额度和第二资源额度，确定目标节点。
例如，可以根据各节点当前的CPU分配率Utilcpu和内存分配率Utilmem查找出资源分配失衡的节点，再根据该新增寄主所需的CPU资源额度Limcpu和内存资源额度Limmem，假设将该新增寄主部署至某个资源分配失衡的节点上，会使得该节点的CPU分配率和内存分配率更加平衡(即两者更加相近)，则可以将该节点作为所述新增寄主的目标节点。
在示例性实施例中，所述方法还可以包括：获取各节点的当前第一资源余量和当前第二资源余量；根据各节点的当前第一资源余量、当前第二资源余量以及所述新增寄主所需的第一资源额度和第二资源额度，确定各节点中的候选节点。
本公开实施例中，所述当前第一资源余量是指节点整机具有的第一资源减去该节点已经分配给其上部署的各个存量寄主的第一资源之和。所述当前第二资源余量是指节点整机具有的第二资源减去该节点已经分配给其上部署的各个存量寄主的第二资源之和。
例如，假设第一资源为CPU，第二资源为内存，则可以获取各个节点当前的CUP余量和内存余量。其中，对每个节点而言，其上已经部署了至少一个存量寄主(这里以容器为例)，每个存量容器已经分配到了固定大小的CPU资源(也称之为容器的CPU配额，即CPU时间片)和内存资源(也称之为容器的内存配额)，则对某个节点而言，其当前CPU余量REScpu可以通过以下公式(3)计算获得：
REScpu＝该节点的整机CPU资源-该节点上已经部署的所有存量容器的CPU配额之和 (3)
类似的，对该节点而言，其当前内存余量RESmem可以通过以下公式(4)计算获得：
RESmem＝该节点的整机内存资源-该节点上已经部署的所有存量容器的内存配额之和 (4)
本公开实施例中，可以判断各节点的当前第一资源余量是否大于等于所述新增寄主所需的第一资源额度，并判断各节点的当前第二资源余量是否大于等于所述新增寄主所需的第二资源额度。若某个节点的当前第一资源余量大于等于所述新增寄主所需的第一资源额度，且该节点的当前第二资源余量大于等于所述新增寄主所需的第二资源额度，则可以判定该节点为候选节点。反之，若某个节点的当前第一资源余量小于所述新增寄主所需的第一资源额度，或者，该节点的当前第二资源余量小于所述新增寄主所需的第二资源额度，则可以判定该节点不为候选节点。
例如，若某个节点的CPU余量和内存余量均能满足新增寄主所需的CPU额度和内存额度，则可以认为这个节点对于所述新增寄主而言，是一个空闲资源足够的候选宿主机，可以将其作为所述新增寄主的候选节点。
在示例性实施例中，所述方法还可以包括：获取各候选节点的当前第一资源利用率；获取所述新增寄主的当前第一资源利用率；根据各候选节点的当前第一资源利用率和所述新增寄主的当前第一资源利用率，计算各候选节点的更新第一资源利用率；根据各候选节点的更新第一资源利用率，确定各候选节点中的目标候选节点。
例如，获得各候选节点的当前CPU利用率(也可以称之为当前负载)。可以从云平台获取所述新增寄主例如新增容器所在服务的当前CPU/内存利用率为其平均负载，将其作为所述新增容器的当前第一资源利用率。如果所述新增容器所在服务是新的服务，则可以将所述新增容器所需的第一资源额度作为所述当前第一资源利用率。其中，一个服务若包含了多个容器，则该服务的总的负载/该服务的容器数即为该服务的平均负载。这里可以预估将所述新增寄主部署到各个候选节点之后，各个候选节点的更新CPU利用率＝各个候选节点的当前CPU利用率+新增寄主的当前CPU利用率。若某个候选节点的更新CPU利用率超过设定的高负载阈值(例如，可以设定为70％，但本公开并不限定于此，可以根据实际需求进行调整)，则说明将该新增寄主部署到该候选节点上，会导致该后续节点出现高负载的情况，为了避免这种情况，将该候选节点排除掉。反之，若某个候选节点的更新CPU利用率未超过所述高负载阈值，则可以将该候选节点作为目标候选节点。需要说明的是，虽然下述举例说明中均以CPU利用率为例说明第一资源利用率，但本公开并不限定于此，例如还可以是内存利用率。
在步骤S340中，将所述新增寄主部署于所述目标节点。
例如，将新增容器部署于上述步骤中确定的目标节点作为其宿主机。
本公开实施方式提供的处理云平台资源碎片的方法，云平台可以包括多个节点，各节点可以包括第一资源和第二资源，通过获取各节点的当前第一资源分配率和当前第二资源分配率，并获取新增寄主所需的第一资源额度和第二资源额度，从而可以根据各节点的当前第一资源分配率和当前第二资源分配率以及所述第一资源额度和第二资源额度，确定目标节点，以实现将所述新增寄主部署于所述目标节点上。一方面，通过自动资源碎片处理，可以事先预防云平台因各节点的资源分配失衡而产生资源碎片，减少资源碎片，提高资源利用率；另一方面，在缓解云平台资源碎片的同时，可以提高各节点的资源分配平衡程度，节省资源。
图4示出了图3中所示的步骤S330在一实施例中的处理过程示意图。
如图4所示，本公开实施例中上述步骤S330可以进一步包括以下步骤。
在步骤S331中，根据各目标候选节点的当前第一资源分配率和当前第二资源分配率，获得各目标候选节点的当前资源失衡度。
本公开实施例中，所述当前资源失衡度是用于衡量节点上的各种资源的分配率之间的差异程度，若不同资源的分配率之间的差异越大，则当前资源失衡度越大，反之，若不同资源的分配率之间的差异越小，则当前资源失衡度越小。
例如，假设某个目标候选节点的当前第一资源分配率为CPU分配率记为Utilcpu，当前第二资源分配率为内存分配率记为Utilmem，则该目标候选节点的当前资源失衡度可以通过如下公式(5)计算获得：
Figure BDA0002138885000000121
在步骤S332中，根据所述第一资源额度和所述第二资源额度，计算各目标候选节点的更新第一资源分配率和更新第二资源分配率。
本公开实施例中，所述更新第一资源分配率是指假设将当前的新增寄主部署于目标候选节点上，则给该新增寄主分配所述第一资源额度和所述第二资源额度，根据该目标候选节点之前已经部署的存量寄主的第一资源配额之和、该目标候选节点的整机第一资源和所述第一资源额度计算所述更新第一资源分配率，以及根据该目标候选节点之前已经部署的存量寄主的第二资源配额之和、该目标候选节点的整机第二资源和所述第二资源额度计算所述更新第二资源分配率。
例如，假设该新增寄主所需的第一资源额度为CPU额度记为Limcpu，则对应的更新第一资源分配率为更新CPU分配率，更新第二资源分配率为更新内存分配率，第二资源额度为内存额度记为Limmem，并假设将其部署于上述目标候选节点上，则该目标候选节点的更新CPU分配率Util’cpu，可以通过以下公式(6)计算获得：
Util’cpu＝(该目标候选节点上已经部署的所有存量容器的CPU配额之和+Limcpu)/该目标候选节点的整机CPU资源 (6)
类似的，对该目标候选节点而言，其更新内存分配率Util’mem，可以通过以下公式(7)计算获得：
Util’mem＝(该目标候选节点上已经部署的所有存量容器的内存配额之和+Limmem)/该目标候选节点的整机内存资源的比值 (7)
在步骤S333中，根据目标候选各节点的更新第一资源分配率和更新第二资源分配率，计算各目标候选节点的更新资源失衡度。
例如，上述目标候选节点的更新资源失衡度可以通过以下公式(8)计算获得：
Figure BDA0002138885000000131
需要说明的是，计算各目标候选节点的当前资源失衡度、更新资源失衡度的方式并不限定于上述例举的公式，其只要满足以下条件即可：即目标候选节点的不同种类资源分配率之间的差异越大，则对应的资源失衡度越大即可。
在步骤S334中，根据各目标候选节点的当前资源失衡度和更新资源失衡度，确定所述目标节点。
这样，除了能够保证新增寄主部署后目标节点的资源分配平衡，还同时考虑了目标节点的运行负载情况，例如CPU利用率，以避免新增容器部署后目标节点出现高负载的情况。
图5示出了图4中所示的步骤S334在一实施例中的处理过程示意图。
如图5所示，本公开实施例中上述步骤S334可以进一步包括以下步骤。
在步骤S3341中，根据各目标候选节点的当前资源失衡度和更新资源失衡度获得各目标候选节点的资源失衡改善度。
例如，各目标候选节点的资源失衡改善度可以通过以下公式(9)计算获得：
资源失衡改善度＝|当前资源失衡度-更新资源失衡度| (9)
在步骤S3342中，将资源失衡改善度最大的目标候选节点作为所述新增寄主的目标节点。
本公开实施例中，云平台中同时包括多个节点(多台宿主机)，新增寄主例如新增容器在选择目标节点即目标宿主机时，可能同时存在多个目标候选节点能够改善其当前资源失衡度，此时，可以假设将该新增容器部署至每一个目标候选节点后，计算每个目标候选节点的更新资源分配率(例如可以包括更新第一资源分配率、更新第二资源分配率、更新第三资源分配率等)，根据每个目标候选节点的当前资源分配率(例如可以包括当前第一资源分配率、当前第二资源分配率、当前第三资源分配率等)计算出每个目标候选节点的资源失衡改善度，然后从中选择资源失衡改善度最大的那一个目标候选节点作为该新增寄主部署的宿主机。若同时存在多个目标候选节点的资源失衡改善度最大且相等，则可以从这多个目标候选节点中随机选择一个目标候选节点作为该新增寄主的目标节点。
图6示意性示出了根据本公开的一实施例的事先预防资源分配策略的示意图。
如图6所示，假设建立一个坐标系，原点为O，CPU分配率作为横坐标，内存分配率作为纵坐标，中间的斜线表示节点的CPU分配率和内存分配率相等，即资源分配处于平衡状态，称之为平衡线。其中，根据某个节点的当前CPU分配率和当前内存分配率确定其在坐标系上的点为A，当往该节点上部署一个新增容器后，如果使得该节点的新的CPU分配率和内存分配率坐标与平衡线之间的距离更近了(例如图中的A’点)，则表示若将该新增寄主分配至该节点上，会使得该节点的资源分配平衡有所缓解。反之，若将该新增寄主部署于该节点上后，如果使得该节点的新的CPU分配率和内存分配率坐标与平衡线之间的距离更远了(例如图中的A”点)，则表示若将该新增寄主分配至该节点上，会使得该节点的资源分配更加失衡。本公开实施例中优先选择能够缓解资源分配失衡的宿主机进行新增寄主例如新增容器的部署。
本公开实施例中，考虑了内存和CPU两个维度，在二维空间中计算点到平衡线y＝x(这里x横坐标代表CPU分配率，y纵坐标代表内存分配率)的距离，通过该距离作为衡量新增容器部署对节点的资源分配平衡效果的影响程度，例如各个点到平衡线的距离可以通过以下公式(10)计算：
Figure BDA0002138885000000151
上述公式中D(Utilcpu,Utilmem)表示坐标为(Utilcpu，Utilmem)的点到平衡线的距离。
在上述实施例中，当云平台中同时包括多台宿主机，新增容器在选择目标宿主机时，若同时能够缓解多台宿主机的资源分配失衡，则从中选择资源失衡改善最大的那个作为目标宿主机。但本公开并不限定于此，在其他实施例中，还可以对云平台中的假设n(n为大于1的正整数)台宿主机按顺序进行编号，假设分别为1至n，并分别获得每一台宿主机的当前CPU分配率和当前内存分配率；然后，根据新增容器所需的CPU额度和内存额度，逐一计算假设将该新增容器加入当前宿主机后，该当前宿主机新的CPU分配率和内存分配率，若第一次计算到该新增容器能够改善某一台宿主机的资源失衡度，则将该新增容器部署到该台宿主机。例如，通过计算可知，假设将新增容器部署到前2台宿主机会恶化其资源分配失衡情况，而部署到第3台宿主机会改善资源分配失衡情况，此时，就将新增容器部署到第3台宿主机。即不需要查找资源失衡改善度最大的节点作为目标宿主机，而只需要满足将该新增寄主分配至能够改善其资源失衡情况的节点即可，这样可以减少计算量。
下面举一个运用上述实施例的方法，进行云平台资源碎片事先预防的场景：
假设宿主机B的CPU总量为40核，内存总量为120GB，且为其上的存量容器已分配的CPU配额和内存配额之和分别为35核、60GB(即当前CPU和内存分配率分别为87.5％、50％)，由于剩余CPU太少导致宿主机B上有60GB的内存难以分配出去，产生内存资源碎片。此时如果有一个新增容器需要部署，需求的CPU和内存资源额度分别为1核、50GB内存，则通过本公开实施例提供的事先预防方式，该新增容器可以优先部署在宿主机B上，部署后宿主机B的更新CPU和内存分配率变为90％、91％，直接解决了宿主机B的资源碎片问题。对于CPU资源碎片也是类似的处理场景。
相关技术中的云平台资源碎片解决方法，大多只是事先预防或事后调整的单一策略。单一的事先预防策略只能控制新部署的容器或者虚拟机，然而云平台实际运行当中，随着多作业对云平台中资源的申请与释放，宿主机会因容器或者虚拟机的迁移或下线产生资源碎片，从而导致资源分配的性能下降或者无法分配，造成作业无法正常运行，使得云平台的资源使用率下降，单一的事先预防策略无法对云平台上宿主机中的存量寄主进行碎片调整。
此外，相关技术中的事后调整方法通过统计分析，直接将资源分配失衡节点上的容器或者虚拟机驱逐，由云平台的分配器选择其他节点重新部署该被驱逐的容器或者虚拟机，重新部署依赖空闲优先或者饱和优先算法，没有优先考虑资源分配失衡的节点之间的相互调整，调整效率较低。
图7示意性示出了根据本公开的另一实施例的处理云平台资源碎片的方法的流程图。
如图7所示，本公开实施例提供的处理云平台资源碎片的方法可以包括以下步骤。
在步骤S710中，获取各节点的当前第一资源分配率和当前第二资源分配率。
本公开实施例中步骤S710的内容可以参照上述步骤S310。
在步骤S720中，根据各节点的当前第一资源分配率和当前第二资源分配率，确定各节点当前处于资源平衡状态、第一资源失衡状态或者第二资源失衡状态其中之一。
在示例性实施例中，根据各节点的当前第一资源分配率(例如CPU分配率)和当前第二资源分配率(例如内存分配率)，确定各节点当前处于资源平衡状态(节点处于图8中的B区域)、第一资源失衡状态(节点处于图8中的C区域)或者第二资源失衡状态(节点处于图8中的M区域)，可以包括：归一化各节点的当前第一资源分配率和当前第二资源分配率；若归一化后的节点的当前第一资源分配率(例如Utilcpu)和当前第二资源分配率(例如Utilmem)与第一圆心(例如图8中的O1)或者第二圆心(例如图8中的O2)之间的距离大于等于第一半径(例如图8中的R0)，且其归一化后的当前第一资源分配率大于当前第二资源分配率；或者若归一化后的节点的当前第一资源分配率大于第二半径(例如图8中的(1-r0))，且其当前第二资源分配率小于所述第二半径；则判定所述节点当前处于第一资源失衡状态(例如CPU失衡状态)。
在示例性实施例中，根据各节点的当前第一资源分配率和当前第二资源分配率，确定各节点当前处于资源平衡状态、第一资源失衡状态或者第二资源失衡状态其中之一，还可以包括：若归一化后的节点的当前第一资源分配率和当前第二资源分配率与第一圆心或者第二圆心之间的距离大于等于所述第一半径，且其归一化后的当前第一资源分配率小于当前第二资源分配率；或者若归一化后的节点的当前第一资源分配率小于所述第二半径，且其当前第二资源分配率大于所述第二半径；则判定所述节点当前处于第二资源失衡状态(例如内存失衡状态)。
在步骤S730中，将处于第一资源失衡状态下的节点中导致第一资源分配失衡的存量寄主，迁移至处于第二资源失衡状态或者资源平衡状态下的节点中。
例如，可以将处于CPU失衡状态下的节点中导致该节点的CPU分配失衡的存量容器或者虚拟机，定向迁移至处于内存失衡状态下或者CPU和内存分配较为平衡状态下的节点。类似的，也可以将处于内存失衡状态下的节点中导致该节点的内存分配失衡的存量寄主，定向迁移至处于CPU失衡状态下或者CPU和内存分配较为平衡状态下的节点。通过存量寄主的定向迁移，可以同时改善CPU资源分配失衡和内存资源分配失衡的节点的资源分配平衡程度。
本公开实施方式提供的处理云平台资源碎片的方法，云平台可以包括多个节点，各节点可以包括第一资源和第二资源，通过获取各节点的当前第一资源分配率和当前第二资源分配率，并根据各节点的当前第一资源分配率和当前第二资源分配率，确定各节点当前处于资源平衡状态、第一资源失衡状态或者第二资源失衡状态其中之一，从而可以将处于第一资源失衡状态下的节点中导致第一资源分配失衡的存量寄主，迁移至处于第二资源失衡状态或者资源平衡状态下的节点中。一方面，可以实现存量寄主的定向迁移，从而能够同时改善第一资源分配失衡和第二资源分配失衡的节点的资源分配平衡程度，降低因各节点的资源分配失衡而产生资源碎片，减少资源碎片，提高资源利用率；另一方面，利用定向迁移方式，在缓解云平台资源碎片的同时，可以减少存量寄主的迁移次数，提高迁移效率。
图8示意性示出了根据本公开的一实施例的资源分配分类的示意图。
结合图8的图，对如何确定各节点当前处于何种状态进行分类判断。如图8所示，CPU分配率为横坐标，内存分配率为纵坐标，这里对各节点的CPU分配率和内存分配率均进行了归一化，即最外面的正方形的边长为1，以便于计算。
其中，图示中的r0是根据经验配置的常量值，用于判断CPU或者内存资源是否即将分配完，例如可以取r0＝0.05，则当某一资源的分配率高于(1-r0)例如0.95时，表示该资源的分配率较高。R0也是根据经验配置的常量值，例如可以取R0＝0.75，用于划定资源平衡的点的范围，图中竖线阴影区域与空白区域交界处的弧线表示以O1为圆心、以R0为半径的圆弧的一部分，图中斜线阴影区域与空白区域交界处的弧线表示以O2为圆心、以R0为半径的圆弧的一部分。其中，O1和O2圆心点，落在虚线正方形的对角线上，具体位置由R0决定。图中边长为1的正方形内，竖线阴影区域标记为M，空白区域标记为B，斜线阴影区域标记为C，边长为1的正方形的面积＝M+B+C。
本公开实施例中，在对资源分配失衡的宿主机进行调整前，需要对其失衡情况进行判定和分类。如图8所示，以CPU和内存分配率为坐标，可将宿主机的资源平衡情况分为3类，分类公式(11)如下：
Figure BDA0002138885000000181
其中，上述公式公式(11)中，假设节点P的坐标为(Utilcpu，Utilmem)，Od是指圆心点，如图中的O1和O2(需要说明的是，此处只取CPU和内存两个资源维度为例进行举例说明，因此只示出了2个圆心点，在更多资源维度的情况下，圆心点相应的增加)；d(P，Od)表示节点P与各个圆心点之间的距离；S(P)表示节点P的平衡分类结果，若结果为M，则表示节点P当前处于内存失衡状态，即节点P的坐标落在图中的M区域，有大量空闲的CPU碎片；若结果为C，则表示节点P当前处于CPU失衡状态，即节点P的坐标落在图中的C区域，有大量空闲的内存碎片；若结果为B，即节点P的坐标落在B区域，表示资源分配较为合理处于资源平衡状态，可以不调整其存量寄主。
图9示意性示出了根据本公开的一实施例的资源分配平衡调度的示意图。
本公开实施例中资源分配平衡调度如图9所示，可以将内存失衡节点中导致内存失衡的存量容器(或者存量虚拟机)定向迁移至CPU失衡节点(也可以迁移至处于资源平衡状态的节点上)。也可以将CPU失衡节点中导致CPU失衡的存量容器(或者存量虚拟机)定向迁移至内存失衡节点。最终目标是使云平台上的各个节点的资源分配率达到平衡状态，不会因为某一资源分完了，导致另一类资源因无法分出而产生浪费。
在示例性实施例中，所述方法还可以包括：获取新增寄主所需的第一资源额度和第二资源额度；根据各节点的当前第一资源分配率和当前第二资源分配率以及所述第一资源额度和第二资源额度，确定目标节点；将所述新增寄主部署于所述目标节点。
在示例性实施例中，根据各节点的当前第一资源分配率和当前第二资源分配率以及所述第一资源额度和第二资源额度，确定目标节点，可以包括：根据各节点的当前第一资源分配率和当前第二资源分配率，获得各节点的当前资源失衡度；根据所述第一资源额度和所述第二资源额度，计算各节点的更新第一资源分配率和更新第二资源分配率；根据各节点的更新第一资源分配率和更新第二资源分配率，计算各节点的更新资源失衡度；根据各节点的当前资源失衡度和更新资源失衡度，确定所述目标节点。
在示例性实施例中，根据各节点的当前资源失衡度和更新资源失衡度，确定所述目标节点，可以包括：根据各节点的当前资源失衡度和更新资源失衡度获得各节点的资源失衡改善度；将资源失衡改善度最大的节点作为所述新增寄主的目标节点。
本公开实施例提供的处理云平台资源的方法，可以同时包括事先预防(具体可以参照上述其他实施例)和事后调整两个环节，事先预防用于处理增量容器或者虚拟机(即新增寄主)，事后调整用于处理存量容器或者虚拟机。
图10示出了图7中所示的步骤S730在一实施例中的处理过程示意图。
如图10所示，本公开实施例中上述步骤S730可以进一步包括以下步骤。
在步骤S731中，计算处于第一资源失衡状态下的各节点的第一资源失衡度。
例如，为了对同一类(这里以同样处于CPU失衡状态下的各个节点为例)节点按照失衡程度区分出处理的优先级，可以计算出处于CPU失衡状态下的各个节点的第一资源失衡度。其中，计算公式可以参照上述实施例中的公式(1)。但本公开并不限定于此，只要能够满足以下条件即可：节点的不同资源之间的分配率差异越大，则资源失衡度越大，处理的优先级也就越高。
类似的，也可以计算出处于内存失衡状态下的各个节点的第二资源失衡度。
在步骤S732中，确定第一资源失衡度最大的第一资源节点。
例如，根据上述公式(1)，可以计算出处于CPU失衡状态下的各个节点的第一资源失衡度，然后按照各个节点的第一资源失衡度的大小进行降序排列或者升序排列，查找到第一资源失衡度最大的节点作为所述第一资源节点。
类似的，可以计算出处于内存失衡状态下的各个节点的第二资源失衡度，然后按照各个节点的第二资源失衡度的大小进行降序排列或者升序排列，查找到第二资源失衡度最大的节点作为第二资源节点。然后可以优先处理所述第一资源节点和所述第二资源节点。
在步骤S733中，将所述第一资源节点中导致第一资源分配失衡的存量寄主，迁移至处于第二资源失衡状态下的节点。
例如，可以优先将内存失衡最严重的节点中导致内存失衡的容器定向迁移至CPU失衡最严重的节点。类似的，也可以同时将CPU失衡最严重的节点中导致CPU失衡的容器定向迁移至内存失衡最严重的节点。
图11示出了图10中所示的步骤S733在一实施例中的处理过程示意图。
如图11所示，本公开实施例中上述步骤S733可以进一步包括以下步骤。
在步骤S7331中，若所述第一资源节点中的存量寄主的第一资源配额(例如CPU配额)与其第二资源配额(例如内存配额)的比值大于所述第一资源节点的当前第一资源分配率(例如当前CPU分配率)与其当前第二资源分配率(例如当前内存分配率)的比值，则判定所述存量寄主为导致所述第一资源节点的第一资源分配失衡的存量寄主。
例如，容器的CPU配额是指该容器部署至宿主机上后，其分配到的固定大小的CPU资源(即CPU时间片)；容器的内存配额是指其分配到的固定大小的内存资源。
在步骤S7332中，将所述第一资源节点中导致第一资源分配失衡的各存量寄主按照其第一资源配额进行降序排列。
在步骤S7333中，顺序遍历降序排列的各存量寄主，将各存量寄主迁移至处于第二资源失衡状态下的节点。
本公开实施例中，若云平台中同时存在多台内存失衡的宿主机和多台CPU失衡的宿主机，此时可以根据以下迁移方式来确定如何将失衡节点中的容器定向迁移至某一宿主机中：
第一步，按照第一资源失衡度从大到小的顺序对处于CPU失衡状态下的各个节点进行降序排列，逐个处理CPU失衡的节点。
第二步，当处理到某个节点K时，先对节点K上已经部署的存量容器(这里以容器为例，但本公开并不限定于此)进行排序。
例如，可以根据各个存量容器对节点K的CPU失衡的影响程度进行降序排列：按照节点K的各个存量容器分配到的CPU配额大到小排序，且同时满足(容器的CPU配额/容器的内存配额>节点K的CPU分配率/节点K的内存分配率)，即代表该容器是导致节点K内存失衡的容器。
第三步，对上述排序后的节点K的存量容器顺序遍历，尝试迁移到处于内存失衡状态下的节点上。
例如，可以按照第二资源失衡度从大到小对处于内存失衡状态下的各个节点进行降序排列，优先尝试将排序后的节点K的第一个存量容器迁移至第二资源节点；若第二资源节点迁移不成功，则可以继续尝试将排序后的节点K的第二个存量容器迁移至排序后的处于内存失衡状态下的第二个节点；以此类推，直至迁移成功。
第四步，若第一个存量容器迁移成功，则继续迁移排序后的节点K的下一个存量容器，下一个存量容器类似的从排序后的处于内存失衡状态的第二资源节点开始尝试迁移，直至下一个存量容器迁移成功。
第五步，循环执行上述第四步，直至节点K处于资源平衡状态，结束迁移节点K内的存量容器。
对于处于内存失衡状态下的各节点中导致内存失衡的各存量寄主，可以采用与上述类似的迁移方式进行存量寄主的定向迁移。
本公开实施方式提供的处理云平台资源碎片的方法，同时采取事先预防加事后调整策略，采用事先预防策略对新部署的容器或者虚拟机进行控制，采用事后调整策略对失衡节点中的存量容器或者虚拟机进行调整，其中事后调整策略可以包括3个主要的步骤：失衡分类(例如M，B，C三类)、失衡打分(例如上述的失衡度计算)和失衡调度，使云平台的各类资源分配总体趋向平衡。
下面举一个应用本公开实施例提供的事后处理策略调整存量宿主的场景：
假设宿主机D和E的CPU总量均为40核、内存总量均为120GB，其中宿主机D上已分配了10核CPU、100GB内存(CPU和内存分配率分别为25％、83％)，其中宿主机D上有个容器d占用了2核CPU、60GB内存；而宿主机E上已分配了30核CPU、10GB内存(CPU和内存分配率分别为75％、8.3％)。通过本公开实施例提供的事后处理策略，可以将宿主机D上的d容器定向迁移到宿主机E上，调整后两台宿主机的资源分配更加平衡，宿主机D的CPU和内存分配率变为(20％、33.3％)，宿主机E的CPU和内存分配率变为(80％、58％)。下面的实施例中，可以对宿主机运行负载进行类似的处理，将此处的分配率换为利用率。
相关技术中采用的事先预防策略，仅考虑了宿主机的资源分配情况，没有考虑宿主机的运行负载情况。本公开实施例中，平衡调度可以包括资源分配平衡调度和负载平衡调度。本公开实施例中，负载是指宿主机的CPU利用率。
图12示出了图11中所示的步骤S7333在一实施例中的处理过程示意图。
如图12所示，本公开实施例中上述步骤S7333可以进一步包括以下步骤。
在步骤S73331中，获取降序排列的各存量寄主的第一资源利用率。
本公开实施例中，还是以上述节点K为例，获取上述根据第一资源配额进行降序排列的各存量寄主的CPU利用率。
其中，以容器为例，可以通过以下公式(12)计算容器的CPU利用率：
容器的CPU利用率(负载)＝该容器实际使用的CPU时间片/该容器的CPU配额(12)
其中，该容器的CPU配额是指该容器实际上分配到的CPU时间片。
在步骤S73332中，若存量寄主的第一资源利用率低于第一阈值，则将所述存量寄主迁移至处于第二资源失衡状态下且第一资源利用率大于等于第二阈值的节点。
例如，所述第一阈值可以取值为20％(这里仅用于举例说明，本公开并不限定于此)，若某个存量容器分配了固定的CPU配额，但实际没怎么使用，CPU利用率例如低于20％，说明该存量容器是低负载或者低CPU利用率。此时，可以将这个低负载的存量容器定向迁移至高负载或者负载均衡的节点。
具体的，所述第二阈值也可以取值为20％(这里仅用于举例说明，且其可以与第一阈值相等，也可以与第一阈值不相等，本公开并不限定于此)。其中，节点的CPU利用率可以利用下述公式(13)计算获得：
节点的CPU利用率(负载)＝该节点上所有存量寄主实际使用的CPU时间片之和/该节点的整机CPU资源 (13)
若某个节点的CPU利用率高于20％，则可以判定其为高负载或者负载均衡的节点。
继续参加图12，还可以包括：在步骤S73333中，若存量寄主的第一资源利用率大于第三阈值，则将所述存量寄主迁移至处于第二资源失衡状态下且第一资源利用率大于等于第四阈值的节点。
其中，所述第一阈值可以小于所述第三阈值(例如70％，这里仅用于举例说明，本公开并不限定于此)，所述第二阈值可以小于所述第四阈值(例如70％，这里仅用于举例说明，本公开并不限定于此)。需要说明的是，所述第三阈值可以与所述第四阈值相等，也可以不相等。
例如，若节点K上的某个容器的CPU利用率大于70％，则说明该容器把分配给其的CPU配额使用的比较满，可以判定该容器为高负载或者高CPU利用率的容器。可以将该高负载容器定向迁移至低负载或者负载均衡的节点(例如，节点的CPU利用率小于等于20％)。
本公开实施方式提供的处理云平台资源碎片的方法，同时采用了事先预防加事后调整的策略来解决宿主机的资源碎片问题，有效缓解了资源碎片；其中，事先预防策略即通过云平台的分配器选择新增寄主部署的目标宿主机时，对备选的宿主机进行失衡改善度的排序，优先部署到资源分配失衡的宿主机上；事后调整策略即通过分析云平台所有宿主机的资源碎片情况，针对失衡宿主机进行存量寄主互迁，事后调整有针对性，调整效率高，快速优化碎片问题。此外，在事后调整策略中不仅考虑了宿主机的资源分配情况，还综合考虑了其运行负载，缓解宿主机运行负载平衡。
图13示意性示出了根据本公开的一实施例的负载平衡调度的示意图。
本公开实施例中，负载平衡调度如图13所示，虽然在资源分配平衡调度中考虑了负载因素，但即使资源分配平衡了，节点仍然有可能是低负载或者高负载，负载平衡主要关注节点的CPU利用率，因此负载平衡调度的主要策略，可以将低负载节点中导致低CPU利用率的容器定向迁移至高负载/正常负载的节点上。也可以将高负载节点中导致高CPU利用率的容器定向迁移至低负载/正常负载的节点上。
本公开实施例中，若云平台中同时存在多台低负载的宿主机和多台高负载的宿主机，此时可以根据以下迁移方式来确定如何将低负载节点中的容器定向迁移至某一宿主机中：
第一步，计算出各节点的CPU利用率，根据各节点的CPU利用率将其划分至以下三类中的任一一种：低负载节点(例如，该节点的CPU利用率低于20％)、正常负载节点(例如，该节点的CPU利用率大于等于20％且小于等于70％)和高负载节点(例如，该节点的CPU利用率大于70％)。将低负载的各个节点按照各自的CPU利用率从小到大进行排序，即CPU利用率最低的节点排在第一位；将高负载的各个节点按照各自的CPU利用率从大到小进行排序，即CPU利用率最高的节点排在第一位。对排序后的第一个低负载节点优先处理，或者对排序后的第一个高负载节点优先处理，之后按顺序进行遍历，即优先处理负载失衡最严重的节点。
第二步，当处理到某个低负载节点K时，先对低负载节点K上已经部署的存量容器(这里以容器为例，但本公开并不限定于此)进行排序。
例如，可以根据各个存量容器对低负载节点K的负载失衡的影响程度进行升序排列：按照低负载节点K的各个存量容器的CPU利用率从小到大排序，且同时满足容器的CPU利用率小于节点K的CPU利用率，即代表该容器是低负载节点K内导致其负载失衡的低负载容器。
若处理到某个高负载节点Q时，先对高负载节点Q上已经部署的存量容器(这里以容器为例，但本公开并不限定于此)进行排序。
例如，可以根据各个存量容器对高负载节点Q的负载失衡的影响程度进行降序排列：按照高负载节点Q的各个存量容器的CPU利用率从大到小排序，且同时满足容器的CPU利用率大于节点Q的CPU利用率，即代表该容器是高负载节点Q内导致其负载失衡的高负载容器。
第三步，对上述排序后的低负载节点K的存量容器顺序遍历，尝试迁移到处于高负载节点上。
例如，可以优先尝试将排序后的低负载节点K的第一个存量容器迁移至排序后的第一个高负载节点；若第一次迁移不成功，则可以继续尝试将排序后的低负载节点K的第二个存量容器迁移至排序后的第二个高负载节点；以此类推，直至迁移成功。
类似的，对上述排序后的高负载节点Q的存量容器顺序遍历，尝试迁移到处于低负载节点上。
第四步，若排序后的低负载节点K中的第一个存量容器迁移成功，则继续迁移排序后的节点K的下一个存量容器，下一个存量容器类似的从排序后的第一个高负载节点开始尝试迁移，直至下一个存量容器迁移成功。
第五步，循环执行上述第四步，直至低负载节点K处于负载平衡状态，结束迁移节点K内的存量容器。
本公开实施例中，为了减少迁移次数，避免迁移导致其它维度指标失衡，节点迁移需要同时满足以下条件：
(1)优先迁移影响程度最大的节点。
这里是指，在资源平衡调度过程中，优先处理资源分配失衡程度最大的节点，优先迁移资源分配失衡的节点中对该资源分配失衡影响程度最大的存量寄主。在负载平衡调度过程中，优先处理负载失衡程度最大的节点，优先迁移负载失衡的节点中对该负载失衡影响程度最大的存量寄主。
例如，首先计算获得失衡度分数(可以是资源失衡度，也可以是负载失衡度)最高的第一宿主机，然后，再分析该第一宿主机中导致资源或者负载失衡的各个容器对失衡度分数的影响程度，优先将影响程度最大的容器迁走；然后再将该第一宿主机中的影响程度其次的容器迁走，直至把第一宿主机中所有对失衡度分数有影响的全部容器迁走。接着，再对失衡度分数第二高的第二宿主机中的各个容器进行类似的处理，以此类推，直至达到负载和资源平衡。
(2)迁出节点低负载时，优先迁走CPU利用率低的节点。
若同一宿主机中存在多个容器导致资源失衡，且这多个容器对资源失衡的影响程度相同，同时该宿主机是低负载，则优先迁走该宿主机中的CPU利用率最低的容器。
(3)迁入节点低负载时，不能迁入CPU利用率低的节点。
例如，在进行资源分配平衡调度时，虽然可以将导致内存失衡的容器迁入CPU失衡的宿主机，但若是该导致内存失衡的容器是低负载的，同时被迁入的宿主机也是低负载，则不能将该容器迁入该低负载的宿主机。
(4)不能导致迁入的节点资源分配失衡/高负载/低负载，或迁出节点资源分配失衡/高负载/低负载。
本公开实施方式提供的处理云平台资源碎片的方法，通过自动资源碎片处理，可以预防并处理云平台的资源碎片问题。一方面，可以缓解云平台因宿主机资源分配失衡导致的文件碎片问题，提高宿主机的资源分配率，节省资源；另一方面，可以维护云平台宿主机的负载，避免出现部分宿主机高负载/低负载的现象，从而维持云平台的稳定运作。
图14示意性示出了根据本公开的又一实施例的处理云平台资源碎片的方法的流程图。所述云平台可以包括多个节点，各节点可以包括第一资源和第二资源。
如图14所示，本公开实施例提供的处理云平台资源碎片的方法可以包括以下步骤。
在步骤S1410中，获取各节点的当前第一资源分配率和当前第二资源分配率。
在步骤S1420中，根据各节点的当前第一资源分配率和当前第二资源分配率，确定各节点当前处于资源平衡状态、第一资源失衡状态或者第二资源失衡状态其中之一。
在示例性实施例中，根据各节点的当前第一资源分配率和当前第二资源分配率，确定各节点当前处于资源平衡状态、第一资源失衡状态或者第二资源失衡状态其中之一，可以包括：归一化各节点的当前第一资源分配率和当前第二资源分配率；若归一化后的节点的当前第一资源分配率和当前第二资源分配率与第一圆心或者第二圆心之间的距离大于等于第一半径，且其归一化后的当前第一资源分配率大于当前第二资源分配率；或者若归一化后的节点的当前第一资源分配率大于第二半径，且其当前第二资源分配率小于所述第二半径；则判定所述节点当前处于第一资源失衡状态。
在示例性实施例中，根据各节点的当前第一资源分配率和当前第二资源分配率，确定各节点当前处于资源平衡状态、第一资源失衡状态或者第二资源失衡状态其中之一，还可以包括：若归一化后的节点的当前第一资源分配率和当前第二资源分配率与第一圆心或者第二圆心之间的距离大于等于所述第一半径，且其归一化后的当前第一资源分配率小于当前第二资源分配率；或者若归一化后的节点的当前第一资源分配率小于所述第二半径，且其当前第二资源分配率大于所述第二半径；则判定所述节点当前处于第二资源失衡状态。
在步骤S1430中，将处于第一资源失衡状态下的节点中导致第一资源分配失衡的存量寄主，迁移至处于第二资源失衡状态或者资源平衡状态下的节点中。
在示例性实施例中，将处于第一资源失衡状态下的节点中导致第一资源分配失衡的存量寄主，迁移至处于第二资源失衡状态或者资源平衡状态下的节点中，可以包括：计算处于第一资源失衡状态下的各节点的第一资源失衡度；确定第一资源失衡度最大的第一资源节点；将所述第一资源节点中导致第一资源分配失衡的存量寄主，迁移至处于第二资源失衡状态下的节点。
在示例性实施例中，将所述第一资源节点中导致第一资源分配失衡的存量寄主，迁移至处于第二资源失衡状态下的节点，可以包括：若所述第一资源节点中的存量寄主的第一资源配额与其第二资源配额的比值大于所述第一资源节点的当前第一资源分配率与其当前第二资源分配率的比值，则判定所述存量寄主为导致所述第一资源节点的第一资源分配失衡的存量寄主；将所述第一资源节点中导致第一资源分配失衡的各存量寄主按照其第一资源配额进行降序排列；顺序遍历降序排列的各存量寄主，将各存量寄主迁移至处于第二资源失衡状态下的节点。
本公开实施例中的具体实现可以参照上述实施例。
本公开实施方式提供的处理云平台资源碎片的方法，对云平台上的各个节点的资源分配情况进行事后调整，其针对资源失衡的节点进行点对点的存量寄主调度，实现资源失衡宿主机之间的存量寄主定向迁移和相互迁移，事后调整针对性强，调整效率高，用尽量少的迁移次数实现宿主机的资源分配平衡。
在示例性实施例中，顺序遍历降序排列的各存量寄主，将各存量寄主迁移至处于第二资源失衡状态下的节点，可以包括：获取降序排列的各存量寄主的第一资源利用率；若存量寄主的第一资源利用率低于第一阈值，则将所述存量寄主迁移至处于第二资源失衡状态下且第一资源利用率大于等于第二阈值的节点。
在示例性实施例中，顺序遍历降序排列的各存量寄主，将各存量寄主迁移至处于第二资源失衡状态下的节点，还可以包括：若存量寄主的第一资源利用率大于第三阈值，则将所述存量寄主迁移至处于第二资源失衡状态下且第一资源利用率大于等于第四阈值的节点；其中，所述第一阈值小于所述第三阈值，所述第二阈值小于所述第四阈值。
本公开实施方式提供的处理云平台资源碎片的方法，宿主机平衡考虑维度更多：同时考虑了宿主机的资源分配情况和负载情况，优化了云平台资源使用效率。
图15示意性示出了根据本公开的一实施例的处理云平台资源碎片的装置的框图。所述云平台可以包括多个节点，各节点可以包括第一资源和第二资源。
如图15所示，本公开实施方式提供的处理云平台资源碎片的装置1500可以包括：当前资源分配率获取单元1510、新增资源额度获取单元1520、目标节点确定单元1530以及新增寄主部署单元1540。
其中，当前资源分配率获取单元1510可以配置为获取各节点的当前第一资源分配率和当前第二资源分配率。新增资源额度获取单元1520可以配置为获取新增寄主所需的第一资源额度和第二资源额度。目标节点确定单元1530可以配置为根据各节点的当前第一资源分配率和当前第二资源分配率以及所述第一资源额度和第二资源额度，确定目标节点。新增寄主部署单元1540可以配置为将所述新增寄主部署于所述目标节点。
在示例性实施例中，处理云平台资源碎片的装置1500还可以包括：资源余量获取单元，可以配置为获取各节点的当前第一资源余量和当前第二资源余量；候选节点确定单元，可以配置为根据各节点的当前第一资源余量、当前第二资源余量以及所述新增寄主所需的第一资源额度和第二资源额度，确定各节点中的候选节点。
在示例性实施例中，处理云平台资源碎片的装置1500还可以包括：节点当前负载获取单元，可以配置为获取各候选节点的当前第一资源利用率；寄主当前负载获取单元，可以配置为获取所述新增寄主的当前第一资源利用率；节点更新负载获取单元，可以配置为根据各候选节点的当前第一资源利用率和所述新增寄主的当前第一资源利用率，计算各候选节点的更新第一资源利用率；目标候选节点确定单元，可以配置为根据各候选节点的更新第一资源利用率，确定各候选节点中的目标候选节点。
在示例性实施例中，目标节点确定单元1530可以包括：当前资源失衡度获得单元，可以配置为根据各目标候选节点的当前第一资源分配率和当前第二资源分配率，获得各目标候选节点的当前资源失衡度；更新资源分配率计算单元，可以配置为根据所述第一资源额度和所述第二资源额度，计算各目标候选节点的更新第一资源分配率和更新第二资源分配率；更新资源失衡度计算单元，可以配置为根据各目标候选节点的更新第一资源分配率和更新第二资源分配率，计算各目标候选节点的更新资源失衡度。目标节点确定单元1530可以配置为根据各目标候选节点的当前资源失衡度和更新资源失衡度，确定所述目标节点。
在示例性实施例中，目标节点确定单元1530还可以配置为：根据各目标候选节点的当前资源失衡度和更新资源失衡度获得各目标候选节点的资源失衡改善度；将资源失衡改善度最大的目标候选节点作为所述新增寄主的目标节点。
在示例性实施例中，处理云平台资源碎片的装置1500还可以包括：节点资源分配状态确定单元，可以配置为根据各节点的当前第一资源分配率和当前第二资源分配率，确定各节点当前处于资源平衡状态、第一资源失衡状态或者第二资源失衡状态其中之一；存量寄主定向迁移单元，可以配置为将处于第一资源失衡状态下的节点中导致第一资源分配失衡的存量寄主，迁移至处于第二资源失衡状态或者资源平衡状态下的节点中。
在示例性实施例中，所述存量寄主定向迁移单元可以包括：第一资源失衡度计算单元，可以配置为计算处于第一资源失衡状态下的各节点的第一资源失衡度；第一资源节点确定单元，可以配置为确定第一资源失衡度最大的第一资源节点。所述存量寄主定向迁移单元可以配置为将所述第一资源节点中导致第一资源分配失衡的存量寄主，迁移至处于第二资源失衡状态下的节点。
在示例性实施例中，所述存量寄主定向迁移单元还可以包括：存量寄主判定单元，可以配置为若所述第一资源节点中的存量寄主的第一资源配额与其第二资源配额的比值大于所述第一资源节点的当前第一资源分配率与其当前第二资源分配率的比值，则判定所述存量寄主为导致所述第一资源节点的第一资源分配失衡的存量寄主；存量寄主排列单元，可以配置为将所述第一资源节点中导致第一资源分配失衡的各存量寄主按照其第一资源配额进行降序排列；存量寄主依序迁移单元，可以配置为顺序遍历降序排列的各存量寄主，将各存量寄主迁移至处于第二资源失衡状态下的节点。
在示例性实施例中，所述存量寄主依序迁移单元可以包括：第一资源利用率获取单元，可以配置为获取降序排列的各存量寄主的第一资源利用率；存量寄主平衡调度单元，可以配置为若存量寄主的第一资源利用率低于第一阈值，则将所述存量寄主迁移至处于第二资源失衡状态下且第一资源利用率大于等于第二阈值的节点。
在示例性实施例中，所述存量寄主依序迁移单元还可以包括：存量寄主均衡调度单元，可以配置为若存量寄主的第一资源利用率大于第三阈值，则将所述存量寄主迁移至处于第二资源失衡状态下且第一资源利用率大于等于第四阈值的节点。其中，所述第一阈值小于所述第三阈值，所述第二阈值小于所述第四阈值。
本公开实施例提供的处理云平台资源碎片的装置中的各个单元的具体实现可以参照上述处理云平台资源碎片的方法中的内容，在此不再赘述。
图16示意性示出了根据本公开的另一实施例的处理云平台资源碎片的装置的框图。所述云平台可以包括多个节点，各节点可以包括第一资源和第二资源。
如图16所示，本公开实施方式提供的处理云平台资源碎片的装置1600可以包括：当前资源分配率获取单元1610、当前资源分配状态确定单元1620以及存量寄主定向迁移单元1630。
其中，当前资源分配率获取单元1610可以配置为获取各节点的当前第一资源分配率和当前第二资源分配率。当前资源分配状态确定单元1620可以配置为根据各节点的当前第一资源分配率和当前第二资源分配率，确定各节点当前处于资源平衡状态、第一资源失衡状态或者第二资源失衡状态其中之一。存量寄主定向迁移单元1630可以配置为将处于第一资源失衡状态下的节点中导致第一资源分配失衡的存量寄主，迁移至处于第二资源失衡状态或者资源平衡状态下的节点中。
在示例性实施例中，当前资源分配状态确定单元1620可以包括：资源分配率归一化单元，可以配置为归一化各节点的当前第一资源分配率和当前第二资源分配率；第一资源失衡状态判定单元，可以配置为若归一化后的节点的当前第一资源分配率和当前第二资源分配率与第一圆心或者第二圆心之间的距离大于等于第一半径，且其归一化后的当前第一资源分配率大于当前第二资源分配率；或者若归一化后的节点的当前第一资源分配率大于第二半径，且其当前第二资源分配率小于所述第二半径；则判定所述节点当前处于第一资源失衡状态。
在示例性实施例中，当前资源分配状态确定单元1620还可以包括：第二资源失衡状态判定单元，可以配置为若归一化后的节点的当前第一资源分配率和当前第二资源分配率与第一圆心或者第二圆心之间的距离大于等于所述第一半径，且其归一化后的当前第一资源分配率小于当前第二资源分配率；或者若归一化后的节点的当前第一资源分配率小于所述第二半径，且其当前第二资源分配率大于所述第二半径；则判定所述节点当前处于第二资源失衡状态。
在示例性实施例中，存量寄主定向迁移单元1630包括：第一资源失衡度计算单元，可以配置为计算处于第一资源失衡状态下的各节点的第一资源失衡度；第一资源节点确定单元，可以配置为确定第一资源失衡度最大的第一资源节点。存量寄主定向迁移单元1630可以配置为将所述第一资源节点中导致第一资源分配失衡的存量寄主，迁移至处于第二资源失衡状态下的节点。
在示例性实施例中，存量寄主定向迁移单元1630还可以包括：存量寄主判定单元，可以配置为若所述第一资源节点中的存量寄主的第一资源配额与其第二资源配额的比值大于所述第一资源节点的当前第一资源分配率与其当前第二资源分配率的比值，则判定所述存量寄主为导致所述第一资源节点的第一资源分配失衡的存量寄主；存量寄主排列单元，可以配置为将所述第一资源节点中导致第一资源分配失衡的各存量寄主按照其第一资源配额进行降序排列；存量寄主依序迁移单元，可以配置为顺序遍历降序排列的各存量寄主，将各存量寄主迁移至处于第二资源失衡状态下的节点。
在示例性实施例中，所述存量寄主依序迁移单元可以包括：第一资源利用率获取单元，可以配置为获取降序排列的各存量寄主的第一资源利用率；存量寄主平衡调度单元，可以配置为若存量寄主的第一资源利用率低于第一阈值，则将所述存量寄主迁移至处于第二资源失衡状态下且第一资源利用率大于等于第二阈值的节点。
在示例性实施例中，所述存量寄主依序迁移单元还可以包括：存量寄主均衡调度单元，可以配置为若存量寄主的第一资源利用率大于第三阈值，则将所述存量寄主迁移至处于第二资源失衡状态下且第一资源利用率大于等于第四阈值的节点。其中，所述第一阈值小于所述第三阈值，所述第二阈值小于所述第四阈值。
在示例性实施例中，处理云平台资源碎片的装置1600还可以包括：新增资源额度获取单元，可以配置为获取新增寄主所需的第一资源额度和第二资源额度；目标节点确定单元可以配置为根据各节点的当前第一资源分配率和当前第二资源分配率以及所述第一资源额度和第二资源额度，确定目标节点；新增寄主部署单元，可以配置为将所述新增寄主部署于所述目标节点。
在示例性实施例中，所述目标节点确定单元可以包括：当前资源失衡度获得单元，可以配置为根据各节点的当前第一资源分配率和当前第二资源分配率，获得各节点的当前资源失衡度；更新资源分配率计算单元，可以配置为根据所述第一资源额度和所述第二资源额度，计算各节点的更新第一资源分配率和更新第二资源分配率；更新资源失衡度计算单元，可以配置为根据各节点的更新第一资源分配率和更新第二资源分配率，计算各节点的更新资源失衡度。所述目标节点确定单元可以进一步配置为根据各节点的当前资源失衡度和更新资源失衡度，确定所述目标节点。
在示例性实施例中，所述目标节点确定单元还可以配置为：根据各节点的当前资源失衡度和更新资源失衡度获得各节点的资源失衡改善度；将资源失衡改善度最大的节点作为所述新增寄主的目标节点。
本公开实施例提供的处理云平台资源碎片的装置中的各个单元的具体实现可以参照上述处理云平台资源碎片的方法中的内容，在此不再赘述。
应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多单元的特征和功能可以在一个单元中具体化。反之，上文描述的一个单元的特征和功能可以进一步划分为由多个单元来具体化。
通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、触控终端、或者网络设备等)执行根据本公开实施方式的方法。
本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。
应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

Claims (20)

1.一种处理云平台资源碎片的方法，其特征在于，所述云平台包括多个节点，各节点包括第一资源和第二资源；其中，所述方法包括：
获取各节点的当前第一资源分配率和当前第二资源分配率；
根据各节点的当前第一资源分配率和当前第二资源分配率，确定各节点当前处于资源平衡状态、第一资源失衡状态或者第二资源失衡状态其中之一；
将处于第一资源失衡状态下的节点中导致第一资源分配失衡的存量寄主，迁移至处于第二资源失衡状态或者资源平衡状态下的节点中，其中处于第一资源失衡状态下的节点中存量寄主的第一资源配额与其第二资源配额的比值大于对应节点的当前第一资源分配率与其当前第二资源分配率的比值的存量寄主为导致对应节点的第一资源分配失衡的存量寄主；
其中，根据各节点的当前第一资源分配率和当前第二资源分配率，确定各节点当前处于资源平衡状态、第一资源失衡状态或者第二资源失衡状态其中之一，包括：
归一化各节点的当前第一资源分配率和当前第二资源分配率，归一化后的节点的当前第一资源分配率为横坐标，归一化后的节点的当前第二资源分配率为纵坐标，形成边长为1的正方形；
若归一化后的节点的当前第一资源分配率和当前第二资源分配率与第一圆心O1或者第二圆心O2之间的距离大于等于第一半径R0，且其归一化后的当前第一资源分配率大于当前第二资源分配率，第一圆心O1的横坐标和纵坐标分别为(R0,1-R0)，第二圆心O2的横坐标和纵坐标分别为(1-R0，R0)，R0是用于划定资源平衡的点的范围；或者
若归一化后的节点的当前第一资源分配率大于第二半径(1-r0)，且其当前第二资源分配率小于所述第二半径；
则判定所述节点当前处于第一资源失衡状态。
2.根据权利要求1所述的方法，其特征在于，根据各节点的当前第一资源分配率和当前第二资源分配率，确定各节点当前处于资源平衡状态、第一资源失衡状态或者第二资源失衡状态其中之一，还包括：
若归一化后的节点的当前第一资源分配率和当前第二资源分配率与第一圆心或者第二圆心之间的距离大于等于所述第一半径，且其归一化后的当前第一资源分配率小于当前第二资源分配率；或者
若归一化后的节点的当前第一资源分配率小于所述第二半径，且其当前第二资源分配率大于所述第二半径；
则判定所述节点当前处于第二资源失衡状态。
3.根据权利要求1所述的方法，其特征在于，将处于第一资源失衡状态下的节点中导致第一资源分配失衡的存量寄主，迁移至处于第二资源失衡状态或者资源平衡状态下的节点中，包括：
计算处于第一资源失衡状态下的各节点的第一资源失衡度；
确定第一资源失衡度最大的第一资源节点；
将所述第一资源节点中导致第一资源分配失衡的存量寄主，迁移至处于第二资源失衡状态下的节点。
4.根据权利要求3所述的方法，其特征在于，将所述第一资源节点中导致第一资源分配失衡的存量寄主，迁移至处于第二资源失衡状态下的节点，包括：
若所述第一资源节点中的存量寄主的第一资源配额与其第二资源配额的比值大于所述第一资源节点的当前第一资源分配率与其当前第二资源分配率的比值，则判定所述存量寄主为导致所述第一资源节点的第一资源分配失衡的存量寄主；
将所述第一资源节点中导致第一资源分配失衡的各存量寄主按照其第一资源配额进行降序排列；
顺序遍历降序排列的各存量寄主，将各存量寄主迁移至处于第二资源失衡状态下的节点。
5.根据权利要求4所述的方法，其特征在于，顺序遍历降序排列的各存量寄主，将各存量寄主迁移至处于第二资源失衡状态下的节点，包括：
获取降序排列的各存量寄主的第一资源利用率；
若存量寄主的第一资源利用率低于第一阈值，则将所述存量寄主迁移至处于第二资源失衡状态下且第一资源利用率大于等于第二阈值的节点。
6.根据权利要求5所述的方法，其特征在于，顺序遍历降序排列的各存量寄主，将各存量寄主迁移至处于第二资源失衡状态下的节点，还包括：
若存量寄主的第一资源利用率大于第三阈值，则将所述存量寄主迁移至处于第二资源失衡状态下且第一资源利用率大于等于第四阈值的节点；
其中，所述第一阈值小于所述第三阈值，所述第二阈值小于所述第四阈值。
7.根据权利要求1所述的方法，其特征在于，还包括：
获取新增寄主所需的第一资源额度和第二资源额度；
根据各节点的当前第一资源分配率和当前第二资源分配率以及所述第一资源额度和第二资源额度，确定目标节点；
将所述新增寄主部署于所述目标节点。
8.根据权利要求7所述的方法，其特征在于，根据各节点的当前第一资源分配率和当前第二资源分配率以及所述第一资源额度和第二资源额度，确定目标节点，包括：
根据各节点的当前第一资源分配率和当前第二资源分配率，获得各节点的当前资源失衡度；
根据所述第一资源额度和所述第二资源额度，计算各节点的更新第一资源分配率和更新第二资源分配率；
根据各节点的更新第一资源分配率和更新第二资源分配率，计算各节点的更新资源失衡度；
根据各节点的当前资源失衡度和更新资源失衡度，确定所述目标节点。
9.根据权利要求8所述的方法，其特征在于，根据各节点的当前资源失衡度和更新资源失衡度，确定所述目标节点，包括：
根据各节点的当前资源失衡度和更新资源失衡度获得各节点的资源失衡改善度；
将资源失衡改善度最大的节点作为所述新增寄主的目标节点。
10.一种处理云平台资源碎片的装置，其特征在于，所述云平台包括多个节点，各节点包括第一资源和第二资源；其中，所述装置包括：
当前资源分配率获取单元，配置为获取各节点的当前第一资源分配率和当前第二资源分配率；
当前资源分配状态确定单元，配置为根据各节点的当前第一资源分配率和当前第二资源分配率，确定各节点当前处于资源平衡状态、第一资源失衡状态或者第二资源失衡状态其中之一；
存量寄主定向迁移单元，配置为将处于第一资源失衡状态下的节点中导致第一资源分配失衡的存量寄主，迁移至处于第二资源失衡状态或者资源平衡状态下的节点中，其中处于第一资源失衡状态下的节点中存量寄主的第一资源配额与其第二资源配额的比值大于对应节点的当前第一资源分配率与其当前第二资源分配率的比值的存量寄主为导致对应节点的第一资源分配失衡的存量寄主；
其中，所述当前资源分配状态确定单元包括：
资源分配率归一化单元，配置为归一化各节点的当前第一资源分配率和当前第二资源分配率，归一化后的节点的当前第一资源分配率为横坐标，归一化后的节点的当前第二资源分配率为纵坐标，形成边长为1的正方形；
第一资源失衡状态判定单元，配置为若归一化后的节点的当前第一资源分配率和当前第二资源分配率与第一圆心O1或者第二圆心O2之间的距离大于等于第一半径R0，且其归一化后的当前第一资源分配率大于当前第二资源分配率，第一圆心O1的横坐标和纵坐标分别为(R0,1-R0)，第二圆心O2的横坐标和纵坐标分别为(1-R0，R0)，R0是用于划定资源平衡的点的范围；或者，若归一化后的节点的当前第一资源分配率大于第二半径(1-r0)，且其当前第二资源分配率小于所述第二半径，则判定所述节点当前处于第一资源失衡状态。
11.根据权利要求10所述的装置，其特征在于，所述当前资源分配状态确定单元还包括：
第二资源失衡状态判定单元，配置为若归一化后的节点的当前第一资源分配率和当前第二资源分配率与第一圆心或者第二圆心之间的距离大于等于所述第一半径，且其归一化后的当前第一资源分配率小于当前第二资源分配率；或者，若归一化后的节点的当前第一资源分配率小于所述第二半径，且其当前第二资源分配率大于所述第二半径，则判定所述节点当前处于第二资源失衡状态。
12.根据权利要求10所述的装置，其特征在于，所述存量寄主定向迁移单元包括：
第一资源失衡度计算单元，配置为计算处于第一资源失衡状态下的各节点的第一资源失衡度；
第一资源节点确定单元，配置为确定第一资源失衡度最大的第一资源节点；
存量寄主定向迁移单元，配置为将所述第一资源节点中导致第一资源分配失衡的存量寄主，迁移至处于第二资源失衡状态下的节点。
13.根据权利要求12所述的装置，其特征在于，所述存量寄主定向迁移单元还包括：
存量寄主判定单元，配置为若所述第一资源节点中的存量寄主的第一资源配额与其第二资源配额的比值大于所述第一资源节点的当前第一资源分配率与其当前第二资源分配率的比值，则判定所述存量寄主为导致所述第一资源节点的第一资源分配失衡的存量寄主；
存量寄主排列单元，配置为将所述第一资源节点中导致第一资源分配失衡的各存量寄主按照其第一资源配额进行降序排列；
存量寄主依序迁移单元，配置为顺序遍历降序排列的各存量寄主，将各存量寄主迁移至处于第二资源失衡状态下的节点。
14.根据权利要求13所述的装置，其特征在于，所述存量寄主依序迁移单元包括：
第一资源利用率获取单元，配置为获取降序排列的各存量寄主的第一资源利用率；
存量寄主平衡调度单元，配置为若存量寄主的第一资源利用率低于第一阈值，则将所述存量寄主迁移至处于第二资源失衡状态下且第一资源利用率大于等于第二阈值的节点。
15.根据权利要求14所述的装置，其特征在于，所述存量寄主依序迁移单元还包括：
存量寄主均衡调度单元，配置为若存量寄主的第一资源利用率大于第三阈值，则将所述存量寄主迁移至处于第二资源失衡状态下且第一资源利用率大于等于第四阈值的节点；
其中，所述第一阈值小于所述第三阈值，所述第二阈值小于所述第四阈值。
16.根据权利要求10所述的装置，其特征在于，还包括：
新增资源额度获取单元，配置为获取新增寄主所需的第一资源额度和第二资源额度；
目标节点确定单元，配置为根据各节点的当前第一资源分配率和当前第二资源分配率以及所述第一资源额度和第二资源额度，确定目标节点；
新增寄主部署单元，配置为将所述新增寄主部署于所述目标节点。
17.根据权利要求16所述的装置，其特征在于，所述目标节点确定单元包括：
当前资源失衡度获得单元，配置为根据各节点的当前第一资源分配率和当前第二资源分配率，获得各节点的当前资源失衡度；
更新资源分配率计算单元，配置为根据所述第一资源额度和所述第二资源额度，计算各节点的更新第一资源分配率和更新第二资源分配率；
更新资源失衡度计算单元，配置为根据各节点的更新第一资源分配率和更新第二资源分配率，计算各节点的更新资源失衡度；
所述目标节点确定单元配置为根据各节点的当前资源失衡度和更新资源失衡度，确定所述目标节点。
18.根据权利要求17所述的装置，其特征在于，所述目标节点确定单元还配置为：根据各节点的当前资源失衡度和更新资源失衡度获得各节点的资源失衡改善度；将资源失衡改善度最大的节点作为所述新增寄主的目标节点。
19.一种电子设备，其特征在于，包括：
一个或多个处理器；
存储装置，配置为存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如权利要求1至9中任一项所述的处理云平台资源碎片的方法。
20.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至9中任一项所述的处理云平台资源碎片的方法。
CN201910662073.XA 2019-07-22 2019-07-22 处理云平台资源碎片的方法及相关设备 Active CN110493317B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910662073.XA CN110493317B (zh) 2019-07-22 2019-07-22 处理云平台资源碎片的方法及相关设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910662073.XA CN110493317B (zh) 2019-07-22 2019-07-22 处理云平台资源碎片的方法及相关设备

Publications (2)

Publication Number Publication Date
CN110493317A CN110493317A (zh) 2019-11-22
CN110493317B true CN110493317B (zh) 2022-04-19

Family

ID=68547862

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910662073.XA Active CN110493317B (zh) 2019-07-22 2019-07-22 处理云平台资源碎片的方法及相关设备

Country Status (1)

Country Link
CN (1) CN110493317B (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110474966B (zh) 2019-07-22 2022-04-19 腾讯科技（深圳）有限公司 处理云平台资源碎片的方法及相关设备
CN112559130B (zh) * 2020-12-16 2024-01-19 恒生电子股份有限公司 容器分配方法、装置、电子设备及存储介质
LU500944B1 (en) * 2021-12-02 2023-06-02 Microsoft Technology Licensing Llc Automated recovery of stranded resources within a cloud computing environment

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106293871A (zh) * 2016-07-22 2017-01-04 浪潮(北京)电子信息产业有限公司 一种集群虚拟机的资源调度方法
CN108710540A (zh) * 2018-05-23 2018-10-26 深信服网络科技（深圳）有限公司 一种分布式集群中的资源调度方法、装置及设备
CN109117269A (zh) * 2018-07-26 2019-01-01 郑州云海信息技术有限公司 一种分布式系统虚拟机调度方法、装置和可读存储介质
CN109213555A (zh) * 2018-08-16 2019-01-15 北京交通大学 一种面向虚拟桌面云的资源动态调度方法

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9021497B1 (en) * 2013-11-07 2015-04-28 International Business Machines Corporation Adjusting pause-loop exiting window values

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106293871A (zh) * 2016-07-22 2017-01-04 浪潮(北京)电子信息产业有限公司 一种集群虚拟机的资源调度方法
CN108710540A (zh) * 2018-05-23 2018-10-26 深信服网络科技（深圳）有限公司 一种分布式集群中的资源调度方法、装置及设备
CN109117269A (zh) * 2018-07-26 2019-01-01 郑州云海信息技术有限公司 一种分布式系统虚拟机调度方法、装置和可读存储介质
CN109213555A (zh) * 2018-08-16 2019-01-15 北京交通大学 一种面向虚拟桌面云的资源动态调度方法

Also Published As

Publication number Publication date
CN110493317A (zh) 2019-11-22

Similar Documents

Publication Publication Date Title
CN110474966B (zh) 处理云平台资源碎片的方法及相关设备
US11429449B2 (en) Method for fast scheduling for balanced resource allocation in distributed and collaborative container platform environment
CN111966500B (zh) 资源调度方法、装置、电子设备及存储介质
US9442763B2 (en) Resource allocation method and resource management platform
CN110493317B (zh) 处理云平台资源碎片的方法及相关设备
CN107832143B (zh) 一种物理机资源的处理方法和装置
WO2017020742A1 (zh) 负载均衡方法及设备
CN102970379A (zh) 在多个服务器之间实现负载均衡的方法
EP4242843A1 (en) Graphics card memory management method and apparatus, device, and system
US20220075665A1 (en) Scheduling method for selecting optimal cluster within cluster of distributed collaboration type
CN112181613A (zh) 异构资源分布式计算平台批量任务调度方法及存储介质
CN110233866B (zh) 一种负载均衡方法及负载均衡器
CN112860383A (zh) 集群资源调度方法、装置、设备及存储介质
CN114625500A (zh) 云环境下拓扑感知的微服务应用调度的方法及应用
CN111381957A (zh) 面向分布式平台的服务实例精细化调度方法及系统
CN110167031B (zh) 一种面向集中式基站的资源分配方法、设备及存储介质
US20230379268A1 (en) Resource scheduling method and system, electronic device, computer readable storage medium
Patel et al. A survey on load balancing in cloud computing
CN107491352B (zh) 一种资源调度方法及装置
CN114116173A (zh) 动态调整任务分配的方法、装置和系统
US20210149745A1 (en) Method for balanced scale out of resources in distributed and collaborative container platform environment
CN116737370A (zh) 一种多资源调度方法、系统、存储介质及终端
CN116360994A (zh) 分布式异构资源池的调度方法、装置、服务器及存储介质
CN111143059A (zh) 改进的Kubernetes资源调度方法
CN109558214A (zh) 异构环境下宿主机资源管理方法、装置和存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 40016168

Country of ref document: HK

SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant