Method and device for distributed storage collaborative optimization, electronic device and storage medium

Abstract

This application provides a method, apparatus, electronic device, and storage medium for distributed storage collaborative optimization, relating to the field of computer storage technology. It utilizes a disk array controller to configure multiple physical hard drives within a storage node as virtual disks, then maps these virtual disks to logical volumes of a distributed storage system. Based on these logical volumes, a multi-replica redundancy strategy is employed to construct dual redundancy protection. When a single physical hard drive in the virtual disk experiences a slow disk or fails, the disk array controller initiates and executes a data reconstruction operation within the storage node. Therefore, it can solve problems in existing technologies such as large-scale data reconstruction triggered by single-disk failures due to the reliance on multi-replica redundancy mechanisms in traditional distributed storage, a surge in disk I / O pressure, high operational complexity, a contradiction between performance and reliability, and low fault handling efficiency caused by the immaturity of hardware RAID and distributed storage collaborative optimization.

Description

Technical Field

[0001] This application relates to the field of computer storage technology, and in particular to a method and apparatus, electronic device and storage medium for distributed storage collaborative optimization. Background Technology

[0002] With the continuous evolution of cloud computing and big data technologies, distributed storage systems, as a key infrastructure supporting massive data processing and high availability services, are widely used in data centers, enterprise-level storage, and cloud platforms. Related technologies typically employ a multi-layered data protection system through the collaborative operation of hardware redundancy mechanisms (such as RAID) and distributed storage strategies (such as multiple replicas and erasure coding). Specifically, this system covers the entire process from physical storage media management to logical data distribution, including key aspects such as data redundancy configuration, fault recovery mechanisms, load balancing strategies, and system monitoring. Hardware RAID primarily handles local redundancy and rapid recovery within nodes, while distributed storage achieves global fault tolerance through cross-node data replication or encoding. Together, they constitute the core technical architecture of modern storage systems.

[0003] However, existing distributed storage solutions directly employ a three-replica redundancy mechanism without fully considering the collaborative optimization between hardware RAID and the software layer. This can lead to problems such as excessive sensitivity to data recovery, concentrated system I / O pressure, and accelerated hardware wear and tear. Specifically, when a single hard drive fails, traditional architectures often trigger large-scale cross-node data reconstruction, consuming significant storage bandwidth and significantly increasing system load and operational complexity. Furthermore, there is a disconnect between hardware RAID and distributed storage at the status monitoring level; the states of logical and physical disks cannot be effectively synchronized, resulting in delayed or misjudged fault warnings, thus affecting the system's continuous service capability and stability. 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 of the Invention

[0004] This application provides a method, apparatus, electronic device, and storage medium for distributed storage collaborative optimization, aiming to at least partially solve one of the technical problems in the related art.

[0005] This application provides a method for distributed storage collaborative optimization, including:

[0006] The disk array controller is used to configure multiple physical hard drives within a storage node as virtual disks;

[0007] The virtual disk is mapped to a logical volume of the distributed storage system, and a multi-replica redundancy strategy is used to store data based on the logical volume, so as to build dual redundancy protection for the same data.

[0008] When a single physical hard drive in the virtual disk experiences a slow disk or fails, a data reconstruction operation is initiated and executed within the storage node through the redundant disk array controller.

[0009] This application also provides a distributed storage collaborative optimization apparatus, comprising:

[0010] The configuration unit is used to configure multiple physical hard drives within a storage node as virtual disks using the disk array controller;

[0011] The mapping unit is used to map virtual disks to logical volumes of a distributed storage system, and to store data using a multi-replica redundancy strategy based on the logical volumes, so as to build dual redundancy protection for the same data.

[0012] The reconstruction unit is used to initiate and execute data reconstruction operations within the storage node via the redundant disk array controller when a single physical hard drive in the virtual disk experiences a slow disk or failure.

[0013] This application also provides an electronic device, including: 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.

[0014] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above methods.

[0015] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above methods.

[0016] This application provides a method, apparatus, electronic device, and storage medium for distributed storage collaborative optimization. By utilizing a disk array controller to configure multiple physical hard drives within a storage node as virtual disks, and then mapping these virtual disks to logical volumes of the distributed storage system, a dual redundancy protection is constructed based on the logical volumes using a multi-replica redundancy strategy. Furthermore, when a single physical hard drive in the virtual disk experiences a slow disk or fails, the disk array controller initiates and executes a data reconstruction operation within the storage node. Therefore, it can solve the problems in existing technologies where traditional distributed storage relies on multi-replica redundancy mechanisms, leading to large-scale data reconstruction triggered by single-disk failures, a surge in disk I / O pressure, high operational complexity, a conflict between performance and reliability, and low fault handling efficiency due to the immaturity of hardware RAID and distributed storage collaborative optimization. This achieves the technical effects of reducing data loss risk, reducing disk wear, simplifying operational operations, balancing performance and reliability, improving single-disk failure handling efficiency, and ensuring the continuous service capability of the distributed storage system.

[0017] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0018] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein:

[0019] Figure 1 A flowchart illustrating a method for distributed storage collaborative optimization provided in an embodiment of this application;

[0020] Figure 2 This is a schematic diagram of a distributed storage collaborative optimization device provided in an embodiment of this application. Detailed Implementation

[0021] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0022] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0023] The specific application environment architecture or specific hardware architecture on which the method of combined distributed storage co-optimization depends is described here.

[0024] The embodiments of this application provide a method for distributed storage collaborative optimization. Figure 1 This is a flowchart illustrating a distributed storage collaborative optimization method provided in an embodiment of this application.

[0025] like Figure 1 As shown, the method includes the following steps:

[0026] Step 101: Use the disk array controller to configure multiple physical hard drives in the storage node as virtual disks.

[0027] In this embodiment, in step 101, the disk array controller (i.e., RAID controller) is the core hardware component connecting the physical hard drives and the storage node. Its core function is to integrate multiple physical hard drives within the storage node into a virtual disk with redundancy protection capabilities. First, it should be clarified that the physical hard drives can be various types of disks that meet storage requirements (such as solid-state drives). The disk array controller must support the corresponding hard drive interface protocol and the preset RAID level (such as RAID 6) to have dual-port NVMe caching support and flexible RAID configuration capabilities, and can stably manage multiple physical hard drives.

[0028] During the configuration process, the disk array controller first identifies all physical hard drives connected to the storage node. Its built-in firmware performs initial checks on the hardware status of each hard drive (such as capacity, rotation speed, and health), eliminating drives with hardware failures or compatibility issues to ensure the stability of subsequent virtual disk construction. Then, based on preset virtual disk construction requirements (such as capacity planning and redundancy strategies), the disk array controller divides a specified number of physical hard drives into a logical group. Using a specific RAID algorithm (such as RAID 6's dual-parity algorithm), it integrates and manages the storage space of the physical hard drives, virtualizing the dispersed storage space of multiple physical hard drives into a contiguous virtual disk with a unified access address. During this process, the disk array controller also configures necessary parameters for the virtual disk (such as stripe size, which can be adjusted according to the data type of the business, such as 256KB stripes for large data read / write). Simultaneously, it enables a local redundancy protection mechanism, giving the virtual disk data verification and fault self-healing capabilities. For example, if a single physical hard drive in the group fails, the controller can reconstruct the data of the failed hard drive on the remaining physical hard drives using verification data, ensuring the data integrity and availability of the virtual disk.

[0029] Storage nodes can use disk array controllers to transform multiple physical hard drives into more functional virtual disks, laying the hardware foundation for the subsequent distributed storage layer to manage logical disks and build a "RAID + replica" dual-redundancy architecture. This not only reduces the complexity of directly managing a large number of physical hard drives in distributed storage, but also improves 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.

[0030] Step 102: Map the virtual disk to a logical volume of the distributed storage system, and use a multi-replica redundancy strategy based on the logical volume to store data, so as to build dual redundancy protection for the same data.

[0031] In this embodiment, in step 102, the virtual disk is a storage unit with local redundancy capabilities formed by integrating multiple physical hard drives through a disk array controller (such as a virtual disk built based on the RAID6 algorithm, with built-in dual-check data protection), while the logical volume is a storage resource carrier that the distributed storage system can directly manage. The mapping process between the two relies on the hardware adaptation module of the distributed storage system. Specifically, the distributed storage system identifies the virtual disk created by the disk array controller within the storage node through the underlying driver, obtains hardware parameters such as the virtual disk's capacity, interface protocol, and read / write performance, and then encapsulates the virtual disk into a logical volume that conforms to the distributed storage data management specifications through a logical volume management tool. During this process, a mapping table between 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 for the logical volume can be accurately translated into hardware operations on the virtual disk, while retaining the original local redundancy capabilities of the virtual disk and avoiding damage to the hardware-layer data protection mechanism during the mapping process.

[0032] After mapping is complete, the multi-replica redundancy strategy based on logical volumes is essentially to synchronize each piece of data written to the logical volume to logical volumes on different storage nodes according to a preset number of replicas (e.g., three replicas). This requires strong consistency – a successful data write response is only returned to the business side after all replicas have been successfully written and confirmed, ensuring real-time synchronization of data across replicas. This dual redundancy protection consists of two layers: the first layer is local redundancy from the hardware layer's virtual disks (e.g., the dual-parity mechanism of RAID 6, which can withstand data loss due to the failure of a single or two physical hard drives); the second layer is multi-replica redundancy from the software layer's distributed storage (e.g., a three-replica strategy, which can withstand data loss due to the failure of one or more storage nodes). These two layers of protection are independent yet synergistic: when a physical hard drive within a storage node fails, the local redundancy mechanism of the virtual disk can first repair the data, and the distributed storage system does not need to immediately trigger cross-node data reconstruction; when the entire storage node fails, the multi-replica redundancy strategy can quickly recover data through logical volume replicas on other nodes, avoiding data security risks caused by the failure of a single redundancy mechanism.

[0033] In actual data storage, distributed storage systems partition logical volumes, sharding data and distributing it evenly across different partitions. This, combined with replication strategies (such as distributing replicas across storage nodes in different racks and physical locations), further reduces the risk of concentrated hardware failures. Simultaneously, the system monitors the operational status of each logical volume in real time. When a logical volume experiences read / write anomalies due to an underlying virtual disk failure, it automatically switches the data replicas on that logical volume to other healthy logical volumes, ensuring continuous accessibility to business data.

[0034] By leveraging the local redundancy of virtual disks to simplify the management complexity of underlying hardware in distributed storage, and by strengthening cross-node data reliability through a multi-replica redundancy strategy, the dual redundancy protection significantly reduces the risk of data loss. At the same time, the logical volume, as an intermediate layer, isolates the impact of hardware layer changes on the distributed storage system (e.g., replacing a physical hard drive only requires reconfiguring the virtual disk, without adjusting the core data management logic of the distributed storage), indirectly reducing operation and maintenance costs and providing a foundation for the stable operation of the system in the future.

[0035] Step 103: When a single physical hard drive in the virtual disk experiences a slow disk or failure, a data reconstruction operation is initiated and executed within the storage node through the redundant disk array controller.

[0036] In this embodiment of the application, in step 103, a slow disk refers to a state in which the physical hard disk read / write response time exceeds a preset threshold (e.g., the normal hard disk IO response latency is within 10ms, while the slow disk latency lasts for more than 50ms) but is not completely failed. A fault refers to a situation in which the physical hard disk is completely unable to read or write data due to hardware damage (e.g., head failure, platter damage). Both 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 for managing the virtual disk, has the ability to monitor in real time and repair locally, and is the key carrier for initiating data reconstruction operations.

[0037] Specifically, the disk array controller continuously collects the operating data of each physical hard drive in the virtual disk through its built-in hardware monitoring module, including IO response time, data transfer rate, and SMART (Self-Monitoring, Analysis and Reporting Technology) parameters (such as the number of bad sectors, temperature, and motor speed). When the controller detects that the IO response time of a physical hard drive is consistently higher than the threshold (determined to be a slow disk), or when the SMART parameters trigger an alarm or data transfer is interrupted (determined to be a fault), the controller will immediately activate the fault isolation mechanism to suspend the read and write tasks of that physical hard drive in the virtual disk, so as to prevent it from affecting the IO performance of the entire virtual disk.

[0038] Subsequently, the disk array controller initiates a data reconstruction operation based on the RAID algorithm used by the virtual disk (such as the dual-parity mechanism of RAID6). First, it reads the valid data and parity data from the remaining healthy physical hard drives in the virtual disk, and then uses the RAID algorithm to reverse-calculate the data stored on the failed / slow physical hard drive. Next, it writes the calculated data to a pre-configured hot spare disk (if no hot spare disk is configured, it must wait until the failed hard drive is manually replaced before writing to the newly replaced hard drive). 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 drive in a virtual disk built on RAID6 fails, the controller uses the data from the remaining hard drives and two sets of parity data to accurately reconstruct all the data on the failed hard drive. During the reconstruction process, the virtual disk can still maintain normal read and write operations, with only a slight performance decrease, and business services will not be interrupted.

[0039] Data from a failed / slow physical hard drive can be quickly rebuilt locally on the storage node. The distributed storage system can only detect that the logical volume is in the "Rebuilding" state, without triggering large-scale data reconstruction across nodes. This avoids a surge in IO pressure and resource consumption at the distributed storage layer, while ensuring rapid data repair at the hardware layer, further enhancing the effectiveness of dual redundancy protection. Compared to the traditional distributed storage model that directly manages physical hard drives, this approach can reduce the frequency of data reconstruction caused by single-disk failures, reduce performance fluctuations caused by reconstruction, and improve the continuity and reliability of data storage.

[0040] This application provides a method for collaborative optimization of distributed storage. By utilizing a disk array controller to configure multiple physical hard drives within a storage node as virtual disks, and then mapping these virtual disks to logical volumes of the distributed storage system, a dual redundancy protection is constructed based on the logical volumes using a multi-replica redundancy strategy. When a single physical hard drive in the virtual disk experiences a slow disk or failure, the disk array controller initiates and executes a data reconstruction operation within the storage node. Therefore, it can solve the problems in existing technologies, such as large-scale data reconstruction triggered by single disk failure due to the reliance on multi-replica redundancy mechanisms in traditional distributed storage, a surge in disk I / O pressure, high operational complexity, a contradiction between performance and reliability, and low fault handling efficiency caused by the immaturity of hardware RAID and distributed storage collaborative optimization. This achieves the technical effects of reducing data loss risk, reducing disk wear, simplifying operational operations, balancing performance and reliability, improving single disk failure handling efficiency, and ensuring the continuous service capability of the distributed storage system.

[0041] In this embodiment of the application, the implementation is further specified as follows: real-time monitoring of the input and output performance indicators of each virtual disk; based on the performance indicators, allocating data write requests to virtual disks with lower loads through a dynamic load balancing algorithm.

[0042] Furthermore, in the embodiments of this application, the input / output performance metrics include the number of input / output operations per second and the throughput.

[0043] Specifically, real-time monitoring of the input / output performance metrics of each virtual disk is a fundamental step in ensuring the efficient operation of a distributed storage system. Here, a virtual disk refers to a storage unit with local redundancy capabilities, formed by integrating multiple physical hard drives through a disk array controller (such as a virtual disk built using the RAID 6 algorithm). Its input / output performance directly determines the overall data processing efficiency of the distributed storage system. Real-time monitoring relies on a collaborative acquisition mechanism between the hardware and software layers: the hardware layer uses the built-in monitoring module of the disk array controller to capture the hardware-level operational data of each virtual disk in real time; the software layer uses the performance acquisition components of the distributed storage system to convert the hardware layer data into standardized input / output performance metrics, ensuring the real-time nature and accuracy of the monitoring data and avoiding load assessment errors caused by data latency.

[0044] The input / output performance metrics specifically include Operations Per Second (IOPS) and throughput. IOPS reflects the number of read / write requests a virtual disk can process per unit of time, directly impacting the processing efficiency of small data blocks (such as database transaction data). For example, a low IOPS value for a virtual disk indicates insufficient capacity to handle frequent, small-scale read / write requests. Throughput, on the other hand, refers to the amount of data a virtual disk can transfer per unit of time (usually measured in MB / s or GB / s), primarily affecting the read / write speed of large data blocks (such as video files or backup data). A decrease in throughput for a virtual disk indicates a bottleneck in handling large-scale data transfer tasks. Monitoring both metrics simultaneously provides a comprehensive picture of the virtual disk's actual load status—relying on only one metric may lead to misjudgments. For instance, a high IOPS but low throughput for a virtual disk might indicate excessive IO resources being consumed by processing a large number of small requests, still warranting classification as a high-load state.

[0045] Based on the aforementioned real-time collected performance metrics, a dynamic load balancing algorithm distributes data write requests to virtual disks with lower loads. The core of this algorithm is to achieve reasonable scheduling of storage resources. The dynamic load balancing algorithm first establishes a virtual disk load assessment model, assigning different weights to IOPS and throughput metrics according to business priority (e.g., IOPS is prioritized for small data transactions, while throughput is prioritized for large data transactions), and calculates the comprehensive load value for each virtual disk. Subsequently, the algorithm compares the comprehensive load values ​​of each virtual disk in real time, identifying virtual disks with lower loads (i.e., comprehensive load values ​​below a preset threshold) and recording their current idle IO resources and data transfer bandwidth. When the distributed storage system receives a data write request, the algorithm matches the corresponding load assessment dimension based on the data type of the request (small / large blocks), and allocates the request to virtual disks with lower loads that are suitable for processing that data type—for example, for small data write requests, priority is given to virtual disks with high IOPS idle rates; for large data write requests, priority is given to virtual disks with sufficient throughput redundancy. Meanwhile, the algorithm continuously tracks the performance changes of the virtual disk after the request is allocated. If the load of a virtual disk suddenly increases due to newly allocated write requests, the algorithm will adjust the subsequent request allocation strategy in a timely manner to prevent the virtual disk from becoming a new performance bottleneck.

[0046] This approach effectively avoids performance degradation caused by excessive load on some virtual disks, while fully utilizing virtual disk resources with lower loads to improve the IO utilization of the entire distributed storage system. In addition, the dynamic allocation mechanism can adapt to the dynamic changes in business data types without the need for manual adjustment of allocation strategies, reducing operation and maintenance intervention costs, and ultimately achieving a stable improvement in data writing efficiency and optimization of overall system performance.

[0047] In this embodiment of the application, the embodiment is further specified as follows: a hot standby logical volume is pre-configured in the distributed storage system; when a physical hard disk failure is detected, the data service is switched to the hot standby logical volume.

[0048] Specifically, a hot standby logical volume refers to a logical volume that is pre-configured and in standby mode during the deployment phase of a distributed storage system. Its core function is to serve as a "backup resource" for failed logical volumes, ensuring rapid data service failover in the event of hardware failure. The pre-configuration of hot standby logical volumes relies on the previously completed virtual disk mapping. First, from the virtual disks constructed by the disk array controller within the storage node, virtual disks with performance parameters (such as IOPS and throughput) that match the business's currently used logical volumes are selected. Then, using the distributed storage system's logical volume management tools, these are encapsulated into hot standby logical volumes that conform to data storage specifications. During configuration, the hot standby logical volume must be pre-configured with the same storage parameters as the currently used logical volumes (such as capacity and replication policy compatibility), while maintaining a "low-load standby" state. It only synchronously updates necessary system metadata, does not participate in daily data read / write operations, avoids consuming business resources, and ensures rapid response during failover.

[0049] During system operation, the distributed storage system monitors the physical hard drive status in real time through a full-stack monitoring system. This system integrates SMART data from the disk array controller (such as the number of bad sectors and temperature warnings) and IPMI hardware status monitoring (such as hard drive power supply and interface connection status) to double-verify the health of the physical hard drives. When a physical hard drive failure is detected (such as SMART parameters triggering a critical threshold or IPMI detecting a hard drive offline), the system immediately determines the virtual disk to which the failed hard drive belongs and then locates the active logical volume mapped by that virtual disk.

[0050] At this point, the failover mechanism will be activated immediately: First, the read and write services of the faulty in-use logical volume will be suspended. Then, through the metadata management module of the distributed storage system, the business access address of the logical volume will be quickly redirected to the pre-configured hot standby logical volume. Subsequently, the hot standby logical volume will synchronize the data that has not been lost in the faulty logical volume based on the multi-replica strong consistency strategy of the distributed storage (because the underlying virtual disk has RAID local redundancy, the data of the faulty hard disk can be rebuilt through RAID, and the hot standby logical volume only needs to supplement a small amount of incremental data), quickly restoring data integrity. After the data synchronization is completed, the hot standby logical volume will officially take over all data services of the original in-use logical volume. The entire switchover process is transparent to the upper-layer business and requires no manual intervention.

[0051] The pre-configuration of hot standby logical volumes avoids the time consumption of temporarily creating logical volumes after a failure, significantly shortens the failover cycle, and reduces the risk of business interruption. At the same time, relying on the local redundancy of virtual disks and the rapid replacement of hot standby logical volumes, the dual redundancy effect of "hardware RAID + distributed replica" is further strengthened, reducing the probability of data service degradation caused by physical hard disk failure, and indirectly improving the continuous service capability and operation and maintenance efficiency of distributed storage systems.

[0052] In this embodiment of the application, the embodiment is further specified as follows: data caching is performed using the cache of the disk array controller and the non-volatile memory cache of the distributed storage system to reduce the latency of data verification and writing.

[0053] Specifically, the disk array controller's cache and the distributed storage system's non-volatile memory cache (NVMe cache) are both core caching components for improving data read and write efficiency. Their collaborative work requires deep adaptation of hardware resources and software strategies. The disk array controller's cache is a high-speed storage unit integrated into the RAID card, equipped with an independent read / write control chip. It can temporarily store data and verification information to be written to the physical hard drive. In write-back mode, after receiving data, the controller first writes it to the cache and returns a "write successful" response to the system. Subsequently, it asynchronously flushes the cached data to the physical hard drive, significantly reducing the waiting time for a single write operation. The distributed storage system's NVMe cache, built on non-volatile memory, combines high-speed read / write and data persistence capabilities. It prioritizes the storage of frequently accessed business data (such as frequently accessed small files and real-time transaction data), reducing repeated access to the underlying virtual disk.

[0054] The specific process of the collaborative caching is as follows: When the distributed storage system receives a data write request, it first divides the data into "hot data" and "non-hot data." Hot data is preferentially written to the distributed storage's NVMe cache, leveraging its low latency to achieve a fast response. Simultaneously, the NVMe cache synchronizes data metadata to the disk array controller cache in real time. Non-hot data is directly transmitted to the disk array controller cache, where it is temporarily stored and parity calculations are initiated (e.g., double parity calculations in RAID 6). During this process, the disk array controller cache and the NVMe cache establish a data interaction channel via the PCIe bus. The controller cache synchronizes the calculated parity information to the NVMe cache, preventing the distributed storage system from repeatedly performing parity calculations and reducing CPU resource consumption. Furthermore, when a certain amount of hot data accumulates in the NVMe cache, it is combined with the idle state of the disk array controller cache to batch-flush the data into the controller cache, which then asynchronously writes it to the virtual disk, avoiding increased IO overhead caused by frequent small data block write operations.

[0055] The key to reducing data verification latency lies in the collaborative sharing of verification calculations between the two: In the traditional model, data verification calculations must be completed at the distributed storage layer before being transmitted to the hardware layer, resulting in dual latency from software calculations and data transmission. In this solution, the disk array controller cache can rely on the hardware acceleration module of the RAID card to directly perform verification calculations on the received data. After the calculation results are synchronized to the NVMe cache, the distributed storage system only needs to verify the integrity of the verification information without re-performing the calculations, significantly shortening the verification process time. Regarding data write latency optimization, the write-back mode RAID card cache solves the latency problem of "data waiting to be flushed to disk," while the NVMe cache solves the latency problem of "repeated access to hot data." The collaboration between the two creates an efficient data write path of "NVMe cache temporarily storing hot data → RAID card cache batch processing verification and asynchronous flushing to disk," avoiding the cumulative latency caused by insufficient capacity or excessive load of a single cache component.

[0056] Through this collaborative caching mechanism, the data verification process does not require repeated calculations across layers, and data writing does not require waiting for the slow response of the physical hard drive, effectively reducing the overall latency of data verification and writing. At the same time, relying on the high-speed hardware characteristics of RAID card caching and NVMe caching, the stability of data reading and writing is further improved, providing performance support for distributed storage systems to handle high-concurrency write scenarios (such as real-time big data collection and high-frequency transaction data storage), and indirectly enhancing the service response efficiency under the "RAID + replica" dual redundancy architecture.

[0057] In this embodiment of the application, the embodiment is further specified as follows: using bus channel segmentation technology, the traffic of the virtual disk is isolated from the input and output traffic directly to the physical hard disk.

[0058] Specifically, the core of bus channel segmentation technology relies on the server hardware's bus architecture (such as a configured PCIe 4.0 x16 bus) to achieve independent transmission of traffic for managing virtual disks and input / output traffic directly to physical hard drives through hardware-level channel division and protocol isolation. Traffic for managing virtual disks refers to the data interaction traffic between the disk array controller and the virtual disks, including virtual disk creation, parameter configuration, data verification calculation, and data transmission during fault reconstruction. Input / output traffic directly to physical hard drives refers to the business traffic of the distributed storage system directly reading and writing data to physical hard drives (if any) not included in the RAID group. If these two types of traffic share the same bus channel, the superposition of traffic peaks can easily lead to bus bandwidth contention, causing data transmission delays or even packet loss.

[0059] In practical implementation, the first step is to logically segment the PCIe channels based on the server's PCIe bus topology using BIOS or hardware configuration tools: divide the server's PCIe 4.0 x16 bus into two independent sub-channels. For example, allocate 8 PCIe channels specifically for connecting to the disk array controller, ensuring stable transmission bandwidth for traffic managing virtual disks; the remaining 8 PCIe channels are used to connect to the interface controller that directly connects to the physical hard drives, ensuring independent transmission paths for input and output traffic. Simultaneously, at the bus protocol level, configure different transmission priorities for the two types of traffic through the disk array controller's firmware settings—traffic managing virtual disks (such as RAID reconstruction data) is set to high priority to avoid delays in virtual disk failure repair due to insufficient bandwidth; input and output traffic directly connecting to physical hard drives is prioritized according to business needs to ensure that core business data transmission is not affected.

[0060] Furthermore, a channel identification module needs to be added to the underlying driver of the distributed storage system. This allows the system to automatically distinguish between 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 SMART data or adjusting RAID stripe parameters), the driver directs this type of traffic to the PCIe sub-channel belonging to the disk array controller; when the system performs business data read / write operations (such as user file storage or database data query), the driver allocates input / output traffic to the PCIe sub-channel corresponding to the physical hard drive. This hardware-level channel isolation fundamentally avoids mutual interference between the two types of traffic at the bus level, breaking through the bandwidth bottleneck of traditional shared bus architectures.

[0061] Traffic for managing virtual disks is transmitted independently from input / output traffic directly to physical hard drives. This ensures the stability of virtual disk management operations (such as stable data transmission rates during RAID reconstruction, unaffected by fluctuations in business traffic) and avoids increased latency caused by bus contention for business input / output traffic. This significantly improves the bandwidth utilization of the PCIe bus and provides a stable hardware transmission foundation for subsequent hardware and software layer collaborative optimization (such as hybrid caching mechanisms and dynamic load balancing), indirectly enhancing the overall read / write performance and operational stability of the distributed storage system.

[0062] In this embodiment of the application, the implementation is further specified as follows: dynamically adjusting the striping size of the virtual disk according to the data type of the business application.

[0063] Specifically, in this embodiment, the striping size of the virtual disk refers to the size of the virtual disk storage space divided into multiple equally sized data blocks (i.e., stripes). This directly affects the verification overhead and transmission efficiency during data read / write operations. Too small a stripe can lead to multiple stripes being required for a single read / write operation, increasing the number of verification calculations and bus transmission frequency. Too large a stripe can result in wasted storage space, and reading / writing small data blocks can easily trigger operations across the entire stripe, reducing IO response speed. Business data types can be categorized by block size into large data blocks (such as video files and backup data, with single blocks typically exceeding 100MB) and small data blocks (such as database transaction data and log files, with single blocks mostly below 1MB). Different data types have significantly different requirements for striping size adaptation; therefore, striping parameters need to be dynamically adjusted based on the business data type.

[0064] The specific adjustment process relies on the collaborative implementation of the stripe adaptation 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 being processed in real time through the business identification module. This is done by factors such as file extensions, data transmission protocols (e.g., object storage S3 protocol often corresponds to large data blocks, while database JDBC protocol often corresponds to small data blocks), or preset business tags to determine whether the data is large or small. Subsequently, the system synchronizes the data type identification results to the parameter control unit of the disk array controller. The controller automatically adjusts the stripe size of the corresponding virtual disk according to preset striping adaptation rules (e.g., large data blocks match 256KB-1MB stripes, small data blocks match 64KB-128KB stripes). For example, when processing video stream writes, the controller adjusts the stripe size to 256KB, ensuring that a single data write can cover a single stripe, reducing cross-strip verification calculations and lowering verification overhead. When processing high-frequency database transaction writes, the controller reduces the stripe size to 64KB, ensuring that small data blocks accurately match the stripe size, avoiding storage space fragmentation and IO resource waste caused by excessively large stripes.

[0065] To ensure stability during dynamic adjustments, the disk array controller employs an "incremental adjustment" strategy: first, it tests the adaptability of the new stripe size on the free partitions of the virtual disk, monitors performance metrics such as read / write latency and verification calculation time after adjustment, and then gradually switches the stripe size of the currently used partitions to the new parameters after confirming that the metrics meet expectations, thus avoiding data read / write interruptions caused by direct adjustments. At the same time, the distributed storage system synchronizes the stripe adjustment progress in real time and optimizes the data sharding strategy according to the new stripe size to ensure that the data shards match the stripe size, further improving read / write efficiency.

[0066] Through this dynamic adjustment mechanism, the striped size of the virtual disk can be precisely adapted to the business data type. This avoids the limitations of fixed stripe sizes in adapting to different business scenarios. Furthermore, by optimizing verification overhead and read / write efficiency, it indirectly improves the IO performance of the virtual disk. This lays a performance foundation for the subsequent adoption of multi-replica redundancy strategies and the construction of dual redundancy protection in distributed storage systems. At the same time, it reduces the waste of hardware resources caused by improper stripe adaptation and improves the overall resource utilization of storage nodes.

[0067] In this embodiment of the application, the disk array controller is further specified as being at the RAID 6 level.

[0068] Specifically, in this embodiment, the disk array controller is set to RAID 6. RAID 6, as a disk array level with dual parity mechanism, has the core advantage of being able to withstand the failure of two physical hard drives simultaneously. Compared to RAID 5, which only supports single-disk failure recovery, it can provide more reliable local data redundancy protection for virtual disks. This is also the key hardware foundation for building a "hardware RAID + distributed replication" dual redundancy architecture. Specifically, RAID 6 introduces two independent parity blocks (usually calculated based on the P+Q dual parity algorithm) into the physical hard drive group, distributing the parity data across different physical hard drives. When one or two physical hard drives in a RAID group within a storage node fail simultaneously (such as physical hard drive damage or interface failure), the disk array controller can use the data in the remaining physical hard drives and these two parity blocks to accurately reconstruct all the data in the failed hard drive through reverse calculation. Moreover, the reconstruction process is completed independently locally on the storage node, without relying on the cross-node resources of the distributed storage system, thus avoiding the situation where large-scale data reconstruction of the distributed storage layer is triggered by hardware failure.

[0069] In actual configuration, the disk array controller allocates the storage locations of data blocks and parity blocks according to the number of connected physical hard drives and the RAID 6 algorithm. For example, when building a RAID 6 group using 7 physical hard drives, the controller will use the storage space of 5 hard drives to store business data, and the remaining 2 hard drives to store dual parity data. The parity data will be evenly distributed in a striped manner to avoid a single parity hard drive becoming a performance bottleneck. Furthermore, RAID 6 also supports pre-configuring hot spare drives within the RAID group. When a physical hard drive shows signs of slowness or failure, the controller can automatically activate the hot spare drive, quickly migrating the data and parity information from the failed hard drive to the hot spare drive, further shortening the fault recovery time and ensuring the continuous availability of the virtual disk.

[0070] From the perspective of data security and system stability, choosing RAID 6 effectively compensates for the limitations of traditional distributed storage that relies solely on multiple replicas for redundancy. When a local hardware failure occurs within a storage node, RAID 6's dual-parity mechanism can immediately restore local data, reducing the risk of distributed storage replicas being lost due to the simultaneous failure of multiple hard drives. From a performance perspective, although RAID 6 incurs some performance overhead due to dual-parity calculations, this overhead can be kept within a reasonable range by optimizing data write paths and reducing parity calculation latency, ensuring that the read and write efficiency of the virtual disk meets business requirements.

[0071] By setting the disk array controller level to RAID 6, the virtual disk is given stronger local redundancy and fault self-healing capabilities. This not only improves the data reliability of a single storage node, but also provides solid hardware support for the subsequent distributed storage layer to build dual redundancy protection using a multi-replica strategy. Ultimately, this effectively reduces the risk of data loss in the entire storage system, while also reducing the frequency of maintenance intervention and resource consumption caused by hardware failures.

[0072] In this embodiment of the application, the embodiment is further specified as follows: collecting the status information of the disk array controller and the distributed storage system, and performing status warnings based on the status information.

[0073] Specifically, in this embodiment, collecting the status information of the disk array controller and the distributed storage system is the foundation for achieving full-stack monitoring and status early warning. These two types of status information cover core operational data at both the hardware and software layers, requiring a multi-source data acquisition mechanism to ensure the comprehensiveness and real-time nature of the information. The disk array controller's status information mainly includes hardware-level operational data, specifically the controller's own operating status (e.g., whether it is in Active mode, PCIe bus connection status), the status of the managed virtual disks (e.g., Optimal normal state, Degraded state, Rebuilding state), and physical hard drive health data obtained through SMART (Self-Monitoring, Analysis and Reporting Technology) (e.g., number of bad sectors, hard drive temperature, cumulative power-on time, read / write error rate). This data needs to be captured in real-time through the disk array controller's dedicated management interface (e.g., the Storcli tool) to ensure timely detection of potential hardware-level faults.

[0074] The status information of the distributed storage system focuses on the software layer's operational status, covering logical volume read / write performance metrics (such as IOPS, throughput, and read / write latency), multi-replica synchronization status (such as whether replicas meet strong consistency and whether there are missing replicas), storage node resource usage (such as CPU utilization, memory utilization, and network bandwidth utilization), and system operation logs (such as data write failure logs and node communication anomaly logs). This information is collected through the monitoring components built into the distributed storage system, and some key metrics (such as replica synchronization status) need to be synchronized to the hardware layer monitoring module in real time to achieve linkage and alignment of software and hardware status.

[0075] After status information collection is completed, status early warning needs to be implemented through data integration and analysis: First, the collected multi-source data (disk array controller SMART data, IPMI hardware status data, and distributed storage logs) are uniformly connected to a time-series database built on Prometheus for data cleaning and standardization to eliminate format differences between different data sources; then, based on preset early warning thresholds and anomaly judgment rules, the integrated data is analyzed in real time—for example, when the disk array controller reports that the number of bad sectors on a physical hard drive exceeds the threshold, or when the distributed storage system detects that the read / write latency of a logical volume is consistently higher than the normal range, the system will automatically trigger an early warning mechanism; finally, the early warning information is displayed in real time through a visualization platform in the form of charts, alarm pop-ups, etc., and combined with the hard drive life prediction model (based on SMART data trend analysis), replacement reminders are issued in advance for hardware that is about to reach its lifespan threshold, and emergency alarms are pushed for abnormal states that may cause data risks (such as multi-replica synchronization interruption) to ensure that maintenance personnel can intervene and handle them in a timely manner.

[0076] This implementation method enables comprehensive monitoring and early warning of the disk array controller and distributed storage system status. It avoids business interruptions caused by undetected hardware failures, reduces the frequency of passive maintenance through the early warning mechanism, lowers the response time for fault handling, and further ensures the stable operation of the "hardware RAID + distributed replica" dual-redundancy architecture. This indirectly improves the continuous service capability and data security of the entire storage system.

[0077] It should be noted that the embodiments of this disclosure may include multiple steps. For ease of description, these steps are numbered, but these numbers are not a limitation on the execution time slots or execution order between the steps; these steps can be implemented in any order, and the embodiments of this disclosure do not limit this.

[0078] Corresponding to the aforementioned distributed storage collaborative optimization method, this disclosure also proposes a distributed storage collaborative optimization apparatus. Since the apparatus embodiments of this disclosure correspond to the aforementioned method embodiments, details not disclosed in the apparatus embodiments can be referred to the aforementioned method embodiments, and will not be repeated here.

[0079] Figure 2 This is a schematic diagram of the structure of a distributed storage collaborative optimization device provided in an embodiment of this disclosure, as shown below. Figure 2 As shown, it includes:

[0080] Configuration unit 21 is used to configure multiple physical hard disks in a storage node as virtual disks using a disk array controller;

[0081] The mapping unit 22 is used to map the virtual disk to a logical volume of the distributed storage system, and to use a multi-replica redundancy strategy to store data based on the logical volume, so as to build dual redundancy protection for the same data.

[0082] The reconstruction unit 23 is used to initiate and execute a data reconstruction operation within the storage node through the redundant disk array controller when a single physical hard disk in the virtual disk experiences a slow disk or failure.

[0083] It should be noted that the foregoing explanation of the method embodiments also applies to the apparatus of this embodiment, and the principle is the same, so it is not limited in this embodiment.

[0084] For a description of the features in the embodiment corresponding to the distributed storage collaborative optimization device, please refer to the relevant description in the embodiment corresponding to the distributed storage collaborative optimization method, which will not be repeated here.

[0085] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above-described distributed storage cooperative optimization method embodiments.

[0086] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described distributed storage collaborative optimization method embodiments at runtime.

[0087] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0088] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described distributed storage collaborative optimization method embodiments.

[0089] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described distributed storage cooperative optimization method embodiments.

[0090] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0091] The foregoing has provided a detailed description of the method, apparatus, electronic device, and storage medium for distributed storage collaborative optimization provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A method for distributed storage collaborative optimization, characterized in that, include: The disk array controller is used to configure multiple physical hard drives within a storage node as virtual disks; The virtual disk is mapped to a logical volume of a distributed storage system, and a multi-replica redundancy strategy is used to store data based on the logical volume, so as to build dual redundancy protection for the same data. When a single physical hard drive in the virtual disk experiences a slow disk or failure, the disk array controller initiates and executes a data reconstruction operation within the storage node based on the RAID algorithm used by the virtual disk. The data reconstruction operation is completed independently within the storage node without the need for the distributed storage system to intervene in cross-node data reconstruction. The method further includes: Real-time monitoring of the input / output performance metrics of each virtual disk; Based on the aforementioned performance metrics, a dynamic load balancing algorithm is used to distribute data write requests to virtual disks with lower loads. The input / output performance metrics include the number of input / output operations per second and throughput. The method further includes: Pre-configure hot-standby logical volumes in the distributed storage system; When a physical hard drive failure is detected, the data service will be switched to the hot standby logical volume; The method further includes: Data caching is performed using the cache of the disk array controller and the non-volatile memory cache of the distributed storage system to reduce the latency of data verification and writing. The method further includes: Bus channel segmentation technology is used to isolate and manage the traffic of the virtual disk from the input / output traffic that directly reaches the physical hard disk.

2. The method for distributed storage collaborative optimization according to claim 1, characterized in that, The method further includes: The striping size of the virtual disk is dynamically adjusted based on the data type of the business application.

3. The method for distributed storage collaborative optimization according to claim 1, characterized in that, The disk array controller is configured for RAID 6.

4. The method for distributed storage collaborative optimization according to claim 1, characterized in that, The method further includes: The status information of the disk array controller and the distributed storage system is collected, and status warnings are issued based on the status information.

5. A device for distributed storage collaborative optimization, characterized in that, include: The configuration unit is used to configure multiple physical hard drives within a storage node as virtual disks using the disk array controller; The mapping unit is used to map the virtual disk to a logical volume of the distributed storage system, and to store data based on the logical volume using a multi-replica redundancy strategy to build dual redundancy protection for the same data. The reconstruction unit is used to initiate and execute a data reconstruction operation within the storage node by the disk array controller based on the RAID algorithm used by the virtual disk when a single physical hard drive in the virtual disk experiences a slow disk or failure. The data reconstruction operation is completed independently within the storage node without the need for the distributed storage system to intervene in cross-node data reconstruction. The device is also used for: Real-time monitoring of the input / output performance metrics of each virtual disk; Based on the aforementioned performance metrics, a dynamic load balancing algorithm is used to distribute data write requests to virtual disks with lower loads. The input / output performance metrics include the number of input / output operations per second and throughput. The device is also used for: Pre-configure hot-standby logical volumes in the distributed storage system; When a physical hard drive failure is detected, the data service will be switched to the hot standby logical volume; The device is also used for: Data caching is performed using the cache of the disk array controller and the non-volatile memory cache of the distributed storage system to reduce the latency of data verification and writing. The device is also used for: Bus channel segmentation technology is used to isolate and manage the traffic of the virtual disk from the input / output traffic that directly reaches the physical hard disk.

6. An electronic device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, which, when executed, enable the at least one processor to perform the distributed storage collaborative optimization method according to any one of claims 1-4.

7. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to perform the distributed storage collaborative optimization method according to any one of claims 1-4.

8. A computer program product, characterized in that, It includes a computer program that, when executed by a processor, implements the distributed storage collaborative optimization method according to any one of claims 1-4.

Images