Calculation network energy resource scheduling processing method, storage medium and electronic equipment

Abstract

The invention discloses a computing network energy resource scheduling processing method, a storage medium and electronic equipment. The method comprises the steps that scheduling factors corresponding to a plurality of computing power clusters are obtained, the scheduling factors comprise computing power factors, network factors, energy factors and service affinity factors, and the computing power factors, the network factors and the energy factors are obtained by conducting index scoring on computing network energy resources through a regional server; based on the business scene adjustment coefficients corresponding to the plurality of computing power clusters, determining scheduling factor weights corresponding to the plurality of computing power clusters; obtaining a cluster score of each computing power cluster based on the scheduling factor and the scheduling factor weight of each computing power cluster; and determining a target computing power cluster for executing the current service request from the plurality of computing power clusters according to the cluster scores. According to the invention, the technical problems of signaling overload and poor resource scheduling flexibility caused by a centralized management architecture in computing network energy resource scheduling in related technologies are solved.

Description

Technical Field

[0001] This invention relates to the field of intelligent scheduling, and more specifically, to a method for scheduling and processing network energy resources, a storage medium, and an electronic device. Background Technology

[0002] The current technological background of the integrated computing, network, and energy dispatching system is deeply rooted in the regional resource allocation and the intelligent transformation of the new power system. With the explosive development of 5G, artificial intelligence, and the Internet of Things, the annual growth rate of computing power demand across society and the surge in data center scale are both significant. However, there is currently a significant spatial mismatch between the distribution of computing power resources and energy supply. For example, some regions bear the majority of the region's computing power demand but face constraints such as land scarcity, high electricity prices, and carbon emission quotas; while other regions, despite having a high proportion of green electricity and ample land resources, have long experienced computing power utilization rates below 10%, resulting in substantial resource waste. To address this contradiction, an increasing number of large-scale computing power hub nodes and data center clusters aim to build a cross-regional resource supply and demand coordination dispatching network.

[0003] A collaborative planning method for computing, network, and energy resources, considering the time-series scheduling of computing tasks, is disclosed in related technologies. This method aims to achieve multi-level interaction among computing resources, computing tasks, load demand, and energy supply, ultimately optimizing the overall configuration of computing, network, and energy resources. However, this method suffers from the following problems: 1) Lack of a differentiated measurement mechanism: The centralized management architecture requires full reporting of node data (such as CPU load, bandwidth, and electricity price), leading to control plane signaling overload. When the number of nodes exceeds 100,000, it consumes a large amount of transmission bandwidth. 2) Insufficient multi-factor fusion: The scheduling models in related technologies only optimize computing network or energy dimension objectives, failing to consider all factors comprehensively. 3) Insufficient multi-factor coordination: The scheduling algorithms in related technologies typically use fixed optimization weight factors. This makes it difficult to flexibly adjust for different demand scenarios, hindering the smooth allocation of time-series requests. In summary, related technologies suffer from problems such as signaling overload and poor scheduling flexibility due to the centralized management architecture in computing, network, and energy resource scheduling.

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

[0005] This invention provides a computing network energy resource scheduling processing method, storage medium, and electronic device to at least solve the technical problems of signaling overload and poor resource scheduling flexibility caused by centralized management architecture in computing network energy resource scheduling in related technologies.

[0006] According to one aspect of the present invention, a method for scheduling computing network energy resources is provided, comprising: acquiring scheduling factors corresponding to multiple computing power clusters, wherein the scheduling factors include computing power factors, network factors, energy factors, and service affinity factors; the computing power factors are obtained by scoring the computing power indicators of the corresponding computing power clusters through a regional server; the network factors are obtained by scoring the network indicators of the corresponding computing power clusters through a regional server; the energy factors are obtained by scoring the energy indicators of the corresponding computing power clusters through a regional server; and the service affinity factor is used to indicate the similarity between the service provided by the corresponding computing power cluster and the current service request; based on multiple computing power clusters... The business scenario adjustment coefficients for each computing power cluster are used to determine the scheduling factor weights for each cluster. These scheduling factor weights include computing power factor weights, network factor weights, energy factor weights, and service affinity factor weights. The business scenario adjustment coefficients are used to adjust the corresponding scheduling factor weights according to the business scenario requirements of the corresponding computing power cluster. Based on the scheduling factors and weights for each computing power cluster, a cluster score is obtained for each cluster. Based on the cluster scores, a target computing power cluster for executing the current service request is determined from among the multiple computing power clusters.

[0007] According to another aspect of the present invention, another method for scheduling computing network energy resources is provided, comprising: acquiring computing power indicators, network indicators, and energy indicators corresponding to each of multiple computing power clusters; determining computing power factors, network factors, and energy factors corresponding to each of the multiple computing power clusters based on the computing power indicators, network indicators, and energy indicators corresponding to each of the multiple computing power clusters; sending the computing power factors, network factors, and energy factors corresponding to each of the multiple computing power clusters to a master server, wherein the master server determines the cluster score corresponding to each of the multiple computing power clusters, wherein the cluster score is obtained based on the scheduling factor and scheduling factor weight of the corresponding computing power cluster, the scheduling factor including computing power factor, network factor, energy factor, and service affinity factor, the service affinity factor being used to indicate the similarity between the service provided by the corresponding computing power cluster and the current service request; the scheduling factor weight is obtained based on the business scenario adjustment coefficient of the corresponding computing power cluster, the scheduling factor weight including computing power factor weight, network factor weight, energy factor weight, and service affinity factor weight, the business scenario adjustment coefficient being used to adjust the corresponding scheduling factor weight according to the business scenario requirements of the corresponding computing power cluster, and the cluster score corresponding to each of the multiple computing power clusters being used to determine the target computing power cluster for executing the current service request from the multiple computing power clusters.

[0008] According to another aspect of the present invention, a non-volatile storage medium is also provided, which stores multiple instructions, the instructions being adapted for a computing network energy resource scheduling processing method to be loaded by a processor and executed at any one of them.

[0009] According to another aspect of the present invention, an electronic device is also provided, including one or more processors and a memory, wherein the memory is used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement any one of the computing network energy resource scheduling processing methods.

[0010] According to another aspect of the present invention, a computer program product is also provided, including a computer program, wherein when the computer program is executed by a processor, it implements the steps of any one of the computer network energy resource scheduling processing methods.

[0011] In this embodiment of the invention, scheduling factors corresponding to multiple computing power clusters are obtained. These scheduling factors include computing power factors, network factors, energy factors, and service affinity factors. The computing power factor is obtained by scoring the computing power indicators of the corresponding computing power cluster using a regional server. The network factor is obtained by scoring the network indicators of the corresponding computing power cluster using a regional server. The energy factor is obtained by scoring the energy indicators of the corresponding computing power cluster using a regional server. The service affinity factor indicates the similarity between the service provided by the corresponding computing power cluster and the current service request. Based on the business scenario adjustment coefficients corresponding to each of the multiple computing power clusters, the scheduling factor weights corresponding to each of the multiple computing power clusters are determined. These scheduling factor weights include computing power factor weights, network factor weights, energy factor weights, and service affinity factor weights. The business scenario adjustment coefficients are used to determine the weights of the scheduling factors corresponding to each of the multiple computing power clusters. The scheduling factor weights are adjusted according to the business scenario requirements of the computing power clusters. Based on the scheduling factors and weights of each computing power cluster, a cluster score is obtained for each cluster. According to the cluster scores, the target computing power cluster for executing the current service request is determined from among the multiple computing power clusters. This achieves efficient, intelligent, and smooth resource scheduling for time-series tasks through hierarchical and domain-based management and dynamic determination of scheduling factor weights, optimizing the allocation of computing network resources. This ensures the flexibility of resource scheduling and the rapid response to service requests, thereby improving resource scheduling efficiency and resource utilization. It also solves the technical problems of signaling overload and poor resource scheduling flexibility caused by centralized management architecture in computing network resource scheduling in related technologies. Attached Figure Description

[0012] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0013] Figure 1 This is a flowchart of a computing network energy resource scheduling and processing method according to an embodiment of the present invention;

[0014] Figure 2 This is a flowchart of another computing network energy resource scheduling and processing method according to an embodiment of the present invention;

[0015] Figure 3 This is a schematic diagram of an optional hierarchical and domain-based scheduling factor and weight determination framework according to an embodiment of the present invention;

[0016] Figure 4 This is a schematic diagram of an optional dynamic adjustment weight determination framework according to an embodiment of the present invention;

[0017] Figure 5 This is an optional overall system architecture diagram according to an embodiment of the present invention;

[0018] Figure 6 This is an optional hierarchical and domain-based system architecture diagram according to an embodiment of the present invention;

[0019] Figure 7 This is a flowchart of an optional computing network energy resource scheduling and processing method according to an embodiment of the present invention;

[0020] Figure 8 This is a schematic diagram of a computing network energy resource scheduling and processing device according to an embodiment of the present invention;

[0021] Figure 9 This is a schematic diagram of another computing network energy resource scheduling and processing device according to an embodiment of the present invention. Detailed Implementation

[0022] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. 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 skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0023] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0024] According to an embodiment of the present invention, a method embodiment for scheduling and processing network energy resources is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0025] Figure 1 This is a flowchart of a computing network energy resource scheduling processing method according to an embodiment of the present invention, such as... Figure 1 As shown, the method includes the following steps:

[0026] Step S102: Obtain the computing power indicators, network indicators, and energy indicators corresponding to each of the multiple computing power clusters.

[0027] This embodiment's method can be applied to a hierarchical and domain-based system framework, which can be divided into a central management layer, regional management layers, and an infrastructure layer. The central and regional management layers effectively manage the distributed data center resources (i.e., computing power clusters) of the infrastructure layer. The infrastructure layer refers to the underlying site resources, managed in the form of computing power clusters; a computing power cluster can contain multiple adjacent data center nodes. The regional management layer manages the massive computing power clusters within a region. The central management layer is mainly used for service registration, business-oriented global information scheduling, and management of critical information reporting. This system framework includes a master server, multiple regional servers, and multiple computing power clusters under each regional server. The master server serves as the central management layer, the multiple regional servers form the regional layer, and the multiple computing power clusters managed by each regional server form the infrastructure layer. The execution entity for steps S102 to S106 can be any regional server. In this step, real-time data and performance indicators related to computing power, network, and energy are collected from each computing power cluster. Computing power metrics may include, but are not limited to, CPU utilization, memory utilization, disk I / O rates, and GPU utilization, used to evaluate the cluster's real-time computing capabilities and load conditions. Network metrics may include, but are not limited to, network latency, bandwidth utilization, and packet loss rate, to measure network health and transmission capacity. Energy metrics may include, but are not limited to, carbon emissions, electricity costs, and the proportion of renewable energy, used to reflect the cluster's energy consumption efficiency and costs.

[0028] Step S104: Based on the computing power indicators, network indicators, and energy indicators corresponding to each of the multiple computing power clusters, determine the computing power factor, network factor, and energy factor corresponding to each of the multiple computing power clusters.

[0029] In this step, the collected computing power, network, and energy metrics are converted into specific scores (i.e., factors). The computing power factor reflects the cluster's performance level in terms of computing power, the network factor reflects the quality of network conditions, and the energy factor quantifies energy consumption and cost control. The calculation of these factor scores can consider standardization of the metrics to ensure comparability between different clusters and different metrics, avoiding the impact of differences in units on the evaluation results.

[0030] In one optional embodiment, based on the computing power indicators, network indicators, and energy indicators corresponding to each of the multiple computing power clusters, the computing power factor, network factor, and energy factor corresponding to each of the multiple computing power clusters are determined, including: when there are multiple computing power indicators, the computing power factor of any computing power cluster is obtained based on the multiple computing power indicators of any computing power cluster in the following manner: the multiple computing power indicators of any computing power cluster are normalized to obtain multiple normalized computing power indicators, wherein the multiple computing power indicators include CPU utilization, memory utilization, disk input / output rate, and video memory utilization; a weighted average is performed on the multiple normalized computing power indicators to obtain the computing power factor of any computing power cluster; based on the computing power indicators corresponding to each of the multiple computing power clusters, the computing power factor corresponding to each of the multiple computing power clusters is obtained by adopting the same method as obtaining the computing power factor of any computing power cluster.

[0031] Optionally, multiple computing power metrics (such as CPU utilization, memory utilization, disk I / O speed, and video memory utilization) for each computing cluster can be standardized to the same dimensions and comparison criteria. Normalization can include, but is not limited to, mapping metric values ​​to a range of 0 to 1 (or a specific range) to facilitate subsequent weighted average calculations. For example, the original CPU utilization value might be between 0% and 100%. After normalization, the CPU utilization scores for all clusters will fall within a uniform 0-1 range, allowing for direct comparison of CPU utilization across different clusters. After normalization, a weighted average is calculated for the normalized metrics of each computing cluster to comprehensively reflect its computing power performance. The weighted average considers the relative importance of different metrics to computing power performance evaluation. For example, if CPU utilization is more critical in computing power evaluation, its weight will be greater than other metrics in the weighted average. By calculating the weighted average, each computing cluster will obtain a single computing power factor, intuitively representing its overall performance across the computing power dimension. The normalization and weighted averaging steps described above are repeated for all computing clusters to ensure that each cluster obtains a factor reflecting its computing power performance. In this way, the master server can compare and evaluate the computing power performance of different clusters based on the computing power factors of all clusters, providing important quantitative basis for subsequent resource scheduling and task allocation.

[0032] Optionally, the computing power metrics used for Compute calculations may include, but are not limited to, CPU utilization (%), expressed as... Memory utilization rate (%) is expressed as Disk I / O rate (MB / s), expressed as ; Video memory utilization rate (%), expressed as The computing power factor employs normalization logic and performs a conversion from negative to positive indicators. For example, the CPU utilization of any computing power cluster can be evaluated in the following way. Normalization is performed to obtain the CPU normalization index for any computing power cluster. ,in, This represents the minimum CPU utilization among multiple computing clusters within a predetermined time period (e.g., within 24 hours). This represents the maximum CPU utilization among multiple computing clusters within a predetermined time period. The memory utilization of any computing cluster can be calculated as follows: Normalization is performed to obtain the memory normalization index for any computing power cluster. ,in, This represents the minimum memory utilization rate among multiple computing clusters within a predetermined time period. This represents the maximum memory utilization rate among multiple computing clusters within a predetermined time period. The disk I / O rate of any computing cluster can be calculated as follows: Normalization is performed to obtain the disk I / O normalization index for any computing power cluster. ,in, This represents the minimum disk I / O rate among multiple computing clusters within a predetermined time period. This represents the maximum disk I / O rate among multiple computing clusters within a predetermined time period. The memory utilization of any given computing cluster can be calculated as follows: Normalization is performed to obtain the memory normalization index of any computing power cluster. ,in, This represents the minimum memory utilization rate among multiple computing clusters within a predetermined time period. This represents the maximum memory utilization rate among multiple computing clusters within a predetermined time period. The maximum and minimum values ​​for each of these metrics are dynamically updated; for example, they can be set to update every 5 minutes. Finally, the four normalized metrics are weighted and averaged in the same way to obtain the computing power factor for any given computing cluster. The corresponding formula is expressed as follows: .

[0033] In one optional embodiment, based on the computing power indicators, network indicators, and energy indicators corresponding to each of the multiple computing power clusters, the computing power factor, network factor, and energy factor corresponding to each of the multiple computing power clusters are determined, including: when there are multiple network indicators, the network factor of any computing power cluster is obtained based on the multiple network indicators of any computing power cluster in the following manner: normalizing the multiple network indicators of any computing power cluster to obtain multiple normalized network indicators, wherein the multiple network indicators include standard network latency and network jitter; performing a weighted summation operation on the multiple normalized network indicators to obtain a weighted network indicator; performing an exponential decay operation on the weighted network indicator based on a preset attenuation intensity coefficient to obtain the network factor of any computing power cluster; and obtaining the network factor corresponding to each of the multiple computing power clusters based on the network indicators corresponding to each of the multiple computing power clusters using the same method as obtaining the network factor of any computing power cluster.

[0034] Optionally, normalization refers to transforming the raw values ​​of network metrics such as network latency and jitter to the same comparison scale. Raw values ​​of network latency and jitter may vary due to differences in measurement units and environments; normalization eliminates these dimensional differences, making network metrics from different clusters comparable. For example, converting network latency and jitter into standardized scores means that lower scores indicate better network performance. Weighted summation, based on normalization, assigns weights to network latency and jitter, reflecting the difference in importance between these two types of network metrics in evaluating network performance. For example, the weight of network latency may be higher than that of network jitter, meaning that latency is a priority factor in network performance evaluation. The result of weighted summation is a composite score that combines the contributions of network latency and jitter, representing a quantitative indicator of the network performance of any computing power cluster. Exponential decay is used to emphasize the importance of lower network latency and jitter values. By applying an exponential decay function to weighted network metrics, clusters with particularly excellent network performance can be highlighted. (Attenuation strength coefficient) The strength of attenuation is determined by the magnitude of the attenuation. This value means that a slight increase in network latency and jitter will lead to a significant drop in the network factor, and vice versa. This approach is crucial for optimizing network resource scheduling because it helps the system prioritize computing clusters with the best network performance, especially important in network latency-sensitive applications. Extending this process to all computing clusters ensures that each cluster has a network factor reflecting its network performance. In this way, the master server can combine the network factors of all clusters, as well as computing power, energy, and service affinity factors, to make more comprehensive and accurate resource scheduling decisions to meet the needs and priorities of different services.

[0035] Optionally, the network metrics used for network factor calculation may include, but are not limited to, network latency (ms), expressed as... Network jitter (ms) is expressed as... The network factor employs normalization logic and converts negative indicators to positive ones, using exponential decay to enhance its low-latency advantage: the network factor of any computing power cluster The formula is expressed as follows: ,in, This represents the current network latency of any network cluster. This represents the current network jitter of any computing power cluster, which is normalized and mapped to the [0-100] range to avoid absolute values ​​affecting weight balance; These are the weighting coefficients for network latency and network jitter, which can be taken as... ; This represents the attenuation intensity coefficient, which can be set to the default value. ; This represents the maximum network latency among multiple computing clusters within a predetermined time period. This represents the maximum value of network jitter for each of the multiple computing clusters within a predetermined time period, and is updated every 5 minutes.

[0036] In one optional embodiment, based on the computing power indicators, network indicators, and energy indicators corresponding to each of the multiple computing power clusters, the computing power factor, network factor, and energy factor corresponding to each of the multiple computing power clusters are determined, including: when there are multiple energy indicators, the energy factor of any computing power cluster is obtained based on the multiple energy indicators of any computing power cluster in the following manner: normalizing the multiple energy indicators of any computing power cluster to obtain multiple normalized energy indicators, wherein the multiple energy indicators include carbon emission factors and electricity costs; performing a weighted average calculation on the multiple normalized energy indicators to obtain the energy factor of any computing power cluster; and obtaining the energy factor corresponding to each of the multiple computing power clusters based on the energy indicators corresponding to each of the multiple computing power clusters using the same method as obtaining the energy factor of any computing power cluster.

[0037] Optionally, energy indicators such as carbon emission factors and electricity costs can be transformed from their raw values ​​to a standardized range (e.g., 0 to 1). The main purpose of normalization is to remove dimensional differences between indicators, allowing different types of energy indicators to be compared and analyzed on the same scale. For example, carbon emission factors might originally be expressed in kilograms of carbon dioxide emissions (kgC). The energy efficiency factor is expressed as a unit of measurement, while the electricity cost is measured in yuan / kWh (CNY / kWh). Through normalization, these values ​​are converted into standardized scores reflecting energy efficiency and cost control. The weighted average calculation at this stage is performed on the normalized carbon emission factor and electricity cost. The aim is to comprehensively evaluate the energy efficiency and cost-effectiveness of any computing cluster based on their respective importance and business needs. The weights in the weighted average reflect different emphases on carbon emissions and cost control in energy management strategies. For example, if business needs prioritize green energy use, the weight of the carbon emission factor may be higher; conversely, if cost control is the primary consideration, the weight of the electricity cost will increase. Through this calculation, any computing cluster will obtain an energy factor that integrates its energy efficiency and cost control. Applying this process to all computing clusters ensures that each cluster has a quantified energy factor. This allows for comparison and decision-making through a unified energy factor standard, whether for cross-cluster resource scheduling or assessing cluster energy efficiency. Ultimately, all computing clusters will have their own energy factors, and these scores will become the key basis for the master server or scheduling system to make energy-based scheduling decisions.

[0038] Optionally, the energy indicators used for calculating the energy factor may include, but are not limited to, carbon emission factors. , represented as Electricity cost in yuan, expressed as The energy factor employs normalization logic and performs a conversion from negative to positive values. The carbon emission intensity index for each cluster is calculated as follows: ,in, The total carbon emission intensity of any computing cluster during a predetermined period (e.g., the next 24 hours) is the total carbon emission intensity of all task loads. This represents the task load of any computing cluster at a future sampling time t. The task load sequence is converted into task energy consumption load (kWh) by measuring the time-series service requests from each regional server. The regional carbon emission factor is related to the type and proportion of green electricity infrastructure in the power grid of the region where any computing cluster is located. The unit of the regional carbon emission factor is: Therefore, the normalized carbon emission intensity is calculated as follows: ,in, Indicates normalized carbon emission intensity, The minimum carbon emission intensity of all computing clusters deployed on servers in the current region; This represents the maximum carbon emission intensity of all computing clusters deployed on servers in the current region. The electricity cost for each computing cluster is calculated as follows: ,in, This represents the total electricity cost of all tasks on any computing cluster within a predetermined time period (e.g., the next 24 hours). This represents the task load of any computing cluster at a future sampling time t. The task load sequence is converted into task energy consumption load (kWh) by measuring the time-series task requests from each regional server. Let represent the real-time electricity price for any computing cluster at time t, where the price fluctuates over time. The normalized electricity cost calculation for any computing cluster is as follows: ,in, This represents the minimum electricity cost of all computing clusters deployed on servers in the current region. The maximum electricity cost for all clusters deployed on servers in the current region; energy factor. It is obtained by weighting two normalized energy indicators, namely normalized carbon emission intensity and normalized electricity cost, and the corresponding formula is expressed as follows: .

[0039] Step S106: The computing power factor, network factor, and energy factor corresponding to each of the multiple computing power clusters are sent to the main server. The main server uses these factors to determine the cluster score for each of the multiple computing power clusters. The cluster score is obtained based on the scheduling factor and scheduling factor weight of the corresponding computing power cluster. The scheduling factor includes the computing power factor, network factor, energy factor, and service affinity factor. The service affinity factor is used to indicate the similarity between the service provided by the corresponding computing power cluster and the current service request. The scheduling factor weight is obtained based on the business scenario adjustment coefficient of the corresponding computing power cluster. The scheduling factor weight includes the computing power factor weight, network factor weight, energy factor weight, and service affinity factor weight. The business scenario adjustment coefficient is used to adjust the corresponding scheduling factor weight according to the business scenario requirements of the corresponding computing power cluster. The cluster score of each of the multiple computing power clusters is used to determine the target computing power cluster for executing the current service request from among the multiple computing power clusters.

[0040] In this step, the scores for computing power, network, and energy dimensions of each computing cluster are uploaded to the central management or scheduling master server. After receiving this data, the master server combines the service affinity factor with scheduling factor weights adjusted based on the current business scenario to comprehensively evaluate the scheduling value (i.e., cluster score) of each computing cluster. The service affinity factor reflects the degree of matching between the services provided by the cluster and the current service request; it is calculated by comparing service tags or attributes, helping to improve the efficiency and performance of service scheduling. The master server calculates scheduling factors to comprehensively evaluate the adaptability and value of each computing cluster to the current service request. The scheduling factor weights can be dynamically adjusted according to the current business scenario requirements, resource allocation goals, and constraints. For example, in cross-domain disaster recovery scenarios, the weights of computing power and network may be increased to prioritize business continuity; while in scenarios of sudden wind power reduction or carbon emission assessment, the weights of energy and affinity factors may be more important to ensure the economic and environmental friendliness of scheduling decisions. By combining scheduling factors with their weights, the master server can obtain a comprehensive score (i.e., cluster score) for each cluster. Based on these comprehensive scores, it can intelligently select the computing power cluster most suitable for executing the current service request, achieving efficient resource allocation and task scheduling. The resource scheduling method in this embodiment, through a hierarchical architecture and multi-dimensional evaluation, combined with a dynamic weight adjustment mechanism, achieves complex computing network resource scheduling, aiming to optimize resource utilization, improve service quality and response speed, while controlling costs and environmental impact.

[0041] Through steps S102 to S106, efficient, intelligent, and smooth resource scheduling for time-series tasks can be achieved through hierarchical and domain-based management and dynamic determination of scheduling factor weights. This optimizes the allocation of computing network resources, ensuring the flexibility of resource scheduling and rapid response to service requests, thereby improving resource scheduling efficiency and resource utilization. Ultimately, this solves the technical problems of signaling overload and poor resource scheduling flexibility caused by centralized management architecture in computing network resource scheduling in related technologies.

[0042] According to an embodiment of the present invention, another embodiment of a method for scheduling and processing computing network energy resources is also provided. Figure 2 This is a flowchart of another computing network energy resource scheduling processing method according to an embodiment of the present invention, such as... Figure 2 As shown, the method includes the following steps:

[0043] Step S202: Obtain the scheduling factors corresponding to each of the multiple computing power clusters. The scheduling factors include computing power factors, network factors, energy factors, and service affinity factors. The computing power factors are obtained by scoring the computing power indicators of the corresponding computing power clusters through the regional server. The network factors are obtained by scoring the network indicators of the corresponding computing power clusters through the regional server. The energy factors are obtained by scoring the energy indicators of the corresponding computing power clusters through the regional server. The service affinity factor is used to indicate the similarity between the services provided by the corresponding computing power clusters and the current service request.

[0044] Optionally, the execution entity for steps S202 to S208 can be the main server. Computing power, network, and energy-related metrics are collected from each computing cluster and quantitatively scored by a regional server. Specifically, the computing power factor can be obtained based on computing power metrics such as CPU utilization and memory utilization; the network factor can be obtained, but is not limited to, based on network performance metrics such as network latency and bandwidth utilization; the energy factor can be obtained, but is not limited to, based on energy metrics such as carbon emissions and electricity costs; and the service affinity factor assesses the matching degree in characteristics between services within the cluster and new service requests. These scores provide a quantitative assessment reflecting the resource status and capabilities of each computing cluster in different dimensions. By setting the computing power factor, network factor, and energy factor to be obtained by the regional server and sent to the main server, the entire system adopts a hierarchical and domain-based management architecture. The normalization calculation of the computing power factor, network factor, and energy factor (i.e., computing power metrics, network metrics, and energy metrics) has been completed at the regional management layer, avoiding the risk of signaling storms caused by the periodic reporting of all data when cluster resources or site nodes are at a massive scale.

[0045] In one optional embodiment, obtaining the scheduling factors corresponding to each of the multiple computing power clusters includes: obtaining the service affinity factor of any computing power cluster by: determining the label similarity between multiple services provided by any computing power cluster and the current service request, wherein the label similarity represents the similarity between the service label of the corresponding service provided by any computing power cluster and the service label of the current service request, wherein the service label is at least used to indicate the service type of the corresponding service; determining the service similarity between multiple services and the current service request based on the label similarity between multiple services and the service before the current service request; and determining the service affinity factor of any computing power cluster based on the service similarity between multiple services and the service before the current service request.

[0046] Optionally, the service tags of all services in the computing power cluster are compared with the service tag of the current service request. Service tags, in addition to service type, may also include, but are not limited to, service runtime environment requirements, service quality level, and resource consumption characteristics. These tags describe the characteristics and requirements of the service. By calculating the tag similarity between services, the degree of matching in characteristics between the services already provided in the cluster and the current service request can be assessed, and whether they share similar technical or environmental requirements. For example, if the current service request involves training a deep learning model, and multiple services similar to machine learning have been deployed in the cluster, then the tags of these services will have a high similarity to the tags of the current service request. Based on the tag similarity, the service similarity between the current service request and multiple existing services in the cluster is further determined. By comparing the similarity between the current request and previous services, it is possible to identify which services have a high relevance and affinity to the current request. For example, if previous service requests were all related to deep learning, then these services will have higher affinity scores and can better support similar new requests. The service affinity factor, based on the results calculated in the first two steps, comprehensively reflects the affinity between all services in any computing power cluster and the current service request. By weighted averaging or selecting the maximum value based on the similarity between each service and the current service request, the overall affinity score of the cluster can be obtained. A higher score indicates that the cluster is better able to meet the requirements of the current service request in terms of service type and technology stack, thus giving it a higher priority in scheduling decisions. The calculation of the service affinity factor considers the clustering effect and historical context of services, helping to improve the efficiency and effectiveness of resource scheduling, reduce conflicts and resource waste between services, and effectively improve scheduling accuracy and response speed, especially in scenarios involving large-scale, multi-type service requests.

[0047] In an optional embodiment, determining the service similarity between multiple services and previous services based on the tag similarity between multiple services and the current service request includes: when each service in any computing power cluster has multiple service tags, and the current service request has multiple service tags, obtaining the service similarity between any service and the current service request in the following manner: determining the maximum tag similarity corresponding to each of the multiple service tags of the current service request from the tag similarity set corresponding to each of the multiple service tags of the current service request, wherein the tag similarity set includes the tag similarity between the corresponding tag of the current service request and the multiple service tags of any service; determining the service similarity between any service and the current service request based on the average of the maximum tag similarity corresponding to each of the multiple service tags of the current service request; and obtaining the service similarity between multiple services and previous services based on the same method used to obtain the service similarity between any service and the current service request.

[0048] Optionally, we first focus on each service tag of the current service request, which could include multiple tags such as AI processing power, GPU requirements, and memory-intensive tasks. Then, for each service in the cluster, we calculate its similarity to each service tag of the current service request, forming a set. Within this set, we identify the maximum similarity between each service tag of the current service request and a specific service in the cluster, reflecting the attributes of that service that best matches the current request. After determining the maximum similarity between each service tag and a specific service in the cluster, we then perform statistical processing on these maximum similarities. Specifically, we average the maximum similarities of all service tags in the current service request to obtain a comprehensive similarity index. This average is considered the service similarity between any service and the current service request, reflecting the degree of matching between services under various characteristics and requirements. We apply this process to all services in any computing power cluster, calculating their service similarity to the current service request one by one. In this way, we obtain the set of similarities between all services in the computing power cluster and the current request. These similarity sets consider not only the characteristics of the services themselves but also the relationships between services, providing the necessary input for subsequently determining service affinity factors. In other words, each service will receive a service similarity score with the current request, which will serve as the basis for evaluating service affinity. The entire process, by quantifying the similarity of service tags, can more accurately assess the affinity between services in any computing power cluster and new service requests, thus prioritizing service clusters with high affinity in resource scheduling decisions. This method is particularly suitable for handling services with complex attributes and tags, effectively identifying and scheduling resources that best match the current service request, improving scheduling efficiency and resource utilization, while reducing unnecessary conflicts and resource waste between services.

[0049] Optionally, the service affinity factor refers to whether services within the same computing power cluster have similarity and clustering effects. The calculation of the service affinity factor can be divided into three layers: The first layer calculates the similarity at the tag level, specifically as follows: Service tags can be converted into vectors using the pre-trained word vector model BERT, and the tag similarity of each tag pair (consisting of a service tag from any service in any computing power cluster and a service tag from the current service request) is calculated as follows: ,in, The label similarity between a service label of any service in any computing power cluster and a service label of the current service request is obtained by calculating the cosine similarity between every two label vectors. This indicates a specific service tag in the current service request ReqTag, which can be obtained through the service management module of the central platform (i.e., the main server). This indicates a service tag of another service SvcTag deployed in the current computing power cluster, which can be obtained through the service management of the central platform. These represent the i-th label vectors converted from the two service labels by the BERT model.

[0050] The second level calculates the similarity between each service. For each service in the current computing power cluster, the similarity between all its service tags and the service tag of the current service request is calculated, and the maximum value is taken. The service tag of the current service request is then summed with the highest similarity scores across all services in the computing power cluster, and the average is taken. The specific formula is as follows: ,in, This refers to any service tag for any service within the current computing power cluster. This represents all service tags for any service within the current computing power cluster; Indicates the number of service tags in the current service request; This represents the similarity score between the final current service request and each service within the current computing power cluster.

[0051] The third level calculates the service similarity between the current service request and each service within each computing power cluster. The highest score among all services within the computing power cluster is taken as the initial service affinity score for the cluster. The specific formula is as follows: ,in, This indicates the service similarity between the service request and any service deployed within the current computing power cluster; This represents the initial service affinity score of the current computing power cluster for the current service request; finally, this score is normalized to obtain the final service affinity factor. The specific formula is as follows: ,in, This represents the highest initial service affinity score among all computing power clusters at the central level. This represents the lowest initial service affinity score among all computing power clusters at the central level.

[0052] Step S204: Based on the business scenario adjustment coefficients corresponding to each of the multiple computing power clusters, determine the scheduling factor weights corresponding to each of the multiple computing power clusters. The scheduling factor weights include computing power factor weights, network factor weights, energy factor weights, and service affinity factor weights. The business scenario adjustment coefficients are used to adjust the corresponding scheduling factor weights according to the business scenario requirements of the corresponding computing power clusters.

[0053] Optionally, the business scenario adjustment coefficient may include, but is not limited to, adjustment coefficients for cross-domain disaster recovery scenarios, wind power reduction scenarios, and carbon emission assessment scenarios, used to quantify the different business scenario requirements of each computing power cluster. This step, based on the scheduling factors, determines the scheduling factor weights for each computing power cluster according to specific business scenario requirements. Scheduling factor weights include computing power factor weights, network factor weights, energy factor weights, and service affinity factor weights. The business scenario adjustment coefficient reflects the importance of different factors in the current scheduling decision. For example, in a business scenario with high network demand, the network factor weight may be increased, while the energy factor weight may be relatively decreased. By dynamically adjusting the weights, it can be ensured that the scheduling decision better aligns with current business needs and resource constraints.

[0054] Optionally, the method in this embodiment implements different indicator collection, resource scoring, and weight calculation at different platform levels. This avoids the reporting of massive monitoring resources at the lower level, while efficiently achieving hierarchical and domain-based management and scoring of resources. Figure 3 This is a schematic diagram of an optional hierarchical and domain-based scheduling factor and weight determination framework according to an embodiment of the present invention, such as... Figure 3 As shown, the regional platform (i.e., the regional server) collects and calculates the scores for computing power factors, network factors, and energy factors, avoiding the reporting of massive amounts of monitoring data to the central platform (i.e., the main server). However, the regional platform needs to report critical anomalies that could cause computing cluster service failures, such as CPU overload, to the central platform (i.e., the main server). The central platform performs affinity factor score calculations because cluster service labels are relatively stable and the data volume is small. On the central platform, for cluster service failure indicators or energy anomalies such as sudden wind power reduction reported by the regional platform, the weights of each scheduling factor are generated through dynamic game theory, considering the correlation between factors in different business scenarios.

[0055] This embodiment proposes a dynamic weight generation method to address typical business scenario requirements: cross-domain disaster recovery, wind power reduction, and carbon emission assessment. It dynamically adjusts weights by real-time sensing of key indicators and system status on the central side (i.e., the main server side). Typical business requirements are transformed into objective indicators. For example, cross-domain disaster recovery requirements can be quantified using the cross-domain disaster recovery scenario adjustment coefficient DA. When key computing power and network indicators in certain regions show high-risk warnings, the upgrade platform needs to report to the central platform. The failure rate is then assessed on the centralized platform, and the corresponding formula is as follows: Demand during a sudden reduction in wind power can be quantified using the wind power reduction scenario adjustment coefficient WD, which is used to assess the fluctuation of wind power energy and reduce the impact of wind power fluctuations on dispatch decisions. The corresponding formula is as follows: Carbon emission assessment scenarios can be quantified using the carbon emission assessment scenario adjustment coefficient CD, which is used to assess the quota requirements for green energy, thereby tilting scheduling decisions towards the carbon emission dimension. The corresponding formula is as follows: .

[0056] In an optional embodiment, before determining the scheduling factor weights corresponding to each of the multiple computing power clusters based on the business scenario adjustment coefficients (including cross-domain disaster recovery scenario adjustment coefficients, wind power reduction scenario adjustment coefficients, and carbon emission assessment scenario adjustment coefficients), the method further includes: determining the cross-domain disaster recovery scenario adjustment coefficients corresponding to each of the multiple computing power clusters based on their respective failure rates, wherein the cross-domain disaster recovery scenario adjustment coefficients are used to quantify the adjustment needs of the corresponding computing power clusters in terms of disaster recovery and business continuity; determining the wind power reduction scenario adjustment coefficients corresponding to each of the multiple computing power clusters based on their respective wind power volatility, wherein the wind power volatility represents the wind power volatility in the region where the corresponding computing power cluster is located, and the wind power reduction scenario adjustment coefficients are used to quantify the adjustment needs of the corresponding computing power clusters in the face of unstable renewable energy supply; and determining the carbon emission assessment scenario adjustment coefficients corresponding to each of the multiple computing power clusters based on their respective remaining carbon emission allowances, wherein the carbon emission assessment scenario adjustment coefficients are used to quantify the adjustment needs of the corresponding computing power clusters in meeting carbon emission targets.

[0057] Optionally, but not limited to, monitoring the failure rate of each computing cluster can be used to assess their performance in disaster recovery and business continuity. A higher failure rate indicates poorer stability, potentially preventing them from maintaining normal business operations in the event of sudden failures. The cross-domain disaster recovery scenario adjustment coefficient is designed to address this decline in stability. It increases the scheduling weight of stable clusters and decreases the weight of unstable clusters, ensuring that resources are prioritized for allocation to more reliable and stable computing clusters in disaster recovery scenarios, thus guaranteeing business continuity and data security. The wind power reduction scenario adjustment coefficient is particularly important when facing the instability of renewable energy, especially wind power supply. Wind power volatility reflects the degree of change in wind power supply over time in the region where the computing cluster is located. When wind power supply is unstable, i.e., when wind power volatility is high, the energy supply of the computing cluster will also be affected, potentially leading to fluctuations in computing power supply and increased costs. The wind power reduction scenario adjustment coefficient measures the adaptability and cost-effectiveness of each cluster in such unstable environments. By adjusting the energy factor weight, clusters with lower costs or more stable energy supplies can be prioritized when wind power supply fluctuates, maintaining the efficiency and economy of computing power services. Against the backdrop of advocating for green and low-carbon development, carbon emissions from data centers have become a crucial consideration. Remaining carbon emission allowances reflect the ability of computing clusters to meet emission reduction targets—that is, how much computing power can continue to be used without violating emission reduction policies within given carbon emission limits. Carbon emission assessment scenario adjustment coefficients are adjusted based on remaining carbon emission allowances, encouraging the use of computing clusters with lower carbon emissions for scheduling. This not only contributes to environmental protection but also avoids additional costs incurred due to exceeding carbon emission limits, promoting both economic and environmental sustainable development. Through this series of business scenario adjustment coefficients, this embodiment can dynamically adjust the scheduling factor weights of each computing cluster according to different environments and needs, achieving more refined and efficient resource management. In practical applications, these adjustment coefficients can help the scheduling system make more reasonable and timely decisions when facing various complex scenarios such as disaster recovery, energy fluctuations, and carbon emission limits, ensuring maximum efficiency in resource utilization while balancing business continuity and environmental responsibility.

[0058] In one optional embodiment, the scheduling factor weights corresponding to each of the multiple computing power clusters are determined based on the business scenario adjustment coefficients corresponding to each of the multiple computing power clusters. This includes: determining the weight adjustment coefficients corresponding to each of the multiple computing power clusters based on the business scenario adjustment coefficients corresponding to each of the multiple computing power clusters, wherein the weight adjustment coefficients include computing power adjustment coefficients, network adjustment coefficients, energy adjustment coefficients, and service affinity adjustment coefficients; and optimizing the initial factor weights corresponding to each of the multiple computing power clusters based on the weight adjustment coefficients corresponding to each of the multiple computing power clusters to obtain the scheduling factor weights corresponding to each of the multiple computing power clusters, wherein the initial factor weights include initial computing power weights, initial network weights, initial energy weights, and initial service affinity weights.

[0059] Optional business scenario adjustment coefficients, such as those for cross-domain disaster recovery, sudden wind power reduction, and carbon emission assessment, reflect the performance and applicability of computing clusters in specific scenarios. This stage involves converting these business scenario adjustment coefficients into specific weight adjustment coefficients. For example, if a computing cluster is located in an area vulnerable to natural disasters, its cross-domain disaster recovery adjustment coefficient may be higher. This means that during scheduling, the cluster's computing power and network weights will be enhanced to ensure business continuity even during disasters. Initial factor weights are a set of pre-defined weights corresponding to four dimensions: computing power, network, energy, and service affinity, used to evaluate the basic scheduling priority of the computing cluster. When considering adjustment coefficients for specific business scenarios, these initial weights need to be adjusted to reflect the new scheduling priorities and objectives. Optimized weights, such as the optimized computing power factor weight corresponding to the computing power adjustment coefficient, and the optimized network factor weight corresponding to the network adjustment coefficient, will be used in the next step of cluster score calculation, making scheduling decisions more closely aligned with current actual needs and environmental conditions. By following the steps described above, the scheduling factor weights of the computing cluster can be dynamically adjusted based on current business scenarios and environmental changes. This ensures that the resource scheduling strategy not only meets basic computing power, network, energy, and service requirements but also flexibly responds to special circumstances such as natural disasters, unstable energy supply, and carbon emission restrictions. This approach enhances the intelligence and adaptability of resource scheduling, improving the efficiency and sustainability of data center operations.

[0060] In one optional embodiment, the weight adjustment coefficients corresponding to each of the multiple computing power clusters are determined based on the business scenario adjustment coefficients corresponding to each of the multiple computing power clusters, including: determining the computing power adjustment coefficient, network adjustment coefficient, and service affinity adjustment coefficient corresponding to each of the multiple computing power clusters based on the cross-domain disaster recovery scenario adjustment coefficients corresponding to each of the multiple computing power clusters; and determining the energy adjustment coefficient corresponding to each of the multiple computing power clusters based on the wind power reduction scenario adjustment coefficients and carbon emission assessment scenario adjustment coefficients corresponding to each of the multiple computing power clusters.

[0061] Optionally, when facing cross-domain disaster recovery scenarios, the stability and rapid recovery capabilities of the computing cluster should be prioritized. The cross-domain disaster recovery scenario adjustment coefficient reflects the reliability level of the computing cluster in terms of disaster recovery and business continuity. If a computing cluster has a high cross-domain disaster recovery scenario adjustment coefficient, it indicates that it has good disaster recovery capabilities. Therefore, the computing power adjustment coefficient and network adjustment coefficient may be increased to enhance the cluster's weight in scheduling decisions and ensure rapid business recovery in the event of a disaster. At the same time, the service affinity adjustment coefficient may be decreased, meaning that under the priority of disaster recovery, service affinity (i.e., the similarity between services) may not be a primary consideration for the time being, in order to reduce the constraints of cross-domain scheduling and allow services to be more flexibly transferred to other stable clusters. When dealing with scenarios with unstable renewable energy supply or carbon emission constraints, energy efficiency needs to be optimized to reduce dependence on fossil fuels. The wind power reduction scenario adjustment coefficient and the carbon emission assessment scenario adjustment coefficient reflect the adaptability and contribution of the computing cluster in the face of energy fluctuations and carbon emission constraints. When the adjustment coefficient for a computing cluster in a scenario of sudden wind power reduction is high, it means that the wind power supply in the region where the cluster is located is unstable. In this case, the energy adjustment coefficient may be adjusted to reduce the energy dependence on the cluster. On the other hand, when the adjustment coefficient for a computing cluster in a scenario of carbon emission assessment is high, it indicates that the cluster has limited ability to meet carbon emission targets. The energy adjustment coefficient will be adjusted to reduce its weight in scheduling decisions, thereby prioritizing the scheduling of greener and more environmentally friendly computing resources.

[0062] By dynamically adjusting these weighting coefficients, we can more intelligently respond to various business scenarios and environmental changes, ensuring that resource allocation meets current needs while maintaining system stability and operational efficiency. This approach improves the flexibility and adaptability of data center computing resource scheduling, especially in the face of disaster recovery, energy fluctuations, and environmental policy constraints, enabling more rational and timely decisions to ensure service continuity and the sustainable development of the data center.

[0063] Optional, Figure 4 This is a schematic diagram of an optional dynamic adjustment weight determination framework according to an embodiment of the present invention, such as... Figure 4 As shown, the business scenario requirements of each computing power cluster are determined through the state awareness layer. In the weight calculation layer, the adjustment coefficients of each scheduling factor can be determined based on the business scenario. Considering that the computing power adjustment coefficient is positively correlated with cross-domain disaster recovery scenarios, the network adjustment coefficient is positively correlated with cross-domain disaster recovery scenarios, the energy consumption adjustment coefficient is positively correlated with wind power reduction scenarios and carbon emission assessment scenarios, and the service affinity adjustment coefficient is negatively correlated with cross-domain disaster recovery scenarios, setting corresponding adjustment coefficients for each scheduling factor can be achieved by designing a nonlinear adjustment function to respond to and adapt to changes in business scenarios. The adjustment coefficient for cross-domain disaster recovery scenarios can be set as follows: For tasks requiring disaster recovery, increasing the computing power factor can ensure seamless switching and rapid recovery of current services, while keeping output within a certain range. The network adjustment coefficient can be set to... Improving the network factor for tasks requiring disaster recovery can ensure seamless switching and rapid recovery of current services, while keeping output within a certain range. The energy regulation coefficient (or energy consumption regulation coefficient) can be set to... To address scenarios of sudden wind power reduction and carbon emission spikes, a smooth response is implemented to avoid abrupt changes and to constrain the output within a certain range. A service affinity adjustment coefficient can be set to... For cross-domain disaster recovery tasks, the constraints of the region are reduced, allowing migration to other cluster nodes.

[0064] Optionally, after obtaining the adjustment coefficients of the four factors, the temporary weight of each scheduling factor can be calculated as follows: ,in, For each scheduling factor, the initial weight can be set to the same value, i.e., 0.25, if there are no scenario requirements. These are the adjustment coefficients calculated for each factor above. The temporary weights are assigned to each scheduling factor. The sum of these temporary weights is then calculated. In the constrained optimization layer, the normalized weights of each scheduling factor are recalculated by normalizing the temporary weights of the initially obtained scheduling factors. Further boundary constraints and redistribution are applied to the obtained normalized weights. Specifically, when the weight of a factor is less than 0.1, the minimum impact of that weight needs to be guaranteed. This can be achieved by adjusting the normalized weights of each scheduling factor as follows: Optimization is performed to obtain the optimized weights of each scheduling factor. , Using the above method, it is possible to determine whether the weight factors after initial normalization need to be truncated. When the normalized weight is less than 0.1, a minimum value of 0.1 is forcibly assigned, and normalization is calculated again. This continues until the optimized weight of each scheduling factor is greater than or equal to 0.1, and the final factor weight of each scheduling factor is obtained as follows. ,in, This represents the sum of the optimized weights of each scheduling factor.

[0065] Step S206: Based on the scheduling factors corresponding to each of the multiple computing power clusters and the scheduling factor weights corresponding to each of the multiple computing power clusters, obtain the cluster scores corresponding to each of the multiple computing power clusters.

[0066] In this step, the cluster score can be obtained by combining the scheduling factor with its weights, such as through a weighted calculation. The cluster score for each computing cluster is influenced by its scores and weights across four dimensions: computing power, network, energy, and service affinity. More specifically, the cluster score is the sum of the weighted factors; for example, the cluster score for each computing cluster can be obtained as follows:

[0067] ;

[0068] in, This represents the cluster score of any computing power cluster. , , , In order, they are computing power factor, network factor, energy factor, and service affinity factor; , , , The weights are, in order, the computing power factor weight, the network factor weight, the energy factor weight, and the service affinity factor weight. The scheduling factor weight reflects the importance of different dimensions in the total score. Through this calculation, each computing cluster will ultimately obtain a comprehensive score, which intuitively represents its adaptability and priority to the current service request.

[0069] Step S208: Based on the cluster scores corresponding to each of the multiple computing power clusters, determine the target computing power cluster for executing the current service request from among the multiple computing power clusters.

[0070] In this step, the highest-scoring computing power cluster can be selected as the target computing power cluster based on a comparison of cluster scores to execute the current service request. This ensures that the scheduling decision considers both resource performance and cost, as well as the specific needs of the service request. The selection of the target computing power cluster is the core of the entire resource scheduling process, aiming to achieve optimal resource allocation and improve the overall system efficiency and service quality through quantitative evaluation and dynamic weight adjustment. The method in this embodiment not only considers the multi-dimensional performance of resources but also incorporates the dynamic needs of the business scenario. Through quantitative scoring and weight adjustment mechanisms, it ultimately determines the most suitable computing power cluster to execute the specific service request, achieving intelligent and efficient resource scheduling.

[0071] In an optional embodiment, when the business scenario adjustment coefficients include cross-domain disaster recovery scenario adjustment coefficients, wind power reduction scenario adjustment coefficients, and carbon emission assessment scenario adjustment coefficients, the target computing power cluster for executing the current service request is determined from the multiple computing power clusters based on the cluster scores corresponding to each of the multiple computing power clusters. This includes: obtaining the weight of the previous cluster corresponding to each of the multiple computing power clusters, wherein the weight of the previous cluster is obtained through the previous service request that executed the current service request; summing the weight of the previous cluster corresponding to each of the multiple computing power clusters with the corresponding cluster scores to obtain the current cluster weight corresponding to each of the multiple computing power clusters; and determining the target computing power cluster from the multiple computing power clusters based on the current cluster weight corresponding to each of the multiple computing power clusters.

[0072] Optionally, the previous cluster weight is a historical value, determined based on the amount of service requests allocated to each computing cluster in the previous scheduling decision and the historical scheduling performance. This weight reflects the performance of the computing cluster in previous service request scheduling, including its processing power, stability, and response speed. For example, if a cluster performed well in handling similar tasks in the past, its previous cluster weight may be higher. The previous cluster weight is combined with the current cluster score based on four dimensions: computing power, network, energy, and service affinity, to generate a new current cluster weight. This summation operation considers the past performance of the computing cluster as well as the evaluation based on the current business scenario and resource status. By integrating historical scheduling performance with current resource adaptability, the current cluster weight can more comprehensively reflect the overall capability of the computing cluster in executing current service requests. For example, a computing cluster may receive a high score due to its powerful processing power, but if its previous cluster weight is low (possibly due to past scheduling instability), its current cluster weight may not be particularly outstanding. The final selection of the target computing cluster is not only based on the current resource status and business scenario but also considers historical scheduling performance. The computing cluster with the highest current cluster weight will be selected as the target for executing the current service request. This method ensures the balance and fairness of resource scheduling in long-term operation, avoids excessive reliance on certain clusters, and dynamically adjusts the scheduling strategy based on current business needs and resource conditions, improving scheduling efficiency and resource utilization. Through the above process, the current cluster weight of each computing cluster can be dynamically calculated by combining historical scheduling effects, current resource status, and business scenarios, thereby making more informed and effective resource allocation decisions. This method is particularly suitable for scenarios that handle large-scale, multi-type service requests, improving scheduling accuracy and response speed while ensuring the long-term stability and efficient utilization of computing resources.

[0073] Optionally, assume that the total number of clusters corresponding to the regional servers is k, and assume that the basic weight of each cluster is: The base weight score represents the current cluster's request processing capability based on the scheduling strategy, and is equal to the current cluster's score, i.e.: The total weight is the sum of all basic weights, that is: The weight of the cluster in the current round is: The initial value is set to 0, and it changes after each decision, i.e., after each service request is executed. The current cluster weight is updated based on the base weight, using the following formula: The cluster with the highest current cluster weight is selected as the node for service request scheduling (i.e., the target computing power cluster). The corresponding formula is expressed as follows: This means that the currently selected cluster is the one with the highest weight (i.e., the target computing power cluster), indicating that the current cluster is the most worthy of being selected. After making the decision on the current service request, the weight information of the selected node (i.e., the target computing power cluster) needs to be updated. This weight update process can be done by checking the current cluster weight of the selected node. Subtract the total weight, which is the updated weight of the selected node. It can be obtained in the following way: After updating the cluster weights, when the next service request is received, it is treated as the new current service request, and the computing power resource scheduling process continues for this new current service request until all service requests have been scheduled. This approach ensures that the policy-based scoring of each cluster has an impact on the final request, and also guarantees that each service request is evenly allocated to different computing power cluster resources.

[0074] Through steps S202 to S208, efficient, intelligent, and smooth resource scheduling for time-series tasks can be achieved through hierarchical and domain-based management and dynamic determination of scheduling factor weights. This optimizes the allocation of computing network resources, ensuring the flexibility of resource scheduling and rapid response to service requests, thereby improving resource scheduling efficiency and resource utilization. Ultimately, this solves the technical problems of signaling overload and poor resource scheduling flexibility caused by centralized management architecture in computing network resource scheduling in related technologies.

[0075] Based on the above embodiments and optional embodiments, the present invention proposes an optional implementation method for computing network energy resource scheduling and processing. Figure 5 This is an optional overall system architecture diagram according to an embodiment of the present invention, and the method can be applied to, for example... Figure 5 The system architecture shown is divided into three layers: the infrastructure layer, the regional management layer, and the central management layer. The overall functions are as follows: The infrastructure layer refers to the underlying site resources, managed in the form of computing power clusters. A computing power cluster can contain multiple adjacent data center nodes, where:

[0076] The regional management layer, operating on a regional basis, manages the massive computing power clusters within that region. It includes four modules: computing power management, network management, site management, and scheduling. The computing power management module manages cluster resources within the region, monitors the computing power metrics of each cluster, and assesses the energy and computational load of computing tasks based on task registration and request information. The network management module manages network devices within the region and monitors key network metrics for each cluster. The site management module manages site resources and related infrastructure within the region, including equipment models, quantities, site locations, energy infrastructure, and electricity cost management. The scheduling module calculates regional-level scheduling factor scores to avoid the need for periodic reporting of massive amounts of information, including computing power factors, network factors, and energy consumption factors.

[0077] The central management layer is used for service registration, business-oriented global information scheduling, and management of critical information reporting. It includes a scheduling engine module, a service management module, and a resource management module. The scheduling engine module generates dynamic game weights (i.e., the weights of each scheduling factor) based on the scenarios described in the resource management module. Then, based on these scheduling factor weights, it calculates the score (i.e., cluster score) for each computing cluster using a multi-factor fusion algorithm. Finally, it uses a smoothed weighted round-robin algorithm to select nodes (i.e., computing clusters). The service management module registers different services and describes typical service scenarios. It receives time-series-based service requests and forwards these requests to the nodes (i.e., computing clusters) selected by the scheduling algorithm. The resource management module clarifies resource scheduling scenarios based on key anomaly indicators and constraint configuration conditions reported by regional resources, such as carbon emission assessment requirements, sudden wind power reduction scenarios, and cross-domain disaster recovery scenarios.

[0078] Figure 6 This is an optional hierarchical and domain-based system architecture diagram according to an embodiment of the present invention. The entire system adopts a hierarchical and domain-based management architecture. At the regional management level, the normalization calculation of computing power factors, network factors, and energy factors has been completed, avoiding the risk of signaling storms caused by the periodic reporting of all data when cluster resources or site nodes are at a massive scale. At the central management level, service affinity factors (i.e., service affinity indicators) and score calculations are processed, effectively achieving globally optimal scheduling. At the same time, key anomaly indicators are detected, thereby ensuring the efficiency and accuracy of overall scheduling. Figure 7 This is a flowchart of an optional computing network energy resource scheduling processing method according to an embodiment of the present invention, such as... Figure 7 As shown, based on the above functions and architecture, the entire scheduling process for the current service request is described as follows:

[0079] Step 1: [Service Management Module] Register the service on the central platform and describe the task type, such as AI training tasks, model size, number of parameters, and computational accuracy. Also, upload a time-series-based service allocation request.

[0080] Step 2: [Computing Power Management Module] In the computing power module, by combining the information of resource computing devices in different computing power clusters, the energy consumption load of the current task request can be evaluated.

[0081] Step 3-1: [Computing Power Management Module] Collects and monitors the metrics of computing power resources, namely computing power metrics, which may include, but are not limited to: CPU utilization, memory utilization, disk utilization, and video memory utilization.

[0082] Step 3-2.1: [Site Management Module] Calculate the electricity cost based on the energy consumption load of the computing power and the energy facilities of the site.

[0083] Step 3-2.2: [Site Management Module] Based on the site energy configuration type and status of each computing power cluster resource, provide the carbon emission factor (i.e., carbon emission factor), and use electricity cost and carbon emission factor as energy indicators.

[0084] Step 3-3: [Network Management Module] Collects and monitors network resource metrics, specifically network indicators, including network jitter and network latency.

[0085] Step 4: [Scheduling Module] Based on computing power, network, and energy metrics, the scheduling factors are scored and normalized at the regional level to avoid reporting massive amounts of information to the central side. Only the scoring information for each factor of each cluster resource needs to be reported, along with any sudden changes in key abnormal indicators. The specific methods for obtaining the computing power factor score, network factor score, and energy factor score are the same as in the previous embodiments and will not be repeated here.

[0086] Step 5-1.1: [Resource Management Module] Based on the key fault indicators reported by the regional management layer (i.e., regional server), such as regional node failures, combined with specific constraints configured by the user, such as: cross-domain disaster recovery scenarios (cluster resource node failures), sudden reduction in wind power scenarios, and carbon emission priority scenarios.

[0087] Step 5-1.2: [Scheduling Engine Module] Based on resource management constraints, the module dynamically generates multi-factor weights through game theory, obtaining corresponding computing power factor weights, network factor weights, and energy factor weights, thereby influencing scheduling decisions. The specific implementation process is the same as in the aforementioned embodiments and will not be repeated here.

[0088] Step 5-2: The scheduling engine module scores services based on the service tag of the current service request and services with the same tag attribute deployed within a resource cluster, obtaining the service affinity factor score for each computing power cluster. The specific implementation process is the same as in the previous embodiment and will not be repeated here.

[0089] Step 6: The scheduling engine module uses four independent scoring dimensions: computing power factor score, network factor score, energy factor score, and service affinity factor score, combined with dynamic game weights, to determine the optimal scheduling strategy. A smoothed weighted round-robin algorithm is then used to determine the node (i.e., the target computing power cluster) to which the current service request is allocated. The specific implementation process is the same as in the previous embodiment and will not be repeated here.

[0090] Step 7: The Service Management Module forwards the scheduling decision request to the corresponding resource node (i.e., the target computing power cluster) through the service gateway.

[0091] It should be noted that this embodiment adopts a hierarchical and domain-based elastic architecture, effectively managing distributed data center resources through a central management layer and regional layers. It also employs a fusion scheduling algorithm encompassing four dimensions: computing power, network, energy, and service. A dynamic game theory algorithm determines the weights of these four scheduling factors, combined with a smooth weighted round-robin algorithm to achieve smooth allocation based on time-series requests. Finally, a differentiated measurement mechanism is used: regional levels score computing power, network, and energy consumption factors, while the central level scores service affinity factors. These scores are then normalized and weighted to obtain the optimal scheduling decision.

[0092] This embodiment also provides a computing network energy resource scheduling and processing device, which is used to implement the above embodiments and preferred embodiments, and will not be repeated as already described. As used below, the terms "module" and "device" can refer to a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0093] According to an embodiment of the present invention, an apparatus embodiment for implementing the above-described computing network energy resource scheduling processing method is also provided. Figure 8 This is a schematic diagram of the structure of a computing network energy resource scheduling and processing device according to an embodiment of the present invention, as shown below. Figure 8 As shown, the above-mentioned computing network energy resource scheduling and processing device includes: an index acquisition module 800, a scheduling factor determination module 802, and a scheduling factor sending module 804, wherein:

[0094] The indicator acquisition module 800 is used to acquire the computing power indicators, network indicators, and energy indicators corresponding to each of the multiple computing power clusters.

[0095] The scheduling factor determination module 802 is connected to the indicator acquisition module 800 and is used to determine the computing power factor, network factor and energy factor corresponding to each of the multiple computing power clusters based on the computing power indicators, network indicators and energy indicators corresponding to each of the multiple computing power clusters.

[0096] The scheduling factor sending module 804, connected to the scheduling factor determining module 802, is used to send the computing power factor, network factor, and energy factor corresponding to each of multiple computing power clusters to the main server. The main server uses this information to determine the cluster score corresponding to each of the multiple computing power clusters. The cluster score is obtained based on the scheduling factor and scheduling factor weight of the corresponding computing power cluster. The scheduling factor includes the computing power factor, network factor, energy factor, and service affinity factor. The service affinity factor is used to indicate the similarity between the service provided by the corresponding computing power cluster and the current service request. The scheduling factor weight is obtained based on the business scenario adjustment coefficient of the corresponding computing power cluster. The scheduling factor weight includes the computing power factor weight, network factor weight, energy factor weight, and service affinity factor weight. The cluster score corresponding to each of the multiple computing power clusters is used to determine the target computing power cluster for executing the current service request from among the multiple computing power clusters.

[0097] According to an embodiment of the present invention, another apparatus embodiment for implementing the above-described computing network energy resource scheduling processing method is also provided. Figure 9 This is a schematic diagram of another computing network energy resource scheduling and processing device according to an embodiment of the present invention, as shown below. Figure 9 As shown, the aforementioned computing network energy resource scheduling and processing device includes: a scheduling factor acquisition module 900, a factor weight determination module 902, a cluster scoring module 904, and a cluster filtering module 906, wherein:

[0098] The scheduling factor acquisition module 900 is used to acquire the scheduling factors corresponding to each of multiple computing power clusters. The scheduling factors include computing power factors, network factors, energy factors, and service affinity factors. The computing power factors are obtained by scoring the computing power indicators of the corresponding computing power cluster by the regional server. The network factors are obtained by scoring the network indicators of the corresponding computing power cluster by the regional server. The energy factors are obtained by scoring the energy indicators of the corresponding computing power cluster by the regional server. The service affinity factor is used to indicate the similarity between the service provided by the corresponding computing power cluster and the current service request.

[0099] The factor weight determination module 902 is connected to the scheduling factor acquisition module 900. It is used to determine the scheduling factor weights corresponding to each of the multiple computing power clusters based on the business scenario adjustment coefficients corresponding to each of the multiple computing power clusters. The scheduling factor weights include computing power factor weights, network factor weights, energy factor weights, and service affinity factor weights.

[0100] The cluster scoring module 904 is connected to the factor weight determination module 902 and is used to obtain the cluster score corresponding to each of the multiple computing power clusters based on the scheduling factors corresponding to each of the multiple computing power clusters and the scheduling factor weights corresponding to each of the multiple computing power clusters.

[0101] The cluster filtering module 906, connected to the cluster scoring module 904, is used to determine the target computing power cluster for executing the current service request from multiple computing power clusters based on the cluster scores corresponding to each of the multiple computing power clusters.

[0102] It should be noted that the above modules can be implemented by software or hardware. For example, for the latter, it can be implemented in the following ways: the above modules can be located in the same processor; or the above modules can be located in different processors in any combination.

[0103] It should be noted that the aforementioned indicator acquisition module 800, scheduling factor determination module 802, and scheduling factor sending module 804 correspond to steps S102 to S106 in the embodiments, and the aforementioned scheduling factor acquisition module 900, factor weight determination module 902, cluster scoring module 904, and cluster filtering module 906 correspond to steps S202 to S208 in the embodiments. The instances and application scenarios implemented by the aforementioned modules and their corresponding steps are the same, but are not limited to the content disclosed in the aforementioned embodiments. It should be noted that the aforementioned modules, as part of the device, can run on a computer terminal.

[0104] It should be noted that the optional or preferred implementation methods of this embodiment can be found in the relevant descriptions in the embodiments, and will not be repeated here.

[0105] The aforementioned computing network energy resource scheduling and processing device may also include a processor and a memory. The aforementioned indicator acquisition module 800, scheduling factor determination module 802, scheduling factor sending module 804, scheduling factor acquisition module 900, factor weight determination module 902, cluster scoring module 904, cluster filtering module 906, etc., are all stored in the memory as program modules, and the processor executes the aforementioned program modules stored in the memory to realize the corresponding functions.

[0106] The processor contains a core that retrieves the corresponding program modules from memory. One or more cores may be configured. Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory includes at least one memory chip.

[0107] According to an embodiment of this application, an embodiment of a non-volatile storage medium is also provided. Optionally, in this embodiment, the non-volatile storage medium includes a stored program, wherein, when the program runs, it controls the device where the non-volatile storage medium is located to execute any of the aforementioned computing network energy resource scheduling processing methods.

[0108] Optionally, in this embodiment, the non-volatile storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals, and the non-volatile storage medium includes stored programs.

[0109] Optionally, a program that controls the device containing the non-volatile storage medium to execute any of the above-mentioned steps of the computing network energy resource scheduling processing method during program execution.

[0110] According to an embodiment of this application, an embodiment of a processor is also provided. Optionally, in this embodiment, the processor is used to run a program, wherein the program executes any of the above-described computing network energy resource scheduling processing methods.

[0111] According to an embodiment of this application, an embodiment of a computer program product is also provided, which, when executed on a data processing device, is adapted to execute a program that initializes the computer network energy resource scheduling processing method steps described above.

[0112] This invention provides an electronic device, which includes a processor, a memory, and a program stored in the memory and executable on the processor. When the processor executes the program, it implements the steps of any of the above-described computing network energy resource scheduling processing methods.

[0113] The order of the above embodiments of the present invention is merely for description and does not represent the superiority or inferiority of the embodiments.

[0114] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

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

[0116] The modules described above as separate components may or may not be physically separate. Similarly, the components shown as modules may or may not be physical modules; they may be located in one place or distributed across multiple modules. Some or all of the modules can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0117] Furthermore, the functional modules in the various embodiments of the present invention can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software functional modules.

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

[0119] The above are merely preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for scheduling and processing computing network energy resources, characterized in that, include: The scheduling factors corresponding to multiple computing power clusters are obtained. The scheduling factors include computing power factors, network factors, energy factors, and service affinity factors. The computing power factors are obtained by scoring the computing power indicators of the corresponding computing power cluster by the regional server. The network factors are obtained by scoring the network indicators of the corresponding computing power cluster by the regional server. The energy factors are obtained by scoring the energy indicators of the corresponding computing power cluster by the regional server. The service affinity factor is used to indicate the similarity between the service provided by the corresponding computing power cluster and the current service request. Based on the business scenario adjustment coefficients corresponding to each of the multiple computing power clusters, the scheduling factor weights corresponding to each of the multiple computing power clusters are determined. The scheduling factor weights include computing power factor weights, network factor weights, energy factor weights, and service affinity factor weights. The business scenario adjustment coefficients are used to adjust the corresponding scheduling factor weights according to the business scenario requirements of the corresponding computing power clusters. Based on the scheduling factors corresponding to each of the multiple computing power clusters and the scheduling factor weights corresponding to each of the multiple computing power clusters, the cluster scores corresponding to each of the multiple computing power clusters are obtained. Based on the cluster scores corresponding to each of the plurality of computing power clusters, the target computing power cluster for executing the current service request is determined from the plurality of computing power clusters.

2. The method according to claim 1, characterized in that, The step of obtaining the scheduling factors corresponding to each of the multiple computing power clusters includes: The service affinity factor of any computing power cluster can be obtained in the following way: Determine the label similarity between multiple services provided by any computing power cluster and the current service request, wherein the label similarity represents the similarity between the service label of the corresponding service provided by any computing power cluster and the service label of the current service request, and the service label is at least used to indicate the service type of the corresponding service; Based on the tag similarity between the plurality of services and the current service request, the similarity between the plurality of services and the services preceding the current service request is determined. Based on the similarity between the multiple services and the services preceding the current service request, the service affinity factor of any computing power cluster is determined.

3. The method according to claim 2, characterized in that, The step of determining the similarity between each of the multiple services and services preceding the current service request based on the tag similarity between the multiple services and the current service request includes: When each of the multiple services provided by any computing power cluster has multiple service tags, and the current service request also has multiple service tags, the service similarity between any of the multiple services and the current service request is obtained in the following way: From the tag similarity set corresponding to each of the multiple service tags of the current service request, determine the maximum tag similarity corresponding to each of the multiple service tags of the current service request, wherein the tag similarity set includes the tag similarity between the corresponding tag of the current service request and the multiple service tags of any service; The service similarity between any service and the current service request is determined based on the average of the maximum tag similarity corresponding to each of the multiple service tags of the current service request. The service similarity between any one of the services and the current service request is obtained by using the method of obtaining the service similarity between the multiple services and the services before the current service request.

4. The method according to claim 1, characterized in that, The business scenario adjustment coefficients include cross-domain disaster recovery scenario adjustment coefficients, wind power reduction scenario adjustment coefficients, and carbon emission assessment scenario adjustment coefficients. Before determining the scheduling factor weights corresponding to each of the multiple computing power clusters based on their respective business scenario adjustment coefficients, the method further includes: Based on the failure rates of the multiple computing power clusters, the cross-domain disaster recovery scenario adjustment coefficients for each of the multiple computing power clusters are determined. The cross-domain disaster recovery scenario adjustment coefficients are used to quantify the adjustment requirements of the corresponding computing power clusters in terms of disaster recovery and business continuity. Based on the wind power volatility corresponding to each of the multiple computing power clusters, the adjustment coefficient for the wind power sudden reduction scenario corresponding to each of the multiple computing power clusters is determined. The wind power volatility represents the wind power volatility in the region where the corresponding computing power cluster is located. The wind power sudden reduction scenario adjustment coefficient is used to quantify the adjustment needs of the corresponding computing power cluster in the face of unstable renewable energy supply. Based on the remaining carbon emission quotas corresponding to each of the multiple computing power clusters, the carbon emission assessment scenario adjustment coefficients corresponding to each of the multiple computing power clusters are determined. The carbon emission assessment scenario adjustment coefficients are used to quantify the adjustment needs of the corresponding computing power clusters in meeting carbon emission targets.

5. The method according to claim 1, characterized in that, The step of determining the scheduling factor weights for each of the multiple computing power clusters based on the business scenario adjustment coefficients for each cluster includes: Based on the business scenario adjustment coefficients corresponding to each of the multiple computing power clusters, the weight adjustment coefficients corresponding to each of the multiple computing power clusters are determined, wherein the weight adjustment coefficients include computing power adjustment coefficients, network adjustment coefficients, energy adjustment coefficients, and service affinity adjustment coefficients. Based on the weight adjustment coefficients corresponding to each of the multiple computing power clusters, the initial factor weights corresponding to each of the multiple computing power clusters are optimized to obtain the scheduling factor weights corresponding to each of the multiple computing power clusters. The initial factor weights include the initial computing power weight, the initial network weight, the initial energy weight, and the initial service affinity weight.

6. The method according to claim 5, characterized in that, The step of determining the weight adjustment coefficients for each of the multiple computing power clusters based on the business scenario adjustment coefficients for each cluster includes: Based on the cross-domain disaster recovery scenario adjustment coefficients corresponding to each of the multiple computing power clusters, the computing power adjustment coefficient, network adjustment coefficient, and service affinity adjustment coefficient corresponding to each of the multiple computing power clusters are determined. Based on the wind power reduction scenario adjustment coefficient and carbon emission assessment scenario adjustment coefficient corresponding to each of the multiple computing power clusters, the energy adjustment coefficient corresponding to each of the multiple computing power clusters is determined.

7. The method according to claim 1, characterized in that, When the business scenario adjustment coefficient includes cross-domain disaster recovery scenario adjustment coefficient, wind power reduction scenario adjustment coefficient, and carbon emission assessment scenario adjustment coefficient, the step of determining the target computing power cluster for executing the current service request from the plurality of computing power clusters based on the cluster scores corresponding to each of the plurality of computing power clusters includes: Obtain the weight of the previous cluster corresponding to each of the plurality of computing power clusters, wherein the weight of the previous cluster is obtained by executing the previous service request of the current service request; The weights of the previous clusters and the corresponding cluster scores of each of the multiple computing power clusters are summed to obtain the current cluster weights of each of the multiple computing power clusters. The target computing power cluster is determined from the plurality of computing power clusters based on the current cluster weights corresponding to each of the plurality of computing power clusters.

8. A method for scheduling and processing computing network energy resources, characterized in that, include: Obtain the computing power metrics, network metrics, and energy metrics corresponding to each of the multiple computing clusters; Based on the computing power indicators, network indicators and energy indicators corresponding to each of the multiple computing power clusters, the computing power factor, network factor and energy factor corresponding to each of the multiple computing power clusters are determined. The computing power factor, network factor, and energy factor corresponding to each of the multiple computing power clusters are sent to the main server, so that the main server can determine the cluster score corresponding to each of the multiple computing power clusters. The cluster score is obtained based on the scheduling factor and scheduling factor weight of the corresponding computing power cluster. The scheduling factor includes computing power factor, network factor, energy factor, and service affinity factor. The service affinity factor is used to indicate the similarity between the service provided by the corresponding computing power cluster and the current service request. The scheduling factor weights are obtained based on the business scenario adjustment coefficients of the corresponding computing power clusters. The scheduling factor weights include computing power factor weights, network factor weights, energy factor weights, and service affinity factor weights. The business scenario adjustment coefficients are used to adjust the corresponding scheduling factor weights according to the business scenario requirements of the corresponding computing power clusters. The cluster scores corresponding to each of the multiple computing power clusters are used to determine the target computing power cluster for executing the current service request from the multiple computing power clusters.

9. The method according to claim 8, characterized in that, The step of determining the computing power factor, network factor, and energy factor corresponding to each of the multiple computing power clusters based on their respective computing power indicators, network indicators, and energy indicators includes: When there are multiple computing power indicators, the computing power factor of any computing power cluster is obtained based on the multiple computing power indicators of any computing power cluster in the following manner: Normalize multiple computing power indicators of any computing power cluster to obtain multiple normalized computing power indicators, wherein the multiple computing power indicators include CPU utilization, memory utilization, disk input / output speed, and video memory utilization. The computing power factor of any computing power cluster is obtained by performing a weighted average calculation on the multiple normalized computing power indicators. Based on the computing power indicators corresponding to each of the multiple computing power clusters, the computing power factors corresponding to each of the multiple computing power clusters are obtained by using the method of obtaining the computing power factor of any one of the computing power clusters.

10. The method according to claim 8, characterized in that, The step of determining the computing power factor, network factor, and energy factor corresponding to each of the multiple computing power clusters based on their respective computing power indicators, network indicators, and energy indicators includes: When the network metrics include multiple metrics, the network factor of any computing power cluster is obtained based on the multiple network metrics of any computing power cluster in the following manner: Normalize multiple network metrics for any computing power cluster to obtain multiple normalized network metrics, wherein the multiple network metrics include network latency and network jitter. The weighted network index is obtained by performing a weighted summation operation on the multiple normalized network indices. Based on a preset attenuation intensity coefficient, the weighted network index is subjected to exponential attenuation calculation to obtain the network factor of any computing power cluster. Based on the network metrics corresponding to each of the multiple computing power clusters, the network factors corresponding to each of the multiple computing power clusters are obtained by using the method of obtaining the network factor of any one of the computing power clusters.

11. The method according to claim 8, characterized in that, The step of determining the computing power factor, network factor, and energy factor corresponding to each of the multiple computing power clusters based on their respective computing power indicators, network indicators, and energy indicators includes: When there are multiple energy indicators, the energy factor of any computing power cluster is obtained based on the multiple energy indicators of any computing power cluster in the following manner: The energy indicators of any computing power cluster are normalized to obtain multiple normalized energy indicators, wherein the multiple energy indicators include carbon emission factor and electricity cost. The energy factor of any computing power cluster is obtained by performing a weighted average calculation on the multiple normalized energy indicators. Based on the energy indicators corresponding to each of the multiple computing power clusters, the energy factors corresponding to each of the multiple computing power clusters are obtained by using the method of obtaining the energy factor of any one of the computing power clusters.

12. A non-volatile storage medium, characterized in that, The non-volatile storage medium stores multiple instructions, which are adapted to be loaded by a processor and executed by the computing network energy resource scheduling processing method according to any one of claims 1 to 11.

13. An electronic device, characterized in that, It includes one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the computing network energy resource scheduling processing method according to any one of claims 1 to 11.

14. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the computer network energy resource scheduling processing method according to any one of claims 1 to 11.

Images