Job task processing method based on cloud service, and cloud management platform

Abstract

Disclosed in the present application are a job task processing method based on a cloud service, and a cloud management platform, which can meet the increasingly complex service requirements of tenants, thereby improving the user experience. The method of the present application comprises: when required to process a job task, a tenant sending a job task processing request of the tenant to a cloud management platform, wherein the job task processing request is used for indicating information of the job task; the cloud management platform splitting the job task into a plurality of subtasks on the basis of the information, and generating a resource orchestration scheme for the plurality of subtasks; and subsequently, the cloud management platform creating a logical node of the tenant on the basis of the resource orchestration scheme, wherein the logical node includes a virtual device implemented on the basis of a plurality of physical devices, such that the cloud management platform can install, on the logical node, an operating system image formulated by the tenant, and thus the logical node can run a plurality of virtual instances, and instruct the plurality of virtual instances to execute the plurality of subtasks.

Description

A job task processing method based on cloud services and a cloud management platform

[0001] The present application claims priority to the Chinese patent application No. 202410796623.8, filed on June 19, 2024, entitled "A matrix resource processing method based on a cloud management platform and a cloud management platform", and to the Chinese patent application No. 202411098724.4, filed on August 09, 2024, entitled "A job task processing method based on cloud services and a cloud management platform", both of which are incorporated herein by reference in their entirety. TECHNICAL FIELD

[0002] Embodiments of the present application relate to the field of cloud technology, and in particular to a job task processing method based on cloud services and a cloud management platform. BACKGROUND

[0003] With the rapid development of cloud technology, more and more tenants choose to use the server racks provided by cloud vendors to complete their businesses. The servers usually have certain performance and can efficiently complete the tenants' businesses.

[0004] In the related art, the cloud service system provided by the cloud vendor can include a cloud management platform and infrastructure. The infrastructure includes multiple servers with different performance, i.e., the specifications of the resources occupied by the multiple servers are different. When a tenant needs to complete its business in the cloud, the cloud management platform can provide the tenant with the multiple servers, and the tenant can select a server with certain performance according to the needs of its business. Therefore, the cloud management platform can allocate the server to the tenant for exclusive use to complete the tenant's business.

[0005] In the above process, after the tenant selects a server, the specifications of the resources occupied by the server are fixed, i.e., the performance of the server is fixed, which cannot fully meet the tenant's increasingly complex business needs, resulting in poor tenant experience. SUMMARY

[0006] Embodiments of the present application provide a job task processing method based on cloud services and a cloud management platform, which can meet the tenant's increasingly complex business needs and improve user experience.

[0007] A first aspect of the embodiments of the present application provides a cloud service-based job task processing method. The method is applied to a cloud management platform, and the cloud management platform is used to manage infrastructures, including a CPU device pool, a memory device pool, a network card device pool, an extension processor device pool, and a disk device pool. Multiple CPUs in the CPU device pool, multiple memories in the memory device pool, multiple network cards in the network card device pool, multiple extension processors in the extension processor device pool, and multiple disks in the disk device pool are all connected to a high-speed interconnection network. The method includes the following steps.

[0008] When a tenant needs to process a job task, the cloud management platform can provide a task processing interface to the tenant. Then, the tenant can input a job task processing request for the job task to the task processing interface. In this way, the cloud management platform can receive, through the task processing interface, a job task processing request for the job task sent by the tenant through a client, and the job task processing request for the job task is used to indicate a model, data, and performance requirement required by the job task.

[0009] After obtaining the job task processing request for the job task, the cloud management platform can first divide the job task into multiple subtasks based on the model and data required by the job task included in the request, and generate a resource arrangement scheme for the multiple subtasks based on the performance requirement required by the job task included in the request.

[0010] Since the resource arrangement scheme includes selecting, from the CPU device pool, a CPU that meets the performance requirement and is idle, selecting, from the extension processor device pool, an extension processor that meets the performance requirement and is idle, selecting, from the memory device pool, a memory that meets the performance requirement and is idle, selecting, from the network card device pool, a network card that meets the performance requirement and is idle, and selecting, from the disk device pool, a disk that meets the performance requirement and is idle, the cloud management platform can create the logical node on the selected CPUs, extension processors, memories, network cards, and disks. The logical node includes virtual CPUs implemented based on the CPUs, virtual extension processors implemented based on the extension processors, virtual memories implemented based on the memories, virtual network cards implemented based on the network cards, virtual disks implemented based on the disks, and a virtual bus network. It should be noted that in the logical node, the CPUs, extension processors, memories, network cards, and disks can communicate through a subnetwork of the high-speed interconnection network, and therefore the virtual CPUs, virtual extension processors, virtual memories, virtual network cards, and virtual disks can communicate through the corresponding virtual bus network of the subnetwork.

[0011] After the logical node is created, the cloud management platform can remind the tenant to provide a self-made operating system image or an operating system image selected by the tenant on the cloud management platform. Then, the cloud management platform can install the operating system image specified by the tenant on the logical node, and the logical node installed with the operating system image can run multiple virtual instances to complete multiple subtasks included in the job task through the multiple virtual instances, thereby meeting the job requirements of the tenant.

[0012] As can be seen from the above method, since the multiple physical devices (CPU, extended processor, memory, network card and disk) used to build the logical node can be selected according to the performance requirements of the job task of the tenant, and the specifications of the multiple physical devices can be different, the specification of the resources occupied by the logical node created based on the multiple physical devices can be understood as being set by the tenant according to its own requirements, that is, the performance of the logical node is set according to the requirements of the tenant. Since the logical node has sufficient performance, the tenant can make the logical node complete various job tasks of the tenant, thereby meeting the increasingly complex business requirements of the tenant and improving the user experience.

[0013] In one possible implementation, the cloud management platform generates a resource arrangement scheme for the multiple subtasks includes: the cloud management platform generates multiple candidate resource arrangement schemes for the multiple subtasks; the cloud management platform evaluates the multiple candidate resource arrangement schemes to obtain evaluation values of the multiple candidate resource arrangement schemes, the evaluation values of the multiple candidate resource arrangement schemes being used to indicate the cost paid for creating the logical node based on the multiple candidate resource arrangement schemes; and the cloud management platform determines, from the multiple candidate resource arrangement schemes, a candidate resource arrangement scheme with the minimum evaluation value as the resource arrangement scheme for the multiple subtasks. In the foregoing implementation, after the job task is split into multiple subtasks, the cloud management platform can generate multiple candidate resource arrangement schemes for the multiple subtasks based on the performance requirements of the job task. Then, the cloud management platform can evaluate the multiple candidate resource arrangement schemes to obtain evaluation values of the multiple candidate resource arrangement schemes, the evaluation values of the multiple candidate resource arrangement schemes being used to indicate the cost paid for creating the logical node based on the multiple candidate resource arrangement schemes. Then, the cloud management platform can determine, from the multiple candidate resource arrangement schemes, a candidate resource arrangement scheme with the minimum evaluation value as the final resource arrangement scheme for the multiple subtasks. As can be seen, the cloud management platform can generate multiple candidate resource arrangement schemes, each of which includes multiple physical devices used to create the logical node of the tenant, and select the optimal scheme by evaluating the implementation cost of each scheme, so as to create the logical node based on the multiple physical devices included in the optimal scheme, which is conducive to reducing the cost of creating the logical node by the tenant and the cloud management platform.

[0014] In one possible implementation, the method further includes: a cloud management platform acquiring the communication behavior and resource utilization of the logical node, including the utilization of virtual CPUs, virtual memory, virtual network interface cards (NICs), virtual extended processors (VEPs), and virtual disks; based on the communication behavior and resource utilization, the cloud management platform determining the target device to be replaced within the logical node, where the target device is a device mapped from one or any combination of virtual CPUs, virtual memory, virtual NICs, VEPs, and virtual disks; the cloud management platform selecting an idle device from one or any combination of CPU device pools, memory device pools, NIC device pools, VEPs device pools, and disk device pools to replace the target device; and the cloud management platform connecting the idle device to the virtual bus network, removing the target device from the virtual bus network, and marking the target device's status as idle. In the aforementioned implementation, after creating the logical node, the cloud management platform can collect the communication behavior of the logical node and the resource utilization of the virtual devices contained within the logical node in real time. Next, based on the communication behavior and resource utilization, the cloud management platform can identify the target device to be replaced among the physical devices used to create the logical node. The target device is a subset of the physical devices (CPU, memory, network interface card, virtual extended processor, and disk) used to create the logical node. Then, the cloud management platform can select an idle device from one or any combination of the CPU device pool, memory device pool, network interface card device pool, virtual extended processor device pool, and disk device pool to replace the target device. Subsequently, the cloud management platform can connect the idle device to the virtual bus network of the logical node and remove the target device from the virtual bus network of the logical node. Therefore, since the tenant's logical node is built based on multiple freely selected physical devices, the resource specifications occupied by the logical node are combined, meaning the resource specifications of the logical node can be understood as adjustable. Thus, the cloud management platform can adjust the internal structure of the logical node to give it better performance, thereby providing tenants with better services and further improving the tenant experience.

[0015] In one possible implementation, the virtual bus network includes a first virtual network plane and a second virtual network plane. The first virtual network plane contains a first virtual instance among multiple virtual instances, and the second virtual network plane contains a second virtual instance among multiple virtual instances. The first virtual instance deploys a first type of subtask among multiple subtasks, and the second virtual instance deploys a second type of subtask among multiple subtasks. In the aforementioned implementation, since a tenant's job task can contain multiple types of subtasks, the cloud management platform can enable the virtual bus network within the logical node to contain multiple virtual network planes. This allows multiple virtual instances of the logical node to complete different types of subtasks through these multiple network planes, ensuring that the execution processes of different types of subtasks do not interfere with each other.

[0016] In one possible implementation, the extended processor type of the extended processor device pool is one or any combination of NPU, GPU, TPU, and DPU.

[0017] In one possible implementation, high-speed interconnect networks are achieved through PCIe networks, IB networks, or CXL networks.

[0018] A second aspect of this application provides a cloud management platform for managing infrastructure, including a CPU device pool, a memory device pool, a network interface card (NIC) device pool, an extended processor device pool, and a disk device pool. Multiple CPUs in the CPU device pool, multiple memory modules in the memory device pool, multiple NICs in the NIC device pool, multiple extended processors in the extended processor device pool, and multiple disks in the disk device pool are all connected to a high-speed interconnect network. The cloud management platform includes: an acquisition module for acquiring job task processing requests input by tenants, the job task processing requests specifying the required models, data, and performance requirements of the job task; a splitting module for splitting the job task into multiple sub-tasks in response to the job task processing request and generating a resource orchestration scheme for the multiple sub-tasks; and a creation module for creating logical nodes according to the resource orchestration scheme, wherein the logical nodes include virtual CPUs, virtual memory, virtual NICs, virtual extended processors, virtual disks, and virtual buses. The network, virtual CPU, virtual memory, virtual network interface card (NIC), virtual extended processor, and virtual disk are logically connected to the virtual bus. The virtual CPU is implemented using at least one idle CPU that meets performance requirements from the CPU device pool. The virtual memory is implemented using at least one idle memory chip that meets performance requirements from the memory device pool. The virtual NIC is implemented using at least one idle NIC that meets performance requirements from the NIC device pool. The virtual extended processor is implemented using at least one idle extended processor that meets performance requirements from the extended processor device pool. The virtual disk is implemented using at least one idle disk that meets performance requirements from the disk device pool. The virtual bus network is implemented through a sub-network of the high-speed interconnect network. The processing module is used to determine the operating system image input or selected by the tenant, notify the logical node to install the operating system image, and deploy multiple subtasks to run in multiple virtual instances on the logical node with the operating system image installed. Each virtual instance has at least one subtask deployed.

[0019] In one possible implementation, a split module is used to: generate multiple candidate resource orchestration schemes for multiple subtasks; evaluate the multiple candidate resource orchestration schemes to obtain evaluation values ​​for the multiple candidate resource orchestration schemes, the evaluation values ​​of the multiple candidate resource orchestration schemes being used to indicate the cost required to create logical nodes based on the multiple candidate resource orchestration schemes; and determine the candidate resource orchestration scheme with the smallest evaluation value from the multiple candidate resource orchestration schemes as the resource orchestration scheme for the multiple subtasks.

[0020] In one possible implementation, the cloud management platform further includes: a collection module for acquiring the communication behavior and resource utilization of logical nodes, including the utilization of virtual CPUs, virtual memory, virtual network interface cards (NICs), virtual extended processors (VEPs), and virtual disks; a determination module for determining, based on the communication behavior and resource utilization, a target device to be replaced in the logical node, wherein the target device is a device mapped from one or any combination of virtual CPUs, virtual memory, virtual NICs, VEPs, and virtual disks; a selection module for selecting an idle device that can replace the target device from one or any combination of CPU device pools, memory device pools, NIC device pools, VEPs device pools, and disk device pools; and an access module for connecting the idle device to the virtual bus network, removing the target device from the virtual bus network, and marking the target device's status as idle.

[0021] In one possible implementation, the virtual bus network includes a first virtual network plane and a second virtual network plane. The first virtual network plane includes a first virtual instance among a plurality of virtual instances, and the second virtual network plane includes a second virtual instance among a plurality of virtual instances. The first virtual instance deploys a first type of subtask among a plurality of subtasks, and the second virtual instance deploys a second type of subtask among a plurality of subtasks.

[0022] In one possible implementation, the extended processor type of the extended processor device pool is one or any combination of NPU, GPU, TPU, and DPU.

[0023] In one possible implementation, high-speed interconnect networks are achieved through PCIe networks, IB networks, or CXL networks.

[0024] A third aspect of this application provides a cloud service system. The cloud service system includes infrastructure and a cloud management platform for managing the infrastructure. The infrastructure includes a CPU device pool, a memory device pool, a network interface card (NIC) device pool, and a disk device pool. Multiple CPUs in the CPU device pool, multiple memory modules in the memory device pool, multiple NICs in the NIC device pool, and multiple disks in the disk device pool are all connected to a high-speed interconnect network. The high-speed interconnect network is used to enable interconnection between devices in each device pool within and between pools. The cloud management platform performs the method described in the first aspect or any possible implementation of the first aspect on these infrastructures.

[0025] A fourth aspect of this application provides a computing device cluster, the computing device cluster including at least one computing device, each computing device including a processor and a memory: the memory is used to store instructions; the processor is used to cause the computing device cluster to perform the method described in the first aspect or any possible implementation of the first aspect according to the instructions.

[0026] A fifth aspect of this application provides a computer storage medium storing one or more instructions that, when executed by one or more computers, cause the one or more computers to perform the method described in the first aspect or any possible implementation of the first aspect.

[0027] A sixth aspect of this application provides a computer program product storing instructions that, when executed by a computer, cause the computer to perform the method described in the first aspect or any possible implementation of the first aspect.

[0028] In this embodiment, when a tenant needs to process a job task, the tenant can send a job task processing request to the task processing interface provided by the cloud management platform. Since the job task processing request indicates information about the job task to be processed (including the model, data, and performance requirements of the job task, etc.), the cloud management platform can, based on this information, split the job task into multiple sub-tasks and generate a resource orchestration scheme for these sub-tasks. This resource orchestration scheme includes resources selected by the cloud management platform from multiple physical device pools (CPU device pool, extended processor device pool, memory device pool, network interface card device pool, and disk device pool). The selected physical devices (CPU, extended processors, memory, network interface cards, and disks) meet the aforementioned performance requirements. Therefore, the cloud management platform can create logical nodes for tenants on these physical devices. Each logical node contains virtual devices (virtual CPU, virtual extended processors, virtual memory, virtual network interface cards, and virtual disks) implemented based on these physical devices. The cloud management platform can then install the tenant-specified operating system image on this logical node, enabling it to run multiple virtual instances and execute various subtasks to meet the tenant's job requirements. In this process, since the multiple physical devices used to construct the logical node can be selected according to the performance requirements of the tenant's job tasks, and these devices can have different specifications, the resource specifications occupied by the logical node created based on these physical devices can be understood as being set by the tenant according to their own needs. That is, the performance of the logical node is set according to the tenant's own requirements. Because the logical node has sufficient performance, the tenant can use it to complete various job tasks, thereby meeting the increasingly complex business needs of the tenant and improving the user experience. Attached Figure Description

[0029] Figure 1 is a schematic diagram of a cloud service system provided in an embodiment of this application;

[0030] Figure 2a is a structural schematic diagram of the infrastructure provided in an embodiment of this application;

[0031] Figure 2b is another structural schematic diagram of the infrastructure provided in the embodiment of this application;

[0032] Figure 3 is a flowchart illustrating a cloud matrix creation method based on a cloud management platform provided in an embodiment of this application;

[0033] Figure 4 is another structural schematic diagram of the cloud service system provided in the embodiment of this application;

[0034] Figure 5 is a schematic diagram of a cloud service system provided in an embodiment of this application;

[0035] Figure 6 is a schematic diagram of the structure of a cloud management platform provided in an embodiment of this application;

[0036] Figure 7 is a schematic diagram of a computing device provided in an embodiment of this application;

[0037] Figure 8 is a schematic diagram of a computing device cluster provided in an embodiment of this application;

[0038] Figure 9 is a schematic diagram of computer devices in a computer cluster connected via a network according to an embodiment of this application. Detailed Implementation

[0039] This application provides a cloud service-based job task processing method and a cloud management platform, which can meet the increasingly complex business needs of tenants and thus improve user experience.

[0040] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of elements is not necessarily limited to those elements, but may include other elements not explicitly listed or inherent to those processes, methods, products, or apparatuses.

[0041] With the rapid development of cloud technology, more and more tenants are choosing server racks provided by cloud providers to complete their business. Servers usually have certain performance and can efficiently complete tenants' business.

[0042] In related technologies, cloud service systems provided by cloud vendors can include cloud management platforms and infrastructure. This infrastructure includes multiple servers with varying performance levels, meaning these servers occupy different resource specifications. When a tenant needs to complete their business in the cloud, the cloud management platform can provide these multiple servers to the tenant. The tenant can choose a server with specific performance characteristics based on their business needs. Therefore, the cloud management platform can allocate that server to the tenant for dedicated use to complete their business. For example, the cloud management platform can provide the tenant with various server products, such as Server 1 and Server 2. Server 1 has 20 CPUs and 100GB of memory, while Server 2 has 15 CPUs and 80GB of memory. Based on the tenant's own business needs, the tenant can choose Server 1 as their dedicated server, and thus the cloud management platform can allocate Server 1 to the tenant for use.

[0043] In the process described above, after a tenant selects a server, the specifications of the resources occupied by that server are fixed, that is, the performance of the server is fixed, which cannot fully meet the increasingly complex business needs of the tenant, resulting in a poor tenant experience.

[0044] Furthermore, when tenants need to adjust the performance of their selected servers, they are often limited by the specifications of the hardware resources occupied by a single server, which prevents them from making performance adjustments and also leads to a poor user experience.

[0045] To address the aforementioned problems, this application provides a cloud service-based job task processing method. This method can be implemented through a cloud service system. Figure 1 is a schematic diagram of the cloud service system provided in this application embodiment. As shown in Figure 1, the cloud service system includes infrastructure that can provide cloud services and a cloud management platform that manages this infrastructure. The cloud management platform and the infrastructure are described in detail below:

[0046] A cloud management platform can centrally manage the infrastructure of the entire cloud service system. (For example, within the infrastructure, it creates logical nodes to serve tenants according to their instructions; these logical nodes, also known as cloud matrices, can be used to execute tenant business logic, thereby meeting their business needs.) The cloud management platform can also be accessible to tenants outside the cloud service system and respond to their requests. For instance, it can provide various interfaces, such as login and task processing interfaces, for tenant clients (e.g., the terminal devices used by the tenant or the browsers on those devices). Specifically, the cloud management platform can authenticate tenant clients through the login interface, allowing them to log in after successful authentication. For example, the cloud management platform can also allow tenant clients to send job task processing requests to the cloud management platform through a task processing interface. Since the job task processing request is used to indicate the information of the job task to be processed (including the model (which can be a neural network model or other models or rules), data, and performance requirements, etc.), the cloud management platform can break down the job task into multiple sub-tasks based on this information and generate a resource orchestration scheme for these multiple sub-tasks. Since the resource orchestration scheme includes physical devices selected by the cloud management platform from multiple physical device pools that meet the aforementioned performance requirements, the cloud management platform can create logical nodes for the tenant on these physical devices. The logical node contains virtual devices implemented based on these physical devices. Therefore, the cloud management platform can install the operating system image specified by the tenant on the logical node, so that the logical node with the operating system image installed can run multiple virtual instances and have these multiple virtual instances execute these multiple sub-tasks, thereby meeting the tenant's job requirements.

[0047] The infrastructure comprises multiple pools of physical devices, including pools of computing devices, storage devices, and network devices of various types. The computing device pools may include CPU pools and extended processor (xPU) pools. Extended processor pools may include graphics processing unit (GPU) pools, NPU pools, tensor processing unit (TPU) pools, and data processing unit (DPU) pools, etc. The storage device pools may include memory pools and disk pools, etc. The network device pools may include network interface card (NIC) pools, etc. Specifically, the CPU pool contains multiple CPUs (these CPUs may have the same or different specifications), the extended processor pool contains multiple extended processor pools (these extended processor pools may have the same or different specifications), the memory pool contains multiple memory modules (these memory modules may have the same or different specifications), the disk pool contains multiple disks (these disks may have the same or different specifications), and the NIC pool contains multiple network interface cards (these NICs may have the same or different specifications). As can be seen, the cloud management platform can select from these physical device pools several types of physical devices that meet the performance requirements of the tenant's job tasks and have certain specifications to build the tenant's logical nodes.

[0048] It is worth noting that these multiple physical device pools are presented and communicated with in various ways:

[0049] (1) As shown in Figure 2a (Figure 2a is a structural schematic diagram of the infrastructure provided in the embodiment of this application), in these multiple physical device pools, all physical devices in each physical device pool are randomly and dispersed on racks, rather than being arranged in a fixed combination within the chassis of physical servers in the racks. Therefore, in these multiple physical device pools, any two physical devices in any physical device pool can communicate with each other through a high-speed interconnect device, and physical devices in any two physical device pools can also communicate with each other through a high-speed interconnect device. This high-speed interconnect device may include a high-speed interconnect bus and a high-speed interconnect bus switch, etc. Thus, the high-speed interconnect device connects all physical devices in multiple physical device pools, forming a high-speed interconnect network among all physical devices (the "high-speed" in high-speed interconnect network refers to a bandwidth of no less than 40G / S). That is, multiple CPUs in the CPU device pool, multiple extended processors in the extended processor device pool, multiple memory modules in the memory device pool, multiple network cards in the network card device pool, and multiple disks in the disk device pool are all connected to the high-speed interconnect network, and therefore, these physical devices can communicate with each other through the high-speed interconnect network.

[0050] It is also worth noting that after the cloud management platform obtains the resource orchestration scheme for multiple subtasks of a tenant's job task, it can select several physical devices (e.g., CPUs, extended processors, memory, network cards, and disks, etc., in the dashed box of Figure 2a) from multiple physical device pools based on the resource orchestration scheme. The platform then creates logical nodes on these physical devices. These logical nodes contain virtual devices implemented based on these physical devices (i.e., these physical devices and these virtual devices have a mapping relationship). Since these physical devices are all connected to a high-speed interconnect network, the network formed between these physical devices is part of the high-speed interconnect network, and can also be called a sub-network of the high-speed interconnect network (e.g., the dashed box in Figure 2a). Because these virtual devices are implemented based on these physical devices, these virtual devices can also be logically connected through a virtual bus network. This virtual bus network is implemented based on a sub-network of the high-speed interconnect network formed between these physical devices (i.e., the virtual bus network and this sub-network have a mapping relationship).

[0051] (2) As shown in Figure 2b (Figure 2b is another structural schematic diagram of the infrastructure provided in the embodiment of this application), these multiple physical device pools can be deployed in the form of multiple super nodes. Each super node contains multiple physical servers, and each physical server can contain multiple physical devices of different types (for example, a physical server contains at least one CPU, at least one memory, at least one extended processor, at least one network card and at least one disk). Any two physical servers can communicate with each other through a high-speed interconnect device. Therefore, for any physical server's CPU, it can not only use the physical server's network card, extended processor, memory and disk, but also the network card, extended processor, memory and disk of other physical servers. In this way, the same type of physical devices of different physical servers can be regarded as "pooled", so that all physical servers in multiple super nodes form these multiple physical device pools. Since all physical servers within multiple supernodes communicate with each other through high-speed interconnect devices, a high-speed interconnect network is formed among all physical servers. This is equivalent to a high-speed interconnect network being formed among multiple physical device pools. In other words, multiple CPUs in the CPU device pool, multiple extended processors in the extended processor device pool, multiple memory modules in the memory device pool, multiple network cards in the network card device pool, and multiple disks in the disk device pool are all connected to the high-speed interconnect network. Therefore, these physical devices can communicate with each other through the high-speed interconnect network.

[0052] It is also worth noting that after the cloud management platform obtains the resource orchestration scheme for multiple sub-tasks of the tenant's job task, the cloud management platform can select several physical devices from multiple physical device pools that meet the performance requirements of the tenant's job task based on the resource orchestration scheme (for example, several physical servers in the dashed box in Figure 2b, the CPU, extended processor, memory, network card and disk contained in these physical servers can be regarded as part of the CPU device pool, part of the extended processor device pool, part of the memory device pool, part of the network card device pool and part of the disk device pool, etc.), and create the logical node on these physical devices. The logical node contains virtual devices implemented based on these physical devices (that is, these physical devices and these virtual devices have a mapping relationship). Since these physical devices are all connected to the high-speed interconnection network, the network formed between these physical devices is part of the high-speed interconnection network, and can also be called a sub-network of the high-speed interconnection network (for example, the dashed box in Figure 2b). Since these virtual devices are implemented based on these physical devices, they can also be logically connected through a virtual bus network. This virtual bus network is implemented based on a sub-network of the high-speed interconnection network formed between these physical devices (i.e., the virtual bus network and the sub-network have a mapping relationship).

[0053] Furthermore, as shown in Figure 2b, the cloud management platform may include a logical node control module, a resource management module, a network management module, a pooled resource management module, a network controller, and a device controller. These modules will be described in detail below:

[0054] The logical node management module provides login and task processing interfaces to tenants, receiving task processing requests from tenants and creating dedicated logical nodes for each tenant. Furthermore, the module manages the lifecycle of tenant logical nodes and operates them according to tenant requests. It can also calculate the costs incurred by tenants using their logical nodes.

[0055] The resource management module may include a resource orchestration unit, a resource scheduling unit, and a behavior awareness unit. The resource orchestration unit, based on the job task information contained in the job task processing request, can orchestrate multiple candidate resource orchestration schemes for multiple sub-tasks of the job task from multiple physical device pools. Each candidate resource orchestration scheme may contain several physical devices, and the physical devices included in different candidate resource orchestration schemes are usually different. The unit then selects the final resource orchestration scheme from these multiple candidate schemes and triggers the resource scheduling module to execute the final resource orchestration scheme. The resource scheduling module can send the final resource orchestration scheme to the pooled resource module, so that the pooled resource module can construct the tenant's logical nodes based on the several physical devices in the resource orchestration scheme.

[0056] The network management module can manage the communication network between all physical devices in multiple physical device pools. It can collect information such as communication latency and bandwidth between physical devices to enable the resource orchestration unit to generate candidate resource orchestration schemes. In addition, the network management module can also collect the communication behavior of physical devices used to create logical nodes for tenants, so that the behavior awareness unit, resource orchestration unit, and resource scheduling unit can adjust the logical nodes of tenants in the future.

[0057] The pooled resource management module can separate several physical devices included in the final resource orchestration scheme from the corresponding physical device pool to isolate these physical devices from the remaining devices in the pool. Therefore, the pooled resource management module can instruct the device controller to perform the corresponding separation and isolation operations on these physical devices, and instruct the network controller to configure the sub-networks of the high-speed interconnection network formed between these physical devices. This allows the sub-networks between these physical devices to form multiple network planes required by the tenant, thereby creating logical nodes for the tenant on these physical devices. For ease of explanation, the following example is used in conjunction with Figure 2b. Assume that the sub-networks between the physical servers (physical devices) used to create logical nodes for tenants have multiple network planes. These multiple network planes include cross-supernode network planes and intra-supernode network planes, etc. A cross-supernode network plane represents the network plane formed between physical servers (physical devices) located on different supernodes used to create the logical node, while an intra-supernode network plane represents the network plane formed between physical servers (physical devices) located on the same supernode used to create the logical node. Accordingly, the physical servers used to create the logical node can enable the logical node to contain corresponding virtual devices and a virtual bus network for these virtual devices to access. Since the virtual bus network is implemented based on the sub-network, it also contains multiple virtual network planes, each corresponding one-to-one with the multiple network planes contained in the sub-network. Based on this, when the logical node installs the operating system image specified by the tenant, it can run multiple virtual instances. These virtual instances are set up in these multiple virtual network planes. Virtual instances in different virtual network planes are used to execute different types of subtasks in the job task, while virtual instances in the same virtual network plane are used to execute the same type of subtask in the job task, because subtasks of the same type executed by virtual instances in the same virtual network plane often need to be linked and exchange data.

[0058] In addition, the pooled resource module can obtain information such as the resource utilization rate of the physical devices used to create the logical nodes of tenants in real time, so that the behavior perception unit, resource orchestration unit and resource scheduling unit can make adjustments to the logical nodes of tenants in the future.

[0059] Furthermore, as shown in Figure 2a (not shown in Figure 2b), each physical device in this pool of multiple physical devices has a certain type of interface. For any given physical device, it can connect to the high-speed interconnect bus switch through its interface, and then communicate with other physical devices through the high-speed interconnect bus.

[0060] Furthermore, for the virtual instances on the tenant's logical node, these virtual instances can be presented in various ways. For example, they can be virtual machines (VMs) created by the cloud management platform on the physical device selected by the cloud management platform using virtualization technology. Alternatively, these virtual instances can be containers (Docker) created by the cloud management platform on the physical device selected by the cloud management platform using virtualization technology. Alternatively, these virtual instances can be micro virtual machines (microVMs) created by the cloud management platform on the physical device selected by the cloud management platform using virtualization technology, and so on.

[0061] Furthermore, for the aforementioned multiple physical device pools, these multiple physical device pools can be deployed in the same site or different sites. The site can be presented in various forms, such as a region in the infrastructure, an availability zone in the infrastructure, a data center (DC) in the infrastructure, a room in the infrastructure, and so on.

[0062] Furthermore, the high-speed interconnection network built between these multiple physical device pools can be implemented based on multiple high-speed interconnect bus switches. Suppose these multiple physical device pools are deployed across a data center, which often contains multiple racks. These racks are used to house several physical devices from each physical device pool. In order to enable communication between physical devices in different racks, each rack often needs to deploy at least one high-speed interconnect bus switch. In this way, the racks can communicate with each other through the high-speed interconnect bus switches, thereby forming a high-speed interconnection network within the data center.

[0063] Furthermore, the aforementioned high-speed interconnect network can take many forms. For example, it can be a high-speed serial computer expansion bus standard (Peripheral Component Interconnect Express, PCIe) network, an InfiniBand (IB) wireless network, a Compute Express Link (CXL) network, or even an interconnect network between devices developed by cloud vendors (the bandwidth of which also needs to be no less than 40 Gbps), etc. Correspondingly, the high-speed interconnect devices connected to each physical device can be communication devices based on the PCIe protocol, CXL protocol, IB protocol, or a communication protocol developed by the cloud vendor. Similarly, the interfaces used by the physical devices in each physical device pool to access the high-speed interconnect network can be PCIe interfaces, CXL interfaces, IB interfaces, or interfaces developed by the cloud vendor, etc.

[0064] Based on the aforementioned cloud service system, when a tenant needs to process job tasks, the tenant can send a job task processing request to the task processing interface provided by the cloud management platform. Since the job task processing request is used to indicate the information of the job task to be processed (including the model, data, and performance requirements required by the job task, etc.), the cloud management platform can split the job task into multiple sub-tasks based on this information and generate a resource orchestration scheme for these multiple sub-tasks. Since the resource orchestration scheme includes physical devices selected by the cloud management platform from multiple physical device pools that meet the aforementioned performance requirements, the cloud management platform can create logical nodes for the tenant on these physical devices. The logical node contains virtual devices implemented based on these physical devices. Therefore, the cloud management platform can install the operating system image specified by the tenant on the logical node, so that the logical node with the operating system image installed can run multiple virtual instances and have these multiple virtual instances execute these multiple sub-tasks, thereby meeting the tenant's job requirements. In the aforementioned process, since the multiple physical devices used to construct the logical node can be selected according to the performance requirements of the tenant's tasks, and these physical devices can have different specifications, the resource specifications occupied by the logical node created based on these physical devices can be understood as being set by the tenant according to their own needs. That is, the performance of the logical node is set according to the tenant's own needs. Because the logical node has sufficient performance, the tenant can use it to complete various tasks, thereby meeting the increasingly complex business needs of the tenant and improving the user experience. To further understand the workflow of the cloud management platform, the following description, in conjunction with Figure 3, illustrates this workflow. Figure 3 is a flowchart illustrating a cloud service-based job task processing method provided in this embodiment. As shown in Figure 3, this method can be implemented through the cloud service system shown in Figure 1. The cloud service system includes infrastructure providing cloud services to tenants and a cloud management platform managing this infrastructure. This infrastructure may include CPU device pools, memory device pools, network interface card (NIC) device pools, and disk device pools. Multiple CPUs in the CPU device pool, multiple memory modules in the memory device pool, multiple NICs in the NIC device pool, and multiple disks in the disk device pool are all connected to a high-speed interconnect network. The high-speed interconnect network is used to interconnect physical devices within and between physical device pools in the infrastructure. The method includes:

[0065] 301. The cloud management platform obtains the job task processing request input by the tenant. The job task processing request is used to specify the model, data, and performance requirements of the job task.

[0066] In this embodiment, when a tenant needs to process a job task, the cloud management platform can provide a task processing interface to the tenant's client (e.g., a task processing bar on the tenant's interface). The tenant can then input a job task processing request for that job task into the task processing interface through their client. In this way, the cloud management platform can receive the job task processing request sent by the tenant through their client via the task processing interface. It is worth noting that the task processing request for this job is used to indicate the model, data, and performance requirements of the job. The model required by the job usually refers to the model that can be used to complete the job (for example, if the job is a model training task, the model is the model to be trained; or if the job is a data processing task, the model is the data processing model or data processing rules, etc.). The data required by the job refers to the data that can be used to complete the job (for example, if the job is a model training task, the data is the training data; or if the job is a data processing task, the data is the data to be processed, etc.). The performance requirements of the job refer to various information about the logical nodes required to complete the job. This information includes the basic information of the logical node (e.g., name, billing mode, etc.), the specifications of the physical devices used to create the logical node (which may include CPU, network card, extended processor, memory, and disk), and information about the multiple network planes formed between the physical devices used to create the logical node, etc.

[0067] For example (this example is based on the example shown in Figure 2b), when a tenant needs to complete a certain job task, the tenant can log in to the cloud management platform. The cloud management platform can provide the tenant with a tenant interface, which includes a job task processing section. Therefore, the tenant can enter the following job task processing request into the job task processing section. This request can include the model, data, and performance requirements required for the job task. Among them, the performance requirements required for the job task may include:

[0068] Based on the above performance requirements, let's assume that the tenant sets two supernodes in the performance requirements for this job task, used to create the logical nodes required for the job task. In the relevant information of these two supernodes, their serial numbers are defined as 1 and 2, meaning the supernodes required to create this logical node are supernode 1 and supernode 2. Next, the tenant can also configure supernode 1 to contain two physical servers, defining their serial numbers as 1.1 and 1.2 in the relevant information of these two physical servers, and setting the required specifications for these two physical servers (i.e., the specifications of the physical devices contained in these two physical servers, including CPU, memory, xPU, network card, and disk, etc.). That is, supernode 1 contains physical server 1.1 and physical server 1.2. Similarly, the tenant can also configure supernode 2 to contain two physical servers, defining their serial numbers as 2.1 and 2.2 in the relevant information of these two physical servers, and setting the required specifications for these two physical servers. That is, supernode 2 contains physical server 2.1 and physical server 2.2.

[0069] Furthermore, the tenant can configure the sub-network of the high-speed interconnection network formed between these two supernodes to contain three network planes, and in the relevant information of these three network planes, set the IDs of these three network planes to 1, 2 and 3, set the type of network plane 1 to a network plane within supernode 1 (i.e., network plane 1 is composed of supernode 1), set the type of network plane 2 to a network plane within supernode 2 (i.e., network plane 2 is composed of supernode 2), and set the type of network plane 3 to a network plane spanning supernode 1 and supernode 2 (i.e., network plane 3 is composed of supernode 1 and supernode 2).

[0070] Furthermore, tenants can configure the source physical server of network plane 1 as physical server 1.1 and the destination physical server as physical server 1.2 in the network plane 1 topology information; the source physical server of network plane 2 as physical server 2.1 and the destination physical server as physical server 2.2 in the network plane 2 topology information; and the source physical server of network plane 3 as physical server 1.1 and the destination physical server as physical server 2.2 in the network plane 3 topology information. It is worth noting that in network plane 3, communication between physical server 1.1 and physical server 2.2 can be achieved through physical server 1.2 and / or 2.1, or it can be achieved without physical server 2.1 and node 2.1.

[0071] 302. The cloud management platform responds to job task processing requests by splitting the job task into multiple sub-tasks and generating resource orchestration schemes for the multiple sub-tasks.

[0072] 303. The cloud management platform creates logical nodes according to the resource orchestration scheme. The logical nodes include virtual CPUs, virtual memory, virtual network cards, virtual extended processors, virtual disks, and virtual bus networks. The virtual CPUs, virtual memory, virtual network cards, virtual extended processors, and virtual disks are logically connected to the virtual bus. The virtual CPU is implemented by at least one CPU in the CPU device pool that meets the performance requirements and is idle. The virtual memory is implemented by at least one memory in the memory device pool that meets the performance requirements and is idle. The virtual network card is implemented by at least one network card in the network card device pool that meets the performance requirements and is idle. The virtual extended processor is implemented by at least one extended processor in the extended processor device pool that meets the performance requirements and is idle. The virtual disk is implemented by at least one disk in the disk device pool that meets the performance requirements and is idle. The virtual bus network is implemented through a sub-network of the high-speed interconnect network.

[0073] After receiving the task processing request for the job, the cloud management platform can parse the task request to obtain the model, data and performance requirements required for the job. Therefore, the cloud management platform can first divide the job into multiple sub-tasks based on the model and data required for the job, and generate a resource orchestration scheme for these multiple sub-tasks based on the performance requirements required for the job.

[0074] Since the resource orchestration scheme involves the cloud management platform selecting at least one idle CPU that meets performance requirements from the CPU device pool, at least one idle extended processor that meets performance requirements from the extended processor device pool, at least one idle memory that meets performance requirements from the memory device pool, at least one idle network card that meets performance requirements from the network card device pool, and at least one idle disk that meets performance requirements from the disk device pool, the cloud management platform can create the logical node on these selected CPUs, extended processors, memory, network cards, and disks. The logical node includes virtual CPUs implemented based on these CPUs, virtual extended processors implemented based on these extended processors, virtual memory implemented based on these memory, virtual network cards implemented based on these network cards, virtual disks implemented based on these disks, and a virtual bus network. It should be noted that in this logical node, since these CPUs, these extended processors, these memories, these network cards, and these disks are all connected to a sub-network of the high-speed interconnect network, that is, these CPUs, these extended processors, these memories, these network cards, and these disks can communicate with each other through this sub-network, the virtual bus network implemented based on this sub-network can be logically connected to these virtual CPUs, these virtual extended processors, these virtual memories, these virtual network cards, and these virtual disks respectively. In other words, these virtual CPUs, these virtual extended processors, these virtual memories, these virtual network cards, and these virtual disks can communicate with each other through this virtual bus network.

[0075] Specifically, the sub-networks between these CPUs, these extended processors, these memories, these network cards, and these disks may contain multiple network planes. Since the virtual bus network is implemented based on the sub-network, the virtual bus network also contains multiple virtual network planes. These multiple virtual network planes (including the aforementioned first virtual network plane and second virtual network plane) correspond one-to-one with the multiple network planes contained in the sub-network.

[0076] More specifically, cloud management platforms can generate resource orchestration schemes in the following ways:

[0077] After breaking down the job task into multiple subtasks, the cloud management platform can generate multiple candidate resource orchestration schemes for the subtasks based on the performance requirements of the job task. It should be noted that while the physical devices selected by the cloud management platform from multiple physical device pools in different candidate resource orchestration schemes all meet the performance requirements, the specific physical devices selected by the cloud management platform from the multiple physical device pools in different candidate resource orchestration schemes will vary. That is, while the CPU, extended processors, memory, network interface cards (NICs), and disks selected by the cloud management platform in each candidate resource orchestration scheme all meet the performance requirements, the CPU, extended processors, memory, NICs, and disks selected by the cloud management platform in one candidate resource orchestration scheme are usually completely different or partially different from those selected by the cloud management platform in another candidate resource orchestration scheme.

[0078] Next, the cloud management platform can evaluate multiple candidate resource orchestration schemes (for example, the cloud management platform can try to simulate the creation of the logical node using multiple candidate resource orchestration schemes) to obtain evaluation values ​​for multiple candidate resource orchestration schemes. The evaluation values ​​of multiple candidate resource orchestration schemes are used to indicate the cost required to create the logical node based on multiple candidate resource orchestration schemes. For any candidate resource orchestration scheme, the larger the evaluation value of the candidate resource orchestration scheme, the greater the cost required to create the logical node based on the candidate resource orchestration scheme, and the smaller the evaluation value of the candidate resource orchestration scheme, the smaller the cost required to create the logical node based on the candidate resource orchestration scheme.

[0079] Then, the cloud management platform can select the candidate resource orchestration scheme with the lowest evaluation value from multiple candidate resource orchestration schemes as the final resource orchestration scheme for multiple subtasks. In this way, the cloud management platform can create the logical node using the CPU, extended processors, memory, network interface cards, and disks included in the resource orchestration scheme.

[0080] Continuing with the example above, as shown in Figure 4 (Figure 4 is another structural schematic diagram of the cloud service system provided in this application embodiment), suppose multiple supernodes have been created (i.e., these multiple supernodes form multiple physical device pools), namely supernode A, supernode B, ..., supernode N, and supernode A contains candidate physical servers a.1 to physical server a.6, supernode B contains candidate physical servers b.1 to physical server b.6, ..., and supernode N contains candidate physical servers n.1 to physical server n.6. All physical servers are connected to a high-speed interconnect network, and each physical server contains a certain number of idle physical devices, such as CPU, extended processor, memory, network card, and disk, etc.

[0081] After determining the model, data, and performance requirements for a tenant's job task, the logical node control module of the cloud management platform can trigger the resource orchestration unit and send the required model, data, and performance requirements to the resource orchestration unit. Next, the resource orchestration unit can divide the job task into multiple subtasks based on the required model and data. Since the performance requirements of this job task indicate that the tenant's logical nodes need to include supernode 1 and supernode 2, supernode 1 includes physical server 1.1 and physical server 1.2, and supernode 2 includes physical server 2.1 and physical server 2.2. Furthermore, these two supernodes, i.e., these four physical servers, constitute network plane 1, network plane 2, and network plane 3. In addition, the resource orchestration unit can also determine the specifications of the physical devices (CPU, extended processors, memory, network interface cards, and disks) required by these four physical servers, as well as relevant information for these three network planes (including communication latency and bandwidth, etc.).

[0082] Then, the resource orchestration unit first collects the specifications of the idle physical devices of physical servers a.1 to n.6, the communication latency between these physical servers, and the communication bandwidth between these physical servers. Then, the resource orchestration unit can generate m candidate resource orchestration schemes from physical servers a.1 to n.6. Candidate resource orchestration scheme 1 includes physical servers a.1, a.2, b.1, and b.2; candidate resource orchestration scheme 2 includes physical servers c.3, c.4, d.5, and d.6; ..., candidate resource orchestration scheme m includes physical servers n-1.1, n-1.2, n.3, and n.4. It should be noted that all m candidate resource orchestration schemes meet the specifications of the physical devices required for physical servers 1.1, 1.2, 2.1, and 2.2 to create the logical nodes of the tenant, as well as the relevant information of network plane 1, network plane 2, and network plane 3 (for example, in candidate resource orchestration scheme 1, the specifications of the idle CPU, extended processor, memory, network card, and disk of physical servers a.1, a.2, b.1, and b.2 meet the specifications of the idle CPU, extended processor, memory, network card, and disk required by physical servers 1.1, 1.2, 2.1, and 2.2, respectively, and the communication latency and bandwidth between physical servers a.1, a.2, b.1, and b.2 meet the communication latency and bandwidth required by network plane 1, network plane 2, and network plane 3, etc.).

[0083] Then, the resource orchestration unit can obtain the evaluation values ​​of these m candidate resource orchestration schemes, that is, the cost required to generate the logical nodes of the tenant based on these m candidate resource orchestration schemes respectively. Suppose that the evaluation value of candidate resource orchestration scheme 1 is the lowest, that is, the cost required to generate the logical nodes of the tenant based on candidate resource orchestration scheme 1 including physical server a.1, physical server a.2, physical server b.1 and physical server b.2 is the lowest. Therefore, the resource orchestration unit can notify the resource scheduling unit to execute candidate resource orchestration scheme 1 (i.e. the final resource orchestration scheme). The resource scheduling unit can provide candidate resource orchestration scheme 1 to the pooled resource management module.

[0084] After receiving candidate resource orchestration scheme 1, the pooled resource management module can notify the device controller to separate physical servers a.1 and a.2 from supernode A to achieve physical server isolation, and separate physical servers b.1 and b.2 from supernode B to achieve physical server isolation. It also notifies the network controller to configure the sub-network of the high-speed interconnection network formed between physical servers a.1, a.2, b.1, and b.2, thereby making the sub-network include network plane 1 (physical server a.1 is the source physical server and physical server a.2 is the destination physical server), network plane 2 (physical server b.1 is the source physical server and physical server b.2 is the destination physical server), and network plane 3 (physical server a.1 is the source physical server and physical server b.2 is the destination physical server). In this way, physical servers a.1, a.2, b.1, and b.2 can serve as physical servers 1.1, 1.2, 2.1, and 2.2, forming the logical nodes required by the tenant.

[0085] It is worth noting that this logical node includes a virtual CPU, a virtual extended processor, virtual memory, a virtual network interface card (NIC), a virtual disk, and a virtual bus network. Specifically, the virtual CPU is implemented based on the CPUs contained in physical servers a.1, a.2, b.1, and b.2; the virtual extended processor is implemented based on the extended processors contained in physical servers a.1, a.2, b.1, and b.2; the virtual memory is implemented based on the memory contained in physical servers a.1, a.2, b.1, and b.2; the virtual NIC is implemented based on the NICs contained in physical servers a.1, a.2, b.1, and b.2; the virtual disk is implemented based on the disks contained in physical servers a.1, a.2, b.1, and b.2; and the virtual bus network is implemented based on this sub-network.

[0086] 304. The cloud management platform determines the operating system image entered or selected by the tenant, notifies the logical node to install the operating system image, and the cloud management platform deploys and runs multiple subtasks on multiple virtual instances on the logical node with the operating system image installed, wherein each virtual instance deploys at least one subtask.

[0087] After creating the logical node, the cloud management platform can prompt the tenant to provide a self-defined operating system image or an operating system image selected by the tenant on the cloud management platform. The cloud management platform can then install the operating system image specified by the tenant on the logical node. The logical node with the operating system image installed can run multiple virtual instances to complete the multiple sub-tasks included in the job task, thereby meeting the tenant's job requirements.

[0088] It is worth noting that since the virtual bus network contained in this logical node includes multiple virtual network planes, after the cloud management platform installs the operating system image specified by the tenant on this logical node, it can set up multiple virtual instances running on this logical node in these multiple virtual network planes. Virtual instances in different virtual network planes are used to execute different types of subtasks in the multiple subtasks contained in the job task, and virtual instances in the same virtual network plane are used to execute the same type of subtask (these multiple virtual network planes include a first virtual network plane and a second virtual network plane, and the multiple virtual instances include a first virtual instance located in the first virtual network plane and a second virtual instance located in the second virtual network plane. The first virtual instance deploys the first type of subtask in these multiple subtasks, and the second virtual instance deploys the second type of subtask in these multiple subtasks).

[0089] Continuing with the example above, since the sub-network of this logical node includes network plane 1, network plane 2, and network plane 3, the virtual bus network of this logical node also includes corresponding virtual network plane 1, virtual network plane 2, and virtual network plane 3. After installing the operating system image specified by the tenant, this logical node can run VM1.1 (which uses the physical device of physical server a.1), VM1.2 (which uses the physical device of physical server a.2), VM2.1 (which uses the physical device of physical server b.1), and VM2.2 (which uses the physical device of physical server b.2). VM1.1 and VM1.2 are located in virtual network plane 1, and VM2... VM1.1 and VM2.2 are located in virtual network plane 2, while VM1.1, VM1.2, VM2.1, and VM2.2 are located in virtual network plane 3. Since the tenant's job task includes several subtasks of type 1, several subtasks of type 2, and several subtasks of type 3, the device controller can instruct VM1.1 and VM1.2 to execute several subtasks of type 1 through virtual network plane 1, instruct VM2.1 and VM2.2 to execute several subtasks of type 1 through virtual network plane 2, and instruct VM1.1, VM1.2, VM2.1, and VM2.2 to execute several subtasks of type 3 through virtual network plane 3, thereby completing the tenant's entire job task.

[0090] More specifically, the cloud management platform can also perform the following operations:

[0091] After the logical node is created, the cloud management platform can collect the communication behavior of the logical node (communication behavior between the physical devices used to create the logical node) and the resource utilization of the virtual devices contained in the logical node (which is equivalent to the resource utilization of the physical devices used to create the logical node) in real time. The resource utilization includes the utilization of the virtual CPU contained in the logical node (i.e., the CPU utilization used to create the logical node), the utilization of the virtual memory contained in the logical node (i.e., the memory utilization used to create the logical node), the utilization of the virtual network interface card contained in the logical node (i.e., the network interface card utilization used to create the logical node), the utilization of the virtual extended processor contained in the logical node (i.e., the extended processor utilization used to create the logical node), and the utilization of the virtual disk contained in the logical node (i.e., the disk utilization used to create the logical node).

[0092] Next, the cloud management platform can determine the target device to be replaced among the physical devices used to create the logical node based on the communication behavior and the resource utilization. The target device is a physical device mapped to one or any combination of the virtual CPU, virtual memory, virtual network card, virtual extended processor and virtual disk contained in the logical node. The target device is a part of the physical devices (CPU, memory, network card, extended processor and disk) used to create the logical node.

[0093] Then, the cloud management platform can select an idle device that can replace the target device from one or any combination of CPU device pools, memory device pools, network card device pools, virtual extended processor device pools, and disk device pools.

[0094] Subsequently, the cloud management platform can connect idle devices to the virtual bus network of the logical node, remove the target device from the virtual bus network of the logical node, and mark the target device's status as idle. Since this virtual bus network is implemented based on a sub-network of the high-speed interconnect network between the physical devices used to create the logical node, after the idle device replaces the target device among these physical devices, the network between the remaining physical devices (excluding the target device) and the idle device becomes another sub-network of the high-speed interconnect network. Therefore, the virtual bus network of the logical node is implemented based on this other sub-network.

[0095] As in the example above, as shown in Figure 5 (Figure 5 is another structural schematic diagram of the cloud service system provided in this application embodiment), after creating a tenant's logical node, the behavior awareness unit can obtain the resource utilization rates (e.g., CPU utilization, memory utilization, network card utilization, and other indicators of these physical servers) of physical servers a.1, physical server a.2, physical server b.1, and physical server b.2 used to create the logical node from the pooled resource management module, and obtain the communication behavior between physical servers a.1, physical server a.2, physical server b.1, and physical server b.2 from the network management module. For example, if there are many communications between physical server a.1 and physical server b.2, the behavior awareness unit can generate an adjustment scheme that includes physical servers a.1, physical server a.2, physical server a.3, and physical server b.1. Because, based on the resource utilization rates and communication behavior of each physical server, the behavior awareness unit believes that it is more appropriate to replace physical server b.2 with physical server a.3, thereby achieving better logical node performance.

[0096] The behavior awareness unit can then obtain the evaluation values ​​of the current plan and the adjustment plan, i.e., the performance exhibited when simulating the execution of the tenant's job tasks using the current plan and the adjustment plan. If the evaluation value of the adjustment plan is higher than that of the current plan, the behavior awareness unit can consider the adjustment plan feasible and send it to the resource orchestration unit. The resource orchestration unit can determine the feasibility of the adjustment plan (e.g., the cost required to execute the adjustment plan, etc.). After determining feasibility (e.g., the cost is less than a certain value), the resource orchestration unit can notify the resource scheduling unit to execute the adjustment plan, that is, replace physical server b.2 with physical server a.3.

[0097] Then, the resource scheduling unit can notify the pooled resource management module to execute the adjustment plan. The pooled resource management module can instruct the physical server controller to stop the sub-tasks executed by each physical server in the logical node. According to the adjustment plan, physical server a.3 replaces the position of physical server b.2 (that is, VM2.2 and its corresponding sub-tasks originally running on physical server b.2 are migrated to physical server a.3 to run. In other words, VM2.2 uses the physical device of physical server a.3 instead of the physical device of physical server b.2). This results in the adjusted logical node. The device controller then restores each physical server in the adjusted logical node to continue running its own VM to complete the corresponding sub-tasks, thereby completing the tenant's job task.

[0098] The adjusted logical node virtual bus network is implemented based on a sub-network of the high-speed interconnection network formed between physical servers a.1, a.2, b.1, and a.3.

[0099] More specifically, the cloud management platform can also perform the following operations:

[0100] The performance requirements for this job task may also include the billing model for the tenant for this logical node. Based on this, the billing model for this logical node may include the following:

[0101] (1) Billing Mode 1: Since the physical equipment required by the physical server has various specifications, corresponding prices can be pre-set for physical equipment of different specifications. Various types of physical equipment of different specifications can be combined to form various logical node products with packaged pricing. Different logical node products correspond to different pre-set prices. After determining the relevant information of the tenant's logical node, the cloud management platform determines the logical node product that matches the tenant's logical node from a variety of logical node products. The platform calculates the cost of the tenant's use of the logical node based on the price of the logical node product and the duration of use of the tenant's logical node set by the tenant, and returns the cost to the tenant so that the tenant can complete the payment for the logical node.

[0102] (2) Billing Mode 2: Since the cloud management platform can determine the specifications of the physical devices required to create the logical nodes of a tenant, these specifications include: the number of these physical devices and the step size of these physical devices (for example, the tenant sets the number of CPUs required to create a certain physical server of its logical node to be 2.5, and the step size of the CPU required by the physical server is 0.5, or the tenant sets the number of CPUs required to create a certain physical server of its logical node to be 3, and the step size of the CPU required by the physical server is 1). Based on this, the cloud management platform can determine a first price based on the number of these physical devices. When the number of these physical devices is within a normal range, the first price is the normal price; when the number of these physical devices is outside a normal range, the first price is the unconventional price. For example, if a tenant configures multiple physical servers required to create its logical nodes, requiring 90 CPUs but only 8GB of memory, the memory or CPU quantity is unconventional, and therefore the cloud management platform sets an unconventional price for this number of physical devices. Conversely, if a tenant configures multiple physical servers required to create its logical nodes, requiring 90 CPUs but only 100GB of memory, the memory or CPU quantity is normal, and therefore the cloud management platform sets a different price for this number of physical devices. The platform sets a standard price for each physical server and a second price based on the step size of the physical servers. The second price is set when the step size of the physical servers is within the standard range, and when the step size is outside the standard range. For example, if a tenant sets up multiple physical servers requiring 90.5 CPUs to create their logical node, the CPU step size is 0.5, which is outside the standard range. Therefore, the cloud management platform sets an outside price for these physical servers based on the step size. Conversely, if a tenant sets up multiple physical servers requiring 90 CPUs to create their logical node, the CPU step size is standard, and the cloud management platform sets a standard price for these physical servers based on the step size.

[0103] In addition, the cloud management platform can determine the third price based on the evaluation value of the final combination scheme (i.e. the aforementioned first combination scheme or second combination scheme), that is, the cost required to execute the combination scheme. The first price, the second price, and the third price are superimposed, and the superimposed price is used in conjunction with the duration of use of the logical node set by the tenant to calculate the cost required for the tenant to use the logical node. This cost is then returned to the tenant so that the tenant can complete the payment for the logical node.

[0104] (3) Billing Mode 3: Based on the aforementioned billing mode 2, since the cloud management platform can detect that the tenant's logical nodes need to be adjusted at the tenant's request or through its own detection function, after determining the aforementioned adjustment plan, the cloud management platform can determine the fourth price based on the cost required to execute the adjustment plan, and then add the first price, the second price, the third price and the fourth price together, and then use the added price and the duration of use of the logical nodes set by the tenant to calculate the final cost required for the tenant to use the logical nodes, and return it to the tenant so that the tenant can complete the payment for the logical nodes, etc.

[0105] In this embodiment, when a tenant needs to process a job task, the tenant can send a job task processing request to the task processing interface provided by the cloud management platform. Since the job task processing request indicates information about the job task to be processed (including the model, data, and performance requirements of the job task, etc.), the cloud management platform can, based on this information, split the job task into multiple sub-tasks and generate a resource orchestration scheme for these sub-tasks. This resource orchestration scheme includes resources selected by the cloud management platform from multiple physical device pools (CPU device pool, extended processor device pool, memory device pool, network interface card device pool, and disk device pool). The selected physical devices (CPU, extended processors, memory, network interface cards, and disks) meet the aforementioned performance requirements. Therefore, the cloud management platform can create logical nodes for tenants on these physical devices. Each logical node contains virtual devices (virtual CPU, virtual extended processors, virtual memory, virtual network interface cards, and virtual disks) implemented based on these physical devices. The cloud management platform can then install the tenant-specified operating system image on this logical node, enabling it to run multiple virtual instances and execute various subtasks to meet the tenant's job requirements. In this process, since the multiple physical devices used to construct the logical node can be selected according to the performance requirements of the tenant's job tasks, and these devices can have different specifications, the resource specifications occupied by the logical node created based on these physical devices can be understood as being set by the tenant according to their own needs. That is, the performance of the logical node is set according to the tenant's own requirements. Because the logical node has sufficient performance, the tenant can use it to complete various job tasks, thereby meeting the increasingly complex business needs of the tenant and improving the user experience.

[0106] Furthermore, in this embodiment, when a tenant needs to adjust its logical node, since the logical node can be built across multiple supernodes, and the specifications of the physical devices of the physical server used by the logical node are combined, the specifications of the resources occupied by the logical node can be understood as adjustable. Therefore, the cloud management platform can adjust the internal structure of the tenant's logical node (for example, by replacing the original physical server with a new one) so that the adjusted logical node has better performance, thereby providing the tenant with better services and further improving the tenant experience.

[0107] The above is a detailed description of the cloud service-based job task processing method provided in the embodiments of this application. The following will introduce the cloud management platform provided in the embodiments of this application. Figure 6 is a structural schematic diagram of the cloud management platform provided in the embodiments of this application. As shown in Figure 6, the cloud management platform is used to manage infrastructure, which includes a CPU device pool, a memory device pool, a network interface card (NIC) device pool, an extended processor device pool, and a disk device pool. Multiple CPUs in the CPU device pool, multiple memory modules in the memory device pool, multiple NICs in the NIC device pool, multiple extended processors in the extended processor device pool, and multiple disks in the disk device pool are all connected to a high-speed interconnect network. The cloud management platform includes:

[0108] The acquisition module 601 is used to acquire the job task processing request input by the tenant. The job task processing request is used to specify the model, data and performance requirements required for the job task. For example, the acquisition module 601 can be used to execute step 301 in the embodiment shown in FIG3.

[0109] The splitting module 602 is used to split a job task into multiple subtasks in response to a job task processing request and generate a resource orchestration scheme for the multiple subtasks; for example, the splitting module 602 can be used to execute step 302 in the embodiment shown in FIG3.

[0110] Creation module 603 is used to create logical nodes according to a resource orchestration scheme. These logical nodes include virtual CPUs, virtual memory, virtual network interface cards (NICs), virtual extended processors, virtual disks, and a virtual bus network. The virtual CPUs, virtual memory, virtual NICs, virtual extended processors, and virtual disks are logically connected to the virtual bus. The virtual CPU is implemented using at least one CPU from the CPU device pool that meets performance requirements and is idle. The virtual memory is implemented using at least one memory from the memory device pool that meets performance requirements and is idle. The virtual NIC is implemented using at least one NIC from the NIC device pool that meets performance requirements and is idle. The virtual extended processor is implemented using at least one extended processor from the extended processor device pool that meets performance requirements and is idle. The virtual disk is implemented using at least one disk from the disk device pool that meets performance requirements and is idle. The virtual bus network is implemented using a sub-network of a high-speed interconnect network. For example, creation module 603 can be used to execute step 303 in the embodiment shown in Figure 3.

[0111] Processing module 604 is used to determine the operating system image input or selected by the tenant, notify the logical node to install the operating system image, and deploy and run multiple subtasks in multiple virtual instances on the logical node with the operating system image installed, wherein each virtual instance deploys at least one subtask. For example, processing module 604 can be used to execute step 304 in the embodiment shown in FIG3.

[0112] In one possible implementation, the splitting module 602 is used to: generate multiple candidate resource orchestration schemes for multiple subtasks; evaluate the multiple candidate resource orchestration schemes to obtain evaluation values ​​for the multiple candidate resource orchestration schemes, the evaluation values ​​of the multiple candidate resource orchestration schemes being used to indicate the cost required to create logical nodes based on the multiple candidate resource orchestration schemes; and determine the candidate resource orchestration scheme with the smallest evaluation value from the multiple candidate resource orchestration schemes as the resource orchestration scheme for the multiple subtasks.

[0113] In one possible implementation, the cloud management platform further includes: a collection module for acquiring the communication behavior and resource utilization of logical nodes, including the utilization of virtual CPUs, virtual memory, virtual network interface cards (NICs), virtual extended processors (VEPs), and virtual disks; a determination module for determining, based on the communication behavior and resource utilization, a target device to be replaced in the logical node, wherein the target device is a device mapped from one or any combination of virtual CPUs, virtual memory, virtual NICs, VEPs, and virtual disks; a selection module for selecting an idle device that can replace the target device from one or any combination of CPU device pools, memory device pools, NIC device pools, VEPs device pools, and disk device pools; and an access module for connecting the idle device to the virtual bus network, removing the target device from the virtual bus network, and marking the target device's status as idle.

[0114] In one possible implementation, the virtual bus network includes a first virtual network plane and a second virtual network plane. The first virtual network plane includes a first virtual instance among a plurality of virtual instances, and the second virtual network plane includes a second virtual instance among a plurality of virtual instances. The first virtual instance deploys a first type of subtask among a plurality of subtasks, and the second virtual instance deploys a second type of subtask among a plurality of subtasks.

[0115] In one possible implementation, the extended processor type of the extended processor device pool is one or any combination of NPU, GPU, TPU, and DPU.

[0116] In one possible implementation, high-speed interconnect networks are achieved through PCIe networks, IB networks, or CXL networks.

[0117] It should be noted that the information interaction and implementation process between the modules / units of the above-mentioned device are based on the same concept as the method embodiments of this application, and the resulting technical effects are the same as those of the method embodiments of this application. For details, please refer to the description in the method embodiments shown above in the embodiments of this application, and will not be repeated here.

[0118] Please refer to Figure 7, which is a schematic diagram of a computing device provided in an embodiment of this application. As shown in Figure 7, the computing device 700 (which can be used to present the aforementioned cloud management platform) includes: a processor 701, a memory 702, a communication interface 703, and a bus 704. The processor 701, the memory 702, and the communication interface 703 are coupled through the bus (not labeled in the figure). The memory 702 stores instructions. When the execution instructions in the memory 702 are executed, the computing device 700 executes the method performed by the cloud management platform in the above method embodiment.

[0119] The computing device 700 may be one or more integrated circuits configured to implement the methods described above, such as: one or more application-specific integrated circuits (ASICs), or one or more digital signal processors (DSPs), or one or more field-programmable gate arrays (FPGAs), or a combination of at least two of these forms of integrated circuits. Furthermore, when the units in the device can be implemented in the form of a processing element scheduler, the processing element may be a general-purpose processor, such as a central processing unit (CPU) or other processor capable of calling programs. Alternatively, these units may be integrated together and implemented as a system-on-a-chip (SOC).

[0120] The processor 701 can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. A general-purpose processor can be a microprocessor or any conventional processor.

[0121] The memory 702 can be volatile memory or non-volatile memory, or it can include both. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM).

[0122] The memory 702 stores executable program code, and the processor 701 executes this executable program code to implement the functions of the aforementioned acquisition module, splitting module, creation module, and processing module, thereby realizing the aforementioned cloud service-based job task processing method. That is, the memory 702 stores instructions for executing the aforementioned cloud service-based job task processing method.

[0123] The communication interface 703 uses transceiver modules, such as, but not limited to, network interface cards and transceivers, to enable communication between the computing device 700 and other devices or communication networks.

[0124] In addition to the data bus, the 704 bus can also include a power bus, a control bus, and a status signal bus. The bus can be a Peripheral Component Interconnect Express (PCIe) bus, an Extended Industry Standard Architecture (EISA) bus, a Unified Bus (Ubus or UB), a Compute Express Link (CXL) bus, a Cache Coherent Interconnect for Accelerators (CCIX) bus, etc. The bus can be divided into address bus, data bus, and control bus.

[0125] Please refer to Figure 8, which is a schematic diagram of a computing device cluster provided in an embodiment of this application. As shown in Figure 8, the computing device cluster 800 includes at least one computing device 700.

[0126] As shown in Figure 8, the computing device cluster 800 includes at least one computing device 700. The memory 702 of one or more computing devices 700 in the computing device cluster 800 may store the same instructions for executing the above-described cloud service-based job task processing method.

[0127] In some possible implementations, the memory 702 of one or more computing devices 700 in the computing device cluster 800 may also store partial instructions for executing the aforementioned cloud service-based job task processing method. In other words, a combination of one or more computing devices 700 can jointly execute the aforementioned cloud service-based job task processing method.

[0128] It should be noted that the memory 702 in different computing devices 700 within the computing device cluster 800 can store different instructions, each used to execute a portion of the functions of the aforementioned cloud management platform. That is, the instructions stored in the memory 702 of different computing devices 700 can implement the functions of one or more modules, such as the acquisition module, the splitting module, the creation module, and the processing module.

[0129] In some possible implementations, one or more computing devices 700 in the computing device cluster 800 can be connected via a network. This network can be a wide area network (WAN) or a local area network (LAN), etc.

[0130] Please refer to Figure 9, which is a schematic diagram of computer devices in a computer cluster provided in an embodiment of this application being connected via a network. As shown in Figure 9, two computing devices 700A and 700B are connected via a network. Specifically, they are connected to the network through the communication interfaces in each computing device.

[0131] In one possible implementation, the memory in computing device 700A stores instructions for executing the functions of modules such as the acquisition module. Meanwhile, the memory in computing device 700B stores instructions for executing the functions of modules such as the splitting module, the creation module, and the processing module.

[0132] It should be understood that the functions of computing device 700A shown in Figure 9 can also be performed by multiple computing devices. Similarly, the functions of computing device 700B can also be performed by multiple computing devices.

[0133] This application also relates to a computer storage medium storing a program for signal processing, which, when run on a computer, causes the computer to perform the steps executed by the cloud management platform in the embodiment shown in FIG3.

[0134] This application also relates to a computer program product that stores instructions that, when executed by a computer, cause the computer to perform the steps performed by the cloud management platform in the embodiment shown in FIG3.

[0135] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0136] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.

[0137] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0138] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0139] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A job task processing method based on cloud services, characterized in that, The method is applied to a cloud management platform, which manages infrastructure including a CPU device pool, a memory device pool, a network interface card (NIC) device pool, an extended processor device pool, and a disk device pool. Multiple CPUs in the CPU device pool, multiple memory modules in the memory device pool, multiple NICs in the NIC device pool, multiple extended processors in the extended processor device pool, and multiple disks in the disk device pool are all connected to a high-speed interconnect network. The method includes: The cloud management platform obtains the job task processing request input by the tenant. The job task processing request is used to specify the model, data, and performance requirements of the job task. The cloud management platform responds to the job processing request by splitting the job into multiple sub-tasks and generating a resource orchestration scheme for the multiple sub-tasks; The cloud management platform creates logical nodes according to the resource orchestration scheme. Each logical node includes a virtual CPU, virtual memory, virtual network interface card (NIC), virtual extended processor, virtual disk, and virtual bus network. The virtual CPU, virtual memory, virtual NIC, virtual extended processor, and virtual disk are logically connected to the virtual bus. The virtual CPU is implemented using at least one idle CPU from the CPU device pool that meets the performance requirements. The virtual memory is implemented using at least one idle memory from the memory device pool that meets the performance requirements. The virtual NIC is implemented using at least one idle NIC from the NIC device pool that meets the performance requirements. The virtual extended processor is implemented using at least one idle extended processor from the extended processor device pool that meets the performance requirements. The virtual disk is implemented using at least one idle disk from the disk device pool that meets the performance requirements. The virtual bus network is implemented through a sub-network of the high-speed interconnect network. The cloud management platform determines the operating system image entered or selected by the tenant; The cloud management platform notifies the logical node to install the operating system image; The cloud management platform deploys and runs the multiple subtasks in multiple virtual instances on the logical node that has the operating system image installed, with each virtual instance having at least one subtask deployed.

2. The method according to claim 1, characterized in that, The cloud management platform generates resource orchestration schemes for the multiple sub-tasks, including: The cloud management platform generates multiple candidate resource orchestration schemes for the multiple sub-tasks; The cloud management platform evaluates the multiple candidate resource orchestration schemes to obtain evaluation values ​​for the multiple candidate resource orchestration schemes. The evaluation values ​​of the multiple candidate resource orchestration schemes are used to indicate the cost required to create logical nodes based on the multiple candidate resource orchestration schemes. The cloud management platform selects the candidate resource orchestration scheme with the lowest evaluation value from the multiple candidate resource orchestration schemes as the resource orchestration scheme for the multiple sub-tasks.

3. The method according to claim 1 or 2, characterized in that, The method further includes: The cloud management platform acquires the communication behavior of the logical node and the resource utilization of the logical node. The resource utilization includes the utilization of the virtual CPU, the virtual memory, the virtual network card, the virtual extended processor, and the virtual disk. Based on the communication behavior and resource utilization, the cloud management platform determines the target device to be replaced in the logical node. The target device is a device mapped from one or any combination of the virtual CPU, the virtual memory, the virtual network card, the virtual extended processor, and the virtual disk. The cloud management platform selects an idle device that can replace the target device from one or any combination of the CPU device pool, the memory device pool, the network card device pool, the virtual extended processor device pool, and the disk device pool. The cloud management platform connects the idle device to the virtual bus network, removes the target device from the virtual bus network, and marks the target device as idle.

4. The method according to any one of claims 1 to 3, characterized in that, The virtual bus network includes a first virtual network plane and a second virtual network plane. The first virtual network plane includes a first virtual instance among the plurality of virtual instances, and the second virtual network plane includes a second virtual instance among the plurality of virtual instances. The first virtual instance deploys a first type of subtask among the plurality of subtasks, and the second virtual instance deploys a second type of subtask among the plurality of subtasks.

5. The method according to any one of claims 1 to 4, characterized in that, The extended processor device pool includes one or any combination of NPU, GPU, TPU, and DPU.

6. The method according to any one of claims 1 to 5, characterized in that, The high-speed interconnect network is implemented through PCIE network, IB network, or CXL network.

7. A cloud management platform, characterized in that, The cloud management platform is used to manage infrastructure, which includes a CPU device pool, a memory device pool, a network interface card (NIC) device pool, an extended processor device pool, and a disk device pool. Multiple CPUs in the CPU device pool, multiple memory modules in the memory device pool, multiple NICs in the NIC device pool, multiple extended processors in the extended processor device pool, and multiple disks in the disk device pool are all connected to a high-speed interconnect network. The cloud management platform includes: The acquisition module is used to acquire the job task processing request input by the tenant. The job task processing request is used to specify the model, data, and performance requirements of the job task. The splitting module is used to split the job task into multiple sub-tasks in response to the job task processing request, and generate a resource orchestration scheme for the multiple sub-tasks. A creation module is used to create logical nodes according to the resource orchestration scheme. The logical nodes include virtual CPUs, virtual memory, virtual network interface cards (NICs), virtual extended processors, virtual disks, and a virtual bus network. The virtual CPUs, virtual memory, virtual NICs, virtual extended processors, and virtual disks are logically connected to the virtual bus. The virtual CPU is implemented using at least one idle CPU from the CPU device pool that meets the performance requirements. The virtual memory is implemented using at least one idle memory from the memory device pool that meets the performance requirements. The virtual NIC is implemented using at least one idle NIC from the NIC device pool that meets the performance requirements. The virtual extended processor is implemented using at least one idle extended processor from the extended processor device pool that meets the performance requirements. The virtual disk is implemented using at least one idle disk from the disk device pool that meets the performance requirements. The virtual bus network is implemented through a sub-network of the high-speed interconnect network. The processing module is used to determine the operating system image input or selected by the tenant, notify the logical node to install the operating system image, and deploy and run the multiple subtasks in multiple virtual instances on the logical node with the operating system image installed, wherein each virtual instance has at least one subtask deployed.

8. The cloud management platform according to claim 7, characterized in that, The splitting module is used for: Generate multiple candidate resource orchestration schemes for the multiple sub-tasks; The multiple candidate resource orchestration schemes are evaluated to obtain evaluation values ​​for the multiple candidate resource orchestration schemes. The evaluation values ​​of the multiple candidate resource orchestration schemes are used to indicate the cost required to create logical nodes based on the multiple candidate resource orchestration schemes. From the multiple candidate resource orchestration schemes, the candidate resource orchestration scheme with the smallest evaluation value is determined as the resource orchestration scheme for the multiple sub-tasks.

9. The cloud management platform according to claim 7 or 8, characterized in that, The cloud management platform also includes: The acquisition module is used to acquire the communication behavior of the logical node and the resource utilization of the logical node, wherein the resource utilization includes the utilization of the virtual CPU, the utilization of the virtual memory, the utilization of the virtual network card, the utilization of the virtual extended processor, and the utilization of the virtual disk. The determination module is used to determine the target device to be replaced in the logical node based on the communication behavior and resource utilization. The target device is a device mapped from one or any combination of the virtual CPU, the virtual memory, the virtual network card, the virtual extended processor, and the virtual disk. The selection module is used to select an idle device that can replace the target device from one or any combination of the CPU device pool, the memory device pool, the network card device pool, the virtual extended processor device pool, and the disk device pool. The access module is used to connect the idle device to the virtual bus network, disconnect the target device from the virtual bus network, and mark the status of the target device as idle.

10. The cloud management platform according to any one of claims 7 to 9, characterized in that, The virtual bus network includes a first virtual network plane and a second virtual network plane. The first virtual network plane includes a first virtual instance among the plurality of virtual instances, and the second virtual network plane includes a second virtual instance among the plurality of virtual instances. The first virtual instance deploys a first type of subtask among the plurality of subtasks, and the second virtual instance deploys a second type of subtask among the plurality of subtasks.

11. The cloud management platform according to any one of claims 7 to 10, characterized in that, The extended processor device pool includes one or any combination of NPU, GPU, TPU, and DPU.

12. The cloud management platform according to any one of claims 7 to 11, characterized in that, The high-speed interconnect network is implemented through PCIE network, IB network, or CXL network.

13. A computing device cluster, characterized in that, The computing device cluster includes at least one computing device, each computing device including a processor and memory: The memory is used to store instructions; The processor is configured to, according to the instructions, cause the computing device cluster to perform the method of any one of claims 1 to 6.

14. A computer storage medium, characterized in that, The computer storage medium stores one or more instructions that, when executed by one or more computers, cause the one or more computers to perform the method of any one of claims 1 to 6.

15. A computer program product, characterized in that, The computer program product stores instructions that, when executed by a computer, cause the computer to perform the method described in any one of claims 1 to 6.

Images