CN118764491A - A method for managing an instance and an instance management platform - Google Patents

Abstract

The embodiment of the present application provides a method for managing instances and an instance management platform, the method comprising: the instance management platform monitors the instances of running tasks in the scaling group to obtain monitoring indicator data such as resource utilization of the instances, and generates a historical task portrait based on the resource utilization; the instance management platform uses a first model to generate one or more scaling strategies based on the historical task portrait, and recommends the scaling strategy to the user, and after the user selects, the instance management platform adjusts the number of instances in the scaling group or the specifications of the instances based on the scaling strategy selected by the user. The method can use the model to automatically generate a reasonable scaling strategy based on the historical task portrait, thereby reducing the problems of cumbersome configuration and large errors caused by manually configuring the scaling strategy.

Description

A method for managing an instance and an instance management platform

Technical Field

The present application relates to the field of cloud services, and more specifically, to a method for managing instances and an instance management platform.

Background Art

The distributed task scheduling system based on cloud services mainly provides task segmentation and scheduling, as well as real-time and accurate scheduling of tasks, with functions such as scheduled tasks, one-time tasks, task scheduling, distributed execution of batch tasks, etc. In order to improve the service-oriented capabilities of the cloud service platform, the task scheduling system also needs to control the elastic scaling of cloud server (ElasticCompute Service, ECS) resources, that is, replenishing resources when they are busy and recycling them when they are idle, thereby further reducing resource costs.

When using a distributed task scheduling system, users need to develop an elastic scaling strategy that conforms to the task execution profile based on historical experience, that is, a strategy for deciding when to scale, how to scale, and which indicators to use for scaling. The configuration process of this strategy is cumbersome, and due to the high degree of manual intervention, errors are prone to occur.

Summary of the invention

The present application provides a method for managing instances and an instance management platform. The method can automatically generate a scaling strategy, solving the problem that scaling strategy configuration is complicated and manual intervention is high and prone to errors.

In a first aspect, a method for managing an instance is provided, the method comprising: an instance management platform monitors an instance of a task running in a scaling group to obtain a resource utilization rate of the instance, the resource utilization rate comprising one or more of the following: a CPU utilization rate and a memory utilization rate; the instance management platform generates a historical task profile based on the resource utilization rate, the historical task profile comprising one or more of the following: a historical task timing feature and a historical task resource feature, wherein the historical task timing feature is used to indicate a timing feature of a historical task when the scaling group is running, and the historical task resource feature is used to indicate a resource type of the scaling group, and the resource type comprises one or more of the following: computing intensive, memory intensive, input/output intensive (In Out Intensive, IO Intensive) type (or referred to as read/write intensive), and graphics intensive; the instance management platform generates one or more scaling policies according to the historical task profile using a first model, the input of the first model being the historical task profile, and the output of the first model being one or more scaling policies; the instance management platform recommends one or more scaling policies to a user; the instance management platform determines the scaling policy selected by the user; and the instance management platform adjusts the number of instances or the specifications of the instances in the scaling group according to the scaling policy selected by the user.

Based on the above technical solution, a large amount of high-quality data can be fully utilized, and the model can be used to automatically generate reasonable scaling strategies according to historical task portraits, thereby solving the problems of cumbersome scaling strategy configuration and large errors in manual intervention, and improving the scaling effect. In addition, formulating scaling strategies based on historical task portraits can reduce the problems of large data calculation volume, cumbersome parameter conversion, low accuracy, etc. caused by directly formulating scaling strategies based on monitoring-related data, making the generation of scaling strategies more efficient and reasonable.

In combination with the first aspect, in certain implementations of the first aspect, the scaling strategy includes one or more of the following: a scheduled scaling strategy and an alarm scaling strategy, and one or more scaling strategies are generated based on historical task portraits using the first model, including: using the first model to determine one or more of the following parameters of the scheduled scaling strategy based on the historical task portraits: scaling time, scheduled scaling semantics, and scheduled scaling scale; using the first model to determine one or more of the following parameters of the alarm scaling strategy based on the historical task portraits: alarm indicators, alarm thresholds, alarm scaling semantics, and alarm scaling scale.

Based on the above implementation, the relevant parameters determined by the required policy generation model are specifically refined, so that the subsequent scaling group can adjust the instance more accurately, thereby further improving the scaling effect.

In combination with the first aspect, in certain implementations of the first aspect, the method also includes: the instance management platform determines the remaining resource amount of the scaling group based on the number of instances and the specifications of the instances; the instance management platform decides to suspend the task and wait, or to schedule the task between scaling groups based on the resource type and the remaining resource amount of the scaling group.

Based on the above implementation, the task execution current limiting parameters can be dynamically adjusted according to the type and remaining resources in the scaling group, and the optimal scaling group can be selected to complete task delivery, thereby avoiding resource waste and improving the task execution efficiency of the scaling group.

In combination with the first aspect, in some implementations of the first aspect, the method further includes: the instance management platform presenting historical task timing characteristics and historical task resource characteristics to the user.

Based on this technical solution, when users formulate scaling strategies themselves, the historical task portrait can assist users in completing scaling strategy formulation, thereby helping to improve the scaling effect of the scaling strategy.

In combination with the first aspect, in certain implementations of the first aspect, generating a historical task portrait based on resource utilization includes: preprocessing the resource utilization to obtain processing data, the preprocessing including one or more of the following: normalization, vectorization; using a second model to generate a historical task portrait based on the processing data, the input of the second model is the processing data, and the output of the second model is the historical task portrait.

Based on this solution, the second model is used to extract historical task portraits based on data such as resource utilization. Compared with manual analysis and extraction of task portraits, historical task portraits can be extracted faster and more accurately; and the second model can extract historical task portraits based on pre-processed processing data, which is conducive to more efficient and accurate generation of historical task portraits.

In combination with the first aspect, in certain implementations of the first aspect, the historical task timing characteristics include one or more of the following: average running time of historical tasks, peak period of historical task volume, trough period of historical task volume, and historical task execution cycle.

In a second aspect, an instance management platform is provided, including: a monitoring module, which is used to monitor the instances of running tasks in a scaling group, and obtain the resource utilization of the instances, where the resource utilization includes one or more of the following: central processing unit CPU utilization and memory utilization; a policy generation module, which is used to generate a historical task portrait based on the resource utilization, where the historical task portrait includes one or more of the following: historical task timing characteristics and historical task resource characteristics, wherein the historical task timing characteristics are used to indicate the timing characteristics of the historical tasks when the scaling group is running, and the historical task resource characteristics are used to indicate the resource type of the scaling group, and the resource type includes one or more of the following: computing intensive, memory intensive, input and output intensive, and graphics intensive; the policy generation module is also used to generate one or more scaling policies according to the historical task portrait using a first model, where the input of the first model is the historical task portrait, and the output of the first model is one or more scaling policies; an execution module, which is used to recommend one or more scaling policies to a user; the execution module is also used to determine the scaling policy selected by the user; the execution module is also used to adjust the number of instances in the scaling group or the specifications of the instances according to the scaling policy selected by the user.

Based on the above technical solution, the strategy generation module can make full use of a large amount of high-quality data, use the model to automatically generate reasonable scaling strategies according to historical task portraits, and can enable scaling strategies by interacting with users, thereby solving the problems of cumbersome scaling strategy configuration and large errors in manual intervention, and can improve the scaling effect; in addition, scaling strategies are formulated based on historical task portraits to reduce the large amount of data calculation, cumbersome parameter conversion, low accuracy, and other problems caused by directly formulating scaling strategies based on monitored data, making the generation of scaling strategies more efficient and reasonable.

In combination with the second aspect, in some implementations of the second aspect, the scaling strategy includes one or more of the following: a scheduled scaling strategy and an alarm scaling strategy. The strategy generation module is specifically used to use the first model to determine one or more of the following parameters of the scheduled scaling strategy based on the historical task portrait: scaling time, scheduled scaling semantics, and scheduled scaling scale; and use the first model to determine one or more of the following parameters of the alarm scaling strategy based on the historical task portrait: alarm indicator, alarm threshold, alarm scaling semantics, and alarm scaling scale.

In combination with the second aspect, in certain implementations of the second aspect, the execution module is also used to: determine the remaining resources of the scaling group based on the number of instances and the specifications of the instances; decide to suspend the task and wait, or schedule the task between scaling groups based on the resource type and remaining resources of the scaling group.

In combination with the second aspect, in some implementations of the second aspect, the execution module is further used to: present historical task timing features and historical task resource features to the user.

In combination with the second aspect, in certain implementations of the second aspect, the strategy generation module is specifically used to: preprocess resource utilization to obtain processing data, the preprocessing including one or more of the following: normalization, vectorization; use the second model to generate a historical task portrait based on the processing data, the input of the second model is the processing data, and the output of the second model is the historical task portrait.

In combination with the second aspect, in certain implementations of the second aspect, the historical task timing characteristics include one or more of the following: average running time of historical tasks, peak period of historical task volume, trough period of historical task volume, and historical task execution cycle.

In a third aspect, a computing device is provided, comprising a processor and a memory, wherein the memory is used to store instructions, and the processor is used to call and execute the instructions from the memory, so that the computing device executes the method in the first aspect or any possible implementation of the first aspect.

In a fourth aspect, a computing device cluster is provided, comprising at least one computing device, each computing device comprising a processor and a memory, wherein the memory is used to store instructions, and the processor is used to call and execute the instructions from the memory, so that the computing device cluster executes the method in the first aspect or any possible implementation of the first aspect.

In conjunction with the fourth aspect, in certain implementations of the fourth aspect, the processor may be a general-purpose processor, which may be implemented by hardware or software. When implemented by hardware, the processor may be a logic circuit, an integrated circuit, etc.; when implemented by software, the processor may be a general-purpose processor, which is implemented by reading software code stored in a memory, and the memory may be integrated in the processor or may be located outside the processor and exist independently.

In a fifth aspect, a computer-readable storage medium is provided, comprising computer program instructions. When the computer program instructions are executed by a computing device cluster, the computing device cluster executes the method in the above-mentioned first aspect or any possible implementation manner of the first aspect.

In combination with the fifth aspect, in certain implementations of the fifth aspect, the above-mentioned storage medium may specifically be a non-volatile storage medium.

In a sixth aspect, a computer program product comprising instructions is provided. When the instructions are executed by a computing device cluster, the computing device cluster executes the method in the above-mentioned first aspect or any possible implementation manner of the first aspect.

In a seventh aspect, a chip is provided, which obtains instructions and executes the instructions to implement the method in the above-mentioned first aspect or any possible implementation manner of the first aspect.

In combination with the seventh aspect, in certain implementations of the seventh aspect, the chip includes a processor and a data interface, and the processor reads instructions stored in the memory through the data interface to execute the method in the above-mentioned first aspect or any possible implementation of the first aspect.

In combination with the seventh aspect, in certain implementations of the seventh aspect, the chip may also include a memory, in which instructions are stored, and the processor is used to execute the instructions stored in the memory. When the instructions are executed, the processor is used to execute the method in the above-mentioned first aspect or any possible implementation of the first aspect.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 is a schematic diagram of a cloud service system architecture provided in an embodiment of the present application.

FIG. 2 is a schematic flowchart of a method 200 for managing instances provided in an embodiment of the present application.

FIG3 is a schematic flowchart of a method 300 for generating a historical task portrait according to an embodiment of the present application.

FIG. 4 is a schematic diagram of a client interface provided in an embodiment of the present application.

FIG5 is a schematic structural block diagram of an instance management platform provided in an embodiment of the present application.

FIG6 is a schematic structural block diagram of a computing device provided in an embodiment of the present application.

FIG. 7 is a schematic structural block diagram of a computing device cluster provided in an embodiment of the present application.

FIG8 is a schematic structural block diagram of another computing device cluster provided in an embodiment of the present application.

DETAILED DESCRIPTION

The technical solution in this application will be described below in conjunction with the accompanying drawings.

The present application will present various aspects, embodiments or features around a system including multiple devices, components, modules, etc. It should be understood and appreciated that each system may include additional devices, components, modules, etc., and/or may not include all devices, components, modules, etc. discussed in conjunction with the figures. In addition, combinations of these schemes may also be used.

In addition, in the embodiments of the present application, words such as "exemplary" and "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described as "example" in the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of the word "example" is intended to present concepts in a concrete way.

The architecture and business scenarios described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. A person of ordinary skill in the art will appreciate that, with the evolution of the architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of the present application are equally applicable to similar technical problems.

References to "one embodiment" or "some embodiments" etc. described in this specification mean that a particular feature, structure or characteristic described in conjunction with the embodiment is included in one or more embodiments of the present application. Thus, the phrases "in one embodiment", "in some embodiments", "in some other embodiments", "in some other embodiments", etc. appearing in different places in this specification do not necessarily refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized in other ways. The terms "including", "comprising", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized in other ways.

In the present application, "at least one" means one or more, and "plurality" means two or more. "And/or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and/or B can mean: including the existence of A alone, the existence of A and B at the same time, and the existence of B alone, where A and B can be singular or plural. The character "/" generally indicates that the previous and next associated objects are in an "or" relationship. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can mean: a, b, c, a-b, a-c, b-c, or a-b-c, where a, b, c can be single or multiple.

The technical solution of this application is applicable to a cloud platform system, hereinafter referred to as a cloud platform. A cloud platform is a server platform that provides an operating environment and resources, such as instances and memory, for applications, and supports multi-instance deployment of applications to support high-concurrency external user access.

FIG1 shows a schematic diagram of a cloud service system architecture provided by an embodiment of the present application. As shown in FIG1 , a client can access a cloud platform via the Internet. Typically, a cloud platform includes multiple servers, such as server 1 to server n, each of which includes cloud service resources, such as server 1 includes cloud service 1 and cloud service 2, and cloud service resources provide corresponding cloud services for tenants. The client is connected to the server via a management platform 10. The hardware layer of the server may include a processor, a memory, a network card, and a data bus, etc.

To facilitate understanding, relevant terms and concepts that may be involved in the embodiments of the present application are first introduced below.

1. Telescopic group

A scaling group can be understood as a collection of ECS instances with the same application scenario, or the smallest unit for managing elastically scalable cloud servers. The number of instances in a scaling group can be elastically scalable. For example, if the load of the instances in a scaling group is too large, the number of instances in the scaling group can be increased to share the load of each instance in the scaling group; if the load of the instances in the scaling group is low, some instances can be deleted to save system resources.

2. Scaling strategy

Scaling policies are used to define how a scaling group performs elastic scaling. Classic elastic scaling policies include timed scaling policies and alarm scaling policies.

The scheduled scaling policy is used to instruct the execution of elastic scaling activities at the set time. You need to specify: scaling time, that is, when to scale; scaling scale, that is, the amount of expansion or reduction when scaling is triggered; scaling semantics, that is, the action to be performed, including increase, decrease, adjust to, increase by a certain percentage, decrease by a certain percentage, etc.

The alarm scaling strategy is used to indicate that elastic scaling activities are performed when the observability indicators and the set thresholds are exceeded. It is necessary to specify: alarm indicators, such as central processing unit (CPU) utilization, memory usage, custom business indicators, etc.; alarm threshold, that is, when the monitoring indicator data reaches the threshold, scaling is performed; alarm scaling scale, that is, the amount of expansion or reduction when scaling is triggered; alarm scaling semantics, that is, the action performed, including increase, decrease, adjust to, increase by a certain percentage, decrease by a certain percentage, etc.

The above briefly describes the terms involved in this application, which will not be repeated in the following embodiments. In addition, the above description of terms is only for the sake of ease of understanding, and does not limit the protection scope of the embodiments of this application.

Distributed task scheduling systems are widely used in continuous delivery scenarios such as DevOps (a general term for processes, methods, and systems that emphasize communication and cooperation between "software developers (Dev)" and "IT operation and maintenance technicians (Ops)"). Distributed task scheduling systems can reasonably shield the details of ECS resource scheduling in the cloud platform, thereby reducing the mental burden of users and better focusing on business.

The task scheduling system can obtain the task data of the target task and upload the task data to the cloud platform. The current task scheduling system used for the cloud platform, such as kubernetes, can provide the component kubernetes Auto Scaler to complete the management and scaling of the scaling group, but it often requires users to analyze the business load characteristics and configure the scaling strategy by themselves, that is, to determine the scaling cycle, scaling scale, alarm indicators, etc. After that, the system collects monitoring indicator data, triggers the scaling strategy according to the alarm or by time, and completes the dynamic adjustment of the ECS instance through the resource adjustment interface provided by the cloud computing vendor. The cumbersome manual configuration process of the scaling strategy requires a lot of manpower and material resources, and configuration based on manual experience may cause errors.

In view of this, an embodiment of the present application provides a method for managing instances. The method can obtain resource utilization by monitoring instances of running tasks in a scaling group, generate historical task portraits based on the resource utilization, and then use a model to automatically generate scaling policies based on the historical task portraits. This method can effectively solve the problems of cumbersome scaling policy configuration and high degree of manual intervention that is prone to errors.

FIG2 shows a schematic flow chart of a method 200 for managing resources on a cloud platform provided in an embodiment of the present application. The method includes the following steps.

S210, the instance management platform monitors the instance running the task in the scaling group to obtain monitoring indicator data of the instance;

In some embodiments, the instance management platform may be a cloud platform. Cloud can be generally understood as a group or a bunch of remote computers that work together to build a platform to provide users with a variety of services, such as computing power for computing and analyzing business data, where computing can refer to various requirements for building business systems. In some embodiments, the cloud platform can also be called a cloud computing platform.

Specifically, an instance may be a server resource. For example, an instance may be a virtual machine, a container, a database, a microservice, etc. In some embodiments, an instance may also be referred to as an ECS instance.

In some embodiments, the monitoring indicator data may include resource utilization, where the resource utilization may include one or more of the following: CPU utilization, memory utilization, GPU utilization, disk utilization, and video memory utilization.

In some embodiments, the monitoring indicator data may also include one or more of the following: load indicator, network indicator, custom indicator, disk read rate, disk write rate. Among them, the network indicator may include a public network bandwidth indicator and an intranet bandwidth indicator.

S220, the instance management platform generates a historical task profile based on the monitoring indicator data;

Among them, the historical task portrait can be used to reflect the characteristics of the historical tasks run by the instance in the scaling group. It is understandable that the historical task can be all or part of the historical tasks run by the instance. In some embodiments, the historical task portrait may include one or more of the following: historical task timing characteristics, historical task resource characteristics. Among them, the historical task timing characteristics can be used to indicate the characteristics of the historical tasks in the timing when the scaling group is running, and the historical task resource characteristics can be used to indicate the resource type of the scaling group.

Optionally, the historical task timing characteristics may include one or more of the historical task average running time, the historical task volume peak period, the historical task volume valley period, and the historical task execution cycle. Reflecting the historical task timing characteristics through the above parameters is conducive to the subsequent strategy generation model to generate scaling strategies more accurately and effectively according to the above parameters.

Optionally, resource types may include one or more of the following: one or more of compute-intensive, memory-intensive, input-output intensive (IO intensive) (or read-write intensive), and graphics intensive. Computation-intensive usually requires a lot of calculations and consumes CPU resources; IO intensive usually consumes less CPU, and most of the task time is spent waiting for IO operations to complete; graphics intensive usually requires a lot of graphics rendering, which requires strong processing and storage capabilities. This embodiment is based on historical task resource characteristics, which is conducive to the subsequent strategy generation model to more accurately predict the amount of resources required at different times during the task execution process according to the characteristics, thereby generating a more reasonable scaling strategy.

S230, the instance management platform generates one or more scaling strategies based on the historical task profile using the first model;

The "first model" in the specific example of this application can also be described as a "strategy generation model", which will not be repeated below. It should be understood that the following is only an example given for the convenience of description and understanding, and should not constitute any limitation on the technical solution.

In some embodiments, the policy generation model may be a machine learning model. It is understood that the policy generation model may be trained and can output a scaling policy based on an input historical task profile. Exemplarily, the machine learning algorithm that implements the profile generation model may include one or more of the following algorithms: a classification algorithm, such as a K-nearest neighbor algorithm; or a regression algorithm, such as a linear regression; or a clustering algorithm, such as a K-means algorithm, etc.

Optionally, the scaling strategy may include one or more of the following: timed scaling strategy, alarm scaling strategy, and periodic scaling strategy. Among them, the alarm scaling strategy can instruct the instance management platform to automatically increase, decrease, or set the number or specifications of instances based on the alarm data of the monitoring system (such as CPU usage); the timed scaling strategy can instruct the instance management platform to automatically increase, decrease, or set the number or specifications of instances based on a certain configured time point; the periodic scaling strategy can instruct the instance management platform to periodically increase, decrease, or set the number or specifications of instances according to the configured period (for example, by day, by week, by month).

S240, the instance management platform recommends one or more scaling strategies to the user, and determines the scaling strategy selected by the user;

In some implementations, after the instance management platform generates one or more scaling strategies, it may interact with the user, for example, it may recommend the scaling strategies to the user.

Exemplarily, the scaling policy may be presented to the user through the front end. Exemplarily, one or more of the following parameters in the timing scaling policy in the scaling policy may be presented to the user through the front end: scaling time, timing scaling semantics, timing scaling scale. Exemplarily, one or more of the following parameters in the alarm scaling policy may also be presented to the user through the front end: alarm indicator, alarm threshold, alarm scaling semantics, alarm scaling scale.

It is understandable that users can choose whether to enable the recommended scaling policy, and which one or more scaling policies to choose. For the scaling policy that users choose to enable, when the policy conditions are met, the scaling of the scaling group will be triggered; the scaling policy that users do not choose to enable will not trigger the scaling of the scaling group.

S250: The instance management platform adjusts the number of instances or the specifications of the instances in the scaling group according to the scaling policy selected by the user.

In some implementations, the scaling group can be scaled horizontally (or horizontal scaling) or vertically (or vertical scaling). Horizontal scaling can be understood as adjusting the number of instances in the scaling group, for example, increasing or decreasing the number of instances. Vertical scaling can be understood as adjusting the specifications of the instances in the scaling group, for example, increasing or decreasing the CPU, memory, bandwidth, and other configurations of the instances.

Based on the above technical solution, a large amount of high-quality data can be fully utilized, and a model can be used to automatically generate reasonable scaling strategies according to historical task portraits. The scaling strategies can also be enabled by interacting with users, thereby solving the problems of cumbersome scaling strategy configuration and large errors in manual intervention, and improving the scaling effect. In addition, scaling strategies are formulated according to historical task portraits to reduce the large amount of data calculation, cumbersome parameter conversion, and low accuracy caused by directly formulating scaling strategies based on monitoring-related data, making the generation of scaling strategies more efficient and reasonable.

Optionally, the historical task portrait can be obtained by manual analysis based on the historical task data, or the historical task portrait can be generated by a machine learning model based on the historical task data. In some implementations, generating the historical task portrait based on the monitoring indicator data in step S220 can specifically include: using a second model to generate the historical task portrait based on the monitoring indicator data, the input of the second model is the monitoring indicator data, and the output of the second model is the historical task portrait.

The "second model" in the specific example of this application can be described as a "portrait generation model", which will not be repeated below. It should be understood that the following is only an example given for the convenience of description and understanding, and should not constitute any limitation on the technical solution.

Optionally, the portrait generation model can also be a trained machine learning model, where the input of the portrait generation model can be monitoring indicator data and the output is a historical task portrait. There are a wide range of machine learning algorithms for implementing the portrait generation model, and commonly used deep learning algorithms can be used, such as gradient descent algorithm, back propagation algorithm, pooling, etc.; classification algorithms, such as K-nearest neighbor algorithm; or clustering algorithms, such as K-means algorithm, etc. can also be used.

Based on this solution, the second model is used to extract historical task portraits based on data such as resource utilization in the monitoring indicator data. Compared with manual analysis and extraction of task portraits, historical task portraits can be extracted faster and more accurately.

In some implementations, before the monitoring indicator data is input into the portrait generation model, the monitoring indicator data may be preprocessed to obtain processed data. FIG3 provides a method for generating a historical task portrait. As shown in FIG3 , the above step S220 may specifically include the following steps:

S221, preprocessing the monitoring indicator data to obtain processed data;

The preprocessing may include one or more of the following: normalization and vectorization.

S222, using the second model to generate a historical task portrait based on the processed data, the input of the second model is the processed data, and the output of the second model is the historical task portrait.

Based on this solution, the portrait generation model can extract historical task portraits based on the preprocessed monitoring indicator data, which is conducive to more efficient and accurate generation of historical task portraits.

In some implementations, after the historical task portrait is generated in step S220, the historical task portrait can also be presented to the user, that is, the historical task time series characteristics and/or historical task resource characteristics can be presented to the user. Specifically, the task portrait can be presented through the front-end user interface. Based on this technical solution, when the user formulates a scaling strategy by himself, the historical task portrait can assist the user in completing the scaling strategy formulation, thereby facilitating improving the scaling effect of the scaling strategy.

In some implementations, the use of the policy generation model in step S230 to generate a scaling policy based on the historical task profile may specifically use the policy generation model to determine one or more of the following parameters of the timed scaling policy based on the historical task profile: scaling time, timed scaling semantics, and timed scaling scale. An example of a timed scaling policy is: "2023/03/01 00:00:00, add 3 instances", and another example is: "2023/03/01 00:00:00, expand capacity by 3".

In some implementations, the above step S230 may specifically use the policy generation model to determine one or more of the following parameters of the alarm scaling policy: alarm indicator, alarm threshold, alarm scaling semantics, and alarm scaling scale. Optionally, the alarm threshold may include an upper threshold and a lower threshold. Examples of alarm scaling policies: "CPU usage > 70%, add 2 instances"; "CPU usage < 30%, reduce 2 instances"

Optionally, in the above step S230, the policy generation model may be used to determine one or more of the following parameters of the periodic scaling policy: scaling period, periodic scaling semantics, and periodic scaling scale. An example of a periodic scaling policy: "2023/03/01 00:00:00-2023/03/31 23:59:59, increase 10% of instances every day".

Optionally, when the business load is difficult to predict, the user can select an alarm policy. The system will trigger scaling activities based on real-time monitoring data (such as CPU usage) and dynamically adjust the number or specifications of instances in the scaling group.

When business load changes regularly, you can select a timing policy or a periodic policy to adjust the number or specifications of instances in the scaling group.

Through the above implementation, the relevant parameters determined by the required policy generation model are specifically refined, so that the subsequent scaling group can adjust the instance more accurately, thereby further improving the scaling effect.

In some implementations, in step S260, the number of instances in the scaling group or the specifications of the instances are adjusted, and specifically there may be the following adjustment modes: direct adjustment mode, progressive adjustment mode, and tracking adjustment mode.

Direct adjustment mode refers to directly adjusting the number of instances in the scaling group or the specifications of the instances to the set value. For example, the scaling policy includes "CPU usage > 70%, expand by 3". When the alarm scaling policy is triggered, the instance management platform can directly add 3 instances to the scaling group.

The progressive adjustment mode refers to segmented expansion and contraction based on monitoring alarms. It adds step-by-step definitions to the direct adjustment mode, allowing for fine-grained control of expansion and contraction.

Tracking adjustment mode means that you can select a monitoring indicator data and specify the target value. The instance management platform will automatically calculate the required number of instances and scale them up and down to keep the monitoring indicator data near the target value. For example, the scaling strategy includes "maintaining CPU utilization at 70%". When the alarm scaling strategy is triggered, the required number of instances is calculated and scaled up and down to keep the CPU utilization near 70%.

When a scaling group performs a scaling operation, the resource capacity in the scaling group changes, which may cause a mismatch between the task and the actual resource load capacity. For example, after the number of instances increases, the task fails to match the actual resource load capacity due to some flow limiting reasons, resulting in resource waste.

Optionally, when a task is issued, the type of task can be determined based on the business affiliation of the task, such as pipeline business, big data business, model training business, etc. The type of task can also be divided into compute-intensive, memory-intensive, read/write-intensive, graphics-intensive, etc. In some implementations, tasks can be preferentially scheduled to scaling groups of matching types. For example, compute-intensive tasks can be preferentially scheduled to compute-intensive scaling groups, and memory-intensive tasks can be preferentially scheduled to memory-intensive scaling groups.

In some implementations, the instance management platform may also calculate the remaining resources of the scaling group according to the number and specifications of the instances in the scaling group. Optionally, tasks may be preferentially scheduled to scaling groups with larger remaining resources.

In some implementations, the instance management platform can decide to suspend the task or schedule the task between scaling groups based on the resource type and remaining resources of the scaling group. In other words, the instance management platform can dynamically adjust the task flow limit based on the resource type and remaining resources of the scaling group. When the task is issued, the task can be preferentially scheduled to the scaling group that matches the task type and has a large remaining resource amount. This scaling group can be called the optimal scaling group. When the remaining resources of the scaling groups that match the task type are relatively small, the task can be suspended and waited.

Based on the above implementation, the task execution current limiting parameters can be dynamically adjusted according to the resource type and remaining resource amount in the scaling group, and the optimal scaling group can be selected to complete task delivery, which can avoid resource waste and improve the task execution efficiency of the scaling group.

As shown in Figure 4, a schematic diagram of a client interface provided in an embodiment of the present application is shown. Exemplarily, the user can click the "Scaling Policy Configuration Recommendation" option to view the current policy and the recommended policy. Among them, recommended policy 1 and recommended policy 2 can be policies generated by the policy recommendation model of the present application. Optionally, the user can click the "Recommended Policy 1" option to view the specific parameters of the scaling policy. For example, after clicking on recommended policy 1, the interface can display "CPU usage > 70%, expansion 3".

Optionally, the instance management platform can monitor the instance's various monitoring indicators in real time. During normal operation, each performance indicator is within a reasonable range.

Exemplarily, the user can click the "Enable" option to enable the corresponding recommended strategy. For example, after the user clicks the "Enable" option corresponding to recommended strategy 1, when the instance CPU usage is monitored to be greater than 70%, the scaling activity of recommended strategy 1 will be triggered, causing the cloud platform to execute the expansion operation and add 3 instances to the scaling group to avoid task execution exceptions.

Exemplarily, the recommended strategy 2 can be "CPU usage <30%, scale down 1". After the user clicks the "Enable" option corresponding to the recommended strategy 2, when the CPU usage is monitored to be less than 30%, the scaling activity of the recommended strategy 2 will be triggered to reduce resource waste and reduce operating costs.

The method embodiment of the embodiment of the present application is described in detail above, and the device embodiment of the embodiment of the present application is described below. The device embodiment and the method embodiment correspond to each other, so the parts not described in detail in the device embodiment can refer to the previous method embodiment.

FIG5 shows a schematic structural block diagram of an instance management platform 500 provided in an embodiment of the present application. The instance management platform may include: a monitoring module 510, which is used to monitor the instance of the running task in the scaling group to obtain the resource utilization of the instance, and the resource utilization includes one or more of the following: CPU utilization and memory utilization; a policy generation module 520, which is used to generate a historical task portrait based on the resource utilization, and the historical task portrait includes one or more of the following: historical task timing characteristics and historical task resource characteristics, wherein the historical task timing characteristics are used to indicate the characteristics of the historical task in the timing when the scaling group is running, and the historical task resource characteristics are used to indicate the resource type of the scaling group, and the resource type may include one or more of the following: computing intensive, memory intensive, input and output intensive, and graphics intensive; the policy generation module 520 is also used to generate one or more scaling policies according to the historical task portrait using a first model, the input of the first model is the historical task portrait, and the output of the first model is one or more scaling policies; an execution module 530, which is used to recommend one or more scaling policies to a user; the execution module 530 is also used to determine the scaling policy selected by the user; the execution module 530 is also used to adjust the number of instances or the specifications of the instances in the scaling group according to the scaling policy selected by the user.

Based on the above technical solution, the strategy generation module 520 can make full use of a large amount of high-quality data, use the model to automatically generate a reasonable scaling strategy according to the historical task portrait, and can interact with the user through the execution module 530 to enable the scaling strategy, thereby solving the problems of cumbersome scaling strategy configuration and large errors in manual intervention, and can improve the scaling effect; in addition, the strategy generation module 520 formulates the scaling strategy according to the historical task portrait, reducing the large amount of data calculation, cumbersome parameter conversion, low accuracy and other problems brought about by directly formulating the scaling strategy based on the monitored data, thereby making the generation of the scaling strategy more efficient and reasonable.

In some possible implementations, the scaling strategy may include one or more of the following: a scheduled scaling strategy and an alarm scaling strategy. The strategy generation module is specifically used to use the first model to determine one or more of the following parameters of the scheduled scaling strategy based on the historical task portrait: scaling time, scheduled scaling semantics, and scheduled scaling scale; use the first model to determine one or more of the following parameters of the alarm scaling strategy based on the historical task portrait: alarm indicator, alarm threshold, alarm scaling semantics, and alarm scaling scale.

Based on the above implementation, the relevant parameters determined by the required policy generation model are specifically refined, so that the subsequent scaling group can adjust the instance more accurately, thereby further improving the scaling effect.

In some possible implementations, the execution module 530 may also be used to: determine the remaining resource amount based on the number of instances and the instance specifications; decide to suspend the task or schedule the task between scaling groups based on the resource type and remaining resource amount of the scaling group.

Based on the above implementation, the task execution current limiting parameters can be dynamically adjusted according to the type and remaining resources in the scaling group, and the optimal scaling group can be selected to complete task delivery, which can reduce resource waste and improve the task execution efficiency of the scaling group.

In some implementations, the execution module 530 may also present historical task timing characteristics and historical task resource characteristics to the user.

Based on this technical solution, when users formulate scaling strategies themselves, historical task portraits can assist users in completing scaling strategy formulation, thereby helping to improve the scaling effect of the scaling strategy.

In some embodiments, the strategy generation module 520 can be specifically used to: preprocess resource utilization to obtain processing data, the preprocessing including one or more of the following: normalization, vectorization; use a second model to generate a historical task portrait based on the processing data, the input of the second model is the processing data, and the output of the second model is the historical task portrait.

Based on this solution, the strategy generation module 520 can use the second model to extract historical task portraits based on data such as resource utilization. Compared with manual analysis to extract task portraits, historical task portraits can be extracted faster and more accurately; and the second model can extract historical task portraits based on pre-processed processing data, which is conducive to more efficient and accurate generation of historical task portraits.

In some implementations of the present application, the historical task timing characteristics may include one or more of the following: average running time of historical tasks, peak time periods of historical task volume, trough time periods of historical task volume, and historical task execution cycles.

Among them, the monitoring module, the policy generation module and the execution module can all be implemented by software, or can be implemented by hardware. Exemplarily, the implementation of the monitoring module is introduced below by taking the monitoring module as an example. Similarly, the implementation of the policy generation module and the execution module can refer to the implementation of the monitoring module.

As an example of a software functional unit, the monitoring module may include code running on a computing instance. Among them, the computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Furthermore, the above-mentioned computing instance may be one or more. For example, the monitoring module may include code running on multiple hosts/virtual machines/containers. It should be noted that the multiple hosts/virtual machines/containers used to run the code may be distributed in the same region or in different regions. Furthermore, the multiple hosts/virtual machines/containers used to run the code may be distributed in the same availability zone (AZ) or in different AZs, each AZ including one data center or multiple data centers with similar geographical locations. Among them, usually a region may include multiple AZs.

Similarly, multiple hosts/virtual machines/containers used to run the code can be distributed in the same virtual private cloud (VPC) or in multiple VPCs. Usually, a VPC is set up in a region. For cross-region communication between two VPCs in the same region and between VPCs in different regions, a communication gateway needs to be set up in each VPC to achieve interconnection between VPCs through the communication gateway.

As an example of a hardware functional unit, the monitoring module may include at least one computing device, such as a server, etc. Alternatively, the monitoring module may also be a device implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL) or any combination thereof.

The multiple computing devices included in the monitoring module can be distributed in the same region or in different regions. The multiple computing devices included in the monitoring module can be distributed in the same AZ or in different AZs. Similarly, the multiple computing devices included in the monitoring module can be distributed in the same VPC or in multiple VPCs. The multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

It should be noted that, in other embodiments, the monitoring module can be used to execute any step in the method for managing an instance, the policy generation module can be used to execute any step in the method for managing an instance, and the execution module can be used to execute any step in the method for managing an instance. The steps that the monitoring module, the policy generation module, and the execution module are responsible for implementing can be specified as needed. The full functions of the instance management platform are realized by respectively implementing different steps in the method for managing an instance through the monitoring module, the policy generation module, and the execution module.

The present application also provides a computing device 600. As shown in FIG6 , the computing device 600 includes: a bus 602, a processor 604, a memory 606, and a communication interface 608. The processor 604, the memory 606, and the communication interface 608 communicate with each other through the bus 602. The computing device 600 can be a server or a terminal device. It should be understood that the present application does not limit the number of processors and memories in the computing device 100.

The bus 602 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, FIG. 6 is represented by only one line, but does not mean that there is only one bus or one type of bus. The bus 602 may include a path for transmitting information between various components of the computing device 600 (e.g., the memory 606, the processor 604, and the communication interface 608).

The processor 604 may include any one or more of a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

The memory 606 may include a volatile memory, such as a random access memory (RAM). The processor 604 may also include a non-volatile memory, such as a read-only memory (ROM), a flash memory, a hard disk drive (HDD), or a solid state drive (SSD).

The memory 606 stores executable program codes, and the processor 604 executes the executable program codes to respectively implement the functions of the aforementioned monitoring module, policy generation module, and execution module, thereby implementing the aforementioned method for managing instances. That is, the memory 606 stores instructions for executing the aforementioned method for managing instances.

The communication interface 608 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 600 and other devices or communication networks.

The embodiment of the present application also provides a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smart phone.

As shown in Fig. 7, the computing device cluster includes at least one computing device 600. The memory 606 in one or more computing devices 600 in the computing device cluster may store the same instructions for executing the above-mentioned method for managing instances.

In some possible implementations, the memory 606 of one or more computing devices 600 in the computing device cluster may also store partial instructions for executing the above-mentioned method for managing instances. In other words, the combination of one or more computing devices 600 may jointly execute instructions for executing the above-mentioned method for managing instances.

It should be noted that the memory 606 in different computing devices 600 in the computing device cluster can store different instructions, which are respectively used to execute part of the functions of the above-mentioned instance management platform. That is, the instructions stored in the memory 606 in different computing devices 600 can implement the functions of one or more modules among the data monitoring module, the policy generation module, and the execution module.

In some possible implementations, one or more computing devices in the computing device cluster can be connected via a network. Wherein, the network can be a wide area network or a local area network, etc. FIG. 8 shows a possible implementation. As shown in FIG. 8 , two computing devices 600A and 600B are connected via a network. Specifically, the network is connected via a communication interface in each computing device. In this type of possible implementation, the memory 606 in the computing device 600A stores instructions for executing the functions of the monitoring module and the execution module. At the same time, the memory 606 in the computing device 600B stores instructions for executing the functions of the strategy generation module.

The connection method between the computing device clusters shown in Figure 8 can be considered that the method model training of the management instance provided in this application requires a lot of calculations, so it is considered to hand over the functions implemented by the policy generation module to the computing device 600B for execution.

It should be understood that the functions of the computing device 600A shown in FIG8 may also be completed by multiple computing devices 600. Similarly, the functions of the computing device 600B may also be completed by multiple computing devices 600.

The embodiment of the present application also provides a computer program product including instructions. The computer program product may be software or a program product including instructions that can be run on a computing device or stored in any available medium. When the computer program product is run on at least one computing device, the at least one computing device executes the above-mentioned method for managing instances.

The embodiment of the present application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that can be stored by a computing device or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state hard disk). The computer-readable storage medium includes instructions that instruct the computing device to execute the above-mentioned method of managing instances.

An embodiment of the present application also provides a chip, which includes a processor and a data interface. The processor reads instructions stored in a memory through the data interface to execute the above-mentioned method for managing instances.

Optionally, the chip includes a processor and a data interface, and the processor reads instructions stored in the memory through the data interface to execute the above-mentioned method of managing the instance.

Optionally, the chip may further include a memory storing instructions, and the processor is used to execute the instructions stored in the memory. When the instructions are executed, the processor is used to execute the above-mentioned method for managing instances.

Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of the present invention.

Claims (15)

1. A method for managing an instance, comprising: The instance management platform monitors the instances running tasks in the scaling group to obtain resource utilization of the instances, where the resource utilization includes one or more of the following: CPU utilization, memory utilization; The instance management platform generates a historical task profile based on the resource utilization, where the historical task profile includes one or more of the following: a historical task timing feature and a historical task resource feature, where the historical task timing feature is used to indicate a characteristic of a historical task in terms of timing when the scaling group is running, and the historical task resource feature is used to indicate a resource type of the scaling group, where the resource type includes one or more of the following: computing intensive, memory intensive, input/output intensive, and graphics intensive; The instance management platform generates one or more scaling policies according to the historical task profile using a first model, where an input of the first model is the historical task profile, and an output of the first model is the one or more scaling policies; The instance management platform recommends the one or more scaling strategies to the user; The instance management platform determines the scaling strategy selected by the user; The instance management platform adjusts the number of instances or the specifications of the instances in the scaling group according to the scaling policy selected by the user. 2. The method according to claim 1, wherein the scaling strategy includes one or more of the following: a timing scaling strategy, an alarm scaling strategy, The using the first model to generate one or more scaling strategies according to the historical task profile includes: Determine one or more of the following parameters of the scheduled scaling strategy according to the historical task profile using the first model: scaling time, scheduled scaling semantics, and scheduled scaling scale; The first model is used to determine one or more of the following parameters of the alarm scaling strategy according to the historical task portrait: alarm indicator, alarm threshold, alarm scaling semantics, and alarm scaling scale. 3. The method according to claim 1 or 2, characterized in that the method further comprises: The instance management platform determines the remaining resources of the scaling group according to the number of instances and specifications of the instances; The instance management platform decides to suspend the task or schedule the task between scaling groups according to the resource type and the remaining resource amount of the scaling group. 4. The method according to any one of claims 1 to 3, characterized in that the method further comprises: The instance management platform presents the historical task timing characteristics and the historical task resource characteristics to the user. 5. The method according to any one of claims 1 to 4, characterized in that generating a historical task profile based on the resource utilization comprises: Preprocessing the resource utilization to obtain processing data, wherein the preprocessing includes one or more of the following: normalization and vectorization; A second model is used to generate the historical task portrait according to the processed data, wherein the input of the second model is the processed data, and the output of the second model is the historical task portrait. 6. The method according to any one of claims 1-5 is characterized in that the historical task timing characteristics include one or more of the following: average running time of historical tasks, peak period of historical task volume, trough period of historical task volume, and historical task execution cycle. 7. An instance management platform, characterized by comprising: A monitoring module is used to monitor the instances of running tasks in the scaling group to obtain resource utilization of the instances, where the resource utilization includes one or more of the following: CPU utilization and memory utilization; A policy generation module, configured to generate a historical task profile based on the resource utilization, wherein the historical task profile includes one or more of the following: a historical task timing feature and a historical task resource feature, wherein the historical task timing feature is used to indicate a characteristic of a historical task in terms of timing when the scaling group is running, and the historical task resource feature is used to indicate a resource type of the scaling group, wherein the resource type includes one or more of the following: computing intensive, memory intensive, input/output intensive, and graphics intensive; The strategy generation module is further used to generate one or more scaling strategies according to the historical task portrait using a first model, where an input of the first model is the historical task portrait, and an output of the first model is the one or more scaling strategies; An execution module, configured to recommend the one or more scaling strategies to a user; The execution module is also used to determine the scaling strategy selected by the user; The execution module is further configured to adjust the number of instances or the specifications of the instances in the scaling group according to the scaling policy selected by the user. 8. The instance management platform according to claim 7, wherein the scaling strategy comprises one or more of the following: a timed scaling strategy, an alarm scaling strategy, The strategy generation module is specifically used to determine one or more of the following parameters of the timed scaling strategy according to the historical task portrait using the first model: scaling time, timed scaling semantics, and timed scaling scale; The first model is used to determine one or more of the following parameters of the alarm scaling strategy according to the historical task portrait: alarm indicator, alarm threshold, alarm scaling semantics, and alarm scaling scale. 9. The instance management platform according to claim 7 or 8, wherein the execution module is further used for: Determining the remaining resources of the scaling group according to the number of instances and specifications of the instances; It is determined according to the resource type and the remaining resource amount of the scaling group whether to suspend the task and wait, or to schedule the task between scaling groups. 10. The instance management platform according to any one of claims 7 to 9, wherein the execution module is further used for: The historical task timing characteristics and the historical task resource characteristics are presented to the user. 11. The instance management platform according to any one of claims 7 to 10, wherein the policy generation module is specifically used to: Preprocessing the resource utilization to obtain processing data, wherein the preprocessing includes one or more of the following: normalization and vectorization; A second model is used to generate the historical task portrait according to the processed data, wherein the input of the second model is the processed data, and the output of the second model is the historical task portrait. 12. An instance management platform according to any one of claims 7-11, characterized in that the historical task timing characteristics include one or more of the following: average running time of historical tasks, peak period of historical task volume, trough period of historical task volume, and historical task execution cycle. 13. A computing device cluster, comprising at least one computing device, each computing device comprising a processor and a memory; The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster executes the method according to any one of claims 1 to 6. 14. A computer-readable storage medium, characterized in that it comprises computer program instructions, and when the computer instructions are executed by a computing device cluster, the computing device cluster executes the method according to any one of claims 1 to 6. 15 . A computer program product comprising instructions, wherein when the instructions are executed by a computing device cluster, the computing device cluster executes the method according to claim 1 .