CN117076106A - Elastic telescoping method and system for cloud server resource management - Google Patents

Abstract

The application relates to the field of cloud computing resource scheduling, in particular to an elastic expansion method and system for cloud server resource management. The method comprises the following steps: according to the elastic expansion method and the system for cloud server resource management, the load pressure line is generated in a random gradient descending and shifting mode, the load state of the load data is judged based on the load pressure line, and an applicable elastic expansion method is selected according to the judging result.

Description

An elastic scaling method and system for cloud server resource management

Technical field

The present invention relates to the field of cloud computing resource scheduling, and specifically to an elastic scaling method and system for cloud server resource management.

Background technique

With the development and popularization of cloud native technology, the elastic scaling strategy of cloud servers has become one of the important indicators to test the load capacity of cloud servers. A good elastic scaling strategy should take into account resource conservation and service performance, that is, ensuring the user experience of cloud server users while using the least resources. And the system is also highly robust under highly variable loads. For now, the mainstream cloud server elastic scaling strategies mainly include passive elastic scaling strategies and active elastic scaling strategies.

Passive elastic scaling strategy: For online cloud server applications that do not have obvious periodic changes, it is usually difficult to predict the load in the next period a priori. The passive elastic scaling strategy mainly collects the load data of microservices in the latest period and sets appropriate target thresholds. Once certain indicators are found to exceed the set thresholds, the expansion and contraction operations are immediately triggered to maintain a stable state of resource utilization. Currently, most cloud data centers use passive elastic scaling strategies, such as using Kubernetes (a container orchestration engine open sourced by Google) developed by Google to automatically expand microservices.

Active elastic scaling strategy: For online applications of cloud servers with obvious cyclical changes, by collecting historical load data, mathematical modeling and portraits of the load are used to predict the load at the next moment and analyze the demand for resources, and allocate or recycle the corresponding resources in a timely manner. resources, it can well solve the delay problem of expansion and contraction. Existing active elastic scaling strategies are divided into prediction models based on machine learning, prediction models based on deep learning, and prediction models based on reinforcement learning, such as Light-GBM, DNN, Q-learning, etc.

Adopting a passive elastic scaling strategy will result in generally low resource utilization and serious redundancy. For example, Kubernetes, which is favored by domestic and foreign cloud service vendors, has a too simple horizontal scaling design and can only calculate the required number of replicas based on a comparison between the real-time perceived load value and the predefined resource water level threshold. This method lacks a risk control mechanism and is not suitable for industrial production. The passive elastic scaling strategy can only respond in real time and cannot predict the service resource demand in the future. Therefore, the workload of the cloud server often changes earlier than its elastic scaling adjustment. Even vertical scaling with fast response time will inevitably have certain problems. Delay, and this delay will lead to reduced service quality, increased SLA default rate and other problems.

Using a proactive elastic scaling strategy for automatic expansion and contraction will inevitably lead to the problem of prediction errors. If the prediction is too low, it will lead to insufficient expansion, which will lead to reduced service quality, increased user SLA violation rate, etc., and based on predictive elasticity The response speed of the scaling strategy when facing burst traffic is not as fast as the passive elastic scaling strategy. And in the early stages of policy execution, it is difficult to manage resources efficiently due to the lack of a large amount of historical load data for mathematical analysis.

Therefore, the existing technology still has shortcomings and needs further improvement.

Contents of the invention

Embodiments of the present invention provide an elastic scaling method and system for cloud server resource management to at least solve the technical problem that adopting a passive elastic scaling strategy will lead to low resource utilization or using an active elastic scaling strategy will cause prediction errors.

According to an embodiment of the present invention, an elastic scaling method for cloud server resource management is provided, including the following steps:

Collect historical workload data;

The load pressure line is generated through stochastic gradient descent and offset, and the load state of the load data is determined based on the load pressure line. The load state includes stable state and unstable state;

Select an elastic scaling strategy for resource allocation based on the current load status. The elastic scaling strategy includes a vertical scaling strategy and a horizontal scaling strategy;

Based on the allocated resources, specific horizontal scaling strategies or vertical scaling strategies are implemented through the cloud server to achieve resource allocation management.

Furthermore, the load pressure line is generated through stochastic gradient descent and offset, and the load state of the load data is determined based on the load pressure line. The load state includes the stable state and the unstable state before including:

Perform data preprocessing on load data. Data preprocessing includes deleting abnormal data and calculating the average value of each parameter with the same timestamp;

Supervised learning transformation is performed on the load data. Supervised learning transformation uses time windows to transform the load data into labeled supervised learning sequences.

Further, an elastic scaling strategy is selected for resource allocation according to the current load status. The elastic scaling strategy includes a vertical scaling strategy and a horizontal scaling strategy including:

Use item-by-item differential vertical scaling strategy for resource allocation;

The specific resource allocation formula of the vertical scaling strategy using item-by-item differentiation is:

Among them, C _N is the resource allocation amount, and the five coefficients α, β, γ, δ, and ε are respectively the five resource usage data C _L1 , C _L2 , C _L3 , C _L4 , and C _L5 collected in the previous time window. The difference coefficient, ρ, represents the margin of resource allocation in vertical scaling;

The above five differential coefficients satisfy the relationship:

α+4λ＝β+3λ＝γ+2λ＝δ+λ＝ε

Among them, λ is the difference number set by cloud server managers according to needs. Setting λ to 0 is the resource allocation formula of Kubernetes. λ is not a negative number.

Further, an elastic scaling strategy is selected for resource allocation according to the current load status. The elastic scaling strategy includes a vertical scaling strategy and a horizontal scaling strategy including:

Adopt a vertical scaling strategy based on load data prediction;

The specific vertical scaling strategy based on load data prediction is as follows:

By collecting historical workload load data, mathematical modeling and portraiture of load data are performed;

Based on mathematical modeling and profiling, predict the load data at the next moment;

Based on the load data analysis of resource requirements at the next moment, the corresponding resources can be allocated or recycled in a timely manner.

Furthermore, based on mathematical modeling and profiling, the load data predicted at the next moment is specifically:

The distributed gradient boosting framework LightGBM based on the decision tree algorithm is used to predict the load data at the next moment.

Further, an elastic scaling strategy is selected for resource allocation according to the current load status. The elastic scaling strategy includes a vertical scaling strategy and a horizontal scaling strategy including:

Use horizontal scaling strategy to coordinate vertical scaling for fine-grained load data management;

The horizontal scaling strategy is used to coordinate vertical scaling for fine-grained load data management. The details are as follows:

Adopt a pre-configured horizontal scaling strategy and combine it with vertical scaling for fine-grained resource management. After pre-configuring in the horizontal direction, resources are allocated at a preset decline rate in the vertical direction, taking into account the flexibility of resource adjustment and cost savings;

Resource allocation is based on the exponential backoff method. The exponential backoff method is as follows:

In the formula, C _N is the amount of resource allocation, C _A is the total amount of resource allocation after horizontal expansion, φ is the base number in the exponential backoff algorithm, n is the number of rounds that need to be rolled back, and t is a different time.

Furthermore, based on mathematical modeling and profiling, predicting load data at the next moment includes:

Load data prediction is performed through the gradient boosting framework method, and according to the prediction results, a vertical scaling strategy or a horizontal scaling strategy is selected for resource allocation.

An elastic scaling system for cloud server resource management, including:

Data collection module, used to collect load data of historical work;

The load state determination module is used to generate a load pressure line through random gradient descent and offset, and determine the load state of the load data based on the load pressure line. The load state includes a stable state and an unstable state;

The policy selection module is used to select an elastic scaling strategy for resource allocation based on the current load status. The elastic scaling strategy includes a vertical scaling strategy and a horizontal scaling strategy;

The resource scheduler is used to implement specific horizontal scaling strategies or vertical scaling strategies for cloud servers based on allocated resources to implement resource allocation management.

A computer-readable medium. The computer-readable storage medium stores one or more programs. The one or more programs can be executed by one or more processors to achieve elastic scaling of cloud server resource management as described above. steps in the method.

A terminal device includes: a processor, a memory and a communication bus; the memory stores a computer-readable program that can be executed by the processor;

The communication bus realizes the connection and communication between the processor and the memory;

When the processor executes a computer-readable program, the steps in the elastic scaling method for cloud server resource management as described above are implemented.

The elastic scaling method and system for cloud server resource management in the embodiment of the present invention generates a load pressure line through random gradient descent and offset, determines the load state of the load data based on the load pressure line, and selects a method based on the judgment result. An applicable elastic scaling method. Compared with the traditional microservice elastic scaling strategy, this method solves the problems of low prediction accuracy and weak applicability of the active elastic scaling strategy, and can guarantee QoS (Quality of Service). ) without loss while improving resource utilization.

Description of the drawings

The drawings described here are used to provide a further understanding of the present invention and constitute a part of this application. The illustrative embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention. In the attached picture:

Figure 1 is a flow chart of the elastic scaling method of cloud server resource management according to the present invention;

Figure 2 is a flow chart of a specific embodiment of the elastic scaling method for cloud server resource management of the present invention;

Figure 3 is the key part of the code of this application of the present invention;

Figure 4 is the first experimental result of the present invention randomly intercepting a piece of data and testing it in the Kubernetes cluster;

Figure 5 shows the second experimental result of the present invention randomly intercepting a piece of data and testing it in the Kubernetes cluster;

Figure 6 shows the third experimental result of the present invention randomly intercepting a piece of data and testing it in the Kubernetes cluster;

Figure 7 shows the fourth experimental result of the present invention randomly intercepting a piece of data and testing it in the Kubernetes cluster;

Figure 8 shows the response time of each method on the left side of the present invention;

Figure 9 shows the resource utilization rates of various methods of the present invention;

Figure 10 shows that the present invention uses a dynamic time adjustment algorithm to perform quantitative performance scoring;

Figure 11 is a schematic diagram of the elastic scaling system for cloud server resource management invented by the invention;

Figure 12 is a diagram of a specific embodiment of the elastic scaling system for cloud server resource management of the invention;

Figure 13 is a diagram of the terminal equipment of the invention.

Detailed ways

In order to enable those skilled in the art to better understand the solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only These are some embodiments of the present invention, rather than all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts should fall within the scope of protection of the present invention.

It should be noted that the terms "first", "second", etc. in the description and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It is to be understood that the data so used are interchangeable under appropriate circumstances so that the embodiments of the invention described herein are capable of being practiced in sequences other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, e.g., a process, method, system, product, or apparatus that encompasses a series of steps or units and need not be limited to those explicitly listed. Those steps or elements may instead include other steps or elements not expressly listed or inherent to the process, method, product or apparatus.

Example 1

According to an embodiment of the present invention, an elastic scaling method for cloud server resource management is provided. Referring to Figure 1, it includes the following steps:

S100: Collect historical work load data;

S200: Generate a load pressure line through stochastic gradient descent and offset, and determine the load state of the load data based on the load pressure line. The load state includes a stable state and an unstable state;

S300: Select an elastic scaling strategy for resource allocation based on the current load status. The elastic scaling strategy includes a vertical scaling strategy and a horizontal scaling strategy;

S400: Based on the allocated resources, the cloud server executes specific horizontal scaling strategies or vertical scaling strategies to realize resource allocation management.

The elastic scaling method of cloud server resource management in the embodiment of the present invention generates a load pressure line through random gradient descent and offset, determines the load state of the load data based on the load pressure line, and selects an appropriate method based on the judgment result. Compared with the traditional microservice elastic scaling strategy, this method solves the problems of low prediction accuracy and weak applicability of the active elastic scaling strategy, and can guarantee QoS (Quality of Service, Quality of Service) Improve resource utilization without loss.

Specifically, this application proposes an efficient and intelligent elastic scaling strategy for real-time adjustment of microservice resources based on machine learning algorithms. It mainly adopts the state detection method to analyze and judge different microservices, and executes different actions based on the analysis results. Auto-scaling strategy. The purpose of this application is to use this intelligent microservice elastic scaling strategy to solve the problem of resource management in cloud servers.

Specifically, the load state of the load data is determined according to the load pressure line. The pressure line in this embodiment can realize load adaptation based on parameter adjustment, which is a method of expressing the pressure line function provided in this embodiment:

The pressure line is a linear function. The general function formula of the pressure line in this embodiment is:

f(t)＝kt+b+αc _v

In the formula, k is the slope of the pressure line, t is the time independent variable, b is the pressure line constant term, c _v is the dispersion coefficient, which is the ratio of the standard deviation σ of the data to its corresponding mean μ, which represents the degree of dispersion within the sample interval. , which is also the margin reserved for the pressure line. The greater the degree of dispersion, the larger the allocated buffer space. On the contrary, the smaller the buffer space. α is the adjustment parameter of pressure line margin.

The determination of the pressure line slope and constant term can be performed using polynomial fitting. First, a set of fitting data is given:

(t _i ,Load _i ), where: i=0,1,2,....,m-1

Making a fitting function b+kt is transformed into a minimum problem of mean square error. If there can be a set of fitting coefficients that minimize ∈, then this set of fitting coefficients can be considered optimal. The calculation formula of mean square error is as follows:

Then, the following two partial derivatives can be obtained for ∈ respectively, and each partial derivative is set to 0, and the system of simultaneous equations can be solved for k and b. The system of simultaneous equations is:

In addition, what also needs to be determined is the value of the pressure line adjustment parameter. The problem is defined below:

Assuming that the load status judger is not used for judgment, there will be Π moments when the load is underestimated, causing performance degradation. The goal is to find Π moments when the load is underestimated. If the load status judger is used for judgment, there are P moments when the load is unstable, which is the potential load underestimation point. The ideal situation is that Π moments correspond to P moments one-to-one. Assuming that there are M points in P moments corresponding to M points in Π, then the judgment accuracy of the load status judger is Load underestimation point finding rate/> The judgment accuracy represents the accuracy of the load status judger. If the judgment accuracy is low, the system will judge many unnecessary load points as potential underestimate points, resulting in unnecessary waste of resources. The discovery rate represents the probability of finding the true load underestimation point. If the discovery rate is too low, the system cannot find most of the load underestimation points, resulting in reduced performance. The goal of the load status judger is to simultaneously ensure the load underestimation point finding rate/> and judgment accuracy/> In a high state.

The choice of parameters can have a large impact on the results, so appropriate parameters need to be determined. Based on a large number of experiments, it has been shown that the finding rate and the accuracy rate have almost opposite trends. In this state, it is difficult to find a state where both are at a high level at the same time, and corresponding trade-offs should be made. The smaller the parameter, the higher the accuracy and the lower the finding rate. This situation is suitable for a radical resource allocation system that gives up some performance in order to achieve higher resource utilization. The larger the parameter, the lower the accuracy and the higher the finding rate. This situation is suitable for a conservative resource allocation system, which increases the use of many resources in order to achieve higher performance. The above two situations are extreme. It is best to take the parameter α to the middle value (20<α<40). This value range takes into account the impact on performance and the use of resources, especially when the finding rate and the judgment accuracy are equal. , achieving a balance between performance impact and resource usage.

Step S100 specifically includes:

For historical workload information, Kubernetes' built-in resource usage collector Metrics Server is used to collect historical workload data. Metrics Server is a Kubernetes cluster monitoring and performance analysis tool that can collect metric data on nodes.

Specific steps before step S200 also include:

S201: Perform data preprocessing on the load data. Data preprocessing includes deleting abnormal data and calculating the average value of each parameter with the same timestamp;

S202: Perform supervised learning conversion on the load data. The supervised learning conversion uses a time window to convert the load data into a labeled supervised learning sequence.

By removing outliers and then supervised learning transformation, time windows are used to transform the data into labeled supervised learning sequences to improve prediction accuracy.

The vertical scaling strategy has the advantage of fast response time. For sudden load increases, vertical scaling can be used to respond promptly to reduce the impact of service performance degradation. In addition, using vertical scaling allows for more fine-grained resource management of cloud servers. Vertical scaling strategies include item-by-item differential vertical scaling strategies and load prediction-based vertical scaling strategies.

If the microservice load is relatively stable, a more radical resource management method can be used to save resources, such as the machine learning method LightGBM (Light Gradient Boosting Machine) based on load prediction. On the contrary, if the microservice load is relatively unstable, a more conservative resource management method will be adopted to ensure that SLA (Service-Level Agreement, Service Level Agreement) rules are not violated, such as the responsive elastic scaling strategy using the item-by-item differential method.

The above all apply to vertical scaling. If resources in the vertical direction are unable to support the current load (exceeding a certain threshold), the horizontal scaling strategy will be triggered to maintain resource utilization within a certain range. In order to avoid jitter, a cooling time is also set to prevent frequent horizontal expansion and contraction from affecting service performance. Horizontal expansion has a large amplitude. Usually, after running for a period of time, the service turns to smooth operation, or the peak value passes, resulting in excess resources. Therefore, after horizontal expansion, vertical resource rollback fine-tuning is performed, using the proposed exponential rollback method. Slowly reduce the vertical resource quota and recycle unused resources.

Step S300 specifically includes:

Resource allocation is performed using item-by-item differential vertical scaling strategy.

Vertical scaling strategy using item-by-item differentiation: It is aimed at cloud server online applications that do not have obvious periodic changes. It is usually difficult to predict the load in the next period a priori. The passive elastic scaling strategy mainly collects the load data of microservices in the latest period. , set appropriate target thresholds, and once it is found that some indicators exceed the set thresholds, the expansion and contraction operations will be triggered immediately to maintain a stable state of resource utilization.

Existing cloud data centers use popular tools and frameworks, such as Kubernetes developed by Google to automatically scale microservices. Kubernetes monitors the historical resource usage C _L in the past time window and then allocates resources in the next time window. C _N is set to:

C _N =C _L (1+ρ)

Among them, ρ is the security factor that the cloud server administrator can flexibly set according to needs.

Obviously, the scaling strategy design of Kubernetes is too simple. It can only calculate the required resources based on the comparison between the real-time perceived load value and the predefined resource water level threshold, resulting in generally low resource utilization and serious redundancy. This method lacks The risk management and control mechanism does not apply to industrial production.

In this application, the resource allocation formula of the item-by-item differential vertical scaling strategy can be used to alleviate the impact of insufficient and over-supply of resources to a certain extent. For example, if the sliding time window is set to five, then the resource allocation formula is:

Among them, C _N is the resource allocation amount, and the five coefficients α, β, γ, δ, and ε are respectively the five resource usage data C _L1 , C _L2 , C _L3 , C _L4 , and C _L5 collected in the previous time window. Differential coefficient. The above five differential coefficients satisfy the relationship:

α+4λ＝β+3λ＝γ+2λ＝δ+λ＝ε

Among them, λ is the difference number set by the cloud server manager according to the needs. Setting λ to 0 is the resource allocation formula of Kubernetes. λ should not be set too large. If λ is set too large, the resource allocation amount will be excessively related to C _L5 . λ should not be set to a negative number, otherwise the resource allocation will be strongly correlated with C _L1 .

Step S300 specifically includes:

Adopt a vertical scaling strategy based on load data prediction;

The specific vertical scaling strategy based on load data prediction is as follows:

S301: By collecting historical work load data, perform mathematical modeling and portrait of the load data;

S302: Based on mathematical modeling and portraits, predict the load data at the next moment;

S3021: Predict load data through the gradient boosting framework method, and select a vertical scaling strategy or a horizontal scaling strategy for resource allocation based on the prediction results;

S303: Analyze resource requirements based on the load data at the next moment, and allocate or recycle corresponding resources in a timely manner.

Adopting a vertical scaling strategy based on load prediction: It is aimed at online applications of cloud servers with obvious cyclic changes in load. By collecting historical load data, mathematical modeling and portraits of the load are performed to predict the load at the next moment and analyze resource requirements. By allocating or recycling corresponding resources in a timely manner, it can well solve the delay problem of expansion and contraction. This application will use the distributed gradient boosting framework LightGBM (Light Gradient Boosting Machine, lightweight gradient boosting machine learning) based on the decision tree algorithm for load prediction analysis. LightGBM is an open source framework for gradient boosting. It is one of the frameworks that implements the GBDT algorithm and supports efficient parallel training.

GBDT (Gradient Descent Tree) is a model in machine learning. Its main idea is to use weak classifiers (decision trees) to iteratively train to obtain the optimal model. This model has the advantages of good training effect and not easy to overfit. However, GBDT needs to traverse the entire training data multiple times in each iteration. If the entire training data is loaded into the memory, the size of the training data will be limited; if it is not loaded into the memory, repeatedly reading and writing the training data will consume a lot of time. Especially in the face of industrial-level massive data, the ordinary GBDT algorithm cannot meet its needs.

The existing GBDT tool XGBoost (an optimized distributed gradient boosting library) is a decision tree algorithm based on the pre-sorting method. The disadvantages of this algorithm for building decision trees are obvious: first, it consumes a lot of space; second, it also consumes a lot of time. Large consumption; finally, it is not friendly to cache (cache memory) optimization. In order to avoid the above-mentioned defects of XGBoost and speed up the training of GBDT model without compromising accuracy, LightGBM has made the following optimizations on the traditional GBDT algorithm: unilateral gradient sampling, mutually exclusive feature bundling, and depth limitation. Leaf growth strategy, direct support for category features, support for efficient parallelism, and Cache hit rate optimization. After optimization, LightGBM can perform model training with very little time overhead and achieve high prediction accuracy, allowing GBDT to be used in cloud load prediction practice better and faster.

After this application uses LightGBM for load prediction, resources can be configured in advance according to the load, and the LightGBM model is regularly maintained and updated.

Step S300 specifically includes:

Horizontal scaling strategy is used to coordinate vertical scaling for fine-grained load data management.

Specifically, the horizontal scaling strategy is simple and effective, so it is widely used in production. However, the technical level of the horizontal scaling system still has some shortcomings in the design. First of all, horizontal scaling technology increases or decreases the number of service replicas to achieve the target resource utilization state in the future. When load bursts and fluctuations occur, it will lead to inefficiency, which may lead to over-provisioning or under-provisioning. ; Secondly, the execution of horizontal scaling takes a certain amount of time, so some cloud computing resource management systems need to find ways to perform horizontal scaling operations before load bursts, which is extremely difficult. On the one hand, if you make a wrong judgment and perform horizontal expansion in advance, it will lead to low resource utilization and poor economic benefits; on the other hand, if you do not perform horizontal expansion in time, it will lead to service performance degradation or even service unavailability.

In order to solve the above problems, this application introduces the cooling period technology in the automatic scaling system. The automatic scaling operation will no longer be performed within a period of time after the latest operation, thereby reducing the adverse effects caused by system turbulence and jitter. Secondly, the horizontal scaling strategy in this application will cooperate with the vertical scaling strategy for fine-grained resource management, mainly using the preconfiguration method, and combined with the vertical scaling strategy for fine-grained resource management. After preconfiguration in the horizontal direction, the vertical scaling strategy will The reduction operation is performed at a certain or preset decline rate, taking into account the flexibility of resource adjustment and cost savings.

Resource allocation is based on the exponential backoff method. The exponential backoff method is as follows:

In the formula, C _N is the amount of resource allocation, C _A is the total amount of resource allocation after horizontal expansion, φ is the base number in the exponential backoff algorithm, n is the number of rounds that need to be rolled back, and t is a different time.

The technical solution of this application is specifically described as follows:

Referring to Figure 2, the main process of this patented method is:

Step 1. Collection of historical workload information or data: Use Kubernetes' built-in resource usage collector Metrics Server to collect data.

Step 2, data preprocessing: workload preprocessing, including deleting abnormal data, calculating the average value of each parameter with the same timestamp, etc.

Step three, supervised learning conversion: improve prediction accuracy by using time windows to convert data into labeled supervised learning sequences.

Step 4: Load data status determination: Generate load pressure lines through stochastic gradient descent and offset to determine whether the load data is in a stable state.

Step 5: Policy selector: Select an appropriate elastic scaling strategy based on the current status of the load, including vertical scaling strategies and horizontal scaling strategies. The main idea is shown in Figure 3 for the policy selector pseudocode.

Load prediction: Load prediction is performed through the machine learning method LightGBM, and resources are allocated based on the prediction results.

Step 6: Responsive scaling: Allocate resources through item-by-item differential vertical scaling strategy resource allocation to improve the performance of the responsive scaling strategy.

Step seven, optimizer: implement specific horizontal scaling strategies and vertical scaling strategies for the cloud server.

This application proposes a cloud server elastic scaling strategy based on machine learning and status detection, which can effectively solve the resource management problem of microservices in cloud server clusters and improve resource allocation utilization while ensuring no loss of QoS.

In order to achieve this goal, the method proposed in this application performs status detection on the load of the cloud server cluster, and then two different scheduling methods can be selected according to the detection results: active strategy and passive strategy, and two different scheduling methods are adopted: Horizontal expansion and vertical expansion.

In addition, this application proposes an item-by-item differential resource allocation method for responsive resource allocation, rationally utilizing the time tags of time series data, and assigning different weights to historical load data at different moments, so that the responsive elastic scaling strategy has a partial prediction effect. . In addition, this application proposes a horizontal scaling pre-configuration method, and cooperates with vertical scaling to shrink resources at a certain decay rate to achieve more fine-grained resource management.

Compared with the existing technology, this application adopts an elastic scaling strategy based on machine learning and microservice status detection. This algorithm uses the inherent characteristics of the microservice load sequence diagram to perform status detection to determine whether the load at the current moment is difficult to predict, and then Choose an appropriate elastic scaling method based on the judgment results. It is a good integration of active and passive elastic scaling strategies. Compared with traditional microservice elastic scaling strategies, this method solves most of the problems of low prediction accuracy and weak applicability of active elastic scaling strategies. It also solves The passive elastic scaling strategy has the disadvantage that it can only respond in real time and cannot predict cluster resource needs in the future. To a certain extent, it can ensure that QoS is not lost while improving resource utilization.

This application experiment uses workload data sets from Alibaba Cloud Data Center. A load generator based on Locust (an open source load testing tool) and a cloud server cluster scheduler based on a machine learning model were used, and several different scheduling algorithms commonly used in the current scheduling field were compared.

The predictive elastic scaling strategy is difficult to predict accurately when the load changes highly. A large buffer setting will lead to a waste of resources, and a small buffer setting will lead to frequent violations of SLA (Service-Level Agreement, Service Level Agreement) rules. The load pressure line generated by stochastic gradient descent can determine whether the current load is difficult to predict based on load characteristics, and change the elastic scaling strategy in advance before the load underestimate point arrives. After testing, the load underestimate point hit accuracy can reach up to 71.03%.

Figures 4 to 7 show a random section of data intercepted from the Alibaba data set and tested in the Kubernetes cluster. Under the same load, four different methods were executed to compare the resource values allocated by the system to the microservices and the number of data processed per second. The load value is used to analyze the degree of fitting of the load by four different methods. Figure 7 is the experimental result chart of the method of this application. It compares the vertical scaling performance of this method with Hyscale, Showar, and XGboost. The experimental results are shown in Figures 4 to Figure 7.

Figure 8 shows the response time of each method. Under the same load condition, when four different methods are executed, the maximum response time and the average response time are compared. The average response time of the method of this application is 18.5% less than Hyscale, 21.42% less than Showar, and 21.42% less than Showar. XGboost is 15.38% less.

Figure 9 shows the resource utilization of each method. Under the same load condition, the CPU utilization is compared when executing four different methods. Compared with the responsive strategy, the method of this application has a slight improvement, but due to the unstable state of the load, a conservative approach is adopted. With the resource allocation strategy, the resource utilization rate has declined compared with the proactive strategy.

Figure 10 shows a quantitative comparison of the fitting degree of the load using the DTW algorithm based on Figures 4 to 7. In Figure 10, a dynamic time adjustment algorithm is used for quantitative performance scoring (the lower the score, the better the method). The performance evaluation is performed by quantifying the similarity of the curves to visualize the performance difference. The points on the two curves do not correspond one to one. , there is a certain offset, and the number of points is usually not the same, so the usual Euclidean distance method does not work, and the dynamic time adjustment algorithm (DTW algorithm) is more applicable and has better results. The dynamic time adjustment algorithm (DTW) is usually used to detect the similarity between two voices. Since the pronunciation of each letter is different each time you speak, the two voices will not completely match. The dynamic time adjustment algorithm will affect the speech. Stretch or compress them so that they are as aligned as possible. The scoring results are: 41.6 points for this application method, 84.0 points for Hyscale, 70.3 points for Showar, and 55.3 points for XGboost. The above results prove that this patent is superior to existing methods in the field of cloud server elastic scaling.

Example 2

According to another embodiment of the present invention, an elastic scaling system for cloud server resource management is provided. See Figure 11, which includes:

The data collection module 100 is used to collect historical work load data;

The load state determination module 200 is used to generate a load pressure line through random gradient descent and offset, and determine the load state of the load data based on the load pressure line. The load state includes a stable state and an unstable state;

The policy selection module 300 is used to select an elastic scaling strategy for resource allocation according to the current load status. The elastic scaling strategy includes a vertical scaling strategy and a horizontal scaling strategy;

The resource scheduler 400 is used to implement specific horizontal scaling strategies or vertical scaling strategies for the cloud server based on the allocated resources to implement resource allocation management.

Specifically, the design goal of this application is to provide an efficient and stable resource management system, and service providers can apply this model to rationally allocate resources. Figure 12 shows the main components of this application, and Figure 3 shows the key part of the code of this patent.

As shown in Figure 12, the system model of this patent includes the following components: load generator, workload analyzer, and cluster scheduler.

Load generator: The load generator uses real load data for simulation and can generate a series of HTTP access requests to test the effectiveness of the system. Specifically, some data are selected from the Alibaba load set, and after data preprocessing and conversion, stress testing is performed with the help of Locust.

Workload analyzer: The function of the workload analyzer is to analyze the load characteristics in order to adopt the optimal resource scheduling strategy. First, it digs out the characteristics of inaccurate prediction points on the load prediction map, and then judges the current situation through the load pressure line. The state of the load. The pressure line is calculated using regression and offset, and the relevant parameters can be dynamically adjusted and adaptive.

Cluster scheduler: The cluster scheduler is responsible for receiving resource scheduling instructions from the workload analyzer and acting on the cloud server cluster to make resource allocation more reasonable. There are two main scheduling strategies: vertical scaling and horizontal scaling.

The elastic scaling system of cloud server resource management in the embodiment of the present invention generates a load pressure line through random gradient descent and offset, determines the load state of the load data based on the load pressure line, and selects an appropriate method based on the judgment result. Compared with the traditional microservice elastic scaling strategy, this method solves the problems of low prediction accuracy and weak applicability of the active elastic scaling strategy, and can guarantee QoS (Quality of Service, Quality of Service) Improve resource utilization without loss.

Example 3

Based on the above elastic scaling method of cloud server resource management, this embodiment provides a computer-readable storage medium. The computer-readable storage medium stores one or more programs. The one or more programs can be processed by one or more processors. Execute the steps in the elastic scaling method for cloud server resource management as in the above embodiment.

Example 4

A terminal device, including: a processor, a memory and a communication bus; the memory stores a computer-readable program that can be executed by the processor; the communication bus realizes connection and communication between the processor and the memory; the processor executes the computer-readable program Implement the steps in the above-mentioned elastic scaling method of cloud server resource management.

Based on the above elastic scaling method of cloud server resource management, this application provides a terminal device, as shown in Figure 13, which includes at least one processor (processor) 20; a display screen 21; and a memory (memory) 22. It can also Including communications interface (Communications Interface) 23 and bus 24. Among them, the processor 20, the display screen 21, the memory 22 and the communication interface 23 can complete communication with each other through the bus 24. The display screen 21 is configured to display a user guidance interface preset in the initial setting mode. Communication interface 23 can transmit information. The processor 20 can call logical instructions in the memory 22 to execute the methods in the above embodiments.

In addition, the above-mentioned logical instructions in the memory 22 can be implemented in the form of software functional units and can be stored in a computer-readable storage medium when sold or used as an independent product.

As a computer-readable storage medium, the memory 22 can be configured to store software programs, computer-executable programs, such as program instructions or modules corresponding to the methods in the embodiments of the present disclosure. The processor 20 executes software programs, instructions or modules stored in the memory 22 to execute functional applications and data processing, that is, to implement the methods in the above embodiments.

The memory 22 may include a program storage area and a data storage area, where the program storage area may store an operating system and at least one application program required for a function; the storage data area may store data created according to the use of the terminal device, etc. In addition, the memory 22 may include high-speed random access memory, and may also include non-volatile memory. For example, there are many media that can store program code, such as U disk, mobile hard disk, read-only memory (ROM), random access memory (Random Access Memory, RAM), magnetic disk or optical disk, or they can also be temporary state storage media.

In addition, the specific process of loading and executing the multiple instruction processors in the above storage medium and terminal device has been described in detail in the above method, and will not be described one by one here.

The above are only preferred embodiments of the present invention. It should be noted that those skilled in the art can make several improvements and modifications without departing from the principles of the present invention. These improvements and modifications can also be made. should be regarded as the protection scope of the present invention.

Claims (10)

1. An elastic scaling method for cloud server resource management, which is characterized by including the following steps: Collect historical workload data; Generate a load pressure line through stochastic gradient descent and offset, and determine the load state of the load data based on the load pressure line. The load state includes a stable state and an unstable state; Select an elastic scaling strategy for resource allocation according to the current load status. The elastic scaling strategy includes a vertical scaling strategy and a horizontal scaling strategy; Based on the allocated resources, the cloud server executes the specific horizontal scaling strategy or vertical scaling strategy to realize resource allocation management. 2. The elastic scaling method according to claim 1, characterized in that the load pressure line is generated by random gradient descent and offset, and the load state of the load data is determined based on the load pressure line. The load state includes stable state and unstable state, and also includes: Perform data preprocessing on the load data. The data preprocessing includes deleting abnormal data and calculating the average value of each parameter with the same timestamp; Supervised learning conversion is performed on the load data, and the supervised learning conversion uses a time window to convert the load data into a labeled supervised learning sequence. 3. The elastic scaling method according to claim 1, characterized in that the elastic scaling strategy is selected according to the current load status for resource allocation, and the elastic scaling strategy includes a vertical scaling strategy and a horizontal scaling strategy including: Allocate resources using the vertical scaling strategy of item-by-item differential; The resource allocation formula of the vertical scaling strategy using item-by-item difference is specifically: Among them, C _N is the resource allocation amount, and the five coefficients α, β, γ, δ, and ε are respectively the five resource usage data C _L1 , C _L2 , C _L3 , C _L4 , and C _L5 collected in the previous time window. The difference coefficient, ρ, represents the margin of resource allocation in vertical scaling; The above five differential coefficients satisfy the relationship: α+4λ=β+3λ=γ+2λ=δ+λ=ε; Among them, λ is the difference number set by cloud server managers according to needs. Setting λ to 0 is the resource allocation formula of Kubernetes. λ is not a negative number. 4. The elastic scaling method according to claim 1, characterized in that the elastic scaling strategy is selected according to the current load status for resource allocation, and the elastic scaling strategy includes a vertical scaling strategy and a horizontal scaling strategy including: Adopt a vertical scaling strategy based on the load data prediction; The vertical scaling strategy based on the load data prediction is specifically: By collecting the load data of historical work, mathematically modeling and profiling the load data; Based on the mathematical modeling and portrait, predict the load data at the next moment; Based on the load data analysis resource demand at the next moment, the corresponding resources are allocated or recycled in a timely manner. 5. The elastic scaling method according to claim 4, characterized in that, based on the mathematical modeling and portrait, predicting the load data at the next moment is specifically: The distributed gradient boosting framework LightGBM based on the decision tree algorithm is used to predict the load data at the next moment. 6. The elastic scaling method according to claim 4, characterized in that the elastic scaling strategy is selected according to the current load status for resource allocation, and the elastic scaling strategy includes a vertical scaling strategy and a horizontal scaling strategy including: Use the horizontal scaling strategy to coordinate with the vertical scaling for fine-grained load data management; The specific steps of using the horizontal scaling strategy to coordinate with the vertical scaling for fine-grained load data management include: Adopt the preconfigured horizontal scaling strategy and combine it with the vertical scaling for fine-grained resource management. After preconfiguring in the horizontal direction, resources are allocated at a preset decline rate in the vertical direction, taking into account the flexibility and cost of resource adjustment. savings; The resource allocation is performed based on an exponential backoff method, which is as follows: In the formula, C _N is the amount of resource allocation, C _A is the total amount of resource allocation after horizontal expansion, φ is the base number in the exponential backoff algorithm, n is the number of rounds that need to be rolled back, and t is a different time. 7. The elastic scaling method according to claim 4, characterized in that, based on the mathematical modeling and portrait, predicting the load data at the next moment includes: Load data prediction is performed through the gradient boosting framework method, and the vertical scaling strategy or the horizontal scaling strategy is selected for resource allocation based on the prediction results. 8. An elastic scaling system for cloud server resource management, which is characterized by including: Data collection module, used to collect load data of historical work; A load state determination module is used to generate a load pressure line through random gradient descent and offset, and determine the load state of the load data based on the load pressure line. The load state includes a stable state and an unstable state; A policy selection module, configured to select an elastic scaling strategy for resource allocation according to the current load status, where the elastic scaling strategy includes a vertical scaling strategy and a horizontal scaling strategy; The resource scheduler is used to execute the specific horizontal scaling strategy or vertical scaling strategy on the cloud server based on the allocated resources to implement resource allocation management. 9. A computer-readable medium, characterized in that the computer-readable storage medium stores one or more programs, and the one or more programs can be executed by one or more processors to implement the claims Steps in the elastic scaling method described in any one of 1-7. 10. A terminal device, characterized in that it includes: a processor, a memory, and a communication bus; the memory stores a computer-readable program that can be executed by the processor; The communication bus implements connection communication between the processor and the memory; When the processor executes the computer-readable program, the steps in the elastic scaling method according to any one of claims 1-7 are implemented.