JP2001216166A - Maintenance control method for information processor, information processor, creating method for software and software - Google Patents

Abstract

PROBLEM TO BE SOLVED: To realize prompt recovery from a fault, preventive maintenance, etc., by efficiently performing remote maintenance of software of external storage devices such as distributively arranged disk array devices. SOLUTION: A disk array device installation site 604 is connected with a fault recovery assistance center 602 with a fault countermeasure data base with information such as a fault countermeasure ID to discriminate faults and the contents of countermeasure and a micro database in which a binary micro program in which the executed fault countermeasure ID and the contents of countermeasure are embedded is stored through a network 603, fault information is reported to the fault recovery assistance center 602 through the network 603 taking the opportunity of generation of a fault of a disk array device 601, the corresponding fault countermeasure ID is detected from the fault countermeasure database, binary retrieval is performed to the micro program itself in the micro database by the obtained fault countermeasure ID, the micro program with the applicable fault countermeasure ID is found, transmitted to the disk array device and updated there.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a maintenance management technique for an information processing apparatus, an information processing apparatus, and a software creation technique and software, and in particular, to a plurality of external storage apparatuses and the like distributed in remote locations or the like. The present invention relates to a technique that is effective when applied to maintenance management of an information processing device.

[0002]

2. Description of the Related Art In recent years, with the rapid expansion of the use of a computer system by an online system or the like, a system of non-stop operation, high reliability, and high availability has been required. If a failure occurs in such a system, the recovery of the system must be performed in a short period of time and in use.
Operation errors and work instruction errors in the recovery procedure are absolutely unacceptable. If recovery is performed by an incorrect procedure, a secondary failure may occur. Therefore, if a recovery operation can be performed on a portion that can automatically avoid a failure without the intervention of maintenance personnel, maintenance errors can be prevented.

For example, if attention is paid to a disk array device which is widely used as an external storage device connected to a computer system, a huge number of microprograms are incorporated in the disk array device in the world and are in operation. Even if a defect is discovered in one microprogram version,
It is difficult to always update the microprogram version to take measures. For this reason, it is necessary to individually take a countermeasure against a defect, and management of the content of the countermeasure and the microprogram version is complicated.

[0004]

When the maintenance management such as the software update is performed manually as described above, it requires a great number of man-hours and it is difficult to eliminate any work mistakes. However, there is a concern that a disk array device that has a high reliability of stored data due to data loss may cause a serious obstacle such as data loss.

[0005] Regarding management of software version and the like, it is possible to know the update history later by adding an annotation at the source code level.
Since it is deleted in the process of converting to a binary load module by compiling and assembling, etc., from the binary load module that is actually mounted and operated on the device,
The change history of the load module cannot be known.

Therefore, conventionally, when managing a large number of load modules having different change histories, a database for recording / managing the names of the individual load modules and the change histories such as countermeasures against failures for the load modules is provided. It is indispensable, and the management and operation of the load module requires a great deal of cost and labor.

[0007] Also, due to such complicated management, when the load module has a plurality of module configurations, software management and update are executed collectively for a plurality of modules. Even if discovered, measures such as updating will be delayed until the entire load module can be replaced, the handling unit (eg, file size) will increase, and transport costs on portable media and communication media will increase. There are also technical issues.

As a remote maintenance technique for a program-controlled electronic device, a conventional technique is disclosed, for example, in Japanese Patent Application Laid-Open No. 6-12538.
The technique disclosed in Japanese Patent Application Laid-Open No. 9-99 is known. That is,
A remote maintenance device is connected to a plurality of digital private branch exchanges (PBXs) via a network, and a database of maintenance history created based on failure information received from the PBX side, troubleshooting information, and corresponding troubleshooting information. A storage means for storing data to be transmitted to the PBX side is provided, the next failure is predicted based on the maintenance history database, and data of failure countermeasure information corresponding to each failure is transmitted to the PBX side. Perform the operation. However, this conventional technique does not disclose a maintenance management technique for efficiently storing, searching, updating, and the like of a failure countermeasure history of software such as a large number of various microprograms.

An object of the present invention is to provide a technique capable of efficiently and efficiently maintaining and managing software mounted on a plurality of information processing apparatuses distributed and arranged. .

Another object of the present invention is to provide a technique capable of efficiently performing maintenance management and operation of binary software mounted and operated on an arbitrary information processing apparatus with high reliability. is there.

Another object of the present invention is to provide a technology capable of performing maintenance management and operation of binary software mounted and operated on an arbitrary information processing device in a small size unit in a fine and quick manner. It is in.

[0012] Another object of the present invention is to provide a communication system in which
It is an object of the present invention to provide a technology for downloading a program in which a measure against a failure is downloaded via a network, and replacing the program without human intervention.

Another object of the present invention is to estimate a defective portion up to a plurality of load modules constituting an executable program and to perform updating in units of load modules so that early countermeasures and network load reduction can be achieved. It is an object of the present invention to provide a technology capable of reducing the amount.

Another object of the present invention is to determine whether or not a running program has a defect by allowing an information processing apparatus in which software is installed to voluntarily access a maintenance support center via a network. It is an object of the present invention to provide a technology capable of preventive maintenance for preventing a failure from occurring.

Another object of the present invention is to provide a technique capable of centrally managing the microprogram version and the content of the troubleshooting by embedding the past troubleshooting content as a binary code in an executable microprogram. To provide.

[0016]

According to a maintenance management method for an information processing apparatus of the present invention, at least one information processing apparatus operated by software is connected to a maintenance support center for managing the software via an information network. When a failure occurs in a device, software in which measures against the failure have been taken is transmitted from the maintenance support center to the information processing device to update the software in the information processing device.

Further, the maintenance management method for an information processing apparatus according to the present invention connects an information processing apparatus operated by software to a maintenance support center for managing the software via an information network. Of the software running and the multiple software stored at the maintenance support center are compared and determined via the information network. When applied to software stored in the center, the first operation for issuing a warning of a potential failure occurrence to the maintenance manager of the information processing device, and the software running on the information processing device, At least one of a second operation of updating with software stored in the maintenance support center via the network. It is intended to perform the work.

According to the present invention, there is provided an information processing apparatus including a control unit operated by software and a network interface connected to a maintenance support center via an information network. A monitoring function, a failure notification function for notifying the occurrence of a failure to the maintenance support center, a software replacement function for receiving software from the maintenance support center for which a measure against the failure has been taken, and replacing the software with an operating software,
Is provided with control logic.

Further, the present invention provides software including a first step of creating or changing a source code, and a second step of converting the source code into a binary executable code mounted on an arbitrary information processing apparatus. In the method of creating
In the first step, when a change is made to the source code as a countermeasure for a fault detected during the operation of the information processing apparatus, the fault countermeasure identification information indicating the type of the fault countermeasure is inherited by the fault countermeasure identification information to the execution code. In addition to the source code in the format described, the fault countermeasure identification information is embedded in the execution code obtained in the second step.

The present invention also relates to binary software implemented in an information processing apparatus, wherein a part of the software includes fault countermeasure identification information indicating a type of a fault countermeasure performed so far on the software. Is embedded.

More specifically, as an example, when a failure occurs, the failure information and the failure occurrence version are reported to a failure recovery support center via a network. Failure countermeasure ID
And a failure countermeasure database (failure countermeasure DB) including information such as cause, phenomenon, and countermeasure contents of the fault, and detects a fault countermeasure ID from the reported fault information and the fault countermeasure DB matching provided on the center side. This failure countermeasure ID is embedded in a microprogram for which a countermeasure has been taken in advance,
Each microprogram is searched for in binary, a microprogram matching the previously detected failure countermeasure ID is found, and the microprogram is sent to the disk array device via the network to be updated.

Here, in order to embed the fault countermeasure ID and the countermeasure contents as a binary code in the microprogram, the fault countermeasure ID is used as an external variable in the source program.
By entering the countermeasure and the countermeasure, the load module created after compiling can have the fault countermeasure ID and countermeasure content as a binary code, which enables centralized management of the fault countermeasure content and the microprogram version Becomes

Further, even in the operating system, whether the failure is dealt with by autonomously querying the failure recovery DB to the failure recovery support center and searching for the failure countermeasure ID embedded in the microprogram. You can find out. If it turns out that the program has the potential for failure occurrence, report it to maintenance personnel and if maintenance personnel instructs you to replace the program, download the program that has been similarly treated and automatically Try to update.

In addition, an enormous number of microprograms are incorporated in disk devices and are in operation throughout the world. Therefore,
By managing the microprogram with the fault countermeasure ID and the content of the countermeasure, it is possible for the microprogram operating in the disk device to easily check whether or not the fault occurring in another disk device has been corrected.

[0025]

Embodiments of the present invention will be described below in detail with reference to the drawings.

FIG. 1 is a flowchart showing an example of the operation of the information processing apparatus maintenance management method according to one embodiment of the present invention. FIG. 2 is a flowchart showing the operation of the information processing apparatus maintenance management method according to this embodiment. FIG. 3 is a conceptual diagram showing an example of the configuration of various databases used in the present embodiment. FIG. 3 is a table showing an example of information embedded in software in the maintenance management method for the information processing apparatus according to the present embodiment. FIG. 4 is an explanatory diagram showing an example of source code of software to be maintained and managed in the information processing apparatus maintenance management method according to the present embodiment, and FIG. In a management method, it is an explanatory view showing an example of a module of a binary execution form after compilation of software for maintenance management by a hexadecimal dump.

FIG. 6 is a conceptual diagram showing an example of the configuration of an information processing system in which the information processing apparatus maintenance management method according to the present embodiment is implemented. FIG. FIG. 8 is a conceptual diagram showing an example of a configuration of a disk array device which is an example of an information processing device that implements a maintenance management method.
FIG. 9 is a conceptual diagram illustrating an example of a configuration of a service processor provided in the disk array device illustrated in FIG. 7, and FIG.
FIG. 2 is a conceptual diagram illustrating an example of a configuration of a failure recovery support center that performs remote maintenance of the disk array device according to the present embodiment.

First, a description will be given of a hardware configuration of a disk device according to the present embodiment, which is performed from the occurrence of a failure in the disk device to the automatic update of a program, with reference to FIGS. 6, 7, 8, and 9.

Referring to FIG. 6, a description will be given of a configuration of an information processing system in which the maintenance management method for the information processing apparatus according to the present embodiment is performed. A disk array device installation site 604 configured by connecting a plurality of disk array devices 601 via a local area network 605 (LAN), and a failure recovery support for supporting a failure recovery from a failure occurring at the disk array device installation site 604 Center 602
Are configured to be communicable via the network 603. In FIG. 6, one failure recovery support center 602 is illustrated for simplicity, but one or a plurality of failure recovery support centers 602 are connected to a network 603 via a local area network 606 (LAN). It can be.

Referring to FIG. 7, an example of the basic configuration of the hardware of the disk array device 601 will be described. The disk array device 601 is a host computer 7 such as a general-purpose computer, a workstation, or a personal computer.
01 and a plurality of host I / Fs for controlling data transmission / reception by directly connecting them via interfaces such as channels.
A control unit 702, a disk control unit 703 for controlling a plurality of disk devices 704, a common bus 705 for connecting these I / F control units, and a control unit for sharing control information between the I / F control units. Of the shared memory 706.

Information exchanged with the host computer 701 and redundant information generated from the information are dispersedly stored in the plurality of disk devices 704 to form a disk array.

Each of the host I / F control units 702 includes, for example, a control storage 702a, and operates according to a microprogram including a plurality of modules stored in the control storage 702a. Similarly, each of the disk control units 703 includes, for example, a control storage 703a.
It operates with a microprogram consisting of a plurality of modules stored in the module 03a. FIG. 10 shows a control storage 702a.
And 703a show an example of the storage state of the microprogram. The microprogram 1000 in binary format implemented in the control storages 702a and 703a is
The load module 1001 is composed of a plurality of load modules 1001. Each load module 1001 includes a failure countermeasure ID 1002 embedded by a method described later and a countermeasure content 1003 as an annotation.

In each disk array device 601, a service processor (Service Processor) (hereinafter, referred to as SVP) connected to the common bus 705 for the purpose of performing maintenance management such as troubleshooting for the disk array device 601.
707. The SVP 707 is a microprocessor (M) (not shown) as hardware for troubleshooting.
PU), a memory, a central processing unit 8 having a common bus, etc.
00, display 801 such as CRT, keyboard 80
2. External input / output device such as mouse 803, and SVP70
7, a microprogram 100 received from the failure recovery support center 602 or the like, or input via the FD and loaded into the disk array device 601.
0, an external storage device such as a hard disk drive 805 (HDD) and a floppy disk drive 804 (FD) for storing data, and an external failure recovery support center 6 via a LAN 605 and a network 603.
Network driver 8 for performing information communication with the device 02 or the like
06 or the like is used. The central processing unit 800 implements functions of a failure monitoring unit 808, a failure notification unit 809, a micro exchange unit 810, and the like, which will be described later. Details are shown in FIG.

Referring to FIG. 8, the software and hardware configuration in the SVP 707 mounted on the disk array device 601 shown in FIG. 7 will be described in more detail. The common bus 705 in the figure corresponds to the disk array device 601 shown in FIG.
Each has an I / F control unit and an I / F. Therefore, the fault detected by each I / F control unit is determined by the common bus 705
Is transmitted to the SVP 707 via the

In the SVP 707, the fault monitoring unit 808 receives fault information such as an error code and an error message detected by each I / F control unit. The received fault information is passed to the fault notification unit 809, and the fault notification unit 809
VP common bus 807, network driver 806,
A notification is sent to the failure recovery support center 602 via a network driver 906 and a common bus 907 shown in FIG. The failure recovery support center 602 sends a program in which a failure has been dealt with to the micro exchange unit 810 via the same part. The micro exchange unit 810 updates the sent program.

FIG. 9 shows a detailed configuration example of the failure recovery support center 602 of this embodiment. The failure recovery support center 602 includes, for example, a central processing unit 900 having a microprocessor (MPU), a memory, a common bus, and the like, a display 901 such as a CRT, an external input / output device such as a keyboard 902, a mouse 903, and a program. Disk drive 905 (HDD) and floppy disk drive 904 for storing data and data
(FD) and an external disk array device 601 via a LAN 606 and a network 603.
Network driver 906 for performing information communication with the SVP 707, etc., and a common bus 90 for interconnecting them.
7 is used.
The workstation includes a failure countermeasure database 908 (failure countermeasure DB) in a format illustrated in FIG.
Also, a microprogram database 909 (hereinafter, microDB909) storing a plurality of microprograms having different functions and fault countermeasure states is connected.

The central processing unit 900 has a failure countermeasure I described later.
D detection program 910, binary search program 9
11. The micro-sending program 912 is executed to perform control such as maintenance management of the disk array device 601 as described later.

When a failure occurred in the disk array device 601 at the disk array device installation site 604 is reported as failure information to the failure recovery support center 602 via the network 603, a failure countermeasure ID detection program in the failure recovery support center 602 910 detects the fault countermeasure ID 908a from the fault countermeasure DB 908. The detected fault countermeasure ID 908a is passed to the binary search program 911 via the common bus 907, and the binary search program 911 searches the micro DB 909 in which the fault has been countermeasured for a microprogram in binary.
908a, find a micro program having the fault countermeasure ID 1002, and send the micro program 91
2 sends to the disk array device 601 the microprogram in which the measure has been taken.

FIG. 2 shows an example of a detailed table structure of the failure countermeasure database 908 used in this embodiment. The items are: failure countermeasure ID 908a, subject 90
8b, phenomenon 908c, cause 908d, and countermeasures 908
e, occurrence program version 908f, countermeasure program version 908g, and multiple events 908h. Here, the event 908h indicates fault information such as an error message or an error code. If it is determined that some faults are classified as the same fault, the event 908h is detected.
08h can be increased. Event 908h includes:
Information indicating the symptom of the failure, such as the number of times the function is retried 5 times or more, or the performance degradation of the function, is stored.

FIG. 3 shows an example of a detailed table structure of information to be embedded in the load module of the microprogram 1000 maintained and managed in this embodiment.
That is, the load module 1001 of the microprogram 1000 includes a failure countermeasure ID 1002 corresponding to the failure countermeasure ID 908a of the failure countermeasure database 908,
A countermeasure content (comment: comment) 1003 is embedded.

FIG. 4 shows an example of external variables to be written in the source code 1000a of the microprogram 1000 in order to embed information in the load module 1001 as exemplified in the table of FIG.

Conventionally, the contents of the measures taken against a failure performed on an arbitrary microprogram are written as an annotation (comment) in the source code of the microprogram. By defining this as an external variable, 5, the failure countermeasure ID 1002 (908a) and the countermeasure content 100 in the binary code of the load module 1001 as exemplified in the hexadecimal dump data of the load module 1001.
3 (908e). This makes it possible to centrally manage the relationship between the contents of the failure countermeasures applied to the microprogram 1000 and the load module 1001 using only the binary load module 1001 without requiring a special database or the like. In addition, it is possible to centrally manage the program version having the failure countermeasure item and its load module.

FIG. 1 is a flowchart showing an example of the operation from the occurrence of a failure to the automatic update of a program when the maintenance management method for an information processing apparatus according to the present embodiment is applied to the disk array apparatus 601 having the above configuration. explain.

In step 101, the occurrence of a failure is monitored. In step 102, the generated fault information is reported to the fault recovery support center 602. In step 103 and step 104, when the notification of the fault information is received, the fault recovery support center 602 searches the fault countermeasure DB 908 for an event 908h that matches the reported fault information, and detects the corresponding fault countermeasure ID 908a.

At this time, the failure countermeasure I is stored in the failure countermeasure DB 908.
If D908a cannot be detected, the failure information is analyzed in step 113. In step 114, as a result of the failure analysis, if it is determined that the failure is the same as the failure countermeasure ID 908a already registered in the failure countermeasure DB 908, A new event 908h is provided for the fault countermeasure ID 908a determined to be the same at 115, and fault information is registered.
The failure countermeasure ID 908a at this time is obtained in step 116, and the process proceeds to step 105.

However, as a result of the failure analysis in step 114, if it is determined that the failure is not registered in the failure countermeasure DB 908, the process proceeds to step 117. If the analysis result is determined to be a failure due to a software defect, the process proceeds to step 117. At 118a, a new fault countermeasure ID 908a is newly set in the fault countermeasure DB 908, and the corresponding subject 908b to event 9
08h and the like, and step 118b
In step 118c, the source code 1000a is corrected and the fault countermeasure ID 1002 and the countermeasure content 1003 are embedded. Further, in step 118c, the source code 1000a is compiled or assembled to include the fault countermeasure ID 1002 and the binary including the countermeasure content 1003. Of the load module 1001 of step 1
18d, the generated microprogram 1000
(Load module 1001) is registered in the micro DB 909.

If it is determined in step 117 that the failure is caused by a hardware defect, in step 119, a separate response such as hardware replacement is performed.

In step 105, the micro DB 909
From this, a binary microprogram 1000 (load module 1001) on which a fault measure has been taken is obtained.
In step 106, the previously acquired microprogram 1000 is searched in binary, and the previously detected failure countermeasure I
Code that matches D908a (failure countermeasure ID 1002)
Search for If there is no matching code, the process returns to step 105 and the same operation is repeated.

If a code (fault countermeasure ID 1002) that matches the fault countermeasure ID 908a is detected in step 107, the load module name and microprogram version are stored in step 108. Step 109
If another microprogram 1000 including the matching code (failure countermeasure ID 1002) exists, the process proceeds to step 105 and the same operation is repeated, and if another microprogram 1000 does not exist, it is stored in step 108. The microprogram 1000 is transmitted to the failed disk array device 601 in step 110.

If a plurality of load modules in which the failure countermeasure ID 1002 corresponding to the target failure countermeasure ID 908a is found by repeating the processing of steps 105 to 109, for example, step 1 is executed.
At 10, a process of selecting and sending the load module of the version closest to the software version of the operating load module is performed. The reason is that if the running microprogram 1000 is updated to the latest one half apart, unexpected trouble may occur,
This is because the update is performed by the microprogram 1000 that is close to half of the currently operating ones within a range in which necessary fault measures have been implemented. If there is no such concern, it is needless to say that the latest version may be unconditionally updated.

In step 111, the microprogram 1000 transmitted in step 110 is received by the SVP 707 of the failed disk array device 601. In step 112, the received microprogram 10
Using 00, the microprogram that is operating in the microexchange unit 810 is updated. In this way, the automatic update of the microprogram is performed in response to the occurrence of a failure in a series of flows.

Also, a fault countermeasure ID 1002 (908a)
Is embedded in the load module 1001, it is possible to manage the failure countermeasures in units of the load module. And the load module 10 in which the failure has been taken
01 can be downloaded via the network 603 and updated.

Also, the operating disk array device 601
In this case, an autonomous access is performed with reference to the failure countermeasure DB 908 and the micro DB 909 of the failure recovery support center 602, and the failure countermeasure ID 1002 embedded in the micro program in the micro DB 909 is searched (for example, the system operates on its own system). Troubleshooting ID 1002 embedded in the microprogram 1000 inside
By comparing with the running microprogram 10
After the trouble countermeasure of 00, it is possible to check whether or not the microprogram 1000 provided with the new trouble countermeasure exists in the micro DB 909. And micro D
Compared to the microprogram 1000 in B909,
When it is determined that there is an unexecuted failure countermeasure in the active microprogram 1000, that is, when it is determined that the active microprogram 1000 is a microprogram 1000 with a potential for failure occurrence,
An alert is sent to maintenance personnel indicating that a potential failure may occur in the operating microprogram 1000. If maintenance personnel instructs the replacement of the program, the microcontroller 1000 that has taken measures as in the update operation described above is notified. The program 1000 is downloaded from the micro DB 909 of the failure recovery support center 602, and the operating micro program 1000 of the disk array device 601 is updated. As a result, preventive maintenance for preventing the occurrence of a failure can be performed.

An example of the voluntary software maintenance management operation of the disk array device 601 at any occasion other than the above-described failure occurrence occasion is illustrated in the flowchart of FIG.

That is, the SVP 707 provided in the disk array device 601 monitors the opportunity to voluntarily access the failure recovery support center 602 (step 20).
1). This opportunity may be determined automatically in advance by determining the access time of a timer or the like, or may be any occasion, such as being performed at any time by a maintenance manager's instruction.

When it is determined that the access to the failure recovery support center 602 has been triggered, the SVP 707 reads, for example, the failure countermeasure ID 1002 embedded in the microprogram 1000 running on its own device, and uses the readout as the key information. A check request is sent to the center 602.
In the failure recovery support center 602, the failure countermeasure ID 1002 of the key information sent from the SVP 707 and the failure countermeasure D
B908 is compared with the failure countermeasure ID 908a for the same type of microprogram 1000 (step 20).
2) Send the collation result to the SVP 707 that sent the key information. At this time, if necessary, the countermeasure contents 908e of the fault countermeasure determined to have not been performed may be transmitted together with the verification result.

The SVP 707 stores the failure countermeasure DB 9
08, there is a fault countermeasure ID 908a that is present in the fault countermeasure ID 908a for the same type of microprogram 1000 and does not exist in the fault countermeasure ID 1002 of the key information of the active microprogram 1000, that is, the active microprogram 1000 has no fault countermeasure ID 908a. If it is determined that the same type of microprogram 1000 that has been subjected to the implemented failure countermeasure exists on the side of the failure recovery support center 602 and that there is a possibility that an unexecuted failure countermeasure may occur (failure potential). (Step 203) First, the microprogram 1000 in operation by the maintenance manager of the own device.
In step 204, a warning is issued to the effect that there is an unexecuted failure countermeasure and that the failure may occur. At this time, the countermeasure content 908e of the fault countermeasure that has been determined not to be performed may be displayed.

The maintenance manager who receives the warning may timely, if necessary, determine whether the failure has been recovered.
02 The latest microprogram 100 that has already been fixed
0 and download the running microprogram 10
Preventive maintenance can also be performed to replace with 00 (step 205).

If it is determined in step 203 that there is no fault potential, the fact is reported to the maintenance manager as necessary (step 206).

As described above, irrespective of whether or not a failure has occurred in the disk array device 601, the SVP 707 side of the disk array device 601 spontaneously operates.
Preventive maintenance can be performed in a timely manner.

In the above description of the embodiment, a case where the present invention is applied to the maintenance management of a disk array device 601 operating under a specific host computer 701 as a system to be managed is described. However, it is not limited to this.

For example, a storage area network 400 (Storage Area Network: S) exemplified in FIG.
AN) can also be applied to maintenance management.

That is, in the SAN 400, a plurality of disk array devices 401 are connected to a high-speed information network 402.
To configure a virtual large-capacity external storage device, and connect a plurality of upper devices 403 such as an external mainframe computer, an open system server, and a personal computer to an arbitrary connection interface 404.
This is a system that provides a data storage service by connecting via the Internet.

A plurality of disk array devices 401 of the SAN 400 are collectively managed and operated under the control of the SAN management center 405 (corresponding to the above-mentioned SVP 707) via the information network 402, and furthermore, the SAN management center 405
Is connected to the maintenance center 406 (corresponding to the above-described failure recovery support center 602) via the public line 407.

Each upper device 403 is connected to another upper device 40.
3 so that the storage area allocated to the host device 403 can be used as a virtual file system or a storage format corresponding to the host device 403 without being aware of the SAN 400.
Based on the desired internal storage format and file system, a mutual conversion service of the storage format is performed according to the required specifications of each of the plurality of higher-level devices 403.

In this case, the owner of each higher-level device 403 does not need to have its own external storage device.
By receiving the data storage service from the 0 provider, there is an advantage that benefits such as reduction in purchase costs and maintenance management costs related to the external storage device can be obtained.

In such a SAN 400 as well, by applying the maintenance management method for the information processing apparatus of this embodiment,
The AN management center 405 has the function of the SVP 707 described above, and the maintenance center 406 has the failure recovery support center 6 described above.
By providing the function 02, maintenance management of software such as a microprogram specified in each disk array device 401 can be efficiently performed, and preventive maintenance can be performed.

As described above, according to the embodiment of the present invention, when a failure occurs in the disk array device 601 or the like at the disk array device installation site 604, the failure recovery support center 602 via the network 603 triggers the failure. Downloading the microprogram with the countermeasures, and performing the replacement work without the intervention of maintenance personnel, quickly and surely prevent early failure of the external storage subsystem such as the disk array device 601 without burdening maintenance personnel. Recovery can be achieved.

The load module 1 such as a microprogram used for controlling the disk array device 601
By embedding the fault countermeasure ID 1002 and the countermeasure content 1003 in the binary code 001, the load module 10 can be loaded without requiring a special external database or the like.
01 alone, it is possible to centrally manage the contents of the fault measures applied to the load module 1001 and the microprogram without the need for complicated database management or the like.

Conventionally, if it is attempted to manage a fault measure for each load module level, the management becomes complicated.
In the present embodiment, the relationship between the individual load modules 1001 and the history of the failure countermeasures can be easily grasped as described above. Maintenance work such as correction and update can be performed in detail for each load module 1001 with a small load module, and the time required for replacement work can be shortened by reducing the load on the communication path when transferring updated software via the network 603 and shortening the communication time. can do.

The SVP of the disk array device 601
707 side voluntarily triggers network 60
3 of the failure recovery support center 602 via the
08, etc., it is possible to determine whether the operating microprogram is software having the potential for failure occurrence, and if necessary, update to a microprogram that has been subjected to failure countermeasures. Preventive maintenance to prevent occurrence is possible.

Although the present invention has been specifically described based on the embodiments, the present invention is not limited to the above-described embodiments. For example, a disk device is exemplified in the above-described embodiments. However, the present invention can be widely applied not only to the disk array device but also to general information processing systems and the like.

For example, the present invention can cope with software upgrades (those without failure) by adding (embedding) identifiers to individual versions of software.

[0074]

According to the present invention, the maintenance and management of software mounted on a plurality of information processing apparatuses distributed and arranged can be efficiently performed with high reliability. .

According to the present invention, maintenance and operation of binary software mounted and operated on an arbitrary information processing apparatus can be efficiently performed with high reliability.
The effect is obtained.

According to the present invention, there is an effect that maintenance and operation of binary software mounted and operated on an arbitrary information processing apparatus can be performed finely and quickly in smaller size units.

According to the present invention, it is possible to obtain an effect that, upon the occurrence of a failure, a program in which the failure has been prevented is downloaded via a network, and the program can be replaced without human intervention.

According to the present invention, the failure portion is estimated for a plurality of load modules constituting the executable program, and the update can be performed for each load module. The effect is that it can be achieved.

According to the present invention, the information processing apparatus in which the software is installed spontaneously accesses the maintenance support center via the network to judge whether or not the running program has a defect, and And preventive maintenance can be performed.

According to the present invention, by embedding the past troubleshooting contents as a binary code in an executable microprogram, it is possible to centrally manage the microprogram version and the troubleshooting contents. Can be

[Brief description of the drawings]

FIG. 1 is a flowchart illustrating an example of an operation of a maintenance management method for an information processing apparatus according to an embodiment of the present invention.

FIG. 2 is a conceptual diagram illustrating an example of a configuration of a database used in a maintenance management method for an information processing apparatus according to an embodiment of the present invention.

FIG. 3 is a conceptual diagram showing an example of information embedded in software in the information processing apparatus maintenance management method according to an embodiment of the present invention.

FIG. 4 is an explanatory diagram showing an example of a source code of software to be maintained and managed in the information processing apparatus maintenance management method according to an embodiment of the present invention;

FIG. 5 is an explanatory diagram showing, by a hexadecimal dump, an example of a binary executable module after compiling software to be maintained and managed in the information processing apparatus maintenance management method according to an embodiment of the present invention; is there.

FIG. 6 is a conceptual diagram illustrating an example of a configuration of an information processing system in which a method for maintaining and managing an information processing apparatus according to an embodiment of the present invention is performed.

FIG. 7 is a conceptual diagram illustrating an example of a configuration of a disk array device that is an example of an information processing device that performs a maintenance management method for the information processing device according to an embodiment of the present invention.

FIG. 8 is a conceptual diagram showing an example of a configuration of a service processor provided in the disk array device illustrated in FIG.

FIG. 9 is a conceptual diagram showing an example of a configuration of a failure recovery support center for performing remote maintenance of a disk array device according to an embodiment of the present invention.

FIG. 10 is a conceptual diagram showing an example of a storage state of a microprogram in control storage of a disk array device which is one embodiment of the information processing of the present invention.

FIG. 11 is a flowchart showing a modification of the operation of the information processing apparatus maintenance management method according to the embodiment of the present invention;

FIG. 12 is a conceptual diagram illustrating an example of a configuration of a storage area network as a modification of the information processing apparatus according to an embodiment of the present invention.

[Explanation of symbols]

400: storage area network, 401: disk array device, 402: information network (first information network), 403: host device, 404: connection interface, 405: SAN management center, 406: maintenance center, 407: public line ( Second information network), 601: Disk array device, 602: Failure recovery support center, 603: Network, 604: Disk array device installation site, 605: Local area network, 606: Local area network, 701
ホ ス ト Host computer 702… Host I / F control unit
702a: control storage, 703: Disk control unit, 703
a: control storage, 704: disk device, 705: common bus, 706: shared memory, 707: service processor, 800: central processing unit, 801: display, 8
02, keyboard, 803, mouse, 804, floppy disk drive, 805, hard disk drive, 806, network driver, 807, common bus in SVP, 808, fault monitoring unit, 809, fault notification unit,
810: Micro exchange unit, 900: Central processing unit, 90
1 ... Display, 902 ... Keyboard, 903 ... Mouse, 904 ... Floppy disk drive, 905 ... Hard disk drive, 906 ... Network driver, 907 ... Common bus, 908 ... Troubleshooting database, 908a ... Troubleshooting ID, 908b ... Subject, 908
c: phenomenon, 908d: cause, 908e: countermeasures, 90
8f: occurrence program version, 908g: countermeasure program version, 908h: event, 909: microprogram database, 910: failure countermeasure ID detection program, 911: binary search program, 912
... micro sending program, 1000 ... micro program, 1000a ... source code, 1001 ... module, 1001 ... load module, 1002 ... failure measure ID, 1003 ... measure contents.

──────────────────────────────────────────────────続 き Continued on the front page (51) Int.Cl. ⁷ Identification symbol FI Theme coat ゛ (Reference) G06F 13/00 351 G06F 15/16 620B 15/16 620 15/177 678A 15/177 678 9/06 420M F Terms (reference) 5B042 GA04 JJ02 5B045 AA00 BB12 BB28 BB47 GG06 JJ02 JJ09 JJ49 5B065 BA01 ZA07 5B076 AC07 EA06 5B089 GB03 JA34 JA35 JB07 JB17 KA13 KB09 KC28 KC44

Claims (19)

[Claims] At least one information processing device operated by software and a maintenance support center for managing the software are connected via an information network, and when a failure occurs in the information processing device, the information is embedded in the software. By referring to the identifier of the software
A maintenance management method for an information processing apparatus, comprising: transmitting the software with the measure against the failure from the maintenance support center to the information processing apparatus to update the software in the information processing apparatus. 2. The method according to claim 1, wherein at the time of creating the software, a fault countermeasure identification indicating a type of a fault countermeasure applied to the software so far in the software. The maintenance support center reads the failure countermeasure identification information embedded in each of the plurality of pieces of software, identifies the software that has dealt with the failure of the information processing apparatus, and specifies the information processing. A maintenance management method for an information processing device, wherein the method is transmitted to the device. 3. The maintenance management method for an information processing apparatus according to claim 1, wherein the software includes a plurality of modules, and the software is applied to each of the modules so far. And transmitting the software from the maintenance support center to the information processing device and updating the software of the information processing device in units of the module. A maintenance management method for an information processing apparatus characterized by the following. 4. A method according to claim 1, wherein said information processing device is a disk array device, and said software is a microprogram. Maintenance management method. 5. An information processing apparatus operated by software and a maintenance support center for managing the software are connected via an information network, and the software running on the information processing apparatus and the maintenance support are arbitrarily triggered. A failure countermeasure that has been implemented for each of the plurality of software stored in the center is compared and determined via the information network, and the failure countermeasure that has not been implemented in the running software is stored in the maintenance support center. If the software has been applied, the first operation of issuing a warning of a potential failure occurrence to the maintenance manager of the information processing device, and the software running on the information processing device, A second operation of updating with the software stored in the maintenance support center via an information network; A maintenance management method for an information processing apparatus, wherein at least one operation is performed. 6. The maintenance management method for an information processing apparatus according to claim 5, wherein at the time of creating the software, a failure countermeasure identification indicating a type of a failure countermeasure applied to the software so far in the software. Information is embedded, and a comparison is made between the implemented troubleshooting measures based on the troubleshooting countermeasure identification information embedded in each of the software running the information processing apparatus and the software stored in the maintenance support center. A maintenance management method for an information processing apparatus, comprising: 7. The maintenance management method for an information processing apparatus according to claim 5, wherein the software includes a plurality of modules, and the software is applied to each of the modules so far. A failure management identification information indicating the type of the failure management implemented, and performing the comparison determination in units of the module. 8. A method according to claim 5, wherein said information processing device is a disk array device, and said software is a microprogram. Maintenance management method. 9. An information processing apparatus including a control unit operated by software and a network interface connected to a maintenance support center via an information network, wherein a fault monitor for monitoring the occurrence of a fault in the information processing apparatus is provided. Function, a failure notification function for notifying the occurrence of the failure to the maintenance support center, and software for receiving, from the maintenance support center, the software that has been subjected to the failure countermeasure against the failure, and replacing the software with an operating software. An information processing apparatus comprising control logic including an exchange function. 10. A plurality of storage devices, each operated by software, accessed from a plurality of higher-level devices via a first information network, and performing maintenance management of the storage devices via the first information network. An information processing apparatus including a management device for performing the management, and a maintenance support center connected to the management device via a second information network, wherein the management device monitors the occurrence of a failure in the storage device. Means, failure reporting means for notifying the maintenance support center of the occurrence of the failure, and software for receiving from the maintenance support center the software provided with the failure countermeasure for the failure and replacing the software with an operating software. An information processing apparatus comprising: an exchange unit. 11. The information processing apparatus according to claim 9, wherein the software has embedded therein fault countermeasure identification information indicating a type of a fault countermeasure performed so far on the software. Information processing device. 12. The information processing apparatus according to claim 9, wherein the control logic is configured to store the failure countermeasure identification information embedded in the running software and the maintenance support center at an arbitrary opportunity. And comparing with the trouble countermeasure identification information embedded in the software, and when a trouble countermeasure that has not been implemented in the running software is performed in the software on the maintenance support center side, the information processing is performed. A function of alerting a maintenance manager of a potential failure occurrence in the device and, if necessary, replacing the operating software with the software stored in the maintenance support center. Information processing device. 13. The information processing apparatus according to claim 9, 11 or 12, wherein the software is composed of a plurality of modules, and for each of the modules, a countermeasure against a fault that has been applied to the module so far is provided. An information processing apparatus, wherein failure countermeasure identification information indicating a type is embedded, and the software is exchanged for each module. 14. The information processing apparatus according to claim 9, wherein the control unit is a host interface control unit that controls transmission and reception of information to and from a higher-level device; A disk interface control unit that controls transmission and reception of the information to and from a plurality of stored disk storage devices, wherein the information processing device includes a plurality of the disk storage devices,
A disk array device that constitutes a disk array in which the information exchanged with the higher-level device and redundant information generated from the information are stored in a distributed manner; An information processing device, which is a service processor that performs management. 15. A method for creating software, comprising: a first step of creating or changing a source code; and a second step of converting the source code into a binary executable code mounted on an arbitrary information processing apparatus. In the first step, when a change is made to the source code as a countermeasure for a fault detected during the operation of the information processing apparatus, the fault countermeasure identification information indicating the type of the fault countermeasure is stored in the first step. A method for creating software, wherein identification information is added to the source code in a format inherited up to the execution code, and the failure countermeasure identification information is embedded in the execution code obtained in the second step. 16. The software creation method according to claim 15, wherein, when the execution code is composed of a plurality of load modules, the failure countermeasure identification information relating to each of the load modules is embedded. How to create software. 17. Binary software implemented in an information processing apparatus, wherein failure countermeasure identification information indicating a type of a failure countermeasure performed so far for the software is embedded in a part of the software. Software characterized by that. 18. The software according to claim 17, wherein the software includes a plurality of load modules, and the failure countermeasure identification information is embedded in each of the load modules. 19. The software according to claim 17, wherein the information processing device is a disk array device, and the software is a microprogram.