Scheduling systems and methods

Abstract

This application discloses a scheduling system and method, comprising: an application intent perception and modeling layer, a global resource profiling and abstraction layer, a multi-level intelligent scheduling decision layer, and a resource supply and lifecycle management layer. The application intent perception and modeling layer parses application requirement templates to obtain an application profile, which includes: the components included in the application, the application's resource requirements, and the application's strategy requirements. The global resource profiling and abstraction layer collects resource information from different types of resource pools and generates a global resource profile based on this information. The multi-level intelligent scheduling decision layer determines target resource pools for components based on the application profile and the global resource profile. The resource supply and lifecycle management layer deploys the target resources for the application. This solves the problem in related technologies where unified intelligent scheduling across different types of resource pools, centered on the application, is not possible.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a scheduling system and method. Background Technology

[0002] As enterprises deepen their digital transformation, private and hybrid cloud environments have become core infrastructure supporting business innovation. Modern data centers commonly feature diverse heterogeneous computing resources, including traditional virtualization resources, cloud-native containerized resources, high-performance bare-metal servers, and heterogeneous computing accelerators such as Graphics Processing Units (GPUs). However, existing cloud management platforms, when faced with this heterogeneous trend, exhibit problems such as management silos, weak application awareness, and static scheduling strategies. Different resource pools possess their own independent management interfaces, data models, and operational semantics, forming information silos and hindering unified resource assessment and global scheduling decisions. Traditional platforms lack the ability to finely perceive the topological relationships of application components, multi-dimensional Service-Level Agreement (SLA) requirements, and data compliance strategies. Resource allocation is based on a coarse-grained decision-making process using capacity, making it difficult to accurately match application needs with infrastructure supply. Existing technologies cannot achieve unified intelligent scheduling across different types of resource pools, centered on the application.

[0003] There is currently no effective solution to the above problems. Summary of the Invention

[0004] This application provides a scheduling system and method to at least solve the problem in related technologies that it is impossible to perform unified intelligent scheduling across different types of resource pools with an application-centric approach.

[0005] This application provides a scheduling system, comprising: an application intent perception and modeling layer, a global resource profiling and abstraction layer, a multi-level intelligent scheduling decision layer, and a resource supply and lifecycle management layer. The application intent perception and modeling layer is used to parse application requirement templates to obtain an application profile, which includes: the components included in the application, the resource requirements of the application, and the policy requirements of the application. The global resource profiling and abstraction layer is used to collect resource information from different types of resource pools and generate a global resource profile based on the resource information. The multi-level intelligent scheduling decision layer is used to determine the target resource pool for the components based on the application profile and the global resource profile. The resource supply and lifecycle management layer is used to deploy the target resources for the application.

[0006] In an exemplary embodiment, the application intent perception and modeling layer includes: a first conversion module, configured to convert the application's requirements into an application requirement template, wherein the application requirement template includes the application's components, the application's resource requirements, and the application's strategy requirements, and the application requirement template is a text file obtained based on a markup language; and an intent parsing engine, configured to parse the application requirement template and convert it into an application profile, wherein the application profile is a data object that can be directly used by the global scheduler.

[0007] In one exemplary embodiment, the resource requirements of the application include at least one of the following: computing resources, storage resources, network resources, and hardware resources; the policy requirements include at least one of the following: quality of service level, topology relationship between components, data sovereignty, and cost and power consumption budget.

[0008] In an exemplary embodiment, the global resource profiling and abstraction layer includes a resource information collector, which communicates with a resource pool of a corresponding type via an adapter to obtain resource information from the resource pool.

[0009] In one exemplary embodiment, the adapter includes at least one of the following: a virtualization platform adapter, a container orchestration system adapter, a bare metal management adapter, and a hardware adapter.

[0010] In one exemplary embodiment, the resource information collector communicates with a resource pool of a corresponding type via an adapter to obtain resource information in the resource pool, including: the resource information collector communicating with the resource pool of a corresponding type via the adapter according to a preset period to obtain resource information in the resource pool; or, the resource information collector communicating with the resource pool of a corresponding type via the adapter according to a subscription event to obtain resource information in the resource pool.

[0011] In an exemplary embodiment, the global resource profiling and abstraction layer further includes: a second conversion module, configured to convert the resource information obtained from the resource pool into a unified resource model object, wherein the unified resource model object includes static attributes and dynamic attributes, the rate of change of resource information having the static attributes is less than or equal to a first rate of change threshold, and the rate of change of resource information having the dynamic attributes is greater than or equal to a second rate of change threshold.

[0012] In an exemplary embodiment, the global resource profile and abstraction layer further includes: a global resource profile database for storing the unified resource model object and generating the global resource profile based on the unified resource model object, wherein the global resource profile database includes an in-memory database and a time-series database, the in-memory database for storing the current snapshot of the unified resource model object, and the time-series database for storing historical data of resource information with the dynamic attributes.

[0013] In an exemplary embodiment, the multi-level intelligent scheduling decision layer includes: a global scheduler, configured to receive the application profile and filter and query the global resource profile based on the hard requirements in the application profile to obtain a candidate resource pool list, wherein the resource requirements and / or the policy requirements include the hard requirements, and the candidate resource pool list includes at least one candidate resource pool; and a resource pool scheduler, configured to receive the application profile and the candidate resource pool list, and determine the target resource pool in the candidate resource pool list based on the application profile and a scheduling policy library.

[0014] In one exemplary embodiment, the scheduling policy library includes at least one of the following policies: affinity / anti-affinity policy, binning policy, distributed policy, cost-first policy, quality of service-first policy, and power-first policy.

[0015] In an exemplary embodiment, the affinity / anti-affinity strategy is used to query topology information in the global resource profile and deploy related components on corresponding servers based on the topology information, wherein the target resource pool includes the servers; the binning strategy is used to deploy new loads to target servers, wherein the target servers already have workloads deployed and resource utilization is less than or equal to a preset threshold, wherein the target resource pool includes the target servers; the distribution strategy is used to deploy different instances of the same application in different fault domains, wherein the fault domains include: physical hosts, racks, and power lines; the cost-priority strategy is used to select the lowest-cost resource based on resource cost information in the global resource profile; and the power-priority strategy is used to select the lowest-power resource based on power consumption data in the global resource profile.

[0016] In an exemplary embodiment, the resource supply and lifecycle management layer includes: a unified resource adapter, configured to call a corresponding script file according to the type of resources in the target resource pool, wherein the script file is used to deploy the resources; and a resource deployment and configuration module, configured to deploy the target resource pool for the application and send a confirmation message to the global resource profile after deployment.

[0017] In an exemplary embodiment, the resource supply and lifecycle management layer includes a status monitoring and recycling module, which includes a fault self-healing unit, configured to trigger a scheduling request to request an update of the application deployment server when a fault is detected in the server where the application is deployed; and a resource recycling unit, configured to release the target resource pool when preset conditions are met, wherein the preset conditions include: deleting the application, or the end of the application's lifecycle.

[0018] In an exemplary embodiment, the status monitoring and recycling module further includes a profile update unit, which is used to update the status of the target resource pool in the global resource profile from an occupied state to an available state after the target resource pool is released.

[0019] This application provides a scheduling method applied to the aforementioned scheduling system, comprising: parsing an application requirement template to obtain an application profile, wherein the application profile includes: components included in the application, resource requirements of the application, and policy requirements of the application; collecting resource information from different types of resource pools and generating a global resource profile through the resource information; determining a target resource pool for the component based on the application profile and the global resource profile; and deploying the target resources for the application.

[0020] In an exemplary embodiment, before parsing the application requirement template, the method further includes: converting the application's requirements into the application requirement template, wherein the application requirement template includes the application's components, the application's resource requirements, and the application's strategy requirements, and the application requirement template is a text file obtained based on a markup language; parsing the application requirement template to convert it into the application profile, wherein the application profile is a data object that can be directly used by the global scheduler.

[0021] In an exemplary embodiment, before parsing the application requirement template, the method further includes: filtering and querying the global resource profile based on the hard requirements in the application profile to obtain a candidate resource pool list, wherein the resource requirements and / or the policy requirements include the hard requirements, and the candidate resource pool list includes at least one candidate resource pool; and determining the target resource pool based on the application profile and the scheduling policy library in the candidate resource pool list.

[0022] This application provides a server management system that employs a four-layer architecture: an application intent perception and modeling layer, a global resource profiling and abstraction layer, a multi-level intelligent scheduling decision layer, and a resource supply and lifecycle management layer. The application intent perception and modeling layer parses application requirement templates into application profiles containing component, resource, and policy requirements. The global resource profiling and abstraction layer collects information from different types of resource pools and generates a global resource profile. The multi-level intelligent scheduling decision layer accurately matches target resource pools to components based on the application profiles and global resource profiles. Finally, the resource supply and lifecycle management layer deploys the target resources to the application, achieving unified intelligent scheduling across different types of resource pools, centered on the application. Therefore, it solves the problem in related technologies that cannot achieve unified intelligent scheduling across different types of resource pools, centered on the application. Attached Figure Description

[0023] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 A schematic diagram of a scheduling system architecture provided in an embodiment of this application;

[0025] Figure 2 A schematic diagram of the overall architecture of the scheduling system provided in the embodiments of this application;

[0026] Figure 3 A flowchart of the scheduling method provided in the embodiments of this application. Detailed Implementation

[0027] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0028] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0029] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0030] The keywords are explained below:

[0031] Central Processing Unit (CPU)

[0032] Graphics Processing Unit (GPU)

[0033] Service-Level Agreement (SLA)

[0034] Application Programming Interface, or API for short.

[0035] The Unified Resource Model (URM) is a set of technologies used to develop and improve resource utilization.

[0036] Input / output operations per second, or IOPS for short.

[0037] Kernel-based Virtual Machine, or KVM for short.

[0038] Intelligent Platform Management Interface (IPMI) is a type of interface that provides intelligent platform management interfaces.

[0039] YAML (Yin't Markup Language) is a data serialization format.

[0040] Virtual Local Area Network, or VLAN for short.

[0041] This application provides a scheduling system, such as Figure 1The system architecture diagram shown includes: an application intent perception and modeling layer, a global resource profiling and abstraction layer, a multi-level intelligent scheduling decision layer, and a resource supply and lifecycle management layer. The application intent perception and modeling layer parses application requirement templates to obtain an application profile, which includes: the components included in the application, the application's resource requirements, and the application's strategy requirements. The global resource profiling and abstraction layer collects resource information from different types of resource pools and generates a global resource profile based on this information. The multi-level intelligent scheduling decision layer determines the target resource pool for the components based on the application profile and the global resource profile. The resource supply and lifecycle management layer deploys the target resources for the application.

[0042] The application intent awareness and modeling layer receives an application requirement template, which describes the components included in the application, the computing and / or storage resources required by the application, and the strategies that the application should follow at runtime, such as whether components should be deployed close to each other or separately.

[0043] An application profile is a structured description formed after parsing an application requirement template. It contains key information about the application, such as its components (which can be one or more), the type and quantity of resources required for each component, and runtime policy constraints. For example, in a video analytics application, the application profile might record that the application contains three components: the analytics component requires a hardware accelerator, the storage component requires a high-performance I / O storage device, and a low-latency network connection is needed between the analytics and caching components.

[0044] A component is an independent deployment unit that makes up an application. An application can consist of multiple components, each responsible for performing a specific business function, and can be deployed, scaled, and recycled independently. For example, in a video analytics application, the data access and caching component is responsible for receiving video streams, the analysis component is responsible for model inference, and the storage component is responsible for saving the results. These three components work together to complete the entire application functionality.

[0045] Resource requirements refer to the infrastructure capabilities necessary for a component to operate. These requirements include, but are not limited to, the number of processor cores, memory capacity, storage space size and performance level, network bandwidth and latency requirements, and the type and number of specific hardware accelerators. For example, in video analytics applications, the resource requirements of the analytics component include a certain number of processor cores, a large amount of memory, and specific types of hardware accelerators for model inference.

[0046] Strategic requirements are the strategies that components should follow during deployment and operation. These requirements include proximity or distance between components, service reliability levels, geographical constraints on data storage, and upper limits on operating costs or energy consumption. For example, in video analytics applications, strategic requirements might necessitate deploying analytics and caching components in network proximity to reduce latency, while also requiring two copies of the database to be deployed on different physical hosts to prevent single points of failure.

[0047] The global resource profiling and abstraction layer connects different types of resource pools through adapters, collects static configuration information and dynamic operating status of various resources, and converts this heterogeneous information into a standardized format to form a global view covering all resources. For example, in a data center containing virtual machine clusters, container clusters, and physical server clusters, this layer collects information such as server processor utilization, remaining memory, network traffic, and hardware health status from each resource pool and stores it uniformly.

[0048] Resource information can be data describing the current state and inherent attributes of a resource. Resource information includes static and dynamic data such as hardware configuration, topology location, remaining capacity, current load, health status, and power consumption. For example, before deploying a video analytics application, the system needs to obtain information such as the physical server's processor utilization, available memory size, hardware accelerator's video memory usage, and the server's rack location.

[0049] A resource pool is a collection of resources with management attributes and technical types. A resource pool can be a cluster of virtual machines managed by the same virtualization platform, a cluster of container nodes managed by a container orchestration platform, or a collection of physical servers controlled through an out-of-band management interface. For example, in video analytics applications, there might be a physical server resource pool containing hardware accelerators, a general-purpose virtual machine resource pool, and a container resource pool.

[0050] A global resource profile is a dataset that provides a unified description of all available resources. Specifically, it standardizes and aggregates various resources from different resource pools, including complete information such as each resource's unique identifier, type, capacity, load, topology location, and health status, and supports real-time querying and updates. For example, in video analytics application scheduling, a global resource profile can answer questions such as which physical servers currently have idle hardware accelerators, which servers have the lowest network latency, and which storage devices can meet high I / O performance requirements.

[0051] The multi-level intelligent scheduling decision layer first filters candidate resource pools from global resources based on the application's hard constraints. Then, within the candidate pool, it selects specific deployment targets for each component based on more granular strategies and the real-time status of the resources. For example, in a video analytics application, this layer first filters a resource pool containing hardware accelerators. Then, within this pool, it selects physical servers with moderate load and high energy efficiency for the analytics components, while simultaneously selecting locations on the network adjacent to the analytics components for the caching components.

[0052] A target resource pool is a specific resource pool determined through scheduling decisions to provide resources for application components. It is one or more candidate pools selected from all global resource pools that meet the application's hard constraints; subsequent fine-grained scheduling will be performed within these pools. For example, in a video analytics application, because the analytics components require hardware accelerators, and only the physical server resource pool possesses this capability, this pool is identified as one of the target resource pools.

[0053] The resource provisioning and lifecycle management layer is the module in the system responsible for executing deployment plans and managing the entire resource lifecycle. This layer receives deployment plans generated by the scheduling decision layer, creates resources in the target resource pool through adapters, configures networks and storage, installs the runtime environment, and continuously monitors deployed resources, automatically reclaiming them when they are no longer needed. For example, in video analytics applications, this layer will install the operating system, deploy analytics software, mount storage volumes, and configure the network to enable communication between components on the selected physical servers according to the deployment plan.

[0054] The aforementioned scheduling system is responsible for automatically allocating the most suitable computing, storage, and network resources to applications in heterogeneous infrastructure environments, based on user expectations of application runtime status. This system is not a simple resource management tool, but an intelligent scheduling framework capable of understanding the application's internal structure, resource requirements, and operational strategies. For example, when a user submits a complex application containing multiple collaborative components, the system analyzes the characteristics of each component, searches for the best match among global resources, and automatically completes the entire process from resource allocation to application deployment.

[0055] The application intent perception and modeling layer, the global resource profiling and abstraction layer, the multi-level intelligent scheduling decision-making layer, and the resource supply and lifecycle management layer each undertake different responsibilities, and these layers interact through standardized data interfaces. The application intent perception and modeling layer is responsible for understanding user needs, the global resource profiling and abstraction layer is responsible for understanding the current resource status, the multi-level intelligent scheduling decision-making layer is responsible for making optimal matching decisions, and the resource supply and lifecycle management layer is responsible for executing decisions and maintaining resource status. These four layers work together to form a complete closed loop from demand input to resource recycling.

[0056] The aforementioned application intent awareness and modeling layer parses application requirement templates to obtain application profiles. This layer is responsible for receiving user-submitted description files and converting them into internally processed structured data. Application requirement templates can be files written by users in a declarative language, describing the components of the application, the resources required by each component, and the relationships between components. This layer checks the template's syntactic correctness and logical rationality before converting it into a standard-format application profile. For example, when a user submits an application description file, this layer extracts all component definitions, resource requirement values, and strategies from the file, generating an application profile object containing this information for subsequent scheduling.

[0057] An application profile includes: the components of the application, the application's resource requirements, and the application's policy requirements. Component information refers to the independent deployment units that make up the application. Resource requirements information refers to the amount of processors, memory, storage, network, or hardware accelerators required by each component. Policy requirements information refers to policies such as whether components should be located close to or far apart, the service reliability level, and geographical restrictions on data storage. For example, an application profile might record that the application contains three components: the first component requires more memory, the second component requires hardware accelerators, and the third component requires highly reliable storage, while also requiring the first and second components to be deployed in a network-proximity location.

[0058] The aforementioned global resource profiling and abstraction layer is used to collect resource information from different types of resource pools. This layer is responsible for obtaining the current status of resources from various heterogeneous infrastructures. Different types of resource pools include virtual machine clusters, container clusters, and physical server clusters, each with different management interfaces and data formats. This layer connects to each resource pool through pluggable adapters, calling their respective management interfaces to obtain resource configuration information and runtime data. For example, in a hybrid environment, this layer will simultaneously obtain the status of virtual machines from the virtualization management platform, the runtime data of containers from the container management platform, and hardware health information from the physical server management interface.

[0059] The global resource profiling and abstraction layer generate a global resource profile based on resource information. This layer standardizes the collected heterogeneous resource information and aggregates it into a unified resource view. The raw data collected varies in format and needs to be converted into a unified description format before being stored in a database that supports fast queries. This unified resource view is the global resource profile, which shields the heterogeneity of underlying resources and provides a unified query interface for upper-layer scheduling. For example, regardless of whether the underlying resource is a virtual machine, container, or physical server, the same data structure is used in the global resource profile to describe it, including information such as resource identifier, type, capacity, current load, and location.

[0060] A multi-level intelligent scheduling decision layer is used to determine target resource pools for components based on application profiles and global resource profiles. This layer is responsible for matching application requirements with available resources, selecting the most suitable resource pool for each component. First, hard constraints are extracted from the application profile, such as whether specific hardware is required or where data must be stored. Then, a query is sent to the global resource profile to filter out resource pools that meet these hard constraints. The filtering results may contain one or more candidate resource pools, which are passed to the next-level scheduler for more refined selection. For example, if a component requires a hardware accelerator, only resource pools containing that type of accelerator will be selected.

[0061] The aforementioned resource supply and lifecycle management layer is used to deploy target resources for applications. This layer is responsible for translating scheduling decisions into actual infrastructure operations and executing them. Once the scheduling decision layer determines which resource pool each component should be deployed in, this layer generates a specific deployment plan and then calls the corresponding adapter to create resources in the target resource pool. The creation process includes steps such as allocating computing resources, configuring network connections, mounting storage volumes, and installing the operating system and runtime environment. After deployment, this layer continuously monitors the resource status and automatically releases resources at the end of the application's lifecycle. For example, when it is determined that a component needs to be deployed on a server in the physical server pool, this layer will start the server through the management interface, load the system image, configure the network and storage, and ultimately enable the application component to run normally.

[0062] It should be noted that this application does not impose specific limitations on the format of the application requirement template. In practical applications, application requirement templates can be written using different markup languages ​​or data exchange formats, as long as they clearly describe the application's component composition, resource requirements, and policy constraints. Templates can be written manually by the user or automatically generated by the upper-layer continuous integration system. The resource dimensions described in the template can be added or removed according to the actual scenario; for example, in some scenarios, specifying network bandwidth requirements may not be necessary, while in others, specifying the processor architecture type may be required. The template can be stored on a local file system, a remote configuration center, or a version repository. Templates can be submitted through various methods, such as command-line tools, graphical interfaces, or application programming interfaces (APIs). Different organizations or business lines can choose different template writing specifications according to their own habits, as long as the final intent parsing engine can correctly understand it.

[0063] like Figure 2The diagram shows the overall system architecture. The application intent perception and modeling layer includes: a first conversion module, used to convert the application's requirements into an application requirement template, wherein the application requirement template contains the application's components, resource requirements, and strategy requirements, and the application requirement template is a text file obtained based on a markup language; and an intent parsing engine, used to parse the application requirement template and convert it into an application profile, wherein the application profile is a data object that can be directly used by the global scheduler.

[0064] The first conversion module transforms user expectations for an application into standardized description documents. This module receives application requirements expressed by users in unstructured or semi-structured formats, such as verbal descriptions, documentation, or interface checkboxes, and organizes them into a text file conforming to a specific format. For example, in a video analytics application scenario, a user might only know that three components are needed to handle data reception, analysis, and storage, but not how to describe them in a standardized way. The first conversion module collects information through guided question-and-answer sessions and then automatically generates a standardized description document.

[0065] Markup languages ​​can be understood as text formats used to structure and describe data. Through specific syntactic strategies, markup languages ​​use tags or keywords to organize information, making the data easy for both humans to read and programs to parse. Different markup languages ​​have different syntactic features, but all can achieve ordered data storage and transmission. For example, in video analytics applications, users use markup languages ​​to write description files, where specific keywords identify information such as component names, resource quantities, and strategy types.

[0066] The intent resolution engine transforms the user description file into internal executable data. This engine reads the standardized text file submitted by the user, checks its syntax and logic, and then extracts all key information to construct a structured internal object. The engine can understand the various declarations in the file and translate them into specific instructions that the scheduler can recognize and execute. For example, in video analytics applications, after reading the description file, the intent resolution engine will identify the definitions of three components, the resource requirements of each component, and the proximity or distance relationships between the components, and then generate an internal object containing this information.

[0067] The global scheduler is the scheduling component responsible for the first round of resource filtering in the system. After receiving the application profile, the global scheduler extracts hard, non-negotiable constraints and then queries the global resource view to quickly eliminate resource pools that do not meet these hard conditions. The goal of the global scheduler is to narrow down the candidate pool, rather than making a final, fine-grained selection. For example, in a video analytics application, if the global scheduler discovers that the analytics component requires a hardware accelerator, it immediately excludes all resource pools that do not have that accelerator, retaining only those containing such accelerators for subsequent scheduling. In another scenario, if the application requires data to be stored in a specific region, the global scheduler will filter out all resource pools in other regions.

[0068] The first conversion module transforms the user's original application requirements into standardized description files that the system can further process. Users may be unfamiliar with the syntax of standardized description files or wish to reduce manual writing work; the first conversion module provides a convenient entry point. For example, after the user selects the application requirements through the graphical interface, the first conversion module automatically generates the corresponding standardized file, without the user needing to concern themselves with the file's specific format details. This module can also perform preliminary validation of user input, promptly prompting the user to correct any obvious errors.

[0069] The intent parsing engine is used to parse application requirement templates. The parsing process includes syntax checking, semantic analysis, and information extraction. The engine first verifies whether the template file's format conforms to specifications, then checks for logical contradictions in the various declarations within the template, and finally extracts the valid information for subsequent use. For example, when a user submits a template file, the intent parsing engine reads the file content line by line, identifies each keyword and its corresponding value, and constructs the internal data structure. If there are syntax errors or logical contradictions in the template, the engine will return explicit error messages.

[0070] After the intent parsing engine completes the parsing, it reorganizes the extracted information into a standardized internal data object. This data object is the application profile, which corresponds to the original template file in content but is more structured in form, making it more suitable for efficient processing by program code. The transformation process is not a simple copy, but rather the merging, simplification, and reorganization of information. For example, the template may use multiple scattered fields to describe the attributes of the same component; the intent parsing engine will aggregate these fields together to form a complete component description object. Similarly, some strategy declarations in the template may imply default behaviors; the engine will make this implicit information explicit.

[0071] Application profiles are data objects that can be directly used by the global scheduler, with their format and content adapted to the scheduler's input requirements. The original application requirement template may contain auxiliary information such as comments, whitespace, and readability formatting, which are of no practical use to the scheduler. The intent parsing engine removes this redundant information, retaining only the core data needed for scheduling decisions, and organizes it into a data structure that the scheduler can directly traverse and query. For example, after receiving an application profile, the global scheduler no longer needs to parse the text file; it can directly read the component list, resource requirements, and policy constraints within it, quickly performing subsequent scheduling calculations.

[0072] In one exemplary embodiment, the resource requirements of the application include at least one of the following: computing resources, storage resources, network resources, and hardware resources; the policy requirements include at least one of the following: quality of service level, topology relationship between components, data sovereignty, and cost and power consumption budget.

[0073] Computing resources include, but are not limited to, the number of processor cores, the processor architecture, the processor clock speed range, and whether dedicated physical cores are required to avoid resource contention. For example, in video analytics applications, the analytics components require strong computing power to process inference operations on video frames; therefore, their resource requirements will specify a certain number of processor cores.

[0074] Storage resources are the data retention and access performance required for application components to run. Storage resources include, but are not limited to, storage space capacity, storage medium type, number of input / output operations per second, data read / write throughput bandwidth, and data persistence methods such as snapshots or backup strategies.

[0075] Network resources are the connectivity capabilities required for communication between application components or with external systems. Network resources include, but are not limited to, network bandwidth, network latency limits, whether they need to be within the same network broadcast domain, and whether specific network services such as load balancing or fixed network addresses are required.

[0076] Hardware resources can be understood as dedicated hardware acceleration capabilities in addition to general-purpose processors and memory. Specifically, hardware resources include, but are not limited to, various accelerator processors, dedicated encryption and decryption chips, data compression and offloading engines, and network offloading capabilities provided by smart network interface cards (NICs).

[0077] Quality of Service (QoS) level refers to the level of stability and performance guarantees that an application requires from its infrastructure. QoS levels include, but are not limited to, high availability requirements, performance guarantee levels, fault recovery time targets, and data persistence commitments. For example, in video analytics applications, the storage component is responsible for persisting the analysis results; loss of these results would cause business interruption. Therefore, its policy requirements would specify the need for a high-reliability storage service.

[0078] The topology relationships between components refer to the mutual constraints on the deployment locations of different components within the same application. Specifically, topology relationships include, but are not limited to, affinity and anti-affinity relationships. Affinity requires multiple components to be deployed on physically close nodes to reduce communication latency, while anti-affinity requires multiple components to be deployed across different fault domains to improve availability. For example, in video analytics applications, there is frequent data exchange between the analytics component and the caching component; therefore, the policy requirements declare that they need to have an affinity relationship and be deployed in network-proximity locations. In another database scenario, the primary and backup replicas of the same database need to have an anti-affinity relationship and be deployed on different physical hosts to prevent single points of failure.

[0079] The aforementioned data sovereignty refers to the legal or compliance constraints that applications place on the geographical location of data storage. Data sovereignty requirements include, but are not limited to, the requirement that data must be stored in a data center within a specific geographical region, that data cannot be transferred across borders, and that backup copies of the data must also be stored within the same geographical region. For example, in video analytics applications, due to business compliance requirements, all video data and results data must be stored in a domestic data center; therefore, the policy requirements will declare data sovereignty restrictions. In another multinational enterprise scenario, user data in a certain region must be stored in a local data center and cannot be transferred out of the region to comply with local data protection regulations.

[0080] The aforementioned cost and power consumption budget represents the upper limit requirements for the economic cost and energy consumption of resources by the application. Specifically, the cost and power consumption budget includes, but is not limited to, the upper limit of resource usage cost per unit time, the total cost budget for the entire application lifecycle, and the priority selection of energy-efficient hardware devices during deployment. For example, in video analytics applications, if this is a long-term business, users may want to control operating costs; therefore, the policy requirements will specify the priority selection of energy-efficient servers.

[0081] Policy requirements describe how to use these resources and under what constraints. They reflect the application's business logic and operational requirements, serving as a key basis for intelligent scheduling. Different applications may have completely different policy focuses; for example, a high-availability application might focus on anti-affinity, a compliance application on data sovereignty, and a cost-sensitive application on budget control.

[0082] Service quality level defines the application's expected level of reliability and performance; topology relationships between components define the mutual constraints between components in terms of deployment location; data sovereignty defines the geographical compliance requirements for data storage; and cost and power budget define the control targets for economic costs and energy consumption. These dimensions can be used independently or in combination.

[0083] It should be noted that this application does not specifically limit the dimensions and expression of resource requirements. In practical applications, new dimensions can be added to resource requirements based on the actual situation of the infrastructure. For example, in some scenarios, it may be necessary to specify the processor cache size or memory access speed. The value of resource requirements can be an exact value or a range; for example, the number of processor cores can be a minimum value. Resource requirements can be marked with priority tags, and when multiple requirements cannot be met simultaneously, the higher-priority requirements are prioritized. Resource requirements can change over time; for example, a component may require more resources at startup, and the resource requirements may decrease after stable operation. Resource requirements can support elastic scaling, allowing components to dynamically adjust resource quotas at runtime.

[0084] In an exemplary embodiment, the global resource profiling and abstraction layer includes a resource information collector, which communicates with a resource pool of a corresponding type via an adapter to obtain resource information in the resource pool.

[0085] The global resource profiling and abstraction layer connects to different types of resource pools through adapters, collecting static configuration information and dynamic operating status of various resources. It then converts this heterogeneous information into a standardized format, forming a global view covering all resources. This layer includes, but is not limited to, collecting data on processor utilization, remaining memory, network traffic, hardware health status, and dedicated accelerator usage from various types of servers. For example, in video analytics applications, this layer simultaneously collects information from physical server pools containing hardware accelerators, general virtual machine pools, and container pools, then unifies this heterogeneous information into data of the same format.

[0086] The aforementioned resource information collector is designed in a pluggable manner, with corresponding collection adapters developed for different types of resource pools. Each adapter specifically handles the communication protocol and data format of a particular resource pool. The resource information collector operates in two modes, including but not limited to active polling and event subscription. It can periodically pull data according to a configured time period, or register listener callbacks to receive real-time notifications when resource status changes. For example, in video analytics applications, the resource information collector might run multiple collection instances simultaneously: one responsible for obtaining the physical server's hardware status through a management interface, another for obtaining container runtime data through a container platform interface, and yet another for obtaining virtual machine load information through a virtualization management interface.

[0087] The aforementioned adapters are communication conversion components in the resource information collector used to interface with specific types of resource pools. Each adapter encapsulates all the details required to interact with a particular resource pool, including authentication methods, calling interfaces, data parsing strategies, and error handling logic. Adapters include, but are not limited to, virtualization platform adapters, container orchestration system adapters, bare metal management adapters, and special hardware adapters. Each adapter is developed and upgraded independently without affecting others. For example, in video analytics applications, hardware adapters obtain fine-grained information such as accelerator memory usage, temperature, and power consumption through dedicated driver interfaces, while virtualization adapters obtain virtual machine processor and memory usage through the management platform's application programming interface.

[0088] The resource information collector communicates with the corresponding type of resource pool through an adapter. The adapter acts as a translator and bridge, converting the uniformly formatted requests issued by the collector into instructions that the specific resource pool can understand, and converting the heterogeneous data returned by the resource pool into a uniform format that the collector can process. The collector itself does not need to know the specific implementation details of the underlying resource pool. For example, in video analytics applications, when the collector needs to obtain the status of a physical server, it calls a bare metal adapter. This adapter is responsible for completing the handshake, authentication, and data acquisition with the server management interface. The collector only needs to receive the standard format data returned by the adapter.

[0089] In one exemplary embodiment, the adapter includes at least one of the following: a virtualization platform adapter, a container orchestration system adapter, a bare metal management adapter, and a hardware adapter.

[0090] A virtualization platform adapter is a communication conversion component that interfaces with a virtualization management system. This adapter encapsulates the details required for interaction with the virtualization platform, including authentication methods, API call methods, data parsing strategies, and exception handling logic. Specifically, the virtualization platform adapter includes, but is not limited to, functions such as obtaining the overall status of the virtual machine cluster, querying the processor and memory usage of individual virtual machines, and obtaining network traffic from virtual switches. For example, in video analytics applications, the virtualization platform adapter is responsible for connecting to the system managing the virtual machine cluster, periodically obtaining load data for each virtual machine, and determining which virtual machines have idle resources to host caching or database components.

[0091] The container orchestration system adapter described above can obtain information such as nodes, container instances, storage volumes, and network configurations in a container cluster. The container orchestration system adapter includes, but is not limited to, functions such as obtaining a list of container nodes, querying the remaining resources of each node, obtaining the running status of container instances, and collecting communication latency of the container network. For example, in video analytics applications, if a component is suitable for running in a containerized manner, the container orchestration system adapter will obtain the remaining processor and memory resources of each node in the container cluster to help the scheduler determine which node is suitable for deploying the component.

[0092] Bare-metal management adapters communicate with the server's management controller via standard management protocols, enabling them to acquire hardware status and control server power without relying on the operating system running on the server. Specifically, bare-metal management adapters include, but are not limited to, acquiring server hardware configuration information, reading sensor temperature and power consumption data, controlling server power-on and power-off, and installing operating systems via network boot. For example, in video analytics applications, a bare-metal management adapter connects to a pool of physical servers, acquires the hardware health status and real-time power consumption of each server, and, after scheduling decisions, powers on the selected servers and deploys application components.

[0093] The hardware adapter reads the internal operating status and health information of the acceleration device through the low-level driver interface or management library provided by the hardware manufacturer. Specifically, the hardware adapter includes, but is not limited to, obtaining the accelerator model and onboard memory size, querying the usage and temperature of video memory, reading the accelerator's power consumption and operating frequency, and obtaining the partitioning of virtualization acceleration instances. For example, in video analytics applications, the hardware adapter is responsible for scanning all accelerators installed on all physical servers, obtaining the current load and available video memory of each accelerator, and helping the scheduler find the most suitable server for deploying inference components.

[0094] The system can flexibly select and deploy corresponding adapters based on the types of resource pools existing in the actual environment. This design makes the system highly scalable; when a new type of resource pool needs to be managed, only the corresponding adapter needs to be added. For example, in a data center where video analytics applications are deployed, there are virtual machine clusters, container clusters, physical servers, and hardware accelerators. Therefore, it is necessary to deploy virtualization platform adapters, container orchestration system adapters, bare metal management adapters, and hardware adapters simultaneously.

[0095] Virtualization platform adapters, container orchestration system adapters, bare metal management adapters, and hardware adapters can be understood as four typical adapter types, corresponding to virtualization resource pools, container resource pools, physical server resource pools, and dedicated hardware devices, respectively. Each adapter follows a unified interface specification, but their internal implementations are completely different because they interface with different management system protocols and data formats. For example, in video analytics applications, the virtualization platform adapter calls the application programming interface of the virtualization management platform to obtain virtual machine information; the container orchestration system adapter calls the container platform's state transition interface to obtain container node information; the bare metal management adapter reads the physical server status through the intelligent platform management interface protocol; and the hardware adapter obtains the accelerator status through the runtime library provided by the hardware vendor.

[0096] In one exemplary embodiment, the resource information collector communicates with a resource pool of a corresponding type via an adapter to obtain resource information in the resource pool, including: the resource information collector communicating with the resource pool of a corresponding type via the adapter according to a preset period to obtain resource information in the resource pool; or, the resource information collector communicating with the resource pool of a corresponding type via the adapter according to a subscription event to obtain resource information in the resource pool.

[0097] The aforementioned preset period can be understood as a fixed time interval pre-set by the system to control the frequency of resource information collection. This period can be reasonably set according to the speed of resource information changes and the timeliness requirements of scheduling decisions. Specifically, the preset period includes, but is not limited to, different granularities such as rapidly changing indicators collected every few seconds, slowly changing indicators collected every few minutes, and almost unchanging indicators collected every few hours.

[0098] The aforementioned subscription events can be understood as a passive information acquisition mechanism, where the resource pool proactively notifies the collector when its own state changes. Unlike active polling, the subscription method does not require the collector to repeatedly query; instead, the resource pool management system triggers a callback or sends a message when it detects a change. Specifically, subscription events include, but are not limited to, resource creation events, resource deletion events, resource attribute change events, performance threshold trigger events, and fault alarm events.

[0099] The aforementioned resource information collector communicates with the corresponding type of resource pool through an adapter to obtain resource information from the pool. This includes the fact that the resource information collector can acquire data in various ways. The term "including" is used to introduce two typical working modes, indicating that the collector is not limited to a single data acquisition method but can flexibly select or combine multiple modes according to the characteristics of the resource pool and business needs. This design allows the system to adapt to the management interface characteristics of different types of resource pools. For example, in video analytics applications, a subscription model can significantly reduce invalid polling for resource pools that support event notification mechanisms, while only a periodic polling model can be used for resource pools that do not support event notifications.

[0100] The resource information collector communicates with the corresponding type of resource pool through the adapter at preset intervals to obtain resource information from the pool. This can be understood as the collector operating in an active polling manner, repeatedly performing the acquisition operation at fixed time intervals. The collector maintains an internal timer; each time the timer expires, the collector initiates a data request to the resource pool through the adapter to obtain a snapshot of the current resource status. The advantage of this mode is its simplicity, low requirements for the resource pool management system, and lack of need for the resource pool to support event push functionality. For example, in video analytics applications, the collector queries the processor utilization and remaining memory of the physical server every few seconds through the bare metal management adapter, performing the query operation periodically regardless of whether the status has changed.

[0101] The aforementioned resource information collector communicates with the corresponding type of resource pool through the adapter according to subscribed events to obtain resource information in the resource pool. This can be understood as the collector operating in a passive receiving manner, registering the event types of interest with the resource pool management system beforehand. When these events occur in the resource pool, the management system proactively sends a notification to the collector, which then obtains detailed change information through the adapter. The advantage of this mode is its good real-time performance; it can promptly detect state changes without frequent polling, significantly reducing unnecessary network requests.

[0102] In an exemplary embodiment, the global resource profiling and abstraction layer further includes: a second conversion module, configured to convert the resource information obtained from the resource pool into a unified resource model object, wherein the unified resource model object includes static attributes and dynamic attributes, the rate of change of resource information having the static attributes is less than or equal to a first rate of change threshold, and the rate of change of resource information having the dynamic attributes is greater than or equal to a second rate of change threshold.

[0103] The aforementioned second conversion module can standardize heterogeneous resource information into components with a unified format. This module receives raw resource data collected from different adapters, which vary in format, unit, and description. The second conversion module converts these data into data objects with the same structure according to predefined specifications. The second conversion module includes, but is not limited to, functions such as data format conversion, unit unification, field mapping, missing value imputation, and data validation.

[0104] The raw data acquired by the collector comes from different sources and has varying formats, making it unsuitable for direct use in unified scheduling decisions. The second transformation module performs data cleaning and format standardization. This module converts the format of the raw resource information, outputting a standardized unified resource model object. This transformation process includes identifying each field in the raw data, mapping them to their corresponding attribute positions in the unified resource model object, and normalizing the data format and units. The transformed object has a fixed data structure and can be processed uniformly by other modules in the system.

[0105] The aforementioned Unified Resource Model (URM) object is a standardized data structure describing a single resource. This structure defines a fixed set of attributes for each type of resource, and regardless of whether the underlying infrastructure is a physical server, virtual machine, container, or dedicated hardware device, it uses the same format of data objects to represent them. Specifically, the URM object includes, but is not limited to, components such as a resource identifier field, a resource type field, a set of static attributes, and a set of dynamic attributes.

[0106] The aforementioned static attributes are inherent characteristics of resources that do not change with their operational state or change extremely slowly. These attributes are typically determined at resource creation and remain largely unchanged throughout their lifecycle, allowing for very low collection frequency to reduce system overhead. Specifically, static attributes include, but are not limited to, a resource's unique identifier, resource type name, hardware model, physical location information, processor architecture type, total memory capacity, total disk capacity, and firmware version. For example, in video analytics applications, the processor model and total memory of the physical server are determined at the factory and do not change over time, thus being classified as static attributes. In another scenario, the pre-defined tag information and tenant information in a virtual machine template also belong to static attributes and do not change during virtual machine operation.

[0107] The aforementioned dynamic attributes are information about resources that changes in real time with load and operating status. These attributes reflect the current usage and health status of resources, and change frequently, requiring frequent collection to maintain data real-time performance. Specifically, dynamic attributes include, but are not limited to, current processor utilization, memory usage, storage I / O load, network transmit / receive rates, hardware accelerator memory utilization, device temperature, real-time power consumption, and health monitoring status. For example, in video analytics applications, the processor utilization and accelerator memory utilization of physical servers fluctuate in real time as the analytics components operate, and are therefore classified as dynamic attributes, requiring frequent collection and updates. In another scenario, the real-time traffic rate and packet loss rate of network ports are also dynamic attributes, providing important reference value for scheduling decisions.

[0108] In an exemplary embodiment, the global resource profile and abstraction layer further includes: a global resource profile database for storing the unified resource model object and generating the global resource profile based on the unified resource model object, wherein the global resource profile database includes an in-memory database and a time-series database, the in-memory database for storing the current snapshot of the unified resource model object, and the time-series database for storing historical data of resource information with the dynamic attributes.

[0109] The global resource profile database is used to store and manage unified resource model objects. This database not only saves snapshots of the current state of resources but also maintains a historical record of resource state changes, providing comprehensive data support for scheduling decisions. Specifically, the global resource profile database includes, but is not limited to, supporting high-concurrency real-time read and write operations, supporting complex multi-dimensional conditional queries, and supporting persistent data storage and backup / recovery. For example, in video analytics applications, when the scheduler needs to find physical servers that simultaneously meet the criteria of low processor load, sufficient memory, and hardware accelerators, the global resource profile database can quickly return a list of servers that meet these conditions.

[0110] The aforementioned in-memory database is a database system that primarily stores data in random access memory (RAM). Because memory read / write speeds are significantly faster than disk speeds, in-memory databases offer microsecond-level data access latency, making them ideal for storing snapshots of resource states that require frequent read / write operations and rapid queries. Specifically, in-memory databases include, but are not limited to, support for key-value stores, document storage, structured query language (SCL) queries, and automatic data expiration cleanup. For example, in video analytics applications, the scheduler needs to query the current load status of various resources in real time. This status data is stored in an in-memory database, allowing the scheduler to filter candidate resources in a very short time.

[0111] The aforementioned time-series database is a database system for processing time-series data. Time-series data is a sequence of data points recorded in chronological order, with each data point containing a timestamp and one or more numerical values. Time-series databases are specifically optimized for writing, storing, and querying this type of data, featuring high compression ratios and high write throughput. Specifically, time-series databases include, but are not limited to, supporting high-frequency data writing, supporting data downsampling and aggregation, supporting automatic deletion of expired data using retention policies, and supporting fast queries by time range.

[0112] A current snapshot is a complete copy of the state of all resources at a specific moment. It records the values ​​of the static and dynamic attributes of each resource at that instant, providing a snapshot of the resource world. Unlike historical data, a snapshot only retains the latest state and does not preserve historical changes. Specifically, a current snapshot includes, but is not limited to, all resource identification information, type information, configuration information, and real-time performance metrics. For example, in video analytics applications, a current snapshot records dynamic information such as processor utilization, remaining memory, and accelerator memory usage for each physical server at that moment, and the scheduler makes deployment decisions based on this snapshot.

[0113] Historical data can be understood as a record of how resource states change over time. Each historical data point records the state value of a resource at a specific moment, and multiple consecutive data points constitute a time series of changes in that resource's state. Historical data is the foundation for trend analysis, anomaly detection, and capacity planning. Specifically, historical data includes, but is not limited to, historical curves of resource utilization, historical records of failure events, and operation logs for resource allocation and release. For example, in video analytics applications, by analyzing historical data on accelerator memory usage over the past few days, load peaks in the next few hours can be predicted, allowing for advance resource reservation. In another scenario, when a resource exhibits abnormal behavior, its historical data can be consulted to pinpoint the time and possible causes of the problem.

[0114] The global resource profiling database can be understood as a layer that, in addition to the modules responsible for data collection and transformation, also includes a dedicated database system for storing and managing resource data. The collection and transformation modules generate the data, while the database persistently stores this data and provides efficient query services. The database is the central data hub of the entire global resource profiling system; the scheduler and upper-layer applications all obtain resource information through it. For example, in video analytics applications, the data acquired by the resource information collector, after being standardized by the second transformation module, is ultimately stored in the global resource profiling database. When making decisions, the scheduler directly retrieves the necessary resource information from the database.

[0115] The database supports CRUD operations and guarantees data consistency and durability. For example, in video analytics applications, when a new physical server is added to the resource pool, the system creates a corresponding unified resource model object and inserts it into the database. When the server is removed, the corresponding object is also deleted from the database.

[0116] The global resource profiling database, comprising an in-memory database and a time-series database, can be understood as employing a hybrid storage architecture, with two different types of databases working together. The in-memory database handles current state queries with high real-time requirements, while the time-series database handles trend queries with high historical data analysis requirements.

[0117] The in-memory database stores a current snapshot of the unified resource model objects, containing the latest state snapshot of all resources. This snapshot is continuously updated as the resource state changes, always maintaining an accurate state at the current moment. Because it is stored in memory, read and write operations on this snapshot data are very fast, supporting the scheduler's high-frequency query needs. For example, in video analytics applications, the processor utilization of each physical server changes every second, and these changes are updated in real time to the corresponding snapshot field in the in-memory database, ensuring that the scheduler always reads the latest values.

[0118] The time-series database stores the historical trajectory of dynamic attributes changing over time. Whenever the collector acquires new dynamic attribute data, in addition to updating the current snapshot in the in-memory database, it also writes this data, along with a timestamp, to the time-series database, appending it to the historical record. The time-series database compresses this time-series data for storage, saving disk space. For example, in video analytics applications, each acquired server processor utilization rate is stored as a data point in the time-series database. These data points are arranged chronologically, forming a continuous utilization rate change curve, which can be used for subsequent statistical analysis and trend prediction.

[0119] In an exemplary embodiment, the multi-level intelligent scheduling decision layer includes: a global scheduler, configured to receive the application profile and filter and query the global resource profile based on the hard requirements in the application profile to obtain a candidate resource pool list, wherein the resource requirements and / or the policy requirements include the hard requirements, and the candidate resource pool list includes at least one candidate resource pool; and a resource pool scheduler, configured to receive the application profile and the candidate resource pool list, and determine the target resource pool in the candidate resource pool list based on the application profile and a scheduling policy library.

[0120] The global scheduler can be understood as the scheduling component responsible for the first round of coarse-grained resource screening in a multi-level intelligent scheduling decision layer. After receiving the application profile, the scheduler extracts the mandatory, non-negotiable hard constraints and then queries the global resource profile database to quickly eliminate resource pools that do not meet these hard constraints. Specifically, the global scheduler includes, but is not limited to, extracting and parsing hard constraints, constructing query statements for the resource profile database, and aggregating the query results into a candidate resource pool list. For example, in a video analytics application, if the application profile declares that the analytics component must use a hardware accelerator, the global scheduler will extract this hard requirement, query the database for all resource pools containing such accelerators, and then output the query results as a candidate list. In another scenario, if the application requires data to be stored within a specific geographical area, the global scheduler will filter out all resource pools in other areas, retaining only candidate pools that meet the geographical requirements.

[0121] Hard requirements can be understood as the constraints in the application profile that must be met without room for compromise. Unlike soft preferences, hard requirements are mandatory; any resource that does not meet these conditions cannot be selected as a deployment target. Specifically, hard requirements include, but are not limited to, the need for specific hardware accelerators, restrictions on data storage locations, guarantees of minimum resource quotas, and requirements for security isolation levels.

[0122] The candidate resource pool list is a collection of resource pools that meet all the application's hard requirements after being filtered by the global scheduler. This list may contain one or more resource pools, each of which has the basic conditions to support the application components. Specifically, the candidate resource pool list includes, but is not limited to, a unique identifier for each candidate pool, the pool's basic attributes, and the pool's current resource overview.

[0123] The resource pool scheduler is a scheduling component that performs a second round of fine-grained resource matching. This scheduler operates within the candidate resource pool selected by the global scheduler, precisely selecting the final deployment target for each component based on the detailed policy requirements in the application profile and the real-time dynamic status of the resources. Specifically, the resource pool scheduler includes, but is not limited to, loading and combining multiple scheduling policies, evaluating the matching degree between candidate resources and component requirements, calculating a comprehensive score, and selecting the optimal target.

[0124] The aforementioned scheduling strategy library is a collection of pluggable scheduling algorithm modules. These modules encapsulate different scheduling objectives and optimization logic, allowing the resource pool scheduler to dynamically load and combine these strategies according to scenario needs, achieving flexible and configurable scheduling behavior. Specifically, the scheduling strategy library includes, but is not limited to, modules for affinity strategies, anti-affinity strategies, binning strategies, distribution strategies, cost-first strategies, performance-first strategies, and power-first strategies. For example, in video analytics applications, the resource pool scheduler loads both affinity and power-first strategies, ensuring network proximity between analytics components and caching components while favoring energy-efficient servers.

[0125] The global scheduler is the first-level component of the multi-level intelligent scheduling decision layer. It undertakes the initial macro-level screening task. This decomposition effectively reduces the complexity of the scheduling problem, avoiding fine-grained calculations on a large number of resources. The global scheduler is characterized by speed and coarseness; its goal is to narrow down the candidate pool rather than make a final decision. For example, in video analytics applications, the global scheduler only needs to determine which resource pools have hardware accelerators, without needing to consider the specific load of each server within the pool. This determination can be quickly completed through a simple database query.

[0126] The global scheduler uses hard requirements as filtering criteria to query the global resource profile database. This filtering query means only retaining resources that meet all hard requirements, and directly excluding those that don't. This type of query is typically based on static attributes and aggregated statistics in the resource profile, without needing to delve into the detailed dynamic status of each resource.

[0127] Within the limited scope of the candidate list, the resource pool scheduler makes the final deployment decision based on the detailed requirements in the application profile. For example, in a video analytics application, after receiving the application profile and the candidate list, the resource pool scheduler evaluates whether the resources in each resource pool in the candidate list can meet the detailed requirements of each component of the application. The resource pool scheduler integrates the policy requirements in the application profile with the algorithm modules in the scheduling policy library to select the most suitable resource pool from the candidate resource pool list as the final target resource pool. The process of determining the target resource pool is a multi-objective optimization problem; the scheduler calculates a comprehensive score for each candidate pool and selects the pool with the highest score. For example, in a video analytics application, assuming the candidate list includes physical server pools and virtual machine pools, after evaluating based on a cost-first strategy, the resource pool scheduler finds that the physical server pool has a lower unit time cost, and therefore selects the physical server pool as the target resource pool.

[0128] In one exemplary embodiment, the scheduling policy library includes at least one of the following policies: affinity / anti-affinity policy, binning policy, distributed policy, cost-first policy, quality of service-first policy, and power-first policy.

[0129] In an exemplary embodiment, the affinity / anti-affinity strategy is used to query topology information in the global resource profile and deploy related components on corresponding servers based on the topology information, wherein the target resource pool includes the servers; the binning strategy is used to deploy new loads to target servers, wherein the target servers already have workloads deployed and resource utilization is less than or equal to a preset threshold, wherein the target resource pool includes the target servers; the distribution strategy is used to deploy different instances of the same application in different fault domains, wherein the fault domains include: physical hosts, racks, and power lines; the cost-priority strategy is used to select the lowest-cost resource based on resource cost information in the global resource profile; and the power-priority strategy is used to select the lowest-power resource based on power consumption data in the global resource profile.

[0130] Affinity strategies tend to deploy components with close collaborative relationships in geographically proximate locations. This strategy analyzes the communication frequency and data exchange volume between components, prioritizing deployments in nearby locations with low network latency and sufficient bandwidth to improve overall application performance. Specifically, affinity strategies include, but are not limited to, deploying components on the same physical server, within the same rack, in the same cabinet, or on different nodes under the same network switch, among other granularities of affinity. For example, in video analytics applications, the analytics component frequently reads video frame data from the cache component. An affinity strategy would deploy these two components in locations with the lowest network latency, potentially choosing the same physical server or different servers within the same rack.

[0131] Anti-affinity strategies tend to distribute redundant components across different fault domains. This strategy analyzes backup or primary-backup relationships between components to ensure that multiple instances of the same application are not simultaneously affected by a single point of failure, thereby improving overall application availability. Specifically, anti-affinity strategies include, but are not limited to, distributing different instances on different physical servers, in different racks, on different power lines, or in different availability zones, among other granular requirements. For example, in video analytics applications, two database replicas need to be mutually primary and backup; an anti-affinity strategy would deploy them on different physical servers, so that even if one server fails, the other can still continue to provide service. In another financial trading scenario, multiple instances of a transaction processing service need to be distributed across different racks to prevent all instances from going offline simultaneously due to rack power failure.

[0132] Crate packing is a scheduling strategy that concentrates workloads across as few servers as possible. This strategy prioritizes deploying new components on servers already under load until their resource utilization reaches a preset high watermark. Idle servers are then placed in a low-power state or shut down, thus saving energy and operational costs. Specifically, cramming strategies include, but are not limited to, prioritizing servers with the fewest remaining resources but sufficient to meet demand, prioritizing servers with the highest current load, and prioritizing servers already running similar components. For example, in video analytics applications, if multiple lightweight caching components need to be deployed, cramming will concentrate their deployment on a few servers rather than distributing them across many servers.

[0133] Distributed strategies tend to evenly distribute workloads across as many servers as possible. This strategy contrasts with binning strategies, aiming to prevent resource hotspots and performance bottlenecks by avoiding concentrating too many components on a single server, while simultaneously improving application fault tolerance. Specifically, distributed strategies include, but are not limited to, prioritizing the server with the lowest current load, prioritizing the server with the fewest deployed instances, and mandating that instances of the same application be distributed across different fault domains. For example, in video analytics applications, if multiple instances of the analytics component need to process a large number of video streams simultaneously, a distributed strategy would deploy them across different physical servers to prevent all inference tasks from competing for computing resources on the same server.

[0134] Cost-first strategies tend to select deployment options with the lowest cost per unit of resource usage. This strategy assesses cost differences between different resource pools or servers, prioritizing resources that meet application requirements with the lowest economic cost, thus helping users control total cost of ownership. Specifically, cost-first strategies include, but are not limited to, prioritizing older servers with lower depreciation costs, prioritizing low-power servers with lower electricity costs, and prioritizing resources available during off-peak hours with lower rental prices. For example, in video analytics applications, if users are sensitive to the application's operating costs, a cost-first strategy might select energy-efficient servers to deploy components, even if these servers don't have the highest absolute performance.

[0135] A Quality of Service (QoS)-first strategy can be understood as a scheduling strategy that prioritizes deployment options that offer the highest performance guarantees. This strategy assesses the differences in capabilities among various resources and prioritizes those that can meet stringent performance metrics, even if these resources are more expensive, to ensure that the application's QoS is not compromised. Specifically, a QoS-first strategy includes, but is not limited to, prioritizing servers with the highest processor clock speeds, storage devices with the best I / O performance, network links with the lowest latency, and servers with hardware acceleration capabilities. For example, in video analytics applications, the inference component is highly sensitive to latency; a QoS-first strategy would select the server with the most powerful processor and the highest accelerator configuration to deploy this component. In another real-time trading scenario, a QoS-first strategy ensures that the transaction processing component has exclusive access to bus resources, avoiding contention with other tasks that could cause latency fluctuations.

[0136] A power-first strategy prioritizes deployments that consume the least overall energy. This strategy evaluates real-time power consumption and energy efficiency ratios of different servers, prioritizing resources that consume the least amount of power while meeting application requirements, thus helping data centers achieve green and low-carbon operations. Specifically, a power-first strategy includes, but is not limited to, prioritizing newer servers with higher energy efficiency, servers with lower current loads and lower power consumption, and servers in low-temperature zones that can utilize natural cooling. For example, in video analytics applications, if multiple physical servers meet the resource requirements of the analytics components, the power-first strategy will select the server with the lowest current real-time power consumption for deployment.

[0137] The aforementioned fault domain can be understood as a collection of resources sharing the same point of failure risk. When an infrastructure component within a fault domain fails, all servers or service instances within that domain will be affected. Therefore, to improve application availability, it is necessary to distribute different instances of the same application across different fault domains.

[0138] The affinity strategy selects the server that best fits the topology constraints as the deployment target based on the strength of the relationship between components. Components with strong relationships should be deployed in locations with the closest topological distance, such as on the same server or within the same rack, while the requirements can be relaxed for components with weaker relationships. The strategy calculates a topology matching score for each candidate server and selects the server with the highest score.

[0139] The binning strategy prioritizes servers already running other workloads over idle servers to improve overall resource utilization. The strategy iterates through all candidate servers, scoring them based on their current resource usage to select the most suitable one. For example, in video analytics applications, when a new big data batch processing task needs to be deployed, the binning strategy will prioritize servers already running other batch processing tasks, concentrating these computationally intensive tasks onto a few high-performance servers.

[0140] The target server selected by the binning strategy meets two conditions: first, other workloads are already deployed on the server, and it is not completely idle; second, the server's resource utilization has not exceeded the preset threshold, and there is sufficient margin to handle new workloads. These two conditions together ensure that the binning strategy can consolidate the workload without overloading the server.

[0141] Distributed deployment strategies improve application availability by distributing different instances of the same application across different fault domains. This avoids single points of failure that could render the entire application unavailable. The strategy analyzes the component instances declared as needing distribution in the application profile and then selects a server belonging to a different fault domain for each instance. For example, in a video analytics application, if the database component requires two instances, the distribution strategy ensures that these two instances are deployed on two different physical hosts. This way, if one host fails, the database instance on the other host can still continue to provide service.

[0142] Fault domains can be divided into physical hosts, racks, and power lines at different granularities, ranging from fine to coarse, including physical host-level fault domains, rack-level fault domains, and power line-level fault domains. Finer granularity makes it easier to meet distribution requirements, but also provides weaker fault isolation capabilities. Coarser granularity provides more stringent distribution requirements and higher availability assurance. Users can choose the appropriate fault domain granularity based on the reliability requirements of their application.

[0143] The cost-first strategy selects the resource with the lowest cost based on resource cost information from the global resource profile. During scheduling, the strategy queries the global resource profile database for cost information on various resources and then selects the resource that meets application requirements but has the lowest economic cost. Cost information can be statically configured, such as the unit-time rental price of different server models, or dynamically calculated, such as the electricity cost calculated based on real-time electricity prices. The strategy calculates the total cost for each candidate resource and selects the one with the lowest cost.

[0144] The power consumption priority strategy selects the resource with the lowest power consumption based on power consumption data in the global resource profile. During scheduling, the strategy queries the global resource profile database for real-time updated server power consumption data and then selects the resource that meets application requirements but has the lowest real-time power consumption. Power consumption data is typically collected and reported in real-time by the server's out-of-band management interface, reflecting the server's current energy consumption. The strategy compares the current power consumption values ​​of each candidate server and selects the one with the lowest power consumption.

[0145] It should be noted that this application does not specifically limit the implementation details and parameter configurations of various strategies. In practical applications, affinity strategies can support different levels of affinity strength, such as forced affinity and soft affinity. Forced affinity must be satisfied or scheduling will fail, while soft affinity can be used as an optimization target but is not mandatory. Anti-affinity strategies can support different numbers of dispersion constraints, such as requiring that the number of instances of the same application in the same rack not exceed a certain amount. The preset threshold of the binning strategy can be dynamically adjusted, and the system can automatically increase or decrease the threshold according to the overall load. The fault domain granularity of the dispersion strategy can be customized and extended, such as adding switch-level fault domains or data center-level fault domains. The cost model of the cost-first strategy can support multi-dimensional cost synthesis, such as simultaneously considering hardware procurement costs, power costs, and maintenance costs, and calculating the comprehensive cost according to different weights. The power-first strategy can combine the server's energy efficiency curve, not only comparing the current instantaneous power consumption, but also predicting the power consumption increment after deploying new loads, and selecting the solution with the smallest increment. Conflicts may exist between various strategies. For example, an affinity strategy might require centralized deployment of components, while a distributed strategy requires distributed deployment. In such cases, the strategy must be prioritized based on user-defined priorities. The strategy can support a fallback mechanism, automatically relaxing constraints or switching to an alternative strategy when the preferred strategy cannot find a feasible solution. The execution results of the strategy can be recorded and analyzed for continuous optimization of strategy parameters. The strategy can support simulated operation, allowing users to preview the decisions the strategy will make before actual scheduling. In summary, any strategy implementation that can make optimized scheduling decisions based on topology information, resource utilization, fault domains, cost information, or power consumption data is acceptable, and this application does not impose any specific limitations on it.

[0146] In an exemplary embodiment, the resource supply and lifecycle management layer includes: a unified resource adapter, configured to call a corresponding script file according to the type of resources in the target resource pool, wherein the script file is used to deploy the resources; and a resource deployment and configuration module, configured to deploy the target resource pool for the application and send a confirmation message to the global resource profile after deployment.

[0147] The unified resource adapter is an execution component that translates standardized instructions into specific resource pool operation commands. This adapter corresponds to the adapter in the resource information acquisition layer; the former is responsible for collecting information, while the latter is responsible for executing operations. Together, they form a complete channel for interacting with heterogeneous resource pools. Specifically, unified resource adapters include, but are not limited to, different types such as resource creation adapters for virtualization platforms, resource deployment adapters for container platforms, boot configuration adapters for bare metal servers, and resource configuration adapters for hardware accelerators.

[0148] The resource deployment and configuration module receives the deployment plan generated by the scheduling decision layer and sequentially calls the unified resource adapter according to a predefined step order to complete the fully automated operation from resource creation to application deployment. Specifically, the resource deployment and configuration module includes, but is not limited to, functional components such as a task orchestration engine, a state tracker, a failure retry mechanism, and deployment result verification.

[0149] The unified resource adapter translates abstract deployment commands into actual operations on specific resource pools. Without adapters, scheduling decisions cannot be implemented. The adapter design follows the same pluggable principle as the acquisition layer adapters, with one adapter implementation corresponding to each resource type. For example, in video analytics applications, the unified resource adapter automatically selects the correct adapter instance based on the type of the target resource pool: a bare-metal adapter for physical servers and a virtualization adapter for virtual machines, without the caller needing to concern itself with the underlying differences.

[0150] The unified resource adapter first identifies the type of the target resource, then selects and executes the corresponding script file based on the type. Different types of resources require different deployment processes and operation commands, and the script file encapsulates these differentiated details. The adapter itself does not contain specific deployment logic; it is only responsible for script scheduling and execution. This design allows adding a new resource type to the network by simply adding the corresponding script file, without modifying the adapter code.

[0151] The resource deployment and configuration module actually allocates resources from the target resource pool selected by the scheduling decision layer to applications. The deployment plan received by this module specifies which resource pool and node each component should be deployed on, and the module must complete the deployment operations according to this plan. The deployment process may involve multiple steps and the coordinated work of multiple adapters; the module is responsible for coordinating the execution order and dependencies of these steps.

[0152] After deployment, a confirmation message is sent to the global resource profile to notify the database that the resource reservations made during the previous scheduling decision phase have officially taken effect, and the corresponding resources have changed from a reserved state to an actually occupied state. Upon receiving the confirmation message, the database updates the status field and occupancy information in the corresponding unified resource model object.

[0153] In an exemplary embodiment, the resource supply and lifecycle management layer includes a status monitoring and recycling module, which includes a fault self-healing unit, configured to trigger a scheduling request to request an update of the application deployment server when a fault is detected in the server where the application is deployed; and a resource recycling unit, configured to release the target resource pool when preset conditions are met, wherein the preset conditions include: deleting the application, or the end of the application's lifecycle.

[0154] The aforementioned status monitoring and recycling module continuously observes the operational status of deployed resources and performs resource cleanup. This module not only passively receives events indicating changes in resource status but also proactively probes the health status of application instances, ensuring timely responses in the event of anomalies or the end of their lifecycle. Specifically, the status monitoring and recycling module includes, but is not limited to, periodically sending health probe requests, receiving fault alarms from the resource pool, collecting application-level performance metrics, and performing resource release operations.

[0155] The fault self-healing unit continuously monitors the heartbeat and health status of deployed resources. Once an anomaly is detected, it automatically initiates a scheduling request, asking the system to find new available resources for the affected components to rebuild, thereby achieving automatic service recovery. Specifically, the fault self-healing unit includes, but is not limited to, functions such as fault detection logic, fault type determination, self-healing strategy selection, and the construction and sending of scheduling requests.

[0156] The aforementioned resource reclamation unit listens for application deletion events or lifecycle end events. When the conditions are met, it proactively invokes the unified resource adapter to perform resource decommissioning, cleanup, and release operations, ensuring that resources can be promptly reclaimed and reintroduced into the available resource pool. Specifically, the resource reclamation unit includes, but is not limited to, listening for application deletion interfaces, parsing lifecycle policies, invoking the adapter to perform resource deletion, and notifying the database to update the status.

[0157] The aforementioned preset conditions are a predefined set of conditions that trigger the resource reclamation unit to perform resource release operations. These conditions can be user-initiated operations or states automatically determined by the system based on the application's lifecycle strategy. When any condition is met, the resource reclamation unit will initiate the reclamation process. Specifically, preset conditions include, but are not limited to, user deletion of the application through the interface or API, application lifecycle expiration, application actively issuing an exit signal, and application being in an abnormal state for an extended period without self-healing. For example, in a video analytics application, a user might decide to discontinue the analytics service due to business adjustments and initiate a deletion operation through the management interface, thus satisfying the application deletion condition among the preset conditions. In another scenario, a temporary application used for data migration is set to have a lifecycle of several hours at creation. When the running time exceeds this duration, the system automatically determines that the lifecycle has ended and triggers the reclamation process.

[0158] The fault self-healing unit is a sub-unit within the status monitoring and recovery module specifically designed for fault recovery. This unit embodies the system's level of automation and intelligence, enabling it to automatically handle common resource failures without human intervention. The presence of the fault self-healing unit significantly improves application reliability; even if the underlying infrastructure fails, the application can automatically recover in a short time.

[0159] Fault types can include hardware failure, operating system crash, network outage, or resource exhaustion. Once a fault is confirmed to have occurred and cannot be recovered in place, the fault self-healing unit will immediately construct and send a scheduling request.

[0160] The aforementioned resource reclamation unit, used to release the target resource pool under preset conditions, can be understood as its responsibility being to perform resource release operations when specific conditions are met, returning the resources occupied in the target resource pool to the system. Release operations include deleting resource instances, clearing configuration data, and reclaiming network addresses and storage space. Released resources will re-enter the available resource pool and can be used by new scheduling requests. For example, in a video analytics application, when a user deletes the application through the management interface, the resource reclamation unit will receive a notification and then release all resources occupied by the application in sequence, including processor and memory resources on the server where the analytics component resides, storage resources occupied by the caching component, and storage volumes occupied by the database component.

[0161] The preset conditions include: deleting the application, or the end of the application's lifecycle. There are two main types of conditions that trigger resource reclamation. The first type is user-initiated deletion of the application, which is the most common manual reclamation scenario. The second type is the natural end of the application's lifecycle, which is an automatic reclamation scenario suitable for temporary or batch processing tasks.

[0162] In an exemplary embodiment, the status monitoring and recycling module further includes a profile update unit, which is used to update the status of the target resource pool in the global resource profile from an occupied state to an available state after the target resource pool is released.

[0163] The profile update unit ensures that the status information in the resource profile database remains strictly consistent with the availability of actual physical resources, and is a key link in forming a closed loop of resource management. Specifically, the profile update unit includes, but is not limited to, receiving notifications of resource reclamation completion, constructing status update requests, sending update instructions to the database, and verifying the success of the update operation.

[0164] The "occupied" state can be understood as a marker in the global resource profile indicating that a resource is currently being used by an application and cannot be allocated to other applications. Resources in the "occupied" state are already included in the quota of a running application, and the scheduler will automatically exclude these resources when making new scheduling decisions to avoid resource over-allocation and conflicts. Specifically, the "occupied" state includes, but is not limited to, resource occupancy markers at different granularities, such as a processor core being exclusively used by a virtual machine, a memory block being locked by a container process, a storage volume being mounted by a database service, and an accelerator being used by an inference task.

[0165] Availability status is a marker in the global resource profile indicating that a resource is currently idle and can be allocated to a new application. Resources in an available state are candidate targets for the scheduler during resource matching, from which the scheduler can select the most suitable resource to deploy new application components. Specifically, availability status includes, but is not limited to, availability markers for different scenarios such as completely idle servers, servers with some resources occupied but still having remaining capacity, and resources that have been reserved but not yet officially used.

[0166] This application provides a scheduling method applicable to the aforementioned scheduling system, such as... Figure 3 This is a flowchart illustrating the scheduling method, which includes the following steps:

[0167] Step S302: Parse the application requirement template to obtain an application profile, wherein the application profile includes: the components included in the application, the resource requirements of the application, and the strategy requirements of the application.

[0168] Step S304: Collect resource information from different types of resource pools, and generate a global resource profile based on the resource information;

[0169] Step S306: Determine the target resource pool for the component based on the application profile and the global resource profile;

[0170] Step S308: Deploy the target resources for the application.

[0171] In an exemplary embodiment, before parsing the application requirement template, the method further includes: converting the application's requirements into the application requirement template, wherein the application requirement template includes the application's components, the application's resource requirements, and the application's strategy requirements, and the application requirement template is a text file obtained based on a markup language; parsing the application requirement template to convert it into the application profile, wherein the application profile is a data object that can be directly used by the global scheduler.

[0172] In an exemplary embodiment, before parsing the application requirement template, the method further includes: filtering and querying the global resource profile based on the hard requirements in the application profile to obtain a candidate resource pool list, wherein the resource requirements and / or the policy requirements include the hard requirements, and the candidate resource pool list includes at least one candidate resource pool; and determining the target resource pool based on the application profile and the scheduling policy library in the candidate resource pool list.

[0173] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0174] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above-described scheduling method embodiments.

[0175] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described scheduling method embodiments at runtime.

[0176] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0177] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described scheduling method embodiments.

[0178] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described scheduling method embodiments.

[0179] Any of the components, modules, units, parts, methods, and operations described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or any combination thereof. Alternatively or additionally, any functionality described herein can be executed at least in part by one or more hardware logic components, such as, but not limited to, a central processing unit (CPU), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), an application-specific standard product (ASSP), a system-on-a-chip (SoC), a complex programmable logic device (CPLD), a microprocessor (MCU), etc. The terms "system," "computing device," or "apparatus" as used herein encompass various means, devices, and machines for processing data, including, for example, one or more programmable processors, computers, SoCs, or combinations thereof. The apparatus may also include code that creates an execution environment for the computer program in question, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or one or more combinations thereof. The aforementioned computer program (also known as a program, software, software application, app, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, including as a standalone program or as a module, component, subroutine, object, or other unit suitable for a computing environment.

[0180] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0181] The scheduling system and method provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make several improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A scheduling system, characterized in that, include: The application consists of an intent perception and modeling layer, a global resource profiling and abstraction layer, a multi-level intelligent scheduling and decision-making layer, and a resource supply and lifecycle management layer. The application intent perception and modeling layer is used to parse the application requirement template to obtain the application profile, wherein the application profile includes: the components included in the application, the resource requirements of the application, and the strategy requirements of the application. The global resource profile and abstraction layer is used to collect resource information from different types of resource pools and generate a global resource profile based on the resource information. A multi-level intelligent scheduling decision layer is used to determine the target resource pool for the component based on the application profile and the global resource profile. The resource supply and lifecycle management layer is used to deploy the target resources for the application.

2. The system according to claim 1, characterized in that, The application intent perception and modeling layer includes: The first conversion module is used to convert the application's requirements into an application requirement template, wherein the application requirement template includes the application's components, the application's resource requirements, and the application's strategy requirements, and the application requirement template is a text file obtained based on a markup language; An intent parsing engine is used to parse the application requirement template and convert it into the application profile, wherein the application profile is a data object that can be directly used by the global scheduler.

3. The system according to claim 1 or 2, characterized in that, The application's resource requirements include at least one of the following: computing resources, storage resources, network resources, and hardware resources; the policy requirements include at least one of the following: quality of service level, topology relationship between components, data sovereignty, and cost and power consumption budget.

4. The system according to claim 1, characterized in that, The global resource profiling and abstraction layer includes: A resource information collector communicates with a resource pool of a corresponding type via an adapter to obtain resource information from the resource pool.

5. The system according to claim 4, characterized in that, The adapter includes at least one of the following: virtualization platform adapter, container orchestration system adapter, bare metal management adapter, and hardware adapter.

6. The system according to claim 4 or 5, characterized in that, The resource information collector communicates with a resource pool of the corresponding type via an adapter to obtain resource information from the resource pool, including: The resource information collector communicates with a corresponding type of resource pool through the adapter at a preset period to obtain resource information from the resource pool; or... The resource information collector communicates with the corresponding type of resource pool through the adapter according to the subscription event to obtain resource information in the resource pool.

7. The system according to claim 1, characterized in that, The global resource profiling and abstraction layer also includes: The second conversion module is used to convert the resource information obtained from the resource pool into a unified resource model object, wherein the unified resource model object includes static attributes and dynamic attributes, the rate of change of resource information with the static attributes is less than or equal to a first rate of change threshold, and the rate of change of resource information with the dynamic attributes is greater than or equal to a second rate of change threshold.

8. The system according to claim 7, characterized in that, The global resource profiling and abstraction layer also includes: A global resource profile database is used to store the unified resource model object and generate the global resource profile based on the unified resource model object. The global resource profile database includes an in-memory database and a time-series database. The in-memory database is used to store the current snapshot of the unified resource model object, and the time-series database is used to store historical data of resource information with the dynamic attributes.

9. The system according to claim 1, characterized in that, The multi-level intelligent scheduling decision layer includes: A global scheduler is used to receive the application profile and filter and query the global resource profile based on the hard requirements in the application profile to obtain a list of candidate resource pools, wherein the resource requirements and / or the policy requirements include the hard requirements, and the list of candidate resource pools includes at least one candidate resource pool. A resource pool scheduler is used to receive the application profile and the candidate resource pool list, and determine the target resource pool from the candidate resource pool list based on the application profile and the scheduling strategy library.

10. The system according to claim 9, characterized in that, The scheduling strategy library includes at least one of the following strategies: affinity / anti-affinity strategy, binning strategy, distribution strategy, cost-first strategy, quality of service-first strategy, and power-first strategy.

11. The system according to claim 10, characterized in that, The affinity / anti-affinity strategy is used to query the topology information in the global resource profile and deploy related components on the corresponding servers based on the topology information, wherein the target resource pool includes the servers; The packing strategy is used to deploy new workloads to target servers, wherein the target servers already have workloads deployed and their resource utilization is less than or equal to a preset threshold, and wherein the target resource pool includes the target servers. The distributed strategy is used to deploy different instances of the same application in different fault domains, wherein the fault domains include: physical hosts, racks, and power lines; The cost-first strategy is used to select the resource with the lowest cost based on the resource cost information in the global resource profile; The power consumption priority strategy is used to select the resource with the lowest power consumption based on the power consumption data in the global resource profile.

12. The system according to claim 1, characterized in that, The resource supply and lifecycle management layer includes: A unified resource adapter is used to call the corresponding script file according to the type of resources in the target resource pool, wherein the script file is used to deploy the resources; The resource deployment and configuration module is used to deploy the target resource pool for the application and send a confirmation message to the global resource profile after deployment is completed.

13. The system according to claim 1, characterized in that, The resource supply and lifecycle management layer includes: a status monitoring and recycling module, which includes: The fault self-healing unit is used to trigger a scheduling request to request the update of the server where the application is deployed when a fault is detected in the server. A resource recycling unit is used to release the target resource pool when preset conditions are met, wherein the preset conditions include: deleting the application, or the end of the application's lifecycle.

14. The system according to claim 13, characterized in that, The status monitoring and recycling module also includes a profile update unit, which is used to update the status of the target resource pool in the global resource profile from occupied to available after the target resource pool is released.

15. A scheduling method, characterized in that, The method, applied to the scheduling system according to any one of claims 1 to 14, comprises: The application requirement template is parsed to obtain an application profile, which includes: the components included in the application, the resource requirements of the application, and the strategy requirements of the application. Collect resource information from different types of resource pools, and generate a global resource profile based on the resource information; Based on the application profile and the global resource profile, a target resource pool is determined for the component; Deploy the target resources for the application.

16. The method according to claim 15, characterized in that, Before parsing the application requirement template, the method further includes: The application's requirements are converted into an application requirement template, which includes the application's components, resource requirements, and strategy requirements. The application requirement template is a text file obtained based on a markup language. The application requirement template is parsed and converted into the application profile, wherein the application profile is a data object that can be directly used by the global scheduler.

17. The method according to claim 15, characterized in that, Before parsing the application requirement template, the method further includes: Based on the hard requirements in the application profile, the global resource profile is filtered and queried to obtain a candidate resource pool list, wherein the resource requirements and / or the strategy requirements include the hard requirements, and the candidate resource pool list includes at least one candidate resource pool. Based on the application profile and scheduling strategy library, the target resource pool is determined from the list of candidate resource pools.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the method described in any one of claims 15 to 17.

19. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method described in any one of claims 15 to 17.

20. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it performs the steps of the method described in any one of claims 15 to 17.

Images