Storage system management method, device, equipment, storage medium and program product

Abstract

The application discloses a storage system management method and device, equipment, a storage medium and a program product, relates to the technical field of storage, and the method of the application develops a monitoring program running in a host kernel, and associates the monitoring program with at least part of protocol layers of a storage protocol stack. Thus, when a target event occurs in the associated protocol layer, the monitoring program can collect context data of the target event. In this way, a collection channel of bottom-layer running data is added in the general storage system. In the case that the general storage system only returns high-latitude data, the bottom-layer running state of the storage system can be judged based on the data collected by the monitoring program, secondary data collection by maintenance personnel is avoided, and therefore, the management efficiency of the storage system can be greatly improved. In this way, the problem that the running information returned by the general storage system in some technologies has high dimensions and the management efficiency of the storage system is low is solved.

Description

Technical Field

[0001] This application relates to the field of storage technology, and in particular to storage system management methods, apparatus, devices, storage media, and software products. Background Technology

[0002] Currently, storage systems are divided into general-purpose storage systems and custom storage systems. General-purpose storage systems are low-cost and can meet the storage needs of general scenarios, but the operational information they return is high-dimensional, meaning maintenance personnel cannot directly obtain the underlying operational information of the storage system, resulting in low management efficiency. Custom storage systems are more expensive, but their hardware firmware (such as firmware in hard drive controllers, firmware in expanders, etc.) and various protocol layers can be highly customized according to specific application scenarios, enabling the storage system to return information of a specified dimension, thereby greatly improving the management efficiency of the storage system. Based on the above description, obtaining the low-dimensional operational information of general-purpose storage systems becomes the key to improving the management efficiency of storage systems. Summary of the Invention

[0003] This application provides a storage system management method, storage system management device, electronic device, computer-readable storage medium, and computer program product to at least solve the problems of high dimensionality of operational information returned by general storage systems in related technologies and low storage system management efficiency.

[0004] This application provides a storage system management method, including:

[0005] The monitoring program collects the runtime data of the storage protocol stack. The monitoring program and the storage protocol stack run in the host kernel. The monitoring program is associated with at least some protocol layers of the storage protocol stack. When a target event occurs in the associated protocol layer, the monitoring program collects the context data of the target event as the runtime data of the storage protocol stack. The target events are different for different protocol layers.

[0006] Based on the operational data of the storage protocol stack, the system state of the storage system is determined;

[0007] The storage system is managed based on the system status.

[0008] This application also provides a storage system management device, including:

[0009] The data acquisition module is used to collect the running data of the storage protocol stack through a monitoring program. The monitoring program and the storage protocol stack run in the host kernel. The monitoring program is associated with at least some protocol layers of the storage protocol stack. When a target event occurs in the associated protocol layer, the monitoring program collects the context data of the target event as the running data of the storage protocol stack. The target events are different for different protocol layers.

[0010] The system status determination module is used to determine the system status of the storage system based on the operating data of the storage protocol stack.

[0011] The system management module is used to manage the storage system based on the system status.

[0012] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the steps of the above-described memory system management method when executing the computer program.

[0013] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of the above-described storage system management method.

[0014] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described storage system management method.

[0015] In some embodiments of this application, a monitoring program is developed and runs in the host kernel. This monitoring program is associated with at least a portion of the protocol layers of the storage protocol stack. When a target event occurs at the associated protocol layer, the monitoring program can collect context data of the target event. This context data can be the underlying operational data of the storage system, or it can reflect the underlying operational state of the storage system, effectively adding a new channel for collecting underlying operational data to the general-purpose storage system. When the general-purpose storage system only returns high-dimensional data, the underlying operational state of the storage system can be determined based on the data collected by the monitoring program, avoiding secondary data collection by maintenance personnel and significantly improving the management efficiency of the storage system. This solves the problem of low management efficiency in some technologies where the operational information returned by general-purpose storage systems is of high dimensionality. Attached Figure Description

[0016] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 A schematic diagram of the eBPF architecture provided for some embodiments of this application;

[0018] Figure 2 A flowchart illustrating a storage system management method provided for some embodiments of this application;

[0019] Figure 3 A schematic diagram of the architecture of a SAS storage system provided for some embodiments of this application;

[0020] Figure 4 Schematic diagrams of the architecture of a SAS storage system provided for other embodiments of this application;

[0021] Figure 5 A schematic diagram of a storage system management device provided for some embodiments of this application;

[0022] Figure 6 A schematic diagram of the modules of an electronic device provided for some embodiments of this application. Detailed Implementation

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

[0024] It should be noted that, in the description of this application, 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. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

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

[0026] Before describing the method of this application, the architecture of eBPF (extended Berkeley Packet Filter) will be explained. (Refer to the relevant references.) Figure 1 This is a schematic diagram of the eBPF architecture provided in some embodiments of this application. Figure 1In the eBPF architecture, the eBPF program, eBPF mapping, and user-space management program are included. The eBPF program runs in the host kernel, while the user-space management program runs in the operating system's user space.

[0027] Based on the dynamic hooking techniques Kprobes / Kretprobes, eBPF programs can be mounted to the function entry or exit points of kernel-mode programs. Based on the dynamic hooking techniques Uprobes / Uretprobes, eBPF programs can be mounted to the function entry or exit points of user-mode applications. Kernel-mode programs refer to programs running in the host kernel, such as the storage protocol stack. User-mode applications refer to programs running in the operating system's user space, such as file system and other storage management programs. Different functions are used to perform different operations. For example, function F21 receives data to be written to the storage system, verifies the data, and outputs the verification result. Function F22 assembles command frames according to the storage protocol.

[0028] After an eBPF program is attached to a function, if that function is called or outputs its results, the eBPF program will be triggered to collect data. Specifically, the data collection logic can be specified in the eBPF program according to actual needs, such as the target data to be collected and the data collection frequency. The eBPF program can differ in different application scenarios; that is, the eBPF program can be developed according to actual requirements.

[0029] The eBPF mapping is a data storage structure for data interaction between eBPF programs and user-space management programs. eBPF programs can write collected data into the eBPF mapping, and user-space management programs can read data collected by the eBPF program from the eBPF mapping and process the data. For example, the user-space management program can statistically analyze the data collected by the eBPF program using daily data and display the results. Or, when the data collected by the eBPF program exceeds a data threshold, the user-space management program can control the storage system according to preset control logic.

[0030] In simple terms, the eBPF program can be viewed as a sensor, primarily used for data acquisition. The user-space management program can be seen as the actual control program, used to process the data acquired by the eBPF program.

[0031] The following describes the current state of the storage system.

[0032] Currently, storage systems can be divided into general-purpose storage systems and custom-designed storage systems. Storage system management can include, but is not limited to, fault location, fault recovery, capacity monitoring and planning, data backup, and performance monitoring.

[0033] Currently, while general-purpose storage systems offer advantages such as low cost and wide applicability, the operational information they return is often of a high dimensionality. Maintenance personnel typically manage these systems by using this high-dimensional operational information as a reference, collecting underlying operational information through data acquisition programs, and then managing the system based on this information. Because maintenance personnel need to perform secondary data collection through these programs, the management efficiency of general-purpose storage systems is relatively low. In contrast, custom storage systems are highly customized. In custom storage systems, the hardware firmware (such as firmware in hard drive controllers and expanders) and various protocol layers of the storage protocol can be highly customized according to the specific application scenario, enabling the storage system to return operational information of a specified dimension. Thus, when managing custom storage systems, maintenance personnel can directly obtain the required operational information from the returned data without needing secondary data collection through programs, significantly improving the management efficiency of the storage system. For ease of understanding, the following example of fault location in a storage system illustrates the difference in operational information returned by general-purpose and custom storage systems.

[0034] Specifically, in general-purpose storage systems, multiple low-level error codes are typically normalized into a single high-dimensional, ambiguous error code. When a system failure occurs, only the high-dimensional error code is returned. Because one high-dimensional error code corresponds to multiple low-level error codes, maintenance personnel cannot directly pinpoint the specific cause of the system failure. Therefore, maintenance personnel can use the high-dimensional error code as a reference, collect low-level operational information of the storage system through an information acquisition program, and locate the specific cause of the system failure based on this information. For example, in general-purpose storage systems, multiple low-level errors such as hardware link disconnection, link negotiation failure, and device response timeout are normalized into a communication interruption. When maintenance personnel receive an error code representing a communication interruption from the storage system, they cannot directly pinpoint the specific cause of the communication interruption; that is, they do not know whether the communication interruption was caused by a hardware link disconnection, a link negotiation failure, or a device response timeout. Therefore, maintenance personnel can use an information acquisition program to collect low-level operational information such as the hardware system status and hard disk controller operation logs of the storage system, and locate the specific cause of the communication interruption based on this information.

[0035] In custom storage systems, the hardware firmware and various protocol layers can be highly customized according to the specific application scenarios, enabling the storage system to return error codes of a specified dimension. This allows maintenance personnel to directly pinpoint the specific cause of system failures based on the returned error codes, eliminating the need for secondary data collection and significantly improving fault location efficiency. For example, in a custom storage system, after customizing the firmware in the hard drive controller, if communication is interrupted due to device response timeout, the hard drive controller can return an error code indicating a timeout. Maintenance personnel can then directly locate the cause of the failure based on this error code, without requiring secondary data collection, thus greatly improving fault location efficiency.

[0036] Based on the above description, this application provides a storage system management method that can directly obtain low-dimensional operational information of a general-purpose storage system during its operation, solving the problem of high-dimensional operational information returned by general-purpose storage systems and low storage system management efficiency in related technologies. The storage system management method can be applied to hosts that need to perform data operations in general-purpose storage systems. Hosts may include, but are not limited to, servers, tablets, laptops, desktop computers, controllers, etc. Specifically, the host may include a user-mode management program. During the operation of the user-mode management program, the storage system management method of this application can be implemented.

[0037] See also Figure 2 This is a flowchart illustrating a storage system management method provided in some embodiments of this application. Figure 2 In this context, the storage system management method includes the following steps:

[0038] Step S201: The monitoring program collects the running data of the storage protocol stack. The monitoring program and the storage protocol stack run in the host kernel. The monitoring program is associated with at least some protocol layers of the storage protocol stack. When a target event occurs in the associated protocol layer, the monitoring program collects the context data of the target event as the running data of the storage protocol stack. The target events are different for different protocol layers.

[0039] In this embodiment, the monitoring program is an eBPF (extended Berkeley Packet Filter) program. The storage protocol stack may include, but is not limited to, NAS (Network Attached Storage) storage protocol stack, SAS (Serial Attached SCSI) storage protocol stack, etc.

[0040] Both the monitoring program and the storage protocol stack run within the host kernel. Each storage protocol can include at least one protocol layer. Each protocol layer can include one or more functions. When a function is called, it performs an operation that matches the logic of the protocol layer. Different functions perform different operations. Based on the dynamic hooking technology Kprobes / Kretprobes, the monitoring program can be attached to the entry or exit point of the target function in the protocol layer. When the target function is called or outputs a result, it indicates that a target event has occurred. At this time, the monitoring program can be triggered to collect the context data of the target event. The context data refers to the data used to characterize the attributes of the target event, such as the time point of the target event, the object ID updated during the target event, and the event ID. For ease of understanding, the following explanation uses the SAS storage protocol stack as an example.

[0041] See also Figure 3 The diagram below is a schematic representation of the architecture of a SAS storage system provided in some embodiments of this application. Figure 3 In this context, the storage system comprises user-space applications and user-mode management programs, the SAS storage protocol stack and monitoring programs running in the kernel, and the hardware layer. For details regarding the monitoring programs and user-mode management programs, please refer to the relevant descriptions above; they will not be repeated here.

[0042] The hardware layer can include, but is not limited to, the hardware and firmware of HBA (Host Bus Adapter), the hardware and firmware of expanders, and the hardware and firmware of hard drives. Specifically, HBA firmware refers to the firmware running in the HBA controller. Expanders are also known as extenders. Expander firmware refers to the firmware running in the expander. Hard drive firmware refers to the firmware running in the hard drive controller.

[0043] Applications can include testing software and regular applications that perform data reading and writing on the storage system. Regular applications can include, but are not limited to, browsers, databases, and other software. Testing software refers to programs used to test the storage system.

[0044] The SAS storage protocol stack consists of the kernel interface layer, block device layer, SCSI driver layer, SCSI middleware layer, SAS transport layer, and HBA driver layer. The functions of each protocol layer are described below.

[0045] Specifically, the kernel interface layer provides a unified storage system access interface for applications, specifically for receiving storage system operation requests from applications. These storage system operation requests may include, but are not limited to, data read / write requests, data migration requests, and disk management requests.

[0046] The block device layer is used for request scheduling, request merging, and partition mapping. For example, it optimizes request order to reduce head seek time. It also merges multiple small requests into a single large request. Furthermore, it maps logical addresses in requests to physical addresses.

[0047] The SCSI driver layer implements a generic driver framework for the SCSI command set, decoupled from specific hardware. For example, it translates block device layer requests into SCSI command description blocks. It also performs SCSI device discovery and initialization.

[0048] The SCSI middleware layer coordinates the higher-level SCSI drivers and the lower-level transport protocols. For example, it scans SCSI devices on the bus. It also manages request queues and controls command concurrency.

[0049] The SAS transport layer handles frame transmission, address management, and link control specific to the SAS storage protocol. For example, it maps SCSI target IDs to SAS addresses. It also performs storage system management. Furthermore, it encapsulates SCSI command description blocks into SAS protocol frames.

[0050] The HBA driver layer controls the SAS host bus adapter hardware and interacts directly with the hardware layer. For example, it transmits SAS frames to the HBA hardware via the PCIe bus. It also loads the HBA firmware, configures RAID functionality, and responds to HBA interrupt signals, performing interrupt handling.

[0051] In each of the aforementioned protocol layers, to implement the functionality of that layer, each layer may include one or more functions. For example, in the kernel interface layer, functions C11 and C12 may be included. Function C11 is used to receive storage system operation requests from applications. Function C12 is used to submit storage system operation requests to the block device layer. As another example, in the block device layer, functions C21 and C22 may be included. Function C21 is used to map logical addresses in a request to physical addresses. Function C22 is used to merge multiple small requests into a large request. As yet another example, in the SCSI driver layer, functions C31, C32, and C33 may be included. Function C31 is used to convert requests from the block device layer into SCSI command description blocks. Function C32 is used to discover SCSI devices. Function C33 is used to initialize SCSI devices.

[0052] In practical applications, based on the management objectives of the storage system, the target functions to be monitored can be determined. Then, using dynamic hooking techniques like Kprobes / Kretprobes, the monitoring program can be attached to the entry or exit point of the target function. When the target function is called or outputs its results, it indicates that a target event has occurred, and the monitoring program can collect the preceding and following file data of the target event. The following example illustrates this.

[0053] For example, suppose we need to perform performance management on a storage system (i.e., performance management is the management objective). After analyzing the functions of each protocol layer, we find the following characteristics:

[0054] Functions based on the HBA driver layer can statistically analyze metrics such as transmission latency, queue depth, interrupt frequency, command completion time, and hardware errors. These metrics can be used to evaluate the performance bottlenecks of the storage system.

[0055] Functions based on the SAS transport layer can be used to statistically analyze metrics such as bit error rate, signal strength, and extender routing latency. These metrics can be used to evaluate the link layer performance of storage systems.

[0056] Functions at the block device layer can be used to measure storage system throughput and request queue wait times. These metrics can be used to evaluate the overall performance of the storage system and identify whether the request scheduling strategy is appropriate.

[0057] Statistical metrics obtained from functions based on the kernel interface layer, SCSI driver layer, and SCSI intermediate layer are either unrelated or only weakly correlated with the performance pressure of the storage system.

[0058] Based on the above analysis, at least some functions in the HBA driver layer, SAS transport layer, and block device layer can be used as target functions, and the monitoring program can be attached to the entry or exit point of these target functions. In this way, after the functions in the HBA driver layer, SAS transport layer, and block device layer are called, the monitoring program can collect context data of the target events, such as interrupt times, start and end times of each command execution, and signal strength at various time points. After the monitoring program writes the collected data into the eBPF mapping, the user-space management program analyzes and processes the data collected by the monitoring program to determine the performance pressure on the storage system.

[0059] For example, suppose we need to perform fault management on a storage system (i.e., fault management is the management objective). After analyzing the functions of each protocol layer, we found the following characteristics of the functions at each protocol layer:

[0060] Functions based on the SCSI middleware layer can retrieve SCSI command failure logs and device response timeout counts. This information can be used to diagnose SCSI protocol parsing errors.

[0061] Functions based on the SAS transport layer can be used to obtain topology change events of the extender. This information can be used to diagnose errors such as link disconnection and extender misconfiguration.

[0062] Functions based on the HBA driver layer can retrieve firmware crash logs. This information can be used to pinpoint the cause of hardware failures.

[0063] Information obtained from functions based on the kernel interface layer, block device layer, and SCSI driver layer is either irrelevant or only marginally relevant to fault location in storage performance.

[0064] Based on the above analysis, at least some functions of the SCSI middleware layer, SAS transport layer, and HBA driver layer can be used as target functions, and the monitoring program can be attached to the entry or exit point of these target functions. In this way, after the functions of the SCSI middleware layer, SAS transport layer, and HBA driver layer are called, the monitoring program can collect context data of the target events, such as firmware crash logs and extender configuration errors. After the monitoring program writes the collected data into the eBPF mapping, the user-space management program analyzes and processes the data collected by the monitoring program to determine the cause of the storage system failure.

[0065] Step S202: Determine the system status of the storage system based on the runtime data of the storage protocol stack.

[0066] Specifically, as described in step S201, after the user-mode management program analyzes and processes the data collected by the monitoring program, it can determine the system status of the storage system. The system status is related to the management objectives of the storage system. For example, if fault management is the management objective, the system status can include whether the storage system is faulty, the cause of the fault, the fault time, and the fault duration. If performance management is the management objective, the system status can include the performance pressure on the storage system and performance pressure trend graphs.

[0067] Step S203: Manage the storage system based on the system status.

[0068] For example, in the event of a storage system failure, the cause of the failure can be analyzed based on data collected by the monitoring program, and then the storage system can be troubleshooted. Another example is that when the storage system is under heavy performance pressure, system performance alarms can be generated to prompt maintenance personnel to address the issue promptly.

[0069] In summary, in the technical solutions of some embodiments of this application, a monitoring program is developed and runs in the host kernel, and the monitoring program is associated with at least a portion of the protocol layers of the storage protocol stack. Thus, when a target event occurs at the associated protocol layer, the monitoring program can collect context data of the target event. This context data can be the underlying operational data of the storage system, or it can reflect the underlying operational state of the storage system, which is equivalent to adding a new channel for collecting underlying operational data in the general-purpose storage system. When the general-purpose storage system only returns high-dimensional data, the underlying operational state of the storage system can be determined based on the data collected by the monitoring program, avoiding secondary data collection by maintenance personnel, thereby greatly improving the management efficiency of the storage system. This solves the problem of low management efficiency in some technologies where the operational information returned by general-purpose storage systems is of high dimensionality.

[0070] Furthermore, this application collects operational data of the storage protocol stack by associating a monitoring program with the protocol layer, without requiring changes to the existing architecture of the general-purpose storage system. For example, it does not require changes to the storage protocol stack architecture or the firmware logic at the hardware layer. Thus, on the one hand, it maintains the advantages of the general-purpose storage system in terms of low cost and wide applicability; on the other hand, it enables the general-purpose storage system to achieve management efficiency comparable to customized management systems.

[0071] In some embodiments, determining the system state of the storage system based on the runtime data of the storage protocol stack may include:

[0072] Obtain the reference system status returned by the storage system;

[0073] Based on the reference system state, the degree of correlation between different protocol layers and the reference system state is determined, and based on the degree of correlation, the weight of the running data corresponding to different protocol layers is determined. The running data weight is used to characterize the importance of the running data collected from different protocol layers in the process of determining the system state.

[0074] Based on the weights of the operational data, the operational data collected from different protocol layers are weighted and fused to obtain the system status.

[0075] Specifically, the reference system state refers to the high-dimensional data originally returned by the storage system. While this high-dimensional data doesn't reflect the underlying operational logic of the storage system, it can indicate the general direction of its state. For example, when the storage system returns an error code indicating a communication interruption, although the specific cause of the interruption cannot be determined, it can be confirmed that the fault is related to communication. Similarly, when the storage system returns an error code indicating excessive performance pressure, although the specific cause of the excessive performance pressure cannot be determined, it can be confirmed that the fault is related to performance pressure. In other words, based on the reference system state returned by the storage system, the initial range of the system state can be determined.

[0076] Based on the reference system state, the degree of correlation between different protocol layers and the reference system state can be determined, and the weight of each protocol layer can be determined according to the degree of correlation. Specifically, if a protocol layer has a high degree of correlation with the reference system state, it can have a high operational data weight; if a protocol layer has a low degree of correlation, it can have a low operational data weight. For example, when the reference system state is a communication failure, the SCSI middleware layer, SAS transport layer, and HBA driver layer can have a high operational data weight, while the kernel interface layer, block device layer, and SCSI driver layer can have a low operational data weight. Similarly, when the reference system state is under excessive storage system performance pressure, the HBA driver layer, SAS transport layer, and block device layer can have a high operational data weight, while the kernel interface layer, SCSI driver layer, and SCSI middleware layer can have a low operational data weight.

[0077] When analyzing and processing the operational data of each protocol layer collected by the monitoring program, we can focus on analyzing the operational data of the protocol layers with larger operational data weights, and use the operational data of the protocol layers with smaller operational data weights as a reference.

[0078] The system state determined based on the runtime data of the storage protocol stack is a sub-state of the reference system state. For example, when the reference system state is a communication failure, the determined sub-state could be a hardware link disconnection or a link negotiation failure. This makes it easier for maintenance personnel to determine the specific cause of the fault.

[0079] In the above embodiments, based on the reference system state returned by the storage system, the correlation between different protocol layers and the reference system state is determined. Based on this correlation, the weights of the operational data corresponding to different protocol layers are determined. Finally, based on these operational data weights, a weighted fusion calculation is performed on the operational data collected from different protocol layers to obtain the system state. This avoids the omission of key information and improves the accuracy of the determined system state.

[0080] In some embodiments, the above-mentioned weighted fusion calculation of operational data collected from different protocol layers based on operational data weights to obtain the system state may include:

[0081] Based on the weight of the running data, at least one protocol layer with a running data weight higher than the first weight threshold is identified, and the running data collected from at least one protocol layer is weighted and fused to obtain the system state.

[0082] Specifically, in this embodiment, it is equivalent to removing protocol layer operational data with lower operational data weight and determining the system state based on protocol layer operational data with higher operational data weight. This significantly reduces the amount of data processing, improves data processing efficiency, and consequently enhances the management efficiency of the storage system.

[0083] In some embodiments, determining the system state of the storage system based on runtime data from the storage protocol stack may include:

[0084] Obtain the reference system state returned by the storage system, wherein the system state determined based on the runtime data of the storage protocol stack is a sub-state of the reference system state;

[0085] Based on the reference system state, the degree of correlation between each target event and the reference system state is determined, and based on the degree of correlation, the context data weights corresponding to different target events are determined. The context data weights are used to characterize the importance of the context data of different target events in the process of determining the system state.

[0086] Based on the context data weights, the context data of different target events are weighted and fused to obtain the system state.

[0087] Among them, the system state is obtained by weighted fusion calculation of the context data of different target events based on context data weights, which may include:

[0088] Based on the context data weights, at least one target event with a context data weight higher than the second weight threshold is found, and the system state is obtained by weighted fusion calculation of the context data from the at least one target event.

[0089] Specifically, the context data weights corresponding to the target events are basically similar to the runtime data weights of the aforementioned protocol layers. The main difference is that this embodiment filters runtime data based on the correlation between the target event and the reference system state. This further improves the accuracy of runtime data used to determine the system state. For example, when the reference system state is a communication failure, although the SCSI middleware layer, SAS transport layer, and HBA driver layer are all highly correlated with the communication failure, some target events in these layers may not have a high correlation. If the runtime data weights of the protocol layers are used, the context data of these target events cannot be eliminated, or their weights reduced. This would increase the data processing volume, affecting data processing efficiency, or cause the omission of key information due to excessive data processing, thus affecting the accuracy of the determined system state. Furthermore, when the reference system state is a communication failure, although the kernel interface layer, SCSI driver layer, and SCSI middleware layer have a low correlation with the communication failure, a small number of target events in these protocol layers may have a high correlation. If the runtime data weights of the protocol layer are used, the context data of these target events may be missed, or the context data of these target events may not be assigned a high weight, thus affecting the accuracy of the determined system state.

[0090] Therefore, in this embodiment, the context data weight of the target event is determined based on the degree of correlation between the context data of the target event and the reference system state. Based on these context data weights, a weighted fusion calculation is performed on the context data of different target events to obtain the system state. In this way, on the one hand, context data of target events with a lower correlation to the reference operating state can be further removed from protocol layer operational data that has a strong correlation with the reference operating state, or these target events' context data can be assigned lower weights. On the other hand, context data of target events with a strong correlation to the reference operating state can be assigned higher weights from protocol layer operational data that has a weak correlation to the reference initial state. This ensures the accuracy of the operational data used to determine the system state, thereby improving system management efficiency and the accuracy of the determined system state.

[0091] In some embodiments, determining the system state of the storage system based on the runtime data of the storage protocol stack may include:

[0092] Based on the operational data of the storage protocol stack during the target historical period, predict the system state of the storage system in the future target period.

[0093] Specifically, managing the storage system based on system status can include:

[0094] If the storage system is in the first system state in the future target time period, then a first management policy for the first system state is determined. The first management policy is used to prevent the storage system from changing to the first system state.

[0095] The storage system is managed based on the first management strategy.

[0096] Specifically, the operational data of the storage protocol stack during the target historical period can be input into a trained neural network model. The neural network model can then predict the system state of the storage system in the future target period. Neural network models have good non-linearity capture capabilities, and using them to predict system states can improve the accuracy of the determined system states.

[0097] By predicting the storage system's state in a future target time period, proactive management of the storage system is possible. For example, the first system state could be a communication failure. If a communication failure is predicted for the storage system in the future target time period, the causes can be avoided in advance, such as prompting maintenance personnel to modify the storage system's hardware links. This can prevent communication failures in the future target time period, thereby improving the stability and reliability of the storage system. Another example is excessive performance pressure. If excessive performance pressure is predicted for the storage system in the future target time period, data operation requests allocated to the storage system can be reduced before the target time period, thus avoiding excessive performance pressure.

[0098] In the above embodiments, based on the operating data of the storage protocol stack during the target historical period, the system state of the storage system in the future target period can be predicted. In this way, the system state of the storage system can be controlled in advance to avoid the storage system from having an unwanted system state and to ensure the reliability and stability of the storage system.

[0099] In some embodiments, if the storage system's system state is a first system state during a future target time period, the duration of the storage system remaining in the first system state can be predicted. If the duration exceeds a duration threshold, the storage system will then be managed based on a first management strategy. For example, if it is predicted that the storage system may experience a brief communication outage during a future target time period, since the duration of such an outage is relatively short, management of the storage system may not be necessary based on this outage; that is, the storage system can be allowed to experience a brief communication outage during the future target time period. This avoids the instability of the storage system caused by frequent management.

[0100] In some embodiments, determining the system state of the storage system based on the runtime data of the storage protocol stack may include:

[0101] Based on the operational data of the storage protocol stack in the current time period, determine the system state of the storage system in the current time period.

[0102] Specifically, managing the storage system based on system status can include:

[0103] If the storage system is in the second system state at the current time, the duration of the second system state is predicted based on the operation data of the storage protocol stack.

[0104] If the duration of the second system state is greater than the duration threshold, a second management strategy is determined for the second system state. The second management strategy is used to transition the storage system from the second system state to the third system state.

[0105] The storage system is managed based on the second management strategy.

[0106] Specifically, the principle of managing the storage system based on the second management strategy when the duration of the second system state exceeds the duration threshold is similar to managing the storage system based on the first management strategy when the duration of the storage system in the first system state exceeds the duration threshold during a future target period. This will not be elaborated here.

[0107] See also Figure 4 The diagram below is a schematic representation of the architecture of a SAS storage system provided in some embodiments of this application. Figure 4 and Figure 3 They are basically similar, with the main differences being: Figure 4 The applications may include system management programs for the storage system, testing software, regular applications for reading and writing data in the storage system, and information collection programs for collecting information from the storage system. For details on regular applications and testing software, please refer to [link to relevant documentation]. Figure 3 Related descriptions will not be repeated here. The following describes the system management program and information collection program.

[0108] System management programs can include, but are not limited to, file systems, multipathing software, and RAID (Redundant Array of Independent Disks) programs. Understandably, these system management programs manage the storage system and also affect its system state. For example, if multipathing software's management strategy is inaccurate when managing the physical paths of the storage system, it may cause communication failures and other problems.

[0109] Therefore, in some embodiments, determining the system state of the storage system based on the runtime data of the storage protocol stack may include:

[0110] The system monitors at least a portion of the system management program's runtime data.

[0111] The system status of the storage system is determined by integrating and calculating the runtime data of the storage protocol stack and the runtime data of the system management program.

[0112] Specifically, a system management program can include multiple functions. Based on the dynamic mounting technology Uprobes / Uretprobes, monitoring programs can be mounted to the entry or exit points of at least some of the functions in the system management program.

[0113] In the above embodiments, the operation data of the storage protocol stack and the operation data of the system management program are fused and calculated. The system management program's management strategy for the storage system can be referenced at the same time, thereby improving the accuracy of the determined system state.

[0114] Information acquisition programs can include, but are not limited to, the `sg_utils` program, the `smp_utils` program, and the `smartctl` program. Different information acquisition programs can be used to collect different low-level operational information of the hardware layer. For example, the `sg_utils` program can be used to collect hard disk capacity and determine whether the storage system has been interrupted. The `smp_utils` program can be used to collect the topology information of the storage system, the basic device information of the extender, the bit error rate of the storage system, signal quality, etc. The `smartctl` program can be used to collect firmware operation logs of the hardware layer. These firmware operation logs of the hardware layer can only be indirectly reflected through the operational data of the storage protocol stack. For example, based on the operational data of the storage protocol stack, it can be inferred that a certain hard disk in the storage system may be damaged, but specific hard disk operational information cannot be obtained. In view of this, the above-mentioned management of the storage system based on system status can include:

[0115] If the system status is the fourth system status, then the information acquisition program is invoked to collect at least some of the device information of the storage system;

[0116] Based on device information and storage protocol stack operation data, a third management strategy is determined for the fourth system state;

[0117] The storage system is managed based on a third management strategy.

[0118] Specifically, the fourth system state can refer to a state related to the underlying hardware of the storage system. For example, a hardware failure could cause read / write failures in the storage system. Since the fourth system state is related to the underlying hardware of the storage system, and the operational data from the storage protocol stack can only provide a rough estimate of potential hardware problems, an information acquisition program can be invoked to collect at least some device information from the storage system. Based on this information, the underlying hardware problems can be accurately assessed. Furthermore, based on the device information and the operational data from the storage protocol stack, a more accurate third management strategy can be determined for the fourth system state, thereby improving the accuracy of the storage system's management strategy.

[0119] In some embodiments, the above-mentioned management of the storage system based on management policies may include:

[0120] Based on management strategies, at least a portion of the system management program is controlled to manage the storage system through the system management program.

[0121] For example, when it is determined that the hardware link allocation strategy of the storage system needs to be adjusted based on the management strategy, the multipath software of the storage system can be controlled to adjust the hardware link allocation strategy, thereby ensuring the accuracy of the storage system strategy.

[0122] Based on the above description, it can be understood that the user-mode management program of this application, based on the data collected by the monitoring program, can perform linkage control on the information collection program and the system management program, thereby improving the management flexibility of the storage system.

[0123] In some embodiments, the monitoring program includes multiple sub-monitoring programs, wherein: each sub-monitoring program corresponds one-to-one with a protocol layer, and each sub-monitoring program is used to collect the runtime data of its corresponding protocol layer; or, each sub-monitoring program corresponds one-to-one with a target event, and each sub-monitoring program is used to collect the context data of its corresponding target event, wherein each protocol layer has one or more target events. Simply put, a separate sub-monitoring program can be developed for each protocol layer or each target event (i.e., function), and the sub-monitoring programs are decoupled from each other. Thus, as actual business needs change, updating the data collection logic of one sub-monitoring program will not affect the other sub-monitoring programs.

[0124] In some embodiments, collecting runtime data of the storage protocol stack through a monitoring program may include:

[0125] Based on the management objectives of the storage system, determine the target operational data that needs to be collected;

[0126] Based on the target operational data, determine the target sub-monitoring program that needs to be run;

[0127] Controls the execution of the target sub-monitoring program and stops the execution of other sub-monitoring programs besides the target sub-monitoring program.

[0128] Specifically, the user-mode management program can control the operation of sub-monitoring programs by loading them, and can also control the sub-monitoring programs to stop running by uninstalling them.

[0129] In this embodiment, multiple sub-monitoring programs can be developed to address multiple management objectives. For example, a first set of sub-monitoring programs can be developed for fault management of the storage system, and a second set of sub-monitoring programs can be developed for performance management of the storage system. When the management objective is fault management, the user-space management program can load the first set of sub-monitoring programs, enabling the sub-monitoring programs to collect protocol layer operational data related to fault management. When the management objective is performance management, the user-space management program can load the second set of sub-monitoring programs, enabling the sub-monitoring programs to collect protocol layer operational data related to performance management.

[0130] In the above embodiments, based on the management objectives of the storage system, the sub-monitoring program is selectively run. On the one hand, this can reduce the amount of data collected and reduce system pressure; on the other hand, it can reduce bandwidth consumption during data transmission.

[0131] In some embodiments, the method of this application further includes:

[0132] After obtaining the runtime data of the storage protocol stack, the runtime data is statistically processed according to the preset data processing dimensions, and the resulting dimensional data is displayed.

[0133] And / or, after obtaining the system status of the storage system, display the system status.

[0134] And / or, after obtaining the running data of the storage protocol stack, if the obtained dimension data exceeds the dimension data threshold after statistical processing of the running data according to the preset data processing dimensions, the first alarm will be issued.

[0135] And / or, after obtaining the system status of the storage system, if the system status indicates that the storage system has failed, a second alarm is issued.

[0136] And / or, invoke the information acquisition program to collect at least some device information of the storage system;

[0137] Based on device information, storage protocol stack operation data, and system status, a topology diagram of the storage system is displayed.

[0138] This makes it easier for maintenance personnel to check the system's operating status.

[0139] In summary, in the technical solutions of some embodiments of this application, a monitoring program is developed and runs in the host kernel, and the monitoring program is associated with at least a portion of the protocol layers of the storage protocol stack. Thus, when a target event occurs at the associated protocol layer, the monitoring program can collect context data of the target event. This context data can be the underlying operational data of the storage system, or it can reflect the underlying operational state of the storage system, which is equivalent to adding a new channel for collecting underlying operational data in the general-purpose storage system. When the general-purpose storage system only returns high-dimensional data, the underlying operational state of the storage system can be determined based on the data collected by the monitoring program, avoiding secondary data collection by maintenance personnel, thereby greatly improving the management efficiency of the storage system. This solves the problem of low management efficiency in some technologies where the operational information returned by general-purpose storage systems is of high dimensionality.

[0140] Furthermore, this application collects operational data of the storage protocol stack by associating a monitoring program with the protocol layer, without requiring changes to the existing architecture of the general-purpose storage system. For example, it does not require changes to the storage protocol stack architecture or the firmware logic at the hardware layer. Thus, on the one hand, it maintains the advantages of the general-purpose storage system in terms of low cost and wide applicability; on the other hand, it enables the general-purpose storage system to achieve management efficiency comparable to customized management systems.

[0141] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of a program plus the necessary general-purpose hardware platform. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0142] See also Figure 5 This is a schematic diagram of a storage system management device provided in some embodiments of this application. Figure 5 In this context, the storage system management device includes:

[0143] The data acquisition module 501 is used to collect the running data of the storage protocol stack through the monitoring program. The monitoring program and the storage protocol stack run in the host kernel. The monitoring program is associated with at least some protocol layers of the storage protocol stack, and when a target event occurs in the associated protocol layer, it collects the context data of the target event as the running data of the storage protocol stack. The target events are different for different protocol layers.

[0144] The system status determination module 502 is used to determine the system status of the storage system based on the running data of the storage protocol stack.

[0145] System management module 503 is used to manage the storage system based on system status.

[0146] In some embodiments, the system state determination module 502 is specifically used for:

[0147] Obtain the reference system state returned by the storage system, wherein the system state determined based on the runtime data of the storage protocol stack is a sub-state of the reference system state;

[0148] Based on the reference system state, the degree of correlation between different protocol layers and the reference system state is determined, and based on the degree of correlation, the weight of the running data corresponding to different protocol layers is determined. The running data weight is used to characterize the importance of the running data collected from different protocol layers in the process of determining the system state.

[0149] Based on the weights of the operational data, the operational data collected from different protocol layers are weighted and fused to obtain the system status.

[0150] In some embodiments, the system state determination module 502 is specifically used for:

[0151] Based on the weight of the running data, at least one protocol layer with a running data weight higher than the first weight threshold is identified, and the running data collected from at least one protocol layer is weighted and fused to obtain the system state.

[0152] In some embodiments, the system state determination module 502 is specifically used for:

[0153] Obtain the reference system state returned by the storage system, wherein the system state determined based on the runtime data of the storage protocol stack is a sub-state of the reference system state;

[0154] Based on the reference system state, the degree of correlation between each target event and the reference system state is determined, and based on the degree of correlation, the context data weights corresponding to different target events are determined. The context data weights are used to characterize the importance of the context data of different target events in the process of determining the system state.

[0155] Based on the context data weights, the context data of different target events are weighted and fused to obtain the system state.

[0156] In some embodiments, the system state determination module 502 is specifically used for:

[0157] Based on the context data weights, at least one target event with a context data weight higher than the second weight threshold is found, and the system state is obtained by weighted fusion calculation of the context data from the at least one target event.

[0158] In some embodiments, the storage system has at least one system management program; the system status determination module 502 is specifically used for:

[0159] The system monitors at least a portion of the system management program's runtime data.

[0160] The system status of the storage system is determined by integrating and calculating the runtime data of the storage protocol stack and the runtime data of the system management program.

[0161] In some embodiments, the system state determination module 502 is specifically used for:

[0162] Based on the operational data of the storage protocol stack during the target historical period, predict the system state of the storage system in the future target period;

[0163] Alternatively, the system status of the storage system in the current time period can be determined based on the operational data of the storage protocol stack in the current time period.

[0164] In some embodiments, the system management module 503 is specifically used for:

[0165] If the storage system is in the first system state in the future target time period, then a first management policy for the first system state is determined. The first management policy is used to prevent the storage system from changing to the first system state.

[0166] The storage system is managed based on the first management strategy.

[0167] In some embodiments, the system management module 503 is specifically used for:

[0168] If the storage system is in the second system state at the current time, the duration of the second system state is predicted based on the operation data of the storage protocol stack.

[0169] If the duration of the second system state is greater than the duration threshold, a second management strategy is determined for the second system state. The second management strategy is used to transition the storage system from the second system state to the third system state.

[0170] The storage system is managed based on the second management strategy.

[0171] In some embodiments, the system management module 503 is specifically used for:

[0172] If the system status is the fourth system status, then the information acquisition program is invoked to collect at least some of the device information of the storage system;

[0173] Based on device information and storage protocol stack operation data, a third management strategy is determined for the fourth system state;

[0174] The storage system is managed based on a third management strategy.

[0175] In some embodiments, the storage system has at least one system management program; the system management module 503 is specifically used for:

[0176] Based on management strategies, at least a portion of the system management program is controlled to manage the storage system through the system management program.

[0177] In some embodiments, the monitoring program includes multiple sub-monitoring programs, wherein each sub-monitoring program corresponds one-to-one with a protocol layer, and each sub-monitoring program is used to collect the operation data of the corresponding protocol layer; or, each sub-monitoring program corresponds one-to-one with a target event, and each sub-monitoring program is used to collect the context data of the corresponding target event, wherein each protocol layer has one or more target events.

[0178] In some embodiments, the data acquisition module 501 is specifically used for:

[0179] Based on the management objectives of the storage system, determine the target operational data that needs to be collected;

[0180] Based on the target operational data, determine the target sub-monitoring program that needs to be run;

[0181] Controls the execution of the target sub-monitoring program and stops the execution of other sub-monitoring programs besides the target sub-monitoring program.

[0182] In some embodiments, the data acquisition module 501 is further configured to:

[0183] After obtaining the runtime data of the storage protocol stack, the runtime data is statistically processed according to the preset data processing dimensions, and the resulting dimensional data is displayed.

[0184] And / or, after obtaining the system status of the storage system, display the system status.

[0185] In some embodiments, the data acquisition module 501 is further configured to:

[0186] After obtaining the runtime data of the storage protocol stack, if the obtained dimension data exceeds the dimension data threshold after statistical processing of the runtime data according to the preset data processing dimensions, the first alarm will be issued.

[0187] And / or, after obtaining the system status of the storage system, if the system status indicates that the storage system has failed, a second alarm is issued.

[0188] In some embodiments, the data acquisition module 501 is further configured to:

[0189] The information collection program is invoked to collect at least some device information from the storage system.

[0190] Based on device information, storage protocol stack operation data, and system status, a topology diagram of the storage system is displayed.

[0191] In summary, in the storage system management apparatus of some embodiments of this application, a monitoring program runs in the host kernel and is associated with at least a portion of the protocol layers of the storage protocol stack. Thus, when a target event occurs at the associated protocol layer, the monitoring program can collect context data of the target event. This context data can be the underlying operational data of the storage system, or it can reflect the underlying operational state of the storage system, effectively adding a new channel for collecting underlying operational data to the general-purpose storage system. When the general-purpose storage system only returns high-dimensional data, the underlying operational state of the storage system can be determined based on the data collected by the monitoring program, avoiding secondary data collection by maintenance personnel and significantly improving the management efficiency of the storage system. This solves the problem of low management efficiency in some technologies where the operational information returned by general-purpose storage systems is of high dimensionality.

[0192] Furthermore, this application collects operational data of the storage protocol stack by associating a monitoring program with the protocol layer, without requiring changes to the existing architecture of the general-purpose storage system. For example, it does not require changes to the storage protocol stack architecture or the firmware logic at the hardware layer. Thus, on the one hand, it maintains the advantages of the general-purpose storage system in terms of low cost and wide applicability; on the other hand, it enables the general-purpose storage system to achieve management efficiency comparable to customized management systems.

[0193] See also Figure 6 Embodiments of this application also provide an electronic device, including a memory 10 and a processor 20, wherein the memory 10 stores a computer program and the processor 20 is configured to run the computer program to perform the steps in any of the above-described communication method embodiments.

[0194] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described communication method embodiments when it is run.

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

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

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

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

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

Claims

1. A storage system management method, characterized in that, The method includes: The monitoring program collects the runtime data of the storage protocol stack. The monitoring program and the storage protocol stack run in the host kernel. The monitoring program is associated with at least some protocol layers of the storage protocol stack. When a target event occurs in the associated protocol layer, the monitoring program collects the context data of the target event as the runtime data of the storage protocol stack. The target events are different for different protocol layers. Based on the operational data of the storage protocol stack, the system state of the storage system is determined; The storage system is managed based on the system status. The monitoring program includes multiple sub-monitoring programs, among which: Each sub-monitoring program corresponds one-to-one with a protocol layer, and each sub-monitoring program is used to collect the running data of the corresponding protocol layer; Alternatively, the sub-monitoring program corresponds one-to-one with the target event, and each sub-monitoring program is used to collect context data of the corresponding target event, wherein each protocol layer has one or more target events; The process of collecting operational data from the storage protocol stack through a monitoring program includes: Based on the management objectives of the storage system, determine the target operational data that needs to be collected; Based on the target operation data, determine the target sub-monitoring program that needs to be run; Control the operation of the target sub-monitoring program, and control the operation of other sub-monitoring programs besides the target sub-monitoring program to stop.

2. The method according to claim 1, characterized in that, Determining the system state of the storage system based on the operational data of the storage protocol stack includes: Obtain the reference system state returned by the storage system, wherein the system state determined based on the operating data of the storage protocol stack is a sub-state of the reference system state; Based on the reference system state, the degree of correlation between different protocol layers and the reference system state is determined, and based on the degree of correlation, the weight of the running data corresponding to different protocol layers is determined. The weight of the running data is used to characterize the importance of the running data collected from different protocol layers during the system state determination process. Based on the weighted operational data, the operational data collected from different protocol layers are weighted and fused to obtain the system state.

3. The method according to claim 2, characterized in that, The process of weighting and fusing operational data collected from different protocol layers based on the operational data weights to obtain the system state includes: Based on the operational data weights, at least one protocol layer with an operational data weight higher than a first weight threshold is identified, and the operational data collected from the at least one protocol layer is weighted and fused to obtain the system state.

4. The method according to claim 1, characterized in that, Determining the system state of the storage system based on the operational data of the storage protocol stack includes: Obtain the reference system state returned by the storage system, wherein the system state determined based on the operating data of the storage protocol stack is a sub-state of the reference system state; Based on the reference system state, the degree of correlation between each target event and the reference system state is determined, and based on the degree of correlation, the context data weights corresponding to different target events are determined. The context data weights are used to characterize the importance of the context data of different target events in the process of determining the system state. Based on the context data weights, the context data of different target events are weighted and fused to obtain the system state.

5. The method according to claim 4, characterized in that, The process of weighted fusion calculation of context data for different target events based on the context data weights to obtain the system state includes: Based on the context data weights, at least one target event with a context data weight higher than a second weight threshold is found, and the system state is obtained by weighted fusion calculation of the context data from the at least one target event.

6. The method according to claim 1, characterized in that, The storage system has at least one system management program; determining the system state of the storage system based on the runtime data of the storage protocol stack includes: The monitoring program collects operational data from at least a portion of the system management programs. The system state of the storage system is determined by fusing and calculating the runtime data of the storage protocol stack and the runtime data of the system management program.

7. The method according to claim 1, characterized in that, Determining the system state of the storage system based on the operational data of the storage protocol stack includes: Based on the operational data of the storage protocol stack during the target historical period, predict the system state of the storage system in the future target period; Alternatively, the system state of the storage system in the current time period can be determined based on the operating data of the storage protocol stack in the current time period.

8. The method according to claim 7, characterized in that, The management of the storage system based on the system state includes: If the storage system is in a first system state during the future target time period, a first management strategy is determined for the first system state. The first management strategy is used to prevent the storage system from changing to the first system state. The storage system is managed based on the first management strategy.

9. The method according to claim 7, characterized in that, The management of the storage system based on the system state includes: If the storage system is in the second system state during the current time period, the duration of the second system state is predicted based on the operating data of the storage protocol stack. If the duration of the second system state is greater than the duration threshold, a second management strategy is determined for the second system state. The second management strategy is used to change the storage system from the second system state to the third system state. The storage system is managed based on the second management strategy.

10. The method according to claim 1, characterized in that, The management of the storage system based on the system state includes: If the system state is the fourth system state, then the information acquisition program is invoked to collect at least some of the device information of the storage system; Based on the device information and the operating data of the storage protocol stack, a third management strategy is determined for the fourth system state; The storage system is managed based on the third management strategy. The fourth system state refers to the state related to the underlying hardware of the storage system.

11. The method according to any one of claims 8 to 10, characterized in that, The storage system has at least one system management program; The storage system is managed based on a management strategy, including: Based on the management strategy, at least a portion of the system management program is controlled to manage the storage system through the system management program.

12. The method according to claim 1, characterized in that, The method further includes: After obtaining the running data of the storage protocol stack, the running data is statistically processed according to the preset data processing dimensions, and the processed dimension data is displayed. And / or, after obtaining the system status of the storage system, display the system status.

13. The method according to claim 1, characterized in that, The method further includes: After obtaining the running data of the storage protocol stack, if the dimensional data obtained after statistical processing of the running data according to the preset data processing dimensions exceeds the dimensional data threshold, then a first alarm is issued. And / or, after obtaining the system status of the storage system, if the system status indicates that the storage system has failed, a second alarm is issued.

14. The method according to claim 1, characterized in that, The method further includes: The information acquisition program is invoked to collect at least some device information of the storage system; Based on the device information, the operating data of the storage protocol stack, and the system status, a topology diagram of the storage system is displayed.

15. A storage system management device, characterized in that, The device includes: The data acquisition module is used to collect the running data of the storage protocol stack through a monitoring program. The monitoring program and the storage protocol stack run in the host kernel. The monitoring program is associated with at least some protocol layers of the storage protocol stack. When a target event occurs in the associated protocol layer, the monitoring program collects the context data of the target event as the running data of the storage protocol stack. The target events are different for different protocol layers. The system status determination module is used to determine the system status of the storage system based on the operating data of the storage protocol stack. The system management module is used to manage the storage system based on the system status; The monitoring program includes multiple sub-monitoring programs, among which: Each sub-monitoring program corresponds one-to-one with a protocol layer, and each sub-monitoring program is used to collect the running data of the corresponding protocol layer; Alternatively, the sub-monitoring program corresponds one-to-one with the target event, and each sub-monitoring program is used to collect context data of the corresponding target event, wherein each protocol layer has one or more target events; The data acquisition module is specifically used for: Based on the management objectives of the storage system, determine the target operational data that needs to be collected; Based on the target operational data, determine the target sub-monitoring program that needs to be run; Controls the execution of the target sub-monitoring program and stops the execution of other sub-monitoring programs besides the target sub-monitoring program.

16. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for implementing the storage system management method as described in any one of claims 1 to 14 when executing the computer program.

17. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the storage system management method as described in any one of claims 1 to 14.

18. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the storage system management method as described in any one of claims 1 to 14.

Images