A Multi-Port Solid State Drive Management Method, Device, Equipment and Storage Medium

Abstract

The present application discloses a multi-port solid-state drive management method, apparatus, device, and storage medium, relating to the field of solid-state drive management. The method includes: obtaining a block device status event reported by a storage performance development kit within the present node; synchronizing the block device status event to the remaining nodes within the system, so that each node within the system updates a cluster hard disk device for system shared access according to the block device status event, and synchronizes derivative event information generated during the update process to the remaining nodes within the system; obtaining an operation instruction for the cluster hard disk device sent by an application layer, and determining whether the present node meets the operation execution condition; if the operation execution condition is not met, then performing a corresponding operation on the multi-port solid-state drive through the in-storage performance development kits of the remaining nodes within the system according to the operation instruction. It can simultaneously exert the performance of the storage performance development kit and the reliability value of the multi-port.

Description

Technical Field

[0001] The present invention relates to the field of solid state drive management, and particularly to a multi-port solid state drive management method, device, equipment and storage medium. Background Art

[0002] At present, in order to solve the disadvantage of single-point failure of single-port hard disks, multi-port hard disks are adopted, that is, multiple nodes (controllers with CPUs) in a storage system are all connected to the multi-port hard disks, so that when a certain node fails, services can continue to be provided through other nodes, ensuring that the business is not interrupted and realizing business redundancy. SPDK (Storage Performance Development Kit) is a high-performance NVMe (NVM Express) hard disk development kit, which uses new technologies such as thread lock-free, binding, and large pages to improve the performance of hard disks. However, SPDK currently only supports single-port hard disks and does not support multi-port hard disks. Summary of the Invention

[0003] In view of this, the purpose of the present invention is to provide a multi-port solid state drive management method, device, equipment and medium, which can give full play to the performance of the storage performance development kit and the reliability value of multi-ports. The specific solutions are as follows:

[0004] In a first aspect, the present application discloses a multi-port solid state drive management method, including:

[0005] Obtaining a block device status event reported by a storage performance development kit within the present node; the block device status event is a block device status change event corresponding to a multi-port solid state drive connected to the present node;

[0006] Synchronizing the block device status event to the remaining nodes in the system, so that each node in the system updates a cluster hard disk device for system shared access according to the block device status event, and synchronizes derivative event information generated during the update process to the remaining nodes in the system;

[0007] Obtaining an operation instruction sent by an application layer for the cluster hard disk device, and determining whether the present node meets the operation execution condition;

[0008] If the operation execution condition is not met, performing a corresponding operation on the multi-port solid state drive according to the operation instruction through the internal storage performance development kits of the remaining nodes in the system.

[0009] Optionally, updating the cluster hard disk device for system shared access according to the block device status event, and synchronizing the derived event information generated during the update to the remaining nodes in the system, including:

[0010] Updating the cluster hard disk device for system shared access according to the block device status event, and generating a device update derived event after the update is completed; wherein, the block device status event includes block device access, block device removal, block device failure, and block device reset;

[0011] Synchronizing the device update derived event to the remaining nodes in the system so that each node in the system includes the cluster hard disk device information of the remaining nodes in the system.

[0012] Optionally, performing corresponding operations on the multi-port solid state drive according to the operation instruction through the in-memory performance development kits of the remaining nodes in the system, including:

[0013] Determining a target node according to the operation instruction and the cluster hard disk device information of the remaining nodes in the system stored in this node;

[0014] Sending the operation instruction to the target node so that the corresponding operation can be performed on the multi-port solid state drive through the in-memory performance development kit of the target node.

[0015] Optionally, synchronizing the block device status event to the remaining nodes in the system, including:

[0016] If this node is the master node in the system, synchronize the block device status event to the local log and broadcast the block device status event to the slave nodes in the system so that the slave nodes can update their respective logs according to the block device status event;

[0017] If this node is a slave node in the system, report the block device status event to the master node in the system. The master node in the system synchronizes the block device status event to its own log and broadcasts the block device status event to the slave nodes in the system so that the slave nodes can update their respective logs according to the block device status event.

[0018] Optionally, the multi-port solid state drive management method further includes:

[0019] After the node starts, temporarily default the node as a slave node and start a lease timer;

[0020] If lease information sent by the master node is obtained within the lease period corresponding to the lease timer, set the node type as a slave node;

[0021] If lease information sent by the master node is not obtained within the lease period corresponding to the lease timer, an arbitration information acquisition request is sent to the arbitration disk of the multi-port solid state drive;

[0022] If arbitration information sent by the arbitration disk is obtained, the node type is set to the master node.

[0023] Optionally, after determining whether this node meets the operation execution conditions, it further includes:

[0024] If it meets the operation execution conditions, the corresponding operation is performed on the multi-port solid state drive through the storage performance development kit in this node according to the operation instruction.

[0025] Optionally, determining whether this node meets the operation execution conditions includes:

[0026] Determining whether there is a fault in the communication link between the storage performance development kit in this node and the multi-port solid state drive;

[0027] If there is a fault, it is determined that this node does not meet the operation execution conditions, otherwise, it is determined that this node meets the operation execution conditions.

[0028] In a second aspect, the present application discloses a multi-port solid state drive management device, including:

[0029] An event acquisition module, configured to acquire block device status events reported by the storage performance development kit in this node; the block device status events are block device status change events corresponding to the multi-port solid state drive connected to this node;

[0030] An event synchronization module, configured to synchronize the block device status events to the remaining nodes in the system, so that each node in the system updates the cluster hard disk device for system shared access according to the block device status events, and synchronizes the derived event information generated during the update process to the remaining nodes in the system;

[0031] An instruction acquisition module, configured to acquire an operation instruction sent by the application layer for the cluster hard disk device, and determine whether this node meets the operation execution conditions;

[0032] An instruction execution module, configured to, if it does not meet the operation execution conditions, perform the corresponding operation on the multi-port solid state drive through the storage performance development kits in the remaining nodes in the system according to the operation instruction.

[0033] In a third aspect, the present application discloses an electronic device, including:

[0034] A memory, configured to store a computer program;

[0035] A processor for executing the computer program to implement the multi-port solid state drive management method described above.

[0036] In a fourth aspect, the present application discloses a computer-readable storage medium for storing a computer program; wherein when the computer program is executed by a processor, the multi-port solid state drive management method described above is implemented.

[0037] In the present application, a block device status event reported by a storage performance development kit within the present node is obtained; the block device status event is a block device status change event corresponding to a multi-port solid state drive connected to the present node; the block device status event is synchronized to the remaining nodes within the system, so that each node within the system updates a cluster hard disk device for system shared access according to the block device status event, and synchronizes derivative event information generated during the update process to the remaining nodes within the system; an operation instruction for the cluster hard disk device sent by the application layer is obtained, and it is determined whether the present node meets the operation execution condition; if the operation execution condition is not met, then according to the operation instruction, through the in-storage performance development kits of the remaining nodes within the system, corresponding operations are performed on the multi-port solid state drive. It can be seen that according to the block device status events reported by the storage performance development kit, a cluster hard disk device object for system shared access is created and updated in real time, and by synchronizing the events of the present node to the remaining nodes within the system, any node within the system stores the cluster hard disk device information of the remaining nodes, realizing the consistency of node events between different nodes. After obtaining an operation instruction for the cluster hard disk device from the application layer, if the present node cannot execute the operation instruction, then according to the operation instruction, through the in-storage performance development kits of the remaining nodes within the system, corresponding operations are performed on the multi-port solid state drive. Thus, the usage scenario of the storage performance development kit is extended to multi-port solid state drives, which can not only give full play to the performance of the storage performance development kit, but also give play to the reliability value of multiple ports. Description of the Drawings

[0038] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the drawings in the following description are only the embodiments of the present invention, and for those of ordinary skill in the art, other drawings can be obtained according to the provided drawings without creative efforts.

[0039] Figure 1 It is a flowchart of a multi-port solid state drive management method provided by the present application;

[0040] Figure 2 It is a specific dual-port solid state drive management architecture diagram provided by the present application;

[0041] Figure 3A specific flowchart for log synchronization between nodes provided by this application;

[0042] Figure 4 A specific structure of the cluster hard disk device components provided by this application;

[0043] Figure 5 A specific message transmission flowchart of sub-components within the cluster hard disk device components provided by this application;

[0044] Figure 6 A specific flowchart for state transitions of the state machine provided by this application;

[0045] Figure 7 A schematic diagram of the structure of the control page components provided by this application;

[0046] Figure 8 A schematic diagram of the structure of the data page components provided by this application;

[0047] Figure 9 A schematic diagram of the structure of a multi-port solid-state drive management device provided by this application;

[0048] Figure 10 A structural diagram of an electronic device provided by this application. Detailed implementation manners

[0049] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. Apparently, the described embodiments are only some of the embodiments of the present invention, rather than all of them. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the scope of protection of the present invention.

[0050] In the prior art, SPDK only supports single-port hard disks and does not support multi-port hard disks. To overcome the above technical problems, this application proposes a dual-port NVMe hard disk management method based on the storage performance development kit, which can give full play to the performance of the storage performance development kit and the reliability value of multi-ports.

[0051] Embodiments of this application disclose a multi-port solid-state drive management method. Refer to Figure 1 as shown, the method may include the following steps:

[0052] Step S11: Obtain the block device status events reported by the storage performance development kit within this node; the block device status events are block device status change events corresponding to the multi-port solid-state drives connected to this node.

[0053] First, withFigure 2 Describe the dual-port solid-state drive management architecture shown below. Figure 2 In the storage performance development kit, the block device component (bdev component), the link transport layer (NVMe pcie transport), and the user dynamic driver (PCIe usrdriver) are components existing in SPDK. Among them, the cluster hard disk device component (cdev, cluster dev) is newly added in this embodiment. The multi-port solid-state drive management method disclosed in this embodiment is integrated into the above-mentioned cluster hard disk device component. That is, the cluster hard disk device component has the characteristic of shared access by 2 nodes, providing redundant hard disk devices for the business (app). The above dual-port solid-state drive can specifically be an NVMe solid-state drive.

[0054] In this embodiment, first, obtain the block device status events reported by the block device component of the storage performance development kit within the node. Among them, the block device status events are block device status change events corresponding to the multi-port solid-state drive connected to this node. The block device status events include, but are not limited to, events such as block device access, block device removal, block device failure, and block device reset. That is, when the block device component detects a change in the block device connected to the local node, it reports the corresponding block device status event to the cluster hard disk device component.

[0055] Step S12: Synchronize the block device status events to the remaining nodes in the system, so that each node in the system updates the cluster hard disk device for system shared access according to the block device status events, and synchronizes the derived event information generated during the update process to the remaining nodes in the system.

[0056] That is, after this node receives the block device status event, it synchronizes the event through the cluster hard disk device components of this node and the remaining nodes, so that each node in the system creates or deletes the cluster hard disk device object that supports system shared access according to the block device status event, and during the update process of the cluster hard disk device, synchronizes the generated derived events to the remaining nodes to achieve the consistency of the cluster hard disk device status in different nodes. For example, after the block device access event is synchronized and verified, all nodes in the system receive the creation event and create the cluster hard disk device, that is, according to whether the accessed block device supports system sharing, if it supports sharing, create the cluster hard disk device corresponding to the block device; specifically, when the hard disk is accessed, a PCIE interrupt is generated, SPDK determines the address information of the hard disk, obtains the basic information of the hard disk (manufacturer, capacity, etc.) according to the NVMe protocol used by the hard disk, the block device component creates a corresponding block device object according to the information corresponding to the hard disk, and reports it to the cluster hard disk device component of this node, and then broadcasts it to all nodes through the master node, so that each node creates a corresponding cluster hard disk device object.

[0057] In this embodiment, synchronizing the block device status event to the remaining nodes in the system may include: if this node is the master node in the system, synchronize the block device status event to the local log, and broadcast the block device status event to the slave nodes in the system, so that the slave nodes can update their respective logs according to the block device status event; if this node is the slave node in the system, report the block device status event to the master node in the system, and the master node in the system synchronizes the block device status event to its own log, and broadcasts the block device status event to the slave nodes in the system, so that the slave nodes can update their respective logs according to the block device status event. That is, the sending logic of the event is sent sequentially in the order of the log as shown in Figure 3 follows. The events are sent by the master node and responded to by the slave nodes. That is, this node sends an event to the master node. After receiving the event, the master node appends the event to the event log, and the master node sends the event to the slave nodes. If the sending fails, it will keep retrying. In this case, if there is a message failure in the slave node, the lease will expire. After the lease expires, the slave node will be kicked out of the cluster and the node will be restarted. If the sending to the slave node is successful, the slave node will record the event in the event log of this node to be consistent with the master node.

[0058] In this embodiment, the multi-port solid-state drive management method may further include: after the node starts, temporarily default the node as a slave node and start a lease timer; if the lease information sent by the master node is obtained within the lease period corresponding to the lease timer, set the node type as a slave node; if the lease information sent by the master node is not obtained within the lease period corresponding to the lease timer, send an arbitration information acquisition request to the arbitration disk of the multi-port solid-state drive; if the arbitration information sent by the arbitration disk is obtained, set the node type as the master node. That is, by using the arbitration disk, there is mutual exclusivity, and only one node can obtain the arbitration information at the same time to determine the master node in the system. Specifically, the node type is set as a slave node first, and a lease timer is initiated to regularly obtain the master node message. If there is a master node in the system and the lease information can be obtained within the lease expiration timer, the role of this node is a slave node. If there is no master node in the system and the lease timer expires, an arbitration information acquisition request is sent to the arbitration disk. If the arbitration information can be obtained, the role of this node is the master node, otherwise it is a slave node.

[0059] In this embodiment, updating the cluster hard disk device for system shared access according to the block device status event and synchronizing the derived event information generated during the update to the remaining nodes in the system may include: updating the cluster hard disk device for system shared access according to the block device status event, and generating a device update derived event after the update is completed; wherein, the block device status event includes block device access, block device removal, block device failure, and block device reset; synchronizing the device update derived event to the remaining nodes in the system so that each node in the system includes the cluster hard disk device information of the remaining nodes in the system.

[0060] Step S13: Obtain the operation instruction for the cluster hard disk device sent by the application layer, and determine whether this node meets the operation execution condition.

[0061] In this embodiment, after the cluster hard disk device object is created, the cluster hard disk device component receives the operation instruction for the cluster hard disk device sent by the application layer, that is, the user. The operation instruction includes but is not limited to hardware events such as partitioning, creating a file system, powering on and powering off, etc. At the same time, it is determined whether this node meets the operation execution condition, that is, whether the operation instruction can be executed.

[0062] In this embodiment, determining whether this node meets the operation execution condition may include: determining whether there is a fault in the communication link between the storage performance development kit and the multi-port solid state drive in this node; if there is a fault, it is determined that this node does not meet the operation execution condition, otherwise, it is determined that this node meets the operation execution condition. That is, it is determined whether there is a fault in the communication link between this node and the multi-port solid state drive. Currently, the current load capacity of the node can also be used as one of the operation execution conditions, that is, if the current node load is too large, other nodes can be selected to execute the operation.

[0063] Step S14: If it does not meet the operation execution condition, execute the corresponding operation on the multi-port solid state drive through the in-storage performance development kits of the remaining nodes in the system according to the operation instruction.

[0064] That is, when it does not meet the operation execution condition, the cluster hard disk device component of this node communicates with the cluster hard disk device component of a certain other node, and uses the in-storage performance development kit of the other node to execute the corresponding operation on the multi-port solid state drive.

[0065] In this embodiment, after determining whether this node meets the operation execution condition, it may further include: if it meets the operation execution condition, execute the corresponding operation on the multi-port solid state drive through the in-storage performance development kit in this node according to the operation instruction. If this node can execute the operation, first this node executes it to avoid the consumption caused by operations such as instruction forwarding.

[0066] In this embodiment, the step of performing a corresponding operation on the multi-port solid-state drive through the in-memory performance development kit of the remaining nodes in the system according to the operation instruction may include: determining a target node according to the operation instruction and the cluster hard disk device information of the remaining nodes in the system stored in this node; sending the operation instruction to the target node, so as to perform a corresponding operation on the multi-port solid-state drive through the in-memory performance development kit of the target node. That is, according to the cluster hard disk device information of the remaining nodes stored in the data layer of this node, the access path for accessing the current target storage through the remaining nodes is determined, and then the operation instruction is sent to the target node through the cluster hard disk device components of this node and the target node, so that the target node can perform a corresponding operation on the multi-port solid-state drive through its own in-memory performance development kit. That is to say, each node can access its corresponding block device through SPDK. Although the block devices accessed by different nodes are the same hard disk from the physical medium perspective, for the block device component, IO reading can only be performed on its own node. Therefore, in this embodiment, by constructing a cluster hard disk device component, the cluster hard disk device component of a certain node can perform IO reading on the physical medium through other nodes.

[0067] Furthermore, the present application discloses a specific structure of a cluster hard disk device component. For example Figure 4 As shown, it may specifically include four sub-components. The state machine (cdev_state_machine) is responsible for the conversion processing of the cdev state. The cluster event processing component (cluster_event_machine) is responsible for the processing of cluster events reported by bdev. The control plane (cdev ctrlplane) is responsible for the creation, deletion, hot plugging, etc. of cdev devices; the data plane (cdev data plane) is responsible for the processing of cdev IO commands. Among them, the message transmission between the sub-components in the cluster hard disk device component can be as Figure 5 As shown, after the bdev is created, a block device status event is sent, such as a block device access event, indicating that a bdev device is accessed. The cluster processing component sends the event to the cluster processing component of the second node in the system through a consistency protocol. After receiving the event, the node calls the state machine to process the event, and the state machine is responsible for the consistency of the cdev states of the two nodes in the system by sending derived events. For example Figure 6The figure shows a schematic diagram of the state transition of the state machine. INIT represents that the cdev state machine registers the cluster event machine event response interface. REPORT_IN represents that the bdev reports the device access event. REPORT_OUT represents that the bdev reports the device removal event. FAULT represents that the bdev reports the device failure event. RESERTING represents that the bdev reports the device reset event. For example, when the cdev state machine is initialized, the state transfers to the INIT state to register the event response interface. When receiving the device access event reported by the bdev, it sends the event of creating the cdev-derived cluster to all nodes in the system. After all nodes in the system receive the creation event, they create the cdev device. After all nodes complete the creation of the cdev device, they send the device update-derived event. After all nodes receive the update event, they send the cdev event of their own node to the update cluster event. All nodes update the cdev device information. After this step is implemented, the cdev contains the cdev information of other nodes, such as path information, etc.

[0068] For example Figure 7 The figure shows a schematic diagram of a specific control page component structure, including the cdev cluster event interface (cdevevent), cdev device management (cdev managed) for device creation, deletion, fault, etc., cdev hardware device management (cdev hdm) for hardware information query, up and down points, reset, etc., and cdev device health monitoring (cdev hm) for inspection, fault prediction, etc. That is, the cdev event registers the event interface with the cluster event machine. After receiving the secondary-derived event generated by the state machine, the cdev managed is responsible for managing the cdev device. If it receives the hardware event for the cdev issued by the application layer, it calls the cdev hdm component to process it. After the cdev device creation and initialization are completed, the cdev hm module starts the background health management function. For example Figure 8The following is a schematic diagram of a specific data page component structure, including an IO device corresponding to cdev (IO Device), which is used to register information such as IO operations and IO chunking; an IO error handling module (IO erp), an IO statistics module (IOstat), and an IO channel (IO channel). It can be understood that after the cdev IO device receives the corresponding IO requests (read and write), the IO device hangs the IO to the corresponding IO channel, and the poll group of the IO channel polls and processes it. If the IO returns an error, the IO erp processes it according to the pre-set error policy, that is, access through the remaining nodes. After the IO is completed, the IO statistics information in the IO stat is updated. That is to say, the operation instructions received by this node at the application layer are sent to the data plane through the control plane, and the data plane is used to determine the access path. If this node supports direct access, it directly accesses through this node. If this node does not support access, the target node is determined according to the recorded cluster hard disk device information of the remaining nodes, and the request is forwarded to the data plane of the target node. Thus, through the cluster hard disk device components pre-created on the upper layer of SDPK between different nodes, communication between components is carried out to achieve information synchronization and access between components.

[0069] As can be seen from the above, in this embodiment, by obtaining the block device status events reported by the storage performance development kit within this node; the block device status events are block device status change events corresponding to the multi-port solid-state drives connected to this node; synchronizing the block device status events to the remaining nodes within the system, so that each node within the system updates the cluster hard disk device for system shared access according to the block device status events, and synchronizes the derived event information generated during the update process to the remaining nodes within the system; obtaining the operation instructions sent by the application layer for the cluster hard disk device, and determining whether this node meets the operation execution conditions; if it does not meet the operation execution conditions, then according to the operation instructions, through the internal storage performance development kits of the remaining nodes within the system, perform the corresponding operations on the multi-port solid-state drives. It can be seen that according to the block device status events reported by the storage performance development kit, a cluster hard disk device object for system shared access is created and updated in real time, and by synchronizing the events of this node to the remaining nodes within the system, any node within the system stores the cluster hard disk device information of the remaining nodes, achieving the consistency of node events between different nodes. After obtaining the operation instructions from the application layer for the cluster hard disk device, if this node cannot execute the operation instructions, then according to the operation instructions, through the internal storage performance development kits of the remaining nodes within the system, perform the corresponding operations on the multi-port solid-state drives. Thus, the usage scenario of the storage performance development kit is extended to multi-port solid-state drives, which can not only give full play to the performance of the storage performance development kit, but also give play to the reliability value of the multi-port.

[0070] Correspondingly, an embodiment of the present application also discloses a multi-port solid state drive management device. Refer to Figure 9 as shown, the device includes:

[0071] An event acquisition module 11, configured to acquire block device status events reported by a storage performance development kit within the present node; the block device status events are block device status change events corresponding to a multi-port solid state drive connected to the present node;

[0072] An event synchronization module 12, configured to synchronize the block device status events to the remaining nodes within the system, so that each node within the system updates a cluster hard disk device for system shared access according to the block device status events, and synchronizes derivative event information generated during the update process to the remaining nodes within the system;

[0073] An instruction acquisition module 13, configured to acquire an operation instruction sent by an application layer for the cluster hard disk device, and determine whether the present node meets the operation execution condition;

[0074] An instruction execution module 14, configured to, if the operation execution condition is not met, execute a corresponding operation on the multi-port solid state drive according to the operation instruction through the storage performance development kits of the remaining nodes within the system.

[0075] As can be seen from the above, in this embodiment, the block device status event reported by the storage performance development kit within this node is obtained; the block device status event is a block device status change event corresponding to the multi-port solid-state drive connected to this node; the block device status event is synchronized to the remaining nodes within the system, so that each node within the system can update the cluster hard disk device for system shared access according to the block device status event, and synchronize the derived event information generated during the update process to the remaining nodes within the system; the operation instruction for the cluster hard disk device sent by the application layer is obtained, and it is determined whether this node meets the operation execution condition; if it does not meet the operation execution condition, the corresponding operation is performed on the multi-port solid-state drive according to the operation instruction through the in-storage performance development kits of the remaining nodes within the system. It can be seen that according to the block device status event reported by the storage performance development kit, the cluster hard disk device object for system shared access is created and updated in real time, and by synchronizing the events of this node to the remaining nodes within the system, any node within the system stores the cluster hard disk device information of the remaining nodes, realizing the consistency of node events between different nodes. After obtaining the operation instruction for the cluster hard disk device from the application layer, if this node cannot execute the operation instruction, the corresponding operation is performed on the multi-port solid-state drive according to the operation instruction through the in-storage performance development kits of the remaining nodes within the system. Thus, the usage scenario of the storage performance development kit is extended to multi-port solid-state drives, which can not only give full play to the performance of the storage performance development kit but also the reliability value of multiple ports.

[0076] In some specific embodiments, the event synchronization module 12 may specifically include:

[0077] An update unit, configured to update the cluster hard disk device for system shared access according to the block device status event, and generate a device update derived event after the update is completed; wherein, the block device status event includes block device access, block device removal, block device failure, and block device reset;

[0078] A derived event synchronization unit, configured to synchronize the device update derived event to the remaining nodes within the system, so that each node within the system includes the cluster hard disk device information of the remaining nodes within the system.

[0079] In some specific embodiments, the instruction execution module 14 may specifically include:

[0080] A target node determination unit, configured to determine a target node according to the operation instruction and the cluster hard disk device information of the remaining nodes within the system stored by this node;

[0081] An operation execution unit, configured to send the operation instruction to the target node, so as to execute a corresponding operation on the multi-port solid state drive through the in-memory performance development kit of the target node.

[0082] In some specific embodiments, the event synchronization module 12 may specifically include:

[0083] A first event synchronization unit, configured to, if this node is the master node in the system, synchronize the block device status event to the local log and broadcast the block device status event to the slave nodes in the system, so that the slave nodes update their respective logs according to the block device status event;

[0084] A second event synchronization unit, configured to, if this node is the slave node in the system, report the block device status event to the master node in the system, and the master node in the system synchronizes the block device status event to its own log and broadcasts the block device status event to the slave nodes in the system, so that the slave nodes update their respective logs according to the block device status event.

[0085] In some specific embodiments, the multi-port solid state drive management device may specifically include:

[0086] A timer start unit, configured to temporarily default the node to a slave node after the node starts and start a lease timer;

[0087] A lease information acquisition unit, configured to, if lease information sent by the master node is acquired within the lease period corresponding to the lease timer, set the node type to a slave node;

[0088] An arbitration information request unit, configured to, if lease information sent by the master node is not acquired within the lease period corresponding to the lease timer, send an arbitration information acquisition request to the arbitration disk of the multi-port solid state drive;

[0089] An arbitration information acquisition unit, configured to, if arbitration information sent by the arbitration disk is acquired, set the node type to the master node.

[0090] In some specific embodiments, the multi-port solid state drive management device may specifically include:

[0091] A local instruction execution unit, configured to, if the operation execution condition is met, execute a corresponding operation on the multi-port solid state drive according to the operation instruction through the in-memory performance development kit in this node.

[0092] In some specific embodiments, the instruction acquisition module 13 may specifically include:

[0093] A fault judgment unit, configured to judge whether there is a fault in the communication link between the storage performance development kit and the multi-port solid-state drive within this node;

[0094] An operation execution condition judgment unit, configured to determine that this node does not meet the operation execution conditions if there is a fault, otherwise, determine that this node meets the operation execution conditions.

[0095] Furthermore, an embodiment of the present application also discloses an electronic device. Refer to Figure 10 As shown, the content in the figure should not be considered as any limitation to the scope of use of the present application.

[0096] Figure 10 It is a schematic structural diagram of an electronic device 20 provided by an embodiment of the present application. The electronic device 20 may specifically include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. Among them, the memory 22 is used to store a computer program, and the computer program is loaded and executed by the processor 21 to implement the relevant steps in the multi-port solid-state drive management method disclosed in any of the foregoing embodiments.

[0097] In this embodiment, the power supply 23 is used to provide working voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows is any communication protocol applicable to the technical solution of the present application, and no specific limitation is imposed on it here; the input / output interface 25 is used to obtain external input data or output data to the outside, and its specific interface type can be selected according to specific application requirements, and no specific limitation is made here.

[0098] In addition, as a carrier for resource storage, the memory 22 can be a read-only memory, a random access memory, a magnetic disk, or an optical disc, etc. The resources stored thereon include an operating system 221, a computer program 222, and data 223 including block device status events, etc., and the storage method can be short-term storage or permanent storage.

[0099] Among them, the operating system 221 is used to manage and control each hardware device on the electronic device 20 and the computer program 222 to implement the operation and processing of the massive data 223 in the memory 22 by the processor 21, and it can be Windows Server, Netware, Unix, Linux, etc. In addition to the computer program that can be used to complete the multi-port solid-state drive management method executed by the electronic device 20 disclosed in any of the foregoing embodiments, the computer program 222 can further include computer programs that can be used to complete other specific tasks.

[0100] Further, the embodiments of the present application also disclose a computer storage medium. Computer-executable instructions are stored in the computer storage medium. When the computer-executable instructions are loaded and executed by a processor, the steps of the multi-port solid-state drive management method disclosed in any of the foregoing embodiments are implemented.

[0101] The various embodiments in this specification are described in a progressive manner. The key point of each embodiment is to illustrate the differences from other embodiments. For the same or similar parts among the various embodiments, reference can be made to each other. For the devices disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple. For the relevant parts, reference can be made to the descriptions in the method part.

[0102] The steps of the methods or algorithms described in combination with the embodiments disclosed in this article can be directly implemented by hardware, software modules executed by a processor, or a combination of both. The software modules can be placed in a random access memory (RAM), internal 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 well-known in the technical field.

[0103] Finally, it should also be noted that in this article, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the term "comprising", "including" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements not only includes those elements, but also includes other elements not expressly listed, or further includes elements inherent to such process, method, article or device. Without further limitation, an element defined by the statement "including a..." does not exclude the existence of additional identical elements in the process, method, article or device including the said element.

[0104] The above has introduced in detail a multi-port solid-state drive management method, device, equipment and medium provided by the present invention. Specific examples are used in this article to elaborate on the principle and implementation manner of the present invention. The descriptions of the above embodiments are only used to help understand the method and its core idea of the present invention; at the same time, for those of ordinary skill in the art, according to the idea of the present invention, there will be changes in the specific implementation manner and application scope. In summary, the content of this specification should not be construed as a limitation to the present invention.

Claims

1. A multi-port solid state drive management method, characterized in that Applied to nodes within a system, including: Obtain block device status events reported by the storage performance development kit within this node; the block device status events are block device status change events corresponding to multi-port solid-state drives connected to this node; Synchronize the block device status events to the remaining nodes within the system, so that each node within the system updates the cluster hard disk device for system shared access according to the block device status events, and synchronizes the derived event information generated during the update process to the remaining nodes within the system; Obtain an operation instruction for the cluster hard disk device sent by the application layer, and determine whether this node meets the operation execution condition; If it does not meet the operation execution condition, then perform the corresponding operation on the multi-port solid-state drive according to the operation instruction through the in-storage performance development kits of the remaining nodes within the system; Among them, the synchronizing the block device status events to the remaining nodes within the system includes: If this node is the master node within the system, then synchronize the block device status events to the local log, and broadcast the block device status events to the slave nodes within the system, so that the slave nodes update their respective logs according to the block device status events; If this node is a slave node within the system, then report the block device status events to the master node within the system, and the master node within the system synchronizes the block device status events to its own log, and broadcasts the block device status events to the slave nodes within the system, so that the slave nodes update their respective logs according to the block device status events; Among them, the determining whether this node meets the operation execution condition includes: Determine whether there is a fault in the communication link between the storage performance development kit within this node and the multi-port solid-state drive; If there is a fault, it is determined that this node does not meet the operation execution condition, otherwise, it is determined that this node meets the operation execution condition.

2. The multi-port solid state drive management method according to claim 1, wherein The updating the cluster hard disk device for system shared access according to the block device status events, and synchronizing the derived event information generated during the update process to the remaining nodes within the system includes: Update the cluster hard disk device for system shared access according to the block device status events, and generate a device update derived event after the update is completed; among them, the block device status events include block device access, block device removal, block device failure, and block device reset; Synchronize the device update derived event to the remaining nodes within the system, so that each node within the system contains the cluster hard disk device information of the remaining nodes within the system.

3. The multi-port solid state drive management method according to claim 2, wherein The performing the corresponding operation on the multi-port solid-state drive according to the operation instruction through the in-storage performance development kits of the remaining nodes within the system includes: Determine the target node according to the operation instruction and the cluster hard disk device information of the remaining nodes within the system stored in this node; Send the operation instruction to the target node, so that the corresponding operation is performed on the multi-port solid-state drive through the in-storage performance development kit of the target node.

4. The multi-port solid state drive management method according to claim 1, wherein It also includes: After the node starts, temporarily default the node as a slave node and start a lease timer; If lease information sent by the master node is obtained within the lease period corresponding to the lease timer, the node type is set to a slave node; If lease information sent by the master node is not obtained within the lease period corresponding to the lease timer, an arbitration information acquisition request is sent to the arbitration disk of the multi-port solid state drive; If arbitration information sent by the arbitration disk is obtained, the node type is set to a master node.

5. The multi-port solid state drive management method according to claim 1, wherein After determining whether this node meets the operation execution conditions, it further includes: If it meets the operation execution conditions, the corresponding operation is performed on the multi-port solid state drive through the storage performance development kit in this node according to the operation instruction.

6. A multi-port solid state drive management device, characterized in that, Applied to a node in the system, it includes: An event acquisition module, configured to acquire a block device status event reported by the storage performance development kit in this node; the block device status event is a block device status change event corresponding to the multi-port solid state drive connected to this node; An event synchronization module, configured to synchronize the block device status event to the remaining nodes in the system, so that each node in the system updates the cluster hard disk device for system shared access according to the block device status event, and synchronizes the derived event information generated during the update process to the remaining nodes in the system; An instruction acquisition module, configured to acquire an operation instruction for the cluster hard disk device sent by the application layer, and determine whether this node meets the operation execution conditions; An instruction execution module, configured to, if it does not meet the operation execution conditions, perform the corresponding operation on the multi-port solid state drive through the storage performance development kit in the remaining nodes in the system according to the operation instruction; Among them, the event synchronization module is configured to, if this node is the master node in the system, synchronize the block device status event to the local log, and broadcast the block device status event to the slave nodes in the system, so that the slave nodes update their respective logs according to the block device status event; if this node is the slave node in the system, report the block device status event to the master node in the system, and the master node in the system synchronizes the block device status event to its own log, and broadcasts the block device status event to the slave nodes in the system, so that the slave nodes update their respective logs according to the block device status event; Among them, the instruction acquisition module is configured to determine whether there is a fault in the communication link between the storage performance development kit in this node and the multi-port solid state drive; if there is a fault, it is determined that this node does not meet the operation execution conditions, otherwise, it is determined that this node meets the operation execution conditions.

7. An electronic device, characterized in that, It includes: A memory, configured to save a computer program; A processor, configured to execute the computer program to implement the multi-port solid state drive management method according to any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, For storing a computer program; wherein when the computer program is executed by the processor, the multi-port solid state drive management method according to any one of claims 1 to 5 is implemented.

Images