A cloud disk snapshot backup method based on IO pressure sensing and dynamic throttling

Abstract

This invention discloses a cloud disk snapshot backup method based on IO pressure awareness and dynamic throttling. The method includes: real-time collection of disk IO performance indicators of production virtual machines and health status indicators of the underlying storage system; comparison of the collected indicators with preset thresholds to dynamically determine the current system IO pressure status; calculation and output of a backup task IO rate limit value in real time using a dynamic throttling algorithm based on the IO pressure status; and rate limiting of the backup data reading process based on the IO rate limit value to achieve dynamic throttling. This application combines business layer indicators with infrastructure layer indicators to construct a more comprehensive and accurate system pressure assessment model, rather than relying solely on a single dimension. Furthermore, without altering the existing hardware infrastructure, it achieves IO resource coordination and automatic arbitration between backup tasks and production operations through software intelligence.

Description

Technical Field

[0001] This invention relates to the field of cloud disk snapshot backup technology, and in particular to a cloud disk snapshot backup method based on IO pressure sensing and dynamic throttling. Background Technology

[0002] With the rapid development of cloud computing technology, cloud disks based on virtualization architecture (such as cloud block storage) have been widely used in various production and business systems. To ensure the security and recoverability of business data, it is usually necessary to perform regular or on-demand snapshot backups of cloud disks. Cloud disk snapshots record the data state at a specific point in time, enabling rapid recovery in the event of failures or data anomalies, and are one of the important data protection methods in current cloud platforms.

[0003] In existing technologies, cloud disk snapshot backups typically involve background tasks scanning and reading stored data, and then copying incremental or full data to the backup storage medium. During this process, the backup task continuously generates a large number of disk read I / O requests, consuming storage bandwidth and system resources.

[0004] However, in real-world production environments, cloud disks often host online business systems (such as databases and transaction systems), which have high real-time and stability requirements for disk I / O performance. When backup tasks run concurrently with production operations, if the backup tasks do not properly control I / O resources, they can easily compete with production operations for resources, leading to increased disk I / O latency, decreased IOPS, and even performance fluctuations or service quality degradation.

[0005] To address the aforementioned issues, existing technologies typically employ the following methods to optimize the backup process: First, a fixed-rate limiting method is used, where a fixed IO bandwidth or rate limit is pre-set when the backup task starts; second, backup tasks are scheduled based on time windows, such as performing backups during off-peak business periods; and third, backup strategies are configured through manual experience, adjusting backup parameters based on historical load conditions.

[0006] However, the above solutions still have the following shortcomings: First, the fixed-rate rate limiting method lacks the ability to perceive the real-time status of the system and cannot dynamically adjust the backup rate according to the current business load. It may still cause performance impact when the business suddenly experiences high load, while it cannot make full use of idle resources when the business is under low load. Second, the time window-based scheduling method is difficult to adapt to scenarios with dynamic changes in business load, especially in the case of large fluctuations in multi-tenant business in the cloud environment, where the off-peak period is not fixed. Third, relying on manual experience for parameter configuration has strong subjectivity and makes it difficult to achieve fine-grained and automated control. Summary of the Invention

[0007] The main objective of this invention is to provide a cloud disk snapshot backup method based on IO pressure sensing and dynamic throttling.

[0008] Another objective of this invention is to propose a cloud disk snapshot backup device based on IO pressure sensing and dynamic throttling.

[0009] The third objective of this invention is to provide an electronic device.

[0010] A fourth objective of this invention is to provide a non-transitory computer-readable storage medium.

[0011] To achieve the above objectives, a first aspect of the present invention proposes a cloud disk snapshot backup method based on IO pressure sensing and dynamic throttling, comprising:

[0012] Real-time collection of disk I / O performance metrics of production virtual machines and health status metrics of the underlying storage system; The collected metrics are compared with preset thresholds to dynamically determine the current IO pressure status of the system. Based on the IO pressure status, the upper limit of the IO rate of the backup task is calculated and output in real time through a dynamic throttling algorithm; Based on the upper limit of the IO rate, the rate of the backup data reading process is limited to achieve dynamic throttling.

[0013] Optional, disk I / O performance metrics include I / O read / write latency, IOPS, and throughput; The underlying storage system health indicators include storage controller CPU utilization, cache utilization, disk queue depth, and the current read rate, completed data volume, and remaining data volume of backup tasks.

[0014] Optionally, the collected metrics can be compared with preset thresholds to dynamically determine the current system's IO pressure status, including: The collected indicators are compared with preset thresholds to dynamically determine the system IO pressure status as high pressure, medium pressure, or low pressure.

[0015] Optionally, based on the IO pressure status, the upper limit of the IO rate for the backup task is calculated and output in real time using a dynamic throttling algorithm, including: When the IO pressure is high, set the maximum IO rate of the backup task to 10% of the baseline value; When the IO pressure is at a medium level, set the maximum IO rate of the backup task to maintain the current rate. When the IO pressure is low, set the backup task IO rate cap to the current rate. Gradually improve The monitoring period is until the bandwidth limit is reached or business metrics fluctuate.

[0016] To achieve the above objectives, a second aspect of the present invention provides a cloud disk snapshot backup device based on IO pressure sensing and dynamic throttling, comprising: The first module is used to collect disk I / O performance metrics of production business virtual machines and health status metrics of the underlying storage system in real time. The second module is used to compare the collected indicators with preset thresholds to dynamically determine the current IO pressure status of the system. The third module is used to calculate and output a backup task IO rate limit in real time based on the IO pressure status using a dynamic throttling algorithm. The fourth module is used to limit the rate of backup data reading processes based on the upper limit of IO rate, so as to achieve dynamic throttling.

[0017] To achieve the above objectives, a third aspect of this application provides an electronic device, including a processor and a memory; wherein the processor runs a program corresponding to the executable program code by reading executable program code stored in the memory, for implementing the method as described in the first aspect embodiment.

[0018] To achieve the above objectives, a fourth aspect of this application provides a non-transitory computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the method as described in the first aspect embodiment.

[0019] The embodiments of the present invention have the following beneficial effects: Reduce the impact on production operations: By dynamically throttling, it is possible to ensure that the IO performance (especially latency) of virtual machines in production operations remains stable within an acceptable SLA (Service Level Agreement) range, achieving seamless backup for the business and significantly improving user experience and system reliability.

[0020] Significantly improves backup efficiency and resource utilization: During periods of low business activity, it can intelligently make full use of idle IO resources to complete backup tasks at maximum speed, effectively shortening the backup window and improving the success rate of backup tasks.

[0021] Excellent cost-effectiveness: There is no need to purchase additional dedicated backup hardware or over-configure high-performance storage. High-quality backups can be achieved on existing shared storage infrastructure through software algorithm optimization, thus achieving the goal of reducing costs and increasing efficiency.

[0022] Enhanced system stability: It avoids the risk of storage array overload caused by "brutal" reads of backup tasks, thereby reducing the probability of the entire cloud platform failing due to excessive storage pressure. Attached Figure Description

[0023] The above-described and additional aspects and advantages of the present invention will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, in which: Figure 1 A flowchart illustrating a cloud disk snapshot backup method based on IO pressure sensing and dynamic throttling, provided as an embodiment of the present invention; Figure 2 This is a structural diagram of a cloud disk snapshot backup method device based on IO pressure sensing and dynamic throttling, provided in an embodiment of the present invention. Detailed Implementation

[0024] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0025] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0026] The following description, with reference to the accompanying drawings, describes a cloud disk snapshot backup method and apparatus based on IO pressure sensing and dynamic throttling according to an embodiment of the present invention.

[0027] Example 1 This embodiment provides a cloud disk snapshot backup method based on IO pressure sensing and dynamic throttling. For example... Figure 1 As shown, the method includes the following steps: S1 collects real-time disk I / O performance metrics of production virtual machines and health status metrics of the underlying storage system.

[0028] This step provides foundational data support for subsequent IO pressure assessment and dynamic throttling by continuously collecting multi-dimensional operational data.

[0029] In this embodiment, disk I / O performance metrics are used to reflect the I / O load of the current production virtual machine at the disk level, specifically including but not limited to I / O read / write latency, IOPS, and throughput. I / O read / write latency characterizes the response time of a single I / O request, directly reflecting the real-time performance of the storage system; IOPS characterizes the number of I / O requests processed per unit time; and throughput characterizes the total amount of data transferred per unit time. By combining these multiple metrics, the I / O usage intensity and performance status of the current virtual machine service can be comprehensively characterized.

[0030] Furthermore, underlying storage system health metrics are used to reflect the overall operational status of storage resources, specifically including storage controller CPU utilization, cache utilization, and disk queue depth. Storage controller CPU utilization characterizes the controller's computational resource usage; cache utilization reflects the utilization of storage cache resources; and disk queue depth reflects the number of I / O requests currently waiting to be processed on the disk, thus indicating the degree of congestion in the storage system.

[0031] Furthermore, to more accurately assess the impact of backup tasks on system I / O resources, this embodiment of the application further collects relevant indicators of the backup task's running status, including the current read rate, the amount of data completed, and the amount of data remaining. The current read rate characterizes the real-time I / O consumption of the storage system by the backup task; the amount of data completed and the amount of data remaining reflect the execution progress of the backup task, thus providing a reference for subsequent dynamic adjustment strategies.

[0032] It should be noted that the above-mentioned indicators can be acquired periodically through the monitoring interface of the virtualization platform, the performance acquisition interface provided by the storage system, or the agent program. The acquisition period can be set to seconds or shorter intervals according to actual needs to ensure the real-time performance and accuracy of the data. By comprehensively acquiring indicators from multiple sources, this application can fully perceive the current IO operation status of the system, providing a reliable data foundation for subsequent IO pressure status determination and dynamic throttling control.

[0033] S2 compares the collected metrics with preset thresholds to dynamically determine the current IO pressure status of the system.

[0034] In this embodiment of the application, after the real-time collection of various indicators in step S1 is completed, the current IO pressure status of the system is further determined in step S2, so as to provide a decision basis for subsequent dynamic throttling control.

[0035] Specifically, in this embodiment, step S2 includes: comparing the collected indicators with preset thresholds, and dynamically determining the current IO pressure status of the system based on the comparison results. By comparing real-time operating data with preset reference standards, changes in system load can be identified in a timely manner, thereby achieving dynamic perception of IO pressure.

[0036] Understandably, preset thresholds can be configured based on historical operational data, system performance baselines, or business service level requirements. For example, one or more latency thresholds can be set for IO read / write latency; corresponding upper limit thresholds can be set for IOPS and throughput; and corresponding alarm thresholds or tiered thresholds can be set for metrics such as storage controller CPU utilization, cache utilization, and disk queue depth. These thresholds can be preset during system deployment or dynamically adjusted based on statistical analysis results during operation.

[0037] Furthermore, by comparing the collected metrics with their corresponding preset thresholds and combining the comprehensive judgment results of multiple metrics, the system's IO pressure status is divided into three states: high pressure, medium pressure, and low pressure. Specifically, when multiple key metrics (such as IO latency, disk queue depth, or controller CPU utilization) exceed their corresponding high thresholds, it can be determined as a high pressure state; when the metrics are within the middle range, it can be determined as a medium pressure state; and when all metrics are below the preset low threshold or within a low load range, it can be determined as a low pressure state.

[0038] In this embodiment, the determination of IO pressure status can be implemented in various ways, such as based on a single-index triggering mechanism, a multi-index weighted scoring mechanism, or a priority determination mechanism. In one optional implementation, different weights can be assigned to each index, and a comprehensive score can be calculated. The pressure level is then determined based on the correspondence between the score result and the grading threshold. In another optional implementation, a "key index priority" determination strategy can be adopted, meaning that when any key index exceeds a high threshold, it is directly determined to be a high-pressure state, thereby improving the sensitivity of the system response.

[0039] In addition, in this embodiment of the application, in order to avoid frequent switching of pressure state due to instantaneous fluctuations, a smoothing processing mechanism can be introduced, such as statistically analyzing data from multiple sampling periods through a sliding window, or setting hysteresis conditions for state switching, thereby improving the stability and reliability of the judgment result.

[0040] Through the above methods, this application can dynamically and accurately classify and determine the system IO pressure status based on multi-dimensional operating indicators, providing a valid basis for subsequent adaptive adjustment of backup rate based on pressure status.

[0041] S3 calculates and outputs the upper limit of the IO rate for backup tasks in real time based on the IO pressure status using a dynamic throttling algorithm.

[0042] After dynamically determining the system IO pressure status through step S2, dynamic throttling control is further performed based on the IO pressure status through step S3 to calculate and output the upper limit of the IO rate of the backup task in real time, so that the execution rate of the backup task can be adaptively adjusted according to the system load.

[0043] Specifically, in this embodiment, step S3 includes: based on the currently determined IO pressure state, calculating the target execution rate of the backup task in real time using a preset dynamic throttling algorithm, and outputting the corresponding upper limit value of the backup task IO rate. The upper limit value of the IO rate can serve as a direct basis for rate limiting control of the subsequent backup read process, so that the backup task can meet data protection requirements while minimizing the impact on the IO performance of production operations.

[0044] In this embodiment, the dynamic throttling algorithm takes the IO pressure status output in step S2 as input and combines it with the current backup task running status, the available bandwidth range of the system, and a predetermined adjustment strategy to generate a rate ceiling value that matches the current system status. In this way, this application does not impose a fixed bandwidth ceiling on the backup task for a long period, but rather continuously, dynamically, and reversibly adjusts the IO utilization of the backup task based on real-time changes in production operations and the underlying storage system.

[0045] Furthermore, when the IO pressure is high, it indicates that the disk access requirements of the production virtual machines are high, or the underlying storage system is under high load or even close to congestion. In this case, to prioritize the service quality of production operations, the backup task IO rate is set to 10% of the baseline value. That is, under high pressure, the backup task is quickly compressed to a lower resource consumption level to reduce its competition for business IO requests and prevent further increases in business latency due to continuous bandwidth and storage processing capacity consumption by backup reads. The baseline value can be the system's preset initial backup task rate limit, the maximum safe bandwidth allowed by the storage system to allocate to the backup task, or a reference read rate determined based on historical statistics. In other words, the baseline value is not limited to a fixed source; any value that can serve as a reference baseline for adjusting the backup task rate can be used as the baseline value in this application. By limiting the backup task rate to 10% of the baseline value under high pressure, rapid suppression of backup IO can be achieved, improving the stability and security of the system under high load scenarios.

[0046] When the IO pressure is at a medium level, it indicates that while the system has some IO load, it has not yet reached a point of significant congestion or performance degradation. In this state, the backup task IO rate cap is set to maintain the current rate. That is, under medium pressure, the backup task rate is neither actively increased nor further reduced; instead, the current rate limit is maintained. This maintenance strategy avoids system oscillations caused by frequent rate increases and decreases, while allowing the backup task to continue running under relatively stable resource usage conditions.

[0047] When the IO pressure is low, it indicates that the current production operations are not heavily utilizing IO resources, or that the underlying storage system has ample idle processing capacity. In this situation, to improve backup efficiency and shorten the backup window, the upper limit of the backup task's IO rate is gradually increased by multiplying the current rate by a power of (1 + 5%), where n is the number of monitoring periods. In other words, if the system remains under low pressure for several consecutive monitoring periods, the upper limit of the backup task's IO rate will increase periodically according to a preset ratio, gradually releasing more bandwidth for the backup task.

[0048] In this embodiment, a gradual increase rather than a one-time large increase is adopted to effectively avoid sudden impacts on production operations caused by a sudden increase in speed. By introducing the number of monitoring periods n, the growth rate of backup tasks can be correlated with the length of time the system remains under low load. That is, the longer the system is in a low-pressure state, the greater the speed increase that backup tasks can achieve, thereby realizing a gradual and adaptive resource utilization optimization mechanism.

[0049] Furthermore, the rate increase process under low-pressure conditions is not indefinite, but continues until the bandwidth limit is reached or a fluctuation in business metrics is detected. The bandwidth limit can be the maximum target bandwidth available to the backup task, the maximum resource allocation for backup services within the storage system, or a security threshold configured by the administrator. Once the backup task rate reaches this bandwidth limit, it will not continue to increase, even if the system is still under low pressure, to prevent the backup task from unrestrainedly consuming system resources.

[0050] Furthermore, in this embodiment, if fluctuations in business metrics are detected during the rate increase process, the rate increase will be terminated. Fluctuations in business metrics may include, but are not limited to, a sudden increase in IO read / write latency, an increase in disk queue depth, a significant increase in storage controller CPU utilization, abnormal changes in cache utilization, or other metrics that deviate from the normal range and reflect changes in system load. By using fluctuations in business metrics as a termination condition, this application can respond promptly in the early stages of a system transition from low to medium or high pressure, preventing backup tasks from adversely affecting production operations.

[0051] In this embodiment, the dynamic throttling algorithm can perform a rate recalculation at the end of each monitoring cycle and output a new upper limit value for the backup task IO rate. This output value can be directly sent to the backup read module as a new rate limiting parameter, or it can be first validated, boundary corrected, or smoothed by the scheduling control module before taking effect. For example, in some implementations, the rate adjustment range between two adjacent monitoring cycles can be further limited to no more than a preset ratio to avoid scheduling jitter caused by excessively rapid changes in the rate upper limit.

[0052] Furthermore, in this embodiment, the dynamic throttling algorithm can also be comprehensively adjusted based on the amount of data completed, the amount of data remaining, and the backup time limit requirements. For example, when the amount of data remaining is large and the system is under low pressure for a long time, the rate can be increased appropriately; while when the backup task is nearing completion, the adjustment sensitivity can be reduced to avoid meaningless large fluctuations in the final stage. By incorporating task progress information into the rate calculation process, this application can further improve the fineness of dynamic throttling control.

[0053] Through step S3 described above, this embodiment of the application can dynamically generate the upper limit of the IO rate for backup tasks based on the real-time IO pressure status of the system, using a combination of graded response and gradual adjustment. Specifically, under high pressure, the backup rate is rapidly compressed; under medium pressure, the current rate is maintained and steadily increased; and under low pressure, the backup rate is gradually increased according to a preset growth strategy. Therefore, this application can improve the resource utilization efficiency and execution efficiency of backup tasks while ensuring the performance of production operations, achieving adaptive dynamic throttling control during cloud disk snapshot backup.

[0054] S4 limits the rate of backup data reading processes based on the upper limit of IO rate, so as to achieve dynamic throttling.

[0055] In this embodiment of the application, after calculating and outputting the upper limit of the IO rate of the backup task in real time through step S3, the backup data reading process is further limited in step S4 according to the upper limit of the IO rate, so as to realize dynamic throttling control of the backup task.

[0056] Specifically, step S4 includes: sending the backup task IO rate upper limit value output in step S3 to the backup data reading process, which then performs data reading operations according to the IO rate upper limit value. This ensures that the backup task is always controlled by the rate limiting policy corresponding to the current system state during actual operation. In other words, the rate upper limit value obtained in step S3 is not merely a theoretical calculation result, but is further transformed into an actual control parameter for backup reading behavior, directly affecting the data reading path during the backup process.

[0057] In this embodiment, the backup data reading process can be a task thread, process, or read / write module responsible for reading the data to be backed up from cloud disk snapshots, source volume data blocks, or incremental data areas. Rate limiting can be implemented through token buckets, leaky buckets, timed quota control, read request interval adjustment, concurrent read quantity control, or bandwidth shaping. In other words, any method that can convert the IO rate upper limit output in step S3 into a constraint on the backup read rate is applicable to this application.

[0058] In one optional implementation, this application embodiment may employ a token bucket mechanism to limit the rate of the backup data reading process. Specifically, the system, according to the IO rate upper limit output in step S3, releases a corresponding number of tokens into the token bucket at a preset time granularity. The backup data reading process needs to acquire tokens before initiating a data read request, and can only perform a read operation when it has acquired enough tokens. In this way, the total amount of data that the backup reading process can read per unit time is limited to within the IO rate upper limit, thereby achieving precise control over the bandwidth usage of the backup task.

[0059] In another alternative implementation, this embodiment of the application can also achieve rate limiting by controlling the amount of data allowed to be read within each monitoring cycle. For example, the IO rate limit can be converted into the maximum number of bytes or data blocks allowed to be read within the current monitoring cycle. When the backup data reading process reaches the limit within the current cycle, new read requests are paused until the next monitoring cycle begins. Through this periodic quota control method, the actual read rate of the backup task can also be controlled by the dynamically calculated rate limit.

[0060] Furthermore, in this embodiment, when rate limiting the backup data reading process, only the data reading path of the backup task can be controlled, without directly interfering with the normal IO request path of the production virtual machine. Therefore, this application can reduce the impact of backup operations on online services by constraining the resource consumption behavior of the backup task itself without changing the access logic of the production service. In other words, the dynamic throttling object of this application is mainly the IO resources consumed by the backup task, rather than passively limiting the production service, thus better ensuring the stability of the service side performance.

[0061] It should be noted that the rate limit is not fixed, but dynamically adjusted as the output of step S3 is updated. Specifically, in each monitoring cycle, the system re-acquires the current backup task's IO rate limit and applies the new limit to the backup data reading process. If the newly calculated rate limit is lower than the currently effective value, the backup data reading process reduces its reading rate accordingly; if the newly calculated rate limit is higher than the currently effective value, the backup data reading process increases its reading rate while meeting the control rules. Thus, the actual execution rate of the backup task can change synchronously with the system's real-time IO pressure, achieving true dynamic throttling.

[0062] To avoid sudden fluctuations when updating rate limit parameters, the process of the rate limit value taking effect can be smoothed out. For example, when the new rate limit value changes significantly compared to the current value, a phased adjustment can be used to gradually transition to the target value, or a maximum single-cycle change range can be set to prevent the backup data reading process from suddenly increasing or decreasing in speed within a short period. These methods can further improve the stability and control precision of backup tasks.

[0063] Furthermore, in this embodiment, while performing rate limiting control, the backup data reading process can continuously report operational information such as the current actual reading rate, the amount of data read within the period, the reading time, and the task progress. This operational information can be used to verify the effectiveness of the current rate limiting strategy, and can also be fed back to the subsequent monitoring and decision-making process as the data collection object in step S1, thus forming a closed-loop control mechanism of "indicator collection—pressure determination—rate calculation—rate limiting execution—status feedback." Through this closed-loop mechanism, this application can continuously adjust the execution rhythm of the backup task according to the actual system status, improving the real-time performance and adaptability of the overall control.

[0064] In this embodiment, by implementing the aforementioned rate limit on the backup data reading process, the backup task can automatically reduce resource consumption when the system IO pressure is high, and gradually increase backup efficiency when the system IO pressure is low, thereby achieving a dynamic balance between backup performance and business performance. Compared to fixed rate limiting, this application can adjust the backup task behavior in real time according to changes in system load; compared to static time window scheduling, this application does not rely on estimated low-peak business periods, but directly performs adaptive control based on real-time monitoring results, thus making it more suitable for cloud environments with frequent load changes and significant business fluctuations.

[0065] In summary, through step S4, this embodiment of the application transforms the upper limit of the IO rate calculated in step S3 into actual rate limiting control of the backup data reading process, enabling the dynamic throttling algorithm to truly apply to the backup execution process. Therefore, this application not only effectively reduces the performance impact of backup tasks on production virtual machines and the underlying storage system, but also maximizes the execution efficiency of backup tasks while ensuring business stability, thereby improving resource utilization and overall system reliability during cloud disk snapshot backup.

[0066] In the embodiments of this application, by implementing the above technical solution, the following beneficial effects can be obtained compared with the prior art: First, this application proposes a multi-dimensional real-time IO pressure perception model. Unlike existing technologies that typically rely on a single metric (such as IOPS or bandwidth), this application innovatively integrates business layer metrics and infrastructure layer metrics for analysis. Business layer metrics, such as virtual machine IO read / write latency, directly reflect the actual user experience, while infrastructure layer metrics, such as storage controller CPU utilization, cache utilization, and disk queue depth, reflect the operational status of underlying resources. By jointly collecting and comprehensively judging these multi-dimensional metrics, this application can construct a more comprehensive and accurate system IO pressure assessment model, effectively avoiding misjudgments caused by single metrics and improving the sensitivity and reliability of pressure identification.

[0067] Secondly, this application proposes a dynamic throttling algorithm based on feedback control. This algorithm uses real-time collected business IO metrics and storage system health metrics as feedback inputs to construct closed-loop control logic, dynamically adjusting the upper limit of the backup task's IO rate according to the system's IO pressure state. In the embodiments of this application, the core of this dynamic throttling algorithm includes two adjustment mechanisms: "decisive circuit breaking" and "gradual probing." When the system is under high pressure, the decisive circuit breaking mechanism is activated, rapidly compressing the backup IO rate to a preset minimum safe value, thereby prioritizing the performance stability of production services. When the system is under low pressure, the gradual probing mechanism is adopted, gradually increasing the backup IO rate in fixed steps or exponentially, making full use of idle resources without affecting business operations. When the system is under medium pressure, the current rate remains unchanged, maintaining a relatively stable collaborative relationship between the backup task and the business load. Through the above-mentioned graded response and dynamic adjustment mechanisms, this application can maximize backup efficiency while ensuring business performance, achieving a dynamic balance between performance and efficiency.

[0068] Furthermore, this application proposes a software-defined resource coordination architecture. In this embodiment, by constructing a system architecture consisting of an intelligent scheduling module and a backup execution module, automatic coordination and intelligent arbitration of IO resources between backup tasks and production operations are achieved. Specifically, the intelligent scheduling module is responsible for collecting system operating indicators, determining IO pressure status, and calculating rate control strategies, while the backup execution module limits the data reading process according to the strategies. Through this architecture design, this application can achieve fine-grained resource management through software-level intelligent control without modifying existing storage hardware or virtualization infrastructure. This software-defined implementation not only has good compatibility and scalability but also significantly reduces system modification costs and improves the practical implementation capability of the solution.

[0069] In summary, this application effectively solves the problem of difficulty in dynamically adjusting resource competition between backup tasks and production operations in existing technologies by using multi-dimensional pressure perception, feedback-based dynamic throttling algorithms, and software-defined resource collaboration architecture. While ensuring the stability of business performance, it improves the execution efficiency of backup tasks and the overall resource utilization of the system, and has good engineering application value and promotion significance.

[0070] Example 2 This invention also provides a cloud disk snapshot backup device based on IO pressure sensing and dynamic throttling, such as... Figure 2 As shown, the device includes: The first module 100 is used to collect disk I / O performance indicators of production business virtual machines and health status indicators of the underlying storage system in real time. The second module 200 is used to compare the collected indicators with preset thresholds to dynamically determine the current IO pressure status of the system. The third module 300 is used to calculate and output a backup task IO rate limit value in real time based on the IO pressure status using a dynamic throttling algorithm. The fourth module 400 is used to limit the rate of the backup data reading process based on the upper limit of the IO rate, so as to achieve dynamic throttling.

[0071] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0072] Example 3 To implement the methods of the above embodiments, the present invention also provides an electronic device, which includes a memory and a processor; wherein the processor runs a program corresponding to the executable program code by reading executable program code stored in the memory, so as to implement the various steps of the above methods.

[0073] Example 4 To implement the above embodiments, this application also proposes a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the methods as described in the foregoing embodiments.

[0074] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

[0075] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0076] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this invention, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

Claims

1. A cloud disk snapshot backup method based on IO pressure sensing and dynamic throttling, characterized in that, Includes the following steps: Real-time collection of disk I / O performance metrics of production virtual machines and health status metrics of the underlying storage system; The collected metrics are compared with preset thresholds to dynamically determine the current IO pressure status of the system. Based on the IO pressure status, the upper limit of the IO rate of the backup task is calculated and output in real time through a dynamic throttling algorithm; Based on the upper limit of the IO rate, the rate of the backup data reading process is limited to achieve dynamic throttling.

2. The method according to claim 1, characterized in that, Disk I / O performance metrics include I / O read / write latency, IOPS, and throughput; The underlying storage system health indicators include storage controller CPU utilization, cache utilization, disk queue depth, and the current read rate, completed data volume, and remaining data volume of backup tasks.

3. The method according to claim 2, characterized in that, The collected metrics are compared with preset thresholds to dynamically determine the current IO pressure status of the system, including: The collected indicators are compared with preset thresholds to dynamically determine the system IO pressure status as high pressure, medium pressure, or low pressure.

4. The method according to claim 3, characterized in that, Based on the IO pressure status, a dynamic throttling algorithm is used to calculate and output the upper limit of the IO rate for the backup task in real time, including: When the IO pressure is high, set the maximum IO rate of the backup task to 10% of the baseline value; When the IO pressure is at a medium level, set the maximum IO rate of the backup task to maintain the current rate. When the IO pressure is low, set the backup task IO rate cap to the current rate. Gradually improve The monitoring period is until the bandwidth limit is reached or business metrics fluctuate.

5. A cloud disk snapshot backup device based on IO pressure sensing and dynamic throttling, characterized in that, include: The first module is used to collect disk I / O performance metrics of production business virtual machines and health status metrics of the underlying storage system in real time. The second module is used to compare the collected indicators with preset thresholds to dynamically determine the current IO pressure status of the system. The third module is used to calculate and output a backup task IO rate limit in real time based on the IO pressure status using a dynamic throttling algorithm. The fourth module is used to limit the rate of backup data reading processes based on the upper limit of IO rate, so as to achieve dynamic throttling.

6. An electronic device, characterized in that, Including processor and memory; The processor runs a program corresponding to the executable program code by reading the executable program code stored in the memory, so as to implement the method as described in any one of claims 1-6.

7. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-6.

Images