A method, device, medium, and product for scheduling heterogeneous resources in a cloud data center.

Abstract

This invention discloses a method, device, medium, and product for heterogeneous resource scheduling in cloud data centers, relating to the field of cloud computing technology. The method includes: receiving a scheduling task for an application instance containing source architecture resource information; filtering processing nodes based on the computing power requirements of the application instance and the specification baseline values ​​of the processing nodes, and determining candidate nodes based on the filtering results; constructing an application performance profile of the application instance based on its performance data; determining the equivalent resource configuration corresponding to the application instance on the candidate nodes based on the application performance profile and the scheduling task, determining a score based on the equivalent resource configuration and specification baseline values, and determining the target node based on the score; modifying the resource request of the application instance based on the equivalent resource configuration to obtain the modified resource request, and deploying the application instance to the target node so that the target node can perform resource configuration based on the modified resource request, thus completing the heterogeneous resource scheduling. This achieves equivalent quantification and intelligent scheduling of heterogeneous resources.

Description

Technical Field

[0001] This invention relates to the field of cloud computing technology, and in particular to a method, device, medium and product for scheduling heterogeneous resources in a cloud data center. Background Technology

[0002] With the rapid development of cloud computing technology, the server hardware architecture of data centers is moving from the era dominated by the single x86 architecture to the era of heterogeneous computing with "one cloud, multiple chips". New processors, represented by the ARM (Advanced RISC Machine, a processor using a reduced instruction set architecture) architecture, are increasingly widely used in cloud data centers due to their advantages in energy consumption, cost, and core density. In addition, dedicated acceleration chips such as GPUs (Graphics Processing Units) and NPUs (Neural-network Processing Units) for specific scenarios such as Artificial Intelligence (AI) and big data analysis have also become indispensable components of cloud platforms.

[0003] This environment of heterogeneous hardware brings flexibility and cost-effectiveness to cloud platforms, but it also introduces unprecedented complexity. Processors with different architectures vary greatly in microarchitecture, instruction sets, and core performance; the actual computing power of an x86 core and an ARM core is not equivalent. Traditional cloud management and resource scheduling systems typically use the number of CPU (Central Processing Unit) cores and memory size as the atomic units for resource allocation. This "same name, different quality" metric leads to a series of problems in heterogeneous environments.

[0004] 1. Inaccurate resource assessment: The inability to accurately measure the true computing power of nodes with different architectures leads to a distortion in the value assessment of the resource pool.

[0005] 2. Unstable application performance: When applications migrate between nodes with different architectures or undergo hybrid scaling, severe performance fluctuations may occur due to unequal computing power, which may violate the service level agreement (SLA).

[0006] 3. High operational complexity: Development and operations personnel need to rely on a lot of experience and tedious manual testing to manually set and adjust resource quotas for nodes with different architectures, which is inefficient and prone to errors.

[0007] 4. Low resource utilization: Due to concerns about performance not meeting standards, administrators often adopt a conservative strategy of over-provisioning, resulting in serious waste of resources.

[0008] It is evident that how to address issues such as inaccurate resource assessment, application migration, and performance fluctuations during scaling up and down caused by hardware differences in cloud computing environments with heterogeneous processor architectures is a matter that those skilled in the art need to consider. Summary of the Invention

[0009] The purpose of this invention is to provide a method, device, medium, and product for heterogeneous resource scheduling in cloud data centers. This method enables accurate measurement and equivalent mapping of computing resources with different architectures, addressing issues such as inaccurate resource assessment, application migration, and performance fluctuations during scaling up and down in cloud computing environments with coexisting heterogeneous processor architectures. The specific solution is as follows.

[0010] In a first aspect, the present invention discloses a method for scheduling heterogeneous resources in a cloud data center, comprising:

[0011] The task receives the scheduling information of the application instance containing source architecture resource information, including source resource configuration and source architecture type.

[0012] Processing nodes are screened based on the computing power requirements of application instances in the cloud data center and the specification benchmark values ​​of processing nodes. Candidate nodes are determined based on the screening results. The specification benchmark values ​​are benchmark values ​​used to characterize the processing performance of processing nodes.

[0013] By running application instances on candidate nodes with different resource configurations and architectures, performance data of the application instances is obtained, and application performance profiles of the application instances are constructed based on the performance data; the application performance profile is a profile used to characterize the mapping relationship between resource configuration, architecture and performance data.

[0014] Based on the application performance profile and scheduling tasks, determine the equivalent resource configuration corresponding to the application instance to be deployed on the candidate nodes, determine the score of each candidate node based on the equivalent resource configuration and specification benchmark value, and determine the target node based on the score;

[0015] The application instance's resource request is modified based on the equivalent resource configuration to obtain the modified resource request. The application instance is then deployed to the target node so that the target node can configure resources based on the modified resource request to complete the heterogeneous resource scheduling of the cloud data center.

[0016] Optionally, before selecting processing nodes based on the computing power requirements of application instances in the cloud data center and the specification benchmarks of processing nodes, the following steps are also included:

[0017] The processing node is tested according to the preset test type, target parameters, operating environment, and number of repetitions to obtain the corresponding test parameters; the target parameters include any one or a combination of several of the following: number of threads, data size, and duration; the test parameters include CPU throughput, memory bandwidth, number of read / write operations per second, and network latency.

[0018] The test parameters are converted into standardized scores based on preset parameter benchmark values;

[0019] The standardized scores are weighted to obtain the baseline score of the architecture performance of the processing node;

[0020] Collect the hardware specifications of the processing nodes; the hardware specifications include the number of physical cores, the number of logical cores, and the clock speed of the central processing unit.

[0021] Determine the first product between the various hardware specification parameters;

[0022] The CPU component score is determined based on the second product between the first product and the architecture performance baseline score.

[0023] The memory score is determined based on the memory capacity and memory bandwidth of the processing node.

[0024] The input / output sub-scores are determined based on the storage type and storage performance of the processing node;

[0025] Specification baseline values ​​are determined based on the CPU score, memory score, and input / output score.

[0026] Optionally, specification baseline values ​​are determined based on CPU sub-scores, memory sub-scores, and I / O sub-scores, including:

[0027] The scores for the central processing unit, memory, and input / output components are normalized to obtain normalized scores.

[0028] The normalized scores are then weighted and averaged to obtain the specification baseline value.

[0029] Optionally, processing nodes are screened based on the computing power requirements of application instances in the cloud data center and the baseline specifications of processing nodes. Candidate nodes are determined based on the screening results, including:

[0030] Determine whether the architecture label of the processing node meets the preset architecture label requirements of the application instance, and obtain the first determination result;

[0031] Determine whether the specification baseline value of the processing node meets the preset specification baseline value requirements of the application instance, and obtain the second judgment result;

[0032] Based on the first and second judgment results, the processing nodes are screened to determine the processing nodes that meet the preset architecture label requirements and the preset specification benchmark value requirements as candidate nodes.

[0033] Optionally, an application performance profile of the application instance can be constructed based on the performance data, including:

[0034] A pre-defined prediction model is trained using performance data to obtain a well-trained prediction model; the pre-defined prediction model is either a linear regression model or a nonlinear model.

[0035] The trained prediction model is used to create an application performance profile for the application instance.

[0036] Optionally, based on the application performance profile and scheduled tasks, determine the equivalent resource configuration corresponding to deploying application instances on candidate nodes, including:

[0037] The current resource configuration for deploying application instances on candidate nodes is determined based on the specification baseline values ​​of the processing nodes and the application performance profile.

[0038] Based on the current resource configuration, launch several probe instances on the candidate nodes to obtain the corresponding performance data; the performance data includes application layer performance metrics and resource utilization; the application layer performance metrics include ticks per second and latency;

[0039] The loss value is determined by the ratio of the difference between the performance target and the performance data of the application instance in the source environment to the performance target.

[0040] If the loss value is greater than the preset threshold, the current resource configuration will be adjusted based on the coordinate descent method or the gradient step size adjustment method to obtain a new resource configuration.

[0041] The new resource configuration is determined as the current resource configuration, and the process jumps back to the step of starting several probe instances on the candidate node according to the current resource configuration until the loss value is less than the preset threshold.

[0042] The current resource configuration is determined as the equivalent resource configuration for deploying application instances on candidate nodes.

[0043] Optionally, after determining the current resource configuration as the equivalent resource configuration for deploying application instances on candidate nodes, the following may also be included:

[0044] The mapping relationship between equivalent resource configurations, corresponding candidate nodes, and application instances is stored in a preset mapping library.

[0045] Optionally, before launching several probe instances on candidate nodes based on the current resource configuration, the following steps are also included:

[0046] The initial prediction model is trained using historical data from a pre-defined mapping library to obtain the target prediction model;

[0047] The target prediction model is used to determine the current resource configuration based on the type of application instance, source resource configuration, and source architecture type.

[0048] Optionally, before determining the equivalent resource configuration corresponding to deploying application instances on candidate nodes based on application performance profiles and scheduling tasks, the following steps are also included:

[0049] Based on the application performance profile, determine whether there is a target mapping relationship in the preset mapping library that corresponds to the candidate node and the application instance;

[0050] If it exists, the equivalent resource configuration corresponding to the application instance deployed on the candidate node is determined directly based on the target mapping relationship;

[0051] If it does not exist, the operation of determining the equivalent resource configuration corresponding to the application instance to be deployed on the candidate node is triggered based on the application performance profile and scheduling task.

[0052] Optionally, before determining the score of each candidate node based on equivalent resource allocation and specification baseline values, the following steps are also included:

[0053] Test cases with different resource dimensions are run on bare metal and in virtual machines or containers to obtain corresponding test performance data; resource dimensions include CPU, memory, storage, network, and latency.

[0054] The target cost coefficient is obtained by performing a weighted average on the performance data of each test.

[0055] Optionally, the score for each candidate node is determined based on equivalent resource allocation and specification baseline values, including:

[0056] Determine the first difference between 1 and the target cost coefficient;

[0057] Determine the second difference between 1 and the preset load factor;

[0058] The effective reference value is determined based on the product of the specification reference value, the first difference, and the second difference;

[0059] The scores of each candidate node are determined based on equivalent resource allocation and effective benchmark values.

[0060] Optionally, the score of each candidate node is determined based on equivalent resource allocation and effective benchmark values, including:

[0061] Determine whether the resource configuration of each candidate node satisfies the requirement of equivalent resource allocation;

[0062] Candidate nodes that meet the requirements for equivalent resource allocation are identified as target candidate nodes;

[0063] The effective benchmark value of the target candidate node is determined as the score of each target candidate node.

[0064] Optionally, target nodes can be determined based on scores, including:

[0065] The target candidate node with the highest score among the target candidate nodes is determined as the target node.

[0066] Optionally, the heterogeneous resource scheduling method for cloud data centers also includes:

[0067] During resource scheduling, a dual-write data mode is initiated so that the target node can configure resources based on the dual-write data mode and the modified resource request.

[0068] Optionally, the heterogeneous resource scheduling method for cloud data centers also includes:

[0069] Analyze the load changes of application instances within the target time period to obtain the corresponding periodic patterns and the load trends corresponding to the periodic patterns;

[0070] Based on periodic patterns and load trends, predict the resource demand curve of application instances for a future preset time period;

[0071] Adjust the resource configuration of application instances according to the resource demand curve to expand or shrink the application instances.

[0072] Optionally, the heterogeneous resource scheduling method for cloud data centers also includes:

[0073] Compile multiple binaries or container images for different architectures so that when deploying application instances to target nodes, the appropriate container image is determined based on the target node's architecture, thus ensuring the correct version for the architecture.

[0074] Optionally, the heterogeneous resource scheduling method for cloud data centers also includes:

[0075] All data during resource scheduling operations is transmitted in encrypted form.

[0076] In a second aspect, the present invention discloses an electronic device, comprising:

[0077] Memory, used to store computer programs;

[0078] A processor is used to execute computer programs to implement the steps of the heterogeneous resource scheduling method for cloud data centers as described above.

[0079] Thirdly, the present invention discloses a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the aforementioned heterogeneous resource scheduling method for cloud data centers.

[0080] Fourthly, the present invention discloses a computer program product, including a computer program / instruction, which, when executed by a processor, implements the steps of the aforementioned heterogeneous resource scheduling method for cloud data centers.

[0081] This invention first receives a scheduling task for an application instance containing source architecture resource information; the source architecture resource information includes source resource configuration and source architecture type; processing nodes are screened based on the computing power requirements of the application instance in the cloud data center and the specification benchmark value of the processing node, and candidate nodes are determined according to the corresponding screening results; the specification benchmark value is a benchmark value used to characterize the processing performance of the processing node; by running the application instance on candidate nodes with different resource configurations and different architectures, the performance data of the application instance is obtained, and an application performance profile of the application instance is constructed based on the performance data; the application performance profile is a profile used to characterize the mapping relationship between resource configuration, architecture and performance data; then, based on the application performance profile and the scheduling task, the equivalent resource configuration corresponding to the application instance deployed on the candidate node is determined, the score of each candidate node is determined based on the equivalent resource configuration and the specification benchmark value, and the target node is determined based on the score; finally, the resource request of the application instance is modified based on the equivalent resource configuration to obtain the modified resource request, and the application instance is deployed to the target node so that the target node can perform resource configuration based on the modified resource request to complete the heterogeneous resource scheduling of the cloud data center.

[0082] Beneficial Effects: This invention first filters nodes, then establishes a business computing power profile model for a specific business application by monitoring its key performance indicators under different resource configurations. Using this model, it determines the equivalent resource configuration for deploying application instances on the filtered nodes. Finally, based on the equivalent resource configuration, the application instances are deployed on the target heterogeneous architecture. This precise business computing power quantification and equivalent mapping ensures that key performance indicators (such as transaction processing volume and response latency) remain stable when applications migrate, deploy, or elastically scale across heterogeneous hardware. By allocating resources through scientific measurement rather than blind guessing, this invention provides applications with "just the right" computing power on demand, effectively avoiding the over-allocation of resources commonly found in traditional methods. Attached Figure Description

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

[0084] Figure 1 A flowchart of a heterogeneous resource scheduling method for a cloud data center provided in an embodiment of the present invention;

[0085] Figure 2 This is a structural diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

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

[0087] The terms "comprising" and "having," and any variations thereof, in the specification and accompanying drawings of this invention are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the steps or units listed, but may include steps or units not listed.

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

[0089] Some technologies can only achieve simple identification and isolation of heterogeneous hardware, or can only perform offline theoretical performance evaluation, or lack awareness of the inequality of computing power in dynamic management. None of them provide a systematic, feedback-driven solution deeply integrated with cloud platform management to automatically achieve equivalence quantification, performance prediction, and intelligent scheduling of heterogeneous computing resources. To address these technical problems, this invention discloses a method, device, medium, and product for heterogeneous resource scheduling in cloud data centers. This method can achieve accurate measurement and equivalence mapping of computing resources with different architectures, solving problems such as inaccurate resource evaluation, application migration, and performance fluctuations during scaling up and down caused by hardware differences in cloud computing environments with coexisting heterogeneous processor architectures.

[0090] See Figure 1 As shown in the figure, this embodiment of the invention provides a heterogeneous resource scheduling method for cloud data centers, including the following steps.

[0091] Step S11: Receive the scheduling task of the application instance containing source architecture resource information; the source architecture resource information includes source resource configuration and source architecture type.

[0092] In this embodiment of the invention, a scheduling task for an application instance containing source architecture resource information is first received, wherein the source architecture resource information includes source resource configuration and source architecture type.

[0093] Step S12: Screen the processing nodes according to the computing power requirements of the application instances in the cloud data center and the specification benchmark values ​​of the processing nodes, and determine the candidate nodes according to the corresponding screening results; the specification benchmark values ​​are benchmark values ​​used to characterize the processing performance of the processing nodes.

[0094] In this embodiment of the invention, during the node screening stage of the scheduling process, nodes that do not meet the conditions are filtered out based on the node's architecture label and specifications / computing power. Before selecting processing nodes based on the computing power requirements of application instances in the cloud data center and the baseline specifications of the processing nodes, the processing nodes are tested according to preset test types, target parameters, operating environments, and repetition counts to obtain corresponding test parameters. Target parameters include any combination of one or more of the following: number of threads, data size, and duration. Test parameters include CPU throughput, memory bandwidth, storage read / write operations per second, and network latency. The test parameters are converted into standardized scores based on the preset baseline parameters. The standardized scores are weighted to obtain the baseline architectural performance score of the processing node. The hardware specifications of the processing nodes are collected, including the number of physical cores, logical cores, and clock speed of the CPU. The first product between the hardware specifications is determined. The CPU sub-score is determined based on the second product between the first product and the baseline architectural performance score. The memory sub-score is determined based on the memory capacity and memory bandwidth of the processing node. The input / output sub-score is determined based on the storage type and storage performance of the processing node. The baseline specifications are determined based on the CPU sub-score, memory sub-score, and input / output sub-score. Next, the scores for the CPU, memory, and input / output components are normalized to obtain normalized scores; then, a weighted average is taken from the normalized scores to obtain the specification baseline value.

[0095] Specifically, this invention designs and implements a core component—the Equivalent Computing Power Management Service—within the Cloud Management Platform. This service is the brain of the entire system, responsible for executing the core logic of computing power quantification, maintaining various data models, and providing decision support to upper-layer scheduling and automation systems. It consists of multiple collaborative internal modules. Among them, the Dynamic Heterogeneous Feature Perceiver: Function: This module is the system's data input source, responsible for actively detecting and collecting the hardware and platform characteristics of all nodes in the entire heterogeneous resource pool. It periodically scans the physical servers in the cluster, obtaining detailed specification information of the resource layer, such as the CPU model, number of cores, cache, instruction set, etc., by interacting with the underlying firmware (such as IPMI / Redfish) or host operating system. At the same time, it also detects the type and version of the hypervisor or container runtime running on the nodes, collecting relevant information at the platform layer. Implementation: Data can be deployed as a lightweight agent on each physical node, or it can be remotely queried via a centralized management node in an agentless manner. The collected data is formatted and standardized before being sent to resource tags and the topology manager for storage. Furthermore, to quickly and systematically evaluate the baseline performance of nodes with different architectures, this invention includes a scalable micro-benchmark library. This library incorporates various types of standardized test loads to simulate different computing scenarios. Test Types:

[0096] CPU-intensive tests: such as performing a large number of floating-point operations, encryption / decryption calculations, or data compression algorithms, to evaluate the CPU's raw computing power.

[0097] Memory-intensive tests: such as performing large-scale random memory reads and writes or linked list traversals to evaluate memory bandwidth and latency.

[0098] I / O-intensive tests: such as performing high-concurrency file read / write or network packet transmission / reception to evaluate storage and network performance.

[0099] Purpose: When a new node joins the cluster, or when the platform overhead of existing nodes needs to be calibrated, the Computing Power Equivalence Management Service triggers one or more test tasks from the micro-benchmark library to quickly derive the node's performance baseline score under different scenarios. These scores are crucial for calculating "specification computing power" and "effective computing power." When calculating the performance baseline score, firstly, a test task is triggered: When a new node joins or recalibration is required, the Computing Power Equivalence Management Service issues a benchmark test task to the target node, executing one or more rounds of testing in bare metal / virtual machine (VM) / container environments. Each task is bound to: test type (CPU / memory / storage IO / network), parameters (number of threads / data size / duration), runtime environment (bare / virt), and number of repetitions N. Raw Metrics are collected: Each type of micro-benchmark produces one or more quantifiable metrics.

[0100] CPU: Throughput (ops / s), compression / encryption throughput, etc. (the higher the better);

[0101] Memory: Bandwidth (GB / s), Latency (ns) (higher bandwidth is better, lower latency is better);

[0102] Storage: IOPS (Input / Output Operations Per Second), Throughput (MB / s), P99 Latency (Percentile-99).

[0103] Network: Throughput (Gbps), RTT / P99 latency;

[0104] For each metric, a stable statistical value is obtained. The original metrics are converted to "normalization": the goal is to transform metrics with different dimensions into comparable "scores" ranging from 0 to 100 (or 0 to 1). The normalized scores are then weighted to obtain the baseline score for the architecture performance of the processing nodes.

[0105] In addition, this invention constructs a standardized indicator system that includes three dimensions: hardware performance, platform overhead, and business performance.

[0106] Hardware performance metrics:

[0107] CPU metrics:

[0108] Core Frequency: Base frequency and maximum turbo boost (Turbo Boost / Precision Boost).

[0109] Core Count: The number of physical cores and the number of logical cores (through technologies such as Hyper-Threading).

[0110] Cache Hierarchy & Size: The capacity and correlation of L1, L2, and L3 caches.

[0111] Instruction Set Support: Such as SIMD (Single Instruction, Multiple Data) instruction sets (AVX series for x86, NEON for ARM), which have a significant impact on certain computationally intensive applications.

[0112] IPC (Instructions Per Clock): The number of instructions executed per clock cycle. This is a core metric for measuring the efficiency of a CPU microarchitecture, and it is usually estimated using specialized benchmarking tools.

[0113] Memory metrics:

[0114] Bandwidth: Memory read / write bandwidth (GB / s) measured using tools such as stream.

[0115] Latency: Memory access latency (ns).

[0116] Storage I / O metrics:

[0117] IOPS (Input / Output Operations Per Second): Random read / write IOPS measured using tools such as fio.

[0118] Throughput: Sequential read / write bandwidth (MB / s).

[0119] Network metrics:

[0120] Bandwidth: Network throughput (Gbps) measured using tools such as iperf.

[0121] Latency: Network round-trip time (RTT).

[0122] "Specification computing power" is the first hurdle in scheduling, used to quickly and roughly rank nodes based on their theoretical performance. This invention proposes a computational model based on coefficients, normalization, and weighted adjustments.

[0123] Model formula:

[0124] ;

[0125] Wherein: Node_Spec_Score is the node's final specification computing power score. W_cpu, W_mem, and W_io are the weights for CPU, memory, and I / O, respectively. These weights can be configured by the administrator based on the cluster's primary application type. For example, for compute-intensive clusters, W_cpu can be set higher.

[0126] Norm_CPU, Norm_Mem, and Norm_IO are the normalized scores for each component.

[0127] CPU score calculation (Norm_CPU):

[0128] CPU_Score=Core_Count*Clock_Speed*Arch_Coefficient*ISA_Bonus;

[0129] Core_Count: Number of cores; Clock_Speed: Base clock speed; Arch_Coefficient (architecture performance baseline score): This is the key to the model. The system maintains an architecture coefficient table, where the coefficients are tested using the aforementioned micro-benchmark library and updated periodically.

[0130] ISA_Bonus (Instruction Set Bonus): If the node supports an instruction set (such as AVX-512) that provides a significant speedup for a specific workload, an additional bonus factor (e.g., 1.05) can be obtained.

[0131] After calculating the scores for each component of all nodes, normalization is required to map them to a uniform range (e.g., 0-100) to eliminate dimensional differences. For example, a maximum-minimum normalization method can be used: Norm_Score = (Current_Score - Min_Score) / (Max_Score - Min_Score) * 100. Although this power model is relatively coarse, its computational cost is extremely low. It can quickly filter out a large number of unsuitable nodes when the scheduler performs large-scale node screening, making it an effective tool for initial scheduling and resource screening.

[0132] In the standard scheduling process, the scheduler primarily makes decisions based on the remaining CPU and memory on a node. This plugin enhances this by enabling it to understand and utilize the higher-dimensional metric of "computing power." When a new application instance (typically called a Pod in container orchestration platforms) needs to be scheduled, nodes that do not meet the instance's computing power requirements are first filtered out. Architecture affinity / anti-affinity: Checks if the node's architecture tag (arch=x86_64 or arch=arm64) meets the instance's requirements. Specification computing power threshold: If the application specifies a minimum "specification computing power" requirement, nodes with a Node_Spec_Score below this threshold are filtered out. Custom capability tags: Nodes lacking the specific hardware capabilities required by the application (such as GPUs or specific instruction sets) are filtered out. Therefore, in the process of filtering nodes, the architecture label of the processing node is first determined to meet the preset architecture label requirements of the application instance, and a first judgment result is obtained; the specification baseline value of the processing node is determined to meet the preset specification baseline value requirements of the application instance, and a second judgment result is obtained; the processing nodes are filtered according to the first judgment result and the second judgment result, so that the processing nodes whose architecture label meets the preset architecture label requirements and whose specification baseline value meets the preset specification baseline value requirements are determined as candidate nodes.

[0133] Step S13: Run application instances on candidate nodes with different resource configurations and architectures to obtain application instance performance data, and construct application performance profiles of application instances based on the performance data; the application performance profile is a profile used to characterize the mapping relationship between resource configuration, architecture and performance data.

[0134] In this embodiment of the invention, performance data is collected by running applications on nodes with different resource configurations and architectures, thereby establishing a "resource-configuration-performance" profile. This profile reveals the sensitivity of a specific application to resources such as CPU and memory, as well as its performance differences across different hardware architectures. In this invention, a preset prediction model is trained using performance data to obtain a trained prediction model; the preset prediction model is either a linear regression model or a nonlinear model; the trained prediction model is then used to determine the application performance profile of the application instance. This invention utilizes statistical models such as time series analysis and multiple regression to establish a profile of the relationship between load and computing power. Establishing the application performance profile:

[0135] Data collection: Continuously collect performance data (P, such as TPS (Transactions Per Second)) of an application under different resource configurations (C CPUs, M GB memory).

[0136] Model training: Use the collected data (C, M, P) to train a prediction model P=f(C, M). This function f is the performance profile of the application.

[0137] Model form: f can be a simple linear regression model P=aC+bM+d, or a more complex nonlinear model (such as multinomial regression, support vector regression, etc.) to capture the performance saturation effect brought about by increased resources (that is, when resources increase to a certain extent, performance no longer increases linearly).

[0138] Utilizing a performance profile for calculation: Forward calculation: Given a resource configuration (e.g., 4C / 8G on an ARM architecture), the model can predict the approximate performance level the application can achieve (e.g., 1200 TPS). Backward calculation: Given a performance target (e.g., needing to reach 1500 TPS), the model can work backward to calculate how many resources are required. Since (C, M) is two-dimensional, there may be multiple solutions (e.g., 4C / 10G or 6C / 8G), and the system can choose based on the principle of optimal cost or resource utilization.

[0139] Step S14: Based on the application performance profile and scheduling tasks, determine the equivalent resource configuration corresponding to the application instance to be deployed on the candidate nodes, determine the score of each candidate node based on the equivalent resource configuration and specification benchmark value, and determine the target node based on the score.

[0140] In this embodiment of the invention, the current resource configuration for deploying application instances on candidate nodes is determined based on the specification baseline values ​​of the processing nodes and the application performance profile. Several probe instances are launched on the candidate nodes according to the current resource configuration to obtain corresponding performance data. The performance data includes application layer performance indicators and resource utilization. The application layer performance indicators include ticks per second and latency. A loss value is determined based on the ratio between the performance target and the performance data of the application instance in the source environment and the performance target. If the loss value is greater than a preset threshold, the current resource configuration is adjusted based on the coordinate descent method or the gradient step size adjustment method to obtain a new resource configuration. The new resource configuration is determined as the current resource configuration, and the process jumps back to the step of launching several probe instances on the candidate nodes according to the current resource configuration until the loss value is less than the preset threshold. The current resource configuration is determined as the equivalent resource configuration corresponding to deploying application instances on the candidate nodes. The computational power equivalence algorithm of this invention is responsible for answering the key question of "how to configure resources to achieve the same application performance on different architectures". This invention employs a feedback-driven equivalence mapping algorithm, which mimics the closed-loop feedback concept in cybernetics. Through an iterative cycle of "prediction-execution-measurement-adjustment," it gradually approaches and converges to the optimal equivalence resource allocation point. Algorithm flow:

[0141] 1. Initial Estimation: When a migration or scaling-up task is initiated, the algorithm first needs to provide an initial resource configuration for the target architecture. This estimation is primarily based on the "specification compute power" model. For example, if an application is currently running on 2 x86 cores with a specification compute power coefficient of 1.0, and the target ARM core coefficient is 0.8, the algorithm will initially estimate the required number of ARM cores to be 2*(1.0 / 0.8) = 2.5, and recommend using 3 ARM cores based on a strategy (such as rounding up). Other resource configurations, such as memory, remain initially unchanged.

[0142] 2. Trial Run: Based on the initial estimated configuration, the system launches one or more "canary instances" on the nodes of the target architecture. These instances can be complete copies of the application or lightweight versions containing only core business logic, introducing a small amount of real or simulated traffic.

[0143] 3. Metrics Feedback: After the probe instance starts running, the monitoring and metric collection module begins collecting its application-layer performance metrics (such as TPS, latency) and resource utilization. This real-time performance data is fed back to the computing power equivalence algorithm core.

[0144] 4. Performance Comparison and Loss Calculation: The algorithm aligns with the same KPI and statistical window, comparing the performance of the probe instance with the performance baseline (or preset performance target) of the source instance, and calculates a "loss value". This loss value quantifies the gap between the current configuration and the expected performance. (The larger the gap, the larger the loss; if the target is met, Loss≈0). For example, the loss function can be defined as Loss=|Target_TPS-Current_TPS| / Target_TPS. Where, Loss: loss value / error ratio, used to quantify the gap between the current performance and the target performance (dimensionless). Target_TPS: target throughput (target transactions per second / requests), derived from the source instance's stable baseline TPS or preset performance target. Current_TPS: current throughput, i.e., the TPS measured by the probe instance under the target architecture / target configuration (aggregate value within the same statistical window). The performance baseline of the source instance is the business KPI (Key Performance Indicator) baseline applied in the source environment, used to define the "expected business performance". It is usually the TPS, P99 and other statistical values ​​of the source instance during the stable period.

[0145] 5. Configuration Iteration: If the loss value exceeds a preset tolerance threshold (e.g., 5%), the algorithm will initiate a configuration adjustment. It uses an intelligent search strategy to determine how to modify the configuration (increase / decrease CPU, memory, etc.).

[0146] Coordinate Descent: A simple and effective strategy is to adjust resources in only one dimension at a time. For example, first fix the memory, gradually increase the number of CPU cores, and observe the trend of TPS changes. When TPS reaches or exceeds the target, try fine-tuning the memory to find the most cost-effective configuration.

[0147] Gradient step size adaptation: To accelerate convergence, the algorithm can dynamically adjust the step size for each resource increment or decrement based on changes in the loss value. If the performance difference is large, the step size can be larger; when approaching the target, the step size should be reduced for fine-tuning.

[0148] 6. Convergence and Archiving: The above iterative process is repeated until the performance of the probe instance stably matches the target within an acceptable error range, i.e., the loss value is less than the threshold. At this point, the algorithm considers an equivalent resource configuration to have been found. This successful mapping relationship (e.g., application A, X862C / 4G <=> ARM3C / 4G, performance 1000TPS) will be recorded in the "equivalent mapping library" of the resource tag and topology manager for direct querying by future identical or similar applications, avoiding repeated iterations.

[0149] Furthermore, after determining the current resource configuration as the equivalent resource configuration for deploying application instances on candidate nodes, the mapping relationship between the equivalent resource configuration, the corresponding candidate nodes, and the application instances is stored in a preset mapping library. Then, the initial prediction model is trained using historical data in the preset mapping library to obtain the target prediction model; the current resource configuration is determined using the target prediction model based on the application instance type, source resource configuration, and source architecture type.

[0150] Specifically, to further reduce the number of online iterations and the time required, this invention also supports the introduction of machine learning models. By using historical data accumulated in the equivalence mapping library as a training set, a predictive model (such as a gradient boosting tree or neural network) can be trained. When a new request arrives, the model can quickly predict a highly accurate initial configuration based on the application type, source configuration, and target architecture. In this way, the feedback-driven iterative process may only require one or two fine-tuning adjustments, or even directly adopt the model's predictions, greatly improving mapping efficiency.

[0151] In addition, before determining the equivalent resource configuration corresponding to the application instance on the candidate node based on the application performance profile and scheduling task, the system determines whether there is a target mapping relationship between the candidate node and the application instance in the preset mapping library based on the application performance profile. If it exists, the system directly determines the equivalent resource configuration corresponding to the application instance on the candidate node based on the target mapping relationship. If it does not exist, the system triggers the operation of determining the equivalent resource configuration corresponding to the application instance on the candidate node based on the application performance profile and scheduling task. After triggering a clear computing power requirement, this requirement can come from various scenarios, such as: Application migration: The administrator or system decides to migrate an application A running on an x86 node to an ARM cluster. Elastic scaling: The load of application B increases, and HPA (Horizontal Pod Autoscaler) decides to add a replica for it, but the current architecture's resource pool is full, and a new replica needs to be created in a heterogeneous resource pool. New application deployment: The developer submits a new application C and specifies its performance goals. Requirement description generation: The system transforms these scenario-based requirements into a standardized "computing power requirement description". This description includes: application identifier, source architecture and configuration (if applicable), performance targets (such as TPS, latency), and target architecture type. The system first queries the "equivalence mapping library" to see if a verified mapping record exists for this application (or similar applications). If a match is found, for example, if the library already contains a record stating "Application A is performance-equivalent on X86 (2C / 4G) and ARM (3C / 4G)," then that configuration is directly adopted, greatly simplifying the process or ending it directly. Model prediction: If no historical records are available, model prediction is initiated. If the application already has a "business computing power" profile P=f(C,M), it can be solved directly. For example, given that on X86 P_x86=f_x86(2,4)=1000TPS, it is now necessary to find (C_arm, M_arm) on ARM such that f_arm(C_arm, M_arm)≈1000. The system can start from an initial point and use optimization algorithms (such as gradient descent) to find a solution that satisfies the conditions.

[0152] In this embodiment of the invention, different virtualization technologies (such as KVM (Kernel-based Virtual Machine)) or container runtimes (such as Docker, containerd) consume a portion of computing resources and may introduce additional performance overhead. The platform layer quantifies this overhead by deploying standard micro-benchmarks. Platform Overhead Metrics include: Virtualization Overhead: CPU Overhead: Calculate the percentage performance loss by running the same CPU benchmark inside and outside the virtual machine. Memory Overhead: Memory occupied by the hypervisor itself, and the performance degradation of memory access caused by virtualization. I / O Virtualization Overhead: Especially for networking, the performance difference between SR-IOV (Single Root I / O Virtualization) and non-SR-IOV modes is significant and needs to be quantified separately. Containerization Overhead: Runtime Overhead: Resources consumed by the container runtime process (such as containerd-shim). Network Overhead: Additional packet / unpacking latency and CPU consumption introduced by container networking (such as overlay networks). Storage Overhead: Performance loss caused by container storage drivers. Business Performance Metrics: Throughput: such as TPS, QPS (Queries Per Second), messages processed per second. Latency: average response time, P95 / P99 quantile latency. Concurrency: maximum concurrent users, concurrent connections. Error Rate: percentage of requests that fail. For example, by running CPU-intensive, memory-intensive, and network I / O-intensive benchmark tests in virtual machines or containers, and comparing their performance with that running on bare metal, a "platform overhead coefficient" (target overhead coefficient) is derived. In this invention, test cases with different resource dimensions are run on bare metal and in virtual machines or containers respectively to obtain corresponding test performance data; resource dimensions include CPU, memory, storage, network, and latency; the target overhead coefficient is obtained by weighted averaging of each test performance data. Specifically, the Platform_Overhead_Factor = "performance difference of the same baseline load in bare metal vs virtualization / container environment", using a ratio of 0 to 1 to represent the overhead caused by virtualization / containers, which is used to discount Effective_Power.

[0153] 1) Individual expense coefficient (calculated separately for each resource dimension):

[0154] For each type of micro-benchmark (CPU / memory / network / storage I / O), the same workload was run on both bare metal and virtual machine / virt to obtain performance metrics.

[0155] 2) Summarize into platform overhead coefficients (output a total coefficient):

[0156] The overhead coefficients of each dimension are summed by weight (the weights can be configured according to the business type: CPU-intensive for compute-intensive and I / O-intensive for storage-intensive).

[0157] In this embodiment of the invention, effective computing power can be understood as a discounted value of the specified computing power after considering platform overhead and current node load. Effective_Power = Spec_Power * (1 - Platform_Overhead_Factor) * (1 - Current_Load_Factor); where Spec_Power is the specified computing power; Platform_Overhead_Factor: platform overhead coefficient, calculated by micro-benchmark tests at the platform layer. For example, a KVM virtualization environment may cause a 5% performance loss, so this coefficient is 0.05. Current_Load_Factor: current load factor, reflecting the resources already occupied by the node and its impact on the performance of new applications. This is not merely a linear deduction of resource utilization, as high load can also lead to resource contention (such as cache pollution, I / O queue waiting), requiring historical data analysis to model this non-linear impact. Therefore, this invention determines a first difference between 1 and the target overhead coefficient; determines a second difference between 1 and the preset load factor; determines an effective benchmark value based on the product of the specified benchmark value, the first difference, and the second difference; and determines the score of each candidate node based on equivalent resource allocation and the effective benchmark value.

[0158] Subsequently, during the process of determining the score of each candidate node based on equivalent resource configuration and effective benchmark value, it is determined whether the resource configuration of each candidate node meets the equivalent resource configuration; candidate nodes that meet the equivalent resource configuration are determined as target candidate nodes; and the effective benchmark value of the target candidate nodes is determined as the score of each target candidate node. Specifically, in the optimization phase, the scheduler scores all pre-selected candidate nodes and selects the node with the highest score. This invention introduces several new scoring plugins: Homogeneous priority: Nodes with the same architecture as the application instance are given high scores. This is because homogeneous scheduling does not require complex computing power conversion and has the lowest risk. Computing power score: The score is calculated based on the overall computing power of the node. For homogeneous nodes: "Effective computing power" is mainly considered. The score can be proportional to the remaining effective computing power of the node, tending to deploy the application on nodes with lower load and higher performance. For heterogeneous nodes: When there is no suitable homogeneous node, heterogeneous scheduling needs to be considered. At this time, the plugin will call the computing power equivalence management service to obtain the equivalent resource configuration required to deploy the instance on the heterogeneous node. It then checks whether the node has sufficient resources to satisfy this equivalent configuration. If so, its score will be calculated based on the effective computing power after satisfying the equivalence requirement.

[0159] Finally, the target candidate node with the highest score among the target candidate nodes is determined as the target node.

[0160] Step S15: Modify the resource request of the application instance based on the equivalent resource configuration to obtain the modified resource request, and deploy the application instance to the target node so that the target node can perform resource configuration based on the modified resource request to complete the heterogeneous resource scheduling of the cloud data center.

[0161] In this embodiment of the invention, after deciding to schedule to a heterogeneous node, a key action of the scheduling plugin is to dynamically modify the resource requests of the application instance. For example, for an x86 application requesting 2C / 4G, when scheduled to an ARM node, the plugin will query the mapping library or execute the mapping process to determine the equivalent configuration as 3C / 4G. Then, it will "dynamically" modify the resource requests of the instance to 3C / 4G before deployment. In some cases, if adjusting the specifications of a single instance cannot meet performance requirements, it can even suggest splitting a large instance into multiple smaller instances (adjusting the number of replicas) to ensure proper performance guarantees. After modification, the application instance is deployed to the target node so that the target node can configure resources based on the modified resource requests to complete the heterogeneous resource scheduling of the cloud data center.

[0162] When a smooth cross-architecture migration of a running application instance is required, the migration module invokes the Computational Equivalence Management Service. The service first determines the equivalent resource configuration of the target node, then pre-creates an instance "shell" with the corresponding configuration on the target node, and finally initiates the data synchronization and state migration process. This ensures that the application can immediately obtain the required performance guarantees after the switchover. Traditional elastic scaling is mainly based on CPU or memory utilization. This invention extends this to make decisions based on "business computing power." Computational power-aware scaling: When the monitoring system finds that the application's average TPS is lower than the target value, the elastic scaling module no longer simply adds a replica of the same specifications. It queries the Computational Equivalence Management Service: How much "business computing power" needs to be added to make up for the current TPS difference? The service returns one or more recommended scaling solutions, such as "adding a 3C / 4G replica on an ARM node" or "adding a 2C / 4G replica on an x86 node." The elastic scaling module executes the scaling operation according to these recommendations. Heterogeneous scaling: When the resource pool of one architecture is strained, this mechanism can seamlessly schedule new replicas to the resource pool of another architecture and automatically apply equivalent resource configurations, achieving true cross-architecture hybrid elastic scaling. Through this converged interface, computing power is seamlessly injected into the "nerve center" of the cloud platform—the scheduling and control system, enabling the entire platform's resource management and application delivery to have profound heterogeneity awareness and performance assurance capabilities.

[0163] Furthermore, to improve the concurrency and response speed of large-scale scaling, this invention supports a two-level scheduling mode. Local scheduling: Within a single physical node, if multiple instances need to be scaled up, the local scheduler can quickly place them in the allocated resource pool. Global scheduling: When scaling across nodes, racks, or even data centers is required, the global scheduler is responsible for making macro-level decisions, selecting the most suitable node or cluster, and distributing the scheduling task to the corresponding local scheduler for execution.

[0164] For stateful applications such as databases and distributed caches, the biggest challenge in cross-architecture migration and scaling lies in ensuring data consistency and service continuity. Traditional distributed consensus protocols typically assume that all nodes in the cluster have equal performance. In heterogeneous environments, this assumption does not hold. A weaker node can become the bottleneck of the entire cluster, leading to problems such as heartbeat timeouts and election failures. Dynamically Adjusting Protocol Parameters: This invention proposes an improved, architecture-aware distributed consensus protocol. The protocol's management module obtains the "effective computing power" score of each node in the cluster from the computing power equivalence management service. Heartbeat Timeout: For nodes with weaker computing power, their heartbeat timeout is appropriately relaxed to avoid being mistakenly judged as downtime due to temporary network or CPU fluctuations. Election Timeout: Similarly, the election timeout parameter is dynamically adjusted. Voting Strategy: In some consensus algorithms, a voting weight based on computing power can be introduced, allowing nodes with stronger performance to have greater influence in decision-making. Adjusting log replication throughput: In the leader-follower replication mode, the leader will dynamically adjust the rate at which logs are sent to different followers based on their computing power scores and network conditions. This avoids overwhelming the followers with poor performance while ensuring that high-performance followers can catch up as quickly as possible.

[0165] In this embodiment of the invention, during resource scheduling, a dual-write mode is initiated so that the target node can configure resources based on the dual-write mode and the modified resource requests. Consistency assurance during migration: Dual-Writing: At the start of migration, the application layer or proxy layer can temporarily enable dual-write mode, simultaneously writing new data to both source and target storage. Incremental replication: Simultaneously with dual-write, a background task is started to replicate historical data from the source to the target using incremental snapshots. Switching and verification: Once incremental replication catches up with real-time writing, the system briefly locks the write operation (usually at the millisecond level) for a final data synchronization verification, then switches traffic to the new application instance located on the target architecture, and finally shuts down the source instance and dual-write mode to complete the migration. Through these special designs for stateful applications, this invention ensures that in complex cross-architecture operations, not only is the application's computational performance guaranteed, but its core data state can also be safely and consistently migrated.

[0166] Furthermore, this invention continuously compares the predicted values ​​of the "business computing power model" with the actual performance values ​​of the application. For example, the model predicts that the TPS of application A should be 800 under a certain ARM configuration, but continuous monitoring shows that its actual TPS is stable at 600. This results in a significant deviation of 25%. This triggers online learning and model adjustment.

[0167] When the prediction deviation continues to exceed the preset threshold, the system will trigger an adaptive learning process.

[0168] Adjust the parameters of the equivalent model:

[0169] Fine-tuning coefficients: For a simple linear model P=aC+bM+d, the system can use algorithms such as online gradient descent to fine-tune the coefficients a, b, and d using new real data points (C,M,P_actual) to make the model closer to the real situation.

[0170] Retraining the model: For complex machine learning models, once enough new data has been accumulated, the system can periodically (e.g., every morning) or when significant model drift is detected, trigger a complete model retraining to generate a more accurate new model.

[0171] Adjust the weighting coefficients:

[0172] Scheduling weights: If the weight of a certain scoring item (such as "effective computing power") is found to be unreasonable in the scheduling decision, resulting in generally poor performance after application deployment, the system can learn to adjust the weights of different scoring items based on historical scheduling decisions and the final application performance.

[0173] Resource weights: In the "Specification Computing Power" model, the weights of CPU, memory, and I / O (W_cpu, W_mem, W_io) can be adaptively adjusted based on the main application types running on the cluster. For example, if monitoring reveals that most applications are memory-intensive, the system can automatically increase the weight of W_mem.

[0174] Adjusting scheduling priority: The system can dynamically adjust the priority of an application in the scheduling queue based on the application's service level agreement requirements. For high-priority applications that frequently fail to meet performance standards, the system will automatically increase their scheduling priority and may enable a more conservative resource allocation strategy for them (e.g., assigning them a more powerful node or providing more resource redundancy).

[0175] Real-time feedback is sent to the execution module:

[0176] All adjusted model parameters, weights, and priorities will be pushed and applied in real time to the computing power equivalence management service, scheduler, and elastic scaling module, immediately affecting subsequent resource decisions.

[0177] In this embodiment of the invention, the load changes of application instances within a target time period are analyzed to obtain the corresponding periodic patterns and load trends. Based on the periodic patterns and load trends, the resource demand curve of the application instances in a future preset time period is predicted. The resource configuration of the application instances is adjusted accordingly based on the resource demand curve to achieve scaling up or down the application instances. This invention analyzes the load change patterns of each application in the past (e.g., several weeks or months) to identify its periodic patterns. Periodicity identification: For example, the load of an e-commerce application may peak between 8-10 pm every day and have another peak on weekends. A report generation application may experience a computation peak at 9 am every weekday. Trend analysis: Analyzing whether the application load is generally trending upwards, downwards, or remaining stable. Combining the identified historical patterns with the calendar of future business activities (e.g., the known "Double Eleven" promotion), the prediction module can generate a resource demand curve for a future period (e.g., the next week) at an hourly or daily granularity. Resource Tiering: The system tiers predicted resource demands, such as "baseline resources" (for daily operation), "periodic peak resources," and "reserved resources for sudden traffic surges." Peak / Valley Warming: Before predicted traffic peaks arrive, the system automatically executes the aforementioned "scaling up / down and warming-up strategies," preparing sufficient pre-warmed application instances. During predicted low traffic periods, the number of instances can be safely reduced to save costs. Ensuring TPS Linearity: Through accurate prediction and proactive warming-up, the system ensures that application TPS grows linearly with rapid traffic growth, preventing performance inflection points or service degradation due to untimely resource preparation. The entire scaling up / down process is smooth and imperceptible to users, with performance errors controlled within a minimal range.

[0178] To break down barriers between different vendors and platforms and achieve standardized interconnectivity of computing power resources, this invention proposes a unified computing power description standard and API (Application Programming Interface) specification. Unified Computing Power Description Standard: Purpose: To define a standardized data model for describing computing power, independent of specific hardware and platforms. Any hardware vendor or cloud platform can map its resources to this standard model. Computing Power Metrics Set: Standardizes the names, units, and calculation methods of "specification computing power," "effective computing power," "business computing power," and their related lower-level metrics (such as CPU core type, frequency, memory bandwidth, platform overhead coefficient, etc.). Data Format: Employs an industry-standard data exchange format to represent computing power descriptions. A node's computing power description file clearly lists its values ​​and labels for each metric. Application Performance Profiling Specification: Defines how to describe the performance profile of an application, including its sensitivity to various resources, performance curve functions, etc. Standardized API Interfaces: Through standardized interfaces, third-party hardware manufacturers can provide a driver or plugin to automatically register the computing power characteristics of their new hardware into this system. Application developers can also publish standardized performance profiles of their applications, enabling the cloud platform to provide resources more intelligently.

[0179] In this embodiment of the invention, multiple binary files or container images for different architectures are compiled so that when an application instance is deployed to a target node, the corresponding container image is determined based on the target node's architecture, thus confirming the correct version for the architecture. Running applications in a heterogeneous environment requires addressing two core issues: whether the application binary files can run on different instruction sets (compatibility), and whether cross-architecture scheduling and migration processes introduce security risks. This system can integrate and utilize various technologies to ensure cross-architecture compatibility of applications. Cross-architecture compilation: In a continuous integration / continuous delivery pipeline, multiple binary files or container images for different target architectures (such as x86, ARM) are compiled for the same source code library. During deployment, the scheduler selects the corresponding image based on the target node's architecture. This is the most efficient and highest-performing method. Binary translation: For legacy applications without source code or that cannot be recompiled, dynamic binary translation technology can be used. It can dynamically translate instructions from one instruction set (such as x86) into another instruction set (such as ARM) at runtime. Although there will be some performance loss, it provides the possibility of reusing legacy applications. Container packaging and multi-architecture images: Container technologies (such as Docker Manifests) can be used to package images with different architectures under the same image tag. When pulling an image at runtime, the container will automatically select the correct version based on the current node's architecture, transparently to the user and scheduler.

[0180] Furthermore, this invention encrypts all data transmitted during resource scheduling operations. Access Control: All API interfaces are protected by strict Role-Based Access Control (RBAC). Only authorized users or services can request computing power mapping, modify scheduling policies, or access sensitive performance data. Resource Isolation: Both virtual machines and containers rely on underlying virtualization technology and operating system kernel functionality to provide strong resource isolation. This invention ensures that these isolation mechanisms are correctly configured during cross-architecture scheduling, preventing interference between applications. Network Isolation: Through Virtual Private Cloud (VPC) and Network Policies, this invention ensures that application network access permissions are not accidentally changed during migration or scaling, preventing security domain breaches caused by cross-architecture operations. Encryption During Migration: For smooth migration of stateful applications, all data transmitted over the network (including memory state and disk data) should be encrypted to prevent eavesdropping or tampering during transmission. In this way, by comprehensively utilizing these scalability, compatibility, and security measures, the present invention has built a powerful, open, flexible, and secure heterogeneous computing power platform for real-world computing and management, providing a solid technical foundation for the true implementation and productization of the "one cloud, multiple chips" strategy in the private cloud field.

[0181] Beneficial Effects: This invention first filters nodes, then establishes a business computing power profile model for a specific business application by monitoring its key performance indicators under different resource configurations. Using this model, it determines the equivalent resource configuration for deploying application instances on the filtered nodes. Finally, based on the equivalent resource configuration, the application instances are deployed on the target heterogeneous architecture. This precise business computing power quantification and equivalent mapping ensures that key performance indicators (such as transaction processing volume and response latency) remain stable when applications migrate, deploy, or elastically scale across heterogeneous hardware. By allocating resources through scientific measurement rather than blind guessing, this invention provides applications with "just the right" computing power on demand, effectively avoiding the over-allocation of resources commonly found in traditional methods.

[0182] To systematically address the issue of unequal computing power across heterogeneous systems, this invention first proposes a clear layered architecture. This architecture divides the entire computing power quantization and scheduling system into three core layers: the Resource Layer, the Platform Layer, and the Application Layer. This layered design aims to achieve separation of concerns, allowing each layer to focus on specific quantization tasks and optimization objectives, thereby reducing the overall system complexity and improving its scalability and flexibility. Firstly, the Resource Layer is the foundation of computing power quantization, its primary responsibility being to measure and evaluate the theoretical computing power of bare-metal physical servers. Here, "computing power" mainly refers to "specification-based computing power" (i.e., the specification benchmark value in this invention), a benchmark value calculated based on hardware specification parameters, used to reflect the theoretical performance differences of different processor architectures under general computing tasks. Core tasks:

[0183] Hardware performance metrics collection: Systematically collect and standardize various low-level hardware performance metrics. This includes, but is not limited to: CPU model, architecture, clock speed, number of cores (physical and logical), cache size (L1 / L2 / L3 cache), and supported instruction sets (such as AVX). In addition, it includes memory capacity, frequency, and bandwidth, as well as the throughput of storage (I / O) and network devices.

[0184] Specification-based computing power calculation: Based on collected hardware metrics, a quantifiable "specification-based computing power" calculation model is established. The core of this model is setting a baseline coefficient for different processor architectures. For example, using a single core of a mainstream x86 architecture CPU as the baseline (coefficient of 1.0), the coefficient of another ARM architecture CPU core might be calibrated to 1.2 or 0.8 based on benchmark test results (e.g., using industry-standard tools such as SPECCPU (Standard Performance Evaluation Corporation)). The final node specification-based computing power is a comprehensive score, which is obtained by normalizing multi-dimensional metrics such as CPU, memory, and I / O through a weighted algorithm. For example: Assuming an x86 node A has 16 cores and its architecture coefficient is 1.0, its CPU specification-based computing power baseline score is 16 * 1.0 = 16 points. Another ARM node B has 24 cores and its architecture coefficient is 0.75, so its CPU specification-based computing power baseline score is 24 * 0.75 = 18 points. This means that, theoretically, node B has slightly higher general computing power than node A.

[0185] The platform layer sits above the resource layer and primarily focuses on the performance overhead caused by virtualization or containerization technologies, as well as the impact of platform scheduling strategies on the effectiveness of computing power. This layer evaluates "effective computing power," which is the actual computing capacity that physical resources, after being virtualized or containerized, can provide to upper-layer applications.

[0186] Core Task: Measuring Virtualization / Containerization Overhead: Different virtualization technologies or container runtimes (such as Docker and containerd) consume computational resources and may introduce additional performance overhead. The platform layer quantifies this overhead by deploying standard micro-benchmarks. For example, by running CPU-intensive, memory-intensive, and network I / O-intensive benchmarks within virtual machines or containers and comparing their performance with that running on bare metal, a "platform overhead coefficient" is derived.

[0187] The application layer is the ultimate goal and value embodiment of computing power. It no longer focuses on theoretical specifications or platform overhead, but directly measures the actual performance of business applications. This layer evaluates "Business-aware Computing Power," which is the key performance indicator that a business application can achieve under specific resource configurations.

[0188] Core Task: Definition and Monitoring of Business Performance Metrics: Define core performance metrics for different application types (such as online transaction processing, big data analytics, video transcoding, etc.). The most common metrics include: transactions per second, request-response latency, concurrent users, and error rate. The application layer continuously collects these business metrics through integration with the monitoring system.

[0189] Building application performance profiles: By running applications on nodes with different resource configurations and architectures, performance data is collected to create a "resource-configuration-performance" profile. This profile reveals the sensitivity of a specific application to resources such as CPU and memory, as well as its performance differences across different hardware architectures.

[0190] Equivalent performance mapping: The ultimate goal of the application layer is to find equivalent business computing power. For example, if a web service can achieve a performance of 1000 TPS when running on an x86 node with 2 CPU cores and 4GB of memory, then when it needs to be migrated to an ARM node, the application layer needs to answer: how many ARM cores and how much memory should be allocated to enable the service to achieve the same performance level of 1000 TPS? This mapping relationship is the equivalent representation of "business computing power".

[0191] Furthermore, in this invention, the resource tag and topology manager serves as a metadata management center, responsible for storing and managing all static and dynamic information related to computing power. Stored content includes: Node tags: Each physical node and virtual resource (such as virtual machine specifications) is tagged with rich tags. For example, arch=x86_64, cpu_model=Intel_Xeon_Platinum, spec_power_ratio=1.0, region=dc1. These tags allow the scheduler to easily filter and match data.

[0192] Computing power coefficient: Storage and maintenance of various "specification computing power" coefficients calculated by the resource layer and "platform overhead coefficients" measured by the platform layer.

[0193] Equivalence Mapping Library: Stores application computing power equivalence relationships calculated and verified by the computing power equivalence algorithm core. For example, it records that "Application A (Web service) has a performance of 1000 TPS under X86 (2C / 4G) configuration, and its equivalent configuration under ARM architecture is 4C / 4G".

[0194] Topology management: Maintains the physical and logical topology of the data center, such as racks and network switches, to support advanced scheduling strategies that take into account factors such as network latency.

[0195] Through the above layered decoupling, this application can accurately assess and measure computing power in heterogeneous environments from different dimensions, providing a solid data foundation and clear architectural support for subsequent equivalence mapping, intelligent scheduling, and elastic scaling. The cloud platform gains the core capabilities to perceive, measure, store, and manage heterogeneous computing power, transforming the originally vague and invisible hardware differences into clear and usable data assets.

[0196] Markets and technologies are constantly evolving; new processors, new virtualization technologies, and new application versions emerge. A static quantization model quickly becomes obsolete. Therefore, this invention emphasizes the model's dynamic self-learning and updating capabilities. The system continuously compares the actual performance of the application with the model's predicted performance through online monitoring. If the prediction deviation consistently exceeds a certain threshold (e.g., the model predicts 1000 TPS, but actual performance only reaches 800 TPS in multiple consecutive runs), a model update process is triggered. New hardware / platform introduction: When the dynamic heterogeneous feature perceptron detects the addition of a new CPU model or a new Hypervisor version to the cluster, it automatically triggers the micro-benchmark library to run a series of tests in the new environment, recalibrating its "architecture coefficients" and "platform overhead coefficients," and updating the computing power model. Application behavior changes: When an application releases a new version, its performance profile may change (e.g., reduced memory sensitivity due to code optimization). The system detects this change (through increased prediction deviation) and automatically launches small-scale "probe" instances to rerun performance tests, generating and updating the application's new performance profile.

[0197] Through this closed-loop feedback and adaptive mechanism, the computational power model of this invention can maintain its accuracy and timeliness, adapt to the ever-changing software and hardware environment, and achieve true self-learning and self-optimization.

[0198] This invention establishes a complete feedback loop from monitoring to execution, enabling the system to continuously learn and adapt to environmental changes, thereby constantly improving the accuracy of its quantitative model and the optimality of its scheduling decisions.

[0199] First, online monitoring and indicator collection: Layered data collection:

[0200] Application layer performance: By integrating with application performance monitoring (APM) systems or service meshes, core business-related metrics such as TPS, latency, and error rate are collected. Collection points should be located as close as possible to the entry point for user requests to reflect the most accurate user experience.

[0201] System-level resource utilization: Within each virtual machine or container, the utilization, saturation, and error count of CPU, memory, network I / O, and disk I / O are collected. These metrics reflect the actual resource consumption of the application.

[0202] Hardware operating status: At the physical host level, hardware sensor data, including CPU temperature, power consumption, and fan speed, is collected through node agents or out-of-band management. This data can be used for subsequent energy consumption and cost optimization.

[0203] Data collection method:

[0204] Edge data acquisition and preprocessing: To reduce the load on the central monitoring system, preliminary data acquisition, aggregation, and filtering of metrics can be performed at the edge of each node or cluster. For example, data can be collected once per second, but aggregated into an average / maximum / P99 value every minute before being reported.

[0205] Centralized aggregation and storage: All collected data is ultimately sent to a centralized time-series database (TSDB). Data must be stored with rich labels, such as application name, instance ID, node name, architecture type, rack location, etc., to enable multi-dimensional correlation analysis.

[0206] Furthermore, reducing energy consumption and operating costs while meeting performance requirements is one of the core demands of cloud platforms. This invention incorporates energy consumption and cost as important dimensions in its optimization model.

[0207] Introducing energy consumption and cost metrics: Energy consumption metrics: Real-time power consumption (watts) of nodes is collected through power sensors on the physical host (or estimated based on CPU / memory utilization). Cost metrics: A cost model is set for different types and architectures of resources (CPU, memory, storage, bandwidth) per unit time. This cost can be calculated based on a combination of factors such as hardware procurement costs, electricity costs, and rack space rental fees.

[0208] Establish an energy efficiency ratio and cost-benefit model:

[0209] Performance per Watt: Defined as computing power / power consumption, such as TPS / Watt. This metric measures how much effective business value is generated per unit of energy consumed.

[0210] Cost-effectiveness (Performance per Dollar): Defined as business computing power / cost, such as TPS / Yuan. This metric measures how much business performance can be purchased per unit of cost.

[0211] Support green and energy-saving dispatching:

[0212] In scheduling and resource allocation decisions, energy efficiency ratio or cost-effectiveness can be used as additional optimization objectives.

[0213] Scenario 1: Selecting an equivalent configuration: When searching for an equivalent configuration for an application, if there are multiple configuration options that meet the performance target (e.g., both x86 2C / 4G and ARM 3C / 3G can reach 1000TPS), the system will prioritize the option with higher energy efficiency or better cost-effectiveness (e.g., the ARM solution has lower total power consumption or cost).

[0214] Scenario 2: Cluster Load Consolidation: During the night when cluster load is low, green energy-saving scheduling strategies can be activated. It attempts to consolidate a small number of applications scattered across multiple nodes into a few nodes with the highest energy efficiency by migrating them across the architecture, and then puts the other idle nodes into a dormant or shutdown state, thereby greatly saving energy consumption across the entire data center.

[0215] Through this complete feedback loop and multi-objective optimization mechanism, this invention evolves from a passive resource allocation tool into an advanced intelligent management platform with self-awareness, self-learning, self-optimization, and long-term planning capabilities. By introducing energy efficiency ratio and cost-effectiveness models, the system can automatically select the most cost-effective hardware to run applications (e.g., prioritizing the use of more energy-efficient or cheaper ARM servers while meeting performance requirements), helping enterprises minimize the total cost of ownership for hardware procurement, power consumption, and data center operations.

[0216] The following section will use a typical application scenario as an example to describe in detail the collaborative workflow of the various components in this invention.

[0217] Scenario Setting: An application providing online video transcoding services (hereinafter referred to as the "transcoding application") is deployed on a private cloud platform. This platform has both an Intel Xeon-based x86 resource pool and a domestic Phytium ARM-based ARM resource pool. The business requirement is to automatically perform cross-architecture elastic scaling based on the task queue length, while ensuring that the average processing time for each transcoding task (e.g., converting a 1080p video to 720p) does not exceed 5 minutes, and to maximize resource cost-effectiveness.

[0218] Step 1: System Initialization and Baseline Calibration

[0219] 1. Deployment and Awareness: After the computing power equivalence management service of this invention is deployed, its "Dynamic Heterogeneous Feature Perceptor" module immediately begins to work. It interacts with the cloud operating system to scan and identify two types of physical nodes in the cluster: Intel Xeon nodes and Phytium ARM nodes. It collects detailed hardware specifications (CPU model, 32 physical cores, 64 logical cores, 2.8GHz clock speed, support for AVX2 instruction set, etc.) and platform information (running KVM version 4.1) for each node. After formatting this information, the "Resource Tagging and Topology Manager" tags each node with labels such as arch=x86_64, cpu_model=intel_xeon, isa=avx2, etc.

[0220] 2. Specification Computing Power Calibration: The computing power equivalence management service triggers the "micro-benchmark library," running a series of standard tests on representative nodes of both architectures. Running CPU-intensive tests (such as Linpack floating-point operations) reveals that the floating-point performance of a single Xeon core is approximately 1.5 times that of a single Phytium core. Running specific instruction set tests for video processing shows that Xeon's AVX2 instruction set significantly accelerates transcoding algorithms. Combining multiple tests and using the Intel Xeon core as the benchmark (architecture coefficient 1.0), the "Specification Computing Power Calculation Model" calculates that the overall architecture coefficient of the Phytium core is approximately 0.7. Ultimately, the CPU specification computing power scores for a 32-core Xeon node and a 64-core Phytium node might be calculated as 32 * 1.0 = 32 and 64 * 0.7 = 44.8, respectively. These scores are also stored as node labels.

[0221] Step 2: Application Performance Profile Creation

[0222] 1. Define Business KPIs: For the "transcoding application," the core business KPI is defined as "average task processing time." The performance target is set at 300 seconds.

[0223] 2. Profile Testing: In the test environment, multiple instances of the application were created on both x86 and ARM nodes, with different resource configurations assigned (e.g., x86: 2C / 4G, 4C / 8G; ARM: 2C / 4G, 4C / 8G, 6C / 8G). Standard transcoding tasks were submitted to these instances, and the "Monitoring and Metrics Collection Module" recorded the average task processing time for each configuration.

[0224] 3. Model Building: The collected data was used to train the application's "business computing power" model. Results showed that on x86, the performance model was Time_x86 = f(CPU, Mem), and due to the AVX2 enhancement, processing time was highly sensitive to the number of CPU cores. On ARM, the performance model was Time_arm = g(CPU, Mem). Although single-core performance was weaker, this could be compensated for by adding more cores. Model analysis showed that a 4C / 8G instance on x86 could achieve a processing time of 290 seconds, meeting the performance target.

[0225] Step 3: The actual implementation of cross-architecture elastic scaling:

[0226] 1. Triggered Expansion: In the production environment, the transcoding task queue length surged, triggering HPA's expansion strategy. HPA requested the "Computationalized Scheduling Plugin" of this invention to create a new application replica.

[0227] 2. Scheduling Decisions:

[0228] The scheduling plugin first checks the x86 resource pool and finds that the resources are full, so it cannot create a new 4C / 8G instance.

[0229] The scheduling plugin then considers the ARM resource pool. It queries the compute equivalence management service: "What equivalent configuration is required on the Phytium ARM node to achieve the 300-second processing time target for the 'transcoding application'?"

[0230] The computing power equivalence management service search for the "equivalence mapping library" found no existing records.

[0231] Therefore, it uses the established business computing power model to perform a reverse solution: solving for g(C_arm, M_arm)<=300. One of the optimal solutions given by the model is 6C / 8G.

[0232] 3. Dynamic resource modification and deployment:

[0233] The scheduling plugin received an equivalent configuration suggestion of "6C / 8G".

[0234] Before scheduling the application instance to the selected ARM node, the plugin dynamically modified the instance's resource request, changing it from the original 4C / 8G to 6C / 8G. After the modification, the instance was successfully deployed to the ARM node.

[0235] Step 4: Feedback, Verification, and Self-Optimization

[0236] 1. Online Verification: After the newly created ARM instance is put into operation, the "Monitoring and Metrics Collection Module" continuously tracks its performance. Data shows that the average task processing time of this 6C / 8G instance is stable at around 295 seconds, with an error of less than 2% compared to the performance target (300 seconds).

[0237] 2. Mapping Relationship Archive: This successful cross-architecture expansion has been confirmed as a valid equivalent mapping. The relationship (application: transcoding, target: processing time <300s) => (X86: 4C / 8G) <=> (ARM: 6C / 8G) has been recorded in the "Equivalent Mapping Library". In the future, when the same expansion requirement arises again, the system can directly query this record and complete the decision in milliseconds, without needing to perform model calculations again.

[0238] 3. Model Adaptation: Several months later, the "Transcoding Application" released a new version, with its development team specifically optimizing it for the NEON instruction set of the ARM architecture. After deployment, the monitoring system discovered that tasks previously requiring 6 ARM cores now only needed 5. A persistent discrepancy emerged between the predicted model and actual performance. The "adaptive parameter tuning" mechanism of this invention was triggered, automatically launching small-scale probe instances to re-profile the new application's performance and update its business computing power model on ARM. Simultaneously, old equivalent mapping records were marked as "outdated." From then on, when making scaling decisions, the system would recommend a more resource-efficient 5C / 8G configuration based on the updated model, further reducing costs.

[0239] In this way, this invention transforms the complex problem of heterogeneous computing power management into a quantifiable, predictable, and automated engineering practice, ultimately achieving reliable application performance assurance and extreme optimization of resource costs in a "one cloud, multiple chips" environment. Through precise business computing power quantification and equivalence mapping, it ensures that key performance indicators (such as transaction processing volume and response latency) remain stable and conform to the preset service level agreement when applications migrate, deploy, or elastically scale across heterogeneous hardware. It completely solves the problem of drastic performance fluctuations caused by unequal computing power in existing technologies, greatly improving the stability, reliability, and user experience of cloud platform services. It transforms the complex task of heterogeneous resource management from a traditional model relying on expert experience and repeated manual testing into an intelligent process automatically completed by the system. Whether it's deploying new applications, migrating existing applications, or scaling up and down to handle sudden traffic surges, the entire process is completed automatically in a closed loop by the system without manual intervention. This greatly reduces the workload of the operations and maintenance team, reduces human error, and improves overall operational efficiency and response speed.

[0240] Furthermore, embodiments of this application also disclose an electronic device, Figure 2This is a structural diagram of an electronic device according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application. Specifically, the electronic device may include: at least one processor 11, at least one memory 12, a power supply 13, a communication interface 14, an input / output interface 15, and a communication bus 16. The memory 12 stores a computer program, which is loaded and executed by the processor 11 to implement the relevant steps in the heterogeneous resource scheduling method for cloud data centers disclosed in any of the foregoing embodiments. Furthermore, the electronic device in this embodiment may specifically be an electronic computer.

[0241] In this embodiment, the power supply 13 is used to provide operating voltage for various hardware devices on the electronic device; the communication interface 14 can create a data transmission channel between the electronic device and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 15 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0242] In addition, the memory 12, as a carrier for resource storage, can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored thereon can include operating system 121, computer program 122, etc., and the storage method can be temporary storage or permanent storage.

[0243] The operating system 121 is used to manage and control the various hardware devices on the electronic device and the computer program 122, which may be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program capable of performing the heterogeneous resource scheduling method for a cloud data center executed by the electronic device as disclosed in any of the foregoing embodiments, the computer program 122 may further include a computer program capable of performing other specific tasks.

[0244] Furthermore, this application also discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned heterogeneous resource scheduling method for cloud data centers. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0245] Furthermore, the present invention also discloses a computer program product, including a computer program / instructions; wherein, when the computer program / instructions are executed by a processor, they implement the aforementioned heterogeneous resource scheduling method for cloud data centers. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0246] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0247] 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.

[0248] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0249] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, 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. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0250] The technical solutions 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 above embodiments are only intended to help understand the methods and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for scheduling heterogeneous resources in a cloud data center, characterized in that, include: Receive scheduling tasks containing source architecture resource information for application instances; The source architecture resource information includes source resource configuration and source architecture type; The processing nodes are screened based on the computing power requirements of the application instances in the cloud data center and the specification benchmark values ​​of the processing nodes, and candidate nodes are determined based on the corresponding screening results. The specification benchmark value is a benchmark value used to characterize the processing performance of the processing node; By running the application instance on candidate nodes with different resource configurations and architectures, the performance data of the application instance is obtained, and an application performance profile of the application instance is constructed based on the performance data. The application performance profile is a profile used to characterize the mapping relationship between resource configuration, architecture, and performance data; Based on the application performance profile and the scheduling task, determine the equivalent resource configuration corresponding to deploying the application instance on the candidate node, determine the score of each candidate node based on the equivalent resource configuration and the specification benchmark value, and determine the target node based on the score; Based on the equivalent resource configuration, modify the resource request of the application instance to obtain the modified resource request, and deploy the application instance to the target node so that the target node can perform resource configuration based on the modified resource request to complete the heterogeneous resource scheduling of the cloud data center. The performance data is used to create a resource-configuration-performance profile, which is used to display the application's sensitivity to resources and the differences in the application's performance on different application architectures. The step of constructing the application performance profile of the application instance based on the performance data includes: The performance data is used to train a preset prediction model to obtain a trained prediction model; the preset prediction model is a linear regression model or a nonlinear model. The trained prediction model is used as the application performance profile of the application instance.

2. The heterogeneous resource scheduling method for cloud data centers according to claim 1, characterized in that, Before filtering the processing nodes based on the computing power requirements of the application instances in the cloud data center and the specification benchmark values ​​of the processing nodes, the method further includes: The processing node is tested according to the preset test type, target parameters, operating environment, and number of repetitions to obtain the corresponding test parameters; the target parameters include any one or a combination of several of the following: number of threads, data size, and duration; the test parameters include CPU throughput, memory bandwidth, number of read / write operations per second, and network latency. The test parameters are converted into standardized scores based on preset parameter benchmark values; The standardized scores are weighted to obtain the baseline score of the architecture performance of the processing node; Collect the hardware specifications of the processing node; the hardware specifications include the number of physical cores, the number of logical cores, and the clock speed of the central processing unit. Determine the first product among the various hardware specification parameters; The CPU component score is determined based on the second product between the first product and the architecture performance baseline score. The memory component score is determined based on the memory capacity and memory bandwidth of the processing node; The input / output sub-scores are determined based on the storage type and storage performance of the processing node; The specification baseline value is determined based on the CPU component score, the memory component score, and the input / output component score.

3. The heterogeneous resource scheduling method for cloud data centers according to claim 2, characterized in that, Determining the specification baseline value based on the CPU component score, the memory component score, and the input / output component score includes: The scores for the central processing unit, the memory, and the input / output components are normalized to obtain normalized scores. The normalized scores are then weighted and averaged to obtain the specification benchmark value.

4. The heterogeneous resource scheduling method for cloud data centers according to claim 1, characterized in that, The process of filtering processing nodes based on the computing power requirements of the application instance in the cloud data center and the specification benchmark values ​​of the processing nodes, and determining candidate nodes based on the corresponding filtering results, includes: Determine whether the architecture label of the processing node meets the preset architecture label requirements of the application instance to obtain a first determination result; Determine whether the specification baseline value of the processing node meets the preset specification baseline value requirement of the application instance to obtain a second determination result; The processing nodes are filtered based on the first judgment result and the second judgment result, so that the processing nodes whose architecture tags meet the preset architecture tag requirements and whose specification benchmark values ​​meet the preset specification benchmark value requirements are determined as the candidate nodes.

5. The heterogeneous resource scheduling method for cloud data centers according to claim 1, characterized in that, The step of determining the equivalent resource configuration corresponding to deploying the application instance on the candidate node based on the application performance profile and the scheduling task includes: The current resource configuration for deploying the application instance on the candidate node is determined based on the specification baseline value of the processing node and the application performance profile. Based on the current resource configuration, several probe instances are launched on the candidate nodes to obtain corresponding performance data; the performance data includes application layer performance metrics and resource utilization; the application layer performance metrics include ticks per second and latency; The loss value is determined based on the ratio between the performance target of the application instance in the source environment and the performance data, and the performance target. If the loss value is greater than a preset threshold, the current resource configuration is adjusted based on the coordinate descent method or the gradient step size adjustment method to obtain a new resource configuration; The new resource configuration is determined as the current resource configuration, and the process jumps back to the step of starting several probe instances on the candidate node according to the current resource configuration until the loss value is less than the preset threshold. The current resource configuration is determined to be the equivalent resource configuration for deploying the application instance on the candidate node.

6. The heterogeneous resource scheduling method for cloud data centers according to claim 5, characterized in that, After determining the current resource configuration as the equivalent resource configuration for deploying the application instance on the candidate node, the method further includes: The mapping relationship between the equivalent resource configuration, the corresponding candidate nodes, and the application instance is stored in a preset mapping library.

7. The heterogeneous resource scheduling method for cloud data centers according to claim 6, characterized in that, Before launching several probe instances on the candidate nodes according to the current resource configuration, the method further includes: The initial prediction model is trained using historical data from the preset mapping library to obtain the target prediction model; The target prediction model is used to determine the current resource configuration based on the type of the application instance, the source resource configuration, and the source architecture type.

8. The heterogeneous resource scheduling method for cloud data centers according to claim 6, characterized in that, Before determining the equivalent resource configuration corresponding to deploying the application instance on the candidate node based on the application performance profile and the scheduling task, the method further includes: Based on the application performance profile, determine whether there is a target mapping relationship in the preset mapping library that corresponds to the candidate node and the application instance; If it exists, the equivalent resource configuration corresponding to deploying the application instance on the candidate node is determined directly based on the target mapping relationship; If it does not exist, the operation of determining the equivalent resource configuration corresponding to the application instance on the candidate node based on the application performance profile and the scheduling task is triggered.

9. The heterogeneous resource scheduling method for cloud data centers according to claim 1, characterized in that, Before determining the score of each candidate node based on the equivalent resource allocation and the specification benchmark value, the method further includes: Test cases with different resource dimensions are run on bare metal and in virtual machines or containers to obtain corresponding test performance data; the resource dimensions include CPU, memory, storage, network, and latency. The test performance data are weighted and averaged to obtain the target cost coefficient.

10. The heterogeneous resource scheduling method for cloud data centers according to claim 9, characterized in that, The process of determining the score for each candidate node based on the equivalent resource allocation and the specification benchmark value includes: Determine the first difference between 1 and the target cost coefficient; Determine the second difference between 1 and the preset load factor; The effective reference value is determined based on the product of the specification reference value, the first difference, and the second difference; The score of each candidate node is determined based on the equivalent resource allocation and the effective benchmark value.

11. The heterogeneous resource scheduling method for cloud data centers according to claim 10, characterized in that, The process of determining the score of each candidate node based on the equivalent resource allocation and the effective benchmark value includes: Determine whether the resource configuration of each candidate node satisfies the equivalent resource configuration; Candidate nodes that satisfy the equivalent resource allocation are identified as target candidate nodes; The effective benchmark value of the target candidate node is determined as the score of each target candidate node.

12. The heterogeneous resource scheduling method for cloud data centers according to claim 11, characterized in that, The process of determining the target node based on the score includes: The target candidate node with the highest score among the target candidate nodes is determined as the target node.

13. The heterogeneous resource scheduling method for cloud data centers according to claim 1, characterized in that, Also includes: During resource scheduling, a dual-write mode is initiated so that the target node can configure resources based on the dual-write mode and the modified resource request.

14. The heterogeneous resource scheduling method for cloud data centers according to claim 1, characterized in that, Also includes: Analyze the load changes of the application instance within the target time period to obtain the corresponding periodic patterns and the load trends corresponding to the periodic patterns; Based on the periodic patterns and load trends, predict the resource demand curve of the application instance in the future within a preset time period; The resource configuration of the application instance is adjusted accordingly based on the resource demand curve to expand or shrink the application instance.

15. The heterogeneous resource scheduling method for cloud data centers according to claim 1, characterized in that, Also includes: Compile multiple binary files or container images with different architectures so that when the application instance is deployed to the target node, the corresponding container image is determined according to the architecture of the target node, thereby determining the correct version for the architecture.

16. The heterogeneous resource scheduling method for a cloud data center according to any one of claims 1 to 15, characterized in that, Also includes: All data during resource scheduling operations is transmitted in encrypted form.

17. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the heterogeneous resource scheduling method for a cloud data center as described in any one of claims 1 to 16.

18. A non-volatile storage medium, characterized in that, The non-volatile storage medium stores a computer program, which, when executed by a processor, implements the steps of the heterogeneous resource scheduling method for a cloud data center as described in any one of claims 1 to 16.

19. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instruction is executed by the processor, it implements the steps of the heterogeneous resource scheduling method for cloud data centers as described in any one of claims 1 to 16.

Images