Terraform-based multi-cloud virtual machine elastic scaling method, system, terminal and medium

Abstract

The application relates to the field of cloud platforms, and specifically provides a multi-cloud virtual machine elastic scaling method and system based on Terraform, a terminal and a medium, which comprises the following steps: synchronizing basic parameters of each cloud platform; collecting resource performance indexes of the cloud platform to generate time sequence monitoring data sets by calling monitoring interfaces of the cloud platform in real time; generating scaling instructions based on real-time load states reflected by the data sets and in combination with preset cost priority, performance priority or mixed strategies; selecting a resource configuration template of a corresponding cloud platform from a preset template library according to a target instance specification in the scaling instructions, and injecting a target instance number and an available zone parameter to generate a variable file; loading the resource configuration template and the variable file by calling a Terraform docking plug-in, generating an infrastructure change scheme through a resource change pre-checking command, and completing resource expansion and scaling by executing a resource change execution command. The application realizes minute-level, low-cost, high-performance and cross-cloud escape closed-loop elastic scaling.

Description

Technical Field

[0001] This application relates to the field of cloud platforms, specifically to a method, system, terminal, and medium for elastic scaling of multi-cloud virtual machines based on Terraform. Background Technology

[0002] In multi-cloud scenarios, the instance specifications, availability zones, and pricing models of different cloud vendors vary significantly, resulting in scattered basic parameters and insufficient real-time performance. The CPU, memory, and other metrics returned by monitoring interfaces are not uniform in format and unit, making it difficult to form a global load view. Existing single-cloud Auto Scaling or Kubernetes HPA scales based solely on static rules or container-level metrics, failing to balance cost and performance simultaneously and lacking cross-cloud scheduling capabilities. Infrastructure scripts need to be repeatedly developed for different cloud platforms, lacking a unified pre-verification mechanism before changes, which can easily lead to configuration conflicts or quota overruns during execution, resulting in high operation and maintenance costs, long scaling times, and vulnerability to being locked into a single cloud vendor. Summary of the Invention

[0003] To address the aforementioned issues, this invention provides a method, system, terminal, and medium for multi-cloud virtual machine elastic scaling based on Terraform, enabling closed-loop elastic scaling with minute-level latency, low cost, high performance, and cross-cloud escapability.

[0004] In a first aspect, the technical solution of the present invention provides a method for elastic scaling of multi-cloud virtual machines based on Terraform, comprising the following steps:

[0005] Periodically synchronize the basic parameters of each cloud platform to the local cache database. The basic parameters include instance specifications, availability zones, and pricing metadata.

[0006] Real-time calls to the monitoring interfaces of various cloud platforms to collect resource performance indicators of the cloud platforms, unify the units and standardize the format of heterogeneous data, and generate time-series monitoring datasets;

[0007] Based on the real-time load status reflected by the time-series monitoring dataset, and combined with preset cost-first, performance-first, or hybrid strategies, scaling instructions containing the target number of instances, target instance specifications, and target cloud platform are generated.

[0008] Based on the target instance specifications in the scaling instruction, select the corresponding cloud platform resource configuration template from the preset template library, and inject the target instance quantity and availability zone parameters into the selected resource configuration template to generate a variable file;

[0009] The Terraform integration plugin is invoked to load the selected resource configuration template and the variable file. An infrastructure change plan is generated through a resource change pre-verification command. When the verification passes, the resource change execution command is executed to complete the resource scaling up or down.

[0010] In an optional implementation, the time-series monitoring dataset reflects real-time load status, specifically including:

[0011] The pre-configured time window length is used to calculate the average, peak, and standard deviation of various resource performance indicators in the time-series monitoring dataset based on this time window length.

[0012] If all calculation results are within the corresponding threshold, the real-time load status is marked as normal load status. If the target calculation result of any target indicator exceeds the warning threshold, the real-time load status is marked as critical load status. If the target calculation result of any target indicator exceeds the safety threshold, the real-time load status is marked as overload status.

[0013] In an optional implementation, scaling instructions containing the target number of instances, target instance specifications, and target cloud platform are generated by combining preset cost-first, performance-first, or hybrid strategies, specifically including:

[0014] The strategy is selected based on the real-time load status. When the state is marked as overload, the performance priority strategy is forcibly enabled. When the state is marked as critical load, if the budget consumption rate is not lower than the preset consumption rate threshold, the cost priority strategy is enabled; otherwise, the hybrid strategy is enabled. When the state is marked as normal load, if the current business peak period is in effect, the hybrid strategy is enabled; otherwise, the cost priority strategy is enabled.

[0015] The strategy weight factor is calculated by calling the corresponding strategy weight function based on the selected strategy type. The strategy weight factor and the time-series monitoring dataset are then input into the strategy decision engine to calculate the initial target number of instances for each cloud platform.

[0016] Based on the initial target number of instances and the cached price metadata, calculate the estimated total cost for each cloud platform, and eliminate cloud platforms whose estimated total cost exceeds the budget limit threshold to obtain a list of candidate cloud platforms.

[0017] Based on the network latency, historical failure rate, and synchronized remaining capacity of the availability zone for each region in the candidate cloud platform list, calculate the availability score of the candidate cloud platform, select the candidate cloud platform with the highest score as the final target cloud platform, and determine the corresponding initial target instance number as the final target instance number.

[0018] The specification scoring function of the corresponding strategy is invoked according to the selected strategy type, and the target instance specification of the final target cloud platform is determined based on the specification scoring function.

[0019] Build scaling instructions that include the target number of instances, the target instance specifications, and the target cloud platform.

[0020] In an optional implementation, the corresponding strategy weight function is called to calculate the strategy weight factor based on the selected strategy type, specifically including:

[0021] If a performance-first strategy is selected, the ratio of peak CPU utilization to the maximum computing power of the instance specification is used as the performance weight, and the unit price of the instance per unit time is used as the cost weight. The two are weighted and summed to obtain the performance weight coefficient.

[0022] If a cost-first strategy is selected, the unit computing power cost is used as the cost weight, and the performance degradation tolerance threshold is used as the performance weight. The two are weighted and summed to obtain the cost weight coefficient.

[0023] If a hybrid strategy is selected, the performance weight and cost weight are dynamically balanced according to the preset business peak weight factor to obtain the hybrid weight coefficient.

[0024] In an optional implementation, the policy weighting factor and time-series monitoring dataset are input into the policy decision engine to calculate the initial target number of instances for each cloud platform, specifically including:

[0025] The performance weight coefficient, cost weight coefficient, or hybrid weight coefficient is mapped to a preset weight-instance number conversion table to obtain the baseline instance increment ΔNbase corresponding to the weight coefficient; wherein, the weight-instance number conversion table records the discrete correspondence between the weight coefficient range and the baseline instance increment, and the same weight coefficient range corresponds to different ΔNbase values ​​under different strategy types.

[0026] Based on the time-series monitoring dataset, sliding time window aggregation operations are performed on the average CPU utilization and average memory utilization to obtain the CPU sliding mean μCPU, the memory sliding mean μMEM, the CPU peak PCPU, and the memory peak PMEM.

[0027] Let the target thresholds for μCPU, μMEM, PCPU, and PMEM be TCPU, TMEM, TCPU_peak, and TMEM_peak, respectively. Calculate the load deviation factor β using the following formula:

[0028]

[0029] If β≤0, then let β=0;

[0030] The initial target number of instances Ninit for the cloud platform is calculated using the following formula:

[0031] Ninit=Ncurrent+round(ΔNbase×(1+β));

[0032] Where Ncurrent is the actual number of running instances on the cloud platform at the current moment, and round() is the rounding function;

[0033] When the calculated Ninit is less than the minimum instance number threshold Nmin of the corresponding cloud platform, let Ninit = Nmin; when Ninit is greater than the maximum instance number threshold Nmax of the corresponding cloud platform, let Ninit = Nmax.

[0034] In one optional implementation, the availability score of the candidate cloud platform is calculated based on the network latency, historical failure rate, and synchronized remaining capacity of each region in the candidate cloud platform list. Specifically, this includes:

[0035] The round-trip time (RTT) from the business exit to the nearest access point of the candidate cloud platform is collected. Based on the preset target latency threshold Tlatency, if RTT≤Tlatency, the network latency score LatencyScore=100; if RTT>Tlatency, the network latency score LatencyScore=100×(Tlatency / RTT).

[0036] Read the instance-level failure rate (FR) of the candidate cloud platform in the past statistical period; based on the acceptable failure rate threshold (TFR), if FR≤TFR, then the historical failure rate score FaultScore=100; if FR>TFR, then the historical failure rate score FaultScore=100×(TFR / FR).

[0037] Based on the synchronized remaining capacity of the availability zone, calculate the schedulable capacity ratio (CR) of the candidate cloud platform in the target area to meet the required instance specifications; if CR ≥ required capacity, then the remaining capacity score of the availability zone, CapacityScore = 100; if CR < required capacity, then the remaining capacity score of the availability zone, CapacityScore = 100 × (CR / required capacity).

[0038] The availability score of the candidate cloud platform is obtained by weighting and summing the network latency score, historical failure rate score, and remaining capacity score of the availability zone.

[0039] In an optional implementation, the specification scoring function of the corresponding strategy is invoked according to the selected strategy type, and the target instance specification of the final target cloud platform is determined based on the specification scoring function, specifically including:

[0040] Based on the cached instance specification metadata, the set of all available instance specifications S={s1,s2,…,sn} for the target cloud platform is obtained by filtering according to the regional identifier; each element si in the instance specification set contains at least three attributes: number of CPU cores, memory capacity, and unit price.

[0041] If a performance-first strategy is selected, the sum of the number of CPU cores and the memory capacity will be used as the performance score. All specifications with a performance score greater than or equal to the computing power threshold required for the current load will be selected, sorted in ascending order by unit price, and the specification with the highest performance score and the lowest unit price will be selected as the target instance specification.

[0042] If the cost-first strategy is selected, the cost per unit of computing power is used as the cost score, and the specification with the lowest cost score is selected as the target instance specification.

[0043] If a hybrid strategy is selected, a performance score is calculated based on the computing power value, a cost score is calculated based on the unit computing power cost, and a weighted sum of the performance score and cost score is obtained based on the hybrid weight coefficient. The specification with the highest comprehensive score is selected as the target instance specification.

[0044] Secondly, the technical solution of the present invention provides a multi-cloud virtual machine elastic scaling system based on Terraform, comprising:

[0045] The basic parameter synchronization module is used to periodically synchronize the basic parameters of each cloud platform to the local cache database. The basic parameters include instance specifications, availability zones, and pricing metadata.

[0046] The resource performance index acquisition module is used to call the monitoring interfaces of various cloud platforms in real time to collect the resource performance indexes of the cloud platforms, unify the units and standardize the format of heterogeneous data, and generate time-series monitoring datasets.

[0047] The scaling instruction generation module is used to generate scaling instructions containing the target number of instances, target instance specifications, and target cloud platform based on the real-time load status reflected by the time-series monitoring dataset and in combination with preset cost-first, performance-first, or hybrid strategies.

[0048] The variable file generation module is used to select the corresponding cloud platform resource configuration template from the preset template library according to the target instance specifications in the scaling instruction, and inject the target instance quantity and availability zone parameters into the selected resource configuration template to generate a variable file;

[0049] The resource scaling module is used to call the Terraform interface plugin to load the selected resource configuration template and the variable file, generate an infrastructure change plan through a resource change pre-verification command, and execute the resource change execution command to complete the resource scaling.

[0050] Thirdly, the technical solution of the present invention provides a terminal, comprising:

[0051] Storage, used to store Terraform-based multi-cloud virtual machine elastic scaling programs;

[0052] A processor is configured to implement the steps of the Terraform-based multi-cloud virtual machine elastic scaling method as described above when executing the Terraform-based multi-cloud virtual machine elastic scaling program.

[0053] Fourthly, the present invention provides a computer-readable storage medium storing a Terraform-based multi-cloud virtual machine elastic scaling program, wherein the Terraform-based multi-cloud virtual machine elastic scaling program, when executed by a processor, implements the steps of the Terraform-based multi-cloud virtual machine elastic scaling method as described in any of the above claims.

[0054] As can be seen from the above technical solutions, this application has the following advantages:

[0055] 1. This application unifies the scattered heterogeneous basic parameters into a real-time, standardized data view by periodically synchronizing the instance specifications, availability zones, and pricing metadata of each cloud platform and caching them to a local database. This directly eliminates script fragmentation caused by API differences and significantly reduces the complexity of operation and maintenance in a multi-cloud environment.

[0056] 2. This application generates a time-series monitoring dataset by collecting and uniformly formatting various cloud monitoring metrics in real time, enabling key metrics such as CPU and memory to be aggregated at the second level under the same semantics. The policy engine can then instantly identify overload or idleness, thereby improving the overall resource utilization.

[0057] 3. This application calculates the target instance quantity, specifications, and target cloud platform in real time based on unified monitoring data and price metadata, according to cost-first / performance-first / hybrid strategies, to achieve dual-objective optimization of cost and performance, and supports dynamic switching between any compliant cloud, completely avoiding vendor lock-in;

[0058] 4. This application generates a variable file by selecting the corresponding template from the pre-set template library according to the scaling instructions and injecting variables, encapsulating cloud differences into a reusable module. Any changes in specifications or quantities are completed within the same code baseline, reducing manual editing errors and compressing the time taken for elastic operations from hours to minutes.

[0059] 5. This application generates a change plan by calling the Terraform interface plugin to execute a pre-verification command. After passing the verification, the change command is executed to complete the scaling up or down. The plan-preview and automatic rollback mechanism eliminates configuration conflicts and quota risks before formal execution, achieving a secure, reliable, and auditable unified orchestration closed loop. Attached Figure Description

[0060] To more clearly illustrate the technical solution of this application, the accompanying drawings used in the description will be briefly introduced below. Obviously, the accompanying 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.

[0061] Figure 1 This is a schematic diagram of a multi-cloud virtual machine elastic scaling method based on Terraform, provided as an embodiment of the present invention.

[0062] Figure 2 This is a schematic block diagram of a multi-cloud virtual machine elastic scaling system based on Terraform, provided as an embodiment of the present invention.

[0063] Figure 3 This is a schematic diagram of the structure of a terminal provided in an embodiment of the present invention. Detailed Implementation

[0064] To make the purpose, features, and advantages of this application more apparent and understandable, specific embodiments and accompanying drawings will be used to clearly and completely describe the technical solution protected by this application. Obviously, the embodiments described below are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0065] Unless otherwise defined, all technical and scientific terms used in this application have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used in this application and in the specification of this invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention.

[0066] The key terms used in this invention will be explained below.

[0067] Terraform is an open-source Infrastructure as Code (IaC) tool developed by HashiCorp for securely and efficiently building, changing, and managing cloud infrastructure. It defines resource topologies through declarative configuration files, supports resource orchestration in multi-cloud environments, and can automatically handle dependencies, enabling lifecycle management of infrastructure.

[0068] Terraform Provider: A plugin for Terraform to interface with specific cloud vendors or services, used to abstract the API differences between different cloud platforms. Each Provider encapsulates the resource types and operation interfaces of the target platform.

[0069] tfvar files: Terraform Variables files are configuration files used for dynamically injecting variable values. In Terraform templates, variables (such as the number of instances, specifications) are defined in variables.tf, while tfvar files (such as auto_generated.tfvars) provide the actual values ​​for these variables.

[0070] Terraform plan: A resource change pre-verification command, a pre-execution analysis instruction for Infrastructure as Code (IaC) used to parse the differences between the Terraform configuration file (.tf file) and the current resource state (tfstate) and generate a detailed plan of the operations to be performed.

[0071] Terraform apply: Resource change execution command, an infrastructure orchestration instruction that, based on the change plan generated by Terraformplan, actually calls the cloud service provider's API to execute resource operations, so that the infrastructure reaches the target state defined in the configuration file.

[0072] Figure 1 This is a schematic diagram illustrating a multi-cloud virtual machine elastic scaling method based on Terraform, provided as an embodiment of the present invention. Figure 1 The executing entity can be a Terraform-based multi-cloud virtual machine elastic scaling system. The Terraform-based multi-cloud virtual machine elastic scaling method provided in this embodiment is executed by a computer device; correspondingly, the Terraform-based multi-cloud virtual machine elastic scaling system runs on the computer device. Depending on different requirements, the order of the steps in this flowchart can be changed, and some steps can be omitted.

[0073] like Figure 1 As shown, the method includes the following steps.

[0074] S1 periodically synchronizes the basic parameters of each cloud platform to the local cache database. The basic parameters include instance specifications, availability zones, and pricing metadata.

[0075] It connects with various cloud providers (such as AWS and Alibaba Cloud) via Web API or console interface to automatically complete account registration and API Key generation. The generated API Key is stored using HashiCorp Vault encryption, supports AES-256-GCM symmetric encryption and key rotation, and is managed hierarchically by provider and region.

[0076] Using the encrypted storage API Key as the access token, the system periodically pulls the availability zone list, instance specification metadata, and pricing table of various cloud vendors, updates them to the local cache, and adopts an incremental update and failure retry mechanism (up to 3 times) to ensure the real-time nature of the metadata.

[0077] Instance specifications refer to the hardware configuration parameters of virtual machines (or cloud servers) provided by cloud service providers, which typically include: computing resources (number of vCPUs, processor model, etc.), memory capacity, storage type (local SSD, cloud disk, NVMe, etc.), network performance (such as intranet bandwidth, maximum number of concurrent connections), and GPU / accelerator support (such as NVIDIA T4, A100, etc.).

[0078] An availability zone is a physical data center isolated within the same region by a cloud service provider. It has independent power, network, and cooling systems to achieve high availability and disaster recovery, avoid single points of failure, and allow users to distribute instances across multiple availability zones to improve business continuity.

[0079] Price metadata refers to the billing information for instance specifications provided by cloud service providers, including: pay-as-you-go (price per hour or per second), reserved instances (long-term reserved discounted prices), spot instances (dynamic bidding prices), and bandwidth / storage surcharges (such as outbound traffic fees and cloud disk storage fees).

[0080] Synchronously caching this information can unify the view of multi-cloud resources, eliminate the differences in APIs among cloud vendors, provide a consistent resource query interface, and provide a data foundation for elastic scaling strategies (such as cost optimization and performance priority).

[0081] S2 calls the monitoring interfaces of various cloud platforms in real time to collect the resource performance indicators of the cloud platforms, unifies the units and standardizes the format of heterogeneous data, and generates a time-series monitoring dataset.

[0082] Resource performance metrics include computing resource metrics, workload metrics, and cloud service provider-specific metrics. Computing resource metrics include average CPU utilization (%), average memory utilization (%), disk I / O throughput (MB / s), and network inbound / outbound bandwidth. Workload metrics include requests per second and application response latency. Cloud service provider-specific metrics include, for example, the vCPU utilization of Alibaba Cloud ECS.

[0083] S3. Based on the real-time load status reflected in the time-series monitoring dataset, and combined with preset cost-priority, performance-priority, or hybrid strategies, generate scaling instructions that include the target number of instances, target instance specifications, and target cloud platform.

[0084] S4. Based on the target instance specifications in the scaling instruction, select the corresponding cloud platform resource configuration template from the preset template library, and inject the target instance quantity and availability zone parameters into the selected resource configuration template to generate a variable file.

[0085] S5, call the Terraform docking plugin to load the selected resource configuration template and the variable file, generate an infrastructure change plan through the resource change pre-verification command, and execute the resource change execution command to complete the resource scaling up or down when the verification passes.

[0086] In some optional implementations, the time-series monitoring dataset reflects the real-time load status, specifically including: a pre-configured time window length; calculating the average, peak, and standard deviation of various resource performance indicators in the time-series monitoring dataset based on the time window length; if all calculation results are within the corresponding threshold, the real-time load status is marked as a normal load status; if the target calculation result of any target indicator exceeds the warning threshold, the real-time load status is marked as a critical load status; if the target calculation result of any target indicator exceeds the safety threshold, the real-time load status is marked as an overload status.

[0087] Taking the CPU and memory utilization of virtual machines on a cloud platform as core resource performance indicators, this paper explains the process by which time-series monitoring datasets reflect real-time load status. A pre-configured time window of 5 minutes is used. Within this window, the system continuously collects the CPU and memory utilization of the target virtual machine. After obtaining the time-series monitoring data, the following results are calculated: the average CPU utilization is 65%, the peak is 72%, and the standard deviation is 5%; the average memory utilization is 60%, the peak is 68%, and the standard deviation is 4%.

[0088] The warning threshold for CPU utilization is 70%, and the safe threshold is 85%; the warning threshold for memory utilization is 75%, and the safe threshold is 90%. Since the average, peak, and standard deviation of the above CPU and memory utilization do not exceed the warning thresholds for the corresponding indicators, the system marks the real-time load status of this virtual machine as a normal load state.

[0089] If, within another 5-minute time window, the calculated metrics are: CPU utilization average 72%, peak 78%, standard deviation 6%; memory utilization average 70%, peak 74%, standard deviation 5%. At this point, both the average CPU utilization of 72% and the peak of 78% exceed the warning threshold of 70%, while none of the memory utilization metrics exceed the warning threshold of 75%. Because the calculated result of any target metric (CPU utilization) exceeds the warning threshold, the system marks the real-time load state as a critical load state.

[0090] If, within another 5-minute time window, the calculated metrics are: CPU utilization average 88%, peak 92%, standard deviation 7%; memory utilization average 85%, peak 89%, standard deviation 6%. Since both the average CPU utilization of 88% and the peak CPU utilization of 92% exceed the safety threshold of 85%, even if the memory utilization metrics do not exceed the safety threshold of 90%, the system marks the real-time load state as overloaded because any one of the target metrics (CPU utilization) exceeds the safety threshold.

[0091] In some optional implementations, step S3 combines preset cost-priority, performance-priority, or hybrid strategies to generate scaling instructions that include the target number of instances, target instance specifications, and target cloud platform, specifically including the following steps.

[0092] S3.1 Select a strategy based on the real-time load status. When marked as overloaded, force the performance priority strategy to be enabled. When marked as critical load, if the budget consumption rate is not lower than the preset consumption rate threshold, enable the cost priority strategy; otherwise, enable the hybrid strategy. When marked as normal load, if the current business is in a peak period, enable the hybrid strategy; otherwise, enable the cost priority strategy.

[0093] Budget consumption rate refers to the proportion of resource costs used in the current period to the total budget, used to quantify cost control status. Its calculation depends on the price metadata and real-time resource usage synchronized in step S1.

[0094] Budget consumption rate = (Actual expenditure in the current period / Total budget in the current period) * 100%

[0095] Actual expenditure can be expressed as the product of the instance price per instance within the period and the runtime of the corresponding instance, plus additional fees. Additional fees include storage fees, network traffic fees, and other charges.

[0096] S3.2, based on the selected strategy type, call the corresponding strategy weight function to calculate the strategy weight factor, and input the strategy weight factor and time series monitoring dataset into the strategy decision engine to calculate the initial target instance number for each cloud platform.

[0097] S3.2.1, Call the corresponding strategy weight function to calculate the strategy weight factor according to the selected strategy type.

[0098] Specifically, if a performance-first strategy is selected, the ratio of peak CPU utilization to the maximum computing power of the instance specification is used as the performance weight, and the unit price of the instance per unit time is used as the cost weight. The two are weighted and summed to obtain the performance weight coefficient. If a cost-first strategy is selected, the unit computing power cost is used as the cost weight, and the performance degradation tolerance threshold is used as the performance weight. The two are weighted and summed to obtain the cost weight coefficient. If a hybrid strategy is selected, the performance weight and cost weight are dynamically balanced according to the preset business peak weight factor to obtain the hybrid weight coefficient.

[0099] The preset peak traffic weighting factor λ is read from the scaling strategy configuration, where 0 ≤ λ ≤ 1. This weighting factor is preset by the user based on the characteristics of the traffic load and is used to distinguish the strategy preferences between peak and off-peak periods.

[0100] Based on the peak business weight factor λ, calculate the performance weight wperf=λ and the cost weight wcost=1-λ.

[0101] S3.2.2, map the performance weight coefficient, cost weight coefficient, or mixed weight coefficient to a preset weight-instance number conversion table to obtain the baseline instance increment ΔNbase corresponding to the weight coefficient; wherein, the weight-instance number conversion table records the discrete correspondence between the weight coefficient range and the baseline instance increment, and the same weight coefficient range corresponds to different ΔNbase values ​​under different strategy types.

[0102] S3.2.3, based on the time-series monitoring dataset, performs sliding time window aggregation operations on the average CPU utilization and average memory utilization to obtain the CPU sliding mean μCPU, the memory sliding mean μMEM, the CPU peak value PCPU, and the memory peak value PMEM.

[0103] S3.2.4, let the target thresholds of μCPU, μMEM, PCPU, and PMEM be TCPU, TMEM, TCPU_peak, and TMEM_peak, respectively. Calculate the load deviation factor β using the following formula.

[0104]

[0105] If β≤0, then let β=0.

[0106] S3.2.5, calculate the initial target number of cloud platform instances Ninit using the following formula:

[0107] Ninit=Ncurrent+round(ΔNbase×(1+β));

[0108] Where Ncurrent is the number of actual running instances on the cloud platform at the current moment, and round() is the rounding function.

[0109] When the calculated Ninit is less than the minimum instance number threshold Nmin of the corresponding cloud platform, let Ninit = Nmin; when Ninit is greater than the maximum instance number threshold Nmax of the corresponding cloud platform, let Ninit = Nmax.

[0110] S3.3 Calculate the estimated total cost for each cloud platform based on the initial target instance count and cached price metadata, and eliminate cloud platforms whose estimated total cost exceeds the budget limit threshold to obtain a candidate cloud platform list.

[0111] Based on the price metadata synchronized and cached in step S1, query the hourly unit price (Price) of the target instance specification in the corresponding region of each candidate cloud platform. i , where i represents the i-th candidate cloud platform. Based on the initial target number of instances Niniti, the estimated total cost (TotalCost) for each candidate cloud platform is calculated. i :

[0112] TotalCost i =Price i ×Ninit i ×Duration

[0113] Duration is the estimated scaling duration in hours, which is preset by the user in the scaling policy or dynamically estimated based on historical load patterns.

[0114] The estimated total cost of each candidate cloud platform is compared with the user's preset budget limit, Threshold. If TotalCost ≤ Threshold, the cloud platform proceeds to the next step of availability score calculation. If TotalCost > Threshold, the cloud platform is removed from the candidate list to avoid resource waste due to cost overruns.

[0115] S3.4 Based on the network latency, historical failure rate and the remaining capacity of the synchronized availability zone for each region in the candidate cloud platform list, calculate the availability score of the candidate cloud platform, select the candidate cloud platform with the highest score as the final target cloud platform, and determine the corresponding initial target instance number as the final target instance number.

[0116] S3.4.1, collect the round-trip time (RTT) from the service exit to the nearest access point of the candidate cloud platform; based on the preset target latency threshold Tlatency, if RTT≤Tlatency, then the network latency score LatencyScore=100; if RTT>Tlatency, then the network latency score LatencyScore=100×(Tlatency / RTT).

[0117] Business egress refers to the starting point from which a business system initiates network requests to the outside world; that is, the network interface or gateway through which the business system communicates with external networks (including cloud platforms). Specifically, it typically refers to the egress network interface of the local data center, private cloud environment, or edge computing node where the business system resides.

[0118] S3.4.2, Read the instance-level failure rate FR of the candidate cloud platform in the past statistical period; based on the acceptable failure rate threshold TFR, if FR≤TFR, then the historical failure rate score FaultScore=100; if FR>TFR, then the historical failure rate score FaultScore=100×(TFR / FR).

[0119] S3.4.3, based on the synchronized remaining capacity of the availability zone, calculate the schedulable capacity ratio CR of the candidate cloud platform in the target area to meet the required instance specifications; if CR ≥ required capacity, then the remaining capacity score of the availability zone CapacityScore = 100; if CR < required capacity, then the remaining capacity score of the availability zone CapacityScore = 100 × (CR / required capacity).

[0120] S3.4.4 calculates a weighted sum of the network latency score, historical failure rate score, and remaining availability zone capacity score to obtain the availability score of the candidate cloud platform.

[0121] The weights for each item are configured by the user.

[0122] S3.5, Invoke the specification scoring function of the corresponding strategy according to the selected strategy type, and determine the target instance specification of the final target cloud platform based on the specification scoring function.

[0123] S3.5.1, based on the cached instance specification metadata, filter according to the region identifier of the target cloud platform to obtain the set of all available instance specifications S={s1,s2,…,sn} in the region; each element si in the instance specification set contains at least three attributes: number of CPU cores, memory capacity and unit price.

[0124] S3.5.2 If a performance-first strategy is selected, the sum of the number of CPU cores and the memory capacity is used as the performance score. All specifications with a performance score greater than or equal to the computing power threshold required for the current load are selected, sorted in ascending order by unit price, and the specification with the highest performance score and the lowest unit price is selected as the target instance specification.

[0125] S3.5.3 If the cost-first strategy is selected, the unit computing power cost is used as the cost score, and the specification with the lowest cost score is selected as the target instance specification.

[0126] S3.5.4 If a hybrid strategy is selected, the performance score is calculated based on the computing power value, the cost score is calculated based on the unit computing power cost, and the performance score and cost score are weighted and summed according to the hybrid weight coefficient to obtain a comprehensive score. The specification with the highest comprehensive score is selected as the target instance specification.

[0127] The base computing power value BasePerf = α1 × CPUcore + α2 × MEMsize, where CPUcore is the number of vCPU cores of the candidate specification si, MEMsize is the memory capacity of the candidate specification si in GiB; α1 and α2 are preset weight coefficients, satisfying α1 + α2 = 1.

[0128] Calculate the specification-load matching coefficient γ based on the real-time peak load PCPU and PMEM and the specification upper limits CPUcore and MEMsize:

[0129] γ=min{CPUcore / PCPU,MEMsize / PMEM}

[0130] If γ≥1, it indicates that the specifications can meet the peak load, so let γ=1; if γ<1, it indicates that there is a bottleneck in the specifications, so keep γ at its original value.

[0131] Performance Score The value is rounded down to the nearest integer.

[0132] Unit cost of computing power is calculated as UnitCost = Price / BasePerf, where Price is the hourly unit price of candidate specification si, in yuan / hour.

[0133] To ensure that lower costs result in higher scores, a reverse mapping is performed on UnitCost:

[0134] CostScore=round(100×(UnitCost_max-UnitCost) / (UnitCost_max-UnitCost_min))

[0135] UnitCost_max and UnitCost_min are the highest and lowest unit computing power costs for all candidate specifications in the compliant cloud platform list, respectively; the CostScore result is rounded to the nearest integer, ranging from [0, 100].

[0136] Using the hybrid weighting coefficients wperf and wcost determined in step S3.2.1 as weights, calculate the comprehensive score:

[0137] CompositeScore=wperf×PerfScore+wcost×CostScore

[0138] Where wperf+wcost=1, and wperf and wcost are given in real time by the mixed weight coefficients.

[0139] S3.6, construct scaling instructions that include the target number of instances, the target instance specifications, and the target cloud platform.

[0140] In this embodiment, the resource configuration templates are standardized Terraform templates pre-installed in the template library, used to define resource configurations on specific cloud platforms. Each template encapsulates the resource definition syntax and parameter structure for the corresponding cloud platform, ensuring API compatibility with the target cloud platform. Through the pre-installed resource configuration templates and dynamically generated variable files, the system can quickly and accurately map the target instance specifications and quantity in scaling instructions to specific cloud platform resource configurations, ensuring that the Terraform orchestration engine can efficiently execute resource scaling operations.

[0141] In some alternative implementations, step S4 includes the following steps.

[0142] S4.1, Resource Configuration Template Selection Sub-step.

[0143] Read the target instance specifications and target cloud platform information from the scaling command. From the pre-configured template library, select the corresponding cloud platform resource configuration template based on the target cloud platform identifier. Verify the completeness and validity of the selected resource configuration template, ensuring that the template contains all necessary resource definitions and parameter fields.

[0144] S4.2, Variable file generation sub-step.

[0145] Extract the target instance count and availability zone parameters from the scaling command. Based on the variable definitions of the selected resource configuration template, inject the target instance count and availability zone parameters into the template's variable file. The variable file uses Terraform's terraform.tfvars format to ensure Terraform can correctly parse and use these parameters.

[0146] The generated variable file contains the following:

[0147] instance_type: Target instance size, such as ecs.g7.large;

[0148] desired_count: The target number of instances;

[0149] availability_zone: Target availability zone.

[0150] Save the generated variable file to the specified directory for subsequent use by the Terraform orchestration engine.

[0151] In some alternative implementations, step S5 specifically includes the following steps.

[0152] S5.1, Terraform initialization.

[0153] The Terraform initialization command `terraforminit` is invoked. This command initializes the Terraform working directory, loads the selected resource configuration template and its dependencies, and ensures that all necessary plugins and modules are correctly configured.

[0154] S5.2, Resource Change Pre-verification.

[0155] The Terraform planning command is invoked to generate an infrastructure change plan, `terraformplan-out=tfplan`. This command generates a detailed resource change plan based on the selected resource configuration template and injected variable files, including a list of resources to be created, modified, or destroyed. The generated change plan file, `tfplan`, is checked to ensure its content meets expectations, including whether resource quantities, specifications, and network configurations are consistent with scaling instructions. If conflicts or errors exist in the change plan (such as insufficient resource quotas or network configuration conflicts), detailed error information is recorded, and a rollback mechanism is triggered to terminate subsequent execution processes, ensuring system consistency and security.

[0156] S5.3, Resource Change Execution.

[0157] If the pre-validation passes, the Terraform application command `terraformapplytfplan` is invoked to execute resource changes. This command, based on the pre-validated change plan file `tfplan`, actually performs resource creation, modification, or destruction operations, completing the resource scaling.

[0158] Monitor log output during execution to ensure smooth resource change operations. If any exception occurs during execution (such as network interruption, API call failure, etc.), immediately trigger the rollback mechanism, calling the Terraform destruction command terraformdestroy to roll back the resource state to its stable state before the change, avoiding business interruption caused by inconsistent resource states.

[0159] By following the steps above, we can ensure that the correctness and feasibility of the change plan are verified through a pre-verification mechanism before performing resource scaling operations, thereby completing the dynamic adjustment of resources under the premise of safety and reliability.

[0160] The foregoing has described in detail an embodiment of a Terraform-based multi-cloud virtual machine elastic scaling method. Based on the Terraform-based multi-cloud virtual machine elastic scaling method described in the above embodiment, this invention also provides a Terraform-based multi-cloud virtual machine elastic scaling system corresponding to the method.

[0161] Figure 2 This invention provides a schematic block diagram of a Terraform-based multi-cloud virtual machine elastic scaling system. In this embodiment, the Terraform-based multi-cloud virtual machine elastic scaling system 200 can be divided into multiple functional modules according to its functions. A module, as referred to in this invention, is a series of computer program segments that can be executed by at least one processor and perform a fixed function, and is stored in memory.

[0162] The basic parameter synchronization module 210 is used to periodically synchronize the basic parameters of each cloud platform to the local cache database. The basic parameters include instance specifications, availability zones, and price metadata.

[0163] The resource performance index acquisition module 220 is used to call the monitoring interfaces of various cloud platforms in real time to collect the resource performance indexes of the cloud platforms, unify the units and standardize the format of heterogeneous data, and generate a time-series monitoring dataset.

[0164] The scaling instruction generation module 230 is used to generate scaling instructions containing the target number of instances, the target instance specifications, and the target cloud platform based on the real-time load status reflected by the time-series monitoring dataset and in combination with preset cost-priority, performance-priority, or hybrid strategies.

[0165] The variable file generation module 240 is used to select the corresponding cloud platform resource configuration template from the preset template library according to the target instance specifications in the scaling instruction, and inject the target instance quantity and availability zone parameters into the selected resource configuration template to generate a variable file.

[0166] The resource scaling module 250 is used to call the Terraform interface plugin to load the selected resource configuration template and the variable file, generate an infrastructure change plan through the resource change pre-verification command, and execute the resource change execution command to complete the resource scaling.

[0167] The Terraform-based multi-cloud virtual machine elastic scaling system of this embodiment is used to implement the aforementioned Terraform-based multi-cloud virtual machine elastic scaling method. Therefore, the specific implementation of this system can be found in the embodiment section of the Terraform-based multi-cloud virtual machine elastic scaling method above. Thus, the specific implementation can be referred to the description of the corresponding embodiments, and will not be elaborated here.

[0168] Furthermore, since the Terraform-based multi-cloud virtual machine elastic scaling system in this embodiment is used to implement the aforementioned Terraform-based multi-cloud virtual machine elastic scaling method, its function corresponds to the function of the above method, and will not be repeated here.

[0169] Figure 3 This is a schematic diagram of a terminal 300 provided in an embodiment of the present invention, including: a processor 310, a memory 320, and a communication unit 330. The processor 310 is used to implement the process steps of the above-described embodiment of the Terraform-based multi-cloud virtual machine elastic scaling method when implementing the Terraform-based multi-cloud virtual machine elastic scaling program stored in the memory 320.

[0170] The terminal 300 includes a processor 310, a memory 320, and a communication unit 330. These components communicate via one or more buses. Those skilled in the art will understand that the server structure shown in the figure does not constitute a limitation of the present invention. It can be a bus topology or a star topology, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0171] The memory 320 can be used to store the execution instructions of the processor 310. The memory 320 can be implemented by any type of volatile or non-volatile memory terminal or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. When the execution instructions in the memory 320 are executed by the processor 310, the terminal 300 is able to perform some or all of the steps in the above method embodiments.

[0172] The processor 310 serves as the control center of the storage terminal, connecting various parts of the electronic terminal via various interfaces and lines. It executes software programs and / or modules stored in the memory 320, and calls data stored in the memory to perform various functions of the electronic terminal and / or process data. The processor can be composed of integrated circuits (ICs), such as a single packaged IC or multiple packaged ICs with the same or different functions connected together. For example, the processor 310 may consist only of a central processing unit (CPU). In this embodiment of the invention, the CPU may have a single processing core or include multiple processing cores.

[0173] The communication unit 330 is used to establish a communication channel, enabling the storage terminal to communicate with other terminals. It can receive user data sent by other terminals or send user data to other terminals.

[0174] The present invention also provides a computer storage medium, wherein the storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM) or a random access memory (RAM), etc.

[0175] The present invention also provides a computer storage medium, wherein the storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM) or a random access memory (RAM), etc.

[0176] The computer storage medium stores a Terraform-based multi-cloud virtual machine elastic scaling program. When the Terraform-based multi-cloud virtual machine elastic scaling program is executed by the processor, it implements the process steps of the above-described Terraform-based multi-cloud virtual machine elastic scaling method embodiment.

[0177] Those skilled in the art will clearly understand that the techniques in the embodiments of the present invention can be implemented using software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solutions in the embodiments of the present invention, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium such as a USB flash drive, mobile hard drive, read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk, or other media capable of storing program code. It includes several instructions to cause a computer terminal (which may be a personal computer, server, or a second terminal, network terminal, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0178] In the embodiments provided by this invention, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0179] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0180] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0181] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for elastic scaling of multi-cloud virtual machines based on Terraform, characterized in that, Includes the following steps: Periodically synchronize basic parameters of each cloud platform to the local cache database. These basic parameters include instance specifications, availability zones, and pricing metadata. Real-time calls to the monitoring interfaces of various cloud platforms to collect resource performance indicators of the cloud platforms, unify the units and standardize the format of heterogeneous data, and generate time-series monitoring datasets; Based on the real-time load status reflected by the time-series monitoring dataset, and combined with preset cost-first, performance-first, or hybrid strategies, scaling instructions containing the target number of instances, target instance specifications, and target cloud platform are generated. Based on the target instance specifications in the scaling instruction, select the corresponding cloud platform resource configuration template from the preset template library, and inject the target instance quantity and availability zone parameters into the selected resource configuration template to generate a variable file; The Terraform integration plugin is invoked to load the selected resource configuration template and the variable file. An infrastructure change plan is generated through a resource change pre-verification command. When the verification passes, the resource change execution command is executed to complete the resource scaling up or down. The time-series monitoring dataset reflects the real-time load status and specifically includes: The pre-configured time window length is used to calculate the average, peak, and standard deviation of various resource performance indicators in the time-series monitoring dataset based on this time window length. If the average, peak, and standard deviation of CPU utilization and memory utilization do not exceed the warning threshold of the corresponding indicators, the real-time load status is marked as normal load status. If the target calculation result of any target indicator exceeds the warning threshold, the real-time load status is marked as critical load status. If the target calculation result of any target indicator exceeds the safety threshold, the real-time load status is marked as overload status. Specifically, it generates scaling instructions that include the target number of instances, target instance specifications, and target cloud platform, based on preset cost-first, performance-first, or hybrid strategies. The strategy is selected based on the real-time load status. When the state is marked as overload, the performance priority strategy is forcibly enabled. When the state is marked as critical load, if the budget consumption rate is not lower than the preset consumption rate threshold, the cost priority strategy is enabled; otherwise, the hybrid strategy is enabled. When the state is marked as normal load, if the current business peak period is in effect, the hybrid strategy is enabled; otherwise, the cost priority strategy is enabled. The strategy weight factor is calculated by calling the corresponding strategy weight function based on the selected strategy type. The strategy weight factor and the time-series monitoring dataset are then input into the strategy decision engine to calculate the initial target number of instances for each cloud platform. Based on the initial target number of instances and the cached price metadata, calculate the estimated total cost for each cloud platform, and eliminate cloud platforms whose estimated total cost exceeds the budget limit threshold to obtain a list of candidate cloud platforms. Based on the network latency, historical failure rate, and synchronized remaining capacity of the availability zone for each region in the candidate cloud platform list, calculate the availability score of the candidate cloud platform, select the candidate cloud platform with the highest score as the final target cloud platform, and determine the corresponding initial target instance number as the final target instance number. The specification scoring function of the corresponding strategy is invoked according to the selected strategy type, and the target instance specification of the final target cloud platform is determined based on the specification scoring function. Build scaling instructions that include the target number of instances, the target instance specifications, and the target cloud platform; Specifically, the strategy weight factor is calculated by calling the corresponding strategy weight function based on the selected strategy type, including: If a performance-first strategy is selected, the ratio of peak CPU utilization to the maximum computing power of the instance specification is used as the performance weight, and the unit price of the instance per unit time is used as the cost weight. The two are weighted and summed to obtain the performance weight coefficient. If a cost-first strategy is selected, the unit computing power cost is used as the cost weight, and the performance degradation tolerance threshold is used as the performance weight. The two are weighted and summed to obtain the cost weight coefficient. If a hybrid strategy is selected, the performance weight and cost weight are dynamically balanced according to the preset business peak weight factor to obtain the hybrid weight coefficient. Specifically, the strategy weighting factor and time-series monitoring dataset are input into the strategy decision engine to calculate the initial target number of instances for each cloud platform, including: The performance weight coefficient, cost weight coefficient, or hybrid weight coefficient is mapped to a preset weight-instance number conversion table to obtain the baseline instance increment ΔNbase corresponding to the weight coefficient; wherein, the weight-instance number conversion table records the discrete correspondence between the weight coefficient range and the baseline instance increment, and the same weight coefficient range corresponds to different ΔNbase values ​​under different strategy types. Based on the time-series monitoring dataset, sliding time window aggregation operations are performed on the average CPU utilization and average memory utilization to obtain the CPU sliding mean μCPU, the memory sliding mean μMEM, the CPU peak PCPU, and the memory peak PMEM. Let the target thresholds for μCPU, μMEM, PCPU, and PMEM be TCPU, TMEM, TCPU_peak, and TMEM_peak, respectively. Calculate the load deviation factor β using the following formula: β=max[(μCPU-TCPU) / TCPU,(μMEM-TMEM) / TMEM,(PCPU-TCPU_peak) / TCPU_peak,(PMEM-TMEM_peak) / TMEM_peak]; If β≤0, then let β=0; The initial target number of instances Ninit for the cloud platform is calculated using the following formula: Ninit=Ncurrent+round(ΔNbase×(1+β)); Where Ncurrent is the actual number of running instances on the cloud platform at the current moment, and round() is the rounding function; When the calculated Ninit is less than the minimum instance number threshold Nmin of the corresponding cloud platform, let Ninit = Nmin; when Ninit is greater than the maximum instance number threshold Nmax of the corresponding cloud platform, let Ninit = Nmax.

2. The Terraform-based multi-cloud virtual machine elastic scaling method according to claim 1, characterized in that, Based on the network latency, historical failure rate, and synchronized remaining capacity of the availability zone for each region in the candidate cloud platform list, an availability score is calculated for the candidate cloud platforms, specifically including: The round-trip time (RTT) from the business exit to the nearest access point of the candidate cloud platform is collected. Based on the preset target latency threshold Tlatency, if RTT≤Tlatency, the network latency score LatencyScore=100; if RTT>Tlatency, the network latency score LatencyScore=100×(Tlatency / RTT). Read the instance-level failure rate (FR) of the candidate cloud platform in the past statistical period; based on the acceptable failure rate threshold (TFR), if FR≤TFR, then the historical failure rate score FaultScore=100; if FR>TFR, then the historical failure rate score FaultScore=100×(TFR / FR). Based on the synchronized remaining capacity of the availability zone, calculate the schedulable capacity ratio (CR) of the candidate cloud platform in the target area to meet the required instance specifications; if CR ≥ required capacity, then the remaining capacity score of the availability zone, CapacityScore = 100; if CR < required capacity, then the remaining capacity score of the availability zone, CapacityScore = 100 × (CR / required capacity). The availability score of the candidate cloud platform is obtained by weighting and summing the network latency score, historical failure rate score, and remaining capacity score of the availability zone.

3. The Terraform-based multi-cloud virtual machine elastic scaling method according to claim 1, characterized in that, The specification scoring function of the corresponding strategy is invoked based on the selected strategy type. The final target instance specification of the target cloud platform is determined based on the specification scoring function, specifically including: Based on the cached instance specification metadata, the set of all available instance specifications S={s1,s2,…,sn} for the target cloud platform is obtained by filtering according to the regional identifier; each element si in the instance specification set contains at least three attributes: number of CPU cores, memory capacity, and unit price. If a performance-first strategy is selected, the sum of the number of CPU cores and the memory capacity will be used as the performance score. All specifications with a performance score greater than or equal to the computing power threshold required for the current load will be selected, sorted in ascending order by unit price, and the specification with the highest performance score and the lowest unit price will be selected as the target instance specification. If the cost-first strategy is selected, the cost per unit of computing power is used as the cost score, and the specification with the lowest cost score is selected as the target instance specification. If a hybrid strategy is selected, a performance score is calculated based on the computing power value, a cost score is calculated based on the unit computing power cost, and a weighted sum of the performance score and cost score is obtained based on the hybrid weight coefficient. The specification with the highest comprehensive score is selected as the target instance specification.

4. A multi-cloud virtual machine elastic scaling system based on Terraform, characterized in that, include: The basic parameter synchronization module is used to periodically synchronize the basic parameters of each cloud platform to the local cache database. The basic parameters include instance specifications, availability zones, and pricing metadata. The resource performance index acquisition module is used to call the monitoring interfaces of various cloud platforms in real time to collect the resource performance indexes of the cloud platforms, unify the units and standardize the format of heterogeneous data, and generate time-series monitoring datasets. The scaling instruction generation module is used to generate scaling instructions containing the target number of instances, target instance specifications, and target cloud platform based on the real-time load status reflected by the time-series monitoring dataset and in combination with preset cost-first, performance-first, or hybrid strategies. The variable file generation module is used to select the corresponding cloud platform resource configuration template from the preset template library according to the target instance specifications in the scaling instruction, and inject the target instance quantity and availability zone parameters into the selected resource configuration template to generate a variable file; The resource scaling module is used to call the Terraform interface plugin to load the selected resource configuration template and the variable file, generate an infrastructure change plan through the resource change pre-verification command, and execute the resource change execution command to complete the resource scaling. The time-series monitoring dataset reflects the real-time load status and specifically includes: The pre-configured time window length is used to calculate the average, peak, and standard deviation of various resource performance indicators in the time-series monitoring dataset based on this time window length. If the average, peak, and standard deviation of CPU utilization and memory utilization do not exceed the warning threshold of the corresponding indicators, the real-time load status is marked as normal load status. If the target calculation result of any target indicator exceeds the warning threshold, the real-time load status is marked as critical load status. If the target calculation result of any target indicator exceeds the safety threshold, the real-time load status is marked as overload status. Specifically, it generates scaling instructions that include the target number of instances, target instance specifications, and target cloud platform, based on preset cost-first, performance-first, or hybrid strategies. The strategy is selected based on the real-time load status. When the state is marked as overload, the performance priority strategy is forcibly enabled. When the state is marked as critical load, if the budget consumption rate is not lower than the preset consumption rate threshold, the cost priority strategy is enabled; otherwise, the hybrid strategy is enabled. When the state is marked as normal load, if the current business peak period is in effect, the hybrid strategy is enabled; otherwise, the cost priority strategy is enabled. The strategy weight factor is calculated by calling the corresponding strategy weight function based on the selected strategy type. The strategy weight factor and the time-series monitoring dataset are then input into the strategy decision engine to calculate the initial target number of instances for each cloud platform. Based on the initial target number of instances and the cached price metadata, calculate the estimated total cost for each cloud platform, and eliminate cloud platforms whose estimated total cost exceeds the budget limit threshold to obtain a list of candidate cloud platforms. Based on the network latency, historical failure rate, and synchronized remaining capacity of the availability zone for each region in the candidate cloud platform list, calculate the availability score of the candidate cloud platform, select the candidate cloud platform with the highest score as the final target cloud platform, and determine the corresponding initial target instance number as the final target instance number. The specification scoring function of the corresponding strategy is invoked according to the selected strategy type, and the target instance specification of the final target cloud platform is determined based on the specification scoring function. Build scaling instructions that include the target number of instances, the target instance specifications, and the target cloud platform; Specifically, the strategy weight factor is calculated by calling the corresponding strategy weight function based on the selected strategy type, including: If a performance-first strategy is selected, the ratio of peak CPU utilization to the maximum computing power of the instance specification is used as the performance weight, and the unit price of the instance per unit time is used as the cost weight. The two are weighted and summed to obtain the performance weight coefficient. If a cost-first strategy is selected, the unit computing power cost is used as the cost weight, and the performance degradation tolerance threshold is used as the performance weight. The two are weighted and summed to obtain the cost weight coefficient. If a hybrid strategy is selected, the performance weight and cost weight are dynamically balanced according to the preset business peak weight factor to obtain the hybrid weight coefficient. Specifically, the strategy weighting factor and time-series monitoring dataset are input into the strategy decision engine to calculate the initial target number of instances for each cloud platform, including: The performance weight coefficient, cost weight coefficient, or hybrid weight coefficient is mapped to a preset weight-instance number conversion table to obtain the baseline instance increment ΔNbase corresponding to the weight coefficient; wherein, the weight-instance number conversion table records the discrete correspondence between the weight coefficient range and the baseline instance increment, and the same weight coefficient range corresponds to different ΔNbase values ​​under different strategy types. Based on the time-series monitoring dataset, sliding time window aggregation operations are performed on the average CPU utilization and average memory utilization to obtain the CPU sliding mean μCPU, the memory sliding mean μMEM, the CPU peak PCPU, and the memory peak PMEM. Let the target thresholds for μCPU, μMEM, PCPU, and PMEM be TCPU, TMEM, TCPU_peak, and TMEM_peak, respectively. Calculate the load deviation factor β using the following formula: β=max[(μCPU-TCPU) / TCPU,(μMEM-TMEM) / TMEM,(PCPU-TCPU_peak) / TCPU_peak,(PMEM-TMEM_peak) / TMEM_peak]; If β≤0, then let β=0; The initial target number of instances Ninit for the cloud platform is calculated using the following formula: Ninit=Ncurrent+round(ΔNbase×(1+β)); Where Ncurrent is the actual number of running instances on the cloud platform at the current moment, and round() is the rounding function; When the calculated Ninit is less than the minimum instance number threshold Nmin of the corresponding cloud platform, let Ninit = Nmin; when Ninit is greater than the maximum instance number threshold Nmax of the corresponding cloud platform, let Ninit = Nmax.

5. A terminal, characterized in that, include: Storage, used to store Terraform-based multi-cloud virtual machine elastic scaling programs; A processor, configured to implement the steps of the Terraform-based multi-cloud virtual machine elastic scaling method as described in any one of claims 1 to 3 when executing the Terraform-based multi-cloud virtual machine elastic scaling program.

6. A computer-readable storage medium, characterized in that, The readable storage medium stores a Terraform-based multi-cloud virtual machine elastic scaling program, which, when executed by a processor, implements the steps of the Terraform-based multi-cloud virtual machine elastic scaling method as described in any one of claims 1 to 3.

Images