Distributed storage collaborative optimization method and device, electronic equipment and storage medium
By configuring virtual disks and adopting a multi-replica redundancy strategy in the distributed storage system, the problem of insufficient coordination and optimization between hardware RAID and software layers is solved, achieving efficient data recovery and system stability, reducing operational complexity, and improving fault handling efficiency.
Patent Information
- Application Number
- CN202511989200.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-26
- Publication Date
- 2026-01-23
- Estimated Expiration
- 2045-12-26
AI Technical Summary
In existing distributed storage solutions, the coordination and optimization between hardware RAID and the software layer are insufficient, resulting in high sensitivity to data recovery, concentrated system I/O pressure, increased hardware wear and tear, and delayed or misjudged fault warnings, which affect the system's continuous service capability and stability.
The disk array controller configures multiple physical hard drives within the storage node as virtual disks and maps them to logical volumes of the distributed storage system. A multi-replica redundancy strategy is used to build dual redundancy protection. When a single physical hard drive in the virtual disk fails, the disk array controller initiates a data reconstruction operation within the storage node.
It reduces the risk of data loss, reduces disk wear and tear, simplifies operation and maintenance, balances performance and reliability, improves the efficiency of single disk failure handling, and ensures the continuous service capability of the distributed storage system.
Smart Images

Figure CN121387208A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of computer storage, and in particular to a distributed storage collaborative optimization method and device, electronic equipment and storage medium. BACKGROUND
[0002] With the continuous evolution of cloud computing and big data technology, distributed storage systems, as the key infrastructure supporting massive data processing and high availability services, are widely used in data centers, enterprise-level storage, and cloud platforms. In related technologies, a multi-level data protection system is usually constructed through the collaborative work of hardware redundancy mechanisms (such as RAID) and distributed storage strategies (such as multi-copy and erasure coding). Specifically, this system covers the entire process from physical storage medium management to logical data distribution, including data redundancy configuration, fault recovery mechanism, load balancing strategy, and system monitoring. Among them, hardware RAID is mainly responsible for local redundancy and rapid recovery within the node, while distributed storage achieves global fault tolerance through cross-node data replication or coding, and the two together constitute the core technical architecture of modern storage systems.
[0003] However, in existing distributed storage solutions, a three-copy redundancy mechanism is directly adopted without fully considering the collaborative optimization between hardware RAID and the software layer, which may lead to problems such as high data recovery sensitivity, concentrated system I / O pressure, and intensified hardware wear. Specifically, when a single hard disk fails, the traditional architecture often triggers large-scale cross-node data reconstruction, which not only consumes a large amount of storage bandwidth but also significantly increases system load and operation and maintenance complexity. In addition, there is a disconnection between hardware RAID and distributed storage in the state monitoring layer, and the states of logical disks and physical disks cannot be effectively synchronized, leading to delayed fault warning or misjudgment, thereby affecting the continuous service capability and stability of the system. Therefore, there is an urgent need for a collaborative mechanism that integrates hardware redundancy and software optimization to achieve a more efficient and intelligent storage architecture design. SUMMARY
[0004] The present application provides a distributed storage collaborative optimization method and device, electronic equipment and storage medium, aiming to at least solve one of the technical problems in the related art to some extent.
[0005] The present application provides a distributed storage collaborative optimization method, comprising: configuring a plurality of physical hard disks in a storage node as virtual disks using a disk array controller; mapping the virtual disks as logical volumes of a distributed storage system, and storing data based on the logical volumes using a multi-copy redundancy strategy to build dual redundancy protection for the same data; When a single physical hard disk in the virtual disk is slow or fails, the data reconstruction operation is initiated and performed in the storage node by the redundant disk array controller.
[0006] The application also provides a device for distributed storage collaborative optimization, comprising: The configuration unit is configured to configure a plurality of physical hard disks in the storage node as a virtual disk by using a disk array controller. The mapping unit is configured to map the virtual disk as a logical volume of a distributed storage system, and store data based on the logical volume by using a multi-copy redundancy strategy to build double redundancy protection for the same data. The reconstruction unit is configured to initiate and perform a data reconstruction operation in the storage node by the redundant disk array controller when a single physical hard disk in the virtual disk is slow or fails.
[0007] The application also provides an electronic device, comprising a memory for storing a computer program, and a processor for executing the computer program to implement the steps of any of the above methods.
[0008] The application also provides a computer-readable storage medium, which stores a computer program, wherein the computer program is executed by a processor to implement the steps of any of the above methods.
[0009] The application also provides a computer program product comprising a computer program, which is executed by a processor to implement the steps of any of the above methods.
[0010] The application provides a method and device for distributed storage collaborative optimization, an electronic device, and a storage medium. The plurality of physical hard disks in the storage node are configured as a virtual disk by using a disk array controller, the virtual disk is mapped as a logical volume of a distributed storage system, and double redundancy protection is built based on the logical volume by using a multi-copy redundancy strategy. When a single physical hard disk in the virtual disk is slow or fails, the data reconstruction operation is initiated and performed in the storage node by the disk array controller. Therefore, the problems of large-scale data reconstruction triggered by single disk failure, dramatic increase of disk I / O pressure, high operation and maintenance complexity, contradiction between performance and reliability, and low failure handling efficiency caused by immature collaborative optimization of hardware RAID and distributed storage in the prior art can be solved. The technical effects of reducing data loss risk, reducing disk wear and tear, simplifying operation and maintenance, balancing performance and reliability, improving single disk failure handling efficiency, and ensuring continuous service capability of the distributed storage system are achieved.
[0011] It is to be understood that the details set forth herein do not construe a limitation on the scope of the present disclosure. Other aspects of the present disclosure will become apparent to those skilled in the art upon reading the following detailed description in conjunction with the drawings. BRIEF DESCRIPTION OF DRAWINGS
[0012] The accompanying drawings are included to provide a further understanding of the present application, and are incorporated in and constitute a part of this specification. Illustrations in the drawings are for Figure 1 A flowchart of a method for distributed storage collaborative optimization provided by an embodiment of the present application is shown. Figure 2 A structural diagram of an apparatus for distributed storage collaborative optimization provided by an embodiment of the present application is shown. DETAILED DESCRIPTION
[0013] Exemplary embodiments of the present disclosure are described herein with reference to the accompanying drawings, in which various details are set forth to facilitate an understanding of the present disclosure. It should be appreciated that various details set forth herein are merely exemplary and that the scope of the present disclosure is not limited to such details. It should also be appreciated that the present disclosure is not limited to the embodiments described herein, but rather, the scope of the present disclosure is limited only by the appended claims. Thus, the present disclosure is not intended to be limited to the embodiments described herein, but rather, the scope of the present disclosure is limited only by the appended claims.
[0014] In order to make the technical personnel in the technical field better understand the present application, the present application will be further described in detail below in combination with the drawings and specific embodiments.
[0015] In combination with the specific application environment architecture or the specific hardware architecture on which the execution of the method for distributed storage collaborative optimization depends, the specific application environment architecture or the specific hardware architecture is described herein.
[0016] An embodiment of the present application provides a method for distributed storage collaborative optimization, Figure 1 A flowchart of a method for distributed storage collaborative optimization provided by an embodiment of the present application is shown.
[0017] As Figure 1 shown, the method comprises the following steps: Step 101, configuring a plurality of physical hard disks in a storage node as virtual hard disks by using a disk array controller.
[0018] In the embodiment of the present application, in step 101, the disk array controller (i.e. RAID controller) as the core hardware component connecting the physical hard disk and the storage node, its core role is to integrate multiple physical hard disks in the storage node into a virtual disk with redundancy protection capability. First of all, it needs to be clear that the physical hard disk can be various types of disks (such as solid state disks) that meet the storage requirements, and the disk array controller needs to support the corresponding hard disk interface protocol and the preset RAID level (such as RAID6 level), which has dual-port NVMe cache support and flexible RAID configuration capability, and can stably manage multiple physical hard disks.
[0019] In the specific configuration process, the disk array controller will first identify all the physical hard disks accessed in the storage node, and initialize the detection of the hardware state (such as capacity, speed, health, etc.) of each hard disk through its built-in firmware program, exclude hard disks with hardware faults or compatibility problems, and ensure the stability of subsequent virtual disk construction. Subsequently, according to the preset virtual disk construction requirements (such as capacity planning, redundancy strategy), the disk array controller will divide a specified number of physical hard disks into a logical group, and integrate and manage the storage space of the physical hard disks through a specific RAID algorithm (such as the double-check algorithm of RAID6), and virtualize the dispersed storage space of multiple physical hard disks into a continuous virtual disk with a unified access address. In this process, the disk array controller will also configure necessary parameters for the virtual disk (such as stripe size, which can be adjusted according to the type of business data in the scheme, such as 256KB stripe for large data read / write), and at the same time enable the local redundancy protection mechanism, so that the virtual disk itself has data checking and fault self-repairing capability. For example, when a single physical hard disk in the group fails, the controller can rebuild the data of the failed hard disk on the remaining physical hard disks through the checking data, to ensure the data integrity and availability of the virtual disk.
[0020] The storage node can convert multiple physical hard disks into a more functional virtual disk with the help of the disk array controller, laying a hardware foundation for subsequent distributed storage layer management logical disk and building a "RAID+replica" dual-redundancy architecture, not only reducing the complexity of directly managing a large number of physical hard disks in the distributed storage, but also improving the data reliability within a single node through RAID local redundancy, indirectly reducing the data reconstruction frequency and resource overhead of the subsequent distributed storage layer.
[0021] In step 102, the virtual disk is mapped to the logical volume of the distributed storage system, and a multi-copy redundancy strategy is used for data storage based on the logical volume to build dual-redundancy protection for the same data.
[0022] In the embodiment of the present application, in step 102, the virtual disk is a storage unit with local redundancy capability formed by integrating multiple physical hard disks through a disk array controller (such as a virtual disk constructed based on a RAID6 algorithm, with double-check data protection), and the logical volume is a storage resource carrier that can be directly managed by the distributed storage system. The mapping process of the two needs to rely on the hardware adaptation module of the distributed storage system. Specifically, the distributed storage system will identify the virtual disk created by the disk array controller in the storage node through the underlying driver, obtain the hardware parameters of the virtual disk such as capacity, interface protocol, and read-write performance, and then encapsulate the virtual disk into a logical volume that meets the distributed storage data management specification through a logical volume management tool. In this process, a mapping relationship table of the physical address of the virtual disk and the logical address of the logical volume is established to ensure that the read-write instructions of the distributed storage system on the logical volume can be accurately converted into hardware operations on the virtual disk, while retaining the original local redundancy capability of the virtual disk, avoiding the destruction of the data protection mechanism at the hardware layer during the mapping process.
[0023] After the mapping is completed, based on the multi-copy redundancy strategy adopted by the logical volume, the core is that for each piece of data written to the logical volume, the data is synchronously stored in the logical volumes of different storage nodes through the replica management module of the distributed storage system according to the preset number of copies (such as three copies), and needs to meet the strong consistency requirement - that is, only when all copies are successfully written and confirmed, the data write success response is returned to the business end, ensuring the real-time synchronization of each copy data. The double redundancy protection here, the first layer comes from the local redundancy of the hardware layer virtual disk (such as the double-check mechanism of RAID6, which can resist data loss caused by single or double physical hard disk failure), and the second layer comes from the multi-copy redundancy of the software layer distributed storage (such as the three-copy strategy, which can resist data loss caused by single or multiple storage node failure), the two layers of protection are independent and cooperative: when a physical hard disk in a storage node fails, the local redundancy mechanism of the virtual disk can repair the data first, and the distributed storage system does not need to trigger data reconstruction across nodes immediately; when the storage node fails as a whole, the multi-copy redundancy strategy can quickly recover the data through the logical volume copies of other nodes, avoiding the data security risk caused by the failure of a single redundancy mechanism.
[0024] In actual data storage process, the distributed storage system will manage the logical volume by partition, evenly distribute the data fragments to different partitions, and then combine with the replica placement strategy (such as storing the replicas in different racks and different physical locations of the storage nodes), to further reduce the risk caused by hardware centralized failure. At the same time, the system will monitor the running state of each logical volume in real time, and when a logical volume appears read-write exception due to underlying virtual disk failure, it will automatically switch the data replicas on the logical volume to other normal logical volumes, ensuring the continuous accessibility of business data.
[0025] The local redundancy of the virtual disk simplifies the management complexity of the underlying hardware of the distributed storage, and the multi-copy redundancy strategy enhances the data reliability across nodes. The double redundancy protection greatly reduces the risk of data loss. Meanwhile, the logical volume as an intermediate layer isolates the impact of hardware layer changes on the distributed storage system (such as replacing a physical hard disk only needs to reconfigure the virtual disk, without adjusting the core data management logic of the distributed storage), indirectly reducing the operation and maintenance cost and providing a foundation for subsequent stable operation of the system.
[0026] In step 103, when a single physical hard disk in the virtual disk is slow or fails, a data reconstruction operation is initiated and performed in the storage node by the redundant disk array controller.
[0027] In the embodiments of the present application, in step 103, the slow disk refers to a state in which the read-write response time of the physical hard disk exceeds the preset threshold (such as the normal hard disk IO response delay is within 10 ms, and the slow disk delay lasts more than 50 ms), but is not completely failed. The failure refers to a situation in which the physical hard disk cannot perform data read-write due to hardware damage (such as head failure, disk damage). Both of them will affect the read-write performance and data security of the virtual disk. The disk array controller (i.e. RAID controller) as the core hardware of managing the virtual disk has the ability of real-time monitoring and local repair, and is the key carrier of initiating the data reconstruction operation.
[0028] Specifically, the disk array controller will continuously collect the running data of each physical hard disk in the virtual disk through the built-in hardware monitoring module, including the IO response time, data transmission rate, S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology) parameters (such as the number of bad tracks, temperature, motor speed) and the like. When the IO response time of a certain physical hard disk is continuously higher than the threshold (judging as a slow disk), or the S.M.A.R.T. parameter triggers a warning, the data transmission is interrupted (judging as a failure), the controller will immediately start the fault isolation mechanism to suspend the read-write task of the physical hard disk in the virtual disk, to avoid its impact on the IO performance of the entire virtual disk.
[0029] Subsequently, the disk array controller initiates a data reconstruction operation based on the RAID algorithm (such as the double-check mechanism of RAID6) adopted by the virtual disk: first, the valid data and the check data of the remaining normal physical hard disks in the virtual disk are read, and the data stored in the failed / slow disk physical hard disk is calculated reversely through the RAID algorithm; then the calculated data is written to the preset hot spare disk (if no hot spare disk is configured, the data needs to be written to the newly replaced hard disk after manual replacement of the failed hard disk), and the entire reconstruction process is completed independently within the storage node without the intervention of the distributed storage system. For example, when a physical hard disk in a virtual disk constructed based on RAID6 fails, the controller can use the data in the remaining hard disks and two copies of the check data to accurately reconstruct all the data of the failed hard disk, and the virtual disk can still maintain normal read and write during the reconstruction process, with only a slight decrease in performance, without interrupting the business service.
[0030] The data of the failed / slow disk physical hard disk can be quickly reconstructed locally in the storage node, and the distributed storage system can only monitor that the logical volume is in the "Rebuilding" state, without triggering large-scale data reconstruction across nodes, which not only avoids the dramatic increase in IO pressure and resource consumption of the distributed storage layer, but also ensures the quick repair of data at the hardware layer, further enhancing the effectiveness of the dual redundancy protection. Compared with the traditional mode of directly managing physical hard disks in the distributed storage, this mode can reduce the frequency of data reconstruction caused by single disk failure, reduce the performance fluctuations caused by reconstruction, and improve the continuity and reliability of data storage.
[0031] The present application provides a distributed storage collaborative optimization method, which configures multiple physical hard disks in a storage node as a virtual disk by using a disk array controller, maps the virtual disk as a logical volume of a distributed storage system, and constructs dual redundancy protection based on the logical volume using a multi-copy redundancy strategy. When a single physical hard disk in the virtual disk fails or becomes slow, the disk array controller initiates and performs a data reconstruction operation within the storage node. Therefore, the technical effects of reducing the risk of data loss, reducing disk wear and tear, simplifying maintenance operations, balancing performance and reliability, improving single disk failure handling efficiency, and ensuring continuous service capability of the distributed storage system can be achieved.
[0032] In the embodiments of the present application, the embodiments of the present application are further embodied as: real-time monitoring of input and output performance indicators of each virtual disk; based on the performance indicators, the data write request is distributed to the virtual disk with lower load through a dynamic load balancing algorithm.
[0033] Further, in the embodiments of the present application, the input-output performance indicators include input-output operations per second and throughput.
[0034] Specifically, real-time monitoring of the input-output performance indicators of each virtual disk is a basic link to ensure efficient operation of the distributed storage system. The virtual disk here is a storage unit with local redundancy capability formed by integrating multiple physical hard disks through a disk array controller (such as a virtual disk constructed based on a RAID6 algorithm), and its input-output performance directly determines the overall data processing efficiency of the distributed storage system. The real-time monitoring process needs to rely on the cooperative collection mechanism of the hardware layer and the software layer: the hardware layer uses the built-in monitoring module of the disk array controller to real-time capture the hardware-level running data of each virtual disk; the software layer converts the hardware layer data into standardized input-output performance indicators through the performance collection component of the distributed storage system, ensuring the real-time and accuracy of the monitoring data, and avoiding load judgment deviation caused by data delay.
[0035] Among them, the input-output performance indicators specifically include input-output operations per second (IOPS) and throughput. Input-output operations per second (IOPS) reflects the number of read-write requests that a virtual disk can process per unit of time, is directly related to the processing efficiency of small data (such as database transaction data), and for example, when the IOPS value of a virtual disk is low, it indicates that its current ability to process small-scale frequent read-write requests is insufficient; throughput refers to the amount of data (usually in units of MB / s or GB / s) that a virtual disk can transmit per unit of time, mainly affects the read-write speed of large data (such as video files, backup data), and if the throughput of a virtual disk decreases, it means that there is a bottleneck in its processing of large-scale data transmission tasks. By monitoring these two indicators at the same time, the actual load state of the virtual disk can be comprehensively reflected - relying on a single indicator may lead to misjudgment, for example, a virtual disk has high IOPS but low throughput, which may be due to processing a large number of small requests occupying too many IO resources, so it still needs to be determined as a high load state.
[0036] Based on the real-time collected performance indicators, the data write request is distributed to the virtual disk with lower load through the dynamic load balancing algorithm, and the core is to realize the reasonable scheduling of storage resources through the algorithm. The dynamic load balancing algorithm will first establish a virtual disk load evaluation model, assign different weights to the IOPS and throughput indicators according to the business priority (such as small data business priority referring to IOPS, and large data business priority referring to throughput), and calculate the comprehensive load value of each virtual disk; then, the algorithm will compare the comprehensive load values of each virtual disk in real time, identify the virtual disk with lower load (i.e. the comprehensive load value is lower than the preset threshold), and record its current idle IO resources and data transmission bandwidth. When the distributed storage system receives a data write request, the algorithm will match the corresponding load evaluation dimension according to the data type (small / large) of the request, and direct the request to the virtual disk with lower load and adapt to the processing needs of the data type - for example, for small data write request, it is preferentially distributed to the virtual disk with high IOPS idle rate; for large data write request, it is preferentially distributed to the virtual disk with sufficient throughput redundancy. At the same time, the algorithm will continuously track the performance changes of the virtual disk after the request is distributed, and if the load of a virtual disk suddenly rises due to the newly distributed write request, the subsequent request distribution strategy will be adjusted in time to avoid the virtual disk becoming a new performance bottleneck.
[0037] In this way, the performance decline of some virtual disks due to excessive load can be effectively avoided, and the resources of virtual disks with lower load can be fully utilized to improve the IO utilization rate of the entire distributed storage system. In addition, the dynamic distribution mechanism can adapt to the dynamic changes of business data types, without the need for manual adjustment of the distribution strategy, reducing the operation and maintenance intervention cost, and finally realizing the stable improvement of data write efficiency and the optimization of system overall performance.
[0038] In the embodiments of the present application, the embodiments of the present application are further embodied as: preconfiguring a hot standby logical volume in the distributed storage system; when a physical hard disk failure is monitored, switching the data service to the hot standby logical volume.
[0039] Specifically, the hot standby logical volume refers to a logical volume configured in advance in the deployment stage of the distributed storage system and in a standby state. Its core role is to serve as a "backup resource" for the failed logical volume, ensuring that the data service can be quickly switched in the event of hardware failure. The pre-configuration of the hot standby logical volume relies on the virtual disk mapping foundation completed in the early stage. First, from the virtual disks constructed by the disk array controller in the storage node, select the virtual disks whose performance parameters (such as IOPS, throughput) match the business in-use logical volume, and encapsulate them into a hot standby logical volume that meets the data storage specification through the logical volume management tool of the distributed storage system. During the configuration process, the hot standby logical volume needs to be preset with storage parameters (such as capacity, replica strategy adaptability) consistent with the in-use logical volume, while keeping it in a "low-load standby" state, only synchronously updating necessary system metadata, not participating in daily data read and write, avoiding occupying business resources, and ensuring quick response in the event of failure switching.
[0040] During system operation, the distributed storage system will monitor the physical hard disk status in real time through the full-stack monitoring system - on the one hand, integrating the S.M.A.R.T. data of the disk array controller (such as the number of hard disk bad tracks, temperature warning), on the other hand, combining IPMI hardware state monitoring (such as hard disk power supply, interface connection state), double-checking the health of the physical hard disk. When a physical hard disk failure is detected (such as S.M.A.R.T. parameters triggering critical threshold, IPMI detecting hard disk offline), the system will first determine the virtual disk to which the failed hard disk belongs, and then locate the in-use logical volume mapped by the virtual disk.
[0041] At this time, the failure switching mechanism will start immediately: first, suspend the read and write service of the failed in-use logical volume, quickly point the business access address of the logical volume to the pre-configured hot standby logical volume through the metadata management module of the distributed storage system; then, the hot standby logical volume will synchronize the data in the failed logical volume that has not been lost (since the underlying virtual disk has local redundancy, the data of the failed hard disk can be reconstructed through RAID, and the hot standby logical volume only needs to supplement a small amount of incremental data) based on the multi-replica strong consistency strategy of the distributed storage, quickly recover the data integrity; after the data synchronization is completed, the hot standby logical volume formally takes over all data services of the original in-use logical volume, and the whole switching process is transparent to the upper-layer business, without manual intervention.
[0042] The pre-configuration of the hot standby logical volume avoids the time consumption of creating a logical volume temporarily after a failure occurs, greatly shortens the failure switching period, and reduces the risk of business interruption; at the same time, relying on the local redundancy of the virtual disk and the quick filling of the hot standby logical volume, the dual redundancy effect of "hardware RAID + distributed replica" is further strengthened, the probability of data service degradation caused by physical hard disk failure is reduced, and the continuous service capability and operation and maintenance efficiency of the distributed storage system are indirectly improved.
[0043] In the embodiments of the present application, the embodiments of the present application are further embodied as: utilizing the cache of the disk array controller and the non-volatile memory cache of the distributed storage system to cache data, so as to reduce the delay of data checking and writing.
[0044] Specifically, the cache of the disk array controller and the non-volatile memory cache (namely, NVMe cache) of the distributed storage system are both core cache components for improving data read-write efficiency, and their cooperative work needs to rely on deep adaptation of hardware resources and software strategies. Among them, the cache of the disk array controller is a high-speed storage unit integrated in the RAID card, has an independent read-write control chip, can temporarily store data and checking information to be written into the physical hard disk, and when using the Write-back mode, the controller first writes the data into the cache after receiving the data and returns a "write success" response to the system, and then asynchronously flushes the cache data into the physical hard disk, greatly shortening the waiting time of single write; the NVMe cache of the distributed storage system is built based on non-volatile memory, has high-speed read-write and data persistence capability, and can store priority for business hotspot data (such as frequently accessed small files, real-time transaction data), reducing repeated access to the underlying virtual disk.
[0045] The specific process of cooperative caching of the two is as follows: when the distributed storage system receives a data write request, first, the data is divided into "hotspot data" and "non-hotspot data" - the hotspot data is written into the NVMe cache of the distributed storage system first, and the low-delay characteristic is used to realize fast response, and at the same time, the NVMe cache synchronizes data element information to the disk array controller cache in real time; the non-hotspot data is directly transmitted to the disk array controller cache, which is temporarily stored by the controller cache and starts checking calculation (such as double-check value calculation of RAID6). In this process, the disk array controller cache and the NVMe cache establish a data interaction channel through the PCIe bus, and the controller cache synchronizes the calculated checking information to the NVMe cache, avoiding repeated checking calculation of the distributed storage system and reducing CPU resource consumption; at the same time, when a certain amount of hotspot data is accumulated in the NVMe cache, the idle state of the disk array controller cache is combined, and the data is batched to be flushed into the controller cache, and then the controller cache asynchronously writes the data into the virtual disk, avoiding the increase of IO overhead caused by frequent small data block write operations.
[0046] For the reduction of data verification delay, the core lies in the cooperative sharing of the two for verification calculation: in the traditional mode, data verification needs to be calculated after the completion of the calculation in the distributed storage layer and then transmitted to the hardware layer, which has double delay of software calculation and data transmission; in the present scheme, the disk array controller cache can rely on the hardware acceleration module of the RAID card to directly verify the received data, and the calculation result is synchronized to the NVMe cache, so that the distributed storage system only needs to verify the integrity of the verification information without the need to re-execute the calculation, greatly shortening the time consumption of the verification process. On the optimization of data write delay, the Write-back mode of the RAID card cache solves the delay problem of "data waiting for disk flushing", and the NVMe cache solves the delay problem of "hot data repeated access", and the cooperation of the two forms an efficient link of "NVMe cache temporarily stores hot data → RAID card cache batch processes verification and asynchronous disk flushing" in the data write path, avoiding the delay superposition caused by insufficient capacity or high load of a single cache component.
[0047] Through the cooperative cache mechanism, the data verification process does not need to repeat the calculation across layers, and the data writing does not need to wait for the slow response of the physical hard disk, effectively reducing the overall delay of data verification and writing, and relying on the hardware high-speed characteristics of the RAID card cache and the NVMe cache, further improving the stability of data reading and writing, providing performance support for the distributed storage system to handle high-concurrency write scenarios (such as real-time data collection of big data and storage of high-frequency transaction data), and indirectly strengthening the service response efficiency under the "RAID+replica" dual-redundancy architecture.
[0048] In the embodiments of the present application, the embodiments of the present application are further embodied as: through bus channel segmentation technology, the traffic of the virtual disk and the input and output traffic of the direct physical hard disk are isolated and managed.
[0049] Specifically, the core of the bus channel segmentation technology is to rely on the bus architecture of the server hardware (such as the configured PCIe4.0x16 bus), to realize the independent transmission of the traffic of the managed virtual disk and the input and output traffic of the direct physical hard disk through channel division and protocol isolation at the hardware level. Among them, the traffic of the managed virtual disk refers to the data interaction traffic between the disk array controller and the virtual disk, including the creation, parameter configuration, data verification calculation, and data transmission during fault reconstruction of the virtual disk; the input and output traffic of the direct physical hard disk refers to the business traffic of the distributed storage system directly reading and writing data with the through physical hard disk (if any) not included in the RAID group, if the two types of traffic share the same bus channel, the bus bandwidth will be contended due to the superposition of traffic peaks, causing data transmission delay or even packet loss.
[0050] In implementation, first, based on the PCIe bus topology of the server, the PCIe channels are logically divided by BIOS or hardware configuration tools: the server PCIe 4.0 x16 bus is divided into two independent sub-channels, for example, 8 PCIe channels are allocated to connect the disk array controller, to ensure that the traffic of the management virtual disk has stable transmission bandwidth; the remaining 8 PCIe channels are used to connect the interface controller of the pass-through physical hard disk, to ensure the independent transmission path of the input and output service traffic. At the same time, at the bus protocol level, different transmission priorities are configured for the two types of traffic through the firmware setting of the disk array controller: the traffic of the management virtual disk (such as RAID rebuild data) is set to high priority, to avoid delay in repairing virtual disk failure due to insufficient bandwidth; the input and output traffic of the direct physical hard disk is set according to the service demand, to ensure that the core business data transmission is not affected.
[0051] In addition, a channel identification module needs to be added in the underlying driver of the distributed storage system, so that the system can automatically distinguish the two types of traffic and direct them to the corresponding PCIe sub-channels: when the system initiates virtual disk management operations (such as reading RAID card S.M.A.R.T. data, adjusting RAID strip parameters), the driver program directs the traffic to the PCIe sub-channel to which the disk array controller belongs; when the system performs business data read and write (such as user file storage, database data query), the driver program allocates the input and output traffic to the PCIe sub-channel corresponding to the pass-through physical hard disk. This channel isolation at the hardware level fundamentally avoids the mutual interference of the two types of traffic at the bus level, breaking through the bandwidth bottleneck under the traditional shared bus architecture.
[0052] The traffic of the management virtual disk and the input and output traffic of the direct physical hard disk are transmitted independently, which not only ensures the stability of the virtual disk management operation (such as stable data transmission rate during RAID rebuild process, unaffected by business traffic fluctuations), but also avoids the increase of delay caused by bus contention of business input and output traffic, significantly improves the bandwidth utilization of the PCIe bus, and provides a stable hardware transmission foundation for subsequent hardware and software layer optimization (such as hybrid cache mechanism, dynamic load balancing), indirectly enhancing the read and write performance and running stability of the distributed storage system as a whole.
[0053] In the embodiments of the present application, the embodiments of the present application are further embodied as: dynamically adjusting the strip size of the virtual disk according to the type of business data.
[0054] Specifically, in the embodiments of the present application, the striping size of the virtual disk refers to the size of dividing the virtual disk storage space into multiple equal-size data blocks (i.e., strips), which directly affects the verification overhead and transmission efficiency during data reading and writing. If the strip is too small, it is easy to cause single reading and writing to cross multiple strips, increasing the number of verification calculations and bus transmission frequency. If the strip is too large, it may cause storage space waste, and small block data reading and writing is easy to trigger whole strip operation, reducing the IO response speed. The business data type can be divided into large block data (such as video files, backup data, and single block data amount usually above 100MB) and small block data (such as database transaction data, log files, and single block data amount below 1MB) according to the data block size. Different types of data have significant differences in the adaptation requirements of striping size, so it is necessary to dynamically adjust the striping parameters based on the business data type.
[0055] The specific adjustment process relies on the cooperation of the strip self-adaptive module of the distributed storage system and the parameter configuration interface of the disk array controller. First, the distributed storage system analyzes the data type currently processed in real time through the business identification module, for example, by file suffix, data transmission protocol (such as object storage S3 protocol corresponding to large block data, and database JDBC protocol corresponding to small block data), or preset business label, to determine whether the data belongs to large block data or small block data. Then, the system synchronizes the data type identification result to the parameter control unit of the disk array controller, and the controller automatically adjusts the strip size of the corresponding virtual disk according to the preset striping adaptation rule (such as large block data matching 256KB-1MB strip, and small block data matching 64KB-128KB strip). For example, when processing video stream writing service, the controller adjusts the strip size to 256KB, so that single data writing can cover a single strip, reducing cross-strip verification calculation and verification overhead. When processing high-frequency transaction writing of the database, the controller reduces the strip size to 64KB, so that small block data can accurately match the strip size, avoiding storage space fragmentation and IO resource waste caused by too large strip.
[0056] In terms of stability guarantee of dynamic adjustment, the disk array controller will adopt the "incremental adjustment" strategy: first test the adaptability of the new strip size in the idle partition of the virtual disk, monitor the performance indicators such as reading and writing delay and verification calculation time after adjustment, and then gradually switch the strip size of the partition in use to the new parameter after confirming that the indicators meet the expectations, avoiding data reading and writing interruption caused by direct adjustment. At the same time, the distributed storage system will synchronize the strip adjustment progress in real time, optimize the data sharding strategy according to the new strip size, and ensure that the data sharding matches the strip size, further improving the reading and writing efficiency.
[0057] Through the dynamic adjustment mechanism, the striping size of the virtual disk can be accurately adapted to the type of business data, avoiding the adaptation limitations of fixed striping size to different business scenarios, and indirectly improving the IO performance of the virtual disk by optimizing the check overhead and read / write efficiency, laying a performance foundation for subsequent distributed storage systems to adopt a multi-copy redundancy strategy and build a dual redundancy protection, while also reducing the waste of hardware resources caused by improper striping, and improving the overall resource utilization of the storage node.
[0058] In the embodiments of the present application, the level of the disk array controller is further specified as RAID 6.
[0059] Specifically, in the embodiments of the present application, the level of the disk array controller is set to RAID 6, and RAID 6, as a disk array level with a double-check mechanism, has the core advantage of being able to resist the failure of two physical hard disks at the same time. Compared with RAID 5 which only supports single-disk failure recovery, it can provide more reliable local data redundancy protection for virtual disks, which is also the key hardware basis for building a "hardware RAID + distributed copy" dual redundancy architecture. Specifically, the RAID 6 level introduces two independent check blocks (usually calculated based on the P+Q double-check algorithm) in the physical hard disk group, and stores the check data on different physical hard disks. When a single or two physical hard disks in a RAID group in the storage node fail (such as physical damage to the hard disk or interface failure), the disk array controller can use the data in the remaining physical hard disks and the two check blocks to accurately reconstruct all the data in the failed hard disk through reverse calculation, and the reconstruction process is completed independently on the local storage node, without relying on cross-node resources of the distributed storage system, avoiding the situation of large-scale data reconstruction in the distributed storage layer triggered by hardware failure.
[0060] In actual configuration, the disk array controller will divide the storage locations of data blocks and check blocks according to the RAID 6 algorithm rules based on the number of physical hard disks accessed - for example, when using 7 physical hard disks to build a RAID 6 group, the controller will use the storage space of 5 hard disks to store business data, and the remaining 2 hard disks to store double-check data, and the check data will be evenly distributed in a striping manner to avoid a single check hard disk becoming a performance bottleneck. At the same time, the RAID 6 level also supports pre-configuring a hot spare disk in the RAID group. When a physical hard disk shows signs of slow or failure, the controller can automatically enable the hot spare disk to quickly migrate the data and check information of the failed hard disk to the hot spare disk, further shortening the failure recovery time and ensuring the continuous availability of the virtual disk.
[0061] From the perspective of data security and system stability, the selection of RAID 6 level effectively makes up for the limitation of traditional distributed storage relying only on multiple copy redundancy - when a local hardware failure occurs within the storage node, the dual-check mechanism of RAID 6 can achieve local data repair at the first time, reducing the risk of losing distributed storage copies due to multiple hard disk failures at the same time; from the performance perspective, although RAID 6 has certain performance overhead due to dual-check calculation, combined with subsequent dynamic load balancing algorithm and hybrid cache mechanism, this performance overhead can be controlled within a reasonable range by optimizing the data write path and reducing the check calculation delay, ensuring that the read-write efficiency of the virtual disk meets the business requirements.
[0062] By setting the disk array controller level to RAID 6, the virtual disk is given stronger local redundancy and fault self-repairing capability, which not only improves the data reliability of a single storage node, but also provides solid hardware support for subsequent distributed storage layers using multiple copy strategies to build dual redundancy protection, effectively reducing the data loss risk of the entire storage system, and reducing the frequency of maintenance intervention and resource consumption caused by hardware failure.
[0063] In the embodiments of the present application, the embodiments of the present application are further embodied as: collecting state information of the disk array controller and the distributed storage system, and performing state early warning based on the state information.
[0064] Specifically, in the embodiments of the present application, collecting state information of the disk array controller and the distributed storage system is the basis for realizing full-stack monitoring and state early warning. The two types of state information cover the core running data of the hardware layer and the software layer, and need to be ensured comprehensive and real-time through a multi-source data collection mechanism. Among them, the state information of the disk array controller mainly includes hardware-level running data, specifically the working state of the controller itself (such as whether it is in Active mode, PCIe bus connection state), the state of the virtual disk managed (such as Optimal normal state, Degraded degraded state, Rebuilding rebuilding state), and the physical hard disk health data (such as the number of bad tracks, hard disk temperature, cumulative power-on time, read-write error rate) obtained through S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology). These data need to be real-time grabbed through the special management interface of the disk array controller (such as the storcli tool) to ensure that potential hardware failures can be discovered in time.
[0065] The state information of the distributed storage system focuses on the running state of the software layer, covering the read-write performance indicators (such as IOPS, throughput, read-write delay) of the logical volume, the synchronization state of multiple copies (such as whether the copies meet strong consistency, whether there is a copy loss), the resource occupation of the storage node (such as CPU usage, memory occupation, network bandwidth utilization), and the system running log (such as data write failure log, node communication exception log). These information are collected through the built-in monitoring components of the distributed storage system, and some key indicators (such as the synchronization state of the copy) need to be synchronized to the hardware layer monitoring module in real time to realize the linkage and alignment of software and hardware states.
[0066] After the state information is collected, data integration and analysis are needed to realize state early warning: first, the collected multi-source data (disk array controller S.M.A.R.T. data, IPMI hardware state data, distributed storage log) are uniformly accessed to the time series database based on Prometheus, and data cleaning and standardization processing are performed to eliminate the format differences of different data sources; then, based on the preset early warning threshold and abnormality determination rules, the integrated data are analyzed in real time - for example, when the number of bad tracks of a physical hard disk reported by the disk array controller exceeds the threshold, or the read-write delay of a logical volume monitored by the distributed storage system is continuously higher than the normal range, the system will automatically trigger the early warning mechanism; finally, the early warning information is displayed in the form of charts, alarm pop-up windows, etc. through the visualization platform in real time, and combined with the hard disk life prediction model (based on S.M.A.R.T. data trend analysis), the system sends a replacement reminder for the hardware that will reach the life threshold, and pushes an emergency alarm for the abnormal state that may cause data risk (such as multiple copy synchronization interruption), so as to ensure that the operation and maintenance personnel can intervene and handle in time.
[0067] Through the implementation, the full-dimensional monitoring and early warning of the state of the disk array controller and the distributed storage system are realized, which not only avoids business interruption caused by not discovering hardware failure in time, but also reduces the frequency of passive operation and maintenance, reduces the response time of fault handling, further ensures the stable operation of the "hardware RAID + distributed copy" dual-redundancy architecture, and indirectly improves the continuous service capability and data security of the entire storage system.
[0068] It should be noted that the embodiments of the present disclosure can include multiple steps, which are numbered for the convenience of description, but these numbers are not a limitation on the execution time slot and execution order between the steps; these steps can be implemented in any order, and the embodiments of the present disclosure do not limit this.
[0069] Corresponding to the method of optimizing the distributed storage, the disclosure also proposes a device for optimizing the distributed storage. Since the device embodiment of the disclosure corresponds to the method embodiment described above, for the details not disclosed in the device embodiment, the method embodiment described above can be referred to, and the disclosure will not be described again.
[0070] Figure 2 A structural schematic diagram of a device for optimizing the distributed storage provided by the embodiment of the disclosure is shown in Figure 2 as shown, comprising: The configuration unit 21 is configured to configure a plurality of physical hard disks in the storage node as virtual disks by using the disk array controller; The mapping unit 22 is configured to map the virtual disks as logical volumes of the distributed storage system, and store data based on the logical volumes by using a multi-copy redundancy strategy to construct double redundancy protection for the same data; The reconstruction unit 23 is configured to initiate and execute a data reconstruction operation in the storage node by the disk array controller when a single physical hard disk in the virtual disk is slow or fails.
[0071] It should be noted that the foregoing explanation and description of the method embodiment also apply to the device of the present embodiment, the principles are the same, and the present embodiment will not be limited.
[0072] The description of the features in the corresponding embodiment of the device for optimizing the distributed storage can refer to the related description of the corresponding embodiment of the method for optimizing the distributed storage, which will not be described one by one here.
[0073] The embodiment of the present application also provides an electronic device comprising a memory and a processor, the memory stores a computer program, and the processor is configured to run the computer program to execute the steps in any one of the above-mentioned method embodiments for optimizing the distributed storage.
[0074] The embodiment of the present application also provides a computer readable storage medium, which stores a computer program, wherein the computer program is configured to execute the steps in any one of the above-mentioned method embodiments for optimizing the distributed storage when running.
[0075] In an exemplary embodiment, the above-mentioned computer readable storage medium can include, but is not limited to: a U disk, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic or optical disk, and various media that can store computer programs.
[0076] The embodiment of the present application further provides a computer program product, which comprises a computer program, and the computer program realizes the steps in any of the method embodiments of the distributed storage collaborative optimization when executed by a processor.
[0077] The embodiment of the present application further provides another computer program product, which comprises a nonvolatile computer readable storage medium, and the nonvolatile computer readable storage medium stores a computer program, and the computer program realizes the steps in any of the method embodiments of the distributed storage collaborative optimization when executed by a processor.
[0078] The skilled in the art can further realize that the units and algorithm steps of the examples described in combination with the embodiments disclosed in the present application can be realized by electronic hardware, computer software or combination of both. In order to clearly illustrate the interchangeability of hardware and software, the components and steps of the examples have been described in the above description in general. Whether the functions are realized in hardware or software depends on the specific application and design constraints of the technical solution. The skilled in the art can use different methods to realize the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.
[0079] The above describes in detail the method and device for distributed storage collaborative optimization, electronic equipment and storage medium provided by the present application. The principle and implementation mode of the present application are described by applying specific examples in the present application. The above description of the examples is only used to help understand the method of the present application and its core idea. It should be pointed out that, for the ordinary skilled in the art, some improvements and modifications can be made to the present application without departing from the principle of the present application, and these improvements and modifications also fall within the protection scope of the claims of the present application.
Claims
1. A method for distributed storage collaborative optimization, the method comprising: The method comprises: configuring multiple physical hard disks in a storage node as virtual disks by using a disk array controller; mapping the virtual disks as logical volumes of a distributed storage system, and storing data based on the logical volumes by using a multi-copy redundancy strategy to build double redundancy protection for the same data; when a single physical hard disk in the virtual disk is slow or fails, initiating and executing a data reconstruction operation in the storage node by the redundant disk array controller.
2. The method of distributed storage co-optimization of claim 1, wherein, The method further comprises: monitoring input and output performance indicators of each virtual disk in real time; based on the performance indicators, distributing data write requests to virtual disks with lower loads by using a dynamic load balancing algorithm.
3. The method of distributed storage co-optimization of claim 2, wherein, The input and output performance indicators include the number of operations per second and throughput.
4. The method of distributed storage co-optimization of claim 1, wherein, The method further comprises: preconfiguring a hot standby logical volume in the distributed storage system; when a physical hard disk failure is detected, switching data services to the hot standby logical volume.
5. The method of distributed storage co-optimization of claim 1, wherein, The method further comprises: using the cache of the disk array controller and the non-volatile memory cache of the distributed storage system for data caching to reduce the delay of data verification and writing.
6. The method of distributed storage co-optimization of claim 1, wherein, The method further comprises: isolating the traffic of the virtual disks and the input and output traffic of the direct physical hard disks by using bus channel segmentation technology.
7. The method of distributed storage co-optimization of claim 1, wherein, The method further comprises: dynamically adjusting the striping size of the virtual disks according to the type of business data.
8. The method of distributed storage co-optimization of claim 1, wherein, The level of the disk array controller is RAID 6.
9. The method of distributed storage co-optimization of claim 1, wherein, The method further comprises: collecting state information of the disk array controller and the distributed storage system, and performing state early warning based on the state information.
10. An apparatus for distributed storage collaborative optimization, the apparatus comprising: The method comprises: a configuration unit configured to configure multiple physical hard disks in a storage node as virtual disks by using a disk array controller; a mapping unit configured to map the virtual disks as logical volumes of a distributed storage system, and store data based on the logical volumes by using a multi-copy redundancy strategy to build double redundancy protection for the same data; a reconstruction unit configured to initiate and execute a data reconstruction operation in the storage node by the redundant disk array controller when a single physical hard disk in the virtual disk is slow or fails.
11. An electronic device, comprising: The method comprises: at least one processor; and a memory connected in communication with the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method of distributed storage collaborative optimization according to any one of claims 1-9.
12. A non-transitory computer-readable storage medium having stored thereon computer instructions, wherein, The computer instructions are used to enable the computer to perform the method of distributed storage collaborative optimization according to any one of claims 1-9.
13. A computer program product, characterised in that, The computer program, when executed by a processor, implements the method of distributed storage collaborative optimization according to any one of claims 1-9.
Citation Information
Patent Citations
Disk storage system and data access method thereof
CN102135862A
Method and device for speeding up data reconstruction of disk array
CN105893188A
Method and device for creating logical volume
CN106302075A
Virtual machine starting method and device
CN106775924A
Distributed storage system based on storage pool virtualization management and data read-write method
CN111158587A
