State self-repairing method and device for thick standby volume in distributed storage

Abstract

The invention provides a state self-repairing method and device for a thick backup volume in distributed storage, and relates to the technical field of distributed storage system state self-repairing technology.The method comprises the steps that metadata state information of the thick backup volume is obtained, and whether the volume is in a formatted state or not is judged; if the volume is in the formatting state, performing layered random sampling verification on the physical data of the volume, and identifying that the volume is a false abnormal volume or a true abnormal volume; if the volume is the false abnormal volume, only updating the metadata state into a formatting completion state; if the volume is a true abnormal volume, determining a breakpoint by adopting a binary search method; the method comprises the steps of collecting IOPS and bandwidth data of a cluster in real time, dynamically calculating a formatting quota, pausing formatting operation and storing current breakpoint coordinates when a cluster load exceeds a preset threshold value, and recovering the formatting operation from the stored breakpoint coordinates when the load is reduced to be below the threshold value. By means of the method and device, separation of metadata and physical data is effectively avoided, the repairing efficiency is remarkably improved, and storage resource consumption is reduced.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of distributed storage system state self-repair, and particularly relates to a thick provisioning volume state self-repair method and device in a distributed storage. BACKGROUND

[0002] As a key resource management mechanism in a distributed storage system, thick provisioning volumes are widely used in cloud computing, virtualization and large-scale data processing scenarios. The core feature is to pre-allocate storage space to ensure the determinacy and stability of data writing, but the accuracy of state management and repair efficiency directly affect the overall performance and resource utilization of the system. In related technologies, the state of the volume is usually identified and repaired by metadata state markers and static scanning strategies, and a full-process management framework is constructed from volume creation, state monitoring to exception handling. Specifically, the technology system covers key links such as metadata maintenance, physical data verification, formatting control and resource scheduling, among which the metadata state (such as thick_state) is used to identify the formatting stage of the volume, and the physical data verification relies on a fixed sampling strategy or a full-volume scanning mechanism to determine whether the volume is in an abnormal state. With the continuous expansion of the storage cluster size, the traditional method gradually exposes systematic bottlenecks in aspects such as abnormal volume misjudgment, repair efficiency and resource conflicts, and a more efficient and intelligent collaborative management mechanism is urgently needed.

[0003] However, in the existing thick provisioning volume state management method, the volume state is directly judged by a single metadata state without dynamic verification combined with physical data, which may cause the metadata and physical data to be out of sync, resulting in false abnormal volume misjudgment as true abnormal volume, and further causing invalid occupation of storage resources. Specifically, the existing technology usually uses a full-volume scanning method to repair abnormal volumes, which is not only inefficient, but also significantly increases the system load and energy consumption in large-capacity volume scenarios. In addition, there is a lack of dynamic coordination mechanism between formatting operations and business I / O, which easily causes resource preemption conflicts in high-concurrency scenarios, resulting in a sharp rise in business delay. In a super-large-scale cluster, the above problems are particularly prominent, not only affecting the real-time response capability of the storage system, but also reducing the reliability and availability of the overall service, limiting the application potential of thick provisioning volumes in high-performance storage architectures. SUMMARY

[0004] The present application aims to at least partially solve one of the technical problems in the related art.

[0005] To this end, a first object of the present application is to propose a thick provisioning volume state self-repair method in a distributed storage.

[0006] A second object of the present application is to propose a device.

[0007] A third object of the present application is to propose an electronic device.

[0008] A fourth object of the present application is to propose a computer-readable storage medium.

[0009] A fifth object of the present application is to propose a computer program product.

[0010] To achieve the above object, the first aspect of the present application proposes a method for self-repairing the state of a thick backup volume in distributed storage, comprising:

[0011] S1, obtaining metadata state information of the thick backup volume, and determining whether the volume is in a formatting-in-progress state; S2, if the volume is in the formatting-in-progress state, dynamically dividing the block size and scanning density based on the volume capacity and historical abnormal patterns, performing hierarchical random sampling verification on the physical data of the volume, and identifying the volume as a false abnormal volume or a true abnormal volume; S3, if the volume is a false abnormal volume, only updating the metadata state to a formatting-completed state; if the volume is a true abnormal volume, using a binary search method to determine the physical address of the last non-0 data as a breakpoint, and continuing the formatting operation from the breakpoint position while recording the formatting progress in real time; S4, collecting IOPS and bandwidth data of the cluster in real time, dynamically calculating the formatting quota, pausing the formatting operation and storing the current breakpoint coordinates when the cluster load exceeds a preset threshold, and resuming the formatting operation from the stored breakpoint coordinates when the load drops below the threshold.

[0012] To achieve the above object, the second aspect of the present application proposes a device for self-repairing the state of a thick backup volume in distributed storage, comprising: a state obtaining module configured to obtain metadata state information of the thick backup volume, and determine whether the volume is in a formatting-in-progress state; an abnormality identifying module configured to, if the volume is in the formatting-in-progress state, dynamically divide the block size and scanning density based on the volume capacity and historical abnormal patterns, perform hierarchical random sampling verification on the physical data of the volume, and identify the volume as a false abnormal volume or a true abnormal volume; a state repairing module configured to, if the volume is a false abnormal volume, only update the metadata state to a formatting-completed state; if the volume is a true abnormal volume, use a binary search method to determine the physical address of the last non-0 data as a breakpoint, and continue the formatting operation from the breakpoint position while recording the formatting progress in real time; a quota control module configured to collect IOPS and bandwidth data of the cluster in real time, dynamically calculate the formatting quota, pause the formatting operation and store the current breakpoint coordinates when the cluster load exceeds a preset threshold, and resume the formatting operation from the stored breakpoint coordinates when the load drops below the threshold.

[0013] To achieve the above object, the third aspect of the present application provides an electronic device, comprising: a processor, and a memory connected with the processor in communication; The memory stores computer execution instructions. The processor executes the computer execution instructions stored in the memory to realize the method according to any one of the first aspect.

[0014] To achieve the above object, the fourth aspect of the present application provides a computer readable storage medium, wherein the computer readable storage medium stores computer execution instructions, and the computer execution instructions are executed by a processor to realize the method according to any one of the first aspect.

[0015] To achieve the above object, the fifth aspect of the present application provides a computer program product, wherein the computer program is executed by a processor to realize the method according to any one of the first aspect.

[0016] The technical scheme provided by the embodiments of the present application at least brings the following beneficial effects: The thick backup volume can be accurately distinguished from the true and false abnormal state, the misjudgment and resource waste are effectively reduced, and the repair efficiency and storage system stability are improved.

[0017] Additional aspects and advantages of the present application will be in part apparent and in part pointed out hereinafter. BRIEF DESCRIPTION OF DRAWINGS

[0018] The above and / or additional aspects and advantages of the present application will become apparent and be readily understood from the following description, taken in conjunction with the accompanying drawings, in which: Figure 1 A flowchart of a thick backup volume state self-repairing method in a distributed storage provided by an embodiment of the present application; Figure 2 A structural diagram of a thick backup volume state self-repairing device in a distributed storage provided by an embodiment of the present application. DETAILED DESCRIPTION

[0019] The embodiments of the present application are described in detail below, and examples of the embodiments are shown in the drawings, wherein the same or similar reference signs represent the same or similar elements or elements having the same or similar functions throughout. The embodiments described below by referring to the drawings are exemplary and are intended to explain the present application, and cannot be understood as a limitation of the present application.

[0020] The embodiments of the present application provide a thick backup volume state self-repairing method in a distributed storage, Figure 1A flowchart of a state self-repairing method for a thick-provisioned volume in a distributed storage provided by an embodiment of the present application is shown in FIG. 1. As shown in FIG. 1, the method comprises the following steps: Figure 1 Step S1, obtaining metadata state information of the thick-provisioned volume, and determining whether the volume is in a formatting state.

[0021] In this embodiment, the step of "obtaining metadata state information of the thick-provisioned volume, and determining whether the volume is in a formatting state" is a key entry point of the thick-provisioned volume state self-repairing mechanism in the present application. The technical implementation is based on the analysis of the volume metadata and the judgment of the state identifier, which ensures that the system can accurately identify whether the current volume is in a formatting state, so as to determine whether to start the subsequent dynamic block sampling and breakpoint resume process.

[0022] In terms of technical implementation, the system first reads the metadata information of the volume through a storage management interface (such as the Ceph RBD interface), which contains a key state field thick_state. The field is used to identify the formatting state of the volume, and its value follows the definition as follows: thick_state=0 represents a thin volume; thick_state≠0 represents a thick-provisioned volume, wherein thick_state=1 represents that the formatting has been completed, and thick_state=2 represents that the current volume is in the formatting process. The system judges whether to perform the continue formatting operation on the volume by analyzing the value of the field.

[0023] In terms of parameter index, the definition of the thick_state field needs to comply with the metadata specification of the storage system, which is usually stored in the metadata table of the volume, such as the rbd_info structure of RBD or the image spec metadata area of Ceph. The state update needs to be ensured consistent through atomic operation to prevent state confusion caused by concurrent operation. In addition, the reading of the field needs to support high-concurrency access, and the response time should be controlled within milliseconds to meet the needs of fast state identification in large-scale clusters.

[0024] In terms of application scenarios, this step is commonly used in state synchronization scenarios after cluster fault recovery, node restart, or formatting interruption. For example, in a distributed storage system, when a node is restarted after being down, the system needs to scan the state of all thick-provisioned volumes to identify the volumes in the "formatting" state to resume the unfinished formatting tasks. This step serves as the trigger condition of the entire self-repairing process, ensuring that only the volumes in abnormal state are processed, avoiding unnecessary interference to normal volumes.

[0025] ​At the technical effect level, this step realizes accurate identification of the thick standby volume state by introducing the state identification field thick_state, effectively avoiding the misjudgment problem caused by relying only on metadata marking in the traditional scheme. At the same time, this step provides clear execution conditions for the subsequent dynamic block sampling and breakpoint writing process, which is the prerequisite guarantee for the efficient operation of the entire self-repair mechanism. Through this mechanism, the system can quickly identify and process abnormal volumes in large-scale clusters, significantly improving the stability and resource utilization of the storage system.

[0026] Step S2, if it is a formatting state, based on the volume capacity and historical abnormal mode, dynamically divide the block size and scanning density, and perform hierarchical random sampling verification on the physical data of the volume to identify the volume as a false abnormal volume or a true abnormal volume.

[0027] In this embodiment, when it is detected that the thick standby volume is in the "formatting" state (i.e., the metadata state thick_state = 2), the system will dynamically divide the block size and scanning density based on the volume capacity and historical abnormal mode (history_risk) to perform hierarchical random sampling verification on the physical data of the volume to identify the volume as a false abnormal volume or a true abnormal volume. This step is the core link of the "double insurance state self-repair mechanism" of the present application, which aims to improve the accuracy and efficiency of abnormal volume identification through intelligent sampling strategies, while reducing the occupation of system resources.

[0028] From the technical implementation point of view, this step first divides the block size and the basic scanning density according to the volume capacity. Specifically, when the volume capacity is ≤100GB, the block size is 4KB and the basic density is 16 sampling points / GB; when 100GB < volume capacity ≤1TB, the block size is 1MB and the basic density is 4 sampling points / GB; when 1TB < volume capacity ≤10TB, the block size is 4MB and the basic density is 1 sampling point / GB; when volume capacity >10TB, the block size is 64MB and the basic density is 0.1 sampling points / 10GB. On this basis, combined with the historical abnormal mode history_risk (range [0,1]), the final scanning density is dynamically calculated by the formula final_density = base_density (1 + history_risk 2) to realize differentiated processing of volumes with different risk levels.

[0029] Further, the system adopts a hierarchical random sampling strategy, divides the volume space into multiple 1 GB level segments, and ensures that there is at least one sampling point in each level segment. The remaining sampling points are randomly allocated to each level segment to improve the uniformity of sampling coverage. During the sampling process, if the number of consecutive zero blocks detected exceeds the dynamically calculated threshold, the skip mechanism is triggered to skip the subsequent zero blocks, thereby reducing unnecessary sampling operations. The skip step is dynamically adjusted according to the continuous zero count to ensure that the skip step grows within a reasonable range.

[0030] At the application scenario level, this step is applicable to the abnormal state repair scenario of thick backup volumes in a distributed storage system, especially in the case of cluster fault recovery, expansion operation, or recovery after formatting interruption. By dynamically adjusting the sampling strategy, the system can significantly reduce the resource consumption and time overhead of abnormal volume detection while ensuring data integrity.

[0031] Further, S2 includes: S21, dividing the block size into four levels according to the volume capacity, wherein the block size is 4KB when the volume capacity is less than or equal to 100GB.

[0032] Specifically, this step involves dividing the block size into four levels according to the volume capacity, wherein the block size is set to 4KB when the volume capacity is less than or equal to 100GB. This technical implementation is a key parameter configuration link in the dynamic block sampling algorithm, and its core purpose is to improve the efficiency and accuracy of abnormal volume detection through a reasonable block division strategy, while taking into account the performance and resource utilization of the storage system.

[0033] Technical implementation level: In some implementations, this step sets the block size based on the total capacity of the volume. Specifically, when the volume capacity is less than or equal to 100GB, the system sets the block size to 4KB. This setting mainly considers the data distribution characteristics of small capacity volumes, i.e., in a smaller storage space, the access frequency of data blocks is higher, and the degree of data fragmentation is relatively large. Using a 4KB smaller block can improve sampling accuracy and ensure coverage of potential non-zero data, thereby improving the reliability of abnormal detection. In addition, the 4KB block size conforms to the common minimum I / O unit (IO Block Size) standard in storage systems, facilitating compatibility with I / O operations of the underlying storage engine (such as Ceph RBD), and reducing additional performance overhead.

[0034] Parameter index level: The key parameters involved in this step include the volume capacity threshold (100 GB), the block size (4 KB), and the base density (16 / GB). Among them, 16 / GB means that 16 4KB-sized blocks will be sampled per GB of storage space. This density setting is based on empirical models and system performance test results, ensuring that enough sampling points are covered in small-capacity volumes, and that the system throughput is not affected by excessive sampling density. In actual deployment, this parameter can be fine-tuned according to the IOPS performance of the storage cluster, the type of storage medium (such as SSD or HDD), to adapt to the performance requirements in different hardware environments.

[0035] Application scenario level: This step is suitable for abnormal state detection and repair scenarios of thick backup volumes in distributed storage systems, especially in business environments with small volume capacity (≤100 GB), such as virtual machine image storage, database log volumes, etc. In these scenarios, data is distributed densely, and a 4KB sampling granularity can more effectively identify abnormal areas, avoiding the problem of missing non-zero data due to a large sampling granularity, which can lead to false positives or incomplete repair.

[0036] Technical effect level: By setting the sampling block size of small-capacity volumes to 4KB, this step significantly improves the accuracy and efficiency of abnormal volume detection. On the one hand, a 4KB sampling granularity can more finely cover potential non-zero data areas, reducing the false positive rate of abnormal volumes; on the other hand, this setting matches well with the I / O unit of the storage system, reducing additional read-write overhead and improving overall processing performance. Further, this step provides basic parameter support for subsequent dynamic density adjustment, hierarchical random sampling, and breakpoint resume writing, which is a key prerequisite for efficient and intelligent volume state self-repair.

[0037] S22, in combination with the historical abnormal pattern history_risk, calculates the final scanning density according to the formula final_density=base_density×(1+history_risk×2), where base_density is the base density determined according to the volume capacity, and history_risk is the historical abnormal risk value recorded in the volume metadata, ranging from [0, 1].

[0038] Specifically, the step involves an algorithm for dynamically adjusting the scanning density, which is based on the base density determined according to the volume capacity and the history risk value recorded in the volume metadata. The final scanning density (final_density) is calculated by the formula final_density = base_density × (1 + history_risk × 2). This algorithm is a key component of the "dynamic block sampling algorithm" in the present application, which is used to dynamically optimize the sampling density according to the historical abnormal patterns of the volume during the self-repair process of the thick standby volume, thereby improving the system efficiency while ensuring the detection accuracy.

[0039] In terms of technical implementation, the base_density is a preset density level divided according to the volume capacity, which is divided into four intervals: when the volume capacity is less than or equal to 100GB, the block_size is 4KB and the base_density is 16 / GB; when the volume capacity is greater than 100GB and less than or equal to 1TB, the block_size is 1MB and the base_density is 4 / GB; when the volume capacity is greater than 1TB and less than or equal to 10TB, the block_size is 4MB and the base_density is 1 / GB; and when the volume capacity is greater than 10TB, the block_size is 64MB and the base_density is 0.1 / GB. The history_risk is a floating-point parameter with a value range of [0, 1], which is used to quantify the historical abnormal risk degree of the volume, with 0 indicating no abnormal record and 1 indicating frequent abnormality. This value is stored in the metadata of the volume and is updated after each sampling operation.

[0040] Further, the calculation method of final_density reflects the adaptive characteristics of the present application. By multiplying the history_risk by 2 and adding it to 1, the volume with a higher historical abnormal risk has a higher scanning density, thereby enhancing the detection capability of potential abnormalities. For example, when history_risk = 0.5, final_density = base_density × 2, which means that the sampling frequency is doubled, suitable for fine detection of high-risk volumes; and when history_risk = 0, final_density = base_density, only the basic sampling is performed, suitable for efficient processing of low-risk volumes.

[0041] In application scenarios, the algorithm is widely applicable to the abnormality detection and repair process of thick provisioning volumes in distributed storage systems. Especially in large-scale cluster environments, by dynamically adjusting the scanning density, unnecessary I / O operations can be effectively reduced, system load can be reduced, and the accuracy of abnormal volume identification can be improved. This step is closely coordinated with the subsequent hierarchical random sampling and real-time density adjustment mechanism to form a complete self-repair process, significantly improving the processing efficiency and stability of thick provisioning volumes in fault recovery, expansion, migration and other scenarios.

[0042] The technical effect of this step is that by combining the metadata state and dynamic block sampling verification of physical data, it can effectively distinguish between false abnormal volumes and true abnormal volumes, avoiding resource waste or data risks caused by false positives. For false abnormal volumes, only the metadata state (thick_state = 1) needs to be updated to restore its availability; for true abnormal volumes, precise repair is performed through subsequent breakpoint positioning and overwrite mechanisms, thereby implementing an efficient and low-disturbance self-repair process and improving the overall operating efficiency and stability of the storage system.

[0043] Step S3, if it is a false abnormal volume, only update the metadata state to a formatted completion state.

[0044] In this embodiment, the step content is: if it is a false abnormal volume, only update the metadata state to a formatted completion state.

[0045] In a distributed storage system, thick provisioning volumes (Thick Provisioning Volume) are pre-allocated with all storage space after creation and need to be formatted to ensure they are in a usable state. In the system fault recovery or abnormality detection process, if the metadata state of the volume (thick_state) shows "formatting" (thick_state = 2), but all sample blocks are found to be all 0 data through dynamic block sampling verification, it is determined that the volume is a false abnormal volume. At this time, no full volume formatting operation is needed, only the metadata state needs to be updated to "formatting complete" (thick_state = 1), which can restore its availability.

[0046] Technical implementation level: The core of this step is to avoid redundant formatting on volumes with no actual data residues through the collaborative verification of physical data sampling and metadata state. In actual operation, the system samples the volume through a dynamic block sampling algorithm. If all sampling points return all 0 data, it is determined that the volume is a false abnormal volume. At this time, the system calls the metadata update interface to update the thick_state field of the volume from “formatting” (2) to “formatting completed” (1), and synchronously clears the temporary metadata records related to the formatting progress. This operation is completed through the metadata management module of the storage system, usually involving atomic update operations on the volume metadata table to ensure the transaction consistency of state switching.

[0047] Parameter index level: The determination of this step depends on the output results of the dynamic block sampling algorithm. The sampling density is dynamically calculated by the formula final_density=base_density×(1+history_risk×2), where base_density is divided into different levels according to the volume capacity (such as 16 / GB for less than 100GB, 4 / GB for 100GB-1TB, etc.), and history_risk is the historical abnormal risk coefficient of the volume, ranging from [0, 1]. In the sampling process, if the number of consecutive all-0 blocks exceeds the dynamically calculated threshold, the jump mechanism is triggered to further reduce the number of sampling points. When all sampling points are all 0, the system determines that the volume is a false abnormal volume and performs metadata state update operations.

[0048] Application scenario level: This step is suitable for the scenario of quickly repairing the state of thick backup volumes after fault recovery, node restart, or abnormal volume state detection in a storage system. For example, in a large-scale distributed storage cluster, when a node is restarted after a failure, the system automatically triggers the volume state scanning process. If a thick backup volume is marked as “formatting” due to interrupted formatting, but no non-0 data has been written, the system can quickly identify and update its state to “formatting completed”, avoiding resource waste and business delay.

[0049] Further, S3 includes: S31, initializing the search range as the start address and end address of the thick backup volume, and determining the last physical address LAB_X storing non-0 data through multiple binary search.

[0050] Specifically, this step involves determining the last physical address LAB_X of non-zero data in a thick provisioning volume during state self-repair in a distributed storage system using binary search. This step is a key link in the "double insurance state self-repair mechanism" and is used to accurately identify the breakpoint position of the true abnormal volume, thereby enabling efficient breakpoint write operation and avoiding resource waste and performance bottlenecks caused by full volume formatting.

[0051] At the technical implementation level, this step first initializes the search range by setting low to the starting block index of the thick provisioning volume (0) and high to the last block index of the volume, which is the total size of the volume divided by the block size (block_size) minus 1. In each iteration, the system calculates the middle block index mid = (low + high) / / 2 and reads the data content of the block. By hash verification or all-0 pattern comparison, it determines whether the block is all-0 data. If the middle block is non-0, it means that the last non-0 block may be located after mid, so set low to mid + 1. If the middle block is all-0, set high to mid - 1 to narrow the search range. This process continues to iterate until low > high, at which point high points to the index of the last non-0 data block, corresponding to the physical address LAB_X.

[0052] At the parameter index level, the block size block_size is dynamically adjusted according to the volume capacity, for example, 4KB blocks are used for volumes below 100GB, 1MB blocks for 100GB to 1TB, 4MB blocks for 1TB to 10TB, and 64MB blocks for volumes exceeding 10TB. In addition, the block index calculation involved in this step needs to be based on the total size of the volume volume_size (in bytes) and the block size block_size to ensure the accuracy of the index range. In actual application, this step is usually run on the metadata management node or distributed coordination service of the storage cluster to quickly locate the breakpoint and resume the formatting process when the volume state is abnormal.

[0053] The technical effect of this step is that binary search significantly improves the efficiency of breakpoint positioning, especially suitable for large-scale storage volume repair scenarios. Compared with linear scanning, its time complexity is O(log N), significantly reducing the number of I / O operations and system resource consumption. At the same time, this mechanism ensures the continuity and consistency of the formatting operation, avoiding repeated execution of the repair process due to system interruption, thereby improving the availability and stability of thick provisioning volumes in a distributed environment.

[0054] S32, starting from the LAB_X address, performing a write 0 operation to the volume in units of block_size, until the end of the volume, and recording the current write position as the formatting progress after completing each block_size of write 0 operation.

[0055] Specifically, this step involves performing a breakpoint resume write formatting operation on a thick provisioning volume in a distributed storage system, which is technically implemented based on the synergy of the "metadata-physical data double-checking" mechanism and the dynamic block sampling algorithm. After identifying the real abnormal volume and locating its end non-0 address LAB_X, the system will start from this address, perform a write 0 operation to the remaining space of the volume in units of a preset block_size, until the end of the volume. During this process, after completing each block_size of write 0 operation, the system records the current write position as the formatting progress, to ensure that after formatting interruption or system failure recovery, it can continue to perform from the last interruption point, avoiding repeated operations and improving formatting efficiency.

[0056] In specific implementation, the size of block_size is determined by the volume capacity, for example, when the volume capacity is greater than 10TB, block_size is 64MB. The write 0 operation adopts a sequential write-in manner, and full 0 data is written block by block through the underlying I / O interface (such as RadosBlock Device, RBD) of the storage system. Each time the write-in is completed, the system records the current write-in logical block address (LBA) to a preset metadata area, which is usually located in the metadata table of the volume, for storing formatting progress information. The recorded formatting progress includes the starting address of the current write-in, the write-in length, and the check state, ensuring that after system restart or task interruption, it can be quickly recovered.

[0057] In the business high-load scenario, the system collects cluster IOPS and bandwidth data in real time through a dynamic traffic scheduling strategy, and when the load exceeds the preset threshold, the formatting operation will be paused, and the current progress will be written to the metadata. After the load decreases, the system resumes the write 0 operation from the breakpoint, with a lower priority than the business I / O, to avoid interference with normal business. This step plays a key role in the overall technical solution, significantly improving the interruption recovery capability and resource utilization of the thick provisioning volume formatting process through the breakpoint resume write mechanism, and combining dynamic block sampling and binary search method, realizing an efficient and accurate abnormal volume repair process.

[0058] Technical effect level: This step effectively improves the resource utilization and response efficiency of the storage system. By updating only the metadata rather than performing full volume formatting, unnecessary I / O overhead and storage resource occupation are avoided, which can significantly reduce system load, especially in large-scale clusters. In addition, this mechanism ensures the consistency of metadata and physical data, preventing data coverage or business interruption caused by misjudgment, thereby enhancing the stability and reliability of the system.

[0059] Step S4, real-time collection of IOPS and bandwidth data of the cluster, dynamic calculation of formatting quota, suspension of formatting operation when the cluster load exceeds the preset threshold and storage of the current breakpoint coordinates, resumption of formatting operation from the stored breakpoint coordinates when the load drops below the threshold.

[0060] In this embodiment, the step of "real-time collection of IOPS and bandwidth data of the cluster, dynamic calculation of formatting quota, suspension of formatting when the cluster load exceeds the preset threshold and storage of the current breakpoint coordinates, resumption of formatting operation from the stored breakpoint coordinates when the load drops below the threshold" in the present application is one of the core mechanisms for realizing self-repairing of thick backup volume state and resource coordination management. Its technical implementation is based on the dynamic resource scheduling strategy and breakpoint resume technology of distributed storage systems, with high real-time and intelligent features.

[0061] In terms of technical implementation, this step collects IOPS (input / output operations per second) and bandwidth (data transfer rate) indicators of the cluster in real time through the monitoring module deployed on the storage controller or management node. The collection frequency can be configured from every second to every minute, depending on the cluster size and business sensitivity. The collected data is transmitted to the scheduling engine through a lightweight communication protocol (such as gRPC or RDMA). The scheduling engine dynamically calculates the current allowed formatting operation quota based on the preset resource quota model. This quota model can use linear scaling or weighted resource allocation algorithms to map cluster load and resource consumption of formatting tasks, thereby determining whether to allow formatting to continue execution.

[0062] When the cluster IOPS or bandwidth exceeds the preset threshold (such as IOPS>10000 or bandwidth>10GB / s), the scheduling engine triggers the formatting suspension mechanism and writes the breakpoint coordinates (i.e. the last processed block address LAB_X) in the current formatting progress to the metadata area of the volume (such as the metadata area of XFS or Btrfs file system, or a custom volume state table). The breakpoint coordinates are stored in the form of physical block addresses, with precision up to 4KB to 64MB level, depending on the block_size configuration of the volume.

[0063] When the cluster load falls below the threshold, the scheduling engine reactivates the formatting process, first reading the stored breakpoint coordinates, and then starting the append process based on the coordinates. During the append process, the resource preemption priority of the formatting task is set lower than the business I / O operation, ensuring that the business performance is not affected. This mechanism conforms to the common QoS (Quality of Service) management specifications in distributed storage systems, such as the PG scheduling strategy of Ceph or the I / O priority control model in distributed file systems.

[0064] Further, S4 comprises: S41, when the cluster IOPS or bandwidth exceeds the preset threshold, suspending the formatting operation, and storing the current breakpoint coordinates to the preset metadata area.

[0065] Specifically, this step involves a key control mechanism in a dynamic flow scheduling strategy, which is based on real-time monitoring of cluster resource load and intelligent suspension and recovery of formatting operations. In distributed storage systems, the formatting operation of thick backup volumes usually requires a large amount of I / O resources, and if it is executed during the business peak period, it will cause the cluster IOPS or bandwidth resources to be tight, and then cause the business I / O delay to rise, affecting the overall performance of the system. Therefore, the present application introduces a dynamic scheduling strategy based on load threshold, which dynamically determines whether to suspend the formatting operation by collecting real-time cluster IOPS and bandwidth data, combined with a preset resource quota model.

[0066] In specific implementation, the system periodically (such as every second or every 500 milliseconds) collects the IOPS and bandwidth usage of the entire cluster, and compares it with the preset resource threshold. The threshold can be dynamically configured based on the cluster size, business type and historical load pattern, for example, for a 1000-node cluster, the IOPS threshold can be set to 100,000 IOPS, and the bandwidth threshold can be set to 10 Gbps. When it is detected that either of the current IOPS or bandwidth exceeds the threshold, the system immediately triggers the formatting suspension mechanism, and writes the breakpoint coordinates (i.e. the last non-0 address LAB_X formatted to) of the current formatting operation into the preset metadata area, such as the metadata table of the volume or the special state table of the storage pool, ensuring the persistent storage of the breakpoint information.

[0067] Further, the metadata area needs to have high availability and low latency access characteristics, and is usually deployed in a distributed metadata service (such as Ceph's MDS or a custom metadata storage module), and uses atomic write operation to prevent concurrent write conflicts. The storage format of the breakpoint coordinates should include the volume ID, breakpoint offset (in block_size units), current formatting progress state, etc. fields, so as to quickly locate and append during subsequent recovery operations.

[0068] This step is particularly suitable for resource coordination during volume state repair or expansion operations during peak business periods in large-scale distributed storage clusters in actual application scenarios. For example, in a cloud data center or enterprise storage system, when a user initiates a large number of read and write requests, the system can automatically pause the formatting task to avoid resource contention, and then resume the formatting process from the breakpoint after the load decreases, thereby achieving dynamic balance between business and maintenance operations.

[0069] The value of this technical solution lies in significantly improving the resource scheduling efficiency and business continuity of the storage system. Through the intelligent pause and breakpoint resume mechanism, the system can maintain low latency for business I / O under high load while ensuring the integrity and recoverability of the formatting operation, effectively avoiding formatting interruption and repeated operations due to resource conflicts in traditional solutions, and improving overall operation and maintenance efficiency and system stability.

[0070] S42, when the cluster load decreases below the threshold, resume the formatting operation from the stored breakpoint coordinates, and set the resource preemption priority of the formatting operation and business I / O lower than the preset value during the recovery process.

[0071] Specifically, when the cluster load decreases below the preset threshold, the system will resume the formatting operation from the stored breakpoint coordinates, and set the resource preemption priority of the formatting operation and business I / O lower than the preset value during the recovery process. This step is a key link in the dynamic traffic scheduling strategy of the present application, and is aimed at realizing the resource elastic allocation and efficient self-repairing capability of the storage system under high-concurrency business scenarios.

[0072] In terms of technical implementation, the system dynamically evaluates the load state of the current storage resources by monitoring the IOPS (input / output operations per second) and bandwidth usage of the cluster in real time. When the cluster load (IOPS or bandwidth) is detected to be lower than the set recovery threshold, the system first reads the breakpoint coordinates (LAB_X) recorded when the formatting was interrupted from the metadata area. The coordinates are accurately determined by the binary search method during formatting interruption. Subsequently, the system starts the resume writing process based on the breakpoint coordinates to continue the formatting operation, i.e., writes all 0 data to the volume in block_size units until the end of the volume. In this process, the system sets the priority of the formatting operation to be lower than the preset priority threshold of the business I / O through the resource scheduling module, ensuring that the business request can obtain the storage resource preferentially, thereby avoiding interference of the formatting operation on the business performance.

[0073] In terms of parameter indicators, the cluster load threshold can be configured according to actual business needs, and is usually set to 70-80% of the maximum IOPS or bandwidth of the system. The setting of the resource preemption priority depends on the scheduling strategy of the storage system. For example, in the Linux CFS (Completely Fair Scheduler) or QoS (Quality of Service) strategy of the storage controller, the priority of the formatting operation can be set to a lower priority level than the business I / O, for example, the scheduling weight of the formatting task is set to 100, and the business I / O is set to 500, so as to ensure that the business I / O has a higher priority in resource competition.

[0074] In application scenarios, this step is widely applicable to thickly provisioned volume state repair and expansion operations in large-scale distributed storage systems. For example, in a cloud data center or enterprise-level storage cluster, when a storage node restarts due to failure, the system needs to recover the thickly provisioned volume in the interrupted formatting state. At this time, if the business load is low, the system can immediately resume the formatting operation without affecting the ongoing business I / O request, thereby realizing efficient utilization of storage resources and business continuity guarantee.

[0075] This step plays a key role in the overall technical solution, which realizes intelligent suspension and recovery of formatting operations by dynamically sensing the cluster load state, effectively alleviating the resource competition between formatting tasks and business I / O, and improving the stability and response capability of the system in high-concurrency scenarios. At the same time, the storage and recovery mechanism of the breakpoint coordinates ensures the continuity and reliability of the formatting process, avoiding repeated operations due to interruptions, thereby significantly improving the repair efficiency and resource utilization of thickly provisioned volumes.

[0076] Step S5, dynamically adjusting the sampling density before the formatting operation starts according to the current state and historical abnormal mode of the volume, wherein the sampling density is reduced by 20% when the historical abnormal mode is 0.

[0077] In this embodiment, this step involves dynamically adjusting the sampling density before the thickly provisioned volume formatting operation starts according to its current state and historical abnormal mode, in order to optimize the abnormal detection efficiency and resource utilization. Specifically, when the historical abnormal mode (history_risk) is 0, it means that the volume has not appeared abnormal, and the system reduces the sampling density by 20%, thereby reducing unnecessary physical data verification operations and improving overall performance.

[0078] At the technical implementation level, this step is based on the metadata state (thick_state) of the volume and the historical abnormal pattern to make a judgment. If the volume state is 2 (i.e. formatting is in progress), the dynamic block sampling process is entered. The adjustment of the sampling density depends on the product relationship between the base density (base_density) and the historical abnormal pattern, and the final scanning density is calculated by the formula final_density = base_density × (1 + history_risk × 2). When history_risk = 0, final_density = base_density × 1, that is, the sampling density is reduced by 20%. This mechanism reduces the number of sampling points and reduces the system I / O load, while ensuring that the key data area is still effectively covered.

[0079] At the parameter index level, the adjustment of the sampling density needs to be combined with the volume capacity level division. For example, for a volume with a volume capacity ≤ 100 GB, the base density is 16 sampling points / GB, and when history_risk is 0, final_density is reduced to 12.8 sampling points / GB. In addition, the hierarchical random sampling mechanism ensures that each GB segment has at least one sampling point, avoiding sampling blind areas. The sampling point offset is generated by a random algorithm and sorted within the full_count range, and the offset is calculated in bits.

[0080] At the application scenario level, this step is suitable for the thick backup volume state self-repair process in a distributed storage system, especially after cluster failure recovery, the system needs to check the state of a large number of volumes, which can significantly reduce resource consumption. For example, in the repair process of a 10TB level volume, if history_risk is 0, the number of sampling points can be reduced from 10,000 to 8,000, effectively relieving the I / O pressure of the storage node.

[0081] The technical effect of this step is to balance the accuracy and efficiency of anomaly detection by dynamically adjusting the sampling density. Reducing the number of sampling points in low-risk volumes can reduce system overhead and improve response speed, while ensuring that sufficient detection accuracy is maintained in high-risk volumes, thereby enhancing the stability and resource utilization of the entire storage system.

[0082] In order to realize the above-mentioned embodiments, the application further provides a thick backup volume state self-repair device in a distributed storage. Figure 2 A structural schematic diagram of a thick backup volume state self-repair device in a distributed storage provided by the embodiment of the application is shown in Figure 2 As shown in the figure, the device comprises: A state acquisition module 100 is configured to acquire metadata state information of a thick backup volume and determine whether the volume is in a formatting state. The abnormality identification module 200 is configured to, if the volume is in the formatting state, dynamically divide the block size and the scanning density based on the volume capacity and historical abnormality mode, perform hierarchical random sampling verification on the physical data of the volume, and identify the volume as a false abnormality volume or a true abnormality volume. The state repair module 300 is configured to, if the volume is the false abnormality volume, update the metadata state to the formatting completion state; and if the volume is the true abnormality volume, determine the physical address of the last non-0 data as a breakpoint by using a binary search method, and continue the formatting operation from the breakpoint position, and record the formatting progress in real time. The quota control module 400 is configured to collect the IOPS and bandwidth data of the cluster in real time, dynamically calculate the formatting quota, suspend the formatting operation and store the current breakpoint coordinate when the load of the cluster exceeds the preset threshold, and resume the formatting operation from the stored breakpoint coordinate when the load drops below the threshold.

[0083] As to the device in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be described in detail here.

[0084] In order to achieve the above-mentioned embodiments, the present application further provides an electronic device, comprising a processor and a memory connected with the processor; the memory stores computer execution instructions; the processor executes the computer execution instructions stored in the memory to realize the method provided by the above-mentioned embodiments.

[0085] In order to achieve the above-mentioned embodiments, the present application further provides a computer readable storage medium, the computer readable storage medium stores computer execution instructions, and the computer execution instructions are executed by the processor to realize the method provided by the above-mentioned embodiments.

[0086] In order to achieve the above-mentioned embodiments, the present application further provides a computer program product, comprising a computer program, the computer program is executed by the processor to realize the method provided by the above-mentioned embodiments.

[0087] The collection, storage, use, processing, transmission, provision and disclosure of the user personal information involved in the present application comply with the relevant laws and regulations, and do not violate public order and good customs.

[0088] It is important to note that user's personal information should be collected for legitimate and reasonable uses of the service and not shared or sold outside of those legitimate uses. Further, such collection / sharing should occur after the users are notified of these uses and agree to the terms, such as by agreeing to the terms of service, where they are given the opportunity to opt in to such uses. Still further, any desired step can be taken by the operator to avoid collecting personal information, such as avoiding collecting personal information on-line. In addition, users should be provided with an opportunity to opt out of collection of personal information, where appropriate, and / or subsequent transfer to a third party.

[0089] Embodiments are contemplated that provide users with the ability to selectively allow or block the use or access of personal information data. That is, the present disclosure contemplates providing users with control to permit, deny, or modify how their personal information data is collected, used, recorded and / or shared, such as by choosing to opt in or opt out of methods for collection and / or uses of information. Users can also have control over how to deliver, use, and / or store the personal information data. Users can opt out of certain data uses outside those necessary for the services, or at least so they are notified of the nature, your use, and given an opportunity to pull out. In addition, appropriate measures can be taken by users, or by the Service, to avoid collecting personal information on-line, such as avoiding certain uses of the site. In addition, users should be provided with an opportunity to opt out of collection of personal information, where appropriate, and / or subsequent transfer to a third party.

[0090] In the foregoing description, numerous specific details are set forth consistent with the detailed description of embodiments discussed herein. It is to be understood, however, that embodiments can be practiced without at least some of these specific details. In other instances, well-known structures have not been described in detail so as not to unnecessarily obscure the understanding of this description. It will be apparent, however, to one skilled in the art that implementations of the present application can be practiced without such specific details. In other instances, well-known structures have not been described in detail so as not to unnecessarily obscure the understanding of this description.

[0091] In addition, the terms "first", "second", and the like, do not denote any order, quantity, combination, or importance, but rather are used to nomenclature different components in the specification. Thus, the features defined with "first", "second", etc. can include at least one of the features. The meaning of "a", "an", and "the" include singular and plural referents. Therefore, the interpretation and application of the terms should be to the broadest scope of their meanings.

[0092] Any processes or methods described in the flow charts or otherwise described herein can be understood as representing code modules, segments, or portions of code which include one or more executable instructions for implementing specific logic functions (or steps) of a larger group of such instructions. It should also be understood that the scope of the present application encompasses also other implementations in which the order of steps can differ from that which is shown or discussed.

[0093] The logic and / or steps represented in flow diagrams or otherwise described herein, for example, can be considered as a sequence of instructions to implement logic functions, and can be embodied in any computer-readable medium for use by an instruction execution system, apparatus, or device, such as a computer-based system, processor- containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions. In the context of this specification, a "computer-readable medium" can be any means that can contain, store, communicate, propagate or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The computer-readable medium can be a machine-readable storage device (e.g., magnetic, optical or other) a machine-readable storage diskette (e.g., floppy disk, optical disk, etc.), a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), optical fibers, and a portable compact disc read-only memory (CDROM). Further, the computer-readable medium can even be paper or other suitable medium upon which the program is printed, as the program can be electronically captured, for example via the optical scanner of a device or other electronic capture device, and then compiled, interpreted, or otherwise processed in a suitable manner, if necessary, and stored in a computer memory.

[0094] It should be understood that aspects of the application can be implemented in hardware, software, firmware or combinations thereof. In the above embodiments, various steps or methods can be implemented in software or firmware that is stored in memory and executed by a suitable instruction execution system. As such, in some embodiments, the steps or methods can be implemented in a combination of hardware and software. If implemented in hardware, as in another embodiment, any of the above techniques can be implemented with or without the use of a programmable data processing apparatus, using any of the following technologies: discrete logic circuitry having logic gates for implementing logic functions upon an application of data signals, application specific integrated circuits having appropriate combinational logic gates, programmable gate arrays (PGA), field programmable gate arrays (FPGA), and the like.

[0095] Those of skill in the art would understand that information and signals can be represented using any of a variety of technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that can be referenced throughout the above description can be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

[0096] In addition, each function unit in each embodiment of the present application can be integrated in one processing module, or each unit can be physically present separately, or two or more units can be integrated in one module. The integrated module can be realized in the form of hardware or in the form of a software function module. When the integrated module is realized in the form of a software function module and sold or used as an independent product, it can also be stored in a computer readable storage medium.

[0097] The storage medium mentioned above can be a read-only memory, a magnetic disk or an optical disk, etc. Although the embodiments of the present application have been shown and described above, it should be understood that the above embodiments are exemplary and should not be construed as limiting the present application, and those skilled in the art can make changes, modifications, replacements and variations to the above embodiments within the scope of the present application.

[0098] It should be understood that various forms of flow shown above can be used to reorder, add or delete steps. For example, each step described in the present application can be executed in parallel, sequentially or in different order, as long as the desired results of the technical solutions of the present application can be achieved, which is not limited herein.

[0099] The above detailed description does not constitute a limitation on the scope of protection of the present application. Those skilled in the art should understand that various modifications, combinations, sub-combinations and replacements can be made according to design requirements and other factors. Any modifications, equivalent replacements and improvements within the spirit and principles of the present application should be included in the scope of protection of the present application.

Claims

1. A method for self-healing the state of thick provisioned volumes in distributed storage, characterized in that, Includes the following steps: S1, obtain the metadata status information of the thick provisioned volume and determine whether the volume is in the process of being formatted; S2, if it is in the formatting state, then dynamically divide the block size and scan density based on the volume capacity and historical abnormal patterns, perform hierarchical random sampling verification on the physical data of the volume, and identify whether the volume is a false abnormal volume or a true abnormal volume. S3, if it is a false abnormal volume, then only update the metadata status to the formatting complete status; If it is a true abnormal volume, a binary search method is used to determine the physical address of the last non-zero data as a breakpoint, and the formatting operation continues from that breakpoint, while the formatting progress is recorded in real time. S4 collects cluster IOPS and bandwidth data in real time, dynamically calculates formatting quotas, pauses formatting operations and stores the current breakpoint coordinates when the cluster load exceeds a preset threshold, and resumes formatting operations from the stored breakpoint coordinates when the load drops below the threshold.

2. The method according to claim 1, characterized in that, The step in S2 of dynamically dividing the block size and scan density based on volume capacity and historical abnormal patterns also includes: S21. The block size is divided into four levels according to the volume capacity. When the volume capacity is ≤100GB, the block size is 4KB; when the volume capacity is 100GB < volume capacity ≤1TB, the block size is 1MB; when the volume capacity is 1TB < volume capacity ≤10TB, the block size is 4MB; when the volume capacity is >10TB, the block size is 64MB. S22, combining historical anomaly patterns, calculate the final scan density according to the formula final_density=base_density×(1+history_risk×2), where base_density is the base density determined based on the volume capacity, and history_risk is the historical anomaly risk value recorded in the volume metadata, ranging from [0,1].

3. The method according to claim 1, characterized in that, The step in S3, which uses a binary search method to determine the physical address of the last non-zero data as the breakpoint, also includes: S31, initialize the search range to the start and end addresses of the thick backup volume, and determine the last physical address LAB_X storing non-zero data through multiple binary search; S32, starting from address LAB_X, performs write 0 operations to the volume in units of block_size, until the end of the volume, and records the current write position as the formatting progress after each block_size write 0 operation is completed.

4. The method according to claim 1, characterized in that, The step of dynamically calculating the formatted quota in S4 also includes: S41, when the cluster IOPS or bandwidth exceeds the preset threshold, pause the formatting operation and store the current breakpoint coordinates to the preset metadata area; S42, when the cluster load drops below the threshold, resume the formatting operation from the breakpoint coordinates of the storage, and set the resource preemption priority of the formatting operation and business I / O to be lower than the preset value during the recovery process.

5. The method according to claim 1, characterized in that, The term includes: S5, based on the current state of the volume and historical anomaly patterns, dynamically adjusts the sampling density before the formatting operation begins. When the historical anomaly pattern is 0, the sampling density is reduced by 20%; when the historical anomaly pattern is 1, the sampling density is increased by 50%.

6. A self-healing device for the status of thick provisioned volumes in distributed storage, characterized in that, include: The status acquisition module is used to acquire the metadata status information of the thick provisioned volume and determine whether the volume is in the process of being formatted. The anomaly identification module is used to dynamically divide the block size and scan density based on the volume capacity and historical anomaly patterns if the volume is in the process of formatting, and to perform hierarchical random sampling verification of the volume's physical data in order to identify whether the volume is a false anomaly volume or a true anomaly volume. The status repair module is used to update the metadata status to format complete if the volume is a false abnormality. If it is a true abnormal volume, a binary search method is used to determine the physical address of the last non-zero data as a breakpoint, and the formatting operation continues from that breakpoint, while the formatting progress is recorded in real time. The quota control module is used to collect cluster IOPS and bandwidth data in real time, dynamically calculate formatting quotas, pause formatting operations and store the current breakpoint coordinates when the cluster load exceeds a preset threshold, and resume formatting operations from the stored breakpoint coordinates when the load drops below the threshold.

7. The apparatus as claimed in claim 6, characterized in that, The anomaly detection module is also used for: The block size is divided into four levels based on the volume capacity: when the volume capacity is ≤100GB, the block size is 4KB; when the volume capacity is 100GB < 1TB, the block size is 1MB; when the volume capacity is 1TB < 10TB, the block size is 4MB; and when the volume capacity is >10TB, the block size is 64MB. Combining the historical anomaly pattern history_risk, the final scan density is calculated according to the formula final_density=base_density×(1+history_risk×2), where base_density is the base density determined based on the volume capacity, and history_risk is the historical anomaly risk value recorded in the volume metadata, ranging from [0,1].

8. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-6.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1-6.

Images