Firmware update system and method for determining the likelihood of failures occurring during firmware updates

Abstract

This invention provides a firmware update system that allows administrators to determine whether problems caused by firmware updates occur in the storage system, and a method for determining the likelihood of failures occurring due to firmware updates. [Solution] In a firmware update system, the storage system includes: a failure information request unit that acquires firmware failure information including information on failures that may occur in the storage system in conjunction with a firmware update and the conditions for such failures to occur; a failure occurrence possibility determination unit that compares the conditions for occurrence in the firmware failure information with the configuration information and operation history of the storage system and determines the possibility of failure occurring, which is the possibility of a failure occurring in the storage system due to a firmware update, based on the comparison result; and a message output unit that outputs the result of the failure occurrence possibility determination.

Description

Technical Field

[0001] The present invention relates to a firmware update system and a method for determining the possibility of occurrence of a failure associated with firmware update.

Background Art

[0002] Firmware used for overall control and various hardware controls in a storage system or the like is preferably kept at the latest version from the viewpoints of supporting new functions and troubleshooting. The storage system updates to the latest version by downloading and self-updating the firmware of the new version from a server that provides the firmware via a communication network every time a new version of the firmware is released.

[0003] By updating the firmware of the newly released version without delay when a new version is released, it is possible to avoid the occurrence of defects addressed in that version.

[0004] Patent Document 1 discloses associating a failure occurring in a device device with the firmware update time, registering them in advance in a download description table of a server device, and when the firmware update is instructed from the server device, the device device acquires the download description table from the server device, collates the record of the failure that has occurred in itself with the download description table, and if the failure that has occurred in itself is registered in the download description table, updates the firmware at a timing based on the update time associated with that failure.

Prior Art Documents

Patent Documents

[0005]

Patent Document 1

Summary of the Invention

[0006] Between the time a failure or malfunction occurs in the storage system and the time when a firmware update incorporating countermeasures and new features is provided, there is a risk that similar failures or malfunctions may occur in a chain reaction among users who are unaware of the previous failure or malfunction. Therefore, measures to prevent the occurrence of new failures or malfunctions are desirable.

[0007] On the other hand, administrators of storage systems that do not necessarily require these countermeasures or new features may be concerned about the emergence of new system operational problems due to firmware updates and may prefer to continue using the currently running firmware.

[0008] Storage systems, which are particularly crucial to IT infrastructure, are required to operate continuously without interruption. Therefore, opportunities to update firmware are limited, such as during periods when the storage system is not in use for hardware maintenance, and frequent firmware updates are undesirable from an operational standpoint.

[0009] This invention has been made in view of the above problems, and aims to enable administrators to understand whether problems caused by firmware updates of a storage system occur in the storage system, and to enable them to quickly perform necessary firmware updates. [Means for solving the problem]

[0010] To solve these problems, the present invention provides a firmware update system for a storage system comprising a processor, memory, and one or more storage devices, which manages the update status of firmware read from memory to the processor and executed, comprising: a failure information request unit that acquires firmware failure information including information on failures that may occur in the storage system in connection with a firmware update and information on the conditions for the occurrence of such failures; a failure occurrence possibility determination unit that compares the conditions for occurrence in the firmware failure information with the configuration information and operation history of the storage system and determines the possibility of failure occurring, which is the possibility that a failure will occur in the storage system due to a firmware update, based on the comparison result; and an output unit that outputs the failure occurrence possibility determination result. [Effects of the Invention]

[0011] According to the present invention, it is possible to determine whether a failure has affected the operating firmware and whether it is necessary to update the firmware, based on the usage status of the storage system. [Brief explanation of the drawing]

[0012] [Figure 1] This figure illustrates a system concept diagram of a firmware update system in an embodiment of the present invention. [Figure 2] This is an example of a block diagram showing the configuration of a firmware maintenance server in an embodiment of the present invention. [Figure 3] This is an example of a block diagram showing the configuration of a storage system in an embodiment of the present invention. [Figure 4] This is an example of a table diagram showing received fault information in an embodiment of the present invention. [Figure 5] This is an example of a table diagram showing the conditions for occurrence in an embodiment of the present invention. [Figure 6] This is an example of a table diagram showing hardware and logical configuration information in an embodiment of the present invention. [Figure 7] This is an example of a table diagram showing the operating software configuration information in an embodiment of the present invention. [Figure 8] This is an example of a table diagram showing the operating firmware information in an embodiment of the present invention. [Figure 9] This is an example of a table diagram showing the operation history information in an embodiment of the present invention. [Figure 10] This is an example of a table diagram showing the performance information in an embodiment of the present invention. [Figure 11] This is an example of a flowchart showing the failure occurrence possibility determination process in an embodiment of the present invention. [Figure 12] This is an example of a flowchart showing the comparison process of failure information and usage history in an embodiment of the present invention. [Figure 13] This is an example of the influence determination result (Example 1) in an embodiment of the present invention. [Figure 14] This is an example of the influence determination result (Example 2) in an embodiment of the present invention. [Figure 15] This is an example of a flowchart showing the processing of the message output unit in an embodiment of the present invention. [Figure 16] This is an example of an output screen in an embodiment of the present invention.

Mode for Carrying Out the Invention

[0013] Hereinafter, embodiments of the present invention will be described with reference to the drawings. In each of the drawings for explaining the embodiments, the same components are given the same names and reference numerals as much as possible, and the repeated description thereof is omitted.

[0014] The present invention is not limited to the embodiments described below, and includes various modifications and equivalent configurations within the scope of the appended claims. For example, the above-described embodiments have been described in detail for the sake of easy understanding of the present invention, and the present invention is not necessarily limited to those having all the configurations described. [[ID=ID=39]]

[0015] Furthermore, the processing units described in the embodiment may be implemented in hardware, for example, by designing some or all of them as integrated circuits, or they may be implemented in software by having a processor interpret and execute programs that realize each of their respective functions.

[0016] The tables, areas, etc., described in the examples may be databases (DBs) or data stored in main memory. [Examples]

[0017] Figure 1 illustrates a conceptual system diagram of a firmware update system in an embodiment of the present invention.

[0018] This firmware update system comprises a firmware maintenance server 1, two storage systems 2 (storage system A2A, storage system B2B), and a maintenance terminal 5. The firmware maintenance server 1 and storage systems A2A and B2B are connected by a network 4 consisting of, for example, the internet or Ethernet (registered commercial).

[0019] Furthermore, the maintenance terminal 5 is connected to the storage system B2B by a management network (not shown) consisting of, for example, Fibre Channel, Ethernet®, or LAN (Local Area Network). However, the network 4 and the management network may be composed of the same network. Also, in this embodiment, the storage system 2 may be configured to include three or more units.

[0020] The firmware maintenance server 1 stores firmware executed on the storage system 2 by version and provides firmware based on requests from the storage system 2 or the maintenance terminal 5. The firmware maintenance server 1 also stores information regarding firmware-related failures that occur in the storage system 2 (hereinafter referred to as failure information) and provides the relevant failure information in response to requests from the storage system 2 or the maintenance terminal 5.

[0021] Storage system 2 provides a logical device for reading and writing data to a host (not shown), and performs data read / write operations to the logical device in response to requests from the host via network 4. Storage system 2 also downloads and installs or updates firmware from firmware maintenance server 1 and executes it as a function of storage system 2. Furthermore, storage system 2 requests the firmware maintenance server 1 to send fault information in response to instructions from maintenance terminal 5, and performs a determination of the possibility of a fault occurring based on the received fault information, as described later. Hereafter in this embodiment, storage system A2A of storage system 2 will be described as having a firmware-related fault, while storage system B2B will be described as having normal firmware operation.

[0022] Maintenance terminal 5 is connected to storage system 2 via a management network and manages the control operations and fault information of storage system 2. Maintenance terminal 5 also instructs storage system 2 to send fault information to firmware maintenance server 1 and outputs the results of the fault probability assessment performed on storage system 2. Maintenance terminal 5 is connected to an input device (keyboard, mouse, card reader, touch panel, etc.), which is a user interface that accepts information input from the user, and an output device (for example, a display device that visualizes various information (LCD (Liquid Crystal Display), graphics card, etc.), an audio output device (speaker), a printing device, etc.), which is a user interface that outputs the fault probability assessment results. In this embodiment, the maintenance terminal 5 is connected only to storage system B2B, but maintenance terminals 5 may also be provided and connected to other storage systems 2, or one maintenance terminal 5 may be connected to multiple storage systems 2.

[0023] If a firmware failure occurs in storage system 2A, for example, the administrator of the firmware that received the failure report will analyze the failure situation, and if it is determined that the failure is firmware-related, it will be registered as failure information, including the conditions under which it occurred, in firmware maintenance server 1. Once a corrected firmware version addressing this failure is completed, the corrected version will also be stored, associated with the failure.

[0024] If a corrective version is being developed, the firmware maintenance server 1 registers the failure information, including the failure symptoms, operational workarounds, and the release schedule for the corrective version. The maintenance personnel for the storage system B2B check the maintenance terminal 5 for updates to the failure information and retrieve any updates. Based on the updated information, the maintenance personnel can check whether a firmware failure related to the storage system B2B they are responsible for has occurred. The check for updates to the failure information may be performed periodically, in which case the check frequency can be set according to the system's operational status.

[0025] Figure 2 is an example of a block diagram showing the configuration of the firmware maintenance server 1 in an embodiment of the present invention.

[0026] The firmware maintenance server 1 is composed of a computer and includes a CPU (Central Processing Unit) 20, memory 21, external storage device 22, and communication device 23. In this embodiment, an example using a computer is described, but it may also be implemented using a cloud system that provides computing resources.

[0027] The CPU 20 is the processor that controls the overall operation of the firmware maintenance server 1. The memory 21 consists of volatile semiconductor memory such as SRAM (Static RAM (Random Access Memory)) and DRAM (Dynamic RAM), and is used as the working memory of the CPU 20 to temporarily hold various programs and necessary data. By executing programs stored in the memory 21 by at least one CPU 20, various processes of the firmware maintenance server 1, as described later, are executed.

[0028] The external storage device 22 consists of high-capacity non-volatile storage devices such as HDDs (Hard Disk Drives) and SSDs (Solid State Drives).

[0029] The communication device 23 is an interface for the firmware maintenance server 1 to communicate with the storage system 2 via the network 4, and is composed of, for example, a NIC (Network Interface Card), an FC card, or a wireless LAN card.

[0030] Memory 21 stores, as software modules, a fault information receiving unit 24 that receives firmware fault information and a corrected firmware information receiving unit 25 that receives corrected firmware versions. When these modules are executed by the CPU 20, information such as tables stored in the external storage device 22 is referenced.

[0031] The external storage device 22 stores fault information 26, which contains the fault information of the firmware received by the fault information receiving unit 24, and firmware information 28, which includes the information of the firmware's countermeasure version received by the countermeasure version information receiving unit 25 and the firmware corresponding to that countermeasure version.

[0032] Figure 3 is an example of a block diagram showing the configuration of the storage system 2 in an embodiment of the present invention.

[0033] The storage system 2 comprises a CPU 30, memory 31, external storage device 32, and communication device 33.

[0034] The CPU 30 is a processor that controls the operation of the entire storage system 2. The memory 31 consists of volatile semiconductor memory such as SRAM (Static RAM (Random Access Memory)) and DRAM (Dynamic RAM), and is used as the working memory of the CPU 30 to temporarily hold various programs and necessary data. When at least one CPU 30 executes the programs stored in the memory 31, various processes of the storage system 2, as described later, are executed.

[0035] The external storage device 32 consists of a large-capacity non-volatile storage device such as an NVMe (Non-Volatile Memory) drive, a SAS (Serial Attached SCSI) drive, a SATA (Serial ATA (Advanced Technology Attachment)), an SSD (Solid State Drive), or an SCM (Storage Class Memory), and provides a physical storage area for actually storing user data stored on a logical volume.

[0036] Multiple storage devices included in the external storage device 32 form a RAID (Redundant Array of Independent Disks) group (parity group), ensuring data integrity and redundancy within that group.

[0037] The communication device 33 is an interface for the storage system 2 to communicate with the firmware maintenance server 1 or other storage systems 2 via the network 4, and is composed of, for example, a NIC (Network Interface Card), an FC card, or a wireless LAN card. The communication device 33 also provides an interface for the storage system 2 to communicate with the maintenance terminal 5 via the management network.

[0038] Memory 31 stores the control unit 34, usage history acquisition unit 35, performance information acquisition unit 36, configuration information acquisition unit 37, occurrence probability determination unit 38, message output unit 39, and fault information request unit 40.

[0039] These are implemented as software modules by the CPU 30, and data such as tables stored in the external storage device 32 are referenced.

[0040] The control unit 34 controls the entire management device, and the usage history acquisition unit 35 acquires the usage history of commands and data processing used in the RAID system, etc., and stores it in the operation history information 55 in the external storage device 32, which will be described later. The performance information acquisition unit 36 ​​stores the execution time of commands and data processing performed in the RAID system, etc., in the performance information 56 in the external storage device 32.

[0041] The configuration information acquisition unit 37 acquires information on the mounted components and firmware used in the storage system and stores it in the H / W / logical configuration information 52, operating software configuration information 53, and operating firmware information 54 of the external storage device 32, respectively. The configuration information acquisition unit 37 stores the firmware information received from the firmware maintenance server 1 in the memory 31, thereby making the firmware included in the firmware information executable by the CPU 30.

[0042] The failure probability determination unit 38 compares the firmware failure information received from the firmware maintenance server 1 with the usage history, configuration information, etc., obtained from the RAID system to determine the likelihood of a failure occurring. Details of the failure probability determination by the failure probability determination unit 38 will be described later with reference to Figures 10 to 14.

[0043] The message output unit 39 outputs the result determined by the probability determination unit 38 based on its severity. The fault information request unit 40 requests the firmware maintenance server 1 to send the latest fault information and stores the fault information obtained from the firmware maintenance server 1 in the received fault information 57.

[0044] The external storage device 32 stores storage information 51 related to the configuration information and operation history of the storage system 2, received failure information 57 which stores the failure information 26 received from the firmware maintenance server 1, and storage information 51 of the storage system 2. The received failure information 57 includes occurrence condition information 59 which indicates the conditions under which a failure occurs. It also stores the impact assessment result 58 obtained by comparing the storage information 51 and the received failure information 57.

[0045] The reception failure information 57 and the occurrence condition information 59 are equivalent to the failure information 26 stored in the firmware maintenance server 1, but it is not necessary to have all the information of the failure information 26. For example, when requesting the transmission of failure information, the date and time when the failure occurred can be specified, and failure information from that date and time onward can be obtained.

[0046] Furthermore, it is also possible to specify a model and request only fault information related to that model. This makes it possible to determine the likelihood of a fault occurring in a short amount of time.

[0047] Storage information 51 includes hardware and logical volume configuration information 52, operating software configuration information 53, operating firmware information 54, storage operation history information 55, and storage performance information 56.

[0048] Figure 4 is an example of a table diagram showing received fault information in an embodiment of the present invention. Figure 4 is an example of a table in which fault information acquired from the firmware maintenance server 1 is presented as received fault information 57.

[0049] The reception failure information table 57 stores information about each firmware-related failure in each record. Each record stores associated information such as the failure case number 60, the failure case name 61, the affected model 67, the version in which the coding causing the failure was first implemented 62, the version in which countermeasures were implemented 63, the phenomenon 64 indicating the phenomenon caused by the failure, the severity 65 indicating the severity of the failure as High, Middle, or Low, and the frequency 66 indicating the frequency of the failure. The information shown in Figure 4 is a partial representation of the information related to the failure.

[0050] If no data is stored in mitigation version 63, it indicates that the mitigation version has not yet been created.

[0051] In addition, if the failure can be avoided through the operation method of the storage system, and if the countermeasure is stored in version 63, the failure can be temporarily avoided by displaying the countermeasure to the user.

[0052] Figure 5 is an example of a table diagram showing the occurrence condition information 59 in an embodiment of the present invention.

[0053] Similar to the reception failure information 57, the table of occurrence condition information 59 stores information about each failure caused by the firmware in each record. Each record is associated with and stores the hardware configuration 71 corresponding to the case number 60, the software configuration 72, the operation that causes the failure 73, the trigger for the failure 74, and the timing of the failure 75.

[0054] The reception failure information table 57 in Figure 4 may include the information shown in the occurrence condition information 59 in Figure 5, or it may be configured by selecting from the failure information 26 so as to exclude the information shown in the occurrence condition information 59.

[0055] Figure 6 is an example of a table diagram showing hardware and logical configuration information 52 in an embodiment of the present invention.

[0056] The hardware and logical configuration information table 52 stores the date 101 on which the hardware configuration information was acquired, the time 102 on which the hardware configuration information was acquired, the model 106 of the hardware on which the firmware is installed, the installed components 105, device information (LDEV) 103, and device information (PG / DP) 104 in association with each other.

[0057] Figure 7 is an example of a table diagram showing the operating software configuration information 53 in an embodiment of the present invention.

[0058] The operating software configuration information table 53 stores the date 151 on which the operating software configuration information was obtained, the time 152 on which the operating software configuration information was obtained, and the software configuration 153 indicating the configuration of the operating software, in association with each other.

[0059] Figure 8 is an example of a table diagram showing the operating firmware information 54 in an embodiment of the present invention.

[0060] The operating firmware information table 54 stores the date 161 on which the operating firmware information was obtained, the time 162 on which the configuration information of the operating software was obtained, the overall firmware version information 163 indicating the representative version of the operating firmware, and the firmware information 164 indicating the information of the operating firmware, all linked together. The firmware information 164 stores the firmware name and version information as a pair for each firmware that is currently in operation.

[0061] In an embodiment of the present invention, the firmware information 28 stored in the firmware maintenance server 1 includes, with respect to multiple types of firmware running on the storage system 2, information on countermeasures for failures caused by each firmware, and the firmware itself corresponding to the countermeasure version. Accordingly, in addition to the version information of each firmware, the firmware information 28 further includes overall firmware version information that indicates the update status of the entire firmware.

[0062] When a patched version is released for each firmware, the version information of that firmware is updated, and the overall firmware version information is updated accordingly. This allows for the identification of the corresponding version of each firmware linked to the overall firmware version information.

[0063] The firmware maintenance server 1 receives a request from the storage system 2 based on the overall firmware version information, provides firmware information 28 including various firmware versions corresponding to the request, and when multiple types of firmware included in the firmware information 28 are installed and running on the storage system 2, it manages the operational firmware information 54 based on the overall firmware version.

[0064] In Figure 8, DKCMAIN at the beginning of firmware information 164 is the firmware that controls the overall system, and its version is updated along with any other firmware updates. Therefore, the version information of DKCMAIN is treated as the overall firmware version information 163 and managed accordingly.

[0065] Furthermore, the built-in version 62 and countermeasure version 63 in the reception interference information 57 of Figure 4 are version information corresponding to the overall firmware version information 163, and the comparison of firmware version information in the embodiment is performed using this information.

[0066] While it is also possible to compare using the version information of various firmwares, in that case, the reception failure information table 57 in Figure 4 should be prepared for each type of firmware, and the customized version 62 and the countermeasure version 63 should each store the version information of the target firmware.

[0067] Figure 9 is an example of a table diagram showing operation history information 55 in an embodiment of the present invention.

[0068] The operation history information table 55 sequentially records the operation date 111, operation time 112, and operation details 113 as corresponding information for operations performed on the storage system.

[0069] Figure 10 is an example of a table diagram showing performance information 56 in an embodiment of the present invention.

[0070] The performance information table 56 stores the date 121 when the data was acquired, the time 122, the overall write wait rate 123, the write wait rate 124 for each MP (microprocessor) unit, and the MP utilization rate 125, all associated with each other.

[0071] Figure 11 is an example flowchart showing the process of determining the possibility of a failure occurring by firmware in an embodiment of the present invention.

[0072] The fault information request unit 40 of the storage system 2 sends a request to transmit fault information to the firmware maintenance server 1 via the network 4 (S1). In step S1, the fault information request unit 40 may be triggered by receiving a fault information transmission request instruction from the maintenance terminal 5, or it may periodically output transmission requests at predetermined intervals. The fault information request unit 40 may also specify the conditions for the fault information to be transmitted (such as the date and time of the fault occurrence) when issuing a fault information transmission request instruction.

[0073] When the firmware maintenance server 1's fault information receiving unit 24 receives a request to send fault information, it sends the fault information 26 corresponding to the request to the storage system 2. In the storage system 2, when the fault information requesting unit 40 receives the fault information, it stores it in the received fault information 57 (S2). The received fault information is reconfigured and stored in the received fault information 57 for each fault case in the format shown in Figure 4.

[0074] Next, the probability determination unit 38 refers to the model 67 of the received fault case in the received fault information 57 and performs a target model match determination to determine whether it matches the storage model used in the storage system 2 (S3). The storage model used can be referenced from the model 106 in the hardware / logical configuration information 52.

[0075] If a problematic model 67 corresponding to the storage model used exists in step S3 (Yes in S3), the next problem probability determination unit 38 refers to the overall firmware version information 163 of the operating firmware information 54 and determines whether the firmware used for the received problem case is version 62 or later (S4).

[0076] If the overall firmware version in operation in step S4 is version 62 or later (Yes in S4), the probability determination unit 38 further determines whether the firmware being used is earlier than version 63 of the countermeasure for the received fault case (S5).

[0077] If, in step S5, the overall firmware version in operation is older than the patched version (Yes in S5), the probability determination unit 38 compares the failure information with the usage history to determine the likelihood of the failure occurring and calculates the probability of the failure occurring (S6). Details of the operation in step S6 will be described later with reference to Figure 12.

[0078] If, in any of the determinations in steps S3 through S5, the operating model or version is not associated with the fault information (No. in S3, No. in S4, or No. in S5), the probability determination unit 38 sets the probability to 0, deletes the fault case from the received fault information 57 (S7), and proceeds to step S8, which will be described later.

[0079] If the probability of a failure corresponding to the failure case received in step S6 is calculated, the probability determination unit 38 determines whether there are any other failure cases received (S8). If there are other failure cases (Yes in S8), it returns to the process in step S3. If there are no other failure cases (No in S8), the message output unit 39 outputs a message indicating the failure probability determination result (S9). Details of the message output will be described later using Figure 15.

[0080] Figure 12 is an example flowchart showing the comparison process between fault information and usage history in step S6 of Figure 11. Figure 13 is an example of the impact determination result 58 in an embodiment of the present invention (Example 1). The operation of the above comparison process will be explained below using Figure 13 as an example.

[0081] The impact assessment result 58 is information generated by the occurrence probability determination unit 38 during the process of comparing the storage information 51 and the reception failure information 57, and consists of failure condition information 58A and failure probability assessment result 58B. The failure condition information 58A includes condition items such as No. (item number) 131, item name 132, explanation 133, and result 134.

[0082] The fault condition information 58A is a list of information about faults included in a single fault case. Numbers 1 to 9 correspond to the information stored in the record for a single fault case in the received fault information 57 table in Figure 4, and number 16 corresponds to the information stored in the record for a single fault in the occurrence condition information 59 table in Figure 5.

[0083] In step S6, the occurrence probability determination unit 38 first refers to the corresponding information in the reception failure information 57 table for items No. 1 to 9 of the failure condition information 58A and enters it in the explanation column 133. The input of the corresponding information in the reception failure information 57 may also be done at the same time as storing the reception failure information 57 in step S2.

[0084] Next, the probability determination unit 38 compares each of the corresponding pieces of information in the received failure information 57 input to the failure condition information 58A by referring to the corresponding information among the various pieces of information contained in the storage information 51, and inputs the result into 134.

[0085] In the example of fault information shown in Figure 13, if it is confirmed in step S4 that the firmware is a version later than the built-in version, "Applicable" is registered in the Result 134 column corresponding to the built-in version in No. 5. In addition, the result corresponding to Result 134 is entered based on the degree of occurrence (High, Middle, or Low) entered in the Explanation 133 of the Occurrence Frequency in No. 9.

[0086] Furthermore, the fault condition information 58A includes multiple categories (hereinafter referred to as "condition categories") such as mounted components, software settings, and operation history in item No. 16, as shown in Figure 13, and is used as a condition for calculating the probability of a fault occurring.

[0087] In the example shown in Figure 13, the failure occurs when all four operations in the operation history category—"Create TC PAIR NOCTG," "Delete TC PAIR," "Split TC PAIR," and "Resync TC PAIR CTG"—are executed.

[0088] Thus, each condition category may contain multiple conditions. For this reason, the probability determination unit 38 adds 1 to the probability denominator (initial value 0), which is the denominator of the frequency of occurrence, each time it determines each condition in each condition category (S10).

[0089] Next, the probability determination unit 38 further refers to information corresponding to each condition category and determines whether there is any matching information (hardware / logical configuration information 52 to performance information 56) contained in the storage information 51 (S11). The probability determination unit 38 may also refer in advance to specific information contained in the storage information 51 in association with each condition category.

[0090] For example, for the category of mounted components, refer to mounted components 105 in hardware / logical configuration information 52; for software settings, refer to software configuration 153 in operating software configuration information 53; and for the category of operation history, refer to operation details 113 in operation history information 55.

[0091] If the condition is met (Yes in S11), 1 is added to the probability numerator (initial value 0), which is the numerator of the frequency of occurrence (S12). The occurrence probability determination unit 38 makes a determination for all conditions in all occurrence condition categories (S13).

[0092] Once the determination is complete for all condition categories and items (No. in S13), the occurrence probability determination unit 38 calculates the frequency of occurrence from the occurrence conditions as an indicator of the likelihood of failure occurring, based on the following formula (S14). Frequency of occurrence based on the conditions for occurrence = (Probability numerator element / Probability denominator) * 100 / 2

[0093] In the example in Figure 13, only the operation history among the condition categories is used to calculate the probability of failure occurring. Since the first three of the four operations in the operation history are applicable, the frequency of occurrence from the condition is (3 / 4)*100 / 2 ≈ 38 after processing in S14.

[0094] Next, based on the occurrence frequency listed in No. 9 of Figure 12, if the occurrence frequency is High, 50 is added; if it is Middle, 25 is added; and if it is Low, 10 is added to the occurrence frequency from the occurrence conditions to calculate the probability of occurrence (S15). In the example in Figure 13, since it is Low, 10 is added as a weight to the occurrence frequency from the occurrence conditions, and the probability of occurrence becomes 38 + 10 = 48.

[0095] The occurrence probability determination unit 38 stores the calculation basis 135 to 137 for the frequency of occurrence from the occurrence conditions together in the failure probability determination result 58B (S16). Of the calculation basis 135 to 137 in the failure probability determination result 58B, calculation basis 135 stores the calculation process and result of the frequency of occurrence from the occurrence conditions in step S14, calculation basis 136 stores the information in the explanation column of the frequency of occurrence for No. 9 of the failure condition information 58A and the frequency of occurrence to be added, and calculation basis 137 stores the calculation basis and result of the probability of occurrence in step S15.

[0096] Furthermore, the judgment result 138 stores example messages based on the probability of occurrence 137, which will be described later, by the message output unit 39.

[0097] Figure 14 shows an example (Example 2) of the impact assessment result 58 in an embodiment of the present invention. In the example shown in Figure 14, only the occurrence conditions for No. 16 of the failure condition information 58A and the failure possibility assessment result 58B are shown. In Figure 14, the information for Nos. 1 to 8 of the failure condition information 58A is assumed to be the same as in Figure 13, and the occurrence frequency of No. 9 is omitted from the illustration as the same information is shown in the calculation basis 138 in the failure possibility assessment result 58B.

[0098] In the example in Figure 14, all condition categories in the occurrence conditions are used to calculate the probability of failure. Similar to the example in Figure 13, if we determine the frequency of occurrence from the occurrence conditions according to the flowchart in Figure 12, in this example the mounted components are first compared with the H / W / Logical Configuration Information 52, and if the conditions match, the frequency of occurrence becomes 1 / 1.

[0099] The software settings are then compared with the operating software configuration information 53, and since both judgment conditions are met, the occurrence frequency is 2 / 2.

[0100] The operation history is compared with the operation history information 55, and since only the first three of the four conditions match, the occurrence frequency is 3 / 4.

[0101] The received command is compared with the operation history information 55, and if one condition is met, the occurrence frequency is 1 / 1. The trigger internal condition is compared with the performance information 56, and if one condition is not met, the occurrence frequency is 0 / 1.

[0102] The device status is compared with the H / W / Logical Configuration Information 52, and if one condition is not met, the occurrence frequency is 0 / 1. The logical configuration is compared with the H / W / Logical Configuration Information 52, and if one condition is met, the occurrence frequency is 1 / 1.

[0103] The storage operation information was compared with performance information 56, and one condition was not met, resulting in an occurrence frequency of 0 / 1.

[0104] Calculating the frequency of occurrence based on the conditions for occurrence, we get (8 / 12)*100 / 2 ≈ 33. Since the frequency of occurrence is low, we add 10, making the probability of occurrence 43.

[0105] In embodiments of the present invention, it is desirable that the condition category among the occurrence conditions used to calculate the probability of failure is predetermined in the reception failure information 57.

[0106] For example, if it is known in advance that the likelihood of a certain failure occurring increases under specific conditions (software settings, device status, storage operating status, etc.) in a system environment where firmware is implemented, the received failure information 57 may be configured to include a condition category linked to the case number of the failure, which will serve as the basis for the calculation, and the occurrence probability determination unit 38 may refer to this to calculate the likelihood of the failure occurring.

[0107] Figure 15 is an example flowchart showing the processing of the message output unit 39 in step S9 of Figure 11.

[0108] The message output unit 39 refers to the failure possibility determination result 58B in the impact determination result 58 and determines the possibility of failure based on the probability of occurrence 137 calculated in step S15. First, the message output unit 39 determines whether the probability of occurrence is 11 or greater (S22), and if it is less than 11, it adopts "There is no possibility of failure and no need to replace the microcontroller" as the message to output (S27).

[0109] If the probability of occurrence is 11 or higher, it is determined whether the probability of occurrence is 51 or higher (S23). If the probability of occurrence is less than 51, the message to be output is "The likelihood of the phenomenon occurring immediately is low, and it is acceptable to postpone the microcontroller replacement with the corrected version." (S28)

[0110] If the probability of occurrence is 51 or higher, it is determined whether the probability of occurrence is 75 or higher (S24). If the probability of occurrence is less than 75, the message to be output is "We recommend replacing the microcontroller with the patched version." (S29). If the probability of occurrence is 75 or higher, the message to be output is "We strongly recommend replacing the microcontroller with the patched version." (S25).

[0111] Once the message to be output is identified, the message output unit 39 reflects that message in the impact assessment result 58 (S28). Specifically, the message output unit 39 stores the adopted message in the corresponding fault possibility assessment result 138 of the fault possibility assessment result 58B. The message output unit 39 then sends the impact assessment result 58 containing the assessment result 138 to the maintenance terminal 5 to prompt message display.

[0112] By modifying the likelihood of occurrence and the messages depending on the model and purpose of use of the storage system being operated, it becomes possible to output diagnostic messages that are appropriate for the site.

[0113] The probability values ​​used to determine the likelihood of failure in Figure 15 are just examples, and other different numerical values ​​or indicators may be used. Furthermore, the storage system 2 may pre-store a table in memory 31 that correlates the calculated probability values ​​with the message information to be output, and the message output unit 39 may refer to this table to select a message.

[0114] Figure 16 shows an example of the output screen 140 in an embodiment of the present invention.

[0115] The output screen 140 is displayed on the maintenance terminal 5 based on the impact assessment result 58 output from the storage system 2, allowing maintenance personnel to determine whether a firmware update is necessary.

[0116] On the output screen 140, the storage system information section 141 displays the IP address used by storage system 2, the ambient temperature of storage system 2, etc., which are used to identify the storage system.

[0117] The results of the fault probability assessment are displayed for each fault case on the assessment results sheet 142. As an example of the information for each case displayed on the assessment results sheet 142, the fault probability 144, the symptoms of the fault that may occur 145, and the fault avoidance measures 146 are displayed.

[0118] Additionally, tabs 147-149, which indicate the likelihood of occurrence corresponding to the severity of the problem, are also displayed. When any of these tabs are selected on the output screen 140, the list of cases corresponding to the severity of the problem will be switched and displayed on the judgment result sheet 142.

[0119] In this embodiment of the present invention, among the probability tabs, the Important tab 147 corresponds to cases where the probability of occurrence is determined to be 75 or higher in the judgment process shown in Figure 15, similarly the Caution tab 148 corresponds to cases where the probability of occurrence is determined to be 51 or higher but less than 75, and the Reference tab 149 corresponds to cases where the probability of occurrence is determined to be 11 or higher but less than 51. When each tab is selected, a list of cases corresponding to the judgment result sheet 142 is displayed.

[0120] Furthermore, if case number 143 of a particular case in the case list is selected on the judgment result sheet 142, detailed information about that case (for example, information on the conditions for occurrence in the case's failure condition information 58A, judgment result 138 in the failure possibility judgment result 58B, etc.) will be displayed separately.

[0121] Furthermore, the workaround 146 displayed on the judgment result sheet 142 will show the version number of the countermeasure version if the countermeasure version 63 of the reception failure information 57 contains the countermeasure version of the entire firmware. By installing the firmware with that version number on the storage system 2, the possibility of avoiding the corresponding failure case can be improved.

[0122] For failure cases for which a corrected version is not provided for workaround 146, measures can be taken to avoid the failure by not performing operations that match the conditions for occurrence described in the detailed information of the case. As an example of a countermeasure to avoid the failure, if the installed component in the failure condition information 58A of the failure case is not installed in storage system 2 and is marked as "not applicable", a message may be output to not change the installed component. Similarly, if the software setting in the failure condition information 58A is set to "not applicable", a message may be output to not change the setting to "not applicable".

[0123] On output screen 140, the display method can be changed to reflect the severity of the problem by altering the color, font size, display order, etc., and there is no need to insist on separating the sheets. [Explanation of Symbols]

[0124] 1. Firmware maintenance server 2 Storage Systems 4 Network 5. Maintenance terminals 20, 30 CPU 21, 31 memory 22, 32 External storage device 23, 33 Communication equipment 24. Service Disaster Information Reception Department 25 Countermeasure Information Reception Department 26. Service Status 28 Firmware Information 34 Control Unit 35. Usage History Acquisition Unit 36 Performance information acquisition section 37 Configuration information acquisition unit 38. Occurrence Probability Determination Unit 39 Message output section 40. Fault Information Request Department 52H / W Logical Configuration Information 53 Operating Software Configuration Information 54 Operating Firmware Information 55 Operation History Information 56 Performance information 57 Reception Interference Information 58 Impact determination results 59. Information on conditions for occurrence

Claims

1. A storage system comprising a processor, memory, and one or more storage devices, wherein a firmware update system manages the update status of firmware read from the memory to the processor and executed, A failure information request unit that acquires firmware failure information, including information on failures that may occur in the storage system as a result of the firmware update and the conditions under which such failures occur. A failure probability determination unit that compares the configuration information and operation history of the storage system with the conditions for occurrence in the firmware failure information, and determines the possibility of failure occurring in the storage system due to the firmware update based on the comparison result, An output unit that outputs the result of the determination of the likelihood of the failure occurring, A firmware update system characterized by having the following features.

2. In the firmware update system according to claim 1, The failure probability determination unit determines the likelihood of failure based on the proportion of the failure conditions in the firmware failure information that match the configuration information and operation history in the storage system. A firmware update system characterized by the following features.

3. In the firmware update system according to claim 2, The firmware failure information includes information on the frequency of occurrence of the failure in question. The failure probability determination unit determines the likelihood of failure based on the result of weighting the proportion of the occurrence conditions in the firmware failure information that match the configuration information and operation history of the storage system, according to the frequency of occurrence. A firmware update system characterized by the following features.

4. In the firmware update system according to claim 1, The firmware failure information includes information on the initial version of the firmware in which the failure in question may occur, which is the build version. The firmware update system is characterized in that the failure probability determination unit determines the failure probability when the version of the firmware currently running in the configuration information of the storage system is later than or equal to the built-in version.

5. In the firmware update system according to claim 1, The aforementioned firmware failure information includes information on the corrected version, which is the firmware version that addresses the target failure. The firmware update system is characterized in that the failure probability determination unit determines the failure probability when the version information of the operating firmware in the configuration information of the storage system is earlier than the countermeasure version.

6. In the firmware update system according to claim 1, The output unit outputs, along with the result of the determination of the likelihood of a failure occurring, information regarding the need for a firmware update according to the determination result. A firmware update system characterized by the following features.

7. In the firmware update system according to claim 1, The firmware failure information includes information on workarounds for the affected failure. The output unit outputs the result of the determination of the likelihood of failure occurring, along with the information on the countermeasures. A firmware update system characterized by the following features.

8. In the firmware update system according to claim 1, The firmware failure information includes information regarding the severity of the failure in question. The output unit classifies and outputs the results of the determination of the likelihood of failure occurring for each failure based on the severity level. A firmware update system characterized by the following features.

9. In the firmware update system according to claim 5, If the version information of the currently running firmware in the configuration information of the storage system is earlier than the corrective version, the output unit outputs the information of the corrective version along with the determination result of the failure probability determination unit. A firmware update system characterized by the following features.

10. A storage system comprising a processor, memory, and one or more storage devices, wherein a method for determining the likelihood of failure occurring in connection with a firmware update that is read from the memory and executed by the processor, The firmware update system that manages the update status of the aforementioned firmware, A first step is to obtain firmware failure information, which includes information on failures that may occur in the storage system as a result of the firmware update and the conditions under which such failures occur. A second step involves comparing the configuration information and operation history of the storage system with the conditions for occurrence in the firmware failure information, and determining the possibility of failure, which is the possibility of a failure occurring in the storage system due to the firmware update, based on the comparison result. A third step of outputting the result of the determination of the likelihood of the failure occurring, A method for determining the likelihood of failure occurring during a firmware update, characterized by performing the following steps.

Images