WO2020119060A1 - 容器资源调度方法和系统、服务器及计算机可读存储介质 - Google Patents

容器资源调度方法和系统、服务器及计算机可读存储介质 Download PDF

Info

Publication number
WO2020119060A1
WO2020119060A1 PCT/CN2019/092457 CN2019092457W WO2020119060A1 WO 2020119060 A1 WO2020119060 A1 WO 2020119060A1 CN 2019092457 W CN2019092457 W CN 2019092457W WO 2020119060 A1 WO2020119060 A1 WO 2020119060A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
shared computing
task
scheduling
data
Prior art date
Application number
PCT/CN2019/092457
Other languages
English (en)
French (fr)
Inventor
雷鸿
Original Assignee
深圳市网心科技有限公司
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 深圳市网心科技有限公司 filed Critical 深圳市网心科技有限公司
Publication of WO2020119060A1 publication Critical patent/WO2020119060A1/zh

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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • 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/5061—Partitioning or combining of resources
    • G06F9/5066—Algorithms for mapping a plurality of inter-dependent sub-tasks onto a plurality of physical CPUs
    • 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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing

Definitions

  • the present application relates to the field of shared computing technology, and in particular, to a container resource scheduling method and system, a server, and a computer-readable storage medium.
  • Resource nodes are distributed in various places on the public network, and can only be connected to the system server through the public network.
  • the connection is unstable, resulting in poor system control of the node, that is, the node does not perform as expected.
  • the traditional service cluster and scheduling cluster are in the same computer room. If the computer room is abnormal, the traffic needs to be migrated as a whole. In a shared computing system based on distributed nodes, a single machine room failure only affects the dispatch service cluster. The dispatch cluster needs to support multi-machine room disaster recovery to ensure the availability of overall services.
  • the present application proposes a container resource scheduling method and system, a server, and a computer-readable storage medium to solve at least one of the above technical problems.
  • this application proposes a container resource scheduling method, which is applied to a server, and the method includes:
  • the real-time status data of the node includes the currently available bandwidth, storage space, and computing resources of the shared computing node, the status of the currently executed task, and the data generated by executing the task.
  • the node management information includes node basic information and online and offline management information of each of the shared computing nodes; the task management information includes maintenance information of resource requirements, attributes, and status of the shared computing task.
  • the node and service portrait data includes a node portrait, a service quality portrait, and a combined service quality portrait
  • the node portrait is a complete attribute state of each shared computing node obtained through historical data analysis
  • the service quality portrait is a correlation analysis of service quality and node attributes, and by inputting specific tasks and node attributes, the service quality performance of the tasks at the nodes is estimated;
  • the combined service quality portrait is an analysis of the service quality of different task combinations and the service quality of task combinations on different nodes.
  • calculating the node allocation result corresponding to the shared computing task based on the node management information, task management information, node real-time status data, and node and service profile data includes at least one calculation according to the following calculation modes
  • the node allocation results corresponding to the shared computing task are output: real-time scheduling algorithm, global scheduling optimization algorithm, and experimental scheduling group algorithm;
  • the real-time scheduling algorithm is to preliminarily determine an optional shared computing node based on the node management information, and then for each optional shared computing node, the node real-time status data and the resource requirements of the shared computing task, increment Calculate the distribution result according to the greedy algorithm;
  • the global scheduling optimization algorithm is based on the global shared computing task resource requirements and the real-time state data of the nodes of all shared computing nodes, as well as the node and service profile data, to perform global optimal scheduling calculation, that is All the shared computing tasks in the world are allocated the optimal computing shared computing nodes respectively;
  • the experimental scheduling group algorithm selects multiple non-optimal shared computing nodes for task assignment randomly or according to preset rules, so that there are various dimensions of combined data in the data warehouse.
  • the server is deployed in the Redis Cluster mode in multiple computer rooms, one of the computer rooms is a host room, and the data in the host room is synchronized to the other computer rooms, when the host room fails , Switch to one of the other machine rooms for container resource scheduling service.
  • the present application further provides a server, the server includes a memory and a processor, and the memory stores a container resource scheduler that can run on the processor, and the container resource scheduler When executed by the processor, the container resource scheduling method as described above is implemented.
  • the server is deployed in the Redis Cluster mode in multiple computer rooms, one of the computer rooms is a host room, and the data in the host room is synchronized to the other computer rooms, when the host room fails , Switch to one of the other servers in the machine room for container resource scheduling service.
  • the present application also provides a container resource scheduling system, the system includes:
  • Data warehouse used to receive and store real-time status data of nodes uploaded by shared computing nodes
  • a scheduling calculation unit configured to obtain node management information of each of the shared computing nodes and task management information of the shared computing tasks to be allocated;
  • a scheduling analysis unit for analyzing and obtaining node and service profile data from the data warehouse through data mining technology for use by the scheduling calculation unit;
  • the scheduling calculation unit is further configured to calculate the node allocation result corresponding to the shared calculation task based on the node management information, task management information, real-time status data of the node, and node and service portrait data;
  • the scheduling and delivering unit is configured to deliver the shared computing task to the corresponding shared computing node according to the node allocation result.
  • the present application also provides a computer-readable storage medium, the computer-readable storage medium stores a container resource scheduler, and the container resource scheduler may be executed by at least one processor to enable The at least one processor executes the container resource scheduling method as described above.
  • the container resource scheduling method, system, server and computer-readable storage medium proposed in this application can support the scheduling of millions or even tens of millions of nodes.
  • the node portrait, Service quality portraits and combined service quality portraits provide more accurate and diverse selection space for container resource scheduling, and on this basis, further scheduling is conducted with the goal of revenue, not just resource selection.
  • the present application explores and gradually approaches a better scheduling state while ensuring service timeliness through multiple scheduling calculation modes.
  • deploying core scheduling units in multiple computer rooms through Redis Cluster mode can support multi-computer room disaster tolerance, as well as system state fault tolerance and fault recovery.
  • FIG. 1 is a schematic diagram of an optional application environment of each embodiment of the present application.
  • FIG. 2 is a schematic structural diagram of a server proposed in the first embodiment of the present application.
  • FIG. 3 is a schematic flowchart of a container resource scheduling method according to the second embodiment of the present application.
  • FIG. 4 is a functional module diagram of a container resource scheduling system proposed in a third embodiment of the present application.
  • FIG. 1 is a schematic diagram of an optional application environment in each embodiment of the present application.
  • the present application can be applied to a shared computing system 1.
  • the above-mentioned shared computing system 1 includes at least a server 2 and a shared computing node 4 (there are multiple, only one is shown as a representative in the figure).
  • the server 2 may be a computing device such as a rack server, a blade server, a tower server, or a rack server.
  • the server 2 may be an independent server or a server cluster composed of multiple servers.
  • the server 2 is used to calculate the node allocation result corresponding to the shared computing task based on the node management information, task management information, node real-time status data, node and service profile data, and deliver the shared computing task to the corresponding share according to the allocation result Compute node 4.
  • the shared computing node 4 is used to perform the assigned tasks and upload the real-time status data of the node to the server 2. Among them, each shared computing node 4 reports the node real-time status data of the node in a triggered manner (when the status changes) or periodically.
  • the above-mentioned server 2 delivers tasks to the corresponding shared computing node 4 and the process of uploading real-time status data to the shared computing node 4 can be called by a remote procedure between the signaling gateway (not shown in the figure) and the shared computing node 4 ( Remote connection protocol (RPC) protocol and hypertext transfer protocol (HyperTextTransferProtocol, HTTP) based on the establishment of long connection bidirectional signaling transmission channel for transmission.
  • RPC Remote connection protocol
  • HTTP hypertext transfer protocol
  • server 2 can be deployed in Redis Cluster mode in multiple computer rooms (generally 2-3), but only one computer room is used as the host room for scheduling services, and the data such as the calculation results of the host room are all Will be synchronized to all Redis Cluster clusters (server 2 in other computer rooms).
  • server 2 in other computer rooms.
  • the main engine room fails, switch to one of the new computer rooms for dispatching services, and rely on the data and server 2 of the new computer room for calculation and delivery.
  • the first embodiment of the present application proposes a server 2.
  • the server 2 includes a memory 21, a processor 23, a network interface 25 and a communication bus 27.
  • the network interface 25 may optionally include a standard wired interface and a wireless interface (such as a WI-FI interface).
  • the communication bus 27 is used to realize connection communication between these components.
  • the memory 21 includes at least one type of readable storage medium.
  • the at least one type of readable storage medium described above may be a non-volatile storage medium such as flash memory, hard disk, multimedia card, card-type memory, or the like.
  • the above-mentioned memory 21 may be an internal storage unit of the server 2, such as the hard disk of the server 2.
  • the memory 21 may also be an external storage unit of the server 2, such as a plug-in hard disk equipped on the server 2, a smart memory card (Smart, Media, Card, SMC), and secure digital (SD) Cards, flash cards, etc.
  • the above-mentioned memory 21 may be used to store application software installed on the server 2 and various types of data, such as the program code of the container resource scheduling program 20 and related data generated during its operation.
  • the processor 23 may be a central processing unit, a microprocessor, or other data processing chip, which is used to run program codes or process data stored in the memory 21.
  • FIG. 2 only shows the server 2 with the components 21-27 and the container resource scheduler 20, but it should be understood that FIG. 2 does not show all the components of the server 2, and more or fewer components may be implemented instead.
  • the second embodiment of the present application proposes a container resource scheduling method, which is applied to the server 2 described above.
  • the execution order of the steps in the flowchart shown in FIG. 3 may be changed, and some steps may be omitted.
  • the method includes:
  • each shared computing node 4 needs to upload the real-time status data of the node to the server 2.
  • the above-mentioned real-time status data of the node includes the currently available bandwidth, storage space, and computing resources of the shared computing node 4, the status of the currently executed task, and the data generated by executing the task.
  • each shared computing node 4 reports the node real-time status data of the node in a triggered manner (when the status changes) or periodically.
  • the node management information of each shared computing node 4 may be obtained from the node manager (which may be located in the server 2 or another server of the shared computing system 1, not shown in FIG. 1), and from the task manager (It may be located in the server 2 or in another server of the shared computing system 1, not shown in FIG. 1) to obtain task management information of the shared computing task to be distributed.
  • the node management information refers to the node basic information and online and offline management information of each shared computing node 4.
  • the above basic information of the node includes the node ID, the region to which it belongs, ISP (Internet Service Provider), NAT (Network Address Translation) type, etc.
  • the online and offline management information includes that the shared computing node 4 is currently online or offline.
  • Task management information refers to maintenance information of resource requirements, attributes, and status of shared computing tasks.
  • the above resource requirements include bandwidth requirements, storage space requirements, and computing resource requirements.
  • the above-mentioned node and service portrait data includes a node portrait, a service quality portrait, and a combined service quality portrait.
  • the node portrait is the complete attribute status of each shared computing node 4 obtained through historical data analysis, such as average online rate and average upstream bandwidth.
  • the service quality portrait is a correlation analysis of service quality and node attributes. By inputting specific tasks (or task features) and node attributes, the service quality performance of the task at the node is estimated. For example, on a Beijing Telecom node with a Nat type of 5 and a disk capacity of 10G, it is estimated that the upstream traffic can reach 2Mbps.
  • the combined service quality portrait is an analysis of the service quality of different task combinations and the service quality of task combinations on different nodes.
  • the above-mentioned node and service profile data can be pre-analyzed from the data warehouse through data mining technology for subsequent scheduling when the shared computing tasks are allocated.
  • the above analysis can be processed by using some existing commonly used data mining techniques, which will not be repeated here.
  • S40 Calculate the node allocation result corresponding to the shared computing task based on the node management information, task management information, node real-time status data, and node and service profile data.
  • the real-time scheduling algorithm is to preliminarily determine the optional shared computing node 4 based on the node management information (for example, based on the region, operator, and whether it is currently online), and then for each optional shared computing node 4 current node real-time status data and The resource requirements of the shared computing task incrementally calculate the node allocation results according to the greedy algorithm.
  • the above-mentioned greedy algorithm refers to selecting the shared computing node 4 with the highest rate of return (revenue/cost) when the filtering conditions are met.
  • the above-mentioned revenue and cost can be settled according to the corresponding business expenses and reward fees to the nodes.
  • the global scheduling optimization algorithm is to calculate the optimal solution for the global according to the global shared computing task resource requirements and the real-time status data of all shared computing nodes 4, as well as the node and service profile data, that is, to allocate all tasks globally Optimal solution of shared computing node 4.
  • the purpose of the above global scheduling optimization algorithm includes: assisting in evaluating and optimizing the real-time scheduling algorithm; and gradually adjusting the global scheduling state according to the results of the global optimization.
  • the experimental scheduling group algorithm selects multiple non-optimal shared computing nodes 4 for task assignment randomly or according to preset rules to ensure that there are enough combined data of various dimensions in the data warehouse.
  • the shared computing node 4 executes the assigned task and uploads the real-time status data of the node.
  • the process of sending the shared computing task to the corresponding shared computing node 4 and the shared computing node 4 to upload real-time status data can be through a long connection between the signaling gateway and the shared computing node 4 based on the RPC protocol and the HTTP protocol. Two-way signaling transmission channel for transmission.
  • the above server 2 can be deployed in Redis Cluster mode in multiple computer rooms (generally 2-3), but only one computer room is used as the host room for scheduling services, and the data such as the calculation results of the host room will be Synchronize to all Redis Cluster. When the main computer room fails, switch to one of the new computer rooms for dispatching services, so as to achieve multi-computer room disaster recovery.
  • the container resource scheduling method provided in this embodiment can support the scheduling of millions or even tens of millions of nodes.
  • the node portrait, service quality portrait, and combined service quality portrait are analyzed to provide more accurate container resource scheduling Diversified choice space, and on this basis, further scheduling with the goal of income, not just resource selection.
  • this method explores and gradually approaches a better scheduling state while ensuring service timeliness through multiple scheduling calculation modes.
  • deploying core scheduling services in multiple computer rooms through Redis Cluster mode can support multi-computer room disaster tolerance, as well as system state fault tolerance and fault recovery.
  • the third embodiment of the present application proposes a container resource scheduling system 200, which is applied to the server 2 described above.
  • the container resource scheduling system 200 includes a data warehouse 202, a scheduling calculation unit 204, a scheduling analysis unit 206, and a scheduling delivery unit 208.
  • the data warehouse 202 is used to receive and store the real-time status data of the nodes uploaded by the shared computing node 4.
  • the scheduling calculation unit 204 is used to acquire the node management information of each shared computing node 4 and the task management information of the shared computing task to be allocated.
  • the scheduling analysis unit 206 is used to obtain node and service profile data from the data warehouse 202 through data mining technology, which is used by the scheduling calculation unit 204.
  • the scheduling calculation unit 204 is also used to calculate the node allocation result corresponding to the shared computing task based on the node management information, task management information, real-time status data of the node, and the node and service profile data.
  • the scheduling and delivering unit 208 is configured to deliver the shared computing task to the corresponding shared computing node 4 according to the above allocation result.
  • the above data warehouse 202, scheduling calculation unit 204, scheduling analysis unit 206, and scheduling delivery unit 208 are core scheduling units of the container resource scheduling system 200, and may be located in one or more servers (for example, server 2).
  • the above-mentioned core scheduling unit can be deployed in multiple computer rooms (generally 2-3) using Redis Cluster mode, but only one computer room is used as a host room for scheduling services, and the data such as the calculation results of the host room are all Will be synchronized to all Redis Cluster (the core scheduling unit of other computer rooms).
  • the main engine room fails, switch to one of the new computer rooms for scheduling services, and rely on the data and core scheduling unit of the new computer room for calculation and delivery.
  • the present application also provides another implementation manner, that is, to provide a computer-readable storage medium that stores a container resource scheduling program 20 that can be executed by at least one processor to Causing the at least one processor to execute the container resource scheduling method as described above.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

本申请公开了一种容器资源调度方法，该方法包括：接收各个共享计算节点上传的节点实时状态数据；获取各个共享计算节点的节点管理信息和待分配的共享计算任务的任务管理信息；获取预先分析得到的节点与服务画像数据；根据所述节点管理信息、任务管理信息、节点实时状态数据、节点与服务画像数据计算出所述共享计算任务对应的节点分配结果；根据所述节点分配结果将所述共享计算任务下发至对应的共享计算节点。本申请还提供一种容器资源调度系统、服务器及计算机可读存储介质。本申请能够对基于分布式节点的共享计算体系进行容器的管理和调度。

Description

容器资源调度方法和系统、服务器及计算机可读存储介质
本申请基于巴黎公约申明享有2018年12月14日递交的申请号为CN201811532786.6、名称为“容器资源调度方法和系统、服务器及计算机可读存储介质”的中国专利申请的优先权，该中国专利申请的整体内容以参考的方式结合在本申请中。
技术领域
本申请涉及共享计算技术领域，尤其涉及一种容器资源调度方法和系统、服务器及计算机可读存储介质。
背景技术
目前，越来越多数据中心将基础设施容器化，并实现运维自动化、快速部署应用、弹性伸缩等功能。容器编排系统也越来越成熟，能够支持上千级别的服务器的管理以及不同的调度策略。
但是，当前的容器编排系统很难对基于分布式节点的共享计算体系进行容器的管理和调度，主要存在下列问题：
(1)资源节点分布在公网的各个地方，与系统服务器也只能通过公网连接，连接不稳定，导致系统对节点的控制力较差，即节点不按照调度预期进行执行。
(2)节点规模庞大，对于数据的维护，任务状态同步都有不小的压力。
(3)节点的服务能力(例如每个节点的可用上下行带宽、节点的在线时长等)存在不确定性。
(4)服务质量存在不确定性：对于一个特定的任务，不同的节点会有差距较大的服务质量，例如地理位置的因素、节点所在网络的网络地址转换类型等均会对服务质量造成影响。
(5)任务组合的互相影响：当一个节点分配多个任务时，任务之间如果存在较强的资源竞争关系，会导致任务无法正常提供服务，甚至降低整个节点的使用效率。即使进行资源隔离，对于不同的节点和不同的任务组合，怎么样的隔离配置才是合理的，也很难确定。而且，共享计算节点的能力一般 较差，很难做到理想化的隔离效果。
(6)在基于分布式节点的共享计算体系中，如何用更少的节点(成本)满足更多的任务需求(收入)是调度的核心目标。对应的调度要求是：在节点维度，选择合适的任务或合适的任务组合，让节点资源的使用效率尽可能高；在全局维度，不断优化节点任务的组合方式，求取最大的收益。
(7)传统的服务集群和调度集群都在相同的机房，如果机房异常，需要将流量整体迁移。而在基于分布式节点的共享计算体系中，单个机房故障只影响调度服务集群，调度集群需要支持多机房容灾，去保证整体服务的可用。
发明内容
有鉴于此，本申请提出一种容器资源调度方法和系统、服务器及计算机可读存储介质，以解决至少一个上述技术问题。
首先，为实现上述目的，本申请提出一种容器资源调度方法，应用于服务器，所述方法包括：
接收各个共享计算节点上传的节点实时状态数据；
获取各个共享计算节点的节点管理信息和待分配的共享计算任务的任务管理信息；
获取预先分析得到的节点与服务画像数据；
根据所述节点管理信息、任务管理信息、节点实时状态数据、节点与服务画像数据计算出所述共享计算任务对应的节点分配结果；及
根据所述节点分配结果将所述共享计算任务下发至对应的共享计算节点。
可选地，所述节点实时状态数据包括所述共享计算节点当前可用的带宽、存储空间、计算资源，当前所执行的任务状态以及执行任务所产生的数据。
可选地，所述节点管理信息包括每个所述共享计算节点的节点基础信息和上下线管理信息；所述任务管理信息包括所述共享计算任务的资源需求、属性、状态的维护信息。
可选地，所述节点与服务画像数据包括节点画像、服务质量画像、组合服务质量画像；
所述节点画像为通过历史数据分析得到每个所述共享计算节点的完整的属性状态；
所述服务质量画像为服务质量与节点属性的相关性分析，通过输入具体的任务和节点属性，预估所述任务在所述节点的服务质量表现；
所述组合服务质量画像为不同的任务组合的服务质量以及任务组合在不同节点上的服务质量的分析。
可选地，所述根据所述节点管理信息、任务管理信息、节点实时状态数据、节点与服务画像数据计算出所述共享计算任务对应的节点分配结果包括按照下列计算模式中的至少一种计算出所述共享计算任务对应的节点分配结果：实时调度算法、全局调度优化算法、实验调度组算法；
所述实时调度算法为根据所述节点管理信息初步确定可选的共享计算节点，然后针对每个可选的共享计算节点的所述节点实时状态数据和所述共享计算任务的资源需求，增量地按照贪心算法计算出所述分配结果；
所述全局调度优化算法为按照全局的共享计算任务的资源需求和所有共享计算节点的所述节点实时状态数据，以及所述节点与服务画像数据，对全局进行最优解的调度计算，即为全局的所有共享计算任务分别分配最优解的共享计算节点；
所述实验调度组算法为随机或者按预设规则挑选多个非最优的共享计算节点进行任务分配，以使所述数据仓库中有各种维度的组合数据。
可选地，所述服务器在多个机房中采用Redis Cluster模式进行部署，其中一个所述机房为主机房，所述主机房中的数据同步至其他所述机房，当所述主机房发生故障时，切换到其中一个其他所述机房进行容器资源调度服务。
此外，为实现上述目的，本申请还提供一种服务器，所述服务器包括存储器、处理器，所述存储器上存储有可在所述处理器上运行的容器资源调度程序，所述容器资源调度程序被所述处理器执行时实现如上述的容器资源调度方法。
可选地，所述服务器在多个机房中采用Redis Cluster模式进行部署，其中一个所述机房为主机房，所述主机房中的数据同步至其他所述机房，当所述主机房发生故障时，切换到其中一个其他所述机房的服务器中进行容器资源调度服务。
进一步地，为实现上述目的，本申请还提供一种容器资源调度系统，所述系统包括：
数据仓库，用于接收并存储共享计算节点上传的节点实时状态数据；
调度计算单元，用于获取各个所述共享计算节点的节点管理信息和待分配的共享计算任务的任务管理信息；
调度分析单元，用于通过数据挖掘技术从所述数据仓库中分析得到节点与服务画像数据，供所述调度计算单元使用；
所述调度计算单元，还用于根据所述节点管理信息、任务管理信息、节点实时状态数据、节点与服务画像数据计算出该共享计算任务对应的节点分配结果；
调度下发单元，用于根据所述节点分配结果将所述共享计算任务下发至对应的共享计算节点。
进一步地，为实现上述目的，本申请还提供一种计算机可读存储介质，所述计算机可读存储介质存储有容器资源调度程序，所述容器资源调度程序可被至少一个处理器执行，以使所述至少一个处理器执行如上述的容器资源调度方法。
相较于现有技术，本申请所提出的容器资源调度方法和系统、服务器及计算机可读存储介质，可以支持百万级甚至千万级节点的调度，通过数据挖掘技术，分析出节点画像、服务质量画像、组合服务质量画像，为容器资源调度提供了更加准确多元的选择空间，并在此基础上，进一步地以收益为目标进行调度，而不仅仅是资源筛选。而且，本申请通过多种调度计算模式，在保证服务时效性的同时，探索并逐步趋近更优的调度状态。另外，通过Redis Cluster模式在多个机房部署核心调度单元，可以支持多机房容灾，以及系统状态的容错和故障恢复。
附图说明
图1是本申请各实施例一可选的应用环境示意图；
图2是本申请第一实施例提出的一种服务器的架构示意图；
图3是本申请第二实施例提出的一种容器资源调度方法的流程示意图；
图4是本申请第三实施例提出的一种容器资源调度系统的功能模块图。
本申请目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。
具体实施方式
为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
需要说明的是，在本申请中涉及“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。另外，各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本申请要求的保护范围之内。
参阅图1所示，是本申请各个实施例一可选的应用环境示意图。本申请可应用于一种共享计算系统1。
上述共享计算系统1至少包括服务器2和共享计算节点4(有多个，图中仅示出一个作为代表)。其中，上述服务器2可以是机架式服务器、刀片式服务器、塔式服务器或机柜式服务器等计算设备，该服务器2可以是独立的服务器，也可以是多个服务器所组成的服务器集群。
服务器2用于根据节点管理信息、任务管理信息、节点实时状态数据、节点与服务画像数据计算出共享计算任务对应的节点分配结果，并根据该分配结果将该共享计算任务下发至对应的共享计算节点4。
共享计算节点4用于执行所分配的任务并上传节点实时状态数据至服务器2。其中，每个共享计算节点4触发式(当状态变更时)或者周期性地上报该节点的节点实时状态数据。
上述服务器2下发任务至对应共享计算节点4以及共享计算节点4上传实时状态数据的过程，均可通过在信令网关(图中未示出)和共享计算节点4之间以远程过程调用(Remote Procedure Call，RPC)协议和超文本传输协议 (Hyper Text Transfer Protocol，HTTP)为基础建立的长连接双向信令传输通道进行传输。
值得注意的是，，上述服务器2可以在多个机房(一般2-3个)中采用Redis Cluster模式进行部署，但是只有一个机房作为主机房，进行调度服务，并且主机房的计算结果等数据均会同步到所有的Redis Cluster集群(其他机房的服务器2)。当主机房发生故障时，切换到其中一个新机房进行调度服务，并依靠新机房的数据和服务器2进行计算和下发。
第一实施例
参阅图2所示，本申请第一实施例提出一种服务器2。
上述服务器2包括：存储器21、处理器23、网络接口25及通信总线27。其中，网络接口25可选地可以包括标准的有线接口、无线接口(如WI-FI接口)。通信总线27用于实现这些组件之间的连接通信。
存储器21至少包括一种类型的可读存储介质。上述至少一种类型的可读存储介质可为如闪存、硬盘、多媒体卡、卡型存储器等的非易失性存储介质。在一些实施例中，上述存储器21可以是服务器2的内部存储单元，例如该服务器2的硬盘。在另一些实施例中，上述存储器21也可以是服务器2的外部存储单元，例如服务器2上配备的插接式硬盘，智能存储卡(Smart Media Card，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(Flash Card)等。
上述存储器21可以用于存储安装于服务器2的应用软件及各类数据，例如容器资源调度程序20的程序代码及其运行过程中产生的相关数据。
处理器23在一些实施例中可以是一中央处理器，微处理器或其它数据处理芯片，用于运行存储器21中存储的程序代码或处理数据。
图2仅示出了具有组件21-27以及容器资源调度程序20的服务器2，但是应理解的是，图2并未示出服务器2的所有组件，可以替代实施更多或者更少的组件。
在图2所示的服务器2实施例中，作为一种计算机存储介质的存储器21中存储容器资源调度程序20的程序代码，处理器23执行上述容器资源调度程序20的程序代码时，实现如下方法：
(1)接收各个共享计算节点4上传的节点实时状态数据。
(2)获取各个共享计算节点4的节点管理信息和待分配的共享计算任务的任务管理信息。
(3)获取预先分析得到的节点与服务画像数据。
(4)根据节点管理信息、任务管理信息、节点实时状态数据、节点与服务画像数据计算出该共享计算任务对应的节点分配结果。
(5)根据上述分配结果将该共享计算任务下发至对应的共享计算节点4。
上述方法的详细说明请参阅下述第二实施例，在此不再赘述。
第二实施例
参阅图3所示，本申请第二实施例提出一种容器资源调度方法，应用于上述服务器2。在本实施例中，根据不同的需求，图3所示的流程图中的步骤的执行顺序可以改变，某些步骤可以省略。该方法包括：
S10，接收各个共享计算节点4上传的节点实时状态数据。
在上述共享计算系统1中，每个共享计算节点4均需要上传节点实时状态数据至服务器2。上述节点实时状态数据包括该共享计算节点4当前可用的带宽、存储空间、计算资源，当前所执行的任务状态以及执行任务所产生的数据等。其中，每个共享计算节点4触发式(当状态变更时)或者周期性地上报该节点的节点实时状态数据。
S20，获取各个共享计算节点4的节点管理信息和待分配的共享计算任务的任务管理信息。
在本实施例中，可以从节点管理器(可位于服务器2中或共享计算系统1的其他服务器中，图1中未示出)中获取各个共享计算节点4的节点管理信息，从任务管理器(可位于服务器2中或共享计算系统1的其他服务器中，图1中未示出)中获取待分配的共享计算任务的任务管理信息。其中，节点管理信息是指每个共享计算节点4的节点基础信息和上下线管理信息。上述节点基础信息包括节点ID、所属区域、ISP(Internet Service Provider，互联网服务提供商)、NAT(Network Address Translation，网络地址转换)类型等。上述上下线管理信息包括该共享计算节点4当前为上线状态或下线状态等。任务管理信息是指共享计算任务的资源需求、属性、状态的维护信息。例如，上述资源需求包括带宽需求、存储空间需求、计算资源需求等。
S30，获取预先分析得到的节点与服务画像数据。
上述节点与服务画像数据包括节点画像、服务质量画像、组合服务质量画像。节点画像为通过历史数据分析得到每个共享计算节点4的完整的属性状态，例如平均在线率、平均上行带宽等。服务质量画像为服务质量与节点属性的相关性分析，通过输入具体的任务(或者任务特征)和节点属性，预估该任务在该节点的服务质量表现。例如某任务在Nat类型为5、磁盘容量10G的北京电信的节点上，预估上行流量可达2Mbps。组合服务质量画像为不同的任务组合的服务质量以及任务组合在不同节点上的服务质量的分析。
在分配共享计算任务之前，可以通过数据挖掘技术从数据仓库中预先分析得到上述节点与服务画像数据，供后续分配共享计算任务时调度使用。上述分析可以采用现有的一些常用的数据挖掘技术进行处理，在此不再赘述。
S40，根据节点管理信息、任务管理信息、节点实时状态数据、节点与服务画像数据计算出该共享计算任务对应的节点分配结果。
在本实施例中，上述节点分配结果有三种计算模式：实时调度算法、全局调度优化算法、实验调度组算法。其中：
实时调度算法为根据节点管理信息初步确定可选的共享计算节点4(例如根据地域、运营商和当前是否在线进行选择)，然后针对每个可选的共享计算节点4当前的节点实时状态数据和该共享计算任务的资源需求，增量地按照贪心算法计算出节点分配结果。上述贪心算法是指在满足过滤条件的情况下，选用收益率(收益/成本)最高的共享计算节点4，上述收益与成本可以按照对应的业务费用和对节点的奖励费用来结算。
全局调度优化算法为按照全局的共享计算任务的资源需求和所有共享计算节点4的节点实时状态数据，以及节点与服务画像数据，对全局进行最优解的计算，即为全局的所有任务分别分配最优解的共享计算节点4。上述全局调度优化算法的目的包括：辅助评估和优化实时调度算法；根据全局优化的结果，对全局调度状态进行逐步的调整。
实验调度组算法为随机或者按预设规则挑选多个并不是最优的共享计算节点4进行任务分配，以保证数据仓库中有足够的各种维度的组合数据。
S50，根据上述分配结果将该共享计算任务下发至对应的共享计算节点4。
共享计算节点4接收到该共享计算任务后，执行所分配的任务并上传节点 实时状态数据。
上述下发共享计算任务至对应共享计算节点4以及共享计算节点4上传实时状态数据的过程，均可通过在信令网关和共享计算节点4之间以RPC协议和HTTP协议为基础建立的长连接双向信令传输通道进行传输。
值得注意的是，上述服务器2可以在多个机房(一般2-3个)中采用Redis Cluster模式进行部署、但是只有一个机房作为主机房，进行调度服务，并且主机房的计算结果等数据均会同步到所有的Redis Cluster集群。当主机房发生故障时，切换到其中一个新机房进行调度服务，从而实现多机房容灾。
本实施例提供的容器资源调度方法，可以支持百万级甚至千万级节点的调度，通过数据挖掘技术，分析出节点画像、服务质量画像、组合服务质量画像，为容器资源调度提供了更加准确多元的选择空间，并在此基础上，进一步地以收益为目标进行调度，而不仅仅是资源筛选。而且，本方法通过多种调度计算模式，在保证服务时效性的同时，探索并逐步趋近更优的调度状态。另外，通过Redis Cluster模式在多个机房部署核心调度服务，可以支持多机房容灾，以及系统状态的容错和故障恢复。
第三实施例
参阅图4所示，本申请第三实施例提出一种容器资源调度系统200，应用于上述服务器2。
在本实施例中，容器资源调度系统200包括数据仓库202、调度计算单元204、调度分析单元206、调度下发单元208。
数据仓库202用于接收并存储共享计算节点4上传的节点实时状态数据。
调度计算单元204用于获取各个共享计算节点4的节点管理信息和待分配的共享计算任务的任务管理信息。
调度分析单元206用于通过数据挖掘技术从数据仓库202中分析得到节点与服务画像数据，供调度计算单元204使用。
调度计算单元204还用于根据节点管理信息、任务管理信息、节点实时状态数据、节点与服务画像数据计算出该共享计算任务对应的节点分配结果。
调度下发单元208用于根据上述分配结果将该共享计算任务下发至对应的共享计算节点4。
上述数据仓库202、调度计算单元204、调度分析单元206、调度下发单元208为容器资源调度系统200的核心调度单元，可以位于一个或多个服务器(例如服务器2)中。在本实施例中，可以在多个机房(一般2-3个)中采用Redis Cluster模式部署上述核心调度单元，但是只有一个机房作为主机房，进行调度服务，并且主机房的计算结果等数据均会同步到所有的Redis Cluster集群(其他机房的核心调度单元)。当主机房发生故障时，切换到其中一个新机房进行调度服务，并依靠新机房的数据和核心调度单元进行计算和下发。
第四实施例
本申请还提供了另一种实施方式，即提供一种计算机可读存储介质，上述计算机可读存储介质存储有容器资源调度程序20，上述容器资源调度程序20可被至少一个处理器执行，以使上述至少一个处理器执行如上述的容器资源调度方法。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台客户端(可以是手机，计算机，电子装置，空调器，或者网络设备等)执行本申请各个实施例所述的方法。
以上仅为本申请的优选实施例，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。

Claims (18)

  1. 一种容器资源调度方法，应用于服务器，其特征在于，所述方法包括：
    接收各个共享计算节点上传的节点实时状态数据；
    获取各个共享计算节点的节点管理信息和待分配的共享计算任务的任务管理信息；
    获取预先分析得到的节点与服务画像数据；
    根据所述节点管理信息、任务管理信息、节点实时状态数据、节点与服务画像数据计算出所述共享计算任务对应的节点分配结果；及
    根据所述节点分配结果将所述共享计算任务下发至对应的共享计算节点。
  2. 如权利要求1所述的容器资源调度方法，其特征在于，所述节点实时状态数据包括所述共享计算节点当前可用的带宽、存储空间、计算资源，当前所执行的任务状态以及执行任务所产生的数据。
  3. 如权利要求1所述的容器资源调度方法，其特征在于，所述节点管理信息包括每个所述共享计算节点的节点基础信息和上下线管理信息；所述任务管理信息包括所述共享计算任务的资源需求、属性、状态的维护信息。
  4. 如权利要求1所述的容器资源调度方法，其特征在于，所述节点与服务画像数据包括节点画像、服务质量画像、组合服务质量画像；
    所述节点画像为通过历史数据分析得到每个所述共享计算节点的完整的属性状态；
    所述服务质量画像为服务质量与节点属性的相关性分析，通过输入具体的任务和节点属性，预估所述任务在所述节点的服务质量表现；
    所述组合服务质量画像为不同的任务组合的服务质量以及任务组合在不同节点上的服务质量的分析。
  5. 如权利要求1所述的容器资源调度方法，其特征在于，所述根据所述节点管理信息、任务管理信息、节点实时状态数据、节点与服务画像数据计算出所述共享计算任务对应的节点分配结果包括按照下列计算模式中的至少一种计算出所述共享计算任务对应的节点分配结果：实时调度算法、全局调度优化算法、实验调度组算法；
    所述实时调度算法为根据所述节点管理信息初步确定可选的共享计算节 点，然后针对每个可选的共享计算节点的所述节点实时状态数据和所述共享计算任务的资源需求，增量地按照贪心算法计算出所述分配结果；
    所述全局调度优化算法为按照全局的共享计算任务的资源需求和所有共享计算节点的所述节点实时状态数据，以及所述节点与服务画像数据，对全局进行最优解的调度计算，即为全局的所有共享计算任务分别分配最优解的共享计算节点；
    所述实验调度组算法为随机或者按预设规则挑选多个非最优的共享计算节点进行任务分配，以使所述数据仓库中有各种维度的组合数据。
  6. 如权利要求1-5任一项所述的容器资源调度方法，其特征在于，所述服务器在多个机房中采用Redis Cluster模式进行部署，其中一个所述机房为主机房，所述方法还包括：
    所述主机房中的数据同步至其他所述机房；
    当所述主机房发生故障时，切换到其中一个其他所述机房进行容器资源调度服务。
  7. 一种服务器，其特征在于，所述服务器包括存储器、处理器，所述存储器上存储有可在所述处理器上运行的容器资源调度程序，所述容器资源调度程序被所述处理器执行时实现以下步骤：
    接收各个共享计算节点上传的节点实时状态数据；
    获取各个共享计算节点的节点管理信息和待分配的共享计算任务的任务管理信息；
    获取预先分析得到的节点与服务画像数据；
    根据所述节点管理信息、任务管理信息、节点实时状态数据、节点与服务画像数据计算出所述共享计算任务对应的节点分配结果；及
    根据所述节点分配结果将所述共享计算任务下发至对应的共享计算节点。
  8. 如权利要求7所述的服务器，其特征在于，所述节点实时状态数据包括所述共享计算节点当前可用的带宽、存储空间、计算资源，当前所执行的任务状态以及执行任务所产生的数据。
  9. 如权利要求7所述的服务器，其特征在于，所述节点管理信息包括每个所述共享计算节点的节点基础信息和上下线管理信息；所述任务管理信息包括所述共享计算任务的资源需求、属性、状态的维护信息。
  10. 如权利要求7所述的服务器，其特征在于，所述节点与服务画像数据包括节点画像、服务质量画像、组合服务质量画像；
    所述节点画像为通过历史数据分析得到每个所述共享计算节点的完整的属性状态；
    所述服务质量画像为服务质量与节点属性的相关性分析，通过输入具体的任务和节点属性，预估所述任务在所述节点的服务质量表现；
    所述组合服务质量画像为不同的任务组合的服务质量以及任务组合在不同节点上的服务质量的分析。
  11. 如权利要求7所述的服务器，其特征在于，所述根据所述节点管理信息、任务管理信息、节点实时状态数据、节点与服务画像数据计算出所述共享计算任务对应的节点分配结果包括按照下列计算模式中的至少一种计算出所述共享计算任务对应的节点分配结果：实时调度算法、全局调度优化算法、实验调度组算法；
    所述实时调度算法为根据所述节点管理信息初步确定可选的共享计算节点，然后针对每个可选的共享计算节点的所述节点实时状态数据和所述共享计算任务的资源需求，增量地按照贪心算法计算出所述分配结果；
    所述全局调度优化算法为按照全局的共享计算任务的资源需求和所有共享计算节点的所述节点实时状态数据，以及所述节点与服务画像数据，对全局进行最优解的调度计算，即为全局的所有共享计算任务分别分配最优解的共享计算节点；
    所述实验调度组算法为随机或者按预设规则挑选多个非最优的共享计算节点进行任务分配，以使所述数据仓库中有各种维度的组合数据。
  12. 如权利要求7所述的服务器，其特征在于，所述服务器在多个机房中采用Redis Cluster模式进行部署，其中一个所述机房为主机房，所述主机房中的数据同步至其他所述机房，当所述主机房发生故障时，切换到其中一个其他所述机房的服务器中进行容器资源调度服务。
  13. 一种容器资源调度系统，其特征在于，所述系统包括：
    数据仓库，用于接收并存储共享计算节点上传的节点实时状态数据；
    调度计算单元，用于获取各个所述共享计算节点的节点管理信息和待分配的共享计算任务的任务管理信息；
    调度分析单元，用于通过数据挖掘技术从所述数据仓库中分析得到节点与服务画像数据，供所述调度计算单元使用；
    所述调度计算单元，还用于根据所述节点管理信息、任务管理信息、节点实时状态数据、节点与服务画像数据计算出该共享计算任务对应的节点分配结果；
    调度下发单元，用于根据所述节点分配结果将所述共享计算任务下发至对应的共享计算节点。
  14. 如权利要求13所述的容器资源调度系统，其特征在于，所述节点实时状态数据包括所述共享计算节点当前可用的带宽、存储空间、计算资源，当前所执行的任务状态以及执行任务所产生的数据。
  15. 如权利要求13所述的容器资源调度系统，其特征在于，所述节点管理信息包括每个所述共享计算节点的节点基础信息和上下线管理信息；所述任务管理信息包括所述共享计算任务的资源需求、属性、状态的维护信息。
  16. 如权利要求13所述的容器资源调度系统，其特征在于，所述节点与服务画像数据包括节点画像、服务质量画像、组合服务质量画像；
    所述节点画像为通过历史数据分析得到每个所述共享计算节点的完整的属性状态；
    所述服务质量画像为服务质量与节点属性的相关性分析，通过输入具体的任务和节点属性，预估所述任务在所述节点的服务质量表现；
    所述组合服务质量画像为不同的任务组合的服务质量以及任务组合在不同节点上的服务质量的分析。
  17. 如权利要求13所述的容器资源调度系统，其特征在于，所述根据所述节点管理信息、任务管理信息、节点实时状态数据、节点与服务画像数据计算出所述共享计算任务对应的节点分配结果包括按照下列计算模式中的至少一种计算出所述共享计算任务对应的节点分配结果：实时调度算法、全局调度优化算法、实验调度组算法；
    所述实时调度算法为根据所述节点管理信息初步确定可选的共享计算节 点，然后针对每个可选的共享计算节点的所述节点实时状态数据和所述共享计算任务的资源需求，增量地按照贪心算法计算出所述分配结果；
    所述全局调度优化算法为按照全局的共享计算任务的资源需求和所有共享计算节点的所述节点实时状态数据，以及所述节点与服务画像数据，对全局进行最优解的调度计算，即为全局的所有共享计算任务分别分配最优解的共享计算节点；
    所述实验调度组算法为随机或者按预设规则挑选多个非最优的共享计算节点进行任务分配，以使所述数据仓库中有各种维度的组合数据。
  18. 一种计算机可读存储介质，所述计算机可读存储介质存储有容器资源调度程序，所述容器资源调度程序可被至少一个处理器执行，以使所述至少一个处理器执行如权利要求1-6中任一项所述的容器资源调度方法。
PCT/CN2019/092457 2018-12-14 2019-06-24 容器资源调度方法和系统、服务器及计算机可读存储介质 WO2020119060A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201811532786.6 2018-12-14
CN201811532786.6A CN109656685A (zh) 2018-12-14 2018-12-14 容器资源调度方法和系统、服务器及计算机可读存储介质

Publications (1)

Publication Number Publication Date
WO2020119060A1 true WO2020119060A1 (zh) 2020-06-18

Family

ID=66114074

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/092457 WO2020119060A1 (zh) 2018-12-14 2019-06-24 容器资源调度方法和系统、服务器及计算机可读存储介质

Country Status (2)

Country Link
CN (1) CN109656685A (zh)
WO (1) WO2020119060A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112214323A (zh) * 2020-10-12 2021-01-12 苏州浪潮智能科技有限公司 一种资源回收方法、装置及计算机可读存储介质

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109656685A (zh) * 2018-12-14 2019-04-19 深圳市网心科技有限公司 容器资源调度方法和系统、服务器及计算机可读存储介质
CN110097278B (zh) * 2019-04-28 2021-06-08 广东省科技基础条件平台中心 一种科技资源智能共享融合训练系统和应用系统
CN111126895A (zh) * 2019-11-18 2020-05-08 青岛海信网络科技股份有限公司 一种复杂场景下调度智能分析算法的管理仓库及调度方法
CN111459641B (zh) * 2020-04-08 2023-04-28 广州欢聊网络科技有限公司 一种跨机房的任务调度和任务处理的方法及装置
CN111949394B (zh) * 2020-07-16 2024-07-16 广州玖的数码科技有限公司 一种共享算力资源的方法、系统及存储介质
CN113487412A (zh) * 2021-07-07 2021-10-08 中国工商银行股份有限公司 基于多渠道的共享服务隔离方法及装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106095582A (zh) * 2016-06-17 2016-11-09 四川新环佳科技发展有限公司 云平台的任务执行方法
CN108062243A (zh) * 2016-11-08 2018-05-22 杭州海康威视数字技术股份有限公司 执行计划的生成方法、任务执行方法及装置
CN109656685A (zh) * 2018-12-14 2019-04-19 深圳市网心科技有限公司 容器资源调度方法和系统、服务器及计算机可读存储介质

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105656973B (zh) * 2014-11-25 2018-11-13 中国科学院声学研究所 一种分布式节点组内任务调度方法及系统
CN104539982B (zh) * 2014-12-18 2018-08-14 新浪网技术(中国)有限公司 一种视频点对点资源共享调度方法、系统及节点终端
CN105141697A (zh) * 2015-09-16 2015-12-09 国云科技股份有限公司 一种多QoS约束的云计算任务调度方法
CN105703940B (zh) * 2015-12-10 2021-08-20 中国电力科学研究院有限公司 一种面向多级调度分布式并行计算的监控系统及监控方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106095582A (zh) * 2016-06-17 2016-11-09 四川新环佳科技发展有限公司 云平台的任务执行方法
CN108062243A (zh) * 2016-11-08 2018-05-22 杭州海康威视数字技术股份有限公司 执行计划的生成方法、任务执行方法及装置
CN109656685A (zh) * 2018-12-14 2019-04-19 深圳市网心科技有限公司 容器资源调度方法和系统、服务器及计算机可读存储介质

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112214323A (zh) * 2020-10-12 2021-01-12 苏州浪潮智能科技有限公司 一种资源回收方法、装置及计算机可读存储介质
CN112214323B (zh) * 2020-10-12 2022-06-14 苏州浪潮智能科技有限公司 一种资源回收方法、装置及计算机可读存储介质

Also Published As

Publication number Publication date
CN109656685A (zh) 2019-04-19

Similar Documents

Publication Publication Date Title
WO2020119060A1 (zh) 容器资源调度方法和系统、服务器及计算机可读存储介质
CN108776934B (zh) 分布式数据计算方法、装置、计算机设备及可读存储介质
CN107066319B (zh) 一种面向异构资源的多维调度系统
TWI755417B (zh) 計算任務分配方法、流計算任務的執行方法、控制伺服器、流計算中心伺服器集群、流計算系統及異地多活系統
JP6490913B2 (ja) グリッドコンピューティングシステムの遊休リソースによるタスク実行
US11062047B2 (en) System and method for distributed computation using heterogeneous computing nodes
CN112162865A (zh) 服务器的调度方法、装置和服务器
CN107919971B (zh) 用于音视频通讯连接容灾的方法、装置及系统
CN109656690A (zh) 调度系统、方法和存储介质
CN104699736A (zh) 一种分布式的基于可移动设备的大规模数据采集系统及方法
CN105868021A (zh) 一种任务分配的方法及装置
CN105049509A (zh) 一种集群调度方法、负载均衡器以及集群系统
WO2016095524A1 (zh) 资源分配方法及装置
CN105976245A (zh) 一种模拟交易系统及方法
CN114979286B (zh) 容器服务的访问控制方法、装置、设备及计算机存储介质
CN110955504B (zh) 智能分配渲染任务的方法、服务器、系统及存储介质
CN107025134B (zh) 数据库服务系统及兼容多种数据库的方法
CN112104679B (zh) 处理超文本传输协议请求的方法、装置、设备和介质
CN104468710A (zh) 一种混合大数据处理系统及处理方法
CN112261125B (zh) 集中单元的云化部署方法、装置及系统
CN105338037A (zh) 一种动态调度方法及系统
CN113992648A (zh) 一种基于容器编排技术的路况实时发布方法及装置
CN109302319B (zh) 报文池分布式集群及其管理方法
US20220114188A1 (en) Efficient Database Loading
CN104503846B (zh) 一种基于云计算系统的资源管理系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19895983

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 29.09.2021)

122 Ep: pct application non-entry in european phase

Ref document number: 19895983

Country of ref document: EP

Kind code of ref document: A1