A method, apparatus, device, and medium for multi-engine task retry in a disk array card.

Abstract

This application discloses a multi-engine task retry method, apparatus, device, and medium for disk array cards, relating to the field of computer technology. It is applied to a task retry system built on microservices, which includes a first microservice component, a second microservice component, and a third microservice component. The method includes: monitoring the task execution status of hardware engines through the first microservice component; when any hardware engine fails to execute a task, obtaining a target event defined by that hardware engine; obtaining task exception information based on the target event; determining retry tasks based on the task exception information through the second microservice component; determining the corresponding target queue based on the task exception information; and writing the retry tasks into the target queue; and re-executing the retry tasks in the target queue through the third microservice component based on a task retry strategy determined according to task urgency, queue priority, and queue usage. This application reduces system load and task retry cycle.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method, apparatus, device, and medium for retrying multi-engine tasks on a disk array card. Background Technology

[0002] With the rapid development of information technologies such as artificial intelligence, the Internet of Things, and cloud computing, the amount of data running and stored on large servers is increasing; at the same time, the requirements for data storage speed, security, and reliability are also becoming higher. This increasing demand for storage has driven the rapid development and continuous improvement of RAID (Redundant Array of Independent Disks) technology.

[0003] The hardware RAID card received a host I / O ( , Afterwards, based on business needs, multiple engines on the RAID card are used in a coordinated "permutation and combination" to complete a specific I / O task. The result of this "permutation and combination" is conventionally called an "I / O data chain." In complex business scenarios, dozens of engines often need to work closely together to complete the disk write task. Anomalies may occur in each engine's processing stage, causing a certain I / O operation sent from the host to the RAID card to fail to write correctly under extreme pressure. Therefore, it is necessary to retry this I / O operation sent from the host to the RAID card. The traditional solution is to rebuild the "I / O data chain" and retry the entire chain. The basic model is as follows: Figure 1 As shown. However, this brings many negative impacts. First, rebuilding the "IO data chain" is a very complex process. It not only requires online analysis of IO anomalies, but also the reconstruction of the "IO data chain". After a series of operations, the system load is greatly increased. Second, the timeout threshold of host IO is not infinite. Under complex business requirements, such a high-load "IO data chain" retry operation often involves dozens of engines participating in the retries, resulting in a long retry cycle and easy host IO timeouts. Third, traditional methods rely heavily on hardware customization and cannot flexibly adjust strategies, resulting in excessively high hardware usage costs. Summary of the Invention

[0004] In view of this, the purpose of this invention is to provide a method, apparatus, device, and medium for multi-engine task retry in a disk array card, which can reduce system load and task retry cycle. The specific solution is as follows:

[0005] In a first aspect, this application discloses a multi-engine task retry method for a disk array card, applied to a task retry system built on a microservice architecture, wherein the task retry system includes a first microservice component, a second microservice component, and a third microservice component, and the method includes:

[0006] The first microservice component monitors the task execution status of each hardware engine in the disk array card, and when any hardware engine fails to execute a task, it obtains the target event defined and fed back by the hardware engine, so as to obtain the corresponding task exception information based on the target event.

[0007] The retry task is determined by the second microservice component based on the task exception information. Then, the target queue corresponding to any hardware engine is determined from a preset number of queues according to the task exception information, and the retry task is written into the target queue.

[0008] The third microservice component determines the task retry strategy based on task urgency, queue priority, and queue usage, and then re-executes the retry tasks in the target queue according to the task retry strategy.

[0009] Optionally, obtaining the target event defined and fed back by any of the hardware engines includes:

[0010] Obtain the target event defined and fed back by any of the hardware engines based on the target format; wherein, the target format is obtained based on the hardware engine number, the reason for task execution failure, the task number, the task storage address, the task data size, the number of engine retries, and the target cyclic redundancy check value, and the target cyclic redundancy check value is a check value obtained by performing cyclic redundancy check on the sum of the hardware engine number, the reason for task execution failure, the task number, the task storage address, the task data size, and the number of engine retries.

[0011] Optionally, before writing the retry task to the target queue, the method further includes:

[0012] The queue priority of each target queue corresponding to each hardware engine is determined based on the engine scheduling order, engine allocation weight, and engine retry count of each hardware engine; wherein, the engine scheduling order is the order in which each hardware engine executes the corresponding task, and the engine retry count is the number of times each hardware engine has re-executed the corresponding task.

[0013] Optionally, determining the queue priority of each target queue corresponding to each hardware engine based on the engine scheduling order, engine allocation weight, and engine retries of each hardware engine includes:

[0014] Determine the first proportion of the engine scheduling order of each hardware engine, the second proportion of the engine allocation weight, and the third proportion of the number of engine retries;

[0015] A first calculation result is determined based on the engine scheduling order and the first proportion; a second calculation result is determined based on the engine allocation weight and the second proportion; and a third calculation result is determined based on the number of engine retries and the third proportion.

[0016] The queue priority of each target queue corresponding to each hardware engine is determined by the first calculation result, the second calculation result, and the third calculation result.

[0017] Optionally, if each target queue includes a first circular queue and a second circular queue, then writing the retry task into the target queue includes:

[0018] Determine whether there is any free space in the first circular queue of the target queue;

[0019] If there is free space in the first circular queue in the target queue, then the retry task is written into the first circular queue;

[0020] If there is no free space in the first circular queue of the target queue, then the retry task is written to the second circular queue.

[0021] Optionally, the step of re-executing the retry tasks in the target queue according to the task retry policy includes:

[0022] From the various target queues, determine the current target queue with the highest urgency;

[0023] Determine whether the retry task exists in the first circular queue of the current target queue;

[0024] If the retry task exists in the first circular queue of the current target queue, then the retry task is re-executed.

[0025] If the retry task is not present in the first circular queue of the current target queue, a new current target queue is determined from the remaining target queues according to the queue priority, and it is determined whether the retry task is present in the first circular queue of the new current target queue.

[0026] If the retry task exists in the first circular queue of the new current target queue, then the retry task is re-executed.

[0027] If the first circular queue in the new current target queue does not contain the retry task, then the process jumps to the step of determining the current target queue with the highest urgency from each of the target queues, so as to determine whether the second circular queue in each of the target queues contains the retry task, and to re-execute the retry task in the second circular queue.

[0028] Optionally, after re-executing the retry tasks in the target queue according to the task retry policy, the method further includes:

[0029] If the re-execution of the process fails, it is determined whether the number of engine retries for any of the hardware engines has reached a preset threshold.

[0030] If the number of retry attempts for any of the hardware engines does not reach the preset threshold, the process jumps to the step of re-executing the retry tasks in the target queue.

[0031] If the number of engine retries for any of the hardware engines reaches the preset threshold, then the hardware engine will be processed based on the preset exception handling mechanism.

[0032] Secondly, this application discloses a multi-engine task retry device for a disk array card, applied to a task retry system built on a microservice architecture. The task retry system includes a first microservice component, a second microservice component, and a third microservice component, comprising:

[0033] The monitoring module is used to monitor the task execution status of each hardware engine in the disk array card through the first microservice component, and when any hardware engine fails to execute a task, it obtains the target event defined and fed back by the hardware engine, so as to obtain the corresponding task exception information based on the target event.

[0034] The feedback module is used to determine the retry task through the second microservice component and based on the task exception information, then determine the target queue corresponding to any hardware engine from a preset number of queues according to the task exception information, and write the retry task into the target queue.

[0035] The retry module is used to determine the task retry strategy through the third microservice component and based on the task urgency, queue priority and queue usage, and then re-execute the retry task in the target queue according to the task retry strategy.

[0036] Thirdly, this application discloses an electronic device, comprising:

[0037] Memory, used to store computer programs;

[0038] A processor is used to execute the computer program to implement the aforementioned disclosed multi-engine task retry method for disk array cards.

[0039] Fourthly, this application discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned disk array card multi-engine task retry method.

[0040] As can be seen, this application proposes a multi-engine task retry method for disk array cards, applied to a task retry system built on a microservice architecture. The task retry system includes a first microservice component, a second microservice component, and a third microservice component. The method includes: monitoring the task execution status of each hardware engine in the disk array card through the first microservice component, and when any hardware engine fails to execute a task, obtaining a target event defined and fed back by the hardware engine, so as to obtain corresponding task exception information based on the target event; determining a retry task through the second microservice component based on the task exception information, and then determining a target queue corresponding to any hardware engine from a preset number of queues based on the task exception information, and writing the retry task into the target queue; determining a task retry strategy through the third microservice component based on task urgency, queue priority, and queue usage, and then re-executing the retry task in the target queue according to the task retry strategy. In summary, this application monitors the task execution status of each hardware engine through a first microservice component. The failed hardware engine defines the target event and feeds it back to the first microservice component, allowing it to understand the corresponding task exception information. A second microservice component then determines and stores the retry tasks. Finally, a third microservice component performs retry operations on the retry tasks determined based on the task exception information. This avoids retrying the entire target task. In other words, compared to traditional technologies that retry the entire IO data chain, this application, based on a microservice architecture, retryes tasks in the hardware engine where exceptions occur, reducing system load and the entire retry cycle, shortening development time, and thus reducing hardware usage costs. Attached Figure Description

[0041] To more clearly illustrate the technical solutions in the embodiments of the present invention 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 the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0042] Figure 1 This is a schematic diagram of a traditional task retry model;

[0043] Figure 2 This application discloses a flowchart of a multi-engine task retry method for a disk array card.

[0044] Figure 3 This is a schematic diagram of a microservice layering of a hardware RAID card disclosed in this application;

[0045] Figure 4 This is a schematic diagram of a hardware RAID card multi-task anomaly monitoring and retry model disclosed in this application;

[0046] Figure 5 This application discloses a flowchart of a specific multi-engine task retry method for a disk array card;

[0047] Figure 6 This is a schematic diagram of a DRQ storage rule disclosed in this application;

[0048] Figure 7 This is a schematic diagram of a task retry rule disclosed in this application;

[0049] Figure 8 This is a schematic diagram of the structure of a multi-engine task retry device for a disk array card disclosed in this application;

[0050] Figure 9 This is a structural diagram of an electronic device disclosed in this application. Detailed Implementation

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

[0052] In complex business scenarios, dozens of engines often need to work closely together to complete the disk write task. Each engine's processing stage can experience anomalies, causing a particular I / O operation sent from the host to the RAID card to fail to write correctly under extreme pressure. Therefore, it's necessary to retry this I / O operation. The typical solution is to rebuild the "I / O data chain" and retry the entire chain. However, this approach has several negative consequences: First, rebuilding the "I / O data chain" is a complex process, requiring not only online analysis of I / O anomalies but also rebuilding the chain, significantly increasing system load. Second, the entire retry cycle is lengthy, easily causing host I / O timeouts. Third, traditional methods heavily rely on hardware customization and cannot flexibly adjust strategies, resulting in excessively high hardware costs.

[0053] Therefore, this application proposes a multi-engine task retry scheme for disk array cards, which can reduce system load and task retry cycle, and reduce hardware usage costs.

[0054] This application discloses a multi-engine task retry method for disk array cards, applied to a task retry system built on a microservice architecture. The task retry system includes a first microservice component, a second microservice component, and a third microservice component. See [link to relevant documentation]. Figure 2 As shown, the method includes:

[0055] Step S11: Monitor the task execution status of each hardware engine in the disk array card through the first microservice component, and when any hardware engine fails to execute a task, obtain the target event defined and fed back by the hardware engine, so as to obtain the corresponding task exception information based on the target event.

[0056] This application is based on the concept of microservice architecture and adopts the design philosophy of HWE (hardware event, events generated by the hardware engine) anomaly monitoring, DRQ (Dual Ring Queue, two ring queues) dynamic storage, and WRR (WRR With Urgent BasedOn DRQ, a weighted round-robin scheduling priority algorithm based on the DRQ storage mechanism) fast retry microservice technology architecture. It constructs three services: anomaly perception, conversion storage, and retry decision. Furthermore, through the above three services, abnormal tasks in the hardware engine with anomaly feedback are retried, thereby avoiding retries of the entire IO data chain.

[0057] Figure 3 This is a schematic diagram of a microservice layering of a hardware RAID card disclosed in this application. Figure 4 This application discloses a schematic diagram of a hardware RAID card multi-task anomaly monitoring and seamless retry model. The entire retry model is divided into three levels from top to bottom: the host, the hardware RAID acceleration card functional group, and the hardware physical disk entity. Specifically, the host provides management services for host-side I / O data, such as writing data to or reading specified data from disks connected to the hardware RAID card. The RAID acceleration card functional group includes engines and modules such as event monitoring, dynamic storage, seamless retry, hardware engine group, and anomaly management engine. The hardware engine group includes various hardware engines, such as a memory allocation engine, RAID acceleration engine, stripe mapping engine, I / O processing engine, data encryption engine, and anomaly management engine. The hardware physical disk entity is used to access the I / O data issued by the host.

[0058] Figure 5This application discloses a flowchart of a specific multi-engine task retry method for a disk array card. First, the host sends IO data. The task dispatcher sends a specific IO task to the hardware engine group based on the IO data. The first microservice component monitors the task execution status of each hardware engine in the hardware engine group. If the hardware engine task is executed successfully, the task dispatcher sends a notification to the done entry point (i.e., ...) of the task dispatcher. Figure 4 The write entry in the code represents the feedback interface for completing the task. If any hardware engine fails to execute the task, the failed hardware engine fills in the target event according to the target format so that the corresponding task exception information and retry task can be obtained according to the target event. The corresponding retry task is stored in the target queue by the second microservice component, and then the corresponding retry task is retried by the third microservice component based on the task retry strategy.

[0059] The hardware engine mainly includes a task acceptance unit, a result report unit, a task processing unit, and hardware channel resources, enabling a single disk drive to independently complete a specific task. Specifically, the task acceptance unit receives tasks to be executed; the result report unit selects whether to report the target event, and if the task execution fails, it fills in the target event according to the target format and reports the completion status; the task processing unit processes the specified task.

[0060] The target format is based on the hardware event ID (Identity document, ID card number) and the hardware engine number ( Reasons for task execution failure ( ), Task Number ( ), Task storage address ( ), task data size ( The target cyclic redundancy check value is obtained by performing a cyclic redundancy check on the sum of the hardware event ID, the hardware engine number, the reason for the task execution failure, the task number, the task storage address, the task data size, and the number of engine retries.

[0061] In this embodiment, a target event defined and fed back by any of the hardware engines is obtained so that corresponding task exception information can be obtained based on the target event. It can be understood that the task exception information includes hardware engine number, task storage address, task data size and engine retries, etc.

[0062] Step S12: Determine the retry task through the second microservice component and based on the task exception information, then determine the target queue corresponding to any hardware engine from a preset number of queues according to the task exception information, and write the retry task into the target queue.

[0063] In this embodiment, before writing the retry task into the target queue, the queue priority of each target queue corresponding to each hardware engine needs to be determined based on the engine scheduling order, engine allocation weight, and engine retries of each hardware engine. The engine scheduling order is the order in which each hardware engine executes its corresponding task, and the engine retries are the number of times each hardware engine has re-executed its corresponding task. Specifically, a first percentage of the engine scheduling order, a second percentage of the engine allocation weight, and a third percentage of the engine retries are determined. A first calculation result is determined based on the engine scheduling order and the first percentage; a second calculation result is determined based on the engine allocation weight and the second percentage; and a third calculation result is determined based on the engine retries and the third percentage. The queue priority of each target queue corresponding to each hardware engine is determined using the first calculation result, the second calculation result, and the third calculation result.

[0064] For example, define The emergency queue has the highest priority and is specifically designed to handle the most urgent retry tasks. For example, the exception handling engine, which needs to handle system-level exceptions on the RAID card, must respond urgently to any resulting exceptions. arrive Priority decreases sequentially. It should be noted that the earlier an engine is scheduled, the higher its expected priority; the higher its assigned weight, the higher its expected priority; and the more retries an engine accumulates, the higher its expected priority. In this embodiment, each proportion is configured according to actual business needs and is not strictly enforced. Furthermore, regarding the hardware engine… , that is, assuming arrive Stored to respectively arrive Furthermore, the retry engine's scheduling priority is consistent with the DRQ storage priority.

[0065] In this embodiment, after determining the priority of each queue, the retry task is determined by the second microservice component based on the task exception information. Then, the target queue corresponding to any hardware engine is determined from a number of preset queues according to the task exception information, and the retry task is written into the target queue.

[0066] Step S13: Determine the task retry strategy through the third microservice component based on the task urgency, queue priority, and queue usage, and then re-execute the retry task in the target queue according to the task retry strategy.

[0067] In this embodiment, a DRQ Ping-Pong (which can simultaneously utilize two task buffers to achieve continuous task reception and uninterrupted processing) storage mechanism is adopted. When the Q0 queue is used to receive or process retry I / O, the Q1 queue is used to prepare the next set of data. During a retry cycle in the Q0 queue, any new abnormal I / O task is injected into Q1. In this way, even with multi-threaded scheduling, there is no need for locking or waiting. The DRQ storage rules are as follows: Figure 6 As shown, in this embodiment, Q0 is referred to as the first circular queue and Q1 as the second circular queue.

[0068] Based on the aforementioned circular queue, in this embodiment, when writing a retry task into the queue, it specifically determines whether there is free space in the first circular queue of the target queue; if there is free space in the first circular queue of the target queue, the retry task is written into the first circular queue; if there is no free space in the first circular queue of the target queue, the retry task is written into the second circular queue.

[0069] Based on the above task writing method, in this embodiment, when reprocessing a retry task, the current target queue with the highest urgency is determined from each of the target queues; it is determined whether the retry task exists in the first circular queue of the current target queue; if the retry task exists in the first circular queue of the current target queue, the retry task is re-executed; if the retry task does not exist in the first circular queue of the current target queue, a new current target queue is determined from the remaining target queues according to the queue priority, and it is determined whether the retry task exists in the first circular queue of the new current target queue; if the retry task exists in the first circular queue of the new current target queue, the retry task is re-executed; if the retry task does not exist in the first circular queue of the new current target queue, the process jumps to the step of determining the current target queue with the highest urgency from each of the target queues, so as to determine whether the retry task exists in the second circular queue of each target queue, and re-execute the retry task in the second circular queue.

[0070] See Figure 7 As shown, when retries are performed on retry tasks, the urgency, priority, and The mechanism determines the task retry strategy from a three-dimensional perspective. Specifically, it includes the following three steps: a) Scheduling the task with the highest urgency. Each DRQ contains two circular queues, Q0 and Q1. Scheduling begins with Q0. If queue Q0 has storage I / O tasks, the retry tasks in queue Q0 are completed; if queue Q0 is empty, the scheduling retry is skipped. b) The highest priority task is scheduled. The scheduling process begins with queue Q0. If queue Q0 has storage I / O tasks, the retry task for queue Q0 is completed; if the queue is empty, this round of scheduling and retrying is skipped. c) After one round of scheduling for queue Q0, another round of scheduling for queue Q1 is executed, and this process is repeated periodically to retry abnormal I / O tasks. In this embodiment, queues with smaller priority numbers have higher urgency and are retried earlier. Furthermore, this embodiment can add a fourth dimension to the above three dimensions: the determination time of the retry task. The retry order of each retry task is determined by the time obtained from different retry tasks, together with the above three dimensions, thus improving the accuracy of the task retry strategy.

[0071] Furthermore, after re-executing the retry tasks in the target queue according to the task retry strategy, the method further includes: if the re-execution process fails, determining whether the number of engine retries for any hardware engine has reached a preset threshold; if the number of engine retries for any hardware engine has not reached the preset threshold, proceeding to the step of re-executing the retry tasks in the target queue; if the number of engine retries for any hardware engine has reached the preset threshold, processing the hardware engine based on a preset exception handling mechanism. In other words, this embodiment sets a retry threshold. If the number of retries is less than the threshold and the retry fails, it can be retried again. If the number of retries is greater than the threshold and the retry fails, no further retries are performed; instead, processing is based on a preset exception handling mechanism.

[0072] In summary, this application proposes a microservice architecture, utilizing an event monitoring mechanism to perceive the execution status of hardware engine tasks. By converting hardware events into executable tasks for the engine and dynamically storing them according to DRQ rules, and then implementing a WRR mechanism for rapid retries, the application achieves real-time interaction with the hardware engine, rapid closed-loop operation, and efficient retries. This improves hardware stability, optimizes hardware system load, reduces hardware usage costs, shortens feature development cycles, and accelerates product launch.

[0073] As can be seen, this application proposes a multi-engine task retry method for disk array cards, applied to a task retry system built on a microservice architecture. The task retry system includes a first microservice component, a second microservice component, and a third microservice component. The method includes: monitoring the task execution status of each hardware engine in the disk array card through the first microservice component, and when any hardware engine fails to execute a task, obtaining a target event defined and fed back by the hardware engine, so as to obtain corresponding task exception information based on the target event; determining a retry task through the second microservice component based on the task exception information, and then determining a target queue corresponding to any hardware engine from a preset number of queues based on the task exception information, and writing the retry task into the target queue; determining a task retry strategy through the third microservice component based on task urgency, queue priority, and queue usage, and then re-executing the retry task in the target queue according to the task retry strategy. In summary, this application monitors the task execution status of each hardware engine through a first microservice component. The failed hardware engine defines the target event and feeds it back to the first microservice component, allowing it to understand the corresponding task exception information. A second microservice component then determines and stores the retry tasks. Finally, a third microservice component performs retry operations on the retry tasks determined based on the task exception information. This avoids retrying the entire target task. In other words, compared to traditional technologies that retry the entire IO data chain, this application, based on a microservice architecture, retryes tasks in the hardware engine where exceptions occur, reducing system load and the entire retry cycle, shortening development time, and thus reducing hardware usage costs.

[0074] Accordingly, this application also discloses a multi-engine task retry device for a disk array card, applied to a task retry system built on a microservice architecture. The task retry system includes a first microservice component, a second microservice component, and a third microservice component. See [link to relevant documentation]. Figure 8 As shown, the device includes:

[0075] Monitoring module 11 is used to monitor the task execution status of each hardware engine in the disk array card through the first microservice component, and when any hardware engine fails to execute a task, obtain the target event defined and fed back by any hardware engine, so as to obtain the corresponding task exception information based on the target event;

[0076] Feedback module 12 is used to determine a retry task through the second microservice component and based on the task exception information, then determine the target queue corresponding to any hardware engine from a preset number of queues according to the task exception information, and write the retry task into the target queue.

[0077] The retry module 13 is used to determine the task retry strategy through the third microservice component and based on the task urgency, queue priority and queue usage, and then re-execute the retry task in the target queue according to the task retry strategy.

[0078] For more detailed information on the working process of each of the above modules, please refer to the relevant content disclosed in the foregoing embodiments, which will not be repeated here.

[0079] As can be seen, this application proposes a multi-engine task retry method for disk array cards, applied to a task retry system built on a microservice architecture. The task retry system includes a first microservice component, a second microservice component, and a third microservice component. The method includes: monitoring the task execution status of each hardware engine in the disk array card through the first microservice component, and when any hardware engine fails to execute a task, obtaining a target event defined and fed back by the hardware engine, so as to obtain corresponding task exception information based on the target event; determining a retry task through the second microservice component based on the task exception information, and then determining a target queue corresponding to any hardware engine from a preset number of queues based on the task exception information, and writing the retry task into the target queue; determining a task retry strategy through the third microservice component based on task urgency, queue priority, and queue usage, and then re-executing the retry task in the target queue according to the task retry strategy. In summary, this application monitors the task execution status of each hardware engine through a first microservice component. The failed hardware engine defines the target event and feeds it back to the first microservice component, allowing it to understand the corresponding task exception information. A second microservice component then determines and stores the retry tasks. Finally, a third microservice component performs retry operations on the retry tasks determined based on the task exception information. This avoids retrying the entire target task. In other words, compared to traditional technologies that retry the entire IO data chain, this application, based on a microservice architecture, retryes tasks in the hardware engine where exceptions occur, reducing system load and the entire retry cycle, shortening development time, and thus reducing hardware usage costs.

[0080] Furthermore, embodiments of this application also provide an electronic device. Figure 9 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application.

[0081] Figure 9This is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of this application. Specifically, the electronic device 20 may include: at least one processor 21, at least one memory 22, a display screen 23, an input / output interface 24, a communication interface 25, a power supply 26, and a communication bus 27. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the disk array card multi-engine task retry method disclosed in any of the foregoing embodiments. Alternatively, the electronic device 20 in this embodiment may specifically be an electronic computer.

[0082] In this embodiment, the power supply 26 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 25 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 24 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0083] Furthermore, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk, or optical disk, etc. The resources stored thereon may include computer programs 221, and the storage method may be temporary storage or permanent storage. The computer programs 221 may include, in addition to computer programs capable of performing the disk array card multi-engine task retry method executed by the electronic device 20 as disclosed in any of the foregoing embodiments, computer programs capable of performing other specific tasks.

[0084] Furthermore, embodiments of this application also disclose a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned disk array card multi-engine task retry method.

[0085] For the specific steps of this method, please refer to the relevant content disclosed in the foregoing embodiments, which will not be repeated here.

[0086] Furthermore, embodiments of this application also disclose a computer program product, including a computer program / instructions, which, when executed by a processor, implement the steps of the disk array card multi-engine task retry method disclosed above.

[0087] The various embodiments in this application are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. For the same or similar parts between the various embodiments, refer to each other. As for the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple, and relevant parts can be referred to in the method section.

[0088] 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.

[0089] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0090] Finally, it should 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.

[0091] The above provides a detailed description of the multi-engine task retry method, apparatus, device, and storage medium for disk array cards provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for retrying multi-engine tasks on a disk array card, characterized in that, An application is made to a task retry system built on a microservice architecture, the task retry system comprising a first microservice component, a second microservice component, and a third microservice component, the method comprising: The first microservice component monitors the task execution status of each hardware engine in the disk array card, and when any hardware engine fails to execute a task, it obtains the target event defined and fed back by the hardware engine, so as to obtain the corresponding task exception information based on the target event. The retry task is determined by the second microservice component based on the task exception information. Then, the target queue corresponding to any hardware engine is determined from a preset number of queues based on the task exception information, and the retry task is written into the target queue. The third microservice component determines the task retry strategy based on task urgency, queue priority, and queue usage, and then re-executes the retry tasks in the target queue according to the task retry strategy.

2. The multi-engine task retry method for disk array cards according to claim 1, characterized in that, The acquisition of the target event defined and fed back by any of the hardware engines includes: Obtain the target event defined and fed back by any of the hardware engines based on the target format; wherein, the target format is obtained based on the hardware engine number, the reason for task execution failure, the task number, the task storage address, the task data size, the number of engine retries, and the target cyclic redundancy check value, and the target cyclic redundancy check value is a check value obtained by performing cyclic redundancy check on the sum of the hardware engine number, the reason for task execution failure, the task number, the task storage address, the task data size, and the number of engine retries.

3. The multi-engine task retry method for disk array cards according to claim 2, characterized in that, Before writing the retry task to the target queue, the method further includes: The queue priority of each target queue corresponding to each hardware engine is determined based on the engine scheduling order, engine allocation weight, and engine retry count of each hardware engine; wherein, the engine scheduling order is the order in which each hardware engine executes the corresponding task, and the engine retry count is the number of times each hardware engine has re-executed the corresponding task.

4. The multi-engine task retry method for disk array cards according to claim 3, characterized in that, The step of determining the queue priority of each target queue corresponding to each hardware engine based on the engine scheduling order, engine allocation weight, and engine retries of each hardware engine includes: A first proportion of the engine scheduling order of each hardware engine, a second proportion of the engine allocation weight, and a third proportion of the number of engine retries are determined; A first calculation result is determined based on the engine scheduling order and the first proportion; a second calculation result is determined based on the engine allocation weight and the second proportion; and a third calculation result is determined based on the number of engine retries and the third proportion. The queue priority of each target queue corresponding to each hardware engine is determined by the first calculation result, the second calculation result, and the third calculation result.

5. The multi-engine task retry method for disk array cards according to any one of claims 1 to 4, characterized in that, Each of the target queues includes a first circular queue and a second circular queue. Therefore, writing the retry task into the target queue includes: Determine whether there is any free space in the first circular queue of the target queue; If there is free space in the first circular queue in the target queue, then the retry task is written into the first circular queue; If there is no free space in the first circular queue of the target queue, then the retry task is written to the second circular queue.

6. The multi-engine task retry method for disk array cards according to claim 5, characterized in that, The step of re-executing the retry tasks in the target queue according to the task retry policy includes: From the various target queues, determine the current target queue with the highest urgency; Determine whether the retry task exists in the first circular queue of the current target queue; If the retry task exists in the first circular queue of the current target queue, then the retry task is re-executed. If the retry task is not present in the first circular queue of the current target queue, a new current target queue is determined from the remaining target queues according to the queue priority, and it is determined whether the retry task is present in the first circular queue of the new current target queue. If the retry task exists in the first circular queue of the new current target queue, then the retry task is re-executed. If the first circular queue in the new current target queue does not contain the retry task, then the process jumps to the step of determining the current target queue with the highest urgency from each of the target queues, so as to determine whether the second circular queue in each of the target queues contains the retry task, and to re-execute the retry task in the second circular queue.

7. The multi-engine task retry method for disk array cards according to claim 6, characterized in that, After re-executing the retry tasks in the target queue according to the task retry policy, the process further includes: If the re-execution of the process fails, it is determined whether the number of engine retries for any of the hardware engines has reached a preset threshold. If the number of retries for any of the hardware engines does not reach the preset threshold, the process jumps to the step of re-executing the retry tasks in the target queue. If the number of engine retries for any of the hardware engines reaches the preset threshold, then the hardware engine will be processed based on the preset exception handling mechanism.

8. A multi-engine task retry device for a disk array card, characterized in that, An application is provided for a task retry system built on a microservice architecture, the task retry system comprising a first microservice component, a second microservice component, and a third microservice component, including: The monitoring module is used to monitor the task execution status of each hardware engine in the disk array card through the first microservice component, and when any hardware engine fails to execute a task, it obtains the target event defined and fed back by the hardware engine, so as to obtain the corresponding task exception information based on the target event. The feedback module is used to determine the retry task through the second microservice component and based on the task exception information, then determine the target queue corresponding to any hardware engine from a preset number of queues according to the task exception information, and write the retry task into the target queue. The retry module is used to determine the task retry strategy through the third microservice component and based on the task urgency, queue priority and queue usage, and then re-execute the retry task in the target queue according to the task retry strategy.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the disk array card multi-engine task retry method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, Used to store computer programs; wherein, when the computer programs are executed by a processor, they implement the disk array card multi-engine task retry method as described in any one of claims 1 to 7.

Images