A hardware acceleration unit disaster recovery method, system, device and computer medium

Abstract

The application discloses a hardware acceleration unit disaster recovery method, system, device and computer medium, relates to the technical field of disk arrays, and is applied to a RAID controller, acquires an I / O instruction to be processed, analyzes the I / O instruction to obtain task information, constructs an I / O task containing a hardware acceleration unit based on the task information, detects whether the I / O task contains a failed hardware acceleration unit, replaces the failed hardware acceleration unit with a software acceleration unit in response to the I / O task containing the failed hardware acceleration unit, and calls the replaced software acceleration unit to process the task. In the application, the RAID controller replaces the failed hardware acceleration unit with a normal software acceleration unit to process the task, so that the I / O operation can be ensured to be smooth and continuous, the impact of the hardware acceleration unit failure on I / O business is reduced, and the I / O performance and data reliability of the RAID controller are improved.

Description

Technical Field

[0001] This application relates to the field of disk array technology, and more specifically, to a method, system, device, and computer medium for disaster recovery of a hardware acceleration unit. Background Technology

[0002] RAID (Redundant Arrays of Independent Disks) is a disk array composed of multiple independent disks. Data is divided into segments and stored on each disk. It can increase storage capacity, improve system I / O request processing capabilities, and enhance data reliability through distributed storage technology, parallel access methods, and information redundancy techniques. The RAID controller is the device used to manage RAID. It is typically designed with an architecture consisting of multiple Hardware Acceleration Units (HAUs) working collaboratively to form a complete RAID controller system.

[0003] In RAID controller applications, situations arise where the HAU (Host Access Controller) fails. In this case, for I / O (Input / Output) requests that haven't yet responded to the host, the lack of necessary response and processing capabilities forces the controller to report operation failures to the host, disrupting business processes. Upper-layer applications may experience abnormal interruptions or errors, impacting business continuity. While backups of the cached data are implemented to restore the data after replacing the RAID controller, this process is complex and risky. Both approaches lead to reduced I / O performance and data reliability of the RAID controller.

[0004] In conclusion, improving the I / O performance and data reliability of RAID controllers is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0005] The purpose of this application is to provide a hardware acceleration unit disaster recovery method, which can, to a certain extent, solve the technical problem of how to improve the I / O performance and data reliability of RAID controllers. This application also provides a hardware acceleration unit disaster recovery system, electronic device, and computer-readable storage medium.

[0006] To achieve the above objectives, this application provides the following technical solution: A hardware acceleration unit disaster recovery method, applied to a RAID controller, includes: Obtain the I / O instructions to be processed; Parse I / O instructions to obtain task information; Based on the task information, an I / O task including a hardware acceleration unit is constructed; Detect whether the I / O task contains a faulty hardware acceleration unit; If an I / O task contains a faulty hardware acceleration unit, the faulty hardware acceleration unit is replaced with a software acceleration unit. The replaced software acceleration unit is invoked for task processing.

[0007] In an exemplary embodiment, detecting whether the I / O task includes a failed hardware acceleration unit includes: Obtain the HAU status table, which is used to record whether the hardware acceleration unit is normal or faulty; Read all hardware acceleration units in the I / O task; For each hardware acceleration unit in the I / O task, the status of the hardware acceleration unit is determined in the HAU status table. If the status is "failed", it is determined that the I / O task contains a failed hardware acceleration unit.

[0008] In an exemplary embodiment, it also includes: During the power-on initialization phase of the RAID controller, acquire the functional test set; The functional test set is applied to perform functional tests on each hardware acceleration unit to obtain functional test results. The functional tests include register read / write tests, data path tests, computational function tests, and memory management tests. Based on the functional test results, check whether the hardware acceleration unit passes all functional tests; In response to the hardware acceleration unit passing all functional tests, the status of the hardware acceleration unit is marked as normal in the HUA status table; If the hardware acceleration unit fails all functional tests, the hardware acceleration unit is marked as failed in the HUA status table.

[0009] In an exemplary embodiment, detecting whether the I / O task includes a failed hardware acceleration unit includes: Based on the I / O task, determine the currently invoked hardware acceleration unit and the subtasks that need to be processed; The subtask is passed to the currently invoked hardware acceleration unit for processing; Detect whether an interrupt notification signal has been received, the interrupt notification signal including an interrupt signal generated when the currently invoked hardware acceleration unit detects a fault; In response to receiving an interrupt notification signal, the currently pending event data is read from the hardware event queue according to the head pointer of the hardware event queue; The event data is parsed to obtain the error code; Detect whether the error code indicates that the currently invoked hardware acceleration unit has failed; If the error code indicates that the currently invoked hardware acceleration unit has failed, then the currently invoked hardware acceleration unit is determined to have failed.

[0010] In an exemplary embodiment, after determining that the currently invoked hardware acceleration unit has failed, the method further includes: In the HUA status table, the currently invoked hardware acceleration unit is marked as inactive.

[0011] In an exemplary embodiment, replacing the malfunctioning hardware acceleration unit with a software acceleration unit includes: Determine the location of the failed hardware acceleration unit in the I / O task; In I / O tasks, remove malfunctioning hardware acceleration units; According to the location information, the software acceleration unit is inserted into the corresponding position of the I / O task.

[0012] In an exemplary embodiment, inserting the software acceleration unit into the corresponding position of the I / O task according to the location information includes: In the I / O task, the preceding and following hardware acceleration units of the failed hardware acceleration unit are determined according to the location information. The next acceleration unit of the preceding hardware acceleration unit is pointed to the software acceleration unit; The next acceleration unit of the software acceleration unit is pointed to the next hardware acceleration unit.

[0013] A hardware acceleration unit disaster recovery system, applied to a RAID controller, includes: The instruction fetching module is used to fetch I / O instructions to be processed; The instruction parsing module is used to parse I / O instructions to obtain task information; The task construction module is used to construct an I / O task containing a hardware acceleration unit based on the task information. The failure detection module is used to detect whether the I / O task contains a failed hardware acceleration unit; The unit replacement module is used to replace the faulty hardware acceleration unit with a software acceleration unit in response to an I / O task containing a faulty hardware acceleration unit. The unit invocation module is used to invoke the replaced software acceleration unit for task processing.

[0014] An electronic device, comprising: Memory, used to store computer programs; A processor for implementing the steps of any of the methods described above when executing the computer program.

[0015] A computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of any of the methods described above.

[0016] This application provides a hardware acceleration unit disaster recovery method applied to a RAID controller. The method involves: acquiring I / O instructions to be processed; parsing the I / O instructions to obtain task information; constructing an I / O task containing hardware acceleration units based on the task information; detecting whether the I / O task contains a failed hardware acceleration unit; replacing the failed hardware acceleration unit with a software acceleration unit in response to the failure; and calling the replaced software acceleration unit to process the task. In this application, after the RAID controller converts the I / O instructions into I / O tasks, it needs to detect whether the I / O task contains a failed hardware acceleration unit. If so, the failed hardware acceleration unit needs to be replaced with a normal software acceleration unit to process the task. This ensures that the overall function of the RAID controller is not affected by the failed hardware acceleration unit, and I / O operations can be performed smoothly and continuously. This reduces the impact of hardware acceleration unit failure on I / O services, enhances the RAID controller's ability to cope with sudden hardware acceleration unit failures, and improves the RAID controller's I / O performance and data reliability. The hardware acceleration unit disaster recovery system, electronic device, and computer-readable storage medium provided in this application also solve corresponding technical problems. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0018] Figure 1 A flowchart illustrating a hardware acceleration unit disaster recovery method provided in this application embodiment; Figure 2 This is a schematic diagram of the I / O task structure; Figure 3 This is a schematic diagram illustrating the replacement of the acceleration unit; Figure 4 I / O static disaster recovery flowchart; Figure 5This is a diagram illustrating static disaster recovery for I / O. Figure 6 A diagram illustrating the power-on self-test of the HAU; Figure 7 This is a dynamic disaster recovery flowchart; Figure 8 A schematic diagram of a hardware acceleration unit disaster recovery system provided in this application embodiment; Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application; Figure 10 This is another structural schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0019] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0020] To facilitate understanding of the RAID controller and HUA involved in this application, both will be explained first. The RAID controller comprehensively controls the operation and management of the RAID array. The RAID controller possesses a range of powerful functions, from flexibly implementing and managing multiple RAID levels to finely handling data allocation and storage path planning, from robustly ensuring data redundancy to efficiently executing data recovery tasks, from significantly optimizing IO performance to accurately completing protocol conversion and adaptation. The role of the RAID controller is ubiquitous and indispensable. To achieve these complex and critical functions, the RAID controller is typically designed as an architecture where multiple hardware acceleration units with different functions work collaboratively. These hardware acceleration units cooperate to build a complete RAID controller system. Each hardware acceleration unit focuses on handling a specific type of task, undertaking a key link in the entire data processing flow. Each hardware acceleration unit is a highly specialized hardware circuit module with the ability to process specific tasks quickly and efficiently.

[0021] Furthermore, within the HAUs of a RAID controller, algorithm-based HAUs are the core force in handling data transformation. These include units for compression / decompression, data encryption / decryption, and erasure coding / decoding. These HAUs are responsible for deeply processing and transforming data transmitted from the host or disk. For example, compression / decompression units can effectively reduce the space occupied by data and improve storage efficiency; data encryption / decryption units are responsible for data security, preventing information leakage during data storage and transmission; erasure coding / decoding units play a crucial role in achieving data redundancy and error correction, ensuring data integrity and reliability, especially in the face of abnormal situations such as disk failures, where they can quickly recover lost data through algorithms. The host interface management HAU is the bridge between the RAID controller and the host, responsible for control and data flow interaction with the host. It ensures that the host's instructions are accurately transmitted to the RAID controller and that the data processed by the RAID controller is fed back to the host in a timely and complete manner, maintaining the collaborative relationship between the storage system and the host system. The Dynamic Memory Management (HAU) acts as a "resource scheduler," dynamically and flexibly managing and allocating limited memory resources. Based on the needs of each module of the RAID controller at different working stages, it rationally allocates memory, ensuring efficient utilization of memory resources when handling complex and ever-changing storage tasks. This avoids memory congestion or resource idleness, thus guaranteeing the smooth operation and performance of the RAID controller. The Host DMA (Direct Memory Access) HAU, leveraging DMA technology, can quickly and efficiently move large amounts of data between the host memory and the RAID controller, thereby improving the overall system's data transfer efficiency and performance. The I / O Coprocessor HAU directly handles disk operations, specifically responsible for performing disk read and write operations. Whether it's reading data from the disk to fulfill the host's read requests or stably storing data written by the host to the disk, the precise control and efficient execution of the I / O Coprocessor HAU are indispensable. These HAUs each perform their specific functions within the RAID controller, yet they also work together to create a powerful, high-performance, and highly stable storage management hub. This enables the RAID system to provide robust support and reliable assurance for various data storage applications, meeting the diverse needs of different users for data storage capacity, performance, security, and reliability.

[0022] Based on this, please refer to Figure 1 , Figure 1 A flowchart illustrating a hardware acceleration unit disaster recovery method provided in this application embodiment.

[0023] This application provides a hardware acceleration unit disaster recovery method applied to a RAID controller, which may include the following steps: Step S101: Obtain the I / O instructions to be processed.

[0024] In practical applications, the RAID controller can first obtain the I / O command to be processed. This I / O command can be a command sent by the host, or a command generated after the RAID controller initiates an I / O operation. The I / O command can be the reading and writing of text data, image data, performance data, etc. in the RAID, without specific limitations.

[0025] Step S102: Parse the I / O instructions to obtain task information.

[0026] Step S103: Based on the task information, construct an I / O task that includes a hardware acceleration unit.

[0027] In practical applications, RAID controllers follow an efficient, refined, and optimized general process when handling I / O operations. The key steps in this process are receiving and parsing I / O commands, and constructing corresponding I / O tasks based on the command content to guide subsequent data processing operations. Based on this, after receiving the I / O command to be processed, the RAID controller needs to parse the command to obtain task information. Task information may include I / O type (e.g., read operation, write operation), start logical block address (SLBA), number of logical blocks (nlb), and RAID type of the I / O operation. The I / O type determines the basic nature of the operation—whether it's reading or writing data. The start logical block address and block size together determine the location range of the data in the storage space, clarifying the specific data block to be operated on. The RAID type affects the data distribution and redundancy strategy in the disk array, playing a decisive role in subsequent data location and processing logic. Then, based on the task information, an I / O task including hardware acceleration units is constructed.

[0028] It's important to note that the process of constructing I / O tasks is essentially decomposing complex I / O operations into a series of ordered subtasks that can be executed by different HAUs. This pre-construction of I / O tasks allows the RAID controller to plan resource allocation and execution processes in advance, significantly improving I / O efficiency. During execution, the RAID controller can quickly and systematically schedule each HAU, ensuring fast and accurate data processing and reducing latency and uncertainty caused by dynamic resource allocation and execution order determination. This provides the storage system with high-performance, highly reliable data processing capabilities, meeting the data storage needs of different application scenarios. For ease of understanding, let's take the I / O task corresponding to RAID 5 write I / O as an example, such as... Figure 2 As shown, Figure 2Each box in the diagram represents a HUA. Initially, the Dynamic Memory Management HAU is responsible for allocating memory space for host data migration and RAID5 redundancy calculation. Subsequently, the Host DMA HAU is responsible for moving host write data to the RAID controller memory. The Algorithm HAU is responsible for calculating redundancy data according to the RAID5 algorithm. The I / O Coprocessor HAU is responsible for writing host data and redundancy data to the disk. At the end of the task, the Dynamic Memory Management HAU is used to release the previously allocated data space. Finally, the Host Interface Management HAU is responsible for sending a write operation completion signal to the host.

[0029] Step S104: Detect whether the I / O task contains a faulty hardware acceleration unit.

[0030] Step S105: In response to an I / O task containing a faulty hardware acceleration unit, the faulty hardware acceleration unit is replaced with a software acceleration unit.

[0031] Step S106: Call the replaced software acceleration unit to process the task.

[0032] In practical applications, considering the possibility of hardware acceleration unit failure, which could hinder task processing, the RAID controller needs to detect whether the I / O task contains a failed hardware acceleration unit. If so, the failed hardware acceleration unit is replaced with a software acceleration unit, and the replaced software acceleration unit is used for task processing. Figure 3 As shown, during this process, those hardware acceleration units that are not faulty and are functioning normally can continue to be used for task processing. In this way, under normal circumstances, the HAU undertakes the main data processing tasks, and the system's hardware resources are utilized efficiently, achieving optimal performance. When the HAU fails and the SAU takes over the tasks, the RAID controller can dynamically adjust the resource allocation of the SAU to ensure that the SAU can complete data processing tasks with high efficiency, achieving optimized resource utilization and a balance in system performance.

[0033] In an exemplary embodiment, if it is known in advance whether a hardware acceleration unit has failed, static disaster recovery can be performed without calling the hardware acceleration unit to process tasks. During this process, the HUA status table can be used to record the status of the hardware acceleration unit and to detect it. Specifically, when the RAID controller detects whether an I / O task contains a failed hardware acceleration unit, it can obtain the HAU status table. The HAU status table records whether the hardware acceleration unit is in normal or failed state and can be in array form, as shown in Table 1, consisting of HUA number and status, where 0 indicates normal and 1 indicates failed. All hardware acceleration units in the I / O task are read. For each hardware acceleration unit in the I / O task, its status is determined in the HAU status table. If the status is failed, it is determined that the I / O task contains a failed hardware acceleration unit. The entire process can be as follows: Figure 4 and Figure 5 As shown.

[0034] Table 1 HUA Status Table

[0035] In specific application scenarios, the RAID controller can also be configured to perform a power-on self-test (POST) on the HUA (Hardware Acceleration Unit). This allows for the timely detection of potential hardware problems before the RAID controller is put into use, preventing faulty HUAs from affecting subsequent I / O operations and ensuring the RAID controller has a stable operating foundation from the outset. Specifically, during the RAID controller's power-on initialization phase, the controller can acquire a functional test set. This test set is then used to perform functional tests on each hardware acceleration unit, obtaining the test results. These tests include register read / write tests, data path tests, computational function tests, and memory management tests. Based on the test results, the controller checks whether the hardware acceleration unit has passed all functional tests. If the hardware acceleration unit passes all functional tests, its status is marked as normal in the HUA status table; if it fails all functional tests, its status is marked as failed in the HUA status table. The entire process is as follows: Figure 6 As shown.

[0036] It should be noted that during the functional testing of the hardware acceleration unit, the register read / write test is used to verify whether the read / write function of the internal registers of the HAU is normal. In this test, the RAID controller writes known values ​​to the registers, then reads them back and verifies the consistency of the data, ensuring that the storage and transmission functions of the registers are normal. The data path test is used to check whether the data input and output paths of the HAU are unobstructed. In this test, the RAID controller sends test data and verifies the output results to confirm that the data can be correctly transmitted and processed within the HAU. The calculation function test is for HAUs with data processing capabilities (such as units responsible for compression / decompression or data encryption / decryption). In this test, the RAID controller provides specific input data and verifies whether its calculation results meet expectations. For example, for a compression HAU, test data is input and its compressed output is checked to see if it is consistent with the expected algorithm result; for an encryption / decryption HAU, it verifies whether its encryption and decryption operations can correctly recover the original data. Memory management testing is used to test the memory allocation and release functions of HAUs (such as dynamic memory management units) that involve memory operations. In this test, the RAID controller simulates various memory allocation and release scenarios to ensure that the HAU can correctly manage memory resources and avoid problems such as memory leaks or illegal access. For example, when testing a dynamic memory management unit HAU, a test set consisting of register read / write tests and memory management tests is selected.

[0037] In an exemplary embodiment, if it is not known in advance whether a hardware acceleration unit has failed, dynamic disaster recovery is required when calling the hardware acceleration unit to process tasks. That is, during the process of detecting whether an I / O task includes a failed hardware acceleration unit, the currently called hardware acceleration unit and the subtask to be processed can be determined according to the I / O task; the subtask is transferred to the currently called hardware acceleration unit for processing; it is detected whether an interrupt notification signal is received, the interrupt notification signal including the interrupt signal generated when the currently called hardware acceleration unit detects a fault; in response to receiving an interrupt notification signal, the currently pending event data is read from the hardware event queue (HWEQ) according to the head pointer of the hardware event queue. This event data belongs to hardware events and may contain a HAU number and an error code. The HAU number can occupy the event... The high 16 bits of the event are used to clearly identify which specific HAU has encountered a problem. The error code can occupy the low 16 bits of the event, which is used to describe in detail the cause of the failure. In order to ensure the sequentiality and correctness of event processing, the RAID controller needs to update the HWEQ header pointer after the read operation is completed. The event data is parsed to obtain the error code. It is then checked whether the error code indicates that the currently called hardware acceleration unit has failed. For example, the RAID controller maintains an error code definition table or a set of error code judgment rules to distinguish different error types and corresponding handling strategies. The error code definition table or error code judgment rules are used to detect whether the error code indicates that the currently called hardware acceleration unit has failed. In response to the error code indicating that the currently called hardware acceleration unit has failed, the failure of the currently called hardware acceleration unit is confirmed.

[0038] It should be noted that dynamic disaster recovery requires the cooperation of hardware acceleration units. That is, when the HAU encounters a failure during the execution of a subtask, it needs to quickly trigger the hardware event sending mechanism. Under this mechanism, the HAU records the hardware event to the HWEQ and simultaneously updates the tail pointer of the hardware event queue. The tail pointer update operation is to accurately record the storage position of the hardware event in the queue, so that subsequent hardware event processing can correctly identify and process newly added events. At the same time, this mechanism notifies the RAID controller of the abnormal status of the HAU in a timely manner through interrupt notification, so that the RAID controller can perform dynamic disaster recovery. Moreover, the interrupt method can utilize specific hardware signal lines to immediately send a request to the interrupt handling module of the RAID controller the moment the HAU detects a fault, thereby ensuring that the RAID controller can pay attention to the abnormal status of the HAU as soon as possible.

[0039] In specific application scenarios, to avoid continuing to use the failed hardware acceleration unit to process tasks, the RAID controller, after determining that the currently invoked hardware acceleration unit has failed, can also mark the status of the currently invoked hardware acceleration unit as failed in the HUA status table. The entire process is as follows: Figure 7 As shown. It should be noted that the real-time updates of the HAU status table can provide accurate fault information for subsequent system recovery and hardware repair, helping maintenance personnel to quickly locate and repair faults in hardware acceleration units, and further enhancing the reliability and maintainability of the RAID controller.

[0040] In an exemplary embodiment, the process of replacing a failed hardware acceleration unit with a software acceleration unit must strictly adhere to the principles of data consistency and integrity to ensure that data is not lost, damaged, or erroneous during the transfer from the HAU to the SAU. Based on this, the RAID controller can determine the location information of the failed hardware acceleration unit in the I / O task; remove the failed hardware acceleration unit in the I / O task; and insert the software acceleration unit into the corresponding position in the I / O task according to the location information.

[0041] In specific application scenarios, during the process of the RAID controller inserting the software acceleration unit into the corresponding position of the I / O task according to the location information, the preceding and following hardware acceleration units of the failed hardware acceleration unit can be determined in the I / O task according to the location information; the next acceleration unit of the preceding hardware acceleration unit is set to the software acceleration unit; and the next acceleration unit of the software acceleration unit is set to the following hardware acceleration unit.

[0042] In an exemplary embodiment, the hardware acceleration unit utilizes dedicated circuitry to handle RAID parity calculations, consuming almost no CPU resources. However, once switched to the software acceleration unit, these calculations are entirely dependent on the CPU, leading to a performance degradation in the RAID controller. To prevent excessive performance degradation in the RAID controller, during task processing by the replaced software acceleration unit, the availability of idle heterogeneous computing resources can be detected. If such resources are available, read / write requests from subtasks are sent to the software acceleration unit via SIMD (Single Instruction Multiple Data), while parity reconstruction requests from subtasks are sent to the idle heterogeneous computing resources for processing. Furthermore, the software acceleration unit is controlled to merge fine-grained data read / write operations into larger blocks for processing. This allows for improved subtask processing speed using SIMD, reducing the CPU load on the RAID controller; reduced data read / write operations by merging data read / write operations, lowering CPU pressure; and the use of idle heterogeneous computing resources to perform complex parity reconstruction tasks, reducing the pressure on the software computing unit and minimizing the performance drop of the RAID controller after enabling the software acceleration unit, thus preventing cascading failures in upper-layer applications caused by sudden performance degradation.

[0043] In specific application scenarios, before receiving I / O commands to be processed, the RAID controller can bind a corresponding software acceleration unit to each hardware acceleration unit. Metadata changes and I / O command streams from the hardware acceleration unit are synchronized to the bound software acceleration unit, allowing the software acceleration unit to parse commands, construct task objects, and preload relevant data into a cache in the background without committing results. This way, when a failed hardware acceleration unit is subsequently replaced with a software acceleration unit, the software acceleration unit, having already warmed up (possessing context, parsed tasks, and preloaded data), can directly transition from a "standby" state to a "commit" state, process tasks, and return results. This reduces hardware acceleration unit failover time and improves system robustness.

[0044] This application provides a hardware acceleration unit disaster recovery method applied to a RAID controller. The method involves: acquiring I / O instructions to be processed; parsing the I / O instructions to obtain task information; constructing an I / O task containing hardware acceleration units based on the task information; detecting whether the I / O task contains a failed hardware acceleration unit; replacing the failed hardware acceleration unit with a software acceleration unit in response to the failure; and calling the replaced software acceleration unit to process the task. In this application, after converting I / O instructions into I / O tasks, the RAID controller needs to detect whether the I / O task contains a failed hardware acceleration unit. If so, the failed hardware acceleration unit needs to be replaced with a normal software acceleration unit for task processing. This ensures that the overall function of the RAID controller is not affected by the failed hardware acceleration unit, and I / O operations can be performed smoothly and continuously. This reduces the impact of hardware acceleration unit failure on I / O services, enhances the RAID controller's ability to cope with sudden hardware acceleration unit failures, and improves the RAID controller's I / O performance and data reliability. Furthermore, the disaster recovery design of this application effectively reduces the risk of RAID controller unavailability and controller replacement due to hardware acceleration unit failure, reduces the user's total cost of ownership, and improves the cost-effectiveness and market competitiveness of the RAID controller.

[0045] Please see Figure 8 , Figure 8 This is a schematic diagram of a hardware acceleration unit disaster recovery system provided in an embodiment of this application.

[0046] This application provides a hardware acceleration unit disaster recovery system applied to a RAID controller, which may include: Instruction acquisition module 101 is used to acquire I / O instructions to be processed; The instruction parsing module 102 is used to parse I / O instructions to obtain task information; The task construction module 103 is used to construct an I / O task containing a hardware acceleration unit based on task information; Failure detection module 104 is used to detect whether the I / O task contains a failed hardware acceleration unit; Unit replacement module 105 is used to replace the failed hardware acceleration unit with a software acceleration unit in response to an I / O task containing a failed hardware acceleration unit. Unit calling module 106 is used to call the replaced software acceleration unit for task processing.

[0047] This application provides a hardware acceleration unit disaster recovery system applied to a RAID controller, wherein the failure detection module may include: The first acquisition unit is used to acquire the HAU status table, which records whether the hardware acceleration unit is in normal or failed. The first read unit is used to read all hardware acceleration units in the I / O task; The first detection unit is used to determine the status of each hardware acceleration unit in the HAU status table for each hardware acceleration unit in the I / O task. If the status is "failed", it is determined that the I / O task contains a failed hardware acceleration unit.

[0048] This application provides a hardware acceleration unit disaster recovery system applied to a RAID controller, which may further include: The second acquisition unit is used to acquire the functional test set during the power-on initialization phase of the RAID controller. The first test unit is used to perform functional tests on each hardware acceleration unit using the application functional test set and obtain functional test results. The functional tests include register read / write tests, data path tests, computational function tests, and memory management tests. The second detection unit is used to detect whether the hardware acceleration unit has passed all functional tests based on the functional test results; in response to the hardware acceleration unit passing all functional tests, the status of the hardware acceleration unit is marked as normal in the HUA status table; in response to the hardware acceleration unit failing all functional tests, the status of the hardware acceleration unit is marked as failed in the HUA status table.

[0049] This application provides a hardware acceleration unit disaster recovery system applied to a RAID controller, wherein the failure detection module may include: The first determining unit is used to determine the currently invoked hardware acceleration unit and the subtask to be processed according to the I / O task. The first transmission unit is used to transmit subtasks to the currently invoked hardware acceleration unit for processing; The third detection unit is used to detect whether an interrupt notification signal has been received. The interrupt notification signal includes the interrupt signal generated when the currently invoked hardware acceleration unit detects a fault. In response to receiving an interrupt notification signal, the unit reads the currently pending event data from the hardware event queue according to the head pointer of the hardware event queue. The first parsing unit is used to parse the event data and obtain the error code; The fourth detection unit is used to detect whether the error code indicates that the currently called hardware acceleration unit has failed; in response to the error code indicating that the currently called hardware acceleration unit has failed, the unit is determined to have failed.

[0050] This application provides a hardware acceleration unit disaster recovery system applied to a RAID controller, which may further include: The first marking unit is used to mark the status of the currently called hardware acceleration unit as failed in the HUA status table after the fourth detection unit determines that the currently called hardware acceleration unit has failed.

[0051] This application provides a hardware acceleration unit disaster recovery system applied to a RAID controller, wherein the unit replacement module may include: The second determining unit is used to determine the location information of the failed hardware acceleration unit in the I / O task; The first removal unit is used to remove faulty hardware acceleration units during I / O tasks; The first insertion unit is used to insert the software acceleration unit into the corresponding position of the I / O task according to the position information.

[0052] This application provides a hardware acceleration unit disaster recovery system applied to a RAID controller. The first insertion unit can be used to: in I / O tasks, determine the preceding and following hardware acceleration units of the failed hardware acceleration unit according to location information; point the next acceleration unit of the preceding hardware acceleration unit to the software acceleration unit; and point the next acceleration unit of the software acceleration unit to the following hardware acceleration unit.

[0053] This application also provides an electronic device and a computer-readable storage medium, both of which have the corresponding effects of the hardware acceleration unit disaster recovery method provided in the embodiments of this application. Please refer to... Figure 9 , Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0054] An electronic device provided in this application includes a memory 201 and a processor 202. The memory 201 stores a computer program, and when the processor 202 executes the computer program, it implements the steps of the hardware acceleration unit disaster recovery method described in any of the above embodiments.

[0055] Please see Figure 10 Another electronic device provided in this application embodiment may further include: an input port 203 connected to the processor 202 for transmitting commands input from the outside to the processor 202; a display unit 204 connected to the processor 202 for displaying the processing results of the processor 202 to the outside; and a communication module 205 connected to the processor 202 for enabling communication between the electronic device and the outside. The display unit 204 may be a display panel, a laser scanner, or the like; the communication method used by the communication module 205 includes, but is not limited to, Mobile High-Definition Link (MHL), Universal Serial Bus (USB), High-Definition Multimedia Interface (HDMI), wireless connectivity: Wireless Fidelity (WiFi), Bluetooth communication technology, Bluetooth Low Energy communication technology, and communication technology based on IEEE 802.11s.

[0056] This application provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the steps of the hardware acceleration unit disaster recovery method described in any of the above embodiments.

[0057] The computer-readable storage media involved in this application include random access memory (RAM), memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disks, removable disks, CD-ROMs (compact disc read-only memory), or any other form of storage media known in the art.

[0058] This application provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the steps of the hardware acceleration unit disaster recovery method described in any of the above embodiments.

[0059] For descriptions of relevant parts of the hardware acceleration unit disaster recovery system, electronic device, and computer-readable storage medium provided in this application's embodiments, please refer to the detailed description of the corresponding parts in the hardware acceleration unit disaster recovery method provided in this application's embodiments, which will not be repeated here. Furthermore, parts of the technical solutions provided in this application that are consistent with the implementation principles of corresponding technical solutions in the prior art are not described in detail to avoid excessive elaboration.

[0060] It should also be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0061] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A disaster recovery method for a hardware acceleration unit, characterized in that, Applied to RAID controllers, including: Obtain the I / O instructions to be processed; Parse I / O instructions to obtain task information; Based on the task information, an I / O task including a hardware acceleration unit is constructed; Detect whether the I / O task contains a faulty hardware acceleration unit; If an I / O task contains a faulty hardware acceleration unit, the faulty hardware acceleration unit is replaced with a software acceleration unit. The replaced software acceleration unit is invoked for task processing.

2. The method according to claim 1, characterized in that, The method for detecting whether an I / O task contains a faulty hardware acceleration unit includes: Obtain the HAU status table, which is used to record whether the hardware acceleration unit is normal or faulty; Read all hardware acceleration units in the I / O task; For each hardware acceleration unit in the I / O task, the status of the hardware acceleration unit is determined in the HAU status table. If the status is "failed", it is determined that the I / O task contains a failed hardware acceleration unit.

3. The method according to claim 2, characterized in that, Also includes: During the power-on initialization phase of the RAID controller, acquire the functional test set; The functional test set is applied to perform functional tests on each hardware acceleration unit to obtain functional test results. The functional tests include register read / write tests, data path tests, computational function tests, and memory management tests. Based on the functional test results, check whether the hardware acceleration unit passes all functional tests; In response to the hardware acceleration unit passing all functional tests, the status of the hardware acceleration unit is marked as normal in the HUA status table; If the hardware acceleration unit fails all functional tests, the hardware acceleration unit is marked as failed in the HUA status table.

4. The method according to claim 1, characterized in that, The method for detecting whether an I / O task contains a faulty hardware acceleration unit includes: Based on the I / O task, determine the currently invoked hardware acceleration unit and the subtasks that need to be processed; The subtask is passed to the currently invoked hardware acceleration unit for processing; Detect whether an interrupt notification signal has been received, the interrupt notification signal including an interrupt signal generated when the currently invoked hardware acceleration unit detects a fault; In response to receiving an interrupt notification signal, the currently pending event data is read from the hardware event queue according to the head pointer of the hardware event queue; The event data is parsed to obtain the error code; Detect whether the error code indicates that the currently invoked hardware acceleration unit has failed; If the error code indicates that the currently invoked hardware acceleration unit has failed, then the currently invoked hardware acceleration unit is determined to have failed.

5. The method according to claim 4, characterized in that, After determining that the currently invoked hardware acceleration unit has failed, the process further includes: In the HUA status table, the currently invoked hardware acceleration unit is marked as inactive.

6. The method according to claim 1, characterized in that, The replacement of the failed hardware acceleration unit with a software acceleration unit includes: Determine the location of the failed hardware acceleration unit in the I / O task; In I / O tasks, remove malfunctioning hardware acceleration units; According to the location information, the software acceleration unit is inserted into the corresponding position of the I / O task.

7. The method according to claim 6, characterized in that, According to the location information, the software acceleration unit is inserted into the corresponding position of the I / O task, including: In the I / O task, the preceding and following hardware acceleration units of the failed hardware acceleration unit are determined according to the location information. The next acceleration unit of the preceding hardware acceleration unit is pointed to the software acceleration unit; The next acceleration unit of the software acceleration unit is pointed to the next hardware acceleration unit.

8. A hardware acceleration unit disaster recovery system, characterized in that, Applied to RAID controllers, including: The instruction fetching module is used to acquire I / O instructions to be processed. The instruction parsing module is used to parse I / O instructions to obtain task information; The task construction module is used to construct an I / O task containing a hardware acceleration unit based on the task information. The failure detection module is used to detect whether the I / O task contains a failed hardware acceleration unit; The unit replacement module is used to replace the faulty hardware acceleration unit with a software acceleration unit in response to an I / O task containing a faulty hardware acceleration unit. The unit invocation module is used to invoke the replaced software acceleration unit for task processing.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the method as claimed in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method as described in any one of claims 1 to 7.

Images