Cross-runtime instance hybrid deployment method and apparatus based on cloud computing technology
By using cloud computing technology resource scheduling system on hybrid nodes of cloud management platform, dynamically scheduling and adjusting various types of runtime instance resources, the problem of low resource utilization in the existing technology is solved and efficient resource utilization is achieved and satisfy the quality of service.
Patent Information
- Application Number
- PCT/CN2024/079353
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2023-09-28
- Filing Date
- 2024-02-29
- Publication Date
- 2025-02-06
AI Technical Summary
The runtime instance types created by existing cloud management platforms on nodes are the same, resulting in the node fragmented resources that cannot be effectively allocated and the resource utilization rate is low.
Through a cloud computing technology-based resource scheduling system, manage resources of multiple hybrid nodes, support the deployment of multiple types of runtime instances, such as containers, virtual machines and serverless functions, dynamically schedule and adjust resources to meet the service quality of different instances Require.
It realizes the full utilization of fine-grained resources of mixed nodes, improves resource utilization, and meets the service quality requirements of different services.
Smart Images

Figure CN2024079353_06022025_PF_FP_ABST
Abstract
Description
Hybrid deployment method and device across runtime instances based on cloud computing technology
[0001] This application claims priority to Chinese patent application No. 202310952215.2 filed on July 31, 2023, entitled “Task Scheduling System, Method and Computing Device Cluster for Providing Cloud Services,” the entire contents of which are incorporated herein by reference.
[0002] This application claims priority to Chinese patent application No. 202311288295.2 filed on September 28, 2023, entitled “Hybrid deployment method and device across runtime instances based on cloud computing technology,” the entire contents of which are incorporated by reference into this application. Technical Field
[0003] The present application relates to the field of cloud technology, and in particular to a hybrid deployment method and device across runtime instances based on cloud computing technology. Background Art
[0004] With the rapid rise of fifth-generation mobile communication technology (5G) networks and edge computing, enterprises are placing higher demands on multi-cloud management platform access, full-stack resource management, and intelligent monitoring and operation and maintenance. Currently, there are multiple types of cloud management platforms on the market, each responsible for creating different types of runtime instances. For example, each cloud management platform creates runtime instances on its own node. Runtime instances created on the same node share the same runtime type, resulting in similar specifications for runtime instances within the same node. This prevents the node's fragmented resources from being allocated to more runtime instances, leading to low node resource utilization.
[0005] Summary of the Invention
[0006] The present invention provides a hybrid deployment method and apparatus across runtime instances based on cloud computing technology, which enables full utilization of node resources. The technical solution is as follows:
[0007] In a first aspect, a hybrid deployment method across runtime instances based on cloud computing technology is provided, which is executed by a resource scheduling system based on cloud computing technology, and the resource scheduling system is used to manage resources of multiple hybrid nodes. A hybrid node refers to a node that supports at least two types of runtime instances, wherein the types of runtime instances include containers, virtual machines, and serverless functions. The method includes the following steps: first, receiving an instance configuration request sent by a tenant through a client, the instance configuration request is used to indicate that a target instance is deployed on a hybrid node, wherein the runtime type of the target instance is a type of runtime instance; then, determining a first hybrid node from multiple hybrid nodes according to the instance configuration request; then, creating a target instance for the tenant at the first hybrid node; and then, sending running status information of the target instance to the client, the running status information including an identifier of the runtime type of the target instance and node information, and the node information is used to indicate that the running environment of the target instance is the first hybrid node.
[0008] This method manages the resources of multiple hybrid nodes through a resource scheduling system. Since hybrid nodes support the deployment of multiple types of runtime instances, the resource scheduling system can deploy different types of runtime instances in the hybrid nodes. The specifications of different types of runtime instances vary greatly, and the fragmented resources of the hybrid nodes can be allocated to runtime instances with smaller specifications, so that the fragmented resources of the hybrid nodes can be fully utilized.
[0009] In one possible implementation, after the first hybrid node creates a target instance for the tenant, the method further includes the following steps: obtaining instance priority information input by the tenant, and adjusting the resources occupied by the target instance in the first hybrid node based on the instance priority information to meet the service quality requirements of the target instance, wherein the instance priority information is used to determine the service quality required by the target instance in the first hybrid node.
[0010] Based on the above possible implementation methods, the resources occupied by the target instance in the hybrid node are adjusted according to the instance priority information input by the tenant, so that the resources occupied by the adjusted target instance can meet the service quality requirements of the target instance, thereby providing a guarantee for the service quality of the business running in the target instance.
[0011] In one possible implementation, the resource scheduling system supports tenants to update instance priority information according to resource-adjusted operating status information. The method further includes the following steps: adjusting resources occupied by the target business instance according to the updated instance priority information.
[0012] Based on the above possible implementation methods, it is convenient for tenants to update instance priority information so that the resource adjustment system can make secondary adjustments to the resources occupied by the target instance according to the updated instance priority information to meet the business needs of the target instance in different time periods.
[0013] In a possible implementation, the method further includes the following steps: in the process of the target instance running the tenant's target business, obtaining the node status of multiple hybrid nodes and the service quality degradation parameters of each business instance running in each hybrid node; determining the resource adjustment strategy of the target instance based on the node status of multiple hybrid nodes, the service quality degradation parameters of each business instance and the actual resource consumption of each business instance; based on the resource adjustment strategy, adjusting the resources occupied by the target instance among the resources provided by the multiple hybrid nodes, wherein the resource adjustment strategy can meet the service quality requirements of the target instance, the service quality degradation parameters are used to indicate the degree of degradation of the service quality of the business instance during operation, and the runtime type of the business instance is a type of runtime instance.
[0014] Based on the above possible implementation methods, the resources occupied by the target instance in the hybrid node are adjusted according to the resource adjustment strategy, so that the resources occupied by the target instance after adjustment can meet the service quality requirements of the target instance, thereby providing a guarantee for the service quality of the business running in the target instance.
[0015] In one possible implementation, the node status includes the resource status and service status of the hybrid node, the resource status is used to indicate at least one of the resource allocation and resource utilization of the hybrid node, and the service status is used to indicate at least one of the busyness of the hybrid node and the affinity between the hybrid node and the local business instance.
[0016] In one possible implementation, the resource adjustment strategy includes any of the following:
[0017] releasing a first amount of resources from the resources occupied by the target instance;
[0018] allocating a second amount of resources to the target instance from unoccupied resources of the first hybrid node;
[0019] A third amount of resources is allocated to the target instance from unoccupied resources of a second hybrid node among the plurality of hybrid nodes.
[0020] Based on the above possible implementations, by adjusting the resources occupied by the target instance through different resource adjustment strategies, the idle fragmented resources in the hybrid node can be integrated, so that the fragmented resources of the hybrid node are fully utilized.
[0021] In one possible implementation, the above-mentioned resource adjustment strategy includes recommended specification information, which is runtime specification information recommended for tenants that can meet the service quality requirements of the target business. Based on this, the method also includes the following steps: updating the operating status information based on the service quality degradation parameters and / or recommended specification information of the target business; and sending the updated operating status information to the client.
[0022] Based on the above possible implementation methods, it is convenient for tenants to view the latest running status of the target instance.
[0023] In one possible implementation, the process of obtaining the service quality degradation parameter of each service instance running in each hybrid node includes: determining the service quality degradation parameter of the service instance based on core indicator data of the processor core bound to the service instance.
[0024] Based on the above possible implementation methods, kernel indicator data can accurately reflect the kernel-level resources consumed by the instance when running on the CPU. Therefore, the service quality degradation of the target instance can be accurately predicted based on the kernel indicator data. In the case of severe service quality degradation, resources of the target instance can be scheduled in a timely manner to alleviate the degradation of the service quality of the target instance as soon as possible.
[0025] In a second aspect, a hybrid deployment device across runtime instances based on cloud computing technology is provided, which is used to execute the method provided in the first aspect or any optional manner of the first aspect.
[0026] In a third aspect, a computing device cluster is provided, the computing device cluster including at least one computing device, each computing device including a processor and a memory, the processor of the at least one computing device being used to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster executes the method provided in the first aspect or any optional manner of the first aspect.
[0027] In a fourth aspect, a computer-readable storage medium is provided, in which computer program instructions are stored. When the computer program instructions are executed by a computing device cluster, the computing device cluster executes the method provided in the first aspect or any optional method of the first aspect.
[0028] In a fifth aspect, a computer program product or computer program is provided, which includes instructions. When the instructions are executed by a computing cluster, the computing cluster executes the method provided in the first aspect or various optional implementations of the first aspect.
[0029] Based on the implementation methods provided in the above aspects, this application can also be further combined to provide more implementation methods. BRIEF DESCRIPTION OF THE DRAWINGS
[0030] FIG1 is an architecture diagram of a resource scheduling system based on cloud computing technology provided in an embodiment of the present application;
[0031] FIG2 is a schematic diagram of the interaction between a resource scheduling system and OpenStack provided in an embodiment of the present application;
[0032] FIG3 is a schematic diagram of the interaction between a resource scheduling system and Kubernetes provided in an embodiment of the present application;
[0033] FIG4 is a global resource diagram of a resource scheduling system provided in an embodiment of the present application;
[0034] FIG5 is a flow chart of a hybrid deployment method across runtime instances based on cloud computing technology provided by an embodiment of the present application;
[0035] FIG6 is a flow chart of a hybrid deployment runtime instance of a resource scheduling system provided by an embodiment of the present application;
[0036] FIG7 is a flow chart of a resource scheduling method based on cloud computing technology provided in an embodiment of the present application;
[0037] FIG8 is a schematic diagram of a resource scheduling strategy provided in an embodiment of the present application;
[0038] FIG9 is a schematic diagram of a task display interface provided in an embodiment of the present application;
[0039] 10 is a schematic structural diagram of a hybrid deployment device across runtime instances based on cloud computing technology provided in an embodiment of the present application;
[0040] FIG11 is a schematic structural diagram of a computer device provided in an embodiment of the present application;
[0041] FIG12 is an architecture diagram of a computer cluster provided in an embodiment of the present application;
[0042] FIG13 is an architecture diagram of another computer cluster provided in an embodiment of the present application. DETAILED DESCRIPTION
[0043] To facilitate understanding of the embodiments of this application, some of the terms involved in this application are introduced below:
[0044] A node is a device that performs at least one of the following functions: processing data and storing data. Nodes run an operating system and can be distinguished by their operating system, meaning different nodes run different operating systems. In other words, the hardware and software required to run an operating system can be considered to belong to the same node. A node can be a complete physical machine, such as a terminal, network device, server, or server agent. A node can also be a component within a physical machine, such as a processor, memory, or storage. If a physical machine contains two nodes, each running different operating systems—for example, a central processing unit (CPU) running operating system 1 and a graphics processing unit (GPU) running operating system 2—the CPU and GPU can be considered to belong to different nodes. When a node is a component, it is a relatively independent entity in terms of hardware. "Independent entity" can be understood as a circuit or module with a specific function, packaged or assembled on a physical machine. A physical machine refers to a computer packaged into a single product, such as a server, desktop computer, all-in-one computer, laptop, or smartphone.
[0045] Runtime environment: refers to the environment provided for running computer programs. In other words, the runtime environment includes the supporting libraries, data structures, functions, and other components required during the operation of the computer program. They provide the necessary infrastructure to enable the computer program to run on a specific operating system and hardware. Types of runtime environments include virtual machines (VMs), containers, serverless functions, bare metal servers, and Linux processes. Virtual machines include kernel-based virtual machines (KVMs), and containers include Linux containers, Docker containers, or Wasm containers. In some embodiments, a runtime environment is also called a runtime instance.
[0046] Unified scheduling: refers to transparently integrating different types of runtime instances and their resources, providing unified task scheduling and resource management capabilities to implement task scheduling across runtime instances.
[0047] Runtime instance resources: These are resources allocated to a runtime instance using virtualization technology, using at least one of the node's computing resources and network resources. These resources include computing resources such as CPU and memory, network resources such as bandwidth, and memory resources such as memory space. The amount of resources allocated to a runtime instance represents the runtime instance's specifications, and the specifications of different runtime instances may be the same or different.
[0048] Task: refers to a computer program (such as an application) running in a runtime instance. At least one task can run in the same runtime instance. The tasks running in the same runtime instance constitute the task set of the runtime instance.
[0049] Service scheduling: refers to scheduling services between different runtime instances of the same runtime type.
[0050] Instance scheduling: Schedules runtime instances between different nodes. The runtime types of the runtime instances in different nodes may be the same or different.
[0051] Flexible computing: is a resource allocation method based on dynamic load matching, designed to achieve efficient utilization of the underlying resources of runtime instances. Flexible computing maximizes runtime resource utilization and optimizes resource allocation by transforming the basis for resource allocation from static fixed specifications to dynamically changeable task load instances. Specifically, while ensuring that the quality of service (QoS) of the task is not degraded, flexible computing uses the load of the business as the key factor in resource allocation, and dynamically adjusts the resources required for business runtime based on the real-time resource demand of the business, thereby improving the flexibility and responsiveness of the system while reducing resource waste and energy consumption. Flexible computing can not only improve resource utilization, but also reduce costs for tenants, improve business efficiency and competitiveness.
[0052] CPU core load performance: This is a core-level performance indicator of the CPU, used to indicate the CPU load. Core load performance includes at least one of the CPU's task clock, context switches, CPU migrations, page faults, cycles, instructions per cycle (IPC), stalled cycles per instruction, branches, branches-misses, L1-dcache loads, L1-dcache load misses, last level cache loads (LLC-loads), and last level cache loads-misses (LLC-loads).
[0053] Task-clock: refers to the CPU time the processor uses to execute tasks, measured in milliseconds (ms).
[0054] context-switches: refers to the number of context switches that occur during service operation.
[0055] cpu-migrations: refers to the number of CPU migrations that occur during service operation. A CPU migration means that a service is transferred from one CPU to another.
[0056] Page-faults: refers to the number of page faults that occur when the CPU accesses memory during business operations. A page fault occurs when the CPU cannot query the mapping between the virtual address to be accessed in the virtual space and the physical memory through the memory management unit (MMU). In the event of a page fault, the CPU interrupt can be used to call a processing function to access the physical memory.
[0057] IPC: refers to the number of instructions that the CPU can complete in one clock cycle. The IPC value is positively correlated with the CPU performance. The higher the IPC value, the better the CPU performance.
[0058] Stalled cycles per instruction: refers to the number of clock cycles in which the CPU is stalled to complete each instruction. The value of stalled cycles per instruction is negatively correlated with CPU performance. The smaller the value of stalled cycles per instruction, the better the CPU performance.
[0059] Branches: refers to the number of times the CPU makes branch predictions within a period of time.
[0060] branches-misses: refers to the number of CPU branch prediction failures within a period of time. The value of branches-misses is negatively correlated with CPU performance. The smaller the value of branches-misses, the better the CPU performance.
[0061] L1-dcache-loads: refers to the number of times the CPU reads data from the first-level cache within a period of time.
[0062] L1-dcache-load-missed: refers to the number of times the CPU fails to read data from the L1 cache within a period of time.
[0063] LLC-loads: refers to the number of times the CPU reads data from the last-level cache within a period of time.
[0064] LLC-load-misses: The number of times the CPU fails to read data from the last-level cache within a period of time.
[0065] Next, the embodiments of the present application will be described in further detail with reference to the accompanying drawings.
[0066] Figure 1 is an architecture diagram of a resource scheduling system based on cloud computing technology provided in an embodiment of the present application. Referring to Figure 1, the resource scheduling system 100 includes a platform access device 11, a control device 12, a scheduling device 13 and a storage control device 14, wherein the platform access device 11 is connected to other devices in the resource scheduling system 100. The platform access device 11 is a device in the resource scheduling system 100 that connects to the cloud management platform 21 of the runtime instance. Other devices in the resource scheduling system 100 can exchange information with the cloud management platform 21 of the runtime instance through the platform access device 11.
[0067] Next, the functions of the cloud management platform 21 of the runtime instance and each device in the resource scheduling system 100 are introduced through the following (1)-(5).
[0068] (1) Cloud management platform for runtime instances 21
[0069] There are multiple types of cloud management platforms 21 in the resource scheduling system 100. As shown in FIG1 , these multiple types of cloud management platforms 21 are all cloud management platforms that provide infrastructure as a service (IaaS). There is at least one cloud management platform 21 of each type. Cloud management platforms 21 of the same type manage the same type of runtime instances, while cloud management platforms 21 of different types manage different types of runtime instances. As shown in FIG1 , three types of cloud management platforms 21 are shown, namely OpenStack, Kubernetes, and Serverless. The runtime instances corresponding to OpenStack, Kubernetes, and Serverless are virtual machine instances, container instances, and serverless function instances, respectively. A virtual machine instance is a virtual machine, a container instance is a container, and a serverless function instance is a serverless function.
[0070] Any cloud management platform 21 has management functions for runtime instances of the same type, such as creating and deleting runtime instances, scheduling services between multiple runtime instances of the same type, and obtaining relevant information of the runtime instances.
[0071] As shown in Figure 1, each cloud management platform 21 is connected to multiple nodes 22 respectively. The cloud management platform 21 can establish a runtime instance on the node 22 to which it is connected to configure the runtime instance. Taking the virtual machine instance as an example, OpenStack establishes virtual machines on nodes 0 and 3 respectively. OpenStack can dispatch the business running on the virtual machine in node 0 to the virtual machine in node 1. Taking the container instance as an example, Kubernetes establishes containers on nodes 1 and 4 respectively. Kubernets can dispatch the business running on the container in node 1 to the container in node 4. Taking the function instance as an example, Serverless establishes serverless functions on nodes 2 and 5 respectively. Serverless can dispatch the business running on the serverless function in node 2 to the serverless function in node 5. Of course, business scheduling can also be performed between multiple runtime instances in the same node 22.
[0072] The cloud management platform 21 can manage each runtime instance of the cloud management platform 21 and perform task scheduling between each runtime instance according to the needs of the user (such as the administrator of the cloud management platform 21 or the tenant of the runtime instance). Taking the cloud management platform 21 as OpenStack and OpenStack creating a virtual machine as an example, referring to the interaction diagram of a resource scheduling system and OpenStack provided by an embodiment of the present application shown in FIG2, the user 1 issues an instruction to create a virtual machine (VM) to the application programming interface (API) combination in the management plane of OpenStack. The API combination calls the nova API based on the instruction to create the VM. After the nova API receives the call request for creating the VM, it issues a command to create the VM to the nova conductor. Based on the command, the nova conductor sends a command to create the VM to the node 22 through the nova compute on the host side to create the VM on the node 22. The API combination is a unified calling interface composed of multiple APIs. The nova API and the nova conductor are respectively used to create and manage VMs. The nova compute is used to send commands to the VM or the node 22 where the VM is located to obtain the status information of the VM.
[0073] Taking the cloud management platform 21 as Kubernetes and Kubernetes creating containers as an example, refer to the schematic diagram of the interaction between a resource scheduling system and Kubernetes provided in an embodiment of the present application shown in Figure 3. User 2 issues an instruction to create a container to the application programming interface service (API Server) in the management plane of Kubernetes. The API Server calls the Pod API based on the instruction to create the container. After receiving the call request for creating the container, the Pod API sends a command to create the container to the ReplicationController API. Based on the command, the ReplicationController API creates the container on node 22 through the kubelet. Among them, the API Server is one of the most important components in Kubernetes, responsible for managing all API resources in Kubernetes. The Pod API is used to create and manage containers. The ReplicationController API is an API interface for creating and managing ReplicaSet and Deployment resources. By creating and managing ReplicaSet resources and Deployment resources, it can create, expand, shrink, and update Pod sets. The kubelet is an agent running on each node 22 in Kubernetes, responsible for interacting with the API Server and managing containers.
[0074] (2) Platform access device 11
[0075] The platform access device 11 is a device in the resource scheduling system 100 that connects to the cloud management platform 21. The platform access device 11 supports access to multiple cloud management platforms 21. Taking Figure 1 as an example, the platform access device 11 is connected to three cloud management platforms 21, namely OpenStack, Kubernetes, and Serverless. It should be understood that Figure 1 only illustrates the platform access device 11 accessing these three cloud management platforms 21 as an example. In other embodiments, the platform access device 11 may connect to any two of the three cloud management platforms 21, or may be connected to at least four cloud management platforms 21. These at least four cloud management platforms 21 may include the three cloud management platforms 21 shown in Figure 1 and other cloud management platforms 21 (such as cloud management platforms for runtime instances such as bare metal servers), or may not include the three cloud management platforms 21 shown in Figure 1. Here, the embodiments of the present application do not limit the number of cloud management platforms 21 supported by the platform access device 11.
[0076] In one possible implementation, the platform access device 11 is connected to the cloud management platform 21 through a platform access interface. For example, the platform access device 11 is configured with multiple platform access interfaces, and the multiple platform access interfaces support access to different cloud management platforms 21. As shown in Figure 1, the platform access device 11 deploys these multiple platform access interfaces to different cloud management platforms 21 to achieve access (i.e., connection) to multiple cloud management platforms 21. Any platform access interface meets the service protocol supported by the accessed cloud management platform, such as the platform access interface deployed on OpenStack supports the virtual machine as a service (VaaS) protocol, the platform access interface deployed on Kubernetes supports the container as a service (CaaS) protocol, and the platform access interface deployed on Serverless supports the container as a service (FaS) protocol. The platform access device 11 or other devices other than the platform access device 11 can interact with the cloud management platform 21 connected to the platform access interface by calling the platform access interface, such as sending instructions to the cloud management platform 21, or obtaining relevant information of the runtime instance from the cloud management platform 21, so that each device can effectively manage and schedule the resources of the cloud management platform 21, thereby effectively unifying the scheduling of business operations and improving the overall efficiency and stability of the system.
[0077] In one possible implementation, the platform access interface provided by the platform access device 11 for the same cloud management platform 21 includes a management layer interface and a host layer interface. The management layer interface is used to connect to the management side interface of the cloud management platform 21 (the interface for managing and creating runtime instances), and the host layer interface is used to connect to the host side interface of the cloud management platform 21 (such as the interface on the host side for collecting relevant information of runtime instances).
[0078] Taking the platform access device 11 interfacing with OpenStack as an example, as shown in Figure 2, the management layer interface and host layer interface provided by the platform access device 11 for OpenStack are the management layer VaaS interface and the host layer VaaS interface, respectively. The management layer VaaS interface connects to the API combination and nova conductor in the management plane of OpenStack to create and delete VMs through the API combination. The nova conductor interface schedules services for VMs to manage virtual machines. The host layer VaaS interface connects to libvirt on the host side of OpenStack to obtain VM-related information from libvirt. libvirt is a general virtualization interface used to obtain detailed information about VMs. The nova compute interface can send the status information of each VM to libvirt so that libvirt can collect the VM's status information. It should be understood that libvirt can also collect other VM information in addition to status information to obtain detailed information about the VM.
[0079] Taking the docking of the platform access device 11 with Kubernetes as an example, as shown in FIG3 , the management layer interface and host layer interface provided by the platform access device 11 for Kubernetes are the management layer CaaS interface and the host layer CaaS interface, respectively. The management layer CaaS interface is connected to the API Server and Pod API in the management plane of Kubernetes, so that containers can be created through the API Server and the containers can be scheduled or deleted through the Pod API to manage the containers. The host layer CaaS interface is connected to the metrics on the host side of Kubernetes to obtain relevant information about the container from the metrics. Among them, metrics is a monitoring system used to obtain status information and performance indicator data of each container. Kubelet can send the status information of each container to metrics so that metrics can collect the status information and performance indicator data of the container.
[0080] All devices in the resource scheduling system 100 except the platform access device 11 can call these multiple platform access interfaces. At the same time, the platform access device 11 may receive call requests for multiple platform access interfaces from multiple other devices. The platform access device 11 can process the call requests for multiple platform access interfaces in parallel, thereby being able to efficiently process the call requests in a multi-threaded manner.
[0081] In one possible implementation, the platform access device 11 also adheres to security and scalability constraints to ensure the entire system can operate securely and support large-scale business processing. For example, the platform access device 11 is also configured with a configuration interface, which is used to load and remove the platform access interface in the platform access device 11. This allows the platform access device 11 to support dynamic loading and unloading of plug-in services, allowing for easy expansion and replacement of the platform access interface's functionality to meet the needs of different business scenarios.
[0082] The multiple platform access interfaces and configuration interfaces configured by the platform access device 11 are all APIs, so that the resource scheduling system 100 provides a rich set of APIs through the platform access device 11, so that devices / modules outside the resource scheduling system 100, devices within the resource scheduling system 100, or users can conveniently manage and schedule resources of different cloud management platforms 21. In one possible implementation, the multiple platform access interfaces and configuration interfaces configured by the platform access device 11 are all plug-in interfaces, so that devices / modules outside the resource scheduling system 100, devices within the resource scheduling system 100, or users can manage and schedule resources of different cloud management platforms 21 by using plug-ins.
[0083] In one possible implementation, the platform access device 11 also supports business process configuration, customizing business processes based on user needs. For example, a set of business processes can be customized for each of the multiple cloud management platforms 21 so that devices inside and outside the resource scheduling system 100 can interact with the cloud management platform according to the corresponding business processes.
[0084] In one possible implementation, the platform access device 11 is also responsible for managing resources and services on each cloud management platform 21. The platform access device 11 also has management functions for various types of runtime instances, such as container orchestration, virtual machine management, etc., to meet the needs of different users.
[0085] It should be understood that the platform access device 11 provides a set of standard interfaces so that different services of various types of runtime instances can be seamlessly integrated into the resource scheduling system 100 , which is a business automation scheduling system.
[0086] The above-mentioned various possible implementations of the platform access device 11 can be further combined to provide more implementations. It should be understood that the platform access device 11 can access the cloud management platform 21 of multiple types of runtime instances, thereby achieving management and scheduling across multiple runtime instances.
[0087] (3) Control device 12
[0088] The control device 12 is the control center of the resource scheduling system 100, which is used to manage the operating status of the resource scheduling system 100. For example, it has multiple functions such as providing API interface, recording logs and monitoring system operation status. Of course, in addition to this, the control device 12 may also have other management functions for the resource scheduling system 100.
[0089] The control device 12 has a management function for the runtime instances of all cloud management platforms 21 connected to the platform access device 11. Exemplarily, the control device 12 interacts with each underlying cloud management platform 21 through the platform access device 11. By interacting with each cloud management platform 21, the control device 12 performs lifecycle management on the runtime instances of each cloud management platform 21 and collects relevant information about each runtime instance of each cloud management platform 21. The relevant information about any runtime instance includes the internet protocol (IP) address of the runtime environment, the tag of the runtime environment, the image / runtime instance used in the runtime environment, the name of each service running in the runtime environment, the operating status of each service, and the consumption of various resources of the runtime instance.
[0090] Taking OpenStack as an example, as shown in Figure 2 , control device 12 invokes the management-layer VaaS interface in platform access device 11 to send instructions to the API combination in OpenStack to create or delete a VM. Based on the instructions, the API combination invokes the nova API to create or delete a VM in node 22. Control device 12 also invokes the host-layer VaaS interface in platform access device 11 to send instructions to libvirt to obtain information about each VM from the information collected by libvirt.
[0091] Taking Kubernetes as an example, as shown in Figure 3, the control device 12 calls the management-level CaaS interface in the platform access device 11 to send instructions to the API Server in Kubernetes to create or delete containers. The API Server calls the Pod API based on the instructions to create containers in the node 22. The control device 12 calls the host-level CaaS interface in the platform access device 11 to send instructions to the metrics in Kubernetes to obtain relevant information about each container from the information collected by the metrics.
[0092] The control device 12 and each cloud management platform 21 provide an access interface (such as an interface or API). The tenant can operate the client to remotely access the access interface and purchase a runtime instance in the resource purchase interface. After the payment is successfully made, the control device 12 (or cloud management platform 21) allocates the purchased runtime instance to the tenant at node 22, and provides the remote login account and password of the purchased runtime instance. The client can remotely log in to the runtime instance and install and run the tenant's business in the runtime instance.
[0093] The resource purchase interface offers both elastic and flexible billing options, or offers both. Elastic billing and flexible billing correspond to two resource adjustment modes: elastic adjustment mode and flexible scheduling mode, respectively. Tenants can select either the elastic or flexible billing option to purchase runtime instances on the purchase interface.
[0094] In the elastic billing method, the tenant specifies the specifications of the purchased runtime instance, the control device 12 (or the cloud management platform 21) establishes a runtime instance of the specified specification for the tenant, and runs the tenant's business in the runtime instance of the specified specification. In the elastic adjustment mode, the scheduling device 13 schedules the tenant's business to other runtime instances of the specified specification when scheduling the runtime instance for the tenant's business. In the elastic billing method, billing is performed according to the specified specifications. If the amount of resources required by the group's business during operation reaches the unspecified specifications, part of the resources of the runtime instance where the business is located will be wasted, but the fee is calculated according to the specified specifications. Therefore, unnecessary expenses for the tenant will be increased.
[0095] In the flexible billing method, the tenant specifies the maximum size of the runtime instance to be purchased. In the flexible adjustment mode, the scheduling device 13 first establishes a runtime instance of the maximum size for the tenant. When the tenant's business runs in the runtime instance, if the QOS of the application deteriorates, the control device 12 determines the amount of resources required to run the business, and determines the new amount of resources to be allocated to the business based on the flexible calculation method and the amount of resources required to run the business. The new amount of resources of other runtime instances are allocated to the business, and the business is run in other runtime instances. Alternatively, other businesses in the runtime instance where the business is located are terminated, the resources occupied by other businesses are released, and resources are allocated to the business from the released amount of resources, so that the business has the new amount of resources. In the flexible billing method, billing is based on the actual amount of resources used by the business, and the actual amount of resources used is lower than the maximum size of resources specified by the tenant. Therefore, the flexible billing method can avoid unnecessary expenses for tenants, avoid wasting resources of runtime instances, and increase the resource utilization of runtime instances. It is a win-win strategy for cloud providers and tenants.
[0096] If a tenant purchases a runtime instance from any cloud management platform 21, the cloud management platform 21 reports the tenant's purchase information to the control device 12 via the platform access device 11. If the tenant purchases the runtime instance through the purchase interface provided by the control device 12, the control device 12 can obtain the purchase information without having to obtain the purchase information from the cloud management platform 21. The purchase information includes the tenant's identifier, the identifier of the billing method selected by the tenant when purchasing the runtime instance, and the specifications of the purchased runtime instance, which include the resource quantity of at least one resource.
[0097] After obtaining the purchase information, the control device 12 allocates a runtime instance to the tenant based on the purchase information. Exemplarily, the control device 12 sends a runtime instance allocation request to the scheduling device 13 based on the purchase information. The runtime instance allocation request includes the purchase information to indicate that a runtime instance that meets the specification information is allocated to the tenant. After receiving the runtime instance allocation request, the scheduling device 13 allocates a runtime instance to the tenant based on the specifications in the runtime instance allocation request. For example, the scheduling device 13 is configured with a resource pool, which includes the identifiers of multiple idle runtime instances and the specifications of each idle runtime instance. The multiple idle runtime instances are runtime instances that have not been used in each cloud management platform 21 accessed by the resource scheduling system 100. The scheduling device 13 can allocate a runtime instance of the specified specifications (i.e., the specifications in the purchase information) to the tenant from the idle resource pool. Alternatively, the scheduling device 13 does not allocate a runtime instance to the tenant from the resource pool. The scheduling device 13 establishes a runtime instance that can meet the tenant's specified specifications on the cloud management platform 21 and allocates the established runtime instance to the tenant. After allocating the runtime instance to the tenant, an allocation completion response is sent to the control device 12, which includes the remote login account and password of the runtime instance allocated to the tenant. Then, the control device 12 returns the remote login account and password to the tenant.
[0098] The runtime instance allocation request also indicates that the tenant's business is scheduled according to the resource adjustment mode corresponding to the payment method selected by the tenant. During the operation of the tenant's business in the runtime instance, the control device 12 detects whether the business meets the scheduling conditions. If the scheduling conditions are met, the business is scheduled in the runtime instances of multiple cloud management platforms 21.
[0099] The control device 12 can also perform task scheduling and management of runtime instances of each cloud management platform 21 according to user needs. For example, the user can issue an instruction to the control device 12 to instruct the creation or deletion of a runtime instance on a certain cloud management platform 21. Then, based on the instruction, the control device 12 notifies the certain cloud management platform 21 through the platform access device 11 to create or delete the runtime instance. For another example, instance scheduling can be performed between different nodes 22. For example, a container instance in node 1 can be scheduled to node 0, so that two types of runtime instances, virtual machines and containers, exist in node 0. For another example, the control device 12 sends the resource adjustment mode of the business running in each runtime instance to the scheduling device 13, and the scheduling device 13 performs business scheduling between different runtime instances and / or instance scheduling between different nodes 22 according to the resource adjustment mode of the business.
[0100] The resource scheduling system 100 supports multiple tenants, and the control device 12 also supports security management of the services of multiple tenants. For example, the control device 12 provides isolation protection measures for the services of each tenant to isolate and protect the services of different tenants.
[0101] (4) Scheduling device 13
[0102] The scheduling device 13 is a device in the resource scheduling system 100 responsible for service scheduling and instance scheduling. It can perform service scheduling between multiple runtime instances of the same type and instance scheduling between different nodes, thereby realizing resource scheduling across runtime instances.
[0103] The scheduling device 13 can communicate directly with the control device 12 or indirectly through the platform access device 11. The scheduling device 13 can obtain the resource adjustment mode for each service from the control device 12 and monitor the resource usage of each runtime instance. This allows different nodes 2 to schedule services between various types of runtime instances based on the resource usage of each runtime instance and the resource adjustment mode of the services running in each runtime instance. The scheduling device 13's multiple resource adjustment modes and efficient design ensure the confidentiality and integrity of data and services.
[0104] In one possible implementation, after any service is scheduled, during the operation of the service, the scheduling device 13 also monitors the operation of the service in the scheduled runtime instance. If an abnormality occurs in the operation of the service, the scheduling device 13 performs abnormal processing on the service, such as scheduling the service to a newly obtained runtime instance. Of course, the scheduling device 13 may not monitor the operation of the service and not perform abnormal processing on the service, and the control device 12 may monitor the operation of the service and perform abnormal processing on the service.
[0105] FIG1 shows an example in which the control device 12 and the scheduling device 13 are different devices. In other embodiments, the control device 12 and the scheduling device 13 may be integrated into the same device. In this case, the control device 12 and the scheduling device 13 are both a module of the device.
[0106] (5) Storage control device 14
[0107] The storage control device 14 is a device in the resource scheduling system 100 responsible for reading and writing data, and is used to provide data storage services for other devices in the resource scheduling system 100 and various cloud management platforms 21 connected to the resource scheduling system 100.
[0108] The storage systems supported for configuration by different cloud management platforms 21 may be the same or different. The same cloud management platform 21 supports the configuration of at least one storage system. For example, OpenStack supports the configuration of a block storage system or an object storage system. When OpenStack is configured with a block storage system, OpenStack can access the block storage subsystem through Cinder. When OpenStack is configured with an object storage system, OpenStack can access the object storage system through Swift. Cinder introduces a layer of "logical storage volume" abstraction between virtual machines and storage nodes. Cinder provides a plug-in mechanism for integration with multiple storage backends, such as logical volume manager (LVM), network file system (NFS), scalable network file system (Gluster file system, GlusterFS), etc., so that Cinder supports different types of storage nodes. Cinder manages the corresponding backend storage by calling the driver interface of different storage backend types, providing users with a unified storage interface for volume-related operations. Swift provides a hypertext transfer protocol (HTTP) API and an object storage protocol. Swift can store data in a distributed storage system through an API or a direct object storage protocol. For example, Kubernetes supports configuring persistent storage systems. Kubernetes can implement persistent storage using persistent volumes (PVs) and persistent volume claims (PVCs). A PV represents a storage resource, which can be a local storage device on a host or a storage volume on a remote storage server. A PVC represents a request for storage resources from an application (such as a running business).
[0109] In order to be able to connect to the storage systems supported and configured by each cloud management platform 21, the storage control device 14 includes multiple storage access interfaces. These multiple storage access interfaces correspond to different cloud management platforms 21, and the storage access interfaces support access to the storage systems configured by the corresponding cloud management platforms 21. In the case where the same cloud management platform 21 supports the configuration of multiple storage systems, the cloud management platform 21 can also correspond to multiple storage access interfaces so that the configured storage systems can be accessed through the corresponding storage access interfaces. The storage access interface and the storage system it supports access use the same storage protocol so that the storage access interface can interact with the storage system it supports access. For example, when devices inside or outside the resource scheduling system 100 or the cloud management platform 21 need to access a certain storage system, they can access the storage system by calling the storage access interface to which the storage system is connected, so as to read and write data in the storage system.
[0110] In one possible implementation, the resource scheduling system 100 also provides a distributed storage system, which includes multiple storage subsystems, each storage subsystem includes multiple storage nodes, and the storage nodes are used to store data. The types of the multiple storage subsystems are different, and the storage protocols supported by the multiple storage subsystems are different. The data stored by each storage node in the same storage subsystem has the same type or format. The data stored by the storage nodes in different storage subsystems have different types or formats. The multiple storage subsystems include at least two of the block storage system, object storage system, file storage system, and persistent storage system. Of course, there may also be other types of storage subsystems. Here, the embodiment of the present application does not limit the system type of each storage subsystem in the distributed storage system.
[0111] These multiple storage subsystems support the configuration of different cloud management platforms 21. The storage subsystems are used to store relevant information of the runtime instance of the configured cloud management platform 21 and business data of each business run by the runtime instance of the cloud management platform 21 (such as data generated during the business operation). The storage control device 14 is the control core in the distributed storage system. The various storage access interfaces of the storage control device 14 are respectively connected to these multiple storage subsystems. When any cloud management platform 21 is connected to the resource scheduling system 100, the control device 12 configures a storage subsystem for the cloud management platform 21 from these multiple storage subsystems. Of course, the cloud management platform 21 may also have its own storage system. The control device 12 (or cloud management platform 21) controls the storage system to be connected to the corresponding storage access interface in the storage control device 14, so that subsequent devices inside and outside the resource scheduling system 100 can access the storage system through the storage access interface.
[0112] Each cloud management platform 21 can access the storage system (such as a sub-storage system or its own storage system) configured for the cloud management platform 21 through the platform access device 11 and the storage control device 14. For example, the cloud management platform 21 sends a data read / write request to the platform access device 11 through the platform access interface to which it is connected, to indicate that the storage configured for the cloud management platform 21 should be read and written. After receiving the data read / write request, the platform access device 11 sends a data read / write request to the storage control device 14. After receiving the data read / write request from the platform access device 11, the storage control device 14 reads and writes data in the storage system configured for the cloud management platform 21 based on the data read / write request. For example, based on the data read / write request, the storage control device 14 sends a read / write instruction to the storage access interface corresponding to the cloud management platform 21. The storage access interface reads and writes data in the storage system configured for the cloud management platform 21 based on the read / write instruction, thereby enabling the cloud management platform 21 to access its own configured storage system based on the resource scheduling system 100.
[0113] In another possible implementation, the resource scheduling system 100 does not provide a distributed storage system. Each cloud management platform 21 connected to the resource scheduling system 100 has its own storage system. The cloud management platform 21 / control device 12 controls the storage system to be connected to the corresponding storage access interface in the storage control device 14, so that subsequent devices inside and outside the resource scheduling system 100 can access the storage system through the storage access interface.
[0114] When a certain service is scheduled from one runtime instance to another runtime instance, the storage control device 14 can also convert the format of the service data generated when the runtime instance of the service was originally running, so that the data format of the converted service data meets the requirements of the runtime instance to be scheduled, thereby enabling data sharing and collaboration between different types of runtime instances.
[0115] When storing data in the storage system configured on the cloud management platform 21, the storage control device 14 can also use distributed storage technology to copy and back up data to multiple storage nodes 22 of the storage system to ensure data reliability and fault tolerance, improve data availability and security, and cope with unforeseen failure situations. The storage control device 14 can also use a load balancing strategy to distribute the load between the various storage nodes 22 in the storage system, thereby improving the scalability and concurrency of the system. The storage control device 14 can use a multi-level identity authentication and authority management strategy to ensure system security and manageability. The storage control device 14 can also provide monitoring and logging functions to facilitate user management and maintenance of the distributed storage system.
[0116] The storage control device 14 is also connected to a target storage system, which may be a storage system configured separately for the resource scheduling system 100 or a storage system configured for a cloud management platform. The target storage system is used to provide data storage services for each device in the resource scheduling system 100. Information collected by the control device 12 in the resource scheduling system 100, information required by the scheduling device 13 during the scheduling process, configuration information of the platform access device 11, configuration information of the control device 12, configuration information of the scheduling device 13, configuration information of the storage control device 14, and the consumption and remaining status of storage resources of each storage system connected to the storage control device 14 can all be stored in the target storage system. The information collected by the control device 12 includes information related to each runtime resource of each cloud management platform, purchase information of each tenant, resource adjustment mode and billing mode of each tenant's business, resource consumption and remaining status of each node configured by each cloud management platform, etc. Information required by the scheduling device 13 during the scheduling process includes, for example, the resource adjustment mode of the business, purchase information of the tenant to which the business belongs, and all or part of the relevant information of the runtime instance to which the business belongs.
[0117] Based on the above introduction to each device in the resource scheduling system 100, the resources of all cloud management platforms 11 connected to the resource scheduling system 100 can constitute the global resources of the resource scheduling system 100. As shown in Figure 4, a global resource diagram of a resource scheduling system provided by an embodiment of the present application, global resources include runtime instance resources and host-side resources. Runtime instance resources include runtime instances (such as virtual machines, containers, Linux processes, serviceless functions, etc.) in each node 22 of all cloud management platforms 11. Host-side resources refer to the hardware resources and software resources of all nodes 22 of all cloud management platforms, such as CPU, memory, input and output (IO) external devices, and software resources such as file systems. The host-side resources of each node 22 can be managed by the operating system (OS) of each node 22 respectively. The operating system of node 22 is also called cloud OS.
[0118] Each device in the resource scheduling system 100 can manage the runtime instance resources of each cloud management platform 21 by calling the plug-in on the host side of each cloud management platform 21. For example, by calling nova compute in Openstack, the status information of each virtual machine managed by Openstack can be obtained. For another example, by calling kubelet in Kubernetes, the business of the container managed by Kubernetes can be scheduled. For another example, by calling the high performance computing (HPC) agent / Hadoop agent (angent) of the cloud management platform for Linux processes, the Linux process can be managed. Thus, the resource scheduling system 100 can globally manage multiple types of runtime instances.
[0119] The control device 12 and / or the scheduling device 13 can interact with the OS of each node 22 by calling the plug-in on the host side of each cloud management platform 21 to determine the hardware resources and software resources of each node 22 and collect the consumption of the hardware resources and the usage of the software resources of each node, so as to monitor the global hardware resources, global software resources, resource consumption of global hardware resources and usage of global software resources of the resource scheduling system 100 in real time, so as to create and manage runtime instances in each node 22 based on the global hardware resources, global software resources, resource consumption of global hardware resources and usage of global software resources. In some embodiments, the same type of runtime instance can be established on the nodes 22 of the same cloud management platform 21, or multiple types of runtime instances can be established on the nodes 22 of the same cloud management platform 21, so as to achieve sharing of hardware resources and software resources on the host side of multiple cloud management platforms 12, and to globally manage the hardware resources and software resources on the host side of multiple cloud management platforms 12.
[0120] The resource scheduling system 100 globally manages the runtime instance resources, host-side hardware resources, and software resources of all connected cloud management platforms 12 to integrate the relevant information of runtime instances of various types of cloud management platforms 12. This can solve the information isolation problem between different types of cloud management platforms, and can also solve the information isolation problem between multiple cloud management platforms of the same type. The information in the information isolation can be information about runtime instances, hardware resources, and soft resources, etc.
[0121] Because the platform access device 11 supports access to multiple cloud management platforms 21, the other devices in the resource scheduling system 100 can interact with different cloud management platforms 21, so that the control device 12 can uniformly manage the runtime instances of multiple cloud management platforms 21, so that the scheduling device 13 can uniformly schedule services between the runtime instances of multiple cloud management platforms 21, and so that the storage control device 14 can provide storage services for multiple cloud management platforms 21. As a result, the resource scheduling system 100 can provide consistent business scheduling services for tenants' applications, simplifying the business management process, improving management efficiency, and reducing operation and maintenance costs. Based on the architecture of the resource scheduling system 100, it is possible to achieve automated deployment and scheduling of distributed applications, thereby improving business processing efficiency and resource utilization. Because the platform access device 11 and the control device 13 are configured to support flexible configuration interfaces, the resource scheduling system 100 has good scalability and flexibility and can adapt to various business scenarios and needs. In summary, the resource scheduling system 100 is a unified business scheduling system architecture that can achieve scheduling across multiple runtime instances, and this architecture has efficient resource utilization and business benefits.
[0122] In another possible implementation, the resource management system 100 is used to manage the resources of multiple nodes 22, and the multiple nodes 22 are divided into hybrid nodes and non-hybrid nodes, wherein there are multiple hybrid nodes, and a hybrid node refers to a node that supports at least two types of runtime instances, and the types of the runtime instances include containers, virtual machines, serverless functions, or other runtime types. A non-hybrid node supports one type of runtime instance. For example, a node that only supports the deployment of virtual machines is a non-hybrid node (called a virtual node), and a node that only supports the deployment of containers is a non-hybrid node (called a container node). For example, the resource scheduling system in Figure 6 manages K (K>2) hosts, each host is a node, wherein host 1 is a virtual machine node, host 2 is a container node, and host K is a hybrid node. For any node 22, the control device 12 can also configure the node 22 as a hybrid node or a non-hybrid node, so as to create different types of runtime instances in the hybrid node and create a runtime instance that supports one runtime type in the non-hybrid node. Since the hybrid node supports at least two types of runtime instances, hybrid deployment across runtime instances can be achieved. Next, the method of hybrid deployment of runtime instances is introduced as follows in conjunction with Figure 5.
[0123] Figure 5 is a flow chart of a hybrid deployment method across runtime instances based on cloud computing technology, provided by an embodiment of the present application. This method is accomplished through interaction between a client and a resource scheduling system, wherein the resource scheduling system is used to manage the resources of multiple hybrid nodes. Based on this, the process of deploying runtime instances is executed by the resource scheduling system, which is the cloud computing-based resource scheduling system described above. The method includes the following steps:
[0124] 501. The client sends the instance configuration request to the resource scheduling system. The instance configuration request is used to instruct to deploy a target instance on a hybrid node. The runtime type of the target instance is a type of runtime instance.
[0125] Among them, the target instance is any runtime instance purchased by any tenant, and the runtime type of the target instance is a container, a virtual machine, a serverless function or other runtime type. The target instance is used to run the tenant's business (referred to as the target business). Among them, the instance configuration request includes at least one of the identifier of the target runtime type, the identifier of the target node type, the identifier of the target adjustment mode, the target specification information and the instance priority information, wherein the target runtime type is the runtime type of the target instance, the target node type is the type of the node used to deploy the target instance, and the node type is divided into hybrid node type and non-hybrid node type. The target adjustment mode is the resource adjustment mode (elastic adjustment mode or flexible adjustment mode) supported by the target instance, and the target specification information is the specification of the target instance under the target adjustment mode. The instance priority information is used to determine the service quality of the target instance at the node.
[0126] Taking the hybrid deployment process shown in Figure 6 as an example, after a tenant purchases a target instance or purchases a target instance, the tenant configures the instance parameters of the target instance in the instance configuration interface provided by the client to apply for instance creation. As shown in Figure 6, the instance configuration interface includes runtime type configuration options, hybrid deployment configuration options, priority configuration options, and scheduling mode configuration options. The runtime type configuration option is used to configure the target runtime type. The runtime type configuration option provides multiple runtime types. The tenant selects any of the multiple runtime types. In response to this selection, the client determines the runtime type as the target runtime type.
[0127] The hybrid deployment option is used to confirm whether the tenant accepts deploying the target instance on a hybrid node. If the tenant confirms acceptance of the hybrid deployment option, the client, in response to the acceptance confirmation, determines the hybrid node type as the target node type. If the tenant confirms rejection of the hybrid deployment option, the client, in response to the rejection confirmation, determines the non-hybrid node type as the target node type. In one possible implementation, based on the business requirements of the target business, the tenant can select a target runtime type and a target node type for the target instance. As shown in Figure 6, if the target business requires secure operation, the tenant can select a virtual machine as the target runtime type and a non-hybrid node as the target node type, thereby selecting to establish the target instance on a virtual machine node. If the target business requires high performance, the tenant can select a container as the target runtime type and a non-hybrid node as the target node type, thereby selecting to establish the target instance on a container node. If the target business has less stringent requirements for secure operation and performance, such as requiring only local access, the tenant can select a hybrid node as the target node type, and the target runtime type can be selected based on other business requirements.
[0128] The priority configuration option is used to configure the instance priority information of the target instance. The priority configuration option provides multiple business priorities. Different business priorities correspond to different service quality levels. As shown in Figure 6, there are three business priorities, namely high business priority, medium business priority and low business priority. The service quality levels corresponding to these three business priorities decrease in sequence. In another possible implementation, there may be more than three or less than three business priorities. The number of business priorities is not limited here. Different business priorities are set to meet the service quality requirements of different businesses. The tenant selects any one of the multiple business priorities, and the client responds to the selection operation and determines the identifier of any one of the business priorities as the instance priority information of the target instance.
[0129] The Scheduling Mode Configuration option is used to configure the target adjustment mode and target specification information. The Adjustment Mode Configuration option includes the Elastic Adjustment Mode sub-option and the Flexible Mode sub-option. For either of these sub-options, the tenant configures the specifications of the target instance in that sub-option and performs a confirmation selection operation on that sub-option. In response to this confirmation selection operation, the client determines the resource adjustment mode represented by that sub-option as the target adjustment mode and determines the specification information configured in that sub-option as the target specification information.
[0130] The client then generates an instance configuration request based on the determined target runtime type, target node type, target adjustment mode, target specification information, and instance priority information, and sends the request to the resource scheduling system. If the target node type is a hybrid node, the instance configuration request instructs the target instance to be deployed on a hybrid node; if the target node type is a non-hybrid node, the instance configuration request instructs the target instance to be deployed on a non-hybrid node. The information carried in the instance configuration request is the instance parameters of the target instance.
[0131] 502. The resource scheduling system receives the instance configuration request.
[0132] The instance configuration request is an instance configuration request sent by the tenant through the client. If the instance configuration request is used to instruct to deploy the target instance on the hybrid node, the following steps 503 and 504 are executed.
[0133] 503. The resource scheduling system determines a first hybrid node from multiple hybrid nodes according to the instance configuration request.
[0134] The first hybrid node is a hybrid node of a target instance to be deployed, the first hybrid node is the target node of the target instance, and the first hybrid node meets the resource amount required by the target specification information of the target instance.
[0135] In one possible implementation, after receiving the instance configuration request, the resource scheduling system parses the instance configuration request to obtain a target runtime type identifier, a target node type identifier, a target adjustment mode identifier, target specification information, and instance priority information. If the target node type is a hybrid node type, the resource scheduling system determines a first hybrid node from multiple hybrid nodes based on the target specification information. The target specification information includes a target resource amount of at least one resource, where the at least one resource includes at least one of a computing resource and a network resource. The target resource amount of any resource is the amount of resources required by the target instance for that resource.
[0136] For example, the resource scheduling system monitors the idle resource amount of the at least one resource of each hybrid node and the idle resource amount of the at least one resource of each non-hybrid node. The idle resource amount of any resource of any node refers to the unallocated amount or unoccupied amount of the resource in the node. For any hybrid node among the multiple hybrid nodes, if the idle resource amount of the at least one resource of the hybrid node is lower than the target resource amount of the corresponding resource, the hybrid node meets the resource amount required by the target specification information, and the resource scheduling system determines the hybrid node as a first hybrid node.
[0137] If the resources in each of the multiple hybrid nodes do not meet the resource requirements of the target specification information of the target instance, the resource scheduling system may configure a new hybrid node that meets the resource requirements of the target specification information and determine the new hybrid node as the first hybrid node. Alternatively, the resource scheduling system may schedule (or migrate) already created runtime instances among the multiple hybrid nodes so that a hybrid node meets the resource requirements of the target specification information and determine the hybrid node as the first hybrid node. Among them, the method of scheduling business instances, for example, if the sum of the amount of resources occupied by at least one runtime instance in a hybrid node and the amount of idle resources of the hybrid node is equal to or higher than the target resource amount, the at least one runtime instance is scheduled to a third hybrid node to release the amount of resources occupied by the at least one runtime instance in the hybrid node, and the hybrid node is determined as the first hybrid node, wherein the third hybrid node is any hybrid node other than the hybrid node among the multiple hybrid nodes, and there are one or more third hybrid nodes. For example, the at least one runtime instance is scheduled to a third hybrid node, and the amount of idle resources of the third hybrid node meets the amount of resources required by at least one runtime instance. For another example, there are multiple runtime instances to be scheduled in the hybrid node, and each business instance to be scheduled is scheduled to a different third hybrid node, and the amount of idle resources of each third hybrid node meets the amount of resources required by the transferred business instance.
[0138] The first hybrid node is determined by scheduling the created runtime instances among multiple hybrid nodes, so that the fragmented resources in the hybrid nodes are fully utilized.
[0139] 504. The resource scheduling system creates a target instance for the tenant at the first hybrid node.
[0140] For example, the resource scheduling system creates a runtime instance of the target runtime type in the first hybrid node, allocates the target resource amount of the first hybrid node to the runtime instance, and the created runtime instance is also the target instance, and the specifications of the target instance are the specifications required by the target specification information.
[0141] 505. The resource scheduling system sends the target instance's running status information to the client. The running status information includes the identifier of the target instance's running type and node information. The node information is used to indicate that the running environment of the target instance is the first hybrid node.
[0142] The node information includes an identifier of the first hybrid node and an identifier of the hybrid node type.
[0143] For example, after creating the target instance, the resource scheduling system runs the target instance on the first hybrid node, generates the running status information based on the runtime type of the target instance (i.e., the target runtime type), the first hybrid node, and the hybrid node type, and returns the running status information to the client.
[0144] 506. The client receives and displays the running status information.
[0145] Based on the running status information, the tenant can know that the target instance has been established and is running on the first hybrid node. The resource scheduling system can also send the remote login account and password of the target instance together with the running status information to the client, and the client will display the remote login account and password of the target instance so that the tenant can log in to the target instance according to the remote login account and password of the target instance and run the tenant's target business on the target instance.
[0146] In another possible implementation, if the instance configuration request is used to indicate that the target instance is deployed on a non-hybrid node, the resource scheduling system determines a first non-hybrid node from multiple non-hybrid nodes that support the target runtime type, and creates a target instance on the first non-hybrid node, wherein the first non-hybrid node meets the resource quantity required by the target specification information. In this implementation, the first non-hybrid node is the target node of the target instance, and the method for determining the first non-hybrid node is the same as the method for determining the first hybrid node. The process of creating the target instance on the first non-hybrid node is the same as the process of creating the target instance on the first hybrid node. After creating the target instance, the resource scheduling system will also send the target instance's running status information to the client, but at this time, the node information in the running status information is used to indicate that the running environment of the target instance is the first non-hybrid node. Accordingly, at this time, the node information includes the identifier of the first non-hybrid node and the identifier of the non-hybrid node type.
[0147] The runtime instances created for tenants at each node (such as a non-hybrid node or a hybrid node) managed by the resource scheduling system are called business instances. In another possible implementation, the process of creating a business instance in a node can be performed by an intelligent scheduling system in the resource scheduling system, wherein the intelligent scheduling system is equivalent to a control device in the resource scheduling system. As shown in FIG6 , the intelligent scheduling system creates a new business instance at a node of a specific node type based on the instance configuration request of each tenant for each business instance, and manages the life cycle of the business instance through the native API supported by the runtime type of the business instance. A native API refers to a cloud management platform that manages a certain runtime instance. For example, if the business instance is a VM, the native API is Open Stack. If the business instance is a container, the native API is Kubernetes. Based on this, as shown in FIG6 , Open Stack can perform life cycle management on virtual machine nodes and VMs in hybrid nodes, and Kubernetes can perform life cycle management on container nodes and containers in hybrid nodes.
[0148] In another possible implementation, each of the above steps 503 to 505 can be performed by the control device or the scheduling device in the resource scheduling system, or the control device and the scheduling device can be performed in cooperation. For example, the control device executes steps 502 and 503 to determine the first hybrid node, notifies the scheduling device to create a target instance at the first hybrid node, and the scheduling device executes steps 504 and 505 based on the notification, or the scheduling device executes step 504 based on the notification, and the control device executes step 506.
[0149] The method provided in the embodiment of the present application manages the resources of multiple hybrid nodes through a resource scheduling system. Since hybrid nodes support the deployment of multiple types of runtime instances, the resource scheduling system can deploy different types of runtime instances in the hybrid nodes. The specifications of different types of runtime instances vary greatly, and the fragmented resources of the hybrid nodes can be allocated to runtime instances with smaller specifications, so that the fragmented resources of the hybrid nodes can be fully utilized.
[0150] For each non-hybrid node managed by the resource scheduling system and the runtime instances created in each hybrid node, the service quality requirements of different runtime instances may be the same or different. For any runtime instance that has been created, the resource scheduling system can also adjust the resources currently occupied by the runtime instance according to the instance priority information of the runtime instance, so that the adjusted resources can meet the service quality requirements of the runtime instance to ensure the service quality of the runtime instance. Next, taking the target instance established in the first hybrid node as an example, the process of adjusting the resources occupied by the target instance through the resource scheduling method based on cloud computing technology shown in Figure 7 is introduced as follows, wherein the method is executed by the above-mentioned resource scheduling system, such as by the scheduling device in the resource scheduling system, and the method includes the following steps.
[0151] 701. The resource scheduling system obtains instance priority information input by a tenant. The instance priority information is used to determine the quality of service required by the target instance on the first hybrid node.
[0152] The instance priority information includes the service priority of the target instance (referred to as the target priority). The instance priority information of the target instance entered by the tenant is the instance priority information entered by the tenant through the client and included in the instance configuration request of the target instance. Based on this, the resource scheduling system obtains the instance priority information from the instance configuration request of the target instance.
[0153] 702. The resource scheduling system adjusts the resources occupied by the target instance in the first hybrid node according to the instance priority information to meet the service quality requirement of the target instance.
[0154] In one possible implementation, the resource scheduling system detects the service quality of the target instance and determines a resource adjustment strategy for the resources occupied by the target instance based on the detection result and instance priority information, such as the process shown in steps 7021 to 7024 below.
[0155] Step 7021: The resource scheduling system determines the service quality degradation parameter of the target instance based on the core indicator data of the processor core bound to the target instance.
[0156] Among them, the service quality degradation parameter of any runtime instance is used to indicate the degree of degradation of the service quality of the runtime instance during operation. The processor core bound to any runtime instance is the processor core that provides computing services for the runtime instance, in other words, the processing core that runs the runtime instance. The core indicator data of any processor core includes at least one of the business clock of the processor core, the number of context switches, the number of processor core migrations, the number of page faults, the clock cycle, the number of instructions per clock cycle, the number of instruction stall cycles, the number of branch predictions, the number of branch prediction failures, the number of first-level cache reads, the number of first-level cache read failures, the number of last-level cache reads, and the number of last-level cache read failures.
[0157] In one possible implementation, step 7021 is performed by a scheduling policy generation module of the resource scheduling system, where the scheduling policy generation module is equivalent to the scheduling device in the resource scheduling system. As shown in Figure 6, the scheduling policy generation module collects information such as resource utilization, busyness, and affinity for each node managed by the resource scheduling system, where busyness indicates the busyness of the node, and affinity refers to the affinity between the node and the local service instance. Based on the collected information such as resource utilization, busyness, affinity of each node, and core indicator data of each processing core in each node, the scheduling policy generation module constructs a unified resource view of the resource scheduling system. For example, the scheduling policy generation module determines the service quality degradation parameters of each service instance based on the core indicator data of each processing core, and constructs a unified resource view of the resource scheduling system based on the service quality degradation parameters of each service instance and information such as resource utilization, busyness, and affinity of each node.
[0158] For example, each cloud management platform will actively collect the core load performance of the CPU of each node when running business, and report the resource utilization, busyness, affinity, core indicator data of each processing core in each node and other information to the scheduling strategy generation module through the host layer interface of each platform access device. Alternatively, each cloud management platform does not actively report this information, and the scheduling strategy generation module actively obtains this information from each cloud management platform through the platform access device.
[0159] The processing core bound to the target instance is called the first CPU. Taking the determination of the service quality degradation parameters of the target instance as an example, in the process of the target instance running the target business, the scheduling strategy generation module collects the kernel indicator data of the first CPU in real time, and determines the service quality degradation parameters of the target instance based on the kernel indicator data of the first CPU at the current moment and the kernel indicator data of the first CPU at the historical moment. Among them, the larger the service quality degradation parameter, the more serious the service quality degradation of the target instance, and the smaller the service quality degradation parameter, the lighter the service quality degradation of the target instance.
[0160] Since kernel metric data is a CPU kernel-level metric, it can accurately reflect the kernel-level resources consumed by the instance while running on the CPU. Therefore, based on the kernel metric data of the first CPU, the degradation of the target instance's service quality can be accurately predicted. In the event of severe service quality degradation, resources can be promptly scheduled for the target instance to quickly alleviate the degradation of the target instance's service quality. During the operation of a service instance, the consumption of the kernel-level resources of the bound processing cores varies. For example, some services experience a high number of context switches during operation, while others experience a high number of first-level cache reads. Based on this, the method of determining the service quality degradation of a service instance based on various core load performance indicators, including the processor's service clock, number of context switches, number of processor migrations, number of page faults, clock cycles, number of instructions per clock cycle, number of instruction stall cycles, number of branch predictions, number of branch prediction failures, number of first-level cache reads, number of first-level cache read failures, number of last-level cache reads, and number of last-level cache read failures, can be applied to various services to meet the needs of different services.
[0161] Step 7022: The resource scheduling system determines the quality of service required by the target instance at the first hybrid node based on the correspondence between the multiple priorities and the service quality levels and according to the target priority in the instance priority information.
[0162] The QoS required by the target instance is the QoS required by the target business running in the target instance. The target business is the business run by the tenant in the target instance. For example, the target QoS level corresponding to the target priority is determined as the QoS required by the target instance.
[0163] Step 7023: The resource scheduling system determines a resource adjustment policy for the target instance based on the target service quality level, the service quality degradation parameter of the target instance, and the resource demand of the target business. The resource adjustment policy can meet the service quality requirements of the target instance.
[0164] The node status of any node includes at least one of the node's resource status and service status. The resource status is used to indicate at least one of the node's resource allocation and resource utilization. The resource allocation includes the amount of idle resources at the node and the amount of resources occupied by each service instance at the node. The resource utilization includes the resource utilization rate of each resource at the node. The service status is used to indicate at least one of the node's busyness and the affinity between the node and local service instances. For example, the service status includes the node's busyness and the affinity between the node and each local service instance.
[0165] The resource adjustment policy includes any one of the following first to third adjustment policies: wherein the first adjustment policy is to release a first number of resources from resources occupied by the target instance; the second adjustment policy is to allocate a second number of resources to the target instance from unoccupied resources of the first hybrid node; and the third adjustment policy is to allocate a third number of resources to the target instance from unoccupied resources of a second hybrid node among the plurality of hybrid nodes.
[0166] In one possible implementation, if the current quality of service level of the target instance is lower than the target service level, and the service quality degradation parameter of the target instance is greater than or equal to the parameter threshold, the resource scheduling system determines that the target instance does not meet the service quality requirements of the target business. The current quality of service level of the target instance is determined by the kernel indicator data of the first CPU currently collected. In another possible implementation, the quality of service provided by the target instance is always higher than or equal to the target service level during the process of the target instance running the target business. During this period, if the service quality degradation parameter of the target instance is greater than the parameter threshold, the resource scheduling system determines that the target instance does not meet the service quality requirements of the target business. The parameter threshold may be different in different implementation scenarios. Here, this application does not limit the parameter threshold.
[0167] If the target instance cannot meet the QoS requirements of the target business, and the target instance also supports the flexible adjustment mode, the target instance meets the resource adjustment conditions. The resource scheduling system determines the resource adjustment policy of the target instance based on the node status of the first node and the resource demand of the target business. The process of determining the resource adjustment policy is described below:
[0168] The target business has at least one resource demand, and any resource demand is the predicted resource quantity of a resource that the target instance needs to consume when running the target business. Taking the determination of the resource demand of the target business for any resource as an example, the resource scheduling system collects the resource consumption of the target instance at each moment during the operation of the target business from the first hybrid node, and periodically counts the changes in the resource consumption of the target instance during the operation of the target business according to the time window. Based on the changes in the resource consumption of the target instance counted in the current time window, the resource demand of the target business in the next time window is determined, and the resource demand of the target business in the next time window is used as the resource demand of the target business for the resource.
[0169] Taking the target business as business i and any resource of the target instance as X, the resource scheduling system obtains the mean value Mean(X) of the resource consumption of the target instance in the current time window and the standard deviation Std(X) of the resource consumption of the target instance in the current time window according to the following formula (1). The sum of the mean value Mean(X) and the standard deviation Std(X) is used as the resource demand Usage(i, X) of business i for resource X in the next time window. Wherein, formula (1) is as follows: Usage(i, X) = Mean(X) + Std(X)
[0170] Where t1 and t2 are the start and end times of the current time window, respectively, and X(i) is the resource consumption of resource X of the target instance at a certain moment during the operation of business i.
[0171] After obtaining the resource demand of the target business, if the resource demand of the target business is lower than the resource demand of the target instance, indicating that there are some idle resources in the resources occupied by the target instance, the resource scheduling system determines a first quantity based on the resource demand of the target instance and the resource demand of the target business, wherein the first quantity is the amount of resources to be released, and the first quantity is less than or equal to the difference between the amount of resources occupied by the target instance and the resource demand of the target business. The amount of resources occupied by the target instance is also the amount of resources in the current specification information of the target instance. For example, if the target instance has not undergone resource adjustment after creation, the target amount of resources in the target specification information of the target instance is the amount of resources occupied by the target instance. If the target instance has undergone resource adjustment after creation, the target specification information of the target instance is updated, and the target amount of resources of the target instance is correspondingly updated. The updated target amount of resources is the amount of resources occupied by the target instance. Alternatively, if the resource demand of the target business is lower than the amount of resources occupied by the target instance, the resource scheduling system uses the idle amount of resources of the target instance as the first quantity. After the first quantity is determined, the resource adjustment policy of the target instance of the resource scheduling system is determined to be the first resource adjustment policy.
[0172] If the resource demand of the target business is higher than the resource occupied by the target instance, it means that the resources occupied by the target instance cannot meet the resource demand of the target business. In this case, a resource adjustment strategy needs to be determined to increase the resource occupied by the target instance to increase the specifications of the target instance and meet the resource demand of the target business.
[0173] For example, if the target service's resource demand is higher than the target instance's resource demand, the resource scheduling system determines a second quantity based on the target service's resource demand and the target instance's resource demand. The second quantity is the amount of additional resources the target service requires over and above the target instance's resource demand, and the second quantity is greater than or equal to the difference between the target instance's resource demand and the target service's resource demand. For example, if the target service's memory demand is 100MB and the target instance's memory resource demand is 80MB, the second quantity is at least 20MB.
[0174] The resource scheduling system determines whether a second amount of resources can be scheduled for the target instance from the resources of the first hybrid node. If the second amount of resources can be scheduled for the target instance from the resources of the first hybrid node, the resource adjustment policy of the target instance is determined to be a second resource adjustment policy. For example, the resource scheduling system obtains the amount of idle resources of the first hybrid node. If the amount of idle resources of the first hybrid node is greater than or equal to the second amount, the second amount of resources can be scheduled for the target instance from the resources of the first hybrid node. The resource scheduling system determines the second resource adjustment policy of the target instance from the resource adjustment policy. If the amount of idle resources of the first hybrid node is lower than the second amount, the resource scheduling system queries whether there is a business instance (referred to as the first business instance) with idle resources in the first hybrid node. If there is a first business instance, the idle resources of the first business instance are released, so that the idle resources of the first hybrid node increase. Alternatively, the resource scheduling system schedules the second business instance in the first hybrid node to the third hybrid node, releasing the resources occupied by the second business instance in the first hybrid node, so that the idle resources of the first hybrid node increase. The second business instance is any business instance other than the target instance in the first hybrid node, and the third hybrid node is any hybrid node other than the first hybrid node among the multiple hybrid nodes. Alternatively, the resource scheduling system releases the idle resources of the first business instance, and schedules the second business instance in the first hybrid node to the third hybrid node, releasing the resources occupied by the second business instance in the first hybrid node, thereby increasing the idle resources of the first hybrid node. After the idle resources of the first hybrid node increase, the idle resource amount of the first hybrid node is updated. If the updated idle resource amount of the first hybrid node is higher than or equal to the second amount, and the second amount of resources can be scheduled for the target instance from the resources of the first hybrid node, the resource scheduling system determines the resource adjustment policy of the target instance as the second resource adjustment policy.
[0175] In another possible implementation, if a second amount of resources can be scheduled for the target instance from the resources of the first hybrid node, the resource scheduling system may also determine, based on the node status of the first hybrid node, whether to determine the resource adjustment policy of the target instance to be the second resource adjustment policy. For example, if the resource utilization of the first hybrid node is less than or equal to the utilization threshold, and / or the busyness of the first hybrid node is less than or equal to the first busyness threshold, it indicates that the resource utilization of the first hybrid node is low and / or the first hybrid node is not busy, and the resources of the first hybrid node are sufficient, then the resource adjustment policy of the target instance is determined to be the second resource adjustment policy. If the resource utilization of the first hybrid node is greater than the utilization threshold, and / or the busyness of the first hybrid node is greater than the first busyness threshold, it indicates that the resource utilization of the first hybrid node is high and / or the first hybrid node is busy, and the resources of the first hybrid node are tight. In order not to affect the operation of other business instances on the first hybrid node, the resource adjustment policy of the target instance is determined to be the third resource adjustment policy.
[0176] In another possible implementation, if the second amount of resources cannot be scheduled for the target instance from the resources of the first hybrid node, the resource scheduling system determines the third resource adjustment policy based on the resource adjustment policy of the target instance. Taking the following steps A1 and A2 as an example, the process of determining the third resource policy is introduced as follows.
[0177] Step A1: During the process of the target instance running the tenant's target business, the resource scheduling system obtains the node status of multiple hybrid nodes and the service quality degradation parameters of each business instance running in each hybrid node. The service quality degradation parameters are used to indicate the degree of degradation of the service quality of the business instance during the operation process.
[0178] Among them, for any hybrid node, the process of the resource scheduling system obtaining the node status of the hybrid node is the same as the process of obtaining the status of the first hybrid node, and the process of the resource scheduling system obtaining the service quality degradation parameters of each business instance running the hybrid node is the same as the process of obtaining the service quality degradation parameters of the target instance. Step A1 will not be repeated here.
[0179] Step A2: The resource scheduling system determines a third resource adjustment strategy for the target instance based on the node status of multiple hybrid nodes, the service quality degradation parameters of each business instance, and the actual resource consumption of each business instance. The third resource adjustment strategy includes allocating a third amount of resources to the target instance from the unoccupied resources of the second hybrid node among the multiple hybrid nodes.
[0180] The third amount is the resource demand of the target service. The second hybrid node is one of the multiple hybrid nodes that has sufficient resources and can allocate the third amount of resources to the target instance.
[0181] Taking any hybrid node other than the first hybrid node among the multiple hybrid nodes as an example, the resource scheduling system determines whether the resources of the hybrid node are sufficient based on the node status of the hybrid node, wherein the determination method is the same as that of determining whether the resources of the first hybrid node are sufficient, and will not be repeated. If the resources of the hybrid node are sufficient and the amount of idle resources is greater than the third number, the resource scheduling system determines the hybrid node as the second hybrid node to avoid affecting the operation of other business instances in the second hybrid node after the resources are subsequently allocated from the second hybrid node to the target instance. Alternatively, if the resources of the hybrid node are sufficient, the service quality degradation parameters of each business instance in the hybrid node are less than or equal to the second parameter threshold, and the amount of idle resources of the hybrid node is greater than the third number, the resource scheduling system determines the hybrid node as the second hybrid node to avoid affecting the service quality of other business instances in the second hybrid node after the resources are subsequently allocated from the second hybrid node to the target instance.
[0182] If the hybrid node has sufficient resources but the idle resource amount of the hybrid node is less than the third amount, the resource scheduling system may further determine the idle resource amount of each service instance based on the actual resource consumption of each service instance in the hybrid node and the resource amount occupied by each service instance, or obtain the idle resource amount of each service instance from the hybrid node. The actual resource consumption of any service instance is the amount of resources consumed by the service instance during the operation of the service instance, and the idle resource consumption of the service instance is the amount of resources that have not been used within the occupied resource amount of the service instance. For example, the idle resource consumption of a service instance is equal to the difference between the occupied resource amount of the service instance and the actual resource consumption of the service instance. Based on the idle resource amounts of each service instance in the hybrid node, the idle resources of at least one service instance in the hybrid node are released, and the resource release amount of the at least one service instance is less than the idle resource amount of the service instance, so as to increase the idle resources of the hybrid node. Alternatively, at least one service instance is scheduled to a fourth hybrid node, and the resources occupied by at least one service instance in the hybrid node are released, so as to increase the idle resources of the hybrid node. Alternatively, the idle resources of at least one service instance in the hybrid node are released, and at least one other service instance in the hybrid node is scheduled to a fourth hybrid node, so as to increase the idle resources of the hybrid node. The fourth hybrid node is any hybrid node among the multiple hybrid nodes except the first hybrid node. The idle resources of the hybrid node are increased, so that the idle resource amount of the hybrid node is updated. If the idle resource amount of the updated hybrid node is greater than or equal to the third amount, the resource scheduling system determines the hybrid node as a second hybrid node.
[0183] In another possible implementation, the resource scheduling system first determines whether the amount of idle resources of each hybrid node is greater than or equal to a third number. If there is a hybrid node with an amount of idle resources greater than or equal to the third number, the resource scheduling system then determines whether the resources of the hybrid node are sufficient based on the node status of the hybrid node. If the resources are sufficient, the hybrid node is determined as a second hybrid node. Alternatively, if there is a hybrid node with an amount of idle resources greater than the third number, the hybrid node is determined as a second hybrid node. At this time, the node status of the hybrid node is not important. If there is no hybrid node with an amount of idle resources greater than the third number among the multiple hybrid nodes, the idle resources of the service instance in a certain hybrid node are released and / or some service instances in the hybrid node are scheduled to other hybrid nodes, so that the idle resources of the hybrid node can be greater than or equal to the third number, and the hybrid node is determined as the second hybrid node.
[0184] The above-mentioned methods for determining the second hybrid node can be arbitrarily combined to expand other methods for determining the second hybrid node, and it is sufficient to find a second hybrid node among multiple hybrid nodes whose idle resource amount is greater than or equal to the third number, and whose third number of idle resources does not affect the service quality of the local business instance after being occupied. Here, the embodiment of the present application does not limit the method for determining the second hybrid node.
[0185] After determining the second hybrid node, the resource scheduling system generates a second resource scheduling policy for the target instance based on the second hybrid node and the third quantity.
[0186] The above is an example of determining a second resource scheduling policy for a target instance based on the node status of other hybrid nodes, the service quality degradation parameters of the business instances in other hybrid nodes, and the actual resource consumption when the target instance cannot be allocated sufficient resources in the first hybrid node. In another possible implementation, the resource scheduling system determines a target hybrid node from multiple hybrid nodes based on the node status of multiple hybrid nodes, the service quality degradation parameters of each business instance, and the actual resource consumption of each business instance. The idle resources of the target hybrid node are sufficient to allocate a target number of resources to the target instance. Based on the target hybrid node and the target number, a resource adjustment policy for the target instance is generated to determine the resource adjustment policy for the target instance based on the node status of multiple hybrid nodes, the service quality degradation parameters of each business instance, and the actual resource consumption of each business instance. In this possible implementation, if the target hybrid node is the first hybrid node, the target number is the first number or the second number; if the target hybrid node is the second hybrid node, the target number is the third number. The process of determining the target hybrid node is similar to the process of determining the second hybrid node and will not be repeated here.
[0187] To facilitate understanding of the principle of determining the resource adjustment strategy, the above is explained by taking an example of increasing the idle resources of the target hybrid node (the first hybrid node or the second hybrid node) by releasing the idle resources of the business instance in the target hybrid node and / or scheduling the business instance to other nodes before the resource adjustment strategy is determined. In other embodiments, in the process of determining the resource adjustment strategy, the idle resources of the target hybrid node are not adjusted. Instead, an idle resource adjustment sub-strategy is generated based on the business instance in the target hybrid node whose idle resources are to be released and / or the business instance to be scheduled out of the target hybrid node. Based on the idle resource adjustment sub-strategy, the target hybrid node and the target number, a resource adjustment strategy for the target instance is generated. At this time, the resource adjustment strategy also includes an idle resource adjustment sub-strategy, and the idle resource adjustment sub-strategy is used to indicate the release of idle resources of at least one business instance in the target hybrid node and / or the scheduling of at least one business instance out of the target hybrid node.
[0188] The resource scheduling policy diagram shown in Figure 8 is used as an example to illustrate the process of determining and adjusting the policy. Assume that host A is a VM node that only supports VM deployment (i.e., a non-hybrid node), host B is a container node that only supports container deployment (i.e., a non-hybrid node), and host C is a hybrid node. Assume that the service instances on hosts A, B, and C run services in two different time periods, t1 and t2, respectively. Table 1 shows the specification information for hosts A, B, and C, the specification information for each service instance within the specification information for hosts A through C, and the resource requirements for each service instance in time periods t1 and t2. Host A has high resource utilization and low busyness. Specifically, host A is relatively busy in time period t1 and relatively idle in time period t2. Host B has high resource utilization and low busyness. Specifically, host B is relatively idle in time period t1 and relatively busy in time period t2. Host C has low resource utilization and high busyness. Specifically, host C is relatively idle in time period t1 and relatively busy in time period t2.
[0189] Table 1
[0190] Assuming that container 3 is the target container, in the time period t1, the resource demand of container 3 reaches the resource amount recorded in the specification information of container 3. If the service quality of container 3 deteriorates seriously, the resource scheduling system can formulate a resource scheduling strategy for container 3 based on parameters such as the resource utilization and busyness of each hybrid node and the resource demand of other business instances in host C in the time period t1. For example, the resource scheduling strategy is to release the resources occupied but unused by VM3 in the time period t1 (that is, the idle resources of VM3).
[0191] Step 7024: The resource scheduling system adjusts the resources occupied by the target instance among the resources provided by the multiple hybrid nodes based on the resource adjustment policy.
[0192] Among them, when the resource adjustment strategy is the first resource adjustment strategy, the resource scheduling system releases a first number of resources from the resources occupied by the target instance in the first hybrid node, so that the released resources become idle resources of the first hybrid node to increase the amount of idle resources of the first hybrid node.
[0193] If the resource adjustment policy is the second resource adjustment policy, and if the second resource adjustment policy includes an idle resource adjustment sub-policy, the resource scheduling system, based on the idle resource adjustment sub-policy, releases idle resources of service instances other than the target instance in the first hybrid node and / or schedules the service instances to other hybrid nodes to increase the idle resources of the first hybrid node; and allocates a second amount of resources to the target service instance from unoccupied resources of the first hybrid node to increase the amount of resources occupied by the target instance. If the second resource adjustment policy does not include an idle resource adjustment policy, the resource scheduling system allocates the second amount of resources to the target service instance from unoccupied resources of the first hybrid node.
[0194] In the case where the resource adjustment policy is the third resource adjustment policy, if the third resource adjustment policy includes an idle resource adjustment sub-policy, the resource scheduling system releases the idle resources of at least one business instance in the third hybrid node and / or schedules at least one business instance to other hybrid nodes based on the idle resource adjustment sub-policy to increase the amount of idle resources of the second hybrid node; schedules the target instance from the first hybrid node to the second hybrid node, and allocates a third amount of resources to the target instance from the unoccupied resources of the second hybrid node to increase the amount of resources occupied by the target instance. If the third resource adjustment policy does not include an idle resource adjustment sub-policy, the resource scheduling system schedules the target instance from the first hybrid node to the second hybrid node, and allocates a third amount of resources to the target instance from the unoccupied resources of the second hybrid node.
[0195] For any business instance, if the resources occupied by the business instance are released or new resources are allocated to the business instance, the amount of resources occupied by the business instance will be updated, and the resource scheduling system will update the resource amount in the specification information of the business instance to the amount of resources occupied by the business instance, that is, the specifications of the business instance are updated. For any business instance, if the business instance is scheduled from one node (called the source node) to another node (called the target node), the resource scheduling system will release the resources occupied by the business instance in the source node to increase the idle resources of the source node, and allocate resources to the business instance from the unused resources (i.e., idle resources) of the target node to reduce the idle resources of the target node. When the business instance is scheduled from the source node to the target node, sufficient resources are allocated to the business instance from the resources of the target node to ensure the service quality of the business instance. For example, when some business instances from host 1 and host 2 are scheduled to host K in Figure 6, instance scheduling with service quality assurance is required.
[0196] In another possible implementation, the process shown in steps 7021 to 7024 can be implemented interactively between multiple modules in the resource scheduling system. As shown in Figure 6, the scheduling policy generation module executes steps 7021-7023 to determine the resource adjustment policy for the target instance and sends the resource adjustment policy to the intelligent scheduling system. The intelligent scheduling system executes step 704 based on the resource adjustment policy to adjust the resources occupied by the target instance. For example, the intelligent scheduling system sends the resource adjustment policy to the native API supported by the runtime type of the target instance, and the native API adjusts the resources occupied by the target instance based on the resource adjustment policy.
[0197] After the target instance has undergone resource adjustment, the operating status information of the target instance will also be updated accordingly. As shown in Figure 6, the updated operating status information includes the identifier of the node where the target instance is located, the identifier of the node type of the node, recommended specification information, and degradation information. Among them, the recommended specification information is the runtime specification information recommended by the tenant that can meet the service quality requirements of the target business. The recommended specification information can be the specification information of the target instance after resource adjustment. The degradation information is used to indicate whether the quality of service (QoS) degradation parameter of the target instance exceeds the first parameter threshold. The degradation information is divided into first degradation information and second degradation information. The first degradation information is used to indicate that the service quality degradation parameter of the target instance exceeds the first parameter threshold, and the second degradation information is used to indicate that the service quality degradation parameter of the target instance does not exceed the first parameter threshold.
[0198] At least one of the recommended specification information and the degradation information is an optional item of the operating status information. Based on this, the resource scheduling system updates the operating status information of the target instance based on the degradation information and / or recommended specification information of the target business. For example, after the target instance undergoes resource adjustment, the resource scheduling system uses the latest specification information of the target instance after resource adjustment as the recommended specification information, obtains the service quality degradation parameter when the current target instance runs the target business, and if the service quality degradation parameter is greater than or equal to the first parameter threshold, generates operating status information based on the first degradation information and / or recommended specification information. If the service quality degradation parameter is less than the first parameter threshold, generates operating status information based on the second degradation information and / or recommended specification information. After the operating status information is generated, the resource scheduling system provides the client with the operating status information of the target instance after resource scheduling by executing the following step 703.
[0199] 703. The resource scheduling system sends the running status information of the target instance after resource scheduling to the client.
[0200] As shown in Figure 6, the resource scheduling system sends the running status information of the target instance after resource scheduling to the client to update the running status of the target instance on the client. The client receives and displays the updated running status information so that the tenant can obtain the current running status of the target instance.
[0201] The above is an example of the target instance supporting the flexible adjustment mode to illustrate the process of adjusting the resources occupied by the target instance. In another possible implementation method, the target instance supports the elastic adjustment mode but does not support the flexible adjustment mode. The resource scheduling system can determine the resource adjustment strategy for the target instance based on the above method, predict the amount of resources after the resources occupied by the target instance are adjusted by the resource adjustment strategy, use the predicted amount of resources as the recommended specification information of the target instance, generate the running status information of the target instance based on the recommended specification information of the target instance, send the running status information to the client, and the client receives and displays the running status information so that the tenant can update (i.e. adjust) at least one of the target instance's specification information, supported resource adjustment modes, and instance priority information according to the recommended specification information. Of course, in the case where the target instance supports the flexible adjustment mode, the tenant can also update the at least one item according to the current running status information of the target instance. If the tenant updates the at least one item through the client, while the target instance is running, the resource scheduling system will make secondary adjustments to the resources occupied by the target business instance based on the updated at least one item. For example, based on the updated at least one item, the system will re-execute the process shown in Figure 7 for the target instance to meet the needs of the target instance at different time periods. This adjustment can be made, for example, by adjusting the at least one item through the instance configuration interface shown in Figure 6 to trigger secondary configuration of the target instance.
[0202] The embodiment shown in Figure 7 adjusts the resources occupied by the target instance in the hybrid node based on the instance priority information input by the tenant, ensuring that the resources occupied by the target instance meet the target instance's quality of service requirements, thereby ensuring the quality of service for the services running on the target instance. Furthermore, by adjusting the resources occupied by the target instance through different resource adjustment policies, idle and fragmented resources in the hybrid node can be integrated, ensuring that the fragmented resources of the hybrid node are fully utilized.
[0203] Figure 7 takes the target instance as a business instance in a hybrid node as an example to illustrate the process of adjusting the resources occupied by the business instance in the hybrid node. In another possible implementation method, for multiple non-hybrid nodes deploying the same runtime instance, the resources provided by the multiple non-hybrid nodes are used as a resource pool. The resource scheduling system can also adjust the resources occupied by the business instances in the multiple non-hybrid nodes in the resources provided by the multiple non-hybrid nodes according to the resource adjustment method described above. This will not be repeated here.
[0204] In another possible implementation, for any business instance in each node (including hybrid nodes or non-hybrid nodes) managed by the resource adjustment system, resource adjustments are made to the resources occupied by the business instance between nodes of different node types or between nodes of the same node type based on the affinity between the business instance and the node. Still taking the target instance as an example, if the affinity between the target instance and the first hybrid node is greater than the first affinity threshold, the target instance does not support scheduling out of the first hybrid node, and the resource scheduling system customizes the first resource adjustment strategy or the second resource adjustment strategy for the target instance to ensure that the target instance is not scheduled out of the first hybrid node. If the affinity between the target instance and the first hybrid node is greater than or equal to the second affinity threshold and less than or equal to the first affinity threshold, the target instance supports adjusting the resources occupied by the target business instance with resources provided by nodes of the same node type as the node, such as supporting adjusting the resources occupied by the target business instance among the resources provided by multiple hybrid nodes. If the affinity between the target instance and the first hybrid node is less than the second affinity threshold, the target instance supports scheduling to a node that supports the deployment of the target instance type, which node is a non-hybrid node or a hybrid node. In this way, the resource scheduling system can adjust the resources occupied by the target business instance among the resources provided by multiple nodes that support the deployment of the target instance type.
[0205] Still taking container 3 in Figure 8 as the target instance, if the affinity between container 3 and host C is greater than the first affinity threshold, the resources occupied by container 3 can only be adjusted within the resources provided by host C. If the affinity between container 3 and host C is greater than or equal to the second affinity threshold and less than or equal to the first affinity threshold, the resources occupied by container 3 can be adjusted within the resources provided by host C and other hybrid nodes. If the affinity between container 3 and host C is less than the second affinity threshold, the resources occupied by container 3 can be adjusted within the resources provided by host C and host B. The affinity of the target instance can be configured by the tenant through the client or determined by the resource scheduling system based on the priority information of the target instance.
[0206] The affinity between business instances on the same node is higher than the affinity between business instances on different nodes. As shown in Figure 8, the affinity between VM2 and VM3 is low, VM2 and VM3 are not affinity, and container 1 and container 2 are affinity.
[0207] For any business instance in each node (including hybrid nodes or non-hybrid nodes) managed by the resource adjustment system, the resource scheduling system provides the client with the operating status information of the business instance in different time periods, so that the tenant can update (i.e., adjust) at least one of the specification information, supported resource adjustment modes, and instance priority information of the business instance based on the current operating status information of the business instance. Subsequently, during the operation of the business instance, the resource scheduling system makes a secondary adjustment to the resources occupied by the business instance based on the updated at least one item. The secondary adjustment process can refer to the embodiment shown in Figure 7 and will not be repeated here.
[0208] In other embodiments, the resource scheduling system introduced above is also used to provide a business display interface, such as a schematic diagram of a business display interface provided in an embodiment of the present application as shown in Figure 9. The business display interface is used to display the relevant information of all businesses managed by the resource scheduling system and the relevant information of all runtime instances. The business display interface can also be understood as the global resource display interface of the resource scheduling system. The resource scheduling system also provides an external interface for accessing the business display interface. The user (tenant user or administrator) calls the interface through the client to display the business display interface on the client.
[0209] As shown in Figure 9, the business display interface 900 is used to display the operating status of each business in the runtime instances of multiple cloud management platforms, the service quality degradation of the business, the image / runtime instance used by the runtime instance where the business is located, the IP address of the runtime instance where the business is located, the label of the runtime instance where the business is located, and at least one of the billing modes corresponding to the resource adjustment mode of the business.
[0210] For example, for any service, the service display interface also displays the name of the service to indicate the service. The service's operating status includes running, paused, or terminated. Paused means that the service's runtime instance is temporarily not running, suspended is called a suspended state, and terminated means that the service's runtime instance has terminated. The operating status is the service status of the service's runtime instance.
[0211] The service quality degradation of any business is either normal or abnormal. The normal situation indicates that the degree of service quality degradation is still within the business allowable range, and the abnormal situation means that the degree of service quality degradation has exceeded the business allowable range. Exemplarily, the business display interface displays service quality degradation parameters to indicate the degree of service quality degradation. When the degree of service quality degradation has exceeded the business allowable range, the control device can also display the service quality degradation parameters through the business display interface and issue an alarm prompt so that the user can handle it as soon as possible. In a possible implementation method, the business display interface is also used to display service quality evaluation indicators that determine the degradation parameters of the service quality of the business. Since the service quality evaluation indicators include kernel-level indicators such as IPC and SC, the service quality degradation situation can be more comprehensively displayed, so that the system performance status can be more accurately reflected, helping users to discover and solve problems in a timely manner, and ensuring the stability and reliability of the resource scheduling system.
[0212] The tag of the runtime instance is used to record the location information and / or other information of the runtime instance, wherein the location information is used to indicate the node where the runtime instance is located and the cloud management platform to which the node belongs. By displaying the tag of the runtime instance, users can more conveniently classify and manage the runtime instance. By displaying the image / runtime instance used by the runtime instance, users can understand the software version running in the resource scheduling system. By displaying the IP address of the runtime instance, users can directly access the runtime instance. By displaying the billing mode, users can understand the resource usage and billing of the resource scheduling system. By displaying the tag of the runtime instance running the business, users can more conveniently classify and manage the runtime instance. By displaying the relevant information of the runtime instance in detail, users or administrators can more conveniently manage and optimize the system, improving work efficiency and optimization capabilities.
[0213] Exemplarily, the service display interface further displays operation options for the runtime instance where the service is located, such as a start option, a stop option, a restart option, etc., so that the runtime instance can be remotely operated.
[0214] Through the information displayed on the business display interface, users can clearly understand the status and operation of the entire resource scheduling system and make necessary adjustments in a timely manner to enable the resource scheduling system to work more efficiently, thereby meeting business needs in different application scenarios.
[0215] The above describes the method of the embodiment of the present application. The following describes the device of the embodiment of the present application. It should be understood that the device described below has any function of any device in the task scheduling system in the above method. Based on the same inventive concept as the above-mentioned task scheduling method for providing cloud services, the device and equipment in the resource scheduling system will be described below in conjunction with Figures 10 to 13. It should be understood that the technical features described in the method embodiment are also applicable to the following device embodiment.
[0216] FIG10 is a schematic diagram of a hybrid deployment device for cross-runtime instances based on cloud computing technology according to an embodiment of the present application. The device 1000 shown in FIG10 includes:
[0217] The access module 1001 is configured to receive an instance configuration request sent by a tenant through a client, wherein the instance configuration request is used to instruct to deploy a target instance on the hybrid node, wherein the runtime type of the target instance is a class of the runtime instance;
[0218] A control module 1002 is configured to determine a first hybrid node from the plurality of hybrid nodes according to the instance configuration request;
[0219] A scheduling module 1003 is configured to create the target instance for the tenant on the first hybrid node;
[0220] The access module 1001 is used to send the running status information of the target instance to the client, where the running status information includes the identifier of the runtime type of the target instance and node information, where the node information is used to indicate that the running environment of the target instance is the first hybrid node.
[0221] In a possible implementation, the access module 1001 is further configured to obtain instance priority information input by the tenant, where the instance priority information is used to determine the quality of service required by the target instance on the first hybrid node;
[0222] The scheduling module 1003 is further configured to adjust the resources occupied by the target instance in the first hybrid node according to the instance priority information, so as to meet the quality of service requirement of the target instance.
[0223] In a possible implementation, the apparatus 1000 supports the tenant in updating the instance priority information according to the operating status information after resource adjustment, and the scheduling module 1003 is further configured to:
[0224] The resources occupied by the target service instance are adjusted according to the updated instance priority information.
[0225] In a possible implementation, the device scheduling module 1003 is further configured to:
[0226] During the process of the target instance running the target service of the tenant, obtaining the node status of the multiple hybrid nodes and a service quality degradation parameter of each service instance running in each hybrid node, wherein the service quality degradation parameter is used to indicate the degree of service quality degradation of the service instance during the running process, and the runtime type of the service instance is a class of the runtime instance;
[0227] Determining a resource adjustment policy for the target instance based on the node states of the multiple hybrid nodes, the service quality degradation parameters of the respective service instances, and the actual resource consumption of the respective service instances, wherein the resource adjustment policy can meet the service quality requirements of the target instance;
[0228] Based on the resource adjustment policy, the resources occupied by the target instance are adjusted among the resources provided by the multiple hybrid nodes.
[0229] In one possible implementation, the node status includes the resource status and service status of the hybrid node, the resource status is used to indicate at least one of the resource allocation and resource utilization of the hybrid node, and the service status is used to indicate at least one of the busyness of the hybrid node and the affinity between the hybrid node and the local business instance.
[0230] In a possible implementation, the resource adjustment strategy includes any one of the following:
[0231] releasing a first amount of resources from the resources occupied by the target instance;
[0232] allocating a second amount of resources to the target instance from unoccupied resources of the first hybrid node;
[0233] A third amount of resources is allocated to the target instance from unoccupied resources of a second hybrid node among the plurality of hybrid nodes.
[0234] In a possible implementation, the resource adjustment policy includes recommended specification information, where the recommended specification information is runtime specification information recommended for the tenant that can meet the quality of service requirements of the target business. The apparatus 1000 further includes:
[0235] The control module 1002 is further configured to update the operation status information based on the service quality degradation parameter of the target service and / or the recommended specification information;
[0236] The access module 1001 is further configured to send the updated operation status information to the client.
[0237] In a possible implementation, the scheduling module 1003 is further configured to:
[0238] Determine a service quality degradation parameter of the service instance based on the core indicator data of the processor core bound to the service instance.
[0239] Among them, the access module 1001 is equivalent to the platform access device 11 in Figure 1, the control module 1002 is equivalent to the control device 12 in Figure 1, and the scheduling module 1003 is equivalent to the scheduling device 13 in Figure 1. In other embodiments, the control module 1002 and the scheduling module 1003 can be integrated into a single module to implement the functions of the control device 12 and the scheduling device 13 in Figure 1. In other embodiments, the access module 1001 and the control module 1003 can also be integrated into a single module to implement the functions of the platform access device 11 and the control device 12 in Figure 1.
[0240] Each module in the apparatus 1000 can be implemented by software or hardware. For example, the following takes the scheduling module 1003 as an example to describe the implementation of the scheduling module 1003. Similar modules in the apparatus 1000 can refer to the implementation of the scheduling module 1003.
[0241] As an example of a software functional unit, the scheduling module 1003 may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Furthermore, the computing instance may be one or more. For example, the scheduling module 1003 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed in the same region or in different regions. Furthermore, the multiple hosts / virtual machines / containers used to run the code may be distributed in the same availability zone (AZ) or in different AZs, each AZ including one data center or multiple geographically close data centers. Typically, a region may include multiple AZs.
[0242] Similarly, multiple hosts / virtual machines / containers running the code can be distributed within the same virtual private cloud (VPC) or across multiple VPCs. Typically, a VPC is set up within a region. Cross-region communication between two VPCs within the same region, or between VPCs in different regions, requires a communication gateway within each VPC to interconnect the VPCs.
[0243] As an example of a hardware functional unit, the scheduling module 1003 may include at least one computing device, such as a server. Alternatively, the scheduling module 1003 may be implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.
[0244] The multiple computing devices included in the scheduling module 1003 can be distributed in the same region or in different regions. The multiple computing devices included in the scheduling module 1003 can be distributed in the same AZ or in different AZs. Similarly, the multiple computing devices included in the scheduling module 1003 can be distributed in the same VPC or in multiple VPCs. The multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.
[0245] It should be noted that, in other embodiments, the scheduling module 1003 can be used to execute any step in the hybrid deployment method across runtime instances based on cloud computing technology, and the control module 1002 can be used to execute any step in the hybrid deployment method across runtime instances based on cloud computing technology. The steps that the access module 1001, the control module 1002 and the scheduling module 1003 are responsible for implementing can be specified as needed. By respectively implementing different steps in the hybrid deployment method across runtime instances based on cloud computing technology through the access module 1001, the control module 1002 and the scheduling module 1003, all functions of the resource scheduling system based on cloud computing technology are realized.
[0246] The present application also provides a computing device. As shown in FIG11 , a schematic diagram of the structure of a computer device provided in an embodiment of the present application is shown. Computing device 1100 includes a bus 1102, a processor 1104, a memory 1106, and a communication interface 1108. Processor 1104, memory 1106, and communication interface 1108 communicate with each other via bus 1102. Computing device 1100 can be a server or a terminal device. It should be understood that the present application does not limit the number of processors and memories in computing device 1100.
[0247] Bus 1102 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, among others. Buses may be classified as address buses, data buses, control buses, and the like. For ease of illustration, FIG11 illustrates a single bus line, but this does not imply a single bus or type of bus. Bus 1102 may include a path for transmitting information between various components of computing device 1100 (e.g., memory 1106, processor 1104, and communication interface 1108).
[0248] The processor 1104 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).
[0249] The memory 1106 may include volatile memory, such as random access memory (RAM). The processor 1104 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).
[0250] Memory 1106 stores executable program code, and processor 1104 executes the executable program code to implement the functions of the aforementioned method for hybrid deployment across runtime instances based on cloud computing technology, thereby implementing the aforementioned method for hybrid deployment across runtime instances based on cloud computing technology. In other words, memory 1106 stores instructions for executing the method for hybrid deployment across runtime instances based on cloud computing technology.
[0251] Alternatively, the memory 1106 stores executable code, and the processor 1104 executes the executable code to implement the aforementioned cloud computing technology-based hybrid deployment device across runtime instances, thereby implementing the aforementioned cloud computing technology-based hybrid deployment method and device method across runtime instances. In other words, the memory 1106 stores instructions for executing the cloud computing technology-based hybrid deployment method across runtime instances.
[0252] The communication interface 1108 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 1100 and other devices or a communication network.
[0253] Embodiments of the present application also provide a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.
[0254] As shown in FIG12 , an architecture diagram of a computer cluster provided by an embodiment of the present application includes at least one computing device 1100. The memory 1106 of one or more computing devices 1100 in the computing device cluster may store the same instructions for executing a hybrid deployment method across runtime instances based on cloud computing technology.
[0255] In some possible implementations, the memory 1106 of one or more computing devices 1100 in the computing device cluster may also store partial instructions for executing the hybrid deployment method across runtime instances based on cloud computing technology. In other words, the combination of one or more computing devices 1100 can collectively execute instructions for executing the hybrid deployment method across runtime instances based on cloud computing technology.
[0256] It should be noted that the memory 1106 in different computing devices 1100 in the computing device cluster can store different instructions, which are respectively used to implement part of the functions of the access module 1001, the control module 1002, and the scheduling module 1003. In other words, the instructions stored in the memory 1106 in different computing devices 1100 can implement the functions of one or more modules among the access module 1001, the control module 1002, and the scheduling module 1003.
[0257] In some possible implementations, one or more computing devices in a computing device cluster may be connected via a network. The network may be a wide area network or a local area network, etc. For example, the embodiment of the present application shown in FIG13 provides an architectural diagram of another computing cluster. As shown in FIG13 , two computing devices 11A and 11B are connected via a network. Specifically, the connection to the network is made through a communication interface in each computing device. In this type of possible implementation, the memory 1106 in the computing device 11A stores instructions for executing the functions of the access module 1001. At the same time, the memory 1106 in the computing device 11B stores instructions for executing the functions of the scheduling module 1003 and the control module 1002.
[0258] The connection method between the computing device clusters shown in Figure 13 can be based on the needs of the hybrid deployment method across runtime instances based on cloud computing technology provided in this application (for example, scheduling multiple tasks at the same time), so it is considered to entrust the functions implemented by the scheduling module 1003 and the control module 1002 to the computing device 11B for execution.
[0259] It should be understood that the functionality of the computing device 11A shown in FIG13 may also be implemented by multiple computing devices 1100. Similarly, the functionality of the computing device 11B may also be implemented by multiple computing devices 1100.
[0260] The present application also provides another computing device cluster. The connection relationship between the computing devices in this computing device cluster can be similar to the connection method of the computing device cluster described in Figures 12 and 13. However, the memory 1106 in one or more computing devices 1100 in this computing device cluster can store the same instructions for executing the methods of the access module 1001 and the control module 1002.
[0261] In some possible implementations, the memory 1106 of one or more computing devices 1100 in the computing device cluster may also store partial instructions for executing the hybrid deployment method across runtime instances based on cloud computing technology. In other words, the combination of one or more computing devices 1100 can collectively execute instructions for executing the hybrid deployment method across runtime instances based on cloud computing technology.
[0262] The present application also provides a computer program product including instructions. The computer program product may be software or a program product including instructions that can be run on a computing device or stored in any available medium. When the computer program product is run on at least one computing device, the at least one computing device executes a hybrid deployment method across runtime instances based on cloud computing technology.
[0263] The embodiment of the present application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that can be stored by a computing device or a data storage device such as a data center that contains one or more available media. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to execute a hybrid deployment method across runtime instances based on cloud computing technology.
[0264] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, storage, display, etc.), and signals involved in this application are all authorized by the user or fully authorized by all parties, and the collection, use, and processing of relevant data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, the SMS sending requests involved in this application are all obtained with full authorization.
[0265] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of the present invention.
Claims
1. A hybrid deployment method across runtime instances based on cloud computing technology, characterized in that: The method is performed by a resource scheduling system based on cloud computing technology, the resource scheduling system is used to manage resources of multiple hybrid nodes, the hybrid nodes refer to nodes that support at least two types of runtime instances, wherein the types of the runtime instances include containers, virtual machines, and serverless functions, and the method includes: receiving an instance configuration request sent by a tenant through a client, wherein the instance configuration request is used to instruct to deploy a target instance on the hybrid node, wherein a runtime type of the target instance is a class of the runtime instance; determining a first hybrid node from the plurality of hybrid nodes according to the instance configuration request; Creating the target instance for the tenant at the first hybrid node; Sending the running status information of the target instance to the client, the running status information including the identifier of the running type of the target instance and node information, the node information being used to indicate that the running environment of the target instance is the first hybrid node.
2. The method according to claim 1, characterized in that After the first hybrid node creates the target instance for the tenant, the method further includes: Acquire instance priority information input by the tenant, where the instance priority information is used to determine the quality of service required by the target instance on the first hybrid node; According to the instance priority information, resources occupied by the target instance in the first hybrid node are adjusted to meet a quality of service requirement of the target instance.
3. The method according to claim 2, characterized in that The resource scheduling system supports the tenant to update the instance priority information according to the running status information after the resource adjustment, and the method further includes: The resources occupied by the target service instance are adjusted according to the updated instance priority information.
4. The method according to claim 2 or 3, characterized in that: The method further comprises: In the process of the target instance running the target service of the tenant, obtaining the node status of the multiple hybrid nodes and the service quality degradation parameter of each service instance running in each hybrid node, wherein the service quality degradation parameter is used to indicate the degree of degradation of the service quality of the service instance during the running process, and the runtime type of the service instance is a class of the runtime instance; Determine a resource adjustment strategy for the target instance based on the node states of the multiple hybrid nodes, the service quality degradation parameters of the respective service instances, and the actual resource consumption of the respective service instances, wherein the resource adjustment strategy can meet the service quality requirements of the target instance; Based on the resource adjustment policy, the resources occupied by the target instance are adjusted among the resources provided by the multiple hybrid nodes.
5. The method according to claim 4, characterized in that The node status includes a resource status and a service status of the hybrid node, wherein the resource status is used to indicate at least one of a resource allocation status and a resource utilization status of the hybrid node, and the service status is used to indicate at least one of a busyness of the hybrid node and a degree of affinity between the hybrid node and a local business instance.
6. The method according to claim 4 or 5, characterized in that: The resource adjustment strategy includes any of the following: Releasing a first amount of resources from resources occupied by the target instance; allocating a second amount of resources to the target instance from unoccupied resources of the first hybrid node; A third amount of resources is allocated to the target instance from unoccupied resources of a second hybrid node among the plurality of hybrid nodes.
7. The method according to any one of claims 4 to 6, characterized in that: The resource adjustment strategy includes recommended specification information, where the recommended specification information is runtime specification information recommended for the tenant that can meet the service quality requirements of the target business. The method further includes: updating the operation status information based on the service quality degradation parameter of the target service and / or the recommended specification information; Send the updated running status information to the client.
8. The method according to any one of claims 4 to 7, characterized in that: Obtaining the service quality degradation parameters of each service instance running in each hybrid node includes: Based on the core indicator data of the processor core bound to the service instance, a service quality degradation parameter of the service instance is determined.
9. A hybrid deployment device across runtime instances based on cloud computing technology, characterized in that: The device is used to manage resources of multiple hybrid nodes, wherein the hybrid node refers to a node that supports at least two types of runtime instances, wherein the types of the runtime instances include containers, virtual machines, and serverless functions, and the device includes: An access module, configured to receive an instance configuration request sent by a tenant through a client, wherein the instance configuration request is used to instruct to deploy a target instance on the hybrid node, wherein a runtime type of the target instance is a class of the runtime instance; A control module, configured to determine a first hybrid node from the plurality of hybrid nodes according to the instance configuration request; A scheduling module, configured to create the target instance for the tenant at the first hybrid node; The access module is also used to send the running status information of the target instance to the client, the running status information includes the identifier of the runtime type of the target instance and node information, and the node information is used to indicate that the running environment of the target instance is the first hybrid node.
10. The device according to claim 8, characterized in that The access module is further used to obtain instance priority information input by the tenant, where the instance priority information is used to determine the quality of service required by the target instance at the first hybrid node; The scheduling module is further configured to adjust the resources occupied by the target instance in the first hybrid node according to the instance priority information to meet the quality of service requirement of the target instance.
11. The device according to claim 9, characterized in that The device supports the tenant to update the instance priority information according to the running status information after resource adjustment, and the scheduling module is further used to: The resources occupied by the target service instance are adjusted according to the updated instance priority information.
12. The device according to claim 9 or 11, characterized in that The scheduling module is also used for: In the process of the target instance running the target service of the tenant, obtaining the node status of the multiple hybrid nodes and the service quality degradation parameter of each service instance running in each hybrid node, wherein the service quality degradation parameter is used to indicate the degree of degradation of the service quality of the service instance during the running process, and the runtime type of the service instance is a class of the runtime instance; Determine a resource adjustment strategy for the target instance based on the node states of the multiple hybrid nodes, the service quality degradation parameters of the respective service instances, and the actual resource consumption of the respective service instances, wherein the resource adjustment strategy can meet the service quality requirements of the target instance; Based on the resource adjustment policy, the resources occupied by the target instance are adjusted among the resources provided by the multiple hybrid nodes.
13. The device according to claim 12, characterized in that The node status includes a resource status and a service status of the hybrid node, wherein the resource status is used to indicate at least one of a resource allocation status and a resource utilization status of the hybrid node, and the service status is used to indicate at least one of a busyness of the hybrid node and a degree of affinity between the hybrid node and a local business instance.
14. The device according to claim 12 or 13, characterized in that The resource adjustment strategy includes any of the following: Releasing a first amount of resources from resources occupied by the target instance; allocating a second amount of resources to the target instance from unoccupied resources of the first hybrid node; A third amount of resources is allocated to the target instance from unoccupied resources of a second hybrid node among the plurality of hybrid nodes.
15. The device according to any one of claims 12-13, characterized in that The resource adjustment strategy includes recommended specification information, where the recommended specification information is runtime specification information recommended for the tenant that can meet the service quality requirement of the target business; The control module is further configured to control the operation status based on the service quality degradation parameter of the target service and / or the recommended specification information. Update status information; The access module is further used to send the updated operation status information to the client.
16. The device according to any one of claims 12 to 15, characterized in that The scheduling module is also used for: Based on the core indicator data of the processor core bound to the service instance, a service quality degradation parameter of the service instance is determined.
17. A computing device cluster, characterized in that: It includes at least one computing device, each computing device includes a processor and a memory; the processor of the at least one computing device is used to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster executes the method as described in any one of claims 1-8.
18. A computer program product comprising instructions, characterized in that When the instructions are executed by a computing device cluster, the computing device cluster is caused to perform the method according to any one of claims 1 to 8.
19. A computer-readable storage medium, characterized in that: The method comprises computer program instructions. When the computer program instructions are executed by a computing device cluster, the computing device cluster performs the method according to any one of claims 1 to 8.
Citation Information
Patent Citations
Cross-runtime instance hybrid deployment method and device based on cloud computing technology
CN119440795A
Processing core distribution method and device for instances
CN113849260A
Resource specification adjustment method and device and storage medium
CN116431341A
Virtual machine and container mixed deployment method and device, equipment and storage medium
CN117130728A
Method for dynamic resources allocation and apparatus for implementing the same
US20220357995A1
Cited By
Memory resource scheduling method and system, computing equipment and electronic equipment
CN119988039A
Service deployment method and device based on cloud computing, electronic equipment and storage medium
CN121301031A
Intelligent access control method and system based on inter-micro-service zero-trust architecture
CN122093194A