A server cluster operation management method and system

Abstract

The present invention discloses a method and system for the operation and management of a server cluster, belonging to the technical field of server operation and management. By constructing a computing unit pool containing multiple service blocks, the resource status and application tag information of the functional modules are combined to identify their operation scenarios and generate a scheduling adaptation factor model. The link capacity, location distribution and communication delay between the service blocks are further integrated to construct an extended structure map. A deep self-tuning engine is used for offline reinforcement learning training to generate the optimal expansion strategy under multiple scenarios. The system can dynamically judge the expansion behavior based on the current status and update the strategy by continuously collecting expansion feedback, thereby realizing intelligent, adaptive and high-efficiency control of resource scheduling.

Description

Technical Field

[0001] The present invention relates to the technical field of server operation management, and in particular to an operation management method and system for a server cluster. Background Art

[0002] A server cluster is a system composed of multiple servers connected over a network, working together as a single entity to provide external services. It improves system processing power, stability, and reliability through load balancing and failover mechanisms. It is commonly used in scenarios requiring high availability and high concurrency, such as large websites, cloud computing platforms, and database services.

[0003] The existing technology has the following shortcomings:

[0004] In a multi-AZ cluster deployed on AWS on a SaaS platform, Cluster Autoscaler automatically expands capacity without configuring a region preference. This may result in selecting a resource-constrained or more expensive AZ, leading to increased operating costs. Furthermore, if the new node is located in an area far from the core database or primary users, network latency may increase, impacting service response speed. In more serious cases, cross-AZ master-slave data synchronization may be restricted, potentially causing service anomalies and even data consistency issues, severely impacting system stability and user experience. Summary of the Invention

[0005] The purpose of the present invention is to provide a server cluster operation management method and system to solve the deficiencies in the background technology.

[0006] In order to achieve the above object, the present invention provides the following technical solution: a method for operating and managing a server cluster, comprising:

[0007] Build the operating environment of the server cluster, including a pool of computing units distributed across multiple service blocks and copies of functional modules deployed on the computing units;

[0008] Based on the current resource usage status and application tag information of the functional module replica, the operating scenario type is identified and the corresponding scheduling adaptation factor model is constructed;

[0009] According to the scheduling adaptation factor model, a state input set and a feedback evaluation function of the elastic control strategy are defined;

[0010] The link capacity, location distribution, and interaction delay between service blocks are modeled as an extended structural graph and introduced into the strategy model as characteristic parameters.

[0011] Using a deep self-tuning engine to perform offline reinforcement learning training on the policy model to generate optimal action mappings for different operating scenarios and structural graphs;

[0012] Based on the current state of the cluster and the trained policy model, dynamically determine whether to perform computing power expansion operations and expand the number of target service blocks and units;

[0013] The operational feedback information of computing power expansion behavior and various monitoring indicators are returned to the strategy model, and the strategy is updated based on the continuous tuning mechanism.

[0014] Preferably, the operating environment for building the server cluster includes:

[0015] For each computing power unit, measure the network round-trip time between it and the dependent nodes; calculate the weighted average of the communication delays of multiple dependent nodes, where the weight of each node is assigned according to the call frequency between it and the functional module; use the weighted average communication time as the communication overhead indicator of the computing power unit; based on the communication overhead indicator, give priority to computing power units with low latency for deploying functional module replicas.

[0016] Preferably, identifying the operation scenario type and constructing the corresponding scheduling adaptation factor model includes:

[0017] Collect resource usage data of the target functional module replica within the predetermined monitoring period, including average CPU usage, memory utilization, request response time, and call frequency;

[0018] Parsing the application tag information carried by the functional module, the tag includes a structured identification field indicating the service type to which the module belongs, the service priority level, and whether it is a state-retaining service;

[0019] Based on the preset operation scenario identification rules, the current state of the module is mapped to a variety of operation scenario types using rule matching, including high-concurrency processing, computation-intensive, low-latency interactive, or resource-saving;

[0020] For the identified operating scenario type, a corresponding scheduling adaptation factor model is constructed. The model is a set of parameters that affect the selection of scheduling strategies, including region selection weight, startup priority, delay tolerance threshold, and expected deployment cycle.

[0021] Preferably, service characteristic parameters are extracted from the scheduling adaptation factor model, including regional elasticity weight, deployment priority, resource sensitivity threshold and delay tolerance level; based on the service characteristic parameters and the current resource status of the cluster, a state input set including node idle rate, network delay, historical deployment behavior and failure rate is constructed, and used as the input of the elasticity control strategy model; multi-objective feedback items including at least deployment success rate, startup time, resource utilization and deployment cost are defined, and weights are assigned to each feedback item to construct a weighted combination feedback evaluation function.

[0022] Preferably, modeling the link capacity, location distribution, and interaction delay between service blocks as an extended structure graph includes:

[0023] A directed graph structure of a set of service blocks is constructed, where each node corresponds to a service block and an edge represents a data transmission path between two blocks. For each edge, the corresponding bandwidth capacity, average network latency, and cross-block distance factor are collected and mapped to the edge's connection weight value. Graph normalization is performed on the structure graph, and the normalized structure graph is introduced as a topological embedding feature into the input of the elastic control strategy model to optimize the node selection and scheduling area matching process.

[0024] Preferably, the offline reinforcement learning training of the policy model using a deep self-tuning engine includes:

[0025] Initialize a dual-structure model consisting of a policy network and a value network. The policy network is used to generate a probability distribution of scheduling actions, and the value network is used to estimate the cumulative expected reward of the current state.

[0026] Construct an offline training sample set that includes a state input set, actual deployment actions, and feedback evaluation functions;

[0027] Use pre-collected system operation history records as training samples to perform behavior cloning warm-up training on the policy network to stabilize the initial output of the model;

[0028] Based on the offline reinforcement learning algorithm, the strategy-value network is jointly optimized to minimize the gap between action prediction error and expected reward, and generate the basic strategy mapping function.

[0029] Preferably, the offline training process further includes:

[0030] For each state input sample used for training, extract the corresponding service block structure graph fragment, including the embedding vectors of the target block node and its adjacent nodes;

[0031] A graph neural network algorithm is used to perform message passing and aggregation processing on graph fragments to generate a high-dimensional structure-aware embedding vector. This vector is then combined with the context embedding vector generated based on the operating context type and the resource state vector generated based on the resource usage status to form a complete state input vector.

[0032] During the policy training process, the model is guided to learn the scheduling policy performance under the influence of the topological structure, thereby achieving optimal expansion behavior mapping for the structural graph.

[0033] Preferably, the dynamically determining whether to perform the computing power expansion operation based on the cluster current state input and the trained policy model includes:

[0034] Receive the current cluster resource status input set, including the remaining resources of each service block, network latency, service load indicators and operation scenario characteristics provided by the scheduling adaptation factor model;

[0035] Input its input set into the trained policy model, triggering the policy model to perform inference operations and generate an output set containing recommended expansion actions;

[0036] The output set includes a Boolean determination value of whether to expand capacity, an identifier of the target service block for recommended expansion, and the number of computing power units recommended for expansion;

[0037] Determine whether to perform capacity expansion based on the output of the policy model. If not, maintain the existing deployment status.

[0038] Preferably, the strategy update based on the continuous tuning mechanism includes:

[0039] After each computing power expansion operation is executed, operational feedback information including deployment success rate, startup time, resource usage stability, cluster load changes, and service response time is collected and archived in a structured manner in association with the corresponding expansion action;

[0040] Based on the feedback information, the comprehensive behavioral score of the current expansion action is calculated and compared with the expected return value of the strategy model before the decision is made;

[0041] Set a fixed time window or policy behavior round as the model update cycle, collect feedback datasets and construct incremental training sample sets;

[0042] Under the premise of ensuring the stability of online reasoning, incremental parameter adjustments are performed on the policy network, and the updated model is selected through the version comparison verification mechanism to complete the continuous policy tuning process.

[0043] The present invention also provides an operation management system for a server cluster, comprising:

[0044] The environment construction module is used to build the operating environment of the server cluster, including the computing power unit pool configured in multiple service blocks and the functional module copies deployed on the computing power units;

[0045] The context recognition module is used to identify the type of operating context based on the current resource usage status and application tag information of the functional module copy, and to build a corresponding scheduling adaptation factor model;

[0046] The strategy modeling module is used to define the state input set and feedback evaluation function of the elastic control strategy based on the scheduling adaptation factor model;

[0047] A structural graph construction module is used to model the link capacity, location distribution, and interaction delay between each service block into an extended structural graph, and input the graph as a feature parameter into the strategy model;

[0048] The policy training module includes a deep self-tuning engine for offline reinforcement learning training of the policy model to generate the optimal scheduling action mapping under different operating scenarios and structural graph conditions;

[0049] The policy reasoning module is used to dynamically determine whether to perform computing power expansion operations based on the current cluster state input and the trained policy model, and to determine the target service block for expansion and the number of computing power units required;

[0050] The feedback update module is used to collect operational feedback information on expansion behaviors and various system monitoring indicators, and structure their feedback to the policy model, and incrementally update the policy model through a continuous tuning mechanism.

[0051] In the above technical solution, the technical effects and advantages provided by the present invention are:

[0052] 1. This invention achieves highly intelligent and dynamically adaptable cluster resource scheduling by introducing scheduling adaptation factor modeling, extended structure graph construction, reinforcement learning strategy training, and a continuous tuning mechanism driven by operational feedback. Compared to traditional scheduling methods that rely on static rules or single-dimensional indicators, this invention makes more context-aware and performance-optimizing scheduling decisions based on the actual operating scenarios of functional modules and the network structure relationships between service blocks, significantly improving service quality and resource utilization efficiency.

[0053] 2. This invention establishes a closed-loop evolutionary path for the policy model, enabling continuous optimization of decision-making logic through actual feedback after deployment, thus avoiding scheduling performance degradation caused by model aging or changes in the operating environment. The system possesses strong robustness and sustainable learning capabilities, making it suitable for large-scale, multi-tenant, multi-availability zone cloud computing platforms and highly elastic business scenarios, significantly improving the cluster's expansion response speed, cross-zone collaboration capabilities, and scheduling autonomy. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments described in the present invention. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0055] Figure 1 Flow chart of the method of the present invention.

[0056] Figure 2 It is a flow chart of the system modules of the present invention. DETAILED DESCRIPTION

[0057] To make the objectives, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0058] Example 1, please refer to Figure 1 As shown, the operation management method of a server cluster described in this embodiment includes:

[0059] Build the operating environment of the server cluster, including a pool of computing units distributed across multiple service blocks and copies of functional modules deployed on the computing units;

[0060] Based on the current resource usage status and application tag information of the functional module replica, the operating scenario type is identified and the corresponding scheduling adaptation factor model is constructed;

[0061] According to the scheduling adaptation factor model, a state input set and a feedback evaluation function of the elastic control strategy are defined;

[0062] The link capacity, location distribution, and interaction delay between service blocks are modeled as an extended structural graph and introduced into the strategy model as characteristic parameters.

[0063] Using a deep self-tuning engine to perform offline reinforcement learning training on the policy model to generate optimal action mappings for different operating scenarios and structural graphs;

[0064] Based on the current state of the cluster and the trained policy model, dynamically determine whether to perform computing power expansion operations and expand the number of target service blocks and units;

[0065] The operational feedback information of computing power expansion behavior and various monitoring indicators are returned to the strategy model, and the strategy is updated based on the continuous tuning mechanism.

[0066] When building the initial operating environment of a server cluster, to prevent functional module replicas from being deployed in a few resource-rich service blocks, which could cause single-area overload and uneven resource scheduling in the later stages, this implementation adopts a deployment scheduling strategy based on multiple resource weight calculations. The specific process is as follows:

[0067] Before the system is deployed, it first collects the current resource usage status of each service block, including indicators such as CPU idle ratio, memory usage, disk IO load, and network bandwidth utilization;

[0068] After normalizing the above indicators, a resource availability score is calculated for each service block;

[0069] Sort each block according to the score value and determine the initial distribution ratio of functional module copies in a weighted manner;

[0070] Set a deployment skew threshold (for example, no more than 30% of the total number of replicas deployed in any service block). When the number of replicas in any block exceeds the threshold, the deployment target is automatically switched to the next best resource block.

[0071] Through the above-mentioned method, this embodiment can achieve balanced control of resource heat, effectively prevent the rapid exhaustion of resources in a certain block, and improve the overall load balancing capability of the system.

[0072] In view of the fact that some functional modules are highly sensitive to communication with dependent nodes such as data sources and configuration services during the initial startup, this implementation provides a deployment optimization process with network overhead as a constraint. The specific steps are as follows:

[0073] Before deployment, identify the key dependency nodes of functional modules, including database services, cache services, authentication services, etc.

[0074] Collect the network delay value between each candidate computing unit and the dependent node, using network probes or internal RTT (round-trip time) statistics;

[0075] The communication delay values ​​of multiple nodes are combined into a comprehensive indicator to measure the communication affinity of the computing power unit to the current functional module;

[0076] Prioritize the deployment of computing units with the smallest latency indicators, forming a "low latency first" deployment strategy.

[0077] This deployment strategy can significantly reduce the data interaction time during the service cold start phase, improve deployment response speed and availability, and is particularly suitable for distributed application scenarios with high initialization performance requirements.

[0078] To enhance the lifecycle management and scheduling stability of functional modules in computing units, the present invention proposes a container binding mechanism based on a hierarchical structure, which includes the following steps:

[0079] Multi-layer container encapsulation of functional module copies. The typical structure includes: business logic container layer, scheduling agent layer and health detection module;

[0080] After each container is bound to the target computing unit, a binding relationship is established between the computing unit, the module replica, and the deployment label.

[0081] Each container registers a running status probe interface for the cluster scheduler to monitor its survival status and performance indicators in real time;

[0082] In scenarios such as capacity expansion, migration, or fault recovery, this binding mechanism ensures that the original deployment characteristics of the functional module can be traced back, avoiding incorrect scheduling and service interruption.

[0083] This mechanism improves the stability and scheduling controllability of functional modules after deployment and is an important means to ensure service continuity.

[0084] When deploying a large number of functional modules in a distributed environment, if there is no mechanism to describe deployment strategies and constraints, it is very easy to cause the loss of replica characteristics during subsequent expansion or failover. To this end, this implementation proposes a "deployment tagging system" with the following specific process:

[0085] When each functional module copy is generated, a set of deployment tag metadata is created, including: functional purpose code, resource preference weight (such as preference for high memory or low latency), and dependency path reference (such as dependency on database type or message middleware identifier);

[0086] Bind the deployment tag to the computing unit as a replica lifecycle attribute and write it to the scheduling metadata repository.

[0087] During subsequent system expansion or module rescheduling, the initial deployment conditions are reconstructed based on the mark to maintain the explainability and consistency of system scheduling.

[0088] The deployment tagging mechanism can be regarded as the "identity fingerprint of the functional module". It provides structural memory capabilities in complex cluster operations and has extremely strong engineering practical value.

[0089] In order to optimize the communication efficiency of module deployment, a communication overhead calculation mechanism with dependency perception and weighted average characteristics is proposed. The detailed steps are as follows:

[0090] For each functional module copy, the system identifies several basic service nodes it depends on based on the deployment description or operation record;

[0091] For each candidate computing unit, a detection mechanism is used to measure the data transmission delay between it and each of the above dependent nodes, in milliseconds.

[0092] For each dependent node, a communication weight value is assigned according to its call frequency during the module execution process;

[0093] Using the weighted average method, multiple measured communication delay values ​​are multiplied by the corresponding weights and then summed up to obtain the average communication overhead index of the computing power unit;

[0094] This indicator is used as one of the reference standards for evaluating whether the unit is suitable for deployment of the target module and participates in the final scheduling sorting.

[0095] Through this communication indicator model, the deployer not only considers the number of resources and load, but also incorporates "communication quality" into the evaluation system, effectively improving the collaborative efficiency of distributed services in the topology structure.

[0096] To collect resource usage status data for functional module replicas, first, during cluster operation, periodically monitor the performance of functional module replicas deployed on each computing unit and collect resource status data within a specified time window (e.g., the last 30 seconds or 5 minutes). The collected indicators include but are not limited to the following categories:

[0097] Average CPU usage; peak memory usage; network bandwidth consumption rate; average request response latency; number of calls per unit time or QPS (request processing volume); I / O wait time (used to identify disk- or storage-intensive modules);

[0098] These metrics are obtained through container-level monitoring components (such as Prometheus, cAdvisor, or kubelet), normalized by the time series processing component, and stored in the context recognition module for subsequent use.

[0099] Secondly, the system reads the application tag information registered by each functional module copy during the deployment phase. These tags can be defined by developers in the deployment configuration or automatically generated by the platform based on service metadata.

[0100] Typical labels include but are not limited to:

[0101] serviceType: identifies the business type of the module (e.g., api-gateway, data-ingest, cache-agent);

[0102] priorityLevel: specifies the service priority;

[0103] stateful: Indicates whether the module is a state-retaining service;

[0104] scalingPattern: indicates whether fast scaling is supported;

[0105] latencySensitivity: latency sensitivity level;

[0106] These labels and monitoring indicators together constitute the context information set for judging the operating situation.

[0107] After obtaining resource indicators and label information, the system calls and runs the context recognition engine to classify the current functional module copies. The classification results are used for the differentiated generation of subsequent scheduling strategies.

[0108] The identification of situation types can be based on one or a combination of the following two strategies:

[0109] Classification strategy based on rule matching: The system pre-defines multiple judgment rules, each of which consists of multiple indicators and label conditions. For example, if the CPU usage exceeds 80%, the request QPS exceeds 1000, and it is marked as a stateless module, it will be classified as "high concurrency processing type";

[0110] If latency sensitivity is high and response time is less than 30ms → classified as "Low Latency Interactive";

[0111] If the memory usage is always below 30% and the priority is marked as low → classify as "resource-saving";

[0112] If the state retention is true and the call frequency is very low → classified as "task type / cold start type";

[0113] Lightweight model-based classification strategy: If the system deployment has machine learning capabilities, a lightweight classification model (such as a decision tree, logistic regression, or a small neural network) can be used to input the above indicators and train a classifier to automatically determine the context type. The input feature vector includes CPU, latency, bandwidth, and label embedding codes, and the output is a discrete context label.

[0114] The results of a situation type are generally one of the following:

[0115] High concurrent processing type: suitable for stateless services, high QPS, and easy scalability;

[0116] Computation-intensive: heavy CPU load and high response tolerance;

[0117] Low-latency interactive: requires extremely low response time and needs to be deployed close to the user;

[0118] Resource-saving: It has stable load and is suitable for deployment in edge areas or reserved resource pools.

[0119] After obtaining the scenario type, the system constructs a set of scheduling adaptation factors, which are subsequently input into the scheduling control strategy model (such as the reinforcement learning decision network, deployment template selector, etc.), affecting its key behaviors such as expansion area, number of replicas, and deployment order.

[0120] The scheduling adaptation factor includes at least the following parameter fields:

[0121] Regional elasticity weight: indicates the sensitivity of the module replica to the availability zone location (e.g., high concurrency → high elasticity; stateful → low elasticity);

[0122] Startup priority coefficient: the priority of the module during concurrent startup (can be bound to the business priority);

[0123] Delay tolerance threshold: the maximum acceptable average communication delay, used to filter deployment blocks;

[0124] Expected deployment cycle: The maximum tolerable time from scheduling to service readiness, used for resource cold start evaluation;

[0125] Replica scalability tag: Whether dynamic replica number changes are supported, affecting the HPA policy generation logic.

[0126] This factor set is bound to the scheduling metadata of the functional module replica in the form of structured parameters and serves as an input reference each time the policy model makes a decision or service is rescheduled.

[0127] The policy model's "state input set" is a set of vectors describing the current cluster operating state, service deployment requirements, and resource availability. Unlike fixed input templates, this method generates a dynamic input structure based on a scheduling adaptability factor model, resulting in high business sensitivity and resource adaptability.

[0128] The construction process includes the following steps:

[0129] Parameter extraction phase: Extract key parameters of the current functional module from the scheduling adaptation factor model, including:

[0130] Regional elasticity weight (indicating whether cross-availability zone deployment is allowed); deployment priority (affecting the degree of competition with other tasks); resource sensitivity threshold (such as the maximum acceptable deployment delay);

[0131] Resource status collection phase: Real-time collection of resource usage status of each service block in the cluster, including but not limited to:

[0132] The current CPU idle rate and remaining memory of each node;

[0133] Network throughput, IO load;

[0134] Node availability index (based on downtime rate and response delay statistics);

[0135] Feature encoding stage: The above parameters are combined to construct a state vector, for example:

[0136] Region A has a CPU idle rate of 45% and a latency of 20ms.

[0137] Functional modules need to be deployed with low latency;

[0138] The state vector weight of region A is lowered, and region B is given priority if it has better indicators.

[0139] Preprocessing stage: Normalization is performed on the state vector to ensure that parameters of different dimensions have a consistent numerical range in the policy model, which facilitates the convergence and generalization of the policy model.

[0140] Through the above process, the system provides the policy model with a set of dynamic, operating environment-aware input sets to support flexible decision-making.

[0141] Another key element in policy model training is the feedback evaluation function, which guides the model to optimize its behavior. To meet complex business needs, this paper introduces a multi-objective fusion feedback mechanism to avoid the problem of a single performance objective dominating the scheduling results in traditional systems.

[0142] The implementation process is as follows:

[0143] Goal definition: Extract the current performance requirement weight of the task from the scheduling adaptation factor model, such as the preference for "low latency and high stability";

[0144] Target item scoring function construction:

[0145] Deployment success rate score: The stability score is formed by summing the success rates of past deployment attempts over a certain time window.

[0146] Cold start delay score: The average value of the time required for the module to report the first health signal from deployment is calculated.

[0147] Resource utilization score: Calculates the difference between the actual resource consumption of a unit replica after deployment and the ideal resource ratio;

[0148] Deployment cost scoring: Calculates the price per resource based on the target region and estimates the resource cost of each replica.

[0149] Weighted fusion: According to the task's focus on each indicator, set the weighting coefficient of each target item, perform weighted average or weighted sum, and form a comprehensive score.

[0150] For example, the current feedback function value of a functional module can be expressed as follows (converted into textual expression):

[0151] Feedback value = (deployment success rate score × 0.3) + (startup delay score × 0.2) + (resource utilization score × 0.3) + (cost score × 0.2);

[0152] The above scoring results will be used as reward signals in the reinforcement learning model or as reference results for policy reasoning and input into the next round of optimization.

[0153] In order to enhance the sensitivity of the policy model to long-term system evolution and service stability, the present invention further introduces the “historical behavior trajectory” feature into the state input set. This mechanism can more accurately reflect the scheduling risk, resource adaptability and stability requirements of specific services.

[0154] The specific steps are as follows:

[0155] Behavior collection: records the module's relevant behavior data during the past several scheduling processes, including:

[0156] Mean time between deployments;

[0157] Scheduling failure rate (e.g., rejection due to insufficient resources);

[0158] Number of migrations and average migration success time;

[0159] The number of resource rescheduling and contention rate (i.e., the frequency of interruptions in high-concurrency scenarios);

[0160] Feature modeling: Statistically analyze the above historical behaviors and output labels such as stability index, failure penalty, and scheduling frequency level.

[0161] Fusion processing: This type of feature is input into the strategy model together with the current resource indicators and factor model parameters to enable it to have "memory-type" reasoning capabilities.

[0162] This mechanism enables the model to perceive which services are sensitive to changes in the deployment environment, thereby improving scheduling robustness.

[0163] In traditional cluster systems, scheduling evaluation is mainly based on system-level indicators (such as resource allocation efficiency). However, the present invention introduces business-level feedback signals to achieve closed-loop control of the policy model, enabling it to learn and respond to the "service quality" itself.

[0164] The implementation is as follows:

[0165] Business indicator collection: After the functional module is deployed, the system receives its business monitoring indicators, such as:

[0166] Request response time jitter (Jitter);

[0167] Error request rate (such as HTTP 5xx);

[0168] Business completion rate (such as payment success rate, processing completion rate);

[0169] Causal analysis mechanism: Use regression analysis or causal relationship modeling to determine whether service fluctuations are affected by resource scheduling policies (for example, deployment in areas with poor network quality causing request timeouts).

[0170] Feedback quantification: Convert highly relevant business fluctuations into positive rewards or negative penalties, and include them in the strategy training returns;

[0171] Feedback loop: The above business feedback signals participate in the iterative update of the model, gradually improving the adaptability of the system strategy to business goals.

[0172] The main goal of constructing a structural graph is to express the resource accessibility and communication cost between each service block. To this end, this implementation adopts a graph structure modeling method, which specifically includes the following steps:

[0173] Link parameter collection: The system periodically collects communication link indicators between service blocks through the embedded network monitoring module or service grid probe component, mainly including:

[0174] Link bandwidth upper limit: indicates the theoretical maximum transmission capacity of the network interface between two blocks;

[0175] Real-time usage rate: refers to the current bandwidth usage ratio, reflecting the network congestion status;

[0176] Packet loss rate and retransmission times: used to evaluate link stability.

[0177] Zone location modeling: Obtain the logical topology number (such as a Kubernetes zone ID or subnet identifier) ​​or geographic coordinate information (such as a region label provided by the cloud platform) of each service zone. This information is used to express physical or topological proximity.

[0178] Communication latency measurement: By periodically sending heartbeat packets or test requests, we measure the round-trip time (RTT) between service blocks and calculate the average over multiple sampling periods. This latency metric serves as the key weight basis for edges in the graph.

[0179] Graph structure construction: Each service block is modeled as a node in the graph, and an edge is connected between any two service blocks with communication capabilities. The initial weight of each edge is a joint indicator, representing the communication cost from block A to block B. It is calculated as follows:

[0180] The communication delay, packet loss rate, and bandwidth congestion rate are combined with certain weights, and the communication cost is obtained through weighted average.

[0181] For example: Communication cost = (delay × 0.5) + (packet loss rate × 0.3) + (bandwidth congestion rate × 0.2). The result is a communication cost score assigned to each edge.

[0182] Ultimately, a structural graph with weighted edges and node attributes is formed, which is used by the policy model to perceive the network relationships and deployment preferences between service blocks.

[0183] To further enhance the expressiveness of the graph, this implementation adds structured attributes to the nodes and edges in the graph and integrates and optimizes the communication indicators, as follows:

[0184] Node attribute vector design: Each service block node is attached with an attribute vector, which includes:

[0185] Resource abundance (e.g., average CPU utilization inverse indicator);

[0186] Historical average response time;

[0187] Deployment success rate and fault recovery time in the last 30 minutes;

[0188] Network stability coefficient.

[0189] The above attributes are stored in numerical form to assist the policy model in evaluating the schedulability of service blocks.

[0190] Edge weight fusion function design: To ensure that the communication cost weights of edges are globally comparable, the original bandwidth, latency, and stability indicators are standardized (such as Z-score or Min-Max normalization), unified in dimension, and then weighted aggregated according to the priority defined by the policy model. The aggregation method can be expressed based on the following formula:

[0191] Edge weight = α × normalized delay + β × normalized bandwidth + γ × normalized packet loss rate, where α, β, and γ are weight coefficients given by the policy model or service configuration.

[0192] Graph structure update mechanism: To ensure that the model is adaptable to dynamic changes in network topology, this system sets a graph update cycle (for example, once every 10 minutes) and performs immediate reconstruction when the cluster topology changes (such as new nodes joining or block failures).

[0193] The above attribute enhancement mechanism ensures that the graph data received by the policy model not only has structural information, but also integrates performance and reliability factors to constitute a complete deployment environment input.

[0194] In order to enable the policy model to directly utilize the above-mentioned graph information to participate in scheduling decisions, this paper adopts graph embedding technology to convert the graph structure into a vector representation that can be input into the policy model. The main steps are as follows:

[0195] Graph embedding technology: Graph neural networks (GNNs) or graph convolutional neural networks (GCNs) are used to encode each node in the graph. This process considers the node's own attributes and the characteristics of adjacent nodes to form a high-dimensional vector representation (e.g., a 64- or 128-dimensional vector) that represents the "scheduling characteristics" of the service block.

[0196] Policy model input fusion: The embedding vector of each service block and the scheduling adaptation factor of the functional module are jointly input into the elastic control policy model, so that the model can consider both the requirements of the functional module and the network characteristics of the service block when evaluating the deployment area.

[0197] Policy reasoning and deployment recommendation: During the policy reasoning process, the model sorts target blocks according to the graph embedding value and prioritizes deployment areas with low communication costs and rich resources, thereby optimizing the expansion path and response time.

[0198] Graph embedding reverse update mechanism: During policy model training or reinforcement learning, if the feedback effect after a certain deployment is poor (for example, a sharp increase in response delay after deployment), the edge weights or node embeddings in the graph are adjusted through the backpropagation mechanism to achieve coordinated optimization of the structural graph and policy behavior.

[0199] In the resource scheduling scenario of a server cluster, scheduling decisions can be viewed as a Markov Decision Process (MDP). Each expansion or deployment operation is an "action," with the current system state as the "state input" and the scheduling results as the "environmental feedback." The goal of the scheduling system is to learn to select the optimal action under different states, thereby maximizing long-term benefits.

[0200] To this end, the present invention adopts a strategy-value dual network structure as the core framework of the strategy model, including:

[0201] Policy Network: Used to generate scheduling actions or action probability distributions, such as choosing whether to expand capacity, selecting a deployment area, and setting the number of replicas.

[0202] Value Network: Used to estimate the expected long-term return under the current state, that is, to estimate the performance of the overall system after performing a certain action in the state.

[0203] This dual network structure can be optimized using mainstream reinforcement learning algorithms such as DDPG (Deep Deterministic Policy Gradient) or PPO (Proximal Policy Optimization).

[0204] In terms of training data construction, an offline reinforcement learning training mechanism is adopted. That is, instead of relying on the online environment to perform operations in real time, the system's historical deployment records are used to construct training samples, including:

[0205] State input vector (e.g., resource state, historical behavior, structural topology);

[0206] Executed deployment actions;

[0207] System feedback from this action (e.g., startup time, cost, service success rate);

[0208] Optional action space (i.e., the set of optional deployment strategies in this state).

[0209] At the beginning of training, behavior cloning is used for warm-up training. That is, the policy network first learns to imitate scheduling actions with better results in history to help the model stabilize output; then it switches to the reinforcement learning process and optimizes the policy model through the reward function.

[0210] The reward function can be:

[0211] Reward value = (deployment success rate × Weight 1) + (resource utilization × Weight 2) − (startup delay × Weight 3) − (deployment cost × Weight 4); the weight values ​​are dynamically set based on business objectives.

[0212] Since different functional modules have significantly different resource preferences and performance requirements during operation (such as high-concurrency services require fast startup, low-latency services focus on communication quality, etc.), the present invention introduces an operation context embedding mechanism to enable the policy model to have "context awareness capabilities".

[0213] The implementation process is as follows:

[0214] Scenario classification and label generation: Before deployment, the scheduling adaptation factor model and application labels are used to determine the operating scenario type of the functional module, such as concurrent processing type, state-preserving type, real-time interactive type, and energy-saving steady-state type.

[0215] Context label embedding processing: Each context label is encoded and converted into a discrete or continuous embedding vector, which is used as part of the state input vector.

[0216] Training sample annotation: When constructing training samples, add a corresponding context embedding field for each sample state so that the model can learn "how to make decisions in a certain type of situation" during training.

[0217] Policy diversity modeling: During training, the model adjusts its output policy based on contextual embeddings. For example, in a "low latency" scenario, the policy may prefer to select faster service blocks; in an "energy-efficient" scenario, it may prefer to select nodes with lower resource usage.

[0218] This mechanism greatly enhances the behavioral diversity and scheduling adaptability of the model.

[0219] There are complex topological relationships between service blocks in a server cluster, such as cross-region communication costs and inter-node latency differences. If the policy model cannot perceive these structures, it will affect deployment efficiency and service quality. To this end, this paper further introduces structural graph embedding features into policy model training, as follows:

[0220] Graph fragment extraction: Each training sample is associated with a service block structure graph fragment, which represents the network structure and attribute relationship between the target deployment area and its adjacent nodes, including:

[0221] Node resource attributes (such as resource abundance);

[0222] Edge weights (e.g., bandwidth, latency);

[0223] Historical scheduling performance (such as stability score).

[0224] Graph neural network encoding: Use GCN (graph convolutional network) or GAT (graph attention network) to process graph fragments, perform node information aggregation and feature propagation, and output structure embedding vectors.

[0225] State input fusion: The state input vector consists of three parts: a structural embedding vector: generated by feature extraction of the service block structure graph by the graph neural network; a context embedding vector: generated by the context classification model based on the module operation label; and a resource state vector: generated based on the CPU, memory, latency and other state parameters collected through monitoring. The combination of the three is used to describe the environment in which the current module is deployed, and serves as the input feature set of the policy model, which is input into the policy network and value network.

[0226] Policy Optimization and Graph Feedback: Through policy training, the model automatically identifies topological combinations that lead to optimal scheduling. In reinforcement learning, if the deployment corresponding to a certain structure results in negative feedback (such as high latency or failure), the graph embedding weights are adjusted through backpropagation, improving the model's adaptability to spatial structure.

[0227] Based on the input set of the current cluster status, the trained policy model generates expansion action recommendations.

[0228] The state input set includes but is not limited to the following:

[0229] The overall load of the cluster (such as total CPU usage and memory consumption);

[0230] The current resource utilization and resource surplus rate of each service block;

[0231] Network communication latency (e.g., round-trip time between service blocks);

[0232] Scheduling adaptability factors of functional modules (such as latency tolerance, elasticity weight, and operational context labels);

[0233] The system's current scalability (e.g., whether each service block has the ability to add new replicas);

[0234] These data are normalized and used as input vectors and sent to the strategy model for reasoning.

[0235] After the policy model is inferred, the output usually includes the following fields:

[0236] Expansion decision value: Boolean type, indicating whether to execute expansion (True / False);

[0237] Target service zone identifier: the target zone for recommended capacity expansion (e.g., zone-A, zone-B);

[0238] Recommended capacity expansion: the number of computing units to be added, such as adding two Pod replicas;

[0239] Optional: Recommendations on expansion timing (immediate execution / delayed observation), etc.

[0240] The above output can be regarded as the model's preliminary judgment on "whether to expand" and "how to expand".

[0241] In order to prevent the policy model from outputting low-credibility suggestions under high uncertainty conditions, the present invention introduces a confidence scoring mechanism as a safety boundary control method for the execution of expansion actions.

[0242] Each time the policy model outputs an expansion action, it generates a confidence score for the action, which usually ranges from 0 to 1 and indicates its credibility in the current state. The confidence score can be calculated based on the following factors:

[0243] The sharpness of the action probability distribution (the maximum value in the softmax output);

[0244] The average value of feedback for the same behavior under similar historical conditions;

[0245] Uncertainty measures internal to the policy model (such as entropy or standard deviation).

[0246] The system dynamically adjusts the confidence threshold based on the current business level and cluster resource risk level. For example:

[0247] Under normal operating conditions, the standard threshold is set to 0.7;

[0248] If system resources are tight or critical business is in progress, increase the threshold to 0.85.

[0249] If you are in a testing environment, you can lower it to 0.5 to allow the model to function freely.

[0250] If the confidence level of the capacity expansion action output by the model is lower than the current threshold, the system enters delayed observation mode, that is, the capacity expansion action is not executed temporarily and will be evaluated again in the next cycle;

[0251] If the confidence level is higher than the threshold, the recommended expansion plan is immediately executed, including target block selection and replica deployment operations.

[0252] This mechanism effectively reduces the risk of incorrect expansion due to model errors or unstable outputs, and improves system robustness.

[0253] Even if the policy model makes a highly confident expansion decision, deviations may occur due to factors such as changes in business scenarios and inconsistent historical behavior. To this end, the present invention introduces a contextual backtracking mechanism to perform multi-dimensional verification of the policy output results.

[0254] The system call function module records the expansion behavior of several past scheduling cycles and extracts the following information:

[0255] The target block and scale of the last expansion;

[0256] It takes time to start the service after expansion;

[0257] Post-deployment service performance metrics (e.g., average response time);

[0258] Check whether there are any expansion failures or deployment interruption records.

[0259] Compare the vector similarity between the current model's recommended action and historical successful capacity expansion actions. Common methods include cosine similarity or Euclidean distance calculation, and output a matching score (e.g., 0 to 1).

[0260] If the matching degree between the current recommended action and the historical efficient behavior is lower than the threshold (e.g., 0.6), and the model confidence is near the critical value (e.g., 0.65-0.75), the policy fallback mechanism is triggered.

[0261] Fallback mechanisms may include:

[0262] Enable expert strategy (rule system takes precedence);

[0263] Use the parameters of the last successful expansion action;

[0264] Postponing the expansion plan pending further observation;

[0265] If the match is high and the confidence is high, the action is executed directly, and the system automatically records the execution effect for the next training sample iteration.

[0266] This mechanism forms a behavioral closed-loop control path of "strategy model → decision recommendation → historical behavior backtracking → action confirmation", ensuring that model decisions are not only scientific but also traceable and business consistent.

[0267] After the policy model in the cluster outputs the expansion decision and completes the deployment of computing units, the system will start the feedback collection submodule to perform structured observation and recording of the expansion results, including the following:

[0268] Deployment-level indicator collection: Record whether the expanded computing power unit is successfully scheduled, the cold start time (from scheduling trigger to the first heartbeat signal), the startup resource allocation (the ratio of initial CPU and memory allocation to actual usage), and whether the replica health status remains stable and meets the standards.

[0269] System-level indicator collection: Record the changing trend of the overall system performance after the expansion is completed, including:

[0270] Changes in the total CPU and memory utilization of the cluster;

[0271] Changes in service response time (P95 / P99);

[0272] Network IO bandwidth and latency fluctuations;

[0273] Is there any improvement in the failure rate?

[0274] Structured archiving method: Encode the above data into structured JSON or Protobuf format, with the following fields:

[0275] Expansion behavior identifier (including service module ID, timestamp, target block ID, number of expansion replicas, etc.);

[0276] The various performance indicators collected;

[0277] Summary of the current running situation and scheduling strategy.

[0278] The feedback information will be written into the "Policy Learning Data Cache" for batch loading during model tuning.

[0279] In order to achieve targeted learning and optimization of the strategy model, the present invention constructs a feedback evaluation function mechanism to quantify the execution effect of each scheduling behavior, and compares it with the expected effect of the original strategy to guide strategy adjustment.

[0280] Evaluation function definition: Preset a set of evaluation index items and weighted combination functions, usually including:

[0281] Deployment success rate score;

[0282] Startup time score (the shorter the time, the higher the score);

[0283] Single-copy resource utilization (stability indicator);

[0284] Improvement in system performance after deployment (e.g., reduction in response time);

[0285] Deployment cost control score (such as whether it enters a high-cost block).

[0286] Behavior score output: After each expansion, the system uses feedback indicators to calculate a normalized score (e.g., in the range of 0–1, where higher scores represent better behavior).

[0287] Difference calculation and loss function update:

[0288] The strategy model has predicted the expected return under this state before execution;

[0289] The system will calculate the difference between the actual score and the expected return;

[0290] This difference is used as part of the policy loss function and participates in backpropagation to update the policy network parameters.

[0291] This "expectation-actual" difference-driven learning mechanism can guide the model to correct erroneous estimates and improve the accuracy of behavioral selection.

[0292] To achieve the continuous evolution of the model rather than one-time training, this paper introduces a continuous tuning mechanism based on time windows and strategy rounds to achieve incremental learning and version verification of the strategy model. The process is as follows:

[0293] Tuning trigger mechanism:

[0294] Set the tuning window, such as "every 10 minutes" or "every 20 expansion actions";

[0295] After each window ends, all expansion records and scoring information are collected to form a batch training sample set.

[0296] Incremental model updates:

[0297] Do not retrain the entire policy model to avoid online service interruption;

[0298] Instead, only the “shallow weight group” or “sub-strategy branch” in the policy network is updated to keep the overall model structure stable;

[0299] The update is done using mini-batch gradient descent or a low-rate optimizer such as RMSProp.

[0300] Model version control and verification mechanism:

[0301] After updating, a new model version is generated and saved to the "Candidate Strategy Pool";

[0302] In subsequent expansion activities, A / B testing methods were used to deploy the new and old models simultaneously on different service modules;

[0303] Compare their differences in response time, deployment success rate, and resource consumption, and select the one with the best performance to update to the main model.

[0304] This mechanism effectively avoids the risk of performance degradation during policy updates, while allowing the model to automatically learn and evolve with the operating environment.

[0305] Example 2, please refer to Figure 2 As shown, the operation and management system of a server cluster described in this embodiment includes a data acquisition module, a sample scoring module, a generation model training module, a sample enhancement and management module, and a distributed recognition module;

[0306] The environment construction module is used to build the operating environment of the server cluster, including the computing power unit pool configured in multiple service blocks and the functional module copies deployed on the computing power units;

[0307] The context recognition module is used to identify the type of operating context based on the current resource usage status and application tag information of the functional module copy, and to build a corresponding scheduling adaptation factor model;

[0308] The strategy modeling module is used to define the state input set and feedback evaluation function of the elastic control strategy based on the scheduling adaptation factor model;

[0309] A structural graph construction module is used to model the link capacity, location distribution, and interaction delay between each service block into an extended structural graph, and input the graph as a feature parameter into the strategy model;

[0310] The policy training module includes a deep self-tuning engine for offline reinforcement learning training of the policy model to generate the optimal scheduling action mapping under different operating scenarios and structural graph conditions;

[0311] The policy reasoning module is used to dynamically determine whether to perform computing power expansion operations based on the current cluster state input and the trained policy model, and to determine the target service block for expansion and the number of computing power units required;

[0312] The feedback update module is used to collect operational feedback information on expansion behaviors and various system monitoring indicators, and structure their feedback to the policy model, and incrementally update the policy model through a continuous tuning mechanism.

[0313] The above formulas are all dimensionless and numerical calculations. The formulas are obtained by collecting a large amount of data and performing software simulation to obtain the most recent real situation. The preset parameters in the formulas are set by technicians in this field according to actual conditions.

[0314] It should be understood that the term "and / or" as used herein simply describes a relationship between associated objects, indicating that three possible relationships exist. For example, "A and / or B" can represent: A alone, A and B together, or B alone. A and B can be singular or plural. Furthermore, the character " / " as used herein generally indicates an "or" relationship between the associated objects, but it may also indicate an "and / or" relationship. For specific understanding, please refer to the context.

[0315] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0316] The above is only a specific implementation method of the present application, but the scope of protection of the present application is not limited thereto. Any technician familiar with this technical field can easily think of changes or replacements within the technical scope disclosed in this application, which should be covered by the scope of protection of the present application.

Claims

1. A method for managing the operation of a server cluster, characterized by: include: Build the operating environment of the server cluster, including a pool of computing units distributed across multiple service blocks and copies of functional modules deployed on the computing units; Based on the current resource usage status and application tag information of the functional module replica, the operating scenario type is identified and the corresponding scheduling adaptation factor model is constructed; According to the scheduling adaptation factor model, a state input set and a feedback evaluation function of the elastic control strategy are defined; The link capacity, location distribution, and interaction delay between service blocks are modeled as an extended structural graph and introduced into the strategy model as characteristic parameters. Specifically, the approach involves constructing a directed graph of service block sets, where each node corresponds to a service block and an edge represents a data transmission path between two blocks. For each edge, the corresponding bandwidth capacity, average network latency, and cross-block distance factor are collected and mapped to the edge's connection weight. The graph is then normalized and used as a topological embedding feature in the input of the elastic control strategy model to optimize node selection and scheduling region matching. Using a deep self-tuning engine to perform offline reinforcement learning training on the policy model to generate optimal action mappings for different operating scenarios and structural graphs; Based on the current state of the cluster and the trained policy model, dynamically determine whether to perform computing power expansion operations and expand the number of target service blocks and units; The operational feedback information of computing power expansion behavior and various monitoring indicators are returned to the strategy model, and the strategy is updated based on the continuous tuning mechanism.

2. The method for managing the operation of a server cluster according to claim 1, wherein: The operating environment for building the server cluster includes: For each computing power unit, measure the network round-trip time between it and the dependent nodes; calculate the weighted average of the communication delays of multiple dependent nodes, where the weight of each node is assigned according to the call frequency between it and the functional module; use the weighted average communication time as the communication overhead indicator of the computing power unit; based on the communication overhead indicator, give priority to computing power units with low latency for deploying functional module replicas.

3. The operation management method of a server cluster according to claim 1, characterized in that: The identifying of the operation scenario type and constructing the corresponding scheduling adaptation factor model includes: Collect resource usage data of the target functional module replica within the predetermined monitoring period, including average CPU usage, memory utilization, request response time, and call frequency; Parsing the application tag information carried by the functional module, the tag includes a structured identification field indicating the service type to which the module belongs, the service priority level, and whether it is a state-retaining service; Based on the preset operation scenario identification rules, the current state of the module is mapped to a variety of operation scenario types using rule matching, including high-concurrency processing, computation-intensive, low-latency interactive, or resource-saving; For the identified operating scenario type, a corresponding scheduling adaptation factor model is constructed. The model is a set of parameters that affect the selection of scheduling strategies, including region selection weight, startup priority, delay tolerance threshold, and expected deployment cycle.

4. The operation management method of a server cluster according to claim 1, characterized in that: Service characteristic parameters, including regional elasticity weight, deployment priority, resource sensitivity threshold, and delay tolerance level, are extracted from the scheduling adaptation factor model. Based on the service characteristic parameters and the current resource status of the cluster, a state input set including node idle rate, network delay, historical deployment behavior, and failure rate is constructed and used as the input of the elasticity control strategy model. Multi-objective feedback items, including at least deployment success rate, startup time, resource utilization, and deployment cost, are defined, and weights are assigned to each feedback item to construct a weighted combination feedback evaluation function.

5. The method for managing the operation of a server cluster according to claim 1, wherein: The offline reinforcement learning training of the policy model using the deep self-tuning engine includes: Initialize a dual-structure model consisting of a policy network and a value network. The policy network is used to generate a probability distribution of scheduling actions, and the value network is used to estimate the cumulative expected reward of the current state. Construct an offline training sample set that includes a state input set, actual deployment actions, and feedback evaluation functions; Use pre-collected system operation history records as training samples to perform behavior cloning warm-up training on the policy network to stabilize the initial output of the model; Based on the offline reinforcement learning algorithm, the strategy-value network is jointly optimized to minimize the gap between action prediction error and expected reward, and generate the basic strategy mapping function.

6. The method for managing the operation of a server cluster according to claim 5, wherein: The offline training process further includes: For each state input sample used for training, extract the corresponding service block structure graph fragment, including the embedding vectors of the target block node and its adjacent nodes; A graph neural network algorithm is used to perform message passing and aggregation processing on graph fragments to generate a high-dimensional structure-aware embedding vector. This vector is then combined with the context embedding vector generated based on the operating context type and the resource state vector generated based on the resource usage status to form a complete state input vector. During the policy training process, the model is guided to learn the scheduling policy performance under the influence of the topological structure, thereby achieving optimal expansion behavior mapping for the structural graph.

7. The method for managing the operation of a server cluster according to claim 1, wherein: The dynamic determination of whether to perform the computing power expansion operation based on the cluster current state input and the trained policy model includes: Receive the current cluster resource status input set, including the remaining resources of each service block, network latency, service load indicators and operation scenario characteristics provided by the scheduling adaptation factor model; Input its input set into the trained policy model, triggering the policy model to perform inference operations and generate an output set containing recommended expansion actions; The output set includes a Boolean determination value of whether to expand capacity, an identifier of the target service block for recommended expansion, and the number of computing power units recommended for expansion; Determine whether to perform capacity expansion based on the output of the policy model. If not, maintain the existing deployment status.

8. The method for managing the operation of a server cluster according to claim 1, wherein: The strategy update based on the continuous optimization mechanism includes: After each computing power expansion operation is executed, operational feedback information including deployment success rate, startup time, resource usage stability, cluster load changes, and service response time is collected and archived in a structured manner in association with the corresponding expansion action; Based on the feedback information, the comprehensive behavioral score of the current expansion action is calculated and compared with the expected return value of the strategy model before the decision is made; Set a fixed time window or policy behavior round as the model update cycle, collect feedback datasets and construct incremental training sample sets; Under the premise of ensuring the stability of online reasoning, incremental parameter adjustments are performed on the policy network, and the updated model is selected through the version comparison verification mechanism to complete the continuous policy tuning process.

9. An operation management system for a server cluster, used to implement the operation management method for a server cluster according to any one of claims 1 to 8, characterized in that: include: The environment construction module is used to build the operating environment of the server cluster, including the computing power unit pool configured in multiple service blocks and the functional module copies deployed on the computing power units; The context recognition module is used to identify the type of operating context based on the current resource usage status and application tag information of the functional module copy, and to build a corresponding scheduling adaptation factor model; The strategy modeling module is used to define the state input set and feedback evaluation function of the elastic control strategy based on the scheduling adaptation factor model; A structural graph construction module is used to model the link capacity, location distribution, and interaction delay between each service block into an extended structural graph, and input the graph as a feature parameter into the strategy model; The policy training module includes a deep self-tuning engine for offline reinforcement learning training of the policy model to generate the optimal scheduling action mapping under different operating scenarios and structural graph conditions; The policy reasoning module is used to dynamically determine whether to perform computing power expansion operations based on the current cluster state input and the trained policy model, and to determine the target service block for expansion and the number of computing power units required; The feedback update module is used to collect operational feedback information on expansion behaviors and various system monitoring indicators, and structure their feedback to the policy model, and incrementally update the policy model through a continuous tuning mechanism.

Images