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

Abstract

The invention relates to the field of cloud platforms, and particularly provides a Terraform-based multi-cloud virtual machine elastic scaling method and system, a terminal and a medium, and the method comprises the steps: synchronizing basic parameters of each cloud platform; calling each cloud platform monitoring interface in real time to collect resource performance indexes of the cloud platform to generate a time sequence monitoring data set; based on the real-time load state reflected by the data set, generating a scaling instruction in combination with a preset cost priority, performance priority or hybrid strategy; according to a target instance specification in the scaling instruction, selecting a resource configuration template corresponding to the cloud platform from a preset template library, and injecting a target instance number and available region parameters to generate a variable file; and calling Terraform to load the resource configuration template and the variable file on the connector, generating an infrastructure change scheme through a resource change pre-verification command, and executing a resource change execution command to complete resource capacity expansion and contraction. According to the invention, minute-level, low-cost, high-performance and cross-cloud escape closed-loop elastic telescoping is realized.

Description

Technical Field

[0001] The present application relates to the field of cloud platforms, and specifically to a Terraform-based multi-cloud virtual machine elastic scaling method, system, terminal, and medium. Background Art

[0002] In a multi-cloud scenario, the instance specifications, availability zones, and pricing models of various cloud vendors vary significantly, resulting in fragmented basic parameters and insufficient real-time performance. The formats and units of metrics such as CPU and memory returned by the monitoring interface are inconsistent, 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, 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 are made, making it easy for configuration conflicts or quota overruns to occur during execution. This results in high O&M costs, time-consuming capacity expansion, and the risk of being locked into a single cloud vendor. Summary of the Invention

[0003] To solve the above problems, the present invention provides a Terraform-based multi-cloud virtual machine elastic scaling method, system, terminal and medium, which can achieve minute-level, low-cost, high-performance closed-loop elastic scaling with cross-cloud escape.

[0004] In a first aspect, the technical solution of the present invention provides a multi-cloud virtual machine elastic scaling method based on Terraform, comprising the following steps: Periodically synchronize basic parameters of each cloud platform to the local cache database, including instance specifications, availability zones, and price metadata; Call each cloud platform's monitoring interface in real time to collect cloud platform resource performance indicators, unify units and standardize formats for heterogeneous data, and generate time-series monitoring data sets; Based on the real-time load status reflected by the time series monitoring data set, combined with a preset cost priority, performance priority, or hybrid strategy, a scaling instruction including the target number of instances, target instance specifications, and target cloud platform is generated; According to the target instance specifications in the scaling instruction, a resource configuration template corresponding to the cloud platform is selected from a preset template library, and the target instance quantity and availability zone parameters are injected into the selected resource configuration template to generate a variable file; The Terraform docking plug-in is called to load the selected resource configuration template and the variable file. The infrastructure change plan is generated through the resource change pre-verification command. When the verification passes, the resource change execution command is executed to complete resource expansion and contraction.

[0005] In an optional embodiment, the time series monitoring data set reflects the real-time load status and specifically includes: Preconfigure the time window length and calculate the average, peak, and standard deviation of various resource performance indicators in the time series monitoring data set based on the time window length. If all calculation results are for the corresponding thresholds, 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.

[0006] In an optional embodiment, a scaling instruction including the target number of instances, target instance specifications, and target cloud platform is generated in combination with a preset cost priority, performance priority, or hybrid strategy, specifically including: Select a strategy based on the real-time load status. When the system is marked as overloaded, the performance priority strategy is forcibly enabled. When the system 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 system is marked as normal load, if the business is currently at peak hours, the hybrid strategy is enabled. Otherwise, the cost priority strategy is enabled. The corresponding policy weight function is called according to the selected policy type to calculate the policy weight factor. The policy weight factor and the time series monitoring data set are input into the policy decision engine to calculate the initial target number of instances for each cloud platform. Based on the initial target number of instances and cached price metadata, the estimated total cost of each cloud platform is calculated. Cloud platforms with estimated total costs exceeding the upper budget threshold are eliminated to obtain a list of candidate cloud platforms. Based on the network latency, historical failure rate, and remaining capacity of the synchronized availability zones for each region in the candidate cloud platform list, the availability score of the candidate cloud platforms is calculated. The candidate cloud platform with the highest score is selected as the final target cloud platform, and the corresponding initial target instance number is determined as the final target instance number. Call the specification scoring function of the corresponding policy according to the selected policy type, and determine the target instance specifications of the final target cloud platform based on the specification scoring function; Construct a scaling instruction that includes the target number of instances, target instance specifications, and target cloud platform.

[0007] In an optional embodiment, the corresponding policy weight function is called according to the selected policy type to calculate the policy weight factor, specifically including: If the performance priority policy is selected, the ratio of the peak CPU utilization to the upper limit of the instance specification is used as the performance weight, and the instance price per unit time is used as the cost weight. The performance weight coefficient is obtained by weighted summing the two. If the cost priority 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 cost weight coefficient is obtained by weighted summing the two. 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 a hybrid weight coefficient.

[0008] In an optional implementation, the policy weight factor and the time series monitoring data set are input into the policy decision engine to calculate the initial target number of instances for each cloud platform, specifically including: Mapping the performance weight coefficient, cost weight coefficient, or hybrid weight coefficient to a preset weight-instance number conversion table to obtain a baseline instance increment ΔNbase corresponding to the weight coefficient; wherein the weight-instance number conversion table records a discrete correspondence between weight coefficient intervals and baseline instance increments, and the same weight coefficient interval corresponds to different ΔNbase values ​​under different policy types; Based on the time series monitoring data set, a sliding time window aggregation operation is performed on the average CPU usage and the average memory usage to obtain the CPU sliding mean μCPU, the memory sliding mean μMEM, as well as the CPU peak value PCPU and the memory peak value PMEM. The target thresholds of μCPU, μMEM, PCPU, and PMEM are TCPU, TMEM, TCPU_peak, and TMEM_peak respectively. The load deviation factor β is calculated by the following formula:

[0009] If β≤0, then set β=0; The initial target number of instances Ninit of the cloud platform is calculated using the following formula: Ninit=Ncurrent+round(ΔNbase×(1+β)); Where Ncurrent is the actual number of running instances of 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.

[0010] In an optional embodiment, the availability score of the candidate cloud platform is calculated based on the network latency, historical failure rate, and synchronized remaining capacity of each available zone in the candidate cloud platform list, specifically including: Collect the round-trip latency (RTT) from the service egress to the nearest access point of the candidate cloud platform. Based on the preset target latency threshold Tlatency, if RTT ≤ Tlatency, the network latency score is LatencyScore = 100. If RTT > Tlatency, the network latency score is 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, the historical failure rate score (FaultScore) is 100. If FR > TFR, the historical failure rate score (FaultScore) is 100 × (TFR / FR). Based on the synchronized available zone remaining capacity, calculate the candidate cloud platform's dispatchable capacity ratio (CR) that meets the required instance specifications in the target region. If CR ≥ required capacity, the available zone remaining capacity score (CapacityScore) = 100. If CR < required capacity, the available zone remaining capacity score (CapacityScore) = 100 × (CR / required capacity). The network latency score, historical failure rate score, and available zone remaining capacity score are weighted and summed to obtain the candidate cloud platform availability score.

[0011] In an optional embodiment, calling a specification scoring function of a corresponding policy according to the selected policy type and determining the target instance specifications of the final target cloud platform according to the specification scoring function specifically includes: Based on the cached instance specification metadata, filter the target cloud platform's region ID to obtain a set of all instance specifications S = {s1, s2, ..., sn} available in that region. Each element si in the instance specification set contains at least three attributes: number of CPU cores, memory capacity, and unit price. If the performance priority strategy is selected, the sum of the number of CPU cores and memory capacity is used as the performance score. All specifications with a performance score ≥ the computing power threshold required by the current load are selected. Then, the specifications with the highest performance score and the lowest unit price are selected as the target instance specifications. If the cost priority 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; If the 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.

[0012] In a second aspect, the technical solution of the present invention provides a multi-cloud virtual machine elastic scaling system based on Terraform, comprising: A 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 price metadata. The resource performance indicator collection module is used to call the monitoring interfaces of each cloud platform in real time to collect the resource performance indicators of the cloud platform, unify the units and standardize the format of heterogeneous data, and generate a time series monitoring data set; A scaling instruction generation module is configured to generate a scaling instruction including a target number of instances, target instance specifications, and a target cloud platform based on the real-time load status reflected by the time series monitoring dataset and in combination with a preset cost priority, performance priority, or hybrid strategy; A variable file generation module is configured to select a resource configuration template corresponding to the cloud platform from a preset template library based on 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 docking plug-in to load the selected resource configuration template and the variable file, generate an infrastructure change plan through a resource change pre-verification command, and when the verification passes, execute the resource change execution command to complete resource scaling.

[0013] In a third aspect, the technical solution of the present invention provides a terminal, including: Storage, used to store Terraform-based multi-cloud virtual machine elastic scaling programs; A processor is configured to implement the steps of any of the above-mentioned Terraform-based multi-cloud virtual machine elastic scaling methods when executing the Terraform-based multi-cloud virtual machine elastic scaling program.

[0014] In a fourth aspect, the technical solution of the present invention provides a computer-readable storage medium, on which a Terraform-based multi-cloud virtual machine elastic scaling program is stored. When the Terraform-based multi-cloud virtual machine elastic scaling program is executed by a processor, the steps of the Terraform-based multi-cloud virtual machine elastic scaling method as described in any one of the above items are implemented.

[0015] It can be seen from the above technical solutions that this application has the following advantages: 1. This application periodically synchronizes instance specifications, availability zones, and pricing metadata across cloud platforms and caches them in a local database, unifying dispersed heterogeneous basic parameters into a real-time, standardized data view. This directly eliminates script fragmentation caused by API differences and significantly reduces the complexity of operations and maintenance in a multi-cloud environment. 2. This application generates a time-series monitoring data set by collecting and uniformly formatting various cloud monitoring indicators in real time. This allows key indicators such as CPU and memory to be aggregated at the second level under the same semantics. The policy engine can instantly identify overloads or idleness, thereby improving overall resource utilization. 3. This application uses unified monitoring data and price metadata to calculate the target instance quantity, specifications, and target cloud platform in real time according to cost priority, performance priority, or hybrid strategies. This optimizes both cost and performance, and supports dynamic switching between any compliant clouds, completely avoiding vendor lock-in. 4. This application encapsulates cloud differences into reusable modules by selecting corresponding templates from a pre-set template library based on scaling instructions and injecting variables into them to generate variable files. Any specification or quantity changes are completed within the same code baseline, reducing manual editing errors and shortening elastic operation time from hours to minutes. 5. This application generates a change plan by calling the Terraform docking plug-in to execute a pre-verification command. After passing the pre-verification command, the change command is executed to complete the expansion and contraction. The plan-preview and automatic rollback mechanism are used to eliminate configuration conflicts and quota risks before formal execution, thus achieving a safe, reliable, and auditable unified orchestration closed loop. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the technical solution of the present application, the following is a brief introduction to the drawings required for the description. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0017] Figure 1 A flow chart of a Terraform-based multi-cloud virtual machine elastic scaling method is provided in accordance with an embodiment of the present invention.

[0018] Figure 2 A schematic block diagram of the structure of a multi-cloud virtual machine elastic scaling system based on Terraform is provided in an embodiment of the present invention.

[0019] Figure 3 A schematic diagram of the structure of a terminal provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0020] In order to make the application objectives, features, and advantages of this application more obvious and easy to understand, the technical solutions protected by this application will be clearly and completely described below using specific embodiments and drawings. Obviously, the embodiments described below are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0021] Unless otherwise defined, all technical and scientific terms used in this application have the same meaning as those commonly understood by those skilled in the art to which the present invention pertains. The terms used in this application and in the specification of the present invention are for the purpose of describing specific embodiments only and are not intended to limit the present invention.

[0022] The key terms appearing in the present invention are explained below.

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

[0024] Terraform Provider: A plug-in that connects Terraform to specific cloud vendors or services, abstracting the API differences between different cloud platforms. Each provider encapsulates the resource types and operation interfaces of the target platform.

[0025] tfvar files: Terraform Variables files are configuration files used to dynamically inject variable values. In a Terraform template, variables.tf is used to define variables (such as the number of instances and specifications), while tfvar files (such as auto_generated.tfvars) provide the actual values ​​for these variables.

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

[0027] Terraform apply: A resource change execution command, an infrastructure orchestration instruction, that actually calls the cloud service provider's API to perform resource operations based on the change plan generated by Terraform Plan, bringing the infrastructure to the target state defined in the configuration file.

[0028] Figure 1 A flow chart of a multi-cloud virtual machine elastic scaling method based on Terraform is provided in an embodiment of the present invention. Figure 1 The execution entity may be a Terraform-based multi-cloud virtual machine elastic scaling system. The Terraform-based multi-cloud virtual machine elastic scaling method provided in embodiments of the present invention is executed by a computer device. Accordingly, the Terraform-based multi-cloud virtual machine elastic scaling system runs on the computer device. The order of the steps in this flowchart may be changed, and some steps may be omitted, depending on different needs.

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

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

[0031] Connect with cloud providers (such as AWS and Alibaba Cloud) through web APIs or console interfaces to automatically register accounts and generate API keys. Generated API keys are encrypted and stored in HashiCorp Vault, supporting AES-256-GCM symmetric encryption and key rotation, and are managed hierarchically by provider and region.

[0032] Using the encrypted API key as the access token, the system regularly pulls the availability zone list, instance specification metadata, and price list of each cloud vendor, updates them to the local cache, and adopts an incremental update and failure retry mechanism (up to 3 times) to ensure the real-time metadata.

[0033] Instance specifications refer to the hardware configuration parameters of the virtual machine (or cloud server) provided by the cloud service provider, typically including: 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.).

[0034] 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 and is used to achieve high availability and disaster recovery, avoiding single points of failure. Users can distribute instances across multiple availability zones to improve business continuity.

[0035] Price metadata refers to the billing information of instance specifications provided by cloud service providers, including: pay-as-you-go (hourly or second-by-second price), reserved instances (long-term reservation discounts), spot instances (dynamic spot prices), and bandwidth / storage add-on fees (such as outbound traffic charges and cloud disk storage fees).

[0036] Synchronously caching this information can unify the multi-cloud resource view, eliminate API differences 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).

[0037] S2, calls the monitoring interfaces of each cloud platform in real time to collect the resource performance indicators of the cloud platform, unifies the units and standardizes the formats of heterogeneous data, and generates a time series monitoring data set.

[0038] Resource performance indicators include computing resource metrics, business load 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. Business load metrics include requests per second and application response latency. Cloud service provider-specific metrics include vCPU utilization in Alibaba Cloud ECS instances.

[0039] S3: Based on the real-time load status reflected by the time series monitoring data set and in combination with a preset cost priority, performance priority, or hybrid strategy, a scaling instruction including the target number of instances, target instance specifications, and target cloud platform is generated.

[0040] S4: Select a resource configuration template corresponding to the cloud platform from a 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.

[0041] S5: Call the Terraform docking plug-in to load the selected resource configuration template and the variable file, generate an infrastructure change plan through the resource change pre-verification command, and when the verification passes, execute the resource change execution command to complete resource expansion and contraction.

[0042] In some optional implementations, the time series monitoring data set reflects the real-time load status, specifically including: pre-configuring the time window length, calculating the various resource performance indicators in the time series monitoring data set according to the time window length to obtain the average value, peak value and standard deviation of the indicator; if all calculation results are for the corresponding threshold value, 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 value, 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 value, the real-time load status is marked as an overload status.

[0043] Taking the CPU and memory utilization of cloud platform virtual machines as core resource performance indicators, this article explains how a time-series monitoring dataset reflects real-time load status. The system continuously collects the CPU and memory utilization of the target virtual machines within a preconfigured 5-minute window. After obtaining the time-series monitoring data, the following metrics are calculated: The average CPU utilization is 65%, with a peak of 72% and a standard deviation of 5%. The average memory utilization is 60%, with a peak of 68% and a standard deviation of 4%.

[0044] The CPU usage warning threshold is 70%, and the safety threshold is 85%. The memory usage warning threshold is 75%, and the safety threshold is 90%. Because the average, peak, and standard deviation of the CPU and memory usage values ​​do not exceed the corresponding warning thresholds, the system marks the real-time load status of this virtual machine as normal.

[0045] If, during another 5-minute window, the calculated metrics are: CPU usage average 72%, peak 78%, and standard deviation 6%; memory usage average 70%, peak 74%, and standard deviation 5%. In this case, both the average CPU usage of 72% and the peak of 78% exceed the warning threshold of 70%, while none of the memory usage results exceed the warning threshold of 75%. Because either target metric (CPU usage) exceeds the warning threshold, the system marks the real-time load status as critical.

[0046] If, within another 5-minute window, the calculated metrics are: CPU usage with an average of 88%, a peak of 92%, and a standard deviation of 7%; and memory usage with an average of 85%, a peak of 89%, and a standard deviation of 6%, then the system will mark the real-time load status as overloaded, even though the CPU usage results do not exceed the safety threshold of 90%. Since the calculated results for any target metric (CPU usage) exceed the safety threshold, the system will mark the real-time load status as overloaded.

[0047] In some optional implementations, step S3 generates a scaling instruction including the target number of instances, target instance specifications, and target cloud platform in combination with a preset cost priority, performance priority, or hybrid strategy, specifically including the following steps.

[0048] S3.1, select the strategy based on the real-time load status. When it is marked as overload status, the performance priority strategy is forcibly enabled. When it is marked as critical load status, 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 it is marked as normal load status, if it is currently in the business peak period, the hybrid strategy is enabled, otherwise the cost priority strategy is enabled.

[0049] The budget consumption rate is the ratio of resource costs used in the current cycle to the total budget, used to quantify cost control status. Its calculation relies on the price metadata and real-time resource usage synchronized in step S1.

[0050] Budget consumption rate = (actual expenditure of the current cycle / total budget of the current cycle) * 100% The actual cost is calculated as the price per instance multiplied by the instance runtime, plus additional fees. Additional fees include storage, network traffic, and other expenses.

[0051] S3.2, according to the selected policy type, call the corresponding policy weight function to calculate the policy weight factor, and input the policy weight factor and the time series monitoring data set into the policy decision engine to calculate the initial target instance number of each cloud platform.

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

[0053] Specifically, if the performance priority strategy is selected, the ratio of the CPU utilization peak to the instance specification computing power upper limit is used as the performance weight, and the instance unit price per unit time is used as the cost weight. The two are weighted summed to obtain the performance weight coefficient; if the cost priority 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 summed to obtain the cost weight coefficient; if the hybrid strategy is selected, the performance weight and the cost weight are dynamically balanced according to the preset business peak weight factor to obtain the hybrid weight coefficient.

[0054] The preset service peak weight factor λ is read from the scaling policy configuration, where 0≤λ≤1. This weight factor is pre-set by the user based on service load characteristics and is used to differentiate policy preferences between peak and off-peak hours.

[0055] Based on the business peak weight factor λ, the performance weight wperf=λ and the cost weight wcost=1-λ are calculated. 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 benchmark instance increment ΔNbase corresponding to the weight coefficient; wherein the weight-instance number conversion table records the discrete correspondence between the weight coefficient interval and the benchmark instance increment, and the same weight coefficient interval corresponds to different ΔNbase values ​​under different strategy types.

[0056] S3.2.3, based on the time series monitoring data set, performs sliding time window aggregation operations on the average CPU usage and the average memory usage, respectively, to obtain the CPU sliding mean μCPU, the memory sliding mean μMEM, as well as the CPU peak value PCPU and the memory peak value PMEM.

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

[0058] If β≤0, then set β=0.

[0059] S3.2.5, calculate the initial target number of cloud platform instances Ninit using the following formula: Ninit=Ncurrent+round(ΔNbase×(1+β)); Where Ncurrent is the actual number of running instances of the cloud platform at the current moment, and round() is the rounding function.

[0060] 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.

[0061] S3.3, based on the initial target number of instances and the cached price metadata, calculate the estimated total cost of each cloud platform, eliminate the cloud platforms whose estimated total cost exceeds the budget upper limit threshold, and obtain a list of candidate cloud platforms.

[0062] Based on the price metadata synchronized and cached in step S1, query the hourly 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, calculate the estimated total cost of each candidate cloud platform TotalCost i : TotalCost i =Price i ×Ninit i ×Duration 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.

[0063] Compare the estimated total cost TotalCost of each candidate cloud platform with the user's preset budget upper limit Threshold: If TotalCost ≤ Threshold, the cloud platform enters 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 excessive costs.

[0064] S3.4. Calculate the availability scores of the candidate cloud platforms based on the network latency, historical failure rate, and remaining capacity of the synchronized availability zones for each region in the candidate cloud platform list. 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.

[0065] S3.4.1. Collect the round-trip latency (RTT) from the service egress to the nearest access point of the candidate cloud platform. Based on the preset target latency threshold Tlatency, if RTT ≤ Tlatency, the network latency score (LatencyScore) is 100. If RTT > Tlatency, the network latency score (LatencyScore) is 100 × (Tlatency / RTT).

[0066] A business egress refers to the starting point for business systems to initiate external network requests. This refers to the network interface or gateway through which business systems communicate 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.

[0067] 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, the historical failure rate score FaultScore = 100; if FR > TFR, the historical failure rate score FaultScore = 100×(TFR / FR).

[0068] S3.4.3. Based on the synchronized remaining capacity of the availability zone, calculate the dispatchable capacity ratio (CR) of the candidate cloud platform in the target region that meets the required instance specifications. If CR ≥ required capacity, the remaining capacity score of the availability zone (CapacityScore) = 100. If CR < required capacity, the remaining capacity score of the availability zone (CapacityScore) = 100 × (CR / required capacity).

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

[0070] The weights of each item are configured by the user.

[0071] S3.5, calling the specification scoring function of the corresponding policy according to the selected policy type, and determining the target instance specifications of the final target cloud platform according to the specification scoring function.

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

[0073] S3.5.2: If the performance priority strategy is selected, the sum of the number of CPU cores and memory capacity is used as the performance score. All specifications with a performance score ≥ the computing power threshold required by the current load are selected, and then sorted in ascending order by unit price. The specification with the highest performance score and the lowest unit price is selected as the target instance specification.

[0074] S3.5.3: If the cost priority 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.

[0075] 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.

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

[0077] Calculate the specification-load matching coefficient γ based on the real-time load peak values ​​PCPU and PMEM and the upper specification limits CPUcore and MEMsize: γ=min{CPUcore / PCPU,MEMsize / PMEM} If γ≥1, it indicates that the specification can meet the peak load, and γ is set to 1; if γ<1, it indicates that there is a bottleneck in the specification, and γ remains the original value.

[0078] Performance scores , the value is rounded down to an integer.

[0079] Unit computing power cost UnitCost = Price / BasePerf, where Price is the hourly price of the candidate specification si, in RMB / hour.

[0080] In order to make the lower the cost, the higher the score, the UnitCost is reversely mapped: CostScore=round(100×(UnitCost_max-UnitCost) / (UnitCost_max-UnitCost_min)) UnitCost_max and UnitCost_min are the highest and lowest unit computing power costs of all candidate specifications in the list of compliant cloud platforms, respectively. CostScore results are rounded to the nearest integer and range from [0 to 100].

[0081] Using the mixed weight coefficients wperf and wcost determined in step S3.2.1 as weights, calculate the comprehensive score: CompositeScore=wperf×PerfScore+wcost×CostScore Wherein wperf+wcost=1, and wperf and wcost are given in real time by the mixing weight coefficient.

[0082] S3.6, construct a scaling instruction that includes the target number of instances, target instance specifications, and target cloud platform.

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

[0084] In some optional implementations, step S4 includes the following steps.

[0085] S4.1, resource configuration template selection sub-step.

[0086] Read the target instance specifications and target cloud platform information from the scaling instruction. Select the corresponding cloud platform resource configuration template from the pre-configured template library based on the target cloud platform ID. Verify the completeness and validity of the selected resource configuration template, ensuring that it contains all required resource definitions and parameter fields.

[0087] S4.2, variable file generation sub-step.

[0088] Extract the target number of instances and availability zone parameters from the scaling directive. Based on the variable definitions in the selected resource configuration template, inject these 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.

[0089] The generated variables file contains the following: instance_type: target instance specification, such as ecs.g7.large; desired_count: target number of instances; availability_zone: target availability zone.

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

[0091] In some optional implementations, step S5 specifically includes the following steps.

[0092] S5.1, Terraform initialization.

[0093] Call the Terraform initialization command terraforminit, which initializes the Terraform working directory, loads the selected resource configuration template and its dependencies, and ensures that all necessary plug-ins and modules are correctly configured.

[0094] S5.2, resource change pre-verification.

[0095] Call the Terraform plan command (terraformplan-out=tfplan) to generate an infrastructure change plan. This command generates a detailed resource change plan based on the selected resource configuration template and the injected variable file, including a list of resources to be created, modified, or destroyed. Check the generated change plan file (tfplan) to ensure that the plan content meets expectations, including whether the resource quantity, specifications, and network configuration are consistent with the scaling instructions. If there are conflicts or errors in the change plan (such as insufficient resource quota or network configuration conflicts), detailed error information is recorded and a rollback mechanism is triggered, terminating subsequent execution processes to ensure system consistency and security.

[0096] S5.3, Resource Change Execution.

[0097] If the pre-verification passes, call the Terraform apply command (terraformapplytfplan) to execute the resource change. This command actually creates, modifies, or destroys resources based on the change plan file (tfplan) that passed the pre-verification, completing resource scaling.

[0098] Monitor log output during execution to ensure that resource changes proceed smoothly. If any exceptions occur during execution (such as network outages or API call failures), the rollback mechanism is immediately triggered. The Terraform destroy command, terraformdestroy, is called to roll back the resource state to its pre-change stable state, avoiding business interruptions caused by inconsistent resource states.

[0099] Through the above steps, it is possible to ensure that before executing resource expansion and contraction operations, the correctness and feasibility of the change plan can be verified through the pre-verification mechanism, so as to complete the dynamic adjustment of resources in a safe and reliable manner.

[0100] The above describes 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, an embodiment of the present invention also provides a Terraform-based multi-cloud virtual machine elastic scaling system corresponding to this method.

[0101] Figure 2 This is a schematic block diagram of the structure of a Terraform-based multi-cloud virtual machine elastic scaling system, provided in an embodiment of the present invention. In this embodiment, the Terraform-based multi-cloud virtual machine elastic scaling system 200 can be divided into multiple functional modules based on the functions they perform. A module, as used herein, refers to a series of computer program segments that can be executed by at least one processor and can perform a fixed function, and is stored in a memory.

[0102] 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.

[0103] The resource performance indicator collection module 220 is used to call the monitoring interfaces of each cloud platform in real time to collect the resource performance indicators of the cloud platform, unify the units and standardize the formats of heterogeneous data, and generate a time series monitoring data set.

[0104] The scaling instruction generation module 230 is configured to generate a scaling instruction including 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 a preset cost priority, performance priority, or hybrid strategy.

[0105] The variable file generation module 240 is configured to select a resource configuration template corresponding to the cloud platform from a 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.

[0106] The resource expansion and contraction module 250 is used to call the Terraform docking plug-in to load the selected resource configuration template and the variable file, generate an infrastructure change plan through a resource change pre-verification command, and when the verification passes, execute the resource change execution command to complete resource expansion and contraction.

[0107] 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 methods of this system can be found in the embodiment section of the Terraform-based multi-cloud virtual machine elastic scaling method in the previous text. Therefore, its specific implementation methods can refer to the descriptions of the corresponding embodiments and will not be elaborated here.

[0108] In addition, since 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, its function corresponds to that of the aforementioned method and will not be repeated here.

[0109] Figure 3 A schematic diagram of the structure of a terminal 300 provided in an embodiment of the present invention includes: a processor 310, a memory 320, and a communication unit 330. The processor 310 is configured to implement the process steps of the 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.

[0110] 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 appreciate that the server structure shown in the figure does not limit the present invention; it may be a bus structure or a star structure, and may include more or fewer components than shown, or combine certain components, or arrange the components differently.

[0111] Memory 320 can be used to store execution instructions of processor 310. Memory 320 can be implemented by any type of volatile or non-volatile storage device, 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 memory, flash memory, magnetic disk, or optical disk. When the execution instructions in memory 320 are executed by processor 310, terminal 300 can perform some or all of the steps in the above-described method embodiments.

[0112] The processor 310 is the control center of the storage terminal. It uses various interfaces and lines to connect various parts of the entire electronic terminal. It runs or 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 an integrated circuit (IC), for example, it can be composed of a single packaged IC, or it can be composed of multiple packaged ICs with the same or different functions. For example, the processor 310 can only include a central processing unit (CPU). In an embodiment of the present invention, the CPU can be a single computing core or multiple computing cores.

[0113] The communication unit 330 is configured to establish a communication channel so that the storage terminal can communicate with other terminals, receive user data sent by other terminals, or send user data to other terminals.

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

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

[0116] 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 a processor, the process steps of the above-mentioned Terraform-based multi-cloud virtual machine elastic scaling method embodiment are implemented.

[0117] Those skilled in the art will clearly understand that the techniques in the embodiments of the present invention can be implemented using software plus a necessary general-purpose hardware platform. Based on this understanding, the technical solutions in the embodiments of the present invention, or the portion that contributes 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, a mobile hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, among other media capable of storing program code, and includes instructions for causing a computer terminal (which can be a personal computer, a server, or a second terminal, a network terminal, etc.) to execute all or part of the steps of the methods described in various embodiments of the present invention.

[0118] In the several embodiments provided by the present invention, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0119] The units described as separate components may or may not be physically separate, and 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 these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0120] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0121] The above description of the disclosed embodiments is intended to enable one skilled in the art to implement or use the present 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 present invention. Therefore, the present invention is not limited to the embodiments shown herein, but is intended to be construed in the widest manner consistent with the principles and novel features disclosed herein.

Claims

1. A multi-cloud virtual machine elastic scaling method based on Terraform, characterized in that: The following steps are involved: Periodically synchronize basic parameters of each cloud platform to the local cache database, including instance specifications, availability zones, and price metadata; Call each cloud platform's monitoring interface in real time to collect cloud platform resource performance indicators, unify units and standardize formats for heterogeneous data, and generate time-series monitoring data sets; Based on the real-time load status reflected by the time series monitoring data set, combined with a preset cost priority, performance priority, or hybrid strategy, a scaling instruction including the target number of instances, target instance specifications, and target cloud platform is generated; According to the target instance specifications in the scaling instruction, a resource configuration template corresponding to the cloud platform is selected from a preset template library, and the target instance quantity and availability zone parameters are injected into the selected resource configuration template to generate a variable file; The Terraform docking plug-in is called to load the selected resource configuration template and the variable file. The infrastructure change plan is generated through the resource change pre-verification command. When the verification passes, the resource change execution command is executed to complete resource expansion and contraction.

2. The Terraform-based multi-cloud virtual machine elastic scaling method according to claim 1, characterized in that: The time series monitoring data set reflects the real-time load status and specifically includes: Preconfigure the time window length and calculate the average, peak, and standard deviation of various resource performance indicators in the time series monitoring data set based on the time window length. If all calculation results are for the corresponding thresholds, 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.

3. The Terraform-based multi-cloud virtual machine elastic scaling method according to claim 2, characterized in that: Combined with the preset cost-first, performance-first, or hybrid strategy, a scaling instruction is generated, including the target number of instances, target instance specifications, and target cloud platform. Specifically, it includes: Select a strategy based on the real-time load status. When the system is marked as overloaded, the performance priority strategy is forcibly enabled. When the system 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 system is marked as normal load, if the business is currently at peak hours, the hybrid strategy is enabled. Otherwise, the cost priority strategy is enabled. The corresponding policy weight function is called according to the selected policy type to calculate the policy weight factor. The policy weight factor and the time series monitoring data set are input into the policy decision engine to calculate the initial target number of instances for each cloud platform. Based on the initial target number of instances and cached price metadata, the estimated total cost of each cloud platform is calculated. Cloud platforms with estimated total costs exceeding the upper budget threshold are eliminated to obtain a list of candidate cloud platforms. Based on the network latency, historical failure rate, and remaining capacity of the synchronized availability zones for each region in the candidate cloud platform list, the availability score of the candidate cloud platforms is calculated. The candidate cloud platform with the highest score is selected as the final target cloud platform, and the corresponding initial target instance number is determined as the final target instance number. Call the specification scoring function of the corresponding policy according to the selected policy type, and determine the target instance specifications of the final target cloud platform based on the specification scoring function; Construct a scaling instruction that includes the target number of instances, target instance specifications, and target cloud platform.

4. The Terraform-based multi-cloud virtual machine elastic scaling method according to claim 3, characterized in that: The corresponding strategy weight function is called according to the selected strategy type to calculate the strategy weight factor, including: If the performance priority policy is selected, the ratio of the peak CPU utilization to the upper limit of the instance specification is used as the performance weight, and the instance price per unit time is used as the cost weight. The performance weight coefficient is obtained by weighted summing the two. If the cost priority 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 cost weight coefficient is obtained by weighted summing the two. 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 a hybrid weight coefficient.

5. The Terraform-based multi-cloud virtual machine elastic scaling method according to claim 4, characterized in that: The policy weight 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, including: Mapping the performance weight coefficient, cost weight coefficient, or hybrid weight coefficient to a preset weight-instance number conversion table to obtain a baseline instance increment ΔNbase corresponding to the weight coefficient; wherein the weight-instance number conversion table records a discrete correspondence between weight coefficient intervals and baseline instance increments, and the same weight coefficient interval corresponds to different ΔNbase values ​​under different policy types; Based on the time series monitoring data set, a sliding time window aggregation operation is performed on the average CPU usage and the average memory usage to obtain the CPU sliding mean μCPU, the memory sliding mean μMEM, as well as the CPU peak value PCPU and the memory peak value PMEM. The target thresholds of μCPU, μMEM, PCPU, and PMEM are TCPU, TMEM, TCPU_peak, and TMEM_peak respectively. The load deviation factor β is calculated by the following formula: β=max[(μCPU-TCPU) / TCPU,(μMEM-TMEM) / TMEM,(PCPU-TCPU_peak) / TCPU_peak,(PMEM-TMEM_peak) / TMEM_peak]; If β≤0, then set β=0; The initial target number of instances Ninit of the cloud platform is calculated using the following formula: Ninit=Ncurrent+round(ΔNbase×(1+β)); Where Ncurrent is the actual number of running instances of 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.

6. The Terraform-based multi-cloud virtual machine elastic scaling method according to claim 3, characterized in that: The availability score of each candidate cloud platform is calculated based on the network latency, historical failure rate, and remaining capacity of the synchronized availability zones in each region of the candidate cloud platform list. Specifically, it includes: Collect the round-trip latency (RTT) from the service egress to the nearest access point of the candidate cloud platform. Based on the preset target latency threshold Tlatency, if RTT ≤ Tlatency, the network latency score is LatencyScore = 100. If RTT > Tlatency, the network latency score is 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, the historical failure rate score (FaultScore) is 100. If FR > TFR, the historical failure rate score (FaultScore) is 100 × (TFR / FR). Based on the synchronized available zone remaining capacity, calculate the candidate cloud platform's dispatchable capacity ratio (CR) that meets the required instance specifications in the target region. If CR ≥ required capacity, the available zone remaining capacity score (CapacityScore) = 100. If CR < required capacity, the available zone remaining capacity score (CapacityScore) = 100 × (CR / required capacity). The network latency score, historical failure rate score, and available zone remaining capacity score are weighted and summed to obtain the candidate cloud platform availability score.

7. The Terraform-based multi-cloud virtual machine elastic scaling method according to claim 3, characterized in that: The specification scoring function of the corresponding policy is called based on the selected policy type. The target instance specifications of the final target cloud platform are determined based on the specification scoring function. Specifically, the following are performed: Based on the cached instance specification metadata, filter the target cloud platform's region ID to obtain a set of all instance specifications S = {s1, s2, ..., sn} available in that region. Each element si in the instance specification set contains at least three attributes: number of CPU cores, memory capacity, and unit price. If the performance priority strategy is selected, the sum of the number of CPU cores and memory capacity is used as the performance score. All specifications with a performance score ≥ the computing power threshold required by the current load are selected. Then, the specifications with the highest performance score and the lowest unit price are selected as the target instance specifications. If the cost priority 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; If the 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.

8. A multi-cloud virtual machine elastic scaling system based on Terraform, characterized in that: include: A 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 price metadata. The resource performance indicator collection module is used to call the monitoring interfaces of each cloud platform in real time to collect the resource performance indicators of the cloud platform, unify the units and standardize the format of heterogeneous data, and generate a time series monitoring data set; A scaling instruction generation module is configured to generate a scaling instruction including a target number of instances, target instance specifications, and a target cloud platform based on the real-time load status reflected by the time series monitoring dataset and in combination with a preset cost priority, performance priority, or hybrid strategy; A variable file generation module is configured to select a resource configuration template corresponding to the cloud platform from a preset template library based on 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 docking plug-in to load the selected resource configuration template and the variable file, generate an infrastructure change plan through a resource change pre-verification command, and when the verification passes, execute the resource change execution command to complete resource scaling.

9. 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 according to any one of claims 1 to 7 when executing the Terraform-based multi-cloud virtual machine elastic scaling program.

10. A computer-readable storage medium, characterized in that The readable 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 a processor, the steps of the Terraform-based multi-cloud virtual machine elastic scaling method according to any one of claims 1 to 7 are implemented.

Images