Expansion method in cloudy environment, electronic device, storage medium and program product

Abstract

The application discloses a capacity expansion method in a multi-cloud environment, an electronic device, a storage medium and a program product, relates to the technical field of cloud services, and comprises three mechanisms of integrated load benchmark calculation, multi-cloud adaptation coefficient matching and real-time quantity checking. End-to-end automation from data collection to capacity expansion decision is realized, three core pain points of ignoring cross-cloud performance differences, inaccurate evaluation basis and lack of real-time checking in manual capacity expansion are solved, unified, accurate and automatically executable capacity expansion evaluation standards are provided for the multi-cloud environment, and the reliability and response efficiency of the capacity expansion decision are improved.

Description

Technical Field

[0001] This application relates to the field of cloud service technology, and in particular to a method for expanding capacity in a multi-cloud environment, electronic devices, storage media, and program products. Background Technology

[0002] With the rapid development of cloud computing technology and the deepening of enterprise digital transformation, more and more enterprises are adopting multi-cloud strategies to meet the needs of different business scenarios, achieving flexibility and reliability in business architecture by integrating the resources and services of multiple cloud service providers. Multi-cloud environments not only avoid over-reliance on a single cloud service provider and reduce vendor lock-in risk, but also improve overall system stability through resource complementarity and redundant backups. However, the complexity of multi-cloud environments also brings unprecedented challenges to enterprise operation and maintenance management. Due to significant differences in cluster performance in multi-cloud environments, expansion assessments must consider both cross-cloud adaptability and load matching. Currently, cross-cloud expansion assessments generally use load watermarks to calculate the expansion quantity, and then manually compile work orders and push them to each cloud vendor. For example, expansion tools based on fixed ratios determine the expansion quantity, and then manually compile and push the data using spreadsheets. These methods fail to adapt to the performance differences across multiple clouds, leading to resource redundancy or overload; reliance on load watermarks results in a disconnect from actual load; the lack of real-time resource verification easily leads to invalid expansion; and the manual compilation and pushing of work orders is inefficient. Summary of the Invention

[0003] This application provides a capacity expansion method, electronic device, storage medium, and program product in a multi-cloud environment to at least solve the problems in related technologies, such as resource redundancy or overload caused by failure to adapt to the performance differences of multi-cloud environments, reliance on load levels leading to disconnect from actual load, ineffective capacity expansion due to lack of real-time resource verification, or low efficiency due to the need for manual processing and pushing of work orders.

[0004] This application provides a capacity expansion method in a multi-cloud environment. The method includes: acquiring load indicator data of the target cluster within multiple preset time periods; generating a load baseline value for the target cluster based on the load indicator data; determining a corresponding load adaptation coefficient based on the identification information of the target cluster, wherein the identification information is used to represent the cloud vendor information and cluster type information of the corresponding cluster; calculating the target expansion quantity of the target cluster based on the load baseline value and the load adaptation coefficient; acquiring the current number of machines in the target cluster, and determining whether to generate an expansion request for the target cluster based on the relationship between the current number of machines and the target expansion quantity, so as to complete the expansion of the target cluster according to the expansion request.

[0005] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement at least the following steps of a multi-cloud environment scaling method: acquiring load index data of a target cluster over multiple preset time periods; generating a load baseline value for the target cluster based on the load index data; determining a corresponding load adaptation coefficient based on the identification information of the target cluster, wherein the identification information is used to represent the cloud vendor information and cluster type information of the corresponding cluster; calculating the target scaling quantity of the target cluster based on the load baseline value and the load adaptation coefficient; acquiring the current number of machines in the target cluster, and determining whether to generate a scaling request for the target cluster based on the relationship between the current number of machines and the target scaling quantity, so as to complete the scaling of the target cluster according to the scaling request.

[0006] This application also provides a computer-readable storage medium storing a computer program, wherein when executed by a processor, the computer program implements at least the following steps: a multi-cloud environment scaling method comprising: acquiring load index data of a target cluster over multiple preset time periods; generating a load baseline value for the target cluster based on the load index data; determining a corresponding load adaptation coefficient based on the identification information of the target cluster, wherein the identification information is used to represent the cloud vendor information and cluster type information to which the corresponding cluster belongs; calculating the target scaling quantity of the target cluster based on the load baseline value and the load adaptation coefficient; acquiring the current number of machines in the target cluster, and determining whether to generate a scaling request for the target cluster based on the relationship between the current number of machines and the target scaling quantity, so as to complete the scaling of the target cluster according to the scaling request.

[0007] This application also provides a computer program product, including a computer program that, when executed by a processor, implements at least the following steps: a multi-cloud environment scaling method comprising: acquiring load index data of a target cluster over multiple preset time periods; generating a load baseline value for the target cluster based on the load index data; determining a corresponding load adaptation coefficient based on the identification information of the target cluster, wherein the identification information is used to represent the cloud vendor information and cluster type information to which the corresponding cluster belongs; calculating the target scaling quantity of the target cluster based on the load baseline value and the load adaptation coefficient; acquiring the current number of machines in the target cluster, and determining whether to generate a scaling request for the target cluster based on the relationship between the current number of machines and the target scaling quantity, so as to complete the scaling of the target cluster according to the scaling request.

[0008] This application achieves end-to-end automation from data collection to capacity expansion decision-making by integrating three major mechanisms: load benchmark calculation, multi-cloud adaptation coefficient matching, and real-time quantity verification. It solves three core pain points in manual capacity expansion: ignoring cross-cloud performance differences, inaccurate evaluation criteria, and lack of real-time verification. It provides a unified, accurate, and automatically executable capacity expansion evaluation standard for multi-cloud environments, improving the reliability and response efficiency of capacity expansion decisions. Attached Figure Description

[0009] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0010] Figure 1 This is a flowchart illustrating the capacity expansion method in a multi-cloud environment in the first embodiment; Figure 2 This is a diagram of the internal structure of the electronic device in the second embodiment. Detailed Implementation

[0011] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0012] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0013] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0014] In the first embodiment, such as Figure 1As shown, a scaling method for a multi-cloud environment is provided. The method includes: acquiring load metric data of the target cluster over multiple preset time periods; generating a load baseline value for the target cluster based on the load metric data; determining a corresponding load adaptation coefficient based on the identification information of the target cluster, wherein the identification information represents the cloud vendor information and cluster type information of the corresponding cluster; calculating the target scaling quantity of the target cluster based on the load baseline value and the load adaptation coefficient; acquiring the current number of machines in the target cluster, and determining whether to generate a scaling request for the target cluster based on the relationship between the current number of machines and the target scaling quantity, so as to complete the scaling of the target cluster according to the scaling request.

[0015] Specifically, the above method integrates three major mechanisms—load benchmark calculation, multi-cloud adaptation coefficient matching, and real-time quantity verification—to achieve end-to-end automation from data collection to capacity expansion decision-making. It solves three core pain points in manual capacity expansion: ignoring cross-cloud performance differences, inaccurate evaluation criteria, and lack of real-time verification. It provides a unified, accurate, and automatically executable capacity expansion evaluation standard for multi-cloud environments, improving the reliability and response efficiency of capacity expansion decisions.

[0016] In a specific embodiment, the load metric data includes one or more combinations of the following metrics: processor utilization, memory utilization, network input / output throughput, number of disk read / write input / output operations, disk utilization, application layer service request response time, and service error rate, etc.

[0017] Furthermore, the process involves acquiring load metric data for the target cluster within multiple preset time periods, including: determining a data collection time window associated with the target cluster based on a preset historical period configuration; using a unified monitoring platform interface, concurrently or sequentially retrieving historical operational data of the target cluster from the cloud infrastructure where the target cluster resides, according to multiple discrete peak time periods contained within the data collection time window. The peak time periods are multiple independent time intervals pre-divided based on the historical business load characteristics of the target cluster, and each peak time period has a predefined start and end time; parsing and extracting the historical operational data to obtain the original value sequence of the load metric data; and triggering a data supplementation process for the corresponding peak time period in response to the detection of data loss or anomalies in the original value sequence within any peak time period, until complete and valid time period data is obtained or the preset retry limit is reached.

[0018] Specifically, the above method, through a structured data acquisition process, refines "data acquisition" into a complete closed loop including time window determination, concurrent fetching, parsing and extraction, and anomaly handling, ensuring the quality and reliability of the basic input data. Concurrent fetching improves acquisition efficiency; preset peak periods ensure data representativeness; and anomaly detection and re-acquisition mechanisms guarantee data continuity, providing a solid data foundation for subsequent accurate calculation of the load benchmark and avoiding evaluation bias caused by data quality issues.

[0019] In a specific implementation, the scenario is assumed to be: scaling up a ride-hailing service during the evening peak hours; the target cluster is the Alibaba Cloud-publish cluster; and the monitoring platform is the Xuanwu platform. Step 1: Determine the data collection time window. System configuration: The historical period is the most recent 14 days. Therefore, the data collection time window is determined to be 14 days prior to the current date (for example, if today is November 17, 2025, the time window is November 3 to November 16). Step 2: Retrieve historical data for preset peak periods. Preset peak periods (predefined based on ride-hailing service characteristics): Morning peak: 08:30-09:30; Midday mini-peak: 12:00-13:00; Evening peak: 17:30-18:30. Data retrieval operation: The system uses the batch query interface provided by the Xuanwu platform to concurrently retrieve all server processor utilization monitoring data for the Alibaba Cloud-publish cluster during these three daily peak periods within the above 14-day time window. Step 3: Parse and extract load indicator data. The retrieved raw data may be JSON format logs containing fields such as timestamps, machine IPs, and processor utilization. The system parses the data, extracting the average processor utilization for each machine within each peak period, forming a sequence of "period-utilization" data. For example, it obtains a list of the average CPU utilization of the cluster for each day of the evening peak period (17:30-18:30) over the past 14 days: [65%, 72%, 68%, ..., 70%] (a total of 14 values). Step 4: Anomaly Detection and Automatic Data Retrieval. Scenario 1 (Missing Data): The system finds that the data for the evening peak period on November 10th could not be retrieved successfully due to network jitter, and the data for this period is null. The system automatically triggers data retrieval: It immediately calls the Xuanwu platform's interface again, specifically requesting the processor utilization data for the period of 17:30-18:30 on November 10th. Scenario 2 (Abnormal Data): The system finds that the processor utilization value for the morning peak period on November 5th is 120%, exceeding the reasonable range (>100%), and is judged as abnormal. The system triggers supplementary data collection or removal: The supplementary data collection process is also triggered. If the data is still abnormal or unavailable after supplementary collection, it is removed from the sequence according to preset rules (e.g., the abnormal value is removed and logged). Final output: After the above steps, the system obtains a continuous, complete, and valid dataset of processor utilization rates characterizing the historical load level of the Alibaba Cloud-publish cluster during peak evening hours, which serves as input for generating the "load baseline value".

[0020] Furthermore, a data supplementation process is triggered for the corresponding peak period until complete and valid period data is obtained or the preset retry limit is reached. This includes: generating a data supplementation task for the corresponding peak period, wherein the data supplementation task includes at least the target cluster's identification information, the start and end times of the corresponding peak period, and the data type to be supplemented; submitting the data supplementation task to an asynchronous task queue and starting an independent supplementation execution thread to re-initiate a data query request for the corresponding peak period through the monitoring platform interface; in response to the first successful supplementation obtaining complete and valid period data, updating the period data to the original value sequence to replace missing or abnormal data, and terminating the data supplementation process; in response to the first failed supplementation or the returned data still being judged as abnormal, continuing to execute the data supplementation process according to the preset retry control policy until complete and valid period data is obtained or the retry limit is reached.

[0021] Specifically, the above method designs a complete fault-tolerant mechanism with task-oriented, asynchronous, and retry control for the data acquisition process, improving the system's robustness and data integrity. By using task queues and independent threads, acquisition is decoupled from the main process, avoiding blocking. Intelligent retry strategies (such as incremental waiting times) improve the data acquisition success rate when the network or platform is unstable, ensuring that even when some data acquisition is abnormal, the system can complete the evaluation through an automated recovery mechanism, enhancing the overall robustness of the solution.

[0022] In a specific embodiment, the data types to be supplemented include at least one or more of the following types: processor utilization, memory utilization, network input / output throughput, and number of disk read / write input / output operations.

[0023] Furthermore, according to the preset retry control strategy, the data acquisition process continues until complete and valid time-period data is obtained or the maximum number of retry attempts is reached. This includes: in response to the initial acquisition failure or the returned data being determined to be abnormal, initializing the retry counter and entering the retry loop; in response to entering the retry loop, determining the waiting time for this retry based on the current number of retries, wherein the waiting time increases exponentially or stepwise with the number of retries; in response to the end of the waiting time, controlling the acquisition execution thread to re-initiate a data query request through the monitoring platform interface, and performing validity verification on the returned query results, wherein the validity verification includes at least checking... Check if the data is complete, if the values ​​are within a preset reasonable range, and if they conform to the historical load change patterns of the target cluster; if the retry successfully obtains complete and valid time period data, update the time period data to the original value sequence and immediately exit the retry loop process; if the retry fails or the validity check fails, increment the retry counter and determine if the current retry count has reached the retry limit; if the current retry count has not reached the retry limit, enter the next round of the retry loop process; if the current retry count has reached the retry limit, terminate the retry loop process and mark the original value sequence of the corresponding peak time period as failed to be acquired.

[0024] Specifically, the above methods improve the success rate and integrity of data acquisition: Through an intelligent waiting mechanism with exponential backoff or stepped growth, temporary failures or network congestion on the monitoring platform are effectively addressed, increasing the probability of successfully obtaining complete and valid data within a limited number of retries, thus ensuring the reliability of the input data base; resource utilization is optimized and system overload is avoided: dynamically increasing waiting time avoids the impact on the monitoring platform or its own system caused by frequent and invalid synchronous retry requests, achieving self-regulation of retry load and improving the overall system stability and resource utilization efficiency; a closed-loop process and clear failure handling are achieved: through a complete retry loop and clear termination conditions (success or reaching the upper limit), combined with the final failure marker, a standardized processing exit is provided for data anomalies, ensuring that the evaluation process is not "suspended," and even if data acquisition fails, a clear "data quality status" can be transmitted downstream, supporting subsequent degradation or alarm processing.

[0025] In a specific embodiment, after marking the original value sequence corresponding to the peak period as a failed data acquisition, to prevent the entire expansion method from being completely interrupted due to the temporary loss of individual data, data filling or interpolation estimation can be performed on the missing or abnormal item based on the load index data of the target cluster during other normal peak periods of the same period, or the overall average load data of historical clusters of the same type. For example, data filling or interpolation estimation based on data from "other normal peak periods of the same period": Scenario: The target cluster is an Alibaba Cloud-publish cluster, with three preset peak periods: morning peak (8:30-9:30), noon peak (12:00-13:00), and evening peak (17:30-18:30). When pulling data for a certain day (e.g., November 10th), the evening peak data is missing and data acquisition fails. Operation: The system will check the load data of the cluster during the morning and noon peaks on the same day (November 10th) (assuming that the data for these two periods is normal and has been acquired). Data filling: The simplest way is to directly use the average of the morning and noon peak data as the estimated value of the evening peak. Interpolation estimation: A smarter approach is to consider time trends. Since evening peak load is typically higher than morning and afternoon peak load, the system may use historical patterns (e.g., evening peak load is 1.2 times that of afternoon peak load) to multiply the afternoon peak data by a coefficient (e.g., 1.2) to obtain an estimate for the evening peak load. Purpose: To use data from other time periods within the same day to infer the situation during missing periods, maintaining data consistency across the "daily" dimension. Filling or interpolation estimation based on "historical average load data of similar clusters": Scenario: Evening peak data for the Alibaba Cloud-publish cluster is missing and data recovery has failed. However, due to special circumstances on that day (e.g., a large-scale system failure), reference data for all time periods on that day may be unreliable. Operation: The system will then search for historical reference data. Determine "similar clusters": "Similar" refers to: publish-type clusters under the same cloud vendor (e.g., Alibaba Cloud-publish clusters in another region); or business clusters with similar load patterns (e.g., clusters serving the same core order processing service). Obtain "overall average load data": Calculate the average load level of these similar clusters during the evening peak period from their historical data. Imputation or estimation: Directly fill in the missing values ​​with this historical average, or fine-tune it based on some known characteristics of the current cluster (such as size). Purpose: When data for the current day is unavailable, use the general patterns of similar historical clusters to provide a reasonable estimate, ensuring the baseline availability of the data.

[0026] Furthermore, based on the load index data, a load baseline value for the target cluster is generated, including: grouping the load index data by peak time periods and calculating the average load data within the peak time periods to obtain a preliminary baseline value for the peak time periods; and performing a weighted calculation on the preliminary baseline values ​​of multiple peak time periods according to a preset time period weight configuration to obtain the load baseline value for the target cluster; wherein, the time period weight configuration is set differently based on the historical impact and business criticality of multiple peak time periods on the business system where the target cluster is located, and the sum of the time period weights is 1.

[0027] Specifically, the above method introduces a weighted benchmark value calculation method based on time period weighting, achieving a deep integration of technical indicators and business logic, making the evaluation results more business-oriented. General mean calculations cannot distinguish the importance of different business time periods, while this method assigns higher weight to critical business peaks (such as evening peaks), enabling the final calculated load benchmark value to more accurately reflect the actual peak business pressure. This guides expansion resources towards the most critical time periods, improving the effectiveness of resource investment.

[0028] In a specific embodiment, we assume the target business is the core order processing service of a ride-hailing SaaS platform, the target cluster is a Tencent Cloud-gray cluster (canary release environment), and the preset peak time periods (derived from historical data analysis) are: morning peak: 08:30-09:30; midday peak: 12:00-13:00; evening peak: 17:30-18:30. Data is collected from the past 14 days, showing the average processor utilization of the cluster during these three time periods. Step 1: Group calculation of preliminary baseline values ​​for each time period: The system groups and calculates the data from the past 14 days to obtain the average value of the data for each time period: Morning peak (08:30-09:30) 14-day average processor utilization: 45%; Midday peak (12:00-13:00) 14-day average processor utilization: 38%; Evening peak (17:30-18:30) 14-day average processor utilization: 62%. These three values ​​(45%, 38%, 62%) are the "preliminary baseline values" for each time period. Step Two: Weighted Calculation Based on "Time Period Weight Configuration": Weight Configuration Logic Analysis (Based on "Historical Impact and Business Criticality"): Evening Peak (17:30-18:30): This is the absolute peak of the day for ride-hailing services, with concentrated commuting demand, the greatest order pressure, the highest risk of system crash, and the strongest business criticality. Therefore, it should be assigned the highest weight, for example, 0.5. Morning Peak (08:30-09:30): Also a peak travel period, with pressure second only to the evening peak, and high business criticality. It should be assigned the second highest weight, for example, 0.3. Midday Peak (12:00-13:00): Mostly short-distance, temporary trips. Although the order volume is slightly higher than the off-peak period, the pressure is much lower than the morning and evening peaks, and the business criticality is relatively low. Therefore, it should be assigned a lower weight, for example, 0.2. (Total weight: 0.5 + 0.3 + 0.2 = 1). Weighted calculation of load baseline value: Load baseline value = (preliminary baseline value of morning peak * weight of morning peak) + (preliminary baseline value of noon peak * weight of noon peak) + (preliminary baseline value of evening peak * weight of evening peak) = (45% * 0.3) + (38% * 0.2) + (62% * 0.5) = 13.5% + 7.6% + 31% = 52.1%.

[0029] Further, based on the identification information of the target cluster, the corresponding load balancing coefficient is determined, including: performing a matching query in a preset load balancing coefficient mapping table based on the identification information of the target cluster, wherein the load balancing coefficient mapping table stores the load balancing coefficients corresponding to different types of clusters under different cloud vendors; in response to finding a record in the load balancing coefficient mapping table that completely matches the identification information of the target cluster, the load balancing coefficient corresponding to the record is determined as the load balancing coefficient of the target cluster; in response to not finding a record in the load balancing coefficient mapping table that completely matches the identification information of the target cluster, the load balancing coefficient corresponding to the default cluster type under the cloud vendor to which the target cluster belongs in the load balancing coefficient mapping table is determined as the load balancing coefficient of the target cluster.

[0030] Specifically, the above method clarifies that the load adaptation coefficient is determined by querying the adaptation coefficient mapping table, and designs a complete matching and degradation strategy, realizing fine-grained and configurable management of cross-cloud performance differences. By quantifying performance differences into specific coefficients and storing them centrally, performance adaptation adjustments for different cloud vendors and cluster types become unified and easy to maintain; the degradation matching strategy ensures the system's default behavior when no explicit configuration is provided, enhancing the solution's versatility and fault tolerance.

[0031] Further, based on the load baseline value and the load adaptation coefficient, the target expansion quantity of the target cluster is calculated, including: multiplying the load baseline value, the load adaptation coefficient, and the preset number of reference machines to obtain the baseline total load; obtaining the theoretical expansion quantity based on the baseline total load and the preset safe expansion ratio; and performing an up rounding operation on the theoretical expansion quantity to obtain the target expansion quantity of the target cluster.

[0032] Specifically, the above method concretizes the formula for calculating the target expansion quantity, clearly defining core parameters such as the baseline total load and the safe expansion ratio, as well as their operational relationships. This transforms the expansion calculation process from a black box into a transparent, interpretable, and adjustable white box model. The explicit formula facilitates understanding, verification, and optimization (such as adjusting the safe expansion ratio). Rounding up ensures that the target expansion quantity is an integer and meets the minimum capacity requirements, improving the credibility of the evaluation results and providing a clear mathematical model for subsequent cost and performance analysis.

[0033] In a specific implementation, the target expansion quantity * safe expansion ratio = load baseline value * load adaptation coefficient * reference machine number. Here, the safe expansion ratio is typically 50%, and the reference machine number is a baseline parameter used to simulate and quantify the load pressure scale. It represents an assumed or standard cluster size based on when performing theoretical expansion simulations. It is mainly used to multiply by the load baseline value and the adaptation coefficient to calculate the baseline total load, which characterizes how much standardized machine capacity is needed to handle the current load level.

[0034] Furthermore, based on the relationship between the current number of machines and the target expansion number, it is determined whether to generate an expansion request for the target cluster, including: in response to the current number of machines being greater than the target expansion number, determining not to generate an expansion request for the target cluster; in response to the current number of machines being less than or equal to the target expansion number, determining to generate an expansion request for the target cluster.

[0035] Specifically, the above method defines a clear decision logic for generating expansion requests, that is, expansion is only triggered when the target expansion quantity is greater than the current actual quantity. This establishes a decision firewall to prevent invalid or reverse expansion, resolving the "negative expansion" problem that may arise due to flaws in the evaluation logic or real-time resource changes (i.e., the evaluated expansion quantity is actually less than the existing number of machines). This ensures that every expansion request has a clear incremental meaning, avoiding resource waste and invalid operations. Further, generating an expansion request for the target cluster includes: constructing an expansion request data packet, which contains at least the following fields: Target cluster identifier: used to uniquely specify the cluster to be expanded; Current number of machines: the latest number of machines obtained by calling the monitoring platform interface; Target expansion quantity: the number of machines to be expanded calculated based on load baseline values, adaptation coefficients, etc.; Expansion reason code: used to indicate the business scenario or load type that triggered the expansion; Request timestamp: records the time the expansion request was generated; Based on the cloud vendor information to which the target cluster belongs, the corresponding cloud vendor work order template is determined, and the fields in the expansion request data packet are mapped and filled into the specified positions of the corresponding cloud vendor work order template to obtain the expansion request for the target cluster.

[0036] Specifically, the above methods achieve standardization and automation of cross-cloud work orders: by constructing structured data packets and mapping them to templates from different cloud vendors, the problems of manual organization and inconsistent formats are solved; key information is ensured to be complete and traceable: core fields such as cluster identifier, quantity, reason, and time are included, so that each expansion action has a clear basis and record; and the accuracy of push and processing efficiency are improved: based on the cluster identifier, the order is automatically routed to the corresponding cloud vendor, avoiding errors in manual distribution and shortening the resource coordination cycle.

[0037] In a specific embodiment, after mapping and filling the fields in the expansion request data packet to the specified positions in the corresponding cloud vendor's work order template, the completed work order is submitted to the corresponding cloud vendor's work order processing interface to expand the target cluster, and the work order serial number is recorded for subsequent tracking.

[0038] It should be understood that, although Figure 1 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figure 1 At least some of the steps in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily executed at the same time, but may be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but may be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0039] In the second embodiment, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it performs the following steps: acquiring load indicator data of a target cluster within multiple preset time periods; generating a load baseline value for the target cluster based on the load indicator data; determining a corresponding load adaptation coefficient based on the identification information of the target cluster, wherein the identification information is used to represent the cloud vendor information and cluster type information to which the corresponding cluster belongs; calculating the target expansion quantity of the target cluster based on the load baseline value and the load adaptation coefficient; acquiring the current number of machines in the target cluster, and determining whether to generate an expansion request for the target cluster based on the relationship between the current number of machines and the target expansion quantity, so as to complete the expansion of the target cluster according to the expansion request.

[0040] When the program instructions are read and executed by one or more processors, they can also perform operations corresponding to the steps in the above method embodiments, as described above, and will not be repeated here. Reference Figure 2 This example illustrates the architecture of an electronic device, which may include a processor 210, a video display adapter 211, a disk drive 212, an input / output interface 213, a network interface 214, and a memory 220. The processor 210, video display adapter 211, disk drive 212, input / output interface 213, network interface 214, and memory 220 can communicate with each other via a communication bus 230.

[0041] The processor 210 can be implemented using a general-purpose central processing unit (CPU), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solution provided in this application.

[0042] The memory 220 can be implemented as a read-only memory (ROM), random access memory (RAM), static storage device, dynamic storage device, etc. The memory 220 can store the operating system 221 for controlling the operation of the electronic device 200, and the basic input / output system (BIOS) 222 for controlling the low-level operations of the electronic device 200. Additionally, it can store a web browser 223, data storage management 224, and an icon / font processing system 225. The icon / font processing system 225 can be the application program that specifically implements the aforementioned steps in this embodiment. In summary, when implementing the technical solution provided in this application through software or firmware, the relevant program code is stored in the memory 220 and executed by the processor 210.

[0043] Input / output interface 213 is used to connect input / output modules to realize information input and output. Input / output modules can be configured as components in the device (not shown in the figure) or externally connected to the device to provide corresponding functions. Input devices may include keyboards, mice, touch screens, microphones, various sensors, etc., and output devices may include displays, speakers, vibrators, indicator lights, etc.

[0044] Network interface 214 is used to connect a communication module (not shown in the figure) to enable communication between this device and other devices. The communication module can communicate via wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0045] Bus 230 includes a pathway for transmitting information between various components of the device, such as processor 210, video display adapter 211, disk drive 212, input / output interface 213, network interface 214, and memory 220.

[0046] In addition, the electronic device 200 can also obtain information on specific acquisition conditions from a virtual resource object acquisition condition information database (not shown in the figure) for condition judgment.

[0047] It should be noted that although the above-described electronic device 200 only shows a processor 210, a video display adapter 211, a disk drive 212, an input / output interface 213, a network interface 214, a memory 220, and a bus 230, in specific implementations, the electronic device may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the above-described device may only include the components necessary for implementing the solution of this application, and does not necessarily include all the components shown in the figures.

[0048] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause an electronic device (which may be a personal computer, cloud server, or network device, etc.) to execute the methods of various embodiments or some parts of the embodiments of this application.

[0049] In a third embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, it performs the following steps: acquiring load indicator data of a target cluster within multiple preset time periods; generating a load baseline value for the target cluster based on the load indicator data; determining a corresponding load adaptation coefficient based on the identification information of the target cluster, wherein the identification information is used to represent the cloud vendor information and cluster type information to which the corresponding cluster belongs; calculating the target expansion quantity of the target cluster based on the load baseline value and the load adaptation coefficient; acquiring the current number of machines in the target cluster, and determining whether to generate an expansion request for the target cluster based on the relationship between the current number of machines and the target expansion quantity, so as to complete the expansion of the target cluster according to the expansion request.

[0050] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0051] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0052] The above embodiments are merely illustrative of several implementation methods of this application, and their descriptions are relatively specific and detailed. However, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application.

[0053] In the fourth embodiment, a computer program product is provided, on which a computer program is stored. When the computer program is executed by a processor, it performs the following steps: acquiring load indicator data of a target cluster within multiple preset time periods; generating a load baseline value for the target cluster based on the load indicator data; determining a corresponding load adaptation coefficient based on the identification information of the target cluster, wherein the identification information is used to represent the cloud vendor information and cluster type information to which the corresponding cluster belongs; calculating the target expansion quantity of the target cluster based on the load baseline value and the load adaptation coefficient; acquiring the current number of machines in the target cluster, and determining whether to generate an expansion request for the target cluster based on the relationship between the current number of machines and the target expansion quantity, so as to complete the expansion of the target cluster according to the expansion request.

[0054] In a fourth embodiment, a computer program product is also provided, including a non-volatile computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it performs the following steps: acquiring load indicator data of a target cluster within multiple preset time periods; generating a load baseline value for the target cluster based on the load indicator data; determining a corresponding load adaptation coefficient based on the identification information of the target cluster, wherein the identification information is used to represent the cloud vendor information and cluster type information to which the corresponding cluster belongs; calculating the target expansion quantity of the target cluster based on the load baseline value and the load adaptation coefficient; acquiring the current number of machines in the target cluster, and determining whether to generate an expansion request for the target cluster based on the relationship between the current number of machines and the target expansion quantity, so as to complete the expansion of the target cluster according to the expansion request.

[0055] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer program product, and when the computer program is executed, it can include the processes of the embodiments of the methods described above.

[0056] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0057] The above embodiments are merely illustrative of several implementation methods of this application, and their descriptions are relatively specific and detailed. However, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application.

Claims

1. A method for expanding capacity in a multi-cloud environment, characterized in that, The method includes: Obtain load metric data for the target cluster over multiple preset time periods; Based on the load metric data, generate the load baseline value for the target cluster; Based on the identification information of the target cluster, the corresponding load matching coefficient is determined, wherein the identification information is used to represent the cloud vendor information and cluster type information to which the corresponding cluster belongs; Calculate the target expansion quantity of the target cluster based on the load baseline value and the load adaptation coefficient; Obtain the current number of machines in the target cluster, and determine whether to generate an expansion request for the target cluster based on the relationship between the current number of machines and the target expansion quantity, so as to complete the expansion of the target cluster according to the expansion request.

2. The method according to claim 1, characterized in that, The acquisition of load metric data for the target cluster over multiple preset time periods includes: Based on the preset historical period configuration, determine the data collection time window associated with the target cluster; Through a unified monitoring platform interface, the historical operation data of the target cluster is pulled concurrently or sequentially from the cloud infrastructure where the target cluster is located, according to multiple discrete peak periods contained in the data collection time window. The peak periods are multiple independent time intervals pre-divided according to the historical business load characteristics of the target cluster, and the peak periods have predefined start and end times. The historical operating data is parsed and extracted to obtain the original value sequence of the load index data; In response to the detection of data loss or anomalies in the original value sequence during any of the peak periods, a data supplementation process for the corresponding peak period is triggered until complete and valid period data is obtained or the preset maximum number of retries is reached.

3. The method according to claim 2, characterized in that, The process of triggering data supplementation for the corresponding peak period, until complete and valid period data is obtained or the preset retry limit is reached, includes: Generate a data supplementation task for the corresponding peak period, wherein the data supplementation task includes at least the identification information of the target cluster, the start and end times of the corresponding peak period, and the data type to be supplemented; The data supplementation task is submitted to the asynchronous task queue, and an independent supplementation execution thread is started to re-initiate the data query request for the corresponding peak period through the monitoring platform interface; In response to the successful acquisition of complete and valid time period data in the first supplementary acquisition, the time period data is updated to the original value sequence to replace missing or abnormal data, and the data supplementary acquisition process is terminated. If the initial data acquisition fails or the returned data is still deemed abnormal, the data acquisition process continues according to the preset retry control strategy until complete and valid time period data is obtained or the maximum number of retry attempts is reached.

4. The method according to claim 1, characterized in that, The step of generating the load baseline value for the target cluster based on the load metric data includes: The load index data is grouped according to peak periods, and the average load data within the peak periods is calculated to obtain the preliminary baseline value of the peak periods; Based on the preset time period weight configuration, the preliminary benchmark values ​​of multiple peak time periods are weighted and calculated to obtain the load benchmark value of the target cluster. The time period weight configuration is based on the differentiated setting of the historical impact and business criticality of the target cluster's business system by multiple peak time periods, and the sum of the time period weights is 1.

5. The method according to claim 1, characterized in that, The step of determining the corresponding load adaptability coefficient based on the identification information of the target cluster includes: Based on the identification information of the target cluster, a matching query is performed in a preset adaptation coefficient mapping table, wherein the adaptation coefficient mapping table stores the load adaptation coefficients corresponding to different types of clusters under different cloud vendors. In response to finding a record in the adaptation coefficient mapping table that completely matches the identification information of the target cluster, the corresponding load adaptation coefficient in the record is determined as the load adaptation coefficient of the target cluster. In response to the fact that no record matching the identification information of the target cluster is found in the adaptation coefficient mapping table, the load adaptation coefficient corresponding to the default cluster type of the cloud vendor to which the target cluster belongs in the adaptation coefficient mapping table is determined as the load adaptation coefficient of the target cluster.

6. The method according to claim 1, characterized in that, The step of calculating the target expansion quantity of the target cluster based on the load baseline value and the load adaptation coefficient includes: The total reference load is obtained by multiplying the load baseline value, the load adaptation coefficient, and the preset number of reference machines. Based on the total baseline load and the preset safe expansion ratio, the theoretical expansion capacity is obtained; The theoretical expansion amount is rounded up to obtain the target expansion amount of the target cluster.

7. The method according to claim 1, characterized in that, The step of determining whether to generate an expansion request for the target cluster based on the relationship between the current number of machines and the target expansion amount includes: In response to the fact that the current number of machines is greater than the target expansion number, it is determined that no expansion request will be generated for the target cluster; In response to the current number of machines being less than or equal to the target expansion number, a expansion request for the target cluster is generated.

8. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the scaling method in a multi-cloud environment as described in any one of claims 1 to 7 when executing the computer program.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, it implements the steps of the expansion method in a multi-cloud environment as described in any one of claims 1 to 7.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the scaling method in a multi-cloud environment as described in any one of claims 1 to 7.

Images