End-cloud integrated cluster dynamic container capacity planning method facing simulation task load dynamic change

Abstract

The invention discloses a simulation task load dynamic change-oriented end-cloud integrated cluster dynamic container capacity planning method, and relates to the technical field of computer services. Modeling a micro-service, a container, a user and a server; load sensing and triggering judgment, including calculation of micro-service total load and load variation, calculation of load intensity and triggering condition judgment; mDP differential capacity adjustment: constructing an MDP state space, formulating a container capacity expansion and shrinkage strategy, and calculating an adjustment correction coefficient; key index calculation including a response time model, a system total cost model and a fairness index model; and carrying out multi-objective solution and verification, namely constructing an objective function, setting constraint conditions and solving by adopting fusion MDP. Hierarchical modeling is carried out by adopting micro-services, containers, users and servers, MDP decision differentiation adjustment is triggered through load sensing, multi-target solving is carried out, a four-layer technical architecture of modeling-sensing-decision-solving is formed, and dynamic optimization of cluster capacity can be realized.

Description

Technical Field

[0001] This invention relates to the field of computer service technology, specifically a dynamic container capacity planning method for an integrated edge-cloud cluster oriented to dynamically change the workload of simulation tasks. Background Technology

[0002] In recent years, with the rapid development of fields such as industrial manufacturing, digital twins, and artificial intelligence, the application demand for computationally intensive tasks such as engineering physics simulation, XR pre-rendering, and AI training has been surging. These tasks are often characterized by large data volumes, high computational complexity, and long operating cycles, placing extremely high demands on the scale and stability of computing resources. Edge-cloud integrated technology, with its advantages of "providing massive computing power in the cloud and ensuring convenient interaction at the terminal," has become the core technical architecture supporting the efficient operation of such tasks.

[0003] In an edge-cloud integrated cluster environment, computationally intensive tasks need to support dual access modes: a cloud-based editor and a local editor. The cloud-based editor enables multi-user collaborative editing and continuous long-session interaction, while the local editor meets users' offline operation and local data storage needs. Both access modes share core services such as the backend compiler and solver, forming a complex service chain dependency relationship (e.g., cloud-based editor → compiler → solver, local editor → compiler → solver). Simultaneously, user load exhibits significant dynamic fluctuations characterized by "sudden spikes in batch submissions and subsequent drops upon task completion." For example, in engineering physics simulation scenarios, a design team might submit dozens of simulation tasks at a project node, causing the cluster load to double in a short period; however, once most tasks have completed their computations, the load quickly drops back to a low level. Traditional container capacity planning methods, based on static resource allocation or simple dynamic adjustment logic, are no longer suitable for these complex scenarios.

[0004] The existing technology has the following significant limitations:

[0005] ① Insufficient scaling and adaptation for stateful services: specifically for cloud-based editors. For these types of stateful long-session services, traditional methods do not incorporate the COW (Copy-on-Write) mechanism to optimize resource consumption, and do not avoid session migration during scaling up and down, which can easily lead to the loss of user editing history or service interruption, and cannot guarantee the continuity of long sessions.

[0006] ② Single load fluctuation response strategy: When faced with dynamic load changes, existing methods mostly adopt a "uniform scaling up and down step size" without distinguishing between different load sizes. (Stateful) and The (stateless) characteristics are different. Under high load, the response delay is prone to exceed the limit due to the adjustment lag, while under low load, the excessive retention of resources will cause waste.

[0007] ③ Lack of multi-objective balancing mechanism: Traditional solutions only focus on a single objective (such as only optimizing response time or only reducing resource costs) and have not built a multi-objective balancing model of "service fairness-cost-response time", which cannot meet the differentiated QoS needs of users with different priorities;

[0008] ④ Insufficient coordination between service chains and routing: Service chain dependencies were not considered. → → Or local editor → → Under the routing and capacity coordination of cloud servers, when deploying services across cloud servers, the overall response time is easily increased due to transmission delays, which reduces service efficiency.

[0009] Based on the current state of the technology, there is an urgent need to propose a dynamic container capacity planning method for end-to-cloud integrated clusters that is specifically designed for dynamic changes in simulation task load, in order to address the shortcomings of traditional technologies in terms of stateful service adaptation, load response differentiation, multi-objective balancing, and service chain collaboration. Summary of the Invention

[0010] To address the shortcomings of the existing technologies, this invention provides a dynamic container capacity planning method for an integrated cloud-edge cluster oriented to dynamically change the workload of simulation tasks. It adopts layered modeling of microservices, containers, users, and servers, triggers MDP decision differentiation adjustment through load awareness, and performs multi-objective solution, forming a four-layer technical architecture of modeling-awareness-decision-solution, which can realize dynamic optimization of cluster capacity.

[0011] To achieve the above objectives, the present invention adopts the following technical solution: a dynamic container capacity planning method for an integrated edge-cloud cluster oriented to dynamically change simulation task load, comprising the following steps:

[0012] Step S1: Microservices, Containers, User and Server Modeling:

[0013] S1.1 Microservice Modeling: ① Define a collection of microservices , For microservices, ,in, For cloud-based editors, For compilers, As the solver, the three constitute the core link of task processing; ② Construction Session state resource model, distinguishing between single-session resources in read-only and modified states; ③ Construct Node deployment model, distinguishing between single-node deployment and multi-node deployment total resource calculation methods; ④ Build Resource requirement model to determine the relationship between single-task CPU requirements, task computation volume, and user priority;

[0014] S1.2 Container Modeling: ① Define a collection of containers , cloud server Microservices ① Define the unique container cluster; ② Define the core container parameters, including the number of instances. Single container resources Startup delay is Stop delay and image stabilization window ,in , and These are CPU resource configuration and memory resource configuration, respectively.

[0015] S1.3 User and Server Modeling: ① Construct a user attribute model and define user sets. , , For users Priority For access methods, For the service chain, ① Define the user session duration for cloud access; ② Construct a cloud server attribute model and define a set of cloud servers. , , This refers to the total amount of CPU and memory resources. ③Construct a network parameter model, defining the network bandwidth and one-way latency sets for user-cloud server and cloud server-cloud server connections;

[0016] Step S2, Load Awareness and Trigger Determination: ① Calculate the total load and load change of the microservice; ② Calculate the load intensity, which is the ratio of the load of the microservice on the cloud server to the total service rate of the container cluster; ③ Determine the triggering conditions, which are divided into expansion trigger and reduction trigger. Expansion trigger is when the load intensity is greater than the high load threshold or the load increment is greater than the growth threshold. Reduction trigger is when the load intensity is less than the low load threshold or the load reduction is greater than the decrease threshold. If the triggering conditions are met, enter the debouncing verification. If the conditions are continuously met within the debouncing window or the cumulative change exceeds the threshold, proceed to the next step.

[0017] Step S3, MDP Differentiated Capacity Adjustment: ① Build an MDP state space for each microservice. , Given the current load intensity, This refers to the previous adjustment action. ② Develop a load change trend; Container scaling-up and scaling-down strategies prioritize adjusting single container resources, and adjust the number of instances once resources reach the upper / lower limit; ③ Formulate The container scaling-up and scaling-down strategy prioritizes adjusting the number of instances, and adjusts the resources of a single container after the number of instances reaches the upper / lower limit; ④ Calculates the adjustment correction coefficient to ensure that the adjustment amount adapts to the load trend, and finally outputs the adjustment result;

[0018] Step S4, Key Indicator Calculation: ① Constructing a Response Time Model Distinguish cloud access user response time and local access user response time ② Construct a total system cost model For various cloud servers as well as The sum of resource consumption costs; ③ Construct a fairness indicator model, using the weighted Jain index. To quantify the fairness of weighted response times for users with different priorities;

[0019] Step S5, Multi-objective solution and verification: ① Construct the objective function , For balance coefficient, The process involves several steps: ① Maximizing the allowable cost; ② Setting constraints, including response time constraints, cloud server resource constraints, and system stability constraints; ③ Employing a fusion MDP solution algorithm. First, an initial solution is constructed, parameters are initialized, the number of instances is calculated based on the initial load and basic resources, resource configuration is set according to the task memory-CPU ratio, and the initial MDP state is set to stable load and no historical actions. Then, routing initialization is performed, routing tasks to the cloud server with the most remaining resources to ensure service chain deployment on the same node; Next, a greedy optimization driven by MDP is performed, collecting load intensity and changes at a fixed sampling period to update the MDP state, adjusting the instance count step size based on the MDP state, and simultaneously verifying cloud server resource constraints. After the instance count reaches the upper / lower limit, the resource step size is adjusted according to the MDP state. Finally, route collaborative optimization is performed, adjusting routes when cross-cloud server transmission latency exceeds a threshold, and simultaneously updating the MDP state and container adjustment amount; ④ Verifying the optimal solution, iteratively optimizing until the objective function value difference is less than a preset threshold for two consecutive times, and the MDP state remains stable for multiple consecutive periods, outputting the optimal number of container instances, single container resource configuration, and the optimal MDP state sequence.

[0020] Furthermore, in step S1.1, the construction In the session state resource model, single-session resources in the user's read-only state are the basic resources. , CPU resources used This refers to the memory resources used; single-session resources in the user-modified state are copied resources. with incremental resources The sum of the resources, copied resources , The base resource ratio for replication, incremental resources Additional resources incurred for modifying the model.

[0021] Furthermore, in step S1.1, the construction When deploying a node, a single-node deployment satisfies the requirement that the total number of sessions is less than or equal to the session threshold, and the total resources are the sum of read-only and modification session resources. A multi-node deployment satisfies the requirement that the total number of sessions is greater than the session threshold, and the number of extended nodes is the ratio of the number of sessions to the threshold rounded up. The total resources include the basic resources of each node, modification session resources, and cross-node synchronization overhead. Cross-node synchronization overhead is the additional resource overhead of cross-node data synchronization.

[0022] Furthermore, in step S1.1, the construction When modeling resource requirements, for users The model, The total computational cost of the compilation task is , The total computational cost of solving the task is CPU resources are allocated as ,Pick , For task coefficients, User priority weight.

[0023] Furthermore, when defining the container core parameters in step S1.2, the startup delay satisfies... , Session state needs to be loaded. Only load the runtime environment.

[0024] Furthermore, in step S1.3, when constructing the network parameter model, the user-cloud server network bandwidth set... User-cloud server network one-way latency set Cloud server - Cloud server network bandwidth collection Cloud server - Cloud server network one-way latency set , For users With cloud servers Network bandwidth between For users With cloud servers Communication delay between them cloud server With another cloud server Network bandwidth between cloud server With another cloud server Communication delay between them.

[0025] Furthermore, in step S3, the following is defined: When implementing container scaling-up and scaling-down strategies, single container resources are adjusted using dynamic step sizes. The dynamic step size rules are as follows: the initial step size is set based on the base value; the step size for continuous scaling-up is the previous step size plus the scaling factor. The product of the two factors does not exceed the maximum value; the step size in the continuous shrinkage state is the previous step size plus the shrinkage coefficient. The product of and is not less than the minimum value; the fluctuation state recovers to the initial step size, and the formula is determined. When implementing container scaling up and down strategies, the number of instances is adjusted according to a dynamic step size. The dynamic step size rules are as follows: the initial step size is set according to the base value, the step size increases during continuous scaling up, decreases during continuous scaling down, and returns to the initial step size during fluctuating states. The number of instances can be increased to the maximum value.

[0026] Furthermore, in step S4, a response time model is constructed. At that time, cloud access user response time Including waiting time, Interaction delay, Execution time and inter-service transmission latency; local access user response time Including waiting time, model upload time, Execution time and inter-service transmission latency are calculated based on bandwidth and latency for cross-cloud server transmission latency, while transmission latency within the same cloud server is ignored.

[0027] Furthermore, in step S4, the weighted Jain index Represented as:

[0028]

[0029] In the formula, Total number of users For users Weighted response time The weight corresponding to the user's priority.

[0030] Furthermore, when setting constraints in step S5:

[0031] Response time constraints are satisfied:

[0032]

[0033] In the formula, Indicates user priority. The user set, Indicates user priority. users , Indicates priority as The response time for the user. Priority is The maximum response time allowed by the user;

[0034] Cloud server resource constraints are met:

[0035]

[0036] System stability constraints are satisfied: Each container cluster The load strength is less than 1.

[0037] Compared with existing technologies, the beneficial effects of this invention are as follows: The method of this invention adopts a resource-priority adjustment strategy for stateful services combined with a COW mechanism, which can effectively avoid session migration and interruption caused by scaling up and down, ensuring session continuity. Simultaneously, based on Markov decision-making, it captures "load intensity - historical actions - changing trends" to achieve dynamic step-size adjustment, enabling rapid scaling up under high load and gradual scaling down under low load, reducing lag and over-adjustment, and improving adaptability. Furthermore, by flexibly adjusting fairness and cost focus through a balancing coefficient, it achieves multi-objective balance optimization to meet the needs of different scenarios. In addition, the coordinated design of routing and capacity can reduce cross-cloud server transmission latency, and the anti-jitter mechanism reduces adjustment costs and improves service chain efficiency. The overall solution has broad applicability, can adapt to various computationally intensive tasks, and parameters can be adjusted according to scenario characteristics without modifying the core logic. Attached Figure Description

[0038] Figure 1 This is an overall execution block diagram of the method of the present invention;

[0039] Figure 2 This is a flowchart of the load sensing and trigger determination process in the method of this invention;

[0040] Figure 3 This is a flowchart of the cloud-based editor adjustment process for MDP differentiated capacity adjustment in the method of this invention;

[0041] Figure 4 This is a flowchart of the compiler-solver adjustment process for MDP differential capacity adjustment in the method of this invention. Detailed Implementation

[0042] 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 invention, not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0043] like Figures 1-4 As shown, a dynamic container capacity planning method for an integrated edge-cloud cluster, oriented towards dynamic changes in simulation task load, is described, and its execution flow combines... Figure 1As shown, it includes the following steps:

[0044] Step S1: Microservices, containers, users, and server modeling;

[0045] S1.1 Microservice Modeling:

[0046] ① Define a set of microservices: Let the set of microservices be defined. , For microservices, ,in, For cloud-based editors (stateful long-session service). For compilers (stateless, computationally intensive services). The solver (a stateless, computationally intensive service) and the three components together form the core link for task processing.

[0047] ②Construction Session state resource model: A single session resource is the user's request. The system resources consumed by establishing a persistent connection with the system during service provision vary depending on the user's operation state. In read-only mode, single-session resources are the basic resources. ,in, CPU resources used This refers to the memory resources used; in user-modified mode, the single-session resource is a copy resource. with incremental resources The sum, of which, copied resources , The base resource ratio for replication, incremental resources The additional resources required to modify the model are positively correlated with operational complexity. The total resources of a single cloud server node are the sum of all single-session resources.

[0048] ③Construction Node deployment model: In single-node deployment (total number of sessions less than or equal to the session threshold), the total resources are the sum of read-only and modification session resources; in multi-node deployment (total number of sessions greater than the session threshold), the number of expanded nodes is the rounded-up ratio of the number of sessions to the threshold, and the total resources include the basic resources of each node, modification session resources, and cross-node synchronization overhead. The cross-node synchronization overhead is the additional resource overhead for cross-node data synchronization (because in multi-node deployment, each node allocates resources independently and cannot share them).

[0049] ④ Construction Resource requirement model: Single-task CPU requirements are positively correlated with task computation volume and user priority. For users... The model, The total computational cost of the compilation task is (Unit: CPU cycles) The total computational cost of solving the task is (Unit: CPU cycles). Therefore, CPU resource allocation is... subscript Winning , This represents the task coefficient; different microservices correspond to different resource allocations for their respective tasks. User priority weight.

[0050] S1.2 Container Modeling:

[0051] ① Define a collection of containers: for each microservice and cloud servers There is a unique container cluster. Then the container set .

[0052] ② Define the container's core parameters:

[0053] The number of instances is Deployed on a cloud server microservices The number of instances;

[0054] Single container resources : Including CPU resource configuration for a single container With memory resource configuration ;

[0055] Startup delay is : ( Session state needs to be loaded. Only the runtime environment needs to be loaded).

[0056] Stop delay and image stabilization window (Used to avoid frequent expansion and contraction operations).

[0057] S1.3 User and Server Modeling:

[0058] ① User attribute model: Define user set Each user Attributes are ,in, For users Priority The higher the user priority, the higher the corresponding weight. The larger, Access method (cloud access / local access). For service chain (cloud access including) Local access does not include ), This refers to the duration of a user session for cloud access.

[0059] ② Cloud Server Attribute Model: Defines a collection of cloud servers Each cloud server Attributes are ,in, This refers to the total amount of CPU and memory resources. The price of CPU and memory resources.

[0060] ③ Network parameter model: The user-cloud server network includes a set of bandwidth and one-way latency, and the cloud server-cloud server network includes a set of bandwidth and one-way latency, both of which are used to calculate data transmission time.

[0061] The network bandwidth and communication latency between each user terminal and each cloud server in the system are expressed as follows:

[0062]

[0063]

[0064] The network bandwidth and communication latency between the cloud servers in the system are expressed as follows:

[0065]

[0066]

[0067] In the formula, For user-cloud server network bandwidth aggregation, For users With cloud servers Network bandwidth between For the user-cloud server network one-way latency set, For users With cloud servers Communication delay between them For cloud servers - cloud server network bandwidth collection, cloud server With another cloud server Network bandwidth between This is the set of one-way network latency between cloud servers. cloud server With another cloud server Communication delay between them.

[0068] Step S2, load perception and trigger determination, process integration Figure 2 As shown;

[0069] ① Calculate the total load of the microservices: The load is contributed only by cloud access users. The load is contributed by all users. Load and Consistent (one-to-one correspondence between compiler and solver). The load change is the difference between the new load and the old load; a positive value indicates an increase in load, and a negative value indicates a decrease.

[0070] ② Calculate load intensity: Load intensity is the ratio of the load of microservices on cloud servers to the total service rate of container clusters. It is used to quantify the container load level and thus determine load trend changes.

[0071] ③ Triggering Condition Determination: This is divided into two cases: expansion triggering and shrinkage triggering. Expansion triggering occurs when load intensity > high load threshold or load increment > growth threshold; shrinkage triggering occurs when load intensity < low load threshold or load reduction > decrease threshold. If the expansion or shrinkage triggering conditions are not met, the total microservice load is recalculated by collecting data at fixed intervals. If the conditions are met, debouncing verification begins. If the conditions are consistently met within the debouncing window or the cumulative change exceeds the threshold, capacity adjustment is triggered, and the process proceeds to the next step for MDP differentiated capacity adjustment. Otherwise, the total microservice load is recalculated by collecting data at fixed intervals.

[0072] Step S3: Adjust the MDP differentiated capacity;

[0073] S3.1 Define the state space of a Markov Decision Process (MDP):

[0074] For each microservice, construct an MDP state space. ,in, cloud server microservices The current load intensity, This refers to the previous adjustment action (expansion / shrinkage / no action). For microservices The load change trend (rising / falling / stable).

[0075] S3.2, Container scaling up and down strategies, combined with processes Figure 3 As shown:

[0076] First, determine whether the adjustment type is expansion or contraction, and define the adjustment priority. Both expansion and contraction prioritize adjusting single-container resources. During expansion, check if the resources have reached the limit. If so, it indicates insufficient resources, and the number of instances is increased to avoid session migration. Otherwise, resources are increased in dynamic increments. During contraction, check if the resources have reached the lower limit. If so, the number of instances is reduced (the adjustment of the number of instances must ensure...). Complete shutdown is prohibited; otherwise, resources will be reduced in dynamic steps. The dynamic step size rules are as follows: the initial step size is set based on the base value; in continuous expansion states (previous expansion and increased load), the step size is the previous step size plus the expansion coefficient. The product of these factors does not exceed the maximum value; in continuous shrinkage states (where the previous shrinkage occurred and the load decreased), the step size is the previous step size plus the shrinkage coefficient. The product of and is not less than the minimum value; the fluctuation state recovers to the initial step size.

[0077] S3.3、 Container scaling up and down strategies, combined with processes Figure 4 As shown:

[0078] First, determine whether the adjustment type is expansion or contraction, and define the adjustment priority. Both expansion and contraction prioritize adjusting the number of instances. When expanding, check if the number of instances has reached the upper limit. If so, increase the resources per container; otherwise, increase the number of instances by a dynamic step size. When contracting, check if the number of instances has reached the lower limit (compared to step S3.2, the number of instances can be reduced to 0 here). If so, reduce the resources per container (resource adjustment should not be lower than the minimum configuration, CPU 0.5 cores, memory 512MB); otherwise, reduce the number of instances by a dynamic step size. The dynamic step size rules are as follows: the initial step size is set according to the base value, the step size increases during continuous expansion, decreases during continuous contraction, and returns to the initial step size during fluctuations. The number of instances can be increased to the maximum value.

[0079] S3.4 Calculate the adjustment correction coefficient: Set the correction coefficient based on the input MDP status to ensure that the adjustment amount is amplified when continuously expanding the capacity and reduced when continuously shrinking the capacity. The adjustment amount is calculated according to the base value when the fluctuation status is stable, ensuring that the adjustment amount is adapted to the load trend and finally outputting the adjustment result.

[0080] Step S4: Calculation of key indicators;

[0081] ① Construct a response time model :

[0082] Response time model There are two scenarios: cloud access user response time is recorded as... Including waiting time, Interaction delay, Execution time (ratio of computational task to allocated CPUs) and inter-service transmission latency; local access user response time is denoted as... Includes waiting time and model upload time (ratio of model size uploaded by local access users to bandwidth). Execution time (ratio of computational task to allocated CPUs) and inter-service transmission latency. Transmission latency across cloud servers is calculated based on bandwidth and latency, while transmission latency within the same cloud server is ignored.

[0083] ② Construct a total system cost model:

[0084] Total system cost For each cloud server as well as The sum of resource consumption costs.

[0085] ③ Construct a fairness indicator model:

[0086] Using the weighted Jain index The weighted Jain index quantifies the fairness of weighted response times for users with different priorities; the closer the index is to 1, the better the fairness. Represented as:

[0087]

[0088] In the formula, Total number of users For users Weighted response time.

[0089] Step S5: Multi-objective solution and verification;

[0090] S5.1 Constructing the Objective Function: With fairness and cost as the core optimization objectives, construct the objective function. ,in, For balance coefficient, This represents the maximum permissible cost.

[0091] S5.2 Setting Constraints: Response time constraints, cloud server resource constraints, and system stability constraints are used together as constraints, among which:

[0092] ① The response time constraint is that the average response time for each priority user does not exceed the maximum allowable value, expressed as:

[0093]

[0094] In the formula, Indicates user priority. The user set, Indicates user priority. users , Indicates priority as The response time for the user. Priority is The maximum response time allowed by the user;

[0095] ② Cloud server resource constraints stipulate that the resource allocation for each container shall not exceed the total CPU and memory of the cloud server, expressed as:

[0096]

[0097] ③ The system stability constraint is for each container cluster The load intensity is less than 1 to avoid the queue from growing indefinitely.

[0098] S5.3, Solution algorithm for fusion Markov decision:

[0099] ① Constructing the initial solution: First, initialize the parameters by calculating the number of instances based on the initial load and basic resources, setting the resource configuration according to the task memory-CPU ratio, and setting the initial MDP state to a stable load with no historical actions; then initialize the routing by routing the task to the cloud server with the most remaining resources to ensure that the service chain is deployed on the same node (to reduce transmission latency).

[0100] ② MDP-driven greedy optimization: First, perform state updates by collecting load intensity and changes at fixed sampling periods and updating the MDP state (load trends are determined by continuous multi-period changes); then optimize the number of instances by adjusting the instance count step size according to the MDP state, scaling up when the load exceeds the threshold and scaling down when the load is insufficient, while simultaneously verifying cloud server resource constraints; next, optimize resource configuration by adjusting the resource step size according to the MDP state after the number of instances reaches the upper / lower limit, ensuring that resource limits and minimum configurations are not exceeded; finally, optimize routing coordination by adjusting routes when cross-cloud server transmission latency exceeds the threshold, while simultaneously updating the MDP state and container adjustment amount.

[0101] S5.4 Verify the optimal solution:

[0102] ① Convergence determination: When the difference between the objective function values ​​is less than the preset threshold for two consecutive iterations and the MDP state remains stable for multiple consecutive cycles (defined as the number of cycles ≥ 50), it is determined to be converged;

[0103] ② Output results: Output the optimal number of container instances, single container resource configuration, and optimal MDP state sequence.

[0104] Through the above design, this invention is applicable to edge-cloud integrated cluster environments for computationally intensive tasks such as engineering physics simulation, XR pre-rendering, and AI training. By establishing microservice layered modeling (including stateful session modeling and stateless computation modeling), container core parameter modeling, Markov Decision Process (MDP) state model, and multi-dimensional constraints such as response time, cloud server resources, and user fairness, and using a multi-objective function that integrates user priority and load intensity as the capacity optimization evaluation index, the optimal capacity configuration of the cluster under dynamic load changes is achieved by adjusting the number of container instances and single container resource configuration on each cluster node, combined with MDP dynamic step size and service link routing coordination. It can adapt to the dual access mode of "cloud editor + local editor" and balance service quality, user fairness, and system resource efficiency by dynamically adjusting container capacity. Among them, the MDP state model refers to a three-dimensional state space built based on "load intensity - historical adjustment actions - load change trend", which is used to adapt to the load characteristics of "sudden increase in batch tasks and decrease after task completion", ensuring that the step size adjustment is more in line with the dynamic load trend; the service chain adaptation refers to the difference between cloud editor access and local editor access, to achieve accurate resource allocation under different access methods, and avoid the waste of resources for irrelevant services.

[0105] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered illustrative and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of the equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

[0106] Furthermore, it should be understood that although this specification describes embodiments, not every embodiment contains only one independent technical solution. This narrative style is merely for clarity. Those skilled in the art should consider the specification as a whole, and the technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.

Claims

1. A method for dynamic container capacity planning in an integrated edge-cloud cluster for simulation task load dynamic changes, characterized in that: Includes the following steps: Step S1: Microservices, Containers, User and Server Modeling: S1.1 Microservice Modeling: ① Define a collection of microservices , For microservices, ,in, For cloud-based editors, For compilers, As the solver, the three constitute the core link of task processing; ② Construction Session state resource model, distinguishing between single-session resources in read-only and modified states; ③ Construct Node deployment model, distinguishing between single-node deployment and multi-node deployment total resource calculation methods; ④ Build Resource requirement model to determine the relationship between single-task CPU requirements, task computation volume, and user priority; S1.2 Container Modeling: ① Define a collection of containers , cloud server Microservices ① Define the unique container cluster; ② Define the core container parameters, including the number of instances. Single container resources Startup delay is Stop delay and image stabilization window ,in , and These are CPU resource configuration and memory resource configuration, respectively. S1.3 User and Server Modeling: ① Construct a user attribute model and define user sets. , , For users Priority For access methods, For the service chain, ① Define the user session duration for cloud access; ② Construct a cloud server attribute model and define a set of cloud servers. , , This refers to the total amount of CPU and memory resources. ③Construct a network parameter model, defining the network bandwidth and one-way latency sets for user-cloud server and cloud server-cloud server connections; Step S2, Load Awareness and Trigger Determination: ① Calculate the total load and load change of the microservice; ② Calculate the load intensity, which is the ratio of the load of the microservice on the cloud server to the total service rate of the container cluster; ③ Determine the triggering conditions, which are divided into expansion trigger and reduction trigger. Expansion trigger is when the load intensity is greater than the high load threshold or the load increment is greater than the growth threshold. Reduction trigger is when the load intensity is less than the low load threshold or the load reduction is greater than the decrease threshold. If the triggering conditions are met, enter the debouncing verification. If the conditions are continuously met within the debouncing window or the cumulative change exceeds the threshold, proceed to the next step. Step S3, MDP Differentiated Capacity Adjustment: ① Build an MDP state space for each microservice. , Given the current load intensity, This refers to the previous adjustment action. ② Develop a load change trend; Container scaling-up and scaling-down strategies prioritize adjusting single container resources, and adjust the number of instances once resources reach the upper / lower limit; ③ Formulate The container scaling-up and scaling-down strategy prioritizes adjusting the number of instances, and adjusts the resources of a single container after the number of instances reaches the upper / lower limit; ④ Calculates the adjustment correction coefficient to ensure that the adjustment amount adapts to the load trend, and finally outputs the adjustment result; Step S4, Key Indicator Calculation: ① Constructing a Response Time Model Distinguish cloud access user response time and local access user response time ② Construct a total system cost model For various cloud servers as well as The sum of resource consumption costs; ③ Construct a fairness indicator model, using the weighted Jain index. To quantify the fairness of weighted response times for users with different priorities; Step S5, Multi-objective solution and verification: ① Construct the objective function , For balance coefficient, The process involves several steps: ① Maximizing the allowable cost; ② Setting constraints, including response time constraints, cloud server resource constraints, and system stability constraints; ③ Employing a fusion MDP solution algorithm. First, an initial solution is constructed, parameters are initialized, the number of instances is calculated based on the initial load and basic resources, resource configuration is set according to the task memory-CPU ratio, and the initial MDP state is set to stable load and no historical actions. Then, routing initialization is performed, routing tasks to the cloud server with the most remaining resources to ensure service chain deployment on the same node; Next, a greedy optimization driven by MDP is performed, collecting load intensity and changes at a fixed sampling period to update the MDP state, adjusting the instance count step size based on the MDP state, and simultaneously verifying cloud server resource constraints. After the instance count reaches the upper / lower limit, the resource step size is adjusted according to the MDP state. Finally, route collaborative optimization is performed, adjusting routes when cross-cloud server transmission latency exceeds a threshold, and simultaneously updating the MDP state and container adjustment amount; ④ Verifying the optimal solution, iteratively optimizing until the objective function value difference is less than a preset threshold for two consecutive times, and the MDP state remains stable for multiple consecutive periods, outputting the optimal number of container instances, single container resource configuration, and the optimal MDP state sequence.

2. The method for dynamic container capacity planning of an integrated edge-cloud cluster oriented to dynamically change simulation task load, as described in claim 1, is characterized in that: The construction in step S1.1 In the session state resource model, single-session resources in the user's read-only state are the basic resources. , CPU resources used This refers to the memory resources used; single-session resources in the user-modified state are copied resources. with incremental resources The sum of the resources, copied resources , The base resource ratio for replication, incremental resources Additional resources incurred for modifying the model.

3. The method for dynamic container capacity planning of an integrated edge-cloud cluster oriented to dynamically change simulation task load, as described in claim 1, is characterized in that: The construction in step S1.1 When deploying a node, a single-node deployment satisfies the requirement that the total number of sessions is less than or equal to the session threshold, and the total resources are the sum of read-only and modification session resources. A multi-node deployment satisfies the requirement that the total number of sessions is greater than the session threshold, and the number of extended nodes is the ratio of the number of sessions to the threshold rounded up. The total resources include the basic resources of each node, modification session resources, and cross-node synchronization overhead. Cross-node synchronization overhead is the additional resource overhead of cross-node data synchronization.

4. The method for dynamic container capacity planning of an integrated edge-cloud cluster oriented to dynamically change simulation task load, as described in claim 1, is characterized in that: The construction in step S1.1 When modeling resource requirements, for users The model, The total computational cost of the compilation task is , The total computational cost of solving the task is CPU resources are allocated as ,Pick , For task coefficients, User priority weight.

5. The method for dynamic container capacity planning of an integrated edge-cloud cluster oriented to dynamically change simulation task load, as described in claim 1, is characterized in that: When defining the container core parameters in step S1.2, the startup delay meets the following requirements. , Session state needs to be loaded. Only load the runtime environment.

6. The method for dynamic container capacity planning of an integrated edge-cloud cluster oriented to dynamically change simulation task load, as described in claim 1, is characterized in that: In step S1.3, when constructing the network parameter model, the user-cloud server network bandwidth set... User-cloud server network one-way latency set Cloud server - Cloud server network bandwidth collection Cloud server - Cloud server network one-way latency set , For users With cloud servers Network bandwidth between For users With cloud servers Communication delay between them cloud server With another cloud server Network bandwidth between cloud server With another cloud server Communication delay between them.

7. The method for dynamic container capacity planning of an integrated edge-cloud cluster oriented to dynamically change simulation task load, as described in claim 1, is characterized in that: In step S3, the following is defined When implementing container scaling up and down strategies, the resources of a single container are adjusted according to a dynamic step size. The dynamic step size rule is: the initial step size is set according to the base value. The step size for continuous expansion is the sum of the previous step size and the expansion coefficient. The product of these numbers does not exceed the maximum value. The step size in the continuous reduction state is the sum of the previous step size and the reduction factor. The product of and is not less than the minimum value; the fluctuation state recovers to the initial step size, and the formula is determined. When implementing container scaling up and down strategies, the number of instances is adjusted according to a dynamic step size. The dynamic step size rules are as follows: the initial step size is set according to the base value, the step size increases during continuous scaling up, decreases during continuous scaling down, and returns to the initial step size during fluctuating states. The number of instances can be increased to the maximum value.

8. The method for dynamic container capacity planning of an integrated edge-cloud cluster oriented to dynamically change simulation task load, as described in claim 1, is characterized in that: In step S4, a response time model is constructed. At that time, cloud access user response time Including waiting time, Interaction delay, Execution time and inter-service transmission latency; local access user response time Including waiting time, model upload time, Execution time and inter-service transmission latency are calculated based on bandwidth and latency for cross-cloud server transmission latency, while transmission latency within the same cloud server is ignored.

9. The method for dynamic container capacity planning of an integrated edge-cloud cluster oriented to dynamically change simulation task load, as described in claim 1, is characterized in that: The weighted Jain index in step S4 Represented as: In the formula, Total number of users For users Weighted response time The weight corresponding to the user's priority.

10. The method for dynamic container capacity planning of an integrated edge-cloud cluster oriented to dynamically change simulation task load, as described in claim 1, is characterized in that: When setting constraints in step S5: Response time constraints are satisfied: In the formula, Indicates user priority. The user set, Indicates user priority. users , Indicates priority as The response time for the user. Priority is The maximum response time allowed by the user; Cloud server resource constraints are met: System stability constraints are satisfied: Each container cluster The load strength is less than 1.

Images