JPH06230992A - Computer system and method for recovery of computer system from fault - Google Patents

Abstract

PURPOSE:To provide the computer system and its fault recovery method which are low in cost and highly reliable. CONSTITUTION:If a fault occurs to one constituent element (e.g. compressing mechanism 113 of disk device 106) in a computer system equipped with plural constituent elements, a substitute constituent element (emulation by CPU 114, etc.) which functions as a substitute for the constituent element is searched for and made to perform substitute processing. Further, another device (disk device 107) or a host processor 101 is requested to perform processing substituting the constituent element where the fault occurs, thereby performing substitutive processing. Consequently, even when many devices are connected, the reliability never decreases and the low-cost, high-reliability system can be structured.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a computer system and its failure recovery method, and particularly to a failure recovery method and a failure recovery method suitable for application to a computer system equipped with a file system which requires high reliability and high expandability. Regarding computer systems.

[0002]

2. Description of the Related Art As a method for improving the reliability of hardware, techniques such as hardware duplication and code error correction are generally used. For example, even in a disk system, there are many systems that ensure high reliability by multiplexing storage disk drives, control processors, or data paths.

In the multiplexing of storage disk drives, the same data is stored in a plurality of disk drives, and if one of the disk drives or a control device controlling the disk drive fails, the same data is stored. By accessing another disk drive, the processing is not interrupted.

There are roughly two types of methods for storing the same data in a plurality of disk drives. One is a method in which software (generally an operating system) issues input / output instructions for storing data in a plurality of disk drives. The other is a method in which the operating system issues one I / O command, and the hardware control is performed so that the disk control device automatically stores in one or more I / O commands in a plurality of disk drives. .

At present, the latter disk drive multiplexing by hardware control has come to be performed for reasons such as reduction of hardware cost and reduction of software load. In such an environment,
When access to one of the disk drives becomes impossible, the hardware detects the failure and automatically performs control to substitute another disk drive. Such control is described in, for example, Japanese Patent Application Laid-Open No. 3-226825.

On the other hand, also in the multiplexing of control processors and the multiplexing of data paths, similarly, when a failure occurs, a control processor and a data path that have not failed are used, thereby ensuring high reliability. In general, the multiplexing is performed at the location where the failure is most likely to occur, or at the core of the system, such as the system bus, among the constituent elements of the system.

[0007]

The above-mentioned multiplexing technique has an advantage that reliability can be improved relatively easily. But in a sense, it's also a waste of resources. Although the hardware cost is lower than before, the cost of multiplexing becomes large in a large-scale system in which a large number of these multiplexed systems are connected.

Further, in the above-mentioned conventional technique, the predetermined multiplicity cannot be easily changed. For example, it is difficult to easily triple or quadruple a system originally designed for duplexing. This is because it is difficult for a system initially designed with duplexing to incorporate hardware for triple and quadruple mounting.
Also, the cost is increased due to the cost of changing the specifications of the hardware for multiplexing control. In these cases,
Normally, higher level software must perform multiplexing.

In view of the above-mentioned problems in the conventional example, it is an object of the present invention to provide a low cost and highly reliable computer system and its failure recovery method.

[0010]

In order to achieve the above object, the present invention is a computer system having a plurality of components, and a detection means for detecting a failure of the components,
When a failure occurs in a certain constituent element, a searching means for searching for an alternative constituent element which functions by substituting the constituent element and a processing for replacing the failed constituent element with respect to the searched alternative constituent element It is characterized by having a management means for making it.

Further, in a peripheral device connected to a computer system or a network including a host processor, the peripheral device including a plurality of components, a detection means for detecting a failure of the above components, and a certain component When a failure occurs, a search means for searching for an alternative constituent element that functions by substituting the failed constituent element among other internal constituent elements, and a failure occurs for the searched alternative constituent element. And a management means for performing a process of substituting the constituent elements.

The alternative component may include, for example, a processor capable of executing a program, and the processor may be used to simulate the operation of the component in which the failure has occurred by emulation or simulation.
Further, when the component in which the failure has occurred is a data compression mechanism, the processor may emulate data compression and perform a process of replacing the data compression mechanism.

The searching means generates a data string including data indicating a constituent element in which a failure has occurred and data indicating an alternative constituent element that replaces the constituent element, sends the data string to the managing means, and the managing means. May perform the alternative process based on the data string.

Further, there is provided a configuration management table which stores data indicating whether or not a failure has occurred in the constituent element and data representing a process of substituting the constituent element when the failure occurs, and the detection means comprises the detecting means. Alternatively, the search means may refer to the configuration management table to detect a failure of a component, and the search unit may refer to the configuration management table to search for a process for substituting the failed component. .

Further, when a failure of each of the constituent elements is detected, the constituent element is made to repeat the same operation again, and when the constituent element normally operates by repeating a predetermined number of times or less, the constituent element is impaired. It is also possible to continue the operation assuming that the occurrence of the above-mentioned condition has not occurred, count the number of times the normal operation is performed by such a repetitive operation, and notify the outside to that effect when the number of times exceeds a predetermined value.

The above components may be multiplexed. The management means itself may be a component capable of performing a process of substituting the component having the failure. The constituent elements are constituent elements that constitute a file system of a computer system, for example.

Further, the present invention comprises a host processor,
A computer system comprising a plurality of peripheral devices, each peripheral device comprising a plurality of components, in a computer system, a detection means for detecting a failure of the component of the peripheral device, and a component When a failure occurs,
The present invention is characterized by including a management unit that causes a peripheral device other than the peripheral device including the constituent element or the host processor to perform a process of substituting the constituent element in which a failure has occurred.

The management means generates and sends a data string including an identifier indicating a failure recovery processing request, an identifier indicating a failed component, and an identifier indicating a processing to be requested, thereby transmitting the data string. The peripheral device or the host processor may be made to perform the alternative process. Further, the management means may transmit the data string to a plurality of peripheral devices, and the peripheral device capable of processing the request stored in the data string may perform the alternative process based on the data string. Good.

Further, there is provided a configuration management table which stores data indicating whether or not a failure has occurred in the constituent element and data representing a process or alternative means for replacing the constituent element when the failure occurs, The detection means is
By referring to the configuration management table, a failure of a component is detected, and the management unit refers to the configuration management table,
It may be determined where to perform the alternative process.

The peripheral devices may be multiplexed. Further, the peripheral device may be a file system of a computer system.

Further, the present invention comprises a host processor,
A computer system having a plurality of file systems capable of communicating with each other, each file system having a plurality of constituent elements including a disk device, and by cross-calling between the file systems, other file systems mutually In a computer system that can access a disk device of the system, a means for detecting a failure in the above-mentioned file system component, and a file system other than the file system including the component when a failure occurs in a component other than the disk device On the other hand, a means for requesting a process for substituting a component having a failure is provided, and the file system which has received the request performs the alternative process based on the request, and the failure causes by the cross call. A file system disk containing the components The device, and wherein the direct access.

A peripheral device of a computer system according to the present invention is a peripheral device connected to a computer system having a host processor or a network, and is a peripheral device having a plurality of constituent elements. A means for detecting a failure of an internal constituent element, and a means for, when a failure occurs in a certain constituent element, transmitting a data string requesting a process for substituting the failed constituent element to another peripheral device. When the processing result of the requested processing is received from another peripheral device, a means for continuing the processing by bypassing the component causing the failure and a component causing the failure from the other peripheral device are provided. When receiving a data string requesting a substitute process, a process is performed based on the request of the data string, and a processing result is returned to the sender of the data string. And it said that there were pictures.

Further, in a peripheral device connected to a computer system or a network including a host processor, the peripheral device including a plurality of components, means for detecting a failure of a component inside the peripheral device itself. And, when a failure occurs in a certain component, means for sending to the host processor a data string requesting a process for replacing the failed component, and a process of the requested process from the host processor. When the processing result is received, a means for bypassing the above-mentioned faulty component and continuing the processing is provided.

Further, the present invention comprises a host processor,
In a computer system including a peripheral device connected to the host processor, the peripheral device is provided with means for requesting another peripheral device or the host processor to perform a process that is normally performed inside the own device. And

Further, in a computer system including a plurality of constituent elements including a processor capable of executing a program, the operation of the constituent elements other than the processor is emulated or simulated by the processor, and a processing result by the constituent element is obtained. It is characterized by being provided with means for comparing the result of emulation or simulation by the processor.

Furthermore, a computer system failure recovery method according to the present invention is a failure recovery method for a computer system having a plurality of components, wherein a step of detecting a failure of the above-mentioned components and a failure of a certain component occur. Then, a step of searching for an alternative constituent element that functions by replacing the constituent element, and a step of causing the searched alternative constituent element to perform a process of substituting the failed constituent element are provided. Characterize.

A computer system comprising a host processor and a plurality of peripheral devices, each peripheral device having a plurality of components, in a failure recovery method for a computer system, the components of the peripheral device. The steps to detect the failure of, and when a certain component fails,
A step of causing a peripheral device other than the peripheral device including the constituent element or the host processor to perform a process for substituting the constituent element in which a failure has occurred.

[0028]

In a computer system having a plurality of constituent elements, when a certain constituent element has a failure, an alternative constituent element that functions by substituting the constituent element is searched for, and the alternative constituent element has a failure. Since the processing for substituting the elements is performed, it is possible to perform the processing equivalent to the hardware that has caused a failure by, for example, emulation or the like, and thereby a low-cost and highly reliable system can be constructed.

Further, since it is possible to request the processing for substituting the faulty component to another peripheral device or the host processor, the fault recovery request is issued to any communicable peripheral device or host processor. It is possible,
The result can be transferred to the device in which a failure has occurred, and a highly reliable system that does not interrupt the processing can be constructed.

[0030]

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

[Embodiment 1] FIG. 1 shows a computer system according to an embodiment of the present invention, and a computer system using a disk system (peripheral device) to which the failure recovery method of the present invention is applied. It is a thing.

This system is roughly divided into host processors 101 and 102 and disk devices 106 and 107.
And channel cables 181, 18
Connected by two. Channel cable 181,1
To control the host processor 101, 102
Input / output processors (IOP) 103 and 104 are provided on the side,
Channel adapters 105 are installed on the disk device side. The channel adapter 105 and the disk devices 106 and 107 are connected to the system bus 183.

The host processors 101 and 102 issue input / output requests to the disk devices 106 and 107, and the disk devices 106 and 107 that have received the request perform data read / write (READ / WRITE) according to the requested contents. Then, the result is notified to the host processors 101 and 102. The disk devices 106 and 107 are box images in this embodiment. Multiple disk systems (file systems) within one enclosure, such as the disk device 106
May be included.

The disk device 106 includes configuration management tables 111 and 131, failure management units 112, 116 and 132,
136, option mechanism (OP) 113, 133, control processor (CPU) 114, 117, 134, 13
7, cache memories 115 and 135, and disk drives 118, 119, 138, and 139. Similarly,
The disk device 107 includes a configuration management table 151, failure management units 152 and 156, an option mechanism 153, control processors 154 and 157, a cache memory 155, and disk drives 158 and 159. As can be seen from the figure, the disk device 106 has two disk systems, a left side and a right side.

Configuration management tables 111, 131, 151
Manages information about a failure of each component in the disk devices 106 and 107, respectively. Fault management unit 1
12, 116, 132, 136, 152 and 156 are one of the features of the present invention, and the disk devices 106 and 107.
This is a part that manages the processing so that it does not stop as much as possible when each component inside fails. The fault management units 112, 116, 132, 136, 152, 156 are
Each is connected to the system bus 183.

Optional mechanism 113, 133, 153
Is a mechanism for enhancing the function of the disk device, and one or more functions convenient for the user can be set. In this embodiment, the compression mechanism will be described below as an example, but the compression mechanism is not limited to this.

Control processors 114, 117, 134,
137, 154 and 157 are disk devices 106 and 10
7 and controls, for example, the host processors 101, 10
2 interprets commands from the cache memory 11
Data management in 5,135,155 is performed. Disk drives 118, 119, 138, 139, 15
8, 159 stores user data and the like.

Further, 121 to 126, 141 to 146
161 to 166 are configuration management tables 111 and 111, respectively.
131, 151 update / reference. 127,14
Reference numerals 7, 167, 128, 148, 168 are paths for directly transferring data to the next processing component without being controlled by the optional mechanism or control processor. Details of these will be described later.

FIG. 2 is a flow chart showing an example (outline) of the flow of failure recovery in this embodiment.

When a failure occurs in a certain component, it is first checked whether or not the component is multiplexed (step 201). As a result, if there is a component which is multiplexed and can be substituted (step 205), the component which can be substituted is substituted and the processing is continued.

When the multiplexing is not available (when the constituent elements are not multiplexed or when the constituent elements are multiplexed but cannot be substituted), it is checked whether or not an equivalent function can be emulated (step 202). Here, the emulation means that the processing originally executed by the hardware is replaced by a software means. If the emulation is possible, the emulation is executed and it is determined whether or not the emulation processing is normally completed (step 206). If the processing ends normally, the processing continues.

Further, when the emulation is impossible or the emulation is abnormally terminated, it is checked whether the same processing can be requested to another disk device within a communicable range of the disk device (step 203). If it can be requested to another device, the process is requested to the other device to be executed, and it is determined whether or not the process is normally completed (step 207). If the process ends normally,
Continue processing.

Further, when the request to the other device is impossible or the process requested to the other device is abnormally terminated, it is checked whether the same process can be requested to the host (step 2).
04). If it is possible to request the host, the host is requested to execute the process, and it is determined whether the process has ended normally (step 208). If the processing ends normally, the processing continues. When the request to the host is impossible or the processing requested to the host ends abnormally, the host that issued the I / O request is notified that an unrecoverable failure has occurred, and then ends abnormally.

In this way, in this embodiment, the failure recovery means is multistage. Conventionally, at most, the failure recovery was made only by substituting the multiplexed constituent elements, but the reliability of the apparatus can be further improved by providing the failure recovery means in multiple stages as shown in FIG.

Next, the fault management units 112, 132, 152
Will be described in detail. Three fault management units 112,
Since the configurations and operations of 132 and 152 are the same, the failure management unit 112 will be described below, and the description of the failure management units 132 and 152 will be omitted.

FIG. 3 shows a block diagram of the fault management unit 112. 301 is a command analysis processor, 302 is a command buffer, 303 is a data buffer, 304 is a failure detection processor, 305 is a failure management processor, 306
Is a memory in which a microprogram to be executed by the fault management processor is stored, and 311 is a selector for switching the transfer destination of the data in the data buffer. Memory 306
A microprogram 307 requesting emulation, a microprogram 308 requesting alternative processing by an external device, and a microprogram 309 requesting alternative processing by the host are stored.

The outline of the processing in the fault management unit 112 will be described. First, the command transferred via the system bus 183 is interpreted by the command analysis processor 301,
It analyzes which component in the disk system it needs to execute the command. The result is transferred to the fault detection processor 304. In response to this, the failure detection unit 304 determines whether or not the constituent elements required for the processing are in the executable state. This determination is
This is performed by referring to the configuration management table 111.

When a component required for processing has a failure, the failure detection processor 304 refers to the configuration management table 111 again, and is there an alternative processing method for substituting the failed component? Search for something.

If an alternative processing method is found, the information is transferred to the fault management processor 305, and an alternative processing is requested. Fault management processor 3 that received the request
05 executes the microprogram in the memory 306 in response to the request. In addition, the fault management processor 30
5 switches the data transfer destination of the selector 311 based on where the alternative process is executed.

In this embodiment, as alternative processing (alternative processing), as shown in FIG. 2, in addition to the method of multiplexing the same constituent elements, the method of emulation, the method of requesting processing to an external device, and A method for requesting processing to the host is provided. Therefore, the fault management processor 305 uses the emulation request program 307 when performing the alternative process by emulation, the external device request program 308 when requesting a process to an external device, and the host when requesting the process to the host. The request program 309 will be executed respectively.

By the above processing, even if a failure occurs, the processing can be continuously executed without interruption.

Next, the fault management units 116, 136 and 156.
Will be described. Three failure management units 116, 136
Since the configuration and operation of 156 are the same, the fault management unit 116 will be described below. In addition, the fault management unit 1
The configuration and operation of 16 are the same as those of the failure management unit 112 described above, and therefore, in the following, particularly different portions will be described.

FIG. 4 is a block diagram of the fault management unit 116 shown in FIG. The components 401 to 411 of the fault management unit 116 are equivalent to the components 301 to 311 of the fault management unit 112 of FIG. However, the failure management unit 116 has few necessary functions. This is because the option mechanism is not managed.

Since the option mechanism is not managed, there is no need to switch the data path to the option mechanism,
Further, since the emulation of the optional mechanism is not requested, it is not necessary to provide the emulation request program in the memory 406. Therefore, in FIG. 4, there is no part corresponding to the data path 312 or the emulation request program 307 of FIG.

In this way, the fault management units 112, 132,
Each of 152, 116, 136, and 156 may have only necessary functions according to the object to be managed. Therefore, the cost can be minimized when the failure management unit is provided.

FIG. 5 shows the structure of the configuration management table 111. The configuration management tables 131 and 151 also have the same configuration.

In FIG. 5, reference numeral 501 denotes a constituent element of the disk system, for example, the compression mechanism 113, the control processors 114 and 117, the cache memory 115, the disk drives 118 and 119. In the column of the component 501 in FIG. 5, “compression mechanism (OP)” means the compression mechanism 113, “control CPU 1” means the control processor 114, and “control CPU 2” means the control processor 117. , "Cache" indicates the cache memory 115, "drive 1" indicates the disk drive 118, and "drive 2" indicates the disk drive 119.

Reference numeral 502 denotes an area for storing information on multiplexing of each component. Here, the component is stored as "1" if it exists alone, as "2" if it is duplicated, and so on. When a constituent element is n-folded, the constituent element has n identical elements therein, and these n elements are called partial elements. The multiplexing information 502 shows whether or not alternative processing by multiplexing is possible. If a subelement of the multiplexed component fails and the subelement becomes unavailable, the value of this field is subtracted by the number of subelements that have failed.

Reference numeral 503 indicates the presence / absence of a fault in the component. This field is marked (marked with "x") when failure recovery due to multiplicity becomes impossible. In the figure,
“O” indicates that the component has no fault, and “x” indicates that the component is faulty and cannot be used. When this field is marked (when a failure occurs), it is necessary to substitute the component by the alternative means 505 described later to continue the processing, or to inform the processing requester that the processing cannot be continued. To judge.

Reference numeral 504 is a field for storing the number of times of occurrence of a failure in the component. Even if a failure occurs, each component may be able to operate normally by retrying several times. This field is a field that stores the number of times it can be used again by retry. By referring to this information, the device administrator can infer that processing may continue due to retries, but if there are too many failures, there may be some cause of failures, and the early warning In addition, the device can be improved. The “fault” in the field 504 has a different meaning from the “fault” in the field 503. The "fault" in the field 503 is a fault in which the constituent element cannot be used.

Reference numeral 505 indicates an alternative means for the component. The alternative means is another means for substituting the constituent element and performing an equivalent process when the constituent element causes a failure (in the case of multiplexing, all of the partial elements). For example, in the case of the compression mechanism 113, alternative means include emulation by a processor, means for requesting compression processing to another device, and means for requesting compression processing to the host. These are stored in the field 505. It is registered.

Configuration management table 1 having the above contents
As shown in FIG. 1, 11 indicates paths 121 to 126 (configuration management table 1) when each component fails.
31 and 151, paths 141 to 146, 161 to 16
It will be updated through 6). That is, the failed component itself updates the configuration management table.

Next, the fault management unit 11 of FIG. 3 will be described in more detail.
2 (the same applies to the failure management unit 116 in FIG. 4).

FIG. 6 shows the format of a command packet transferred from the host to the failure management section. A command packet is a data string in which a processing request, control information, and if necessary, processing data are linked. A command field 601 describes what the command packet requests. A position information 602 indicates where the request in the field 601 is directed. For example, if the command field 601 describes a write (WRITE) request to the disk drive, the position information field 602
The device name, drive name, drive block number, and the like are stored in.

FIG. 7 shows the information described in this position information field and its meaning. Reference numeral 701 shows a specific example of the position information, and 702 shows its meaning. In the position information 701, "device 1" indicates a device name, "VOL1" indicates a disk drive name, and "Block100" indicates a drive block number. As shown in the figure, the location information can be specified by specifying all from the device name to the block number, specifying the device name and disk drive name, specifying only the device name, or where There is a method of designating "ANY" which does not matter.

Referring again to FIG. 6, 603 is a field for describing who issued this command packet and the requester thereof. In the normal case, since the disk input / output request is made from the host, the host identifier is described in this field 603. In the present invention, a certain device may issue a command packet to another device, and therefore, in such a command packet, the device name of the requester is described in this field 603. These will be described in detail later. 604 stores processing data for the command. This field 604 may not be necessary depending on the command.

FIG. 8 is a processing flowchart of the command analysis processor 301 and the failure detection processor 304 of the failure management unit 112 shown in FIG. Steps 801 to 804 show the operation of the command analysis unit 301, and steps 805 to 809 are the failure detection processor 3
The operation of 04 is shown.

In step 801, the command analysis processor 301 reads the packet (for example, FIG. 6) transferred via the system bus 183. Step 8
In 02, the read packet is analyzed, and the command part of the packet (command 601 in FIG. 6, position information 6
02, and the requester 603) to the command buffer 302
Transfer to. Next, in step 803, the data part of the packet (processed data 604 in FIG. 6) is transferred to the data buffer.

Further, in step 804, the command part of the packet is analyzed, and if necessary, the analysis result is sent to the fault detection processor 304. Although FIG. 8 illustrates only the portion (step 804) for determining whether or not the requested command is a process using the compression mechanism 113,
In addition, the cache memory 115 and the control processor 1
Also for 14, it is judged whether or not to use them, and if so, that fact is detected by the failure detection processor 3
04 will be informed.

The command analysis processor 40 shown in FIG.
If it is 1, the control processor 117 and the disk drives 118 and 119 are discriminated whether to use them, and if they are to be used, the failure detection processor 404 is notified of that fact.

Next, in step 805, the fault detection processor 304 searches the configuration management table 111 based on the analysis result from the command analysis processor 301. This search is a search for determining whether or not the component selected in step 804 can be used. Specifically, this is done by referring to the field 503 of the configuration management table 111 of FIG. In step 806, as a result of the search, it is determined whether or not the selected component has a failure.

For example, if the result of the analysis at step 804 indicates that the compression mechanism 113 is used when executing the requested command, at step 805, the compression mechanism 113 of the configuration management table 111 of FIG. Referring to the presence / absence 503 of the failure, in step 806, the compression mechanism 1
It is determined whether 13 is available.

If no fault has occurred in the component in step 806, the requested command can be executed by the normal operation of the component, so the fault management processor 305 is notified of that fact, The processing is transferred to the fault management processor 305. As a result, the fault management processor 305 continues the normal operation when no fault has occurred and executes the command. The process of this fault management processor 305 is as shown in FIG.
This will be described later with reference to 0.

If a failure has occurred in the constituent element in step 806, the constituent element cannot be used. Therefore, the configuration management table 111 is searched again in step 807. Then, in step 808, it is determined whether or not the constituent element (for example, the compression mechanism 113) has an alternative means.

If there is an alternative, the fault management processor 3
05 to that effect and the processing is executed by the fault management processor 3
Move to 05. As a result, the fault management processor 305
Requests the alternative means to process the component having the failure (actually, after retrying a predetermined number of times) to replace the component having the failure. The process of the fault management processor 305 will be described later with reference to FIG.

If there is no alternative means in step 808, the processing requester is notified in step 809 that the failure is unrecoverable.

FIG. 9 shows the fault management when the fault detection processor 304 detects a fault in a component and there is a substitute for that component (sequence from step 808 in FIG. 8 where the process shifts to the fault management processor). Processor 3
The packet to be transferred to 05 is shown.

Reference numeral 901 is a field indicating a component having a failure, and reference numeral 902 is a field storing the number of occurrences of failure of the component. The number of times of failure occurrence is described in the field 504 of FIG. In field 903,
An alternative means (alternative component) for substituting the failed component is described. In the present embodiment, as alternative means of the compression mechanism 113, there are means by emulation, means for requesting compression processing to another device, means for requesting compression processing to the host, etc. The example of the packet when a means is selected is shown.

FIG. 10 shows the fault management unit 112 shown in FIG.
7 is a processing flowchart of the fault management processor 305.

First, in step 1001, it is checked whether or not a failure has occurred in a component necessary for executing the requested processing. If there is no obstacle (when there is no obstacle at step 806 in FIG. 8), the process is continued. If a failure occurs in step 1001 (when there is a failure and there is an alternative means in steps 806 to 808 in FIG. 8), the process proceeds to step 1002.

In step 1002, the transferred packet (for example, FIG. 9) is analyzed, and the component having the failure is retried. Then, in step 1003,
It is checked whether the retry in step 1002 has succeeded. If the retry is successful, the process proceeds to step 1009, and if the retry is unsuccessful, the process proceeds to step 1004. At step 1004, it is checked whether or not the number of retries exceeds a preset value "M". If not exceeded, the process returns to step 1002 and repeats the retry. The number of retries is a predetermined value in step 1004 "
If M ”is exceeded, the alternative means selected by the fault detection processor 304 is used, and the process advances to step 1005.

When the retry is successful in step 1003, 1 is added to the content of the failure occurrence frequency (field 504 in FIG. 5) in the configuration management table in step 1009. Then, in step 1010, it is checked whether or not the added value exceeds the preset value "N". If it exceeds the predetermined value “N”, the process moves to step 1011 to notify the host that there are many faults in the component and to move to step 1012. If it is determined in step 1010 that the failure occurrence frequency does not exceed the predetermined value “N”, the process proceeds to step 1012.

In step 1012, the selector 311 (FIG. 3) is switched to the normal path. For example, when a failure of the compression mechanism 113 in FIG. 3 is detected and the result of the retry is that the compression mechanism 113 becomes normal for the time being, the data to be compressed in the data buffer 303 is transferred to the compression mechanism 113. The path of the selector 311 is the normal path 312.
Switch to.

When the number of retries exceeds the predetermined value "M" in step 1004, it is determined in step 1005 whether the alternative means selected by the fault detection processor 304 is emulation. If the alternative means is emulation, the emulation request is made, and if not, the process proceeds to step 1006. Step 100
At 6, it is determined whether the alternative means is a request to another device. If it is a request to another device, it is executed, and if not, the process proceeds to step 1007. In step 1007, it is determined whether the alternative means is a request to the host. If it is a request to the host, it is executed, and if not, the process proceeds to step 1008.

If the alternative means selected by the failure detection processor 304 cannot be found, the occurrence of an unrepairable failure is notified to the processing requester in step 1008.

Next, a detailed processing procedure of each alternative means selected in steps 1005 to 1007 of FIG. 10 will be described.

FIG. 11 shows a processing flow chart of emulation executed from step 1005 of FIG. The flowchart on the left side of FIG. 10 shows the processing of the emulation request program 307 executed by the fault management processor 305 in FIG. Here, the compression process is requested. The flowchart on the right side of FIG. 10 shows a procedure in which the control processor 114 of FIG. 3 performs a compression process in response to a request for the compression process. Here, the emulation is originally an optional mechanism 113.
Control processor 11 performs processing that must be performed by
It means that the same processing is performed by substituting the micro program of 4.

In FIG. 11, the fault management processor 30
5 switches the selector 311 of FIG. 3 to the path 314 to the control processor 114 in step 1101. As a result, the data in the data buffer 303 is transferred from the original option mechanism 113 to the control processor 114. At step 1102, an emulation request is issued to the control processor 114. Specifically, the control processor 114 is interrupted together with the identifier indicating the emulation request.

Control processor 114 that received the interrupt
After recognizing that it is emulation, in step 1105, the data to be compressed is fetched from the data buffer 303. In step 1106, the operation of the option mechanism 113 is emulated. Specifically, the compression is performed by the same algorithm as the option mechanism 113.

In step 1107, step 1106
Check whether the result of the compression process of is normal. If the compression processing ends abnormally, the process proceeds to step 1108, and the abnormal end is indicated by the failure management processor 305 of the failure management unit 112.
To notify. If the emulation has been normally completed, the compressed data is written in the cache 115 in step 1109. Thereafter, in step 1110, the normal termination is indicated by the fault management processor 305 of the fault management unit 112.
To notify.

The fault management processor 305, which has received the end notification, executes step 1103 in the emulation processing.
And check if it has terminated abnormally. as a result,
If it is an abnormal end, the abnormal end is reported to the failure detection processor 304 in step 1104. Step 1
If the process does not end abnormally in 103, the emulation process ends.

The fault detection processor 304, which has been notified of the abnormal termination, uses the field 50 in the configuration management table 111.
The alternative means for emulation is searched for from No. 5, and if there is an alternative means, the alternative process by the alternative means is tried in the same manner as above. This processing is continued until the processing by the alternative means ends normally or there are no alternative means candidates.

As described above, since the processing is performed by emulation instead of the faulty component, it is possible to obtain almost the same reliability as the multiplexing without having to multiply the costly hardware. It is possible to realize a highly reliable disk system at a cost. The emulation is inferior to the hardware in terms of performance, but there is almost no problem if, for example, the system is such that maintenance is performed within a relatively short time after a failure occurs and parts are replaced.

Further, according to this embodiment, there are the following effects. When a request for using the option mechanism is issued to a disk device not equipped with the option mechanism 113, conventionally, the user is notified that there is no option mechanism, and it is determined that the termination is abnormal. According to the present embodiment, even in that case, it is possible to continue processing by emulation.

FIG. 12 shows a data flow by the emulation. Thick arrows indicate the flow of data.

When a failure occurs in the option mechanism 113, the control processor 114 performs the same processing (emulation) as that of the option mechanism 113, and the compressed data is stored in the cache memory 115 as if the option mechanism 113 operated normally. It indicates that it is stored. Such an alternative process is not limited to the failure of the option mechanism 113, and any process that can be processed by software can be applied.

FIG. 13 shows a processing flow chart of a fault recovery request to another device which is executed from step 1006 of FIG. This process is performed by the fault management processor 305 in FIG.
Request program 308 to be executed by another device
Corresponds to the processing of.

First, in step 1301, the fault management processor 305 creates a request packet for another device.

FIG. 14 shows an example of the format of a request packet for this other device. This packet includes a command field 1401, a position information field 1402, a requester field 1403, a processing content field 1404 to be requested, and a data field 140 to be processed.
It consists of 5.

The command field 1401 describes that the request is a failure recovery request. The location information field 1402 describes which device the user wants to execute. In this example, since "ANY" is designated, it indicates that any device that can perform compression processing may be used. If the same processing is performed by a plurality of devices, a method such as using the value of the device that returns the earliest result may be used.

The requester field 1403 stores the identifier of the failed device. This identifier is used when the processing result is transferred (returned) from the requested device. In the requested processing content field 1404, a substitute request for the compression mechanism is stored in this embodiment. The data field 1405 stores data to be compressed.

Referring again to FIG. 13, step 1301
After creating the request packet as shown in FIG. 14, the created packet is sent to the system bus 183 in step 1302. As a result, the packet is transferred to all the devices connected to the system bus 183. After the packet transfer, wait for the requested processing to end.

Each device receiving the packet checks the position information field 1402 in the packet in the fault management unit in the device itself and determines whether the request is to the device itself. When it is a request to the own device, the command field 1401 is interpreted, and the requested processing is executed in the same manner as described in FIG. 8 and the like. Then, the processing result is returned to the requesting device. In the packet example of FIG. 14,
Since the position information is "ANY", the processing is executed by all the devices that have received the packet, and the result is transmitted. The requesting device uses the processing result sent earliest to continue the subsequent processing.

At step 1303, it is checked whether the requested processing has been completed normally. If it is abnormal termination, the fault detection processor 304
Will be notified to that effect. Otherwise, step 13
At 05, the selector 311 is switched to the direct connection path 127.
As a result, the cache memory 115 and the data buffer 303 are directly connected. In step 1306, the execution result by another device stored in the data buffer 303 is directly transferred to the cache memory 115 by this direct connection path 127.

In the present embodiment, the failure recovery request is issued to another device connected to one system bus 183, but to which device the packet transfer in FIG. 14 is possible. But you can ask for disaster recovery. For example, the processing may be requested to a device connected to the network, a device on the nested network, or the like. Therefore, according to the present invention, when a large number of disk devices are connected, the operation of the system should be stopped as long as the plurality of disk devices provide a component capable of operating one disk device. It becomes possible to operate without.

Generally, the larger the number of devices, the lower the reliability of the entire system. However, according to the present invention, it is possible to minimize deterioration in reliability due to the increase in the number.

FIG. 15 is a diagram showing the flow of processing when requesting processing to another device. It can be considered that the thick arrow indicates not only the flow of processing but also the flow of data when writing data, for example.

Failure management unit 112 of disk device 106
Detects a failure of the compression mechanism 113 and requests another device to substitute the process to be performed by the compression mechanism 113. In FIG. 15, the failure management unit 152 of the disk device 107 receives this, and the compression mechanism 153 in the disk device 107 performs the same processing as that of the failed compression mechanism 113. The result is sent from the failure management unit 152 to the failure management unit 112. The failure management unit 112 switches the selector 311 to the direct connection path 127 and transfers the received data directly to the cache memory 115.

FIG. 16 shows a processing flowchart of the failure recovery request to the host which is executed from step 1007 of FIG. This process is performed by the fault management processor 305 in FIG.
Request request program 309 executed by the host
Corresponds to the processing of.

First, in step 1601, the fault management processor 305 creates a request packet for the host processors 101 and 102.

FIG. 17 shows a format example of a request packet for this host processor. This packet includes a command field 1701, a position information field 1702, a requester field 1703, a processing content field 1704 to request, and a data field 1705 to perform processing.

The command field 1701 describes that the request is a failure recovery request. The position information field 1702 describes which device is desired to be executed. Here, since it is a processing request to the host processor, it is described as "host". The requester field 1703 stores the identifier of the device that has failed. This identifier is used when the processing result is transferred (returned) from the requested host processor side. In the requested processing content field 1704, a substitute request for the compression mechanism is stored in this embodiment. The data field 1705 stores data to be compressed.

Referring again to FIG. 16, step 1601
After creating the request packet as shown in FIG. 17, the created packet is sent to the system bus 183 in step 1602. As a result, the packet is transferred to the host processors 101 and 102 connected to the system bus 183 via the channel adapter 105. After the packet transfer, wait for the requested processing to end.

The processing in the host processor which receives the packet will be described in detail later.

At step 1603, it is checked whether the requested processing has been completed normally. If it is abnormal termination, the fault detection processor 304 is checked in step 1604
Will be notified to that effect. Otherwise, step 16
At 05, the selector 311 is switched to the direct connection path 127.
As a result, the cache memory 115 and the data buffer 303 are directly connected. In step 1606, the execution result by the host processor stored in the data buffer 303 is directly transferred to the cache memory 115 by this direct connection path 127.

FIG. 18 shows the structure of a program particularly related to failure recovery in the host processor 101 (or 102).

Reference numeral 1802 indicates an application program. Input / output requests to the disk devices 106 and 107 are issued by the application program 1802.
Reference numeral 1803 indicates an operating system.
The operating system 1803 is the host 101 (1
02), and only the input / output relationship is taken up and described in the figure.

Reference numeral 1804 denotes an input / output termination processing program, which performs termination processing of the input / output issued from the application program 1802. The termination processing includes releasing resources such as a memory area used for input / output control. Reference numeral 1807 is an input / output issue processing program. Contrary to the I / O termination processing program 1804,
I / O processor 1 that secures the resources required for I / O
03 (104) for asynchronous input / output processing.

Reference numeral 1806 is an interrupt acceptance program. At the end of the input / output issued from the application program 1802, an interrupt occurs from the device side to the host. The interrupt acceptance program 1806
This program accepts this interrupt. Specifically, the packet issued from the device side (including the packet in FIG. 17) is fetched.

Reference numeral 1805 is a termination interrupt analysis program. The program 1805 determines whether the accepted interrupt is an I / O end interrupt or a failure recovery request (FIG. 17). Reference numeral 1808 is a device request management program. This program 1808 executes and manages the contents requested from the device side, and transfers the execution result to the requesting device.

The program to be executed by the device request management program 1808 is the function program library 18
09, and is executed as needed. For example, if the compression process is requested, the compression program 1810 is executed. The conventional host processor does not have a function of receiving a processing request from the device side, except for an input / output end interrupt. In this embodiment,
Since the host processor has the above-mentioned configuration, it becomes possible to receive a processing request from the device side.

FIG. 19 is a flow chart showing the operation of the host processor having the above configuration.

The host processor first proceeds to step 19
At 01, input / output end interrupt acceptance processing is performed. This processing is processing by the interrupt acceptance program 1806 described above, and is specifically processing such as fetching of a packet (such as FIG. 17) issued from the device side.

Next, the end interrupt analysis program 180
Processing 1921 according to No. 5 is performed. That is, first, in step 1902, the received packet is analyzed, and in step 1803, it is determined whether the interrupt is an input / output end interrupt or a failure recovery request. If it is a normal input / output end interrupt, the input / output end processing program 1804 is started, and the input / output processing is completed in step 1909.

If it is determined in step 1903 that the request is a processing request from the device side, control is transferred to the device request management program 1808 and processing 1922 is performed.
In the process 1922, first, in step 1904, the packet (FIG. 17) is analyzed. Then, as a result of the analysis, what to do is determined in steps 1905 to 1907.

Based on the judgments in steps 1905 to 1907, in the processing 1923, the function program library 18
The requested processing is executed using the program in 09. For example, when the processing requested in step 1905 is compression processing, the compression program 1810
In step 1910, compression processing is performed. Similarly, when the process 1 is requested in step 1906, the process 1 is executed in step 1911, and when the process 2 is requested in step 1907, the process 2 is executed in step 1912.

After steps 1910, 1911 and 1912, in step 1908, the execution result is transferred to the device that issued the request.

FIG. 20 shows an outline of the recovery process in the host processor. It can be considered that the thick arrow indicates not only the flow of processing but also the flow of data.

Failure management unit 112 of disk device 106
Detects a failure of the compression mechanism 113 and requests the host to substitute the processing to be performed by the compression mechanism 113. Figure 20
Then, in response to this, the host processor 101 uses the internal compression program 1810 to perform compression processing equivalent to that of the compression mechanism 113 that has failed. The result is
It is sent from the host processor 101 to the failure management unit 112. The failure management unit 112 connects the selector 311 to the direct connection path 1
It switches to 27 and transfers the received data directly to the cache memory 115.

As a result, in addition to the failure recovery in the other apparatus described above, it becomes possible to perform the failure recovery using any apparatus or the host processor with which the device can communicate, thereby constructing a more reliable system. It becomes possible to do.

The present invention is not limited to the disk device, but can be applied to computer systems in general. Also, the basis of the present invention is the efficient use of resources among multiple devices or computing systems. Thus, the present invention is not limited to disaster recovery, but can be generally applied to effectively utilize resources among multiple devices or computing systems.

[Embodiment 2] Next, a second embodiment of the present invention will be described. In this embodiment, the same system as the system of the first embodiment is used. In particular, it is characterized by performing a cross call operation.

FIG. 21 shows the flow of operations when the failure recovery processing in this embodiment is performed using cross call. It can be considered that the thick arrow indicates not only the flow of processing but also the flow of data.

Failure management unit 112 of disk device 106
In response to a data write request from the host device, the compression mechanism 113 compresses the data and stores it in the cache 115. The failure management unit 116 attempts to write the data stored in the cache 115 to the disk drive 118, but at this time, it is assumed that the control processor 117 performing the input / output control of the disk drives 118 and 119 has failed.

At this time, the fault management unit 116 detects a fault in the control processor 117 and requests another device for fault recovery. The failure management unit 132 that received the request stores the received data in the cache 135 through the direct connection path 147, and the failure management unit 136 further stores the received data in the cache 135.
Data stored in the disk drive 1 to the control processor 137, and the control processor 137 transfers the data to the disk drive 1
Write to 18. As described above, the device that receives the failure recovery request directly accesses the disk drive 118 by cross-call without returning the data to the original device.

The existence of the paths 171 and 172 makes this cross-call possible. This path enables access of the disk drive between independent control modes (that is, between the left disk system and the right disk system in the disk device 106).

Next, the fault recovery process by cross call will be described in more detail.

FIG. 22 is a flow chart showing the procedure for requesting a failure recovery process by cross call. This process is
It is executed by the fault management processor 405 of the fault management unit 116. First, in step 2201, a request packet is created. Next, in step 2202, the created packet is sent to the system bus 183 and transferred to a cross-call enabled device.

Two types of request packets will be given.

FIG. 23 is an example of the first packet, and is an example of the request packet sent by the fault management unit 116 in FIG. This packet contains the command field 23
01, position information field 2302, failure recovery requester field 2303, processing requester field 2304, requested processing content field 2305, and processing data field 2306.

The command field 2301 indicates a command and informs the other party that the request is a failure recovery request. The location information field 2302 stores the identifier of the requesting device. Disaster recovery requester field 230
3 stores the identifier of the failure recovery request source.

Here, since the request is from the failure management unit 116 of the left disk system in the disk device 106 to the failure management units 132 and 136 of the right disk system in the same disk device 106, the position information field 2302 Is described as “device 1-2” that represents the right disk system in the disk device 106, and the failure recovery requester field 2303 is described as “device 1-1” that represents the left disk system in the disk device 106. Has been done.

The processing requester field 2304 stores the identifier of the host that is the requester of the processing. When this recovery process is completed by this identifier, the completion report can be sent directly to the host without returning the completion process to the requester. The requested content is written in the requested processing content field 2305. In this example, it is described that the processing is performed by the control processor 117. Request processing data is described in the data field 2306. In this example, necessary data in the cache memory 115 is stored.

Since the request to the other device is made by the packet as described above, the device receiving the request
The processing can be efficiently performed without duplicating the processing unnecessarily.

FIG. 24 is an example of the second packet, which is also an example of the request packet sent by the fault management unit 116 in FIG. This packet includes a command field 2401, a position information field 2402, a processing requester field 2403, and a requested processing content field 24.
04, and a data field 2405 for processing.

A command is stored in the command field 2401, which indicates that the command is a cross call. Position information is stored in the position information field 2402, and here, the position of the disk drive to be accessed is stored. The requester field 2403 stores the host identifier as in the case of the processing requester field 2304 of the first packet.
The processing content field 2404 describes the content of the requested processing, and here, the control processor 1 in which the failure has occurred.
An identifier indicating the processing of 17 is stored. Data field 2405 contains data field 2 of the first packet.
Similar to 306, necessary data is stored in the cache memory 115.

The target cross call is possible by using either the packet shown in FIG. 23 or the packet shown in FIG. Hereinafter, the cross call process using the second packet in FIG. 24 will be described in detail.

FIG. 25 shows a processing flowchart of the apparatus which receives the cross call request packet as shown in FIG. Since steps 2501-2503 are the same as steps 701-703 in FIG. next,
In step 2504, the command field 2 of the packet
It is determined whether 401 is a cross call request.
If the request is a cross-call, the process proceeds to step 2505 by the failure detection unit 304.

The fault detecting unit 304, step 2505
Then, the data in the data field 2405 of the packet is transferred to the cache memory 135. At this time,
In the same manner as described in step 1305 of the above, the fault management unit 1
In the 32 selectors (selector 311 in FIG. 3), the direct connection path 147 is selected.

Next, in step 2506, the data in the request processing field 2404 of the packet is transferred to the control processor 1.
Transfer to 37. The fault management unit 136 performs this transfer process. At this time, the path 414 is selected by the selector (selector 411 in FIG. 4) of the failure management unit 136. As a result, the data stored in the cache memory 135 (data in the data field 2405 of the packet) is passed to the control processor 137 via the path 414, and the control processor 137 writes the data to the disk device 118 by cross call. .

By such processing, the control processor 1
The processing in 34 and the like can be omitted, and high-speed cross call becomes possible. Also, with this cross call,
As compared with the method described in the first embodiment, the communication overhead required for round trip can be reduced, and the processing can be performed at higher speed.

[Third Embodiment] In the first and second embodiments described above, the example in which the present invention is applied to the file system in which the data which the user wants to access exists in only one disk drive has been described. However, in order to realize a file system with higher reliability, a method of obtaining high reliability by storing the same data in a plurality of disk devices may be used. This is called mirroring.

The third embodiment is an example in which the present invention is applied to a mirrored disk file system, and an example in which an efficient failure recovery operation is realized in such a system. The system configuration of this embodiment is the same as that of the first embodiment described above.
In particular, the description will focus on the part that is unique to the third embodiment.

FIG. 26 shows an outline of a failure recovery operation in the mirrored disk file system of this embodiment. It can be considered that the thick arrow indicates not only the flow of processing but also the flow of data. Here, the disk drive 118 and the disk drive 158
Are mirrored and these drives 118,
It is assumed that data having the same content exists in 158.

It is assumed that the disk drive 118 has failed. Fault management unit 112 that has detected this fault
Obtains that the failed disk drive 118 is mirrored by the disk drive 158 by referring to the configuration management table 111. After that, the failure management unit 112 performs failure recovery by performing processing on the disk drive 158.

FIG. 27 shows the contents of the configuration management table 111 in which mirroring information is stored. Each area 2701 to 2705 of the table is an area for storing the same contents as the areas 501 to 505 of the configuration management table 111 of FIG. The difference from the configuration management table 111 of FIG. 5 is that mirroring is added as record information.

In FIG. 27, the component 2701 is an alternative means 2705 for the "drive 1" (disk drive 118).
Is described as "mirror, device 2: drive 1". This shows that the disk drive 118 is mirrored with the disk drive 158 of the disk device 107.

FIG. 28 shows the fault management unit 1 in this embodiment.
12 shows a processing flowchart of 12 failure management processors 305. In the figure, step 2801
2807 is step 1 in FIG. 10 of the first embodiment described above.
001 to 1007, step 2809 is step 10
08, steps 2810 to 2813 are steps 100.
9 to 1012 respectively, and the operations in these steps are the same as those in the first embodiment, and the description thereof will be omitted.

In the flowchart of FIG. 28, step 2
808 has been added. This is a step of checking whether the failure recovery by mirroring is possible. If the failed component is mirrored, then the mirror (the non-failed one of the mirrored components) can be used to continue processing.

FIG. 29 shows a processing flowchart of the failure recovery request to the mirror which is executed from step 2808 of FIG. The program of this processing is stored in the memory 306 similarly to the emulation request program 307 and the external device request program 308 of FIG. The fault management processor 305 first executes step 290.
In step 1, a recovery request packet for a device that is mirrored is created. Then, in step 2902,
The packet is transferred to the target device via the system bus 183.

FIG. 30 shows the structure of the above failure recovery request packet. This packet is similar to the packet of FIG. 6 transferred from the host to the failure management unit in the first embodiment. However, since FIG. 30 shows a request packet to the mirror, the position information field 3002 specifies the mirrored device. The characteristic of the packet at the time of mirroring is that the processing request can be easily made by simply replacing the position information of the original packet with the device to which the mirroring is applied.

[Embodiment 4] In each of the above embodiments, when a certain component fails, another component replaces the failed component and continues the processing. . On the other hand, in the fourth embodiment, the emulation processing described above is not used at the time of a failure, but a multiplexing operation is performed to improve the reliability of data, and a majority decision is made with hardware.

FIG. 31 shows the structure of the failure management unit 112 in the file system of this embodiment. Since the basic configuration is the same as that of FIG. 3, the different points will be described in detail. In the failure management unit 112 of FIG. 31, the option mechanism is multiplexed (duplexed) and includes two option mechanisms 3101 and 3102. Further, comparators 3103 and 3104 for making a majority decision are added.

In this embodiment, it is assumed that a data write request packet as shown in FIG. 6 of the first embodiment is accepted. At this time, the fault management processor 305 passes the data to the multiplexed option mechanisms 3101 and 3102 in order to compress the data to be written to the disk. Further, even when there is no failure in the option mechanisms 3101 and 3102, the control processor 114 is caused to execute the emulation described in the first embodiment.

The result of the compression processing by the option mechanism 3101 and the result of the compression processing by the option mechanism 3102 are
It is compared by the comparator 3103. Further, when the comparison results are the same, the comparator 3104 compares the result of the compression processing in the option mechanisms 3101 and 3102 with the result of the emulation. As a result of these comparisons, if any one data is different from the other two data,
The two data having the value determined by the majority decision are adopted and written in the cache 115.

In this way, the present invention can be applied not only at the time of failure but also at the time of normal operation, and more reliable operation can be realized. It should be noted that the present invention is not limited to the method of taking a majority vote, and it is possible to provide a variation such as duplication using one piece of hardware and emulation.

[Embodiment 5] In each of the embodiments described above, as shown in FIGS. 3 and 4, the fault management processors 305 and 405 and the control processor 11 in the fault management unit.
4, 117 are provided, but they can be shared.

FIG. 32 shows the fault management processor 30 of FIG.
5 and the control processor 114 are replaced with one control processor 3201. The control processor 3201 executes the operations performed by the fault management processor 305 and the control processor 114 of FIG. As a result, the number of parts can be reduced, and the device cost can be further reduced. 2 with one processor
Since the operation performed by one processor is performed, the performance is slightly lower than that of the above-mentioned method, but a considerable cost reduction can be expected due to the reduced number of processors.

[0169]

According to the present invention, in a computer system composed of a plurality of constituent elements, even if a certain constituent element fails, another constituent element (emulation, etc.), another device, a host processor, etc. Since it is possible to request the alternative processing of the constituent element, reliability is not deteriorated even if a large number of devices are connected. Further, since the emulation, another device, or the alternative process by the host processor is performed, it is possible to construct a low-cost and highly reliable system as compared with the conventional method of improving the reliability by multiplexing.

[Brief description of drawings]

FIG. 1 shows an overall configuration diagram of a first embodiment of a computer system according to the present invention.

FIG. 2 shows a flowchart showing a flow of failure recovery in the first embodiment.

FIG. 3 shows a block diagram of a failure management unit 112 in the first embodiment.

FIG. 4 shows a block diagram of a failure management unit 116 in the first embodiment.

FIG. 5 shows a configuration management table storing failure information according to the first embodiment.

FIG. 6 shows a structure of a command packet transferred from a host in the first embodiment.

FIG. 7 shows details of position information in a command packet in the first embodiment.

FIG. 8 shows a processing flowchart of a failure detection unit in the first embodiment.

FIG. 9 shows a configuration of a transfer packet to a fault management processor in the first embodiment.

FIG. 10 shows a processing flowchart of a fault management processor in the first embodiment.

FIG. 11 shows a flowchart of an emulation process in the first embodiment.

FIG. 12 shows an outline of emulation operation in the first embodiment.

FIG. 13 shows a flowchart of a failure recovery request processing to another device in the first embodiment.

FIG. 14 shows the structure of a fault recovery request packet to another device in the first embodiment.

FIG. 15 shows an outline of processing for requesting a failure recovery to another device in the first embodiment.

FIG. 16 shows a flowchart of a failure recovery request processing to the host in the first embodiment.

FIG. 17 shows the structure of a failure recovery request packet to the host in the first embodiment.

FIG. 18 shows a program structure in the host in the first embodiment.

FIG. 19 shows a flowchart of a host failure recovery process in the first embodiment.

FIG. 20 shows an outline of failure recovery request processing to the host in the first embodiment.

FIG. 21 shows an outline of cross-call processing in the second embodiment.

FIG. 22 shows a cross-call request processing flowchart in the second embodiment.

FIG. 23 shows a cross call request packet configuration (part 1) in the second embodiment.

FIG. 24 shows a cross call request packet configuration (part 2) in the second embodiment.

FIG. 25 shows a processing flowchart of an apparatus which receives a cross call request in the second embodiment.

FIG. 26 shows an outline of failure recovery during mirroring in the third embodiment.

FIG. 27 shows a configuration management table at the time of mirroring in the third embodiment.

FIG. 28 shows a flow chart of a fault management processor process during mirroring in the third embodiment.

FIG. 29 shows a failure recovery request flowchart at the time of mirroring in the third embodiment.

FIG. 30 shows the structure of a failure recovery request packet at the time of mirroring in the third embodiment.

FIG. 31 is a block diagram (partial view) of a disk system for performing majority decision using emulation in the fourth embodiment.

FIG. 32 shows a fault management unit using the control processor in the fifth embodiment.

[Explanation of symbols]

101, 102 ... Host processor, 106, 107 ...
Disk device, 111, 131, 151 ... Configuration management table, 112, 116, 132, 136, 152, 15
6 ... Fault management unit, 113, 133, 153 ... Optional mechanism, 114, 117, 134, 137, 154, 15
7 ... Control processor, 115, 135, 155 ... Cache memory, 118, 119, 138, 139, 15
8, 159 ... Disk drive, 301, 401 ... Command analysis processor, 304, 404 ... Fault detection processor, 305, 405 ... Fault management processor, 307 ...
Emulation request program, 308, 40
8 ... External device request program, 309, 409 ...
Host request program, 311, 411 ... Selector.

Claims (34)

[Claims] 1. In a computer system having a plurality of constituent elements, a detection means for detecting a failure of the constituent element, and an alternative constituent element that functions by substituting the constituent element when a failure occurs in the constituent element. A computer system comprising: a searching unit that searches for a component and a management unit that causes the found alternative component to perform a process of substituting the component that has failed. 2. The alternative component comprises a processor capable of executing a program, and using the processor,
The computer system according to claim 1, wherein the operation of the failed component is simulated by emulation or simulation. 3. The computer system according to claim 2, wherein the component in which the failure has occurred is a data compression mechanism, and the processor emulates data compression. 4. The search means generates a data string including data indicating a constituent element in which a failure has occurred and data indicating an alternative constituent element that replaces the constituent element, and sends the data string to the management means. The computer system according to any one of claims 1 to 3, wherein the management unit causes the alternative process to be performed based on the data string. 5. A configuration management table that stores data indicating whether or not a failure has occurred in the constituent element and data indicating processing for substituting the constituent element when the failure occurs, the detection table comprising: The means refers to the configuration management table to detect a failure of a component, and the searching means refers to the configuration management table to search for a process for substituting the failed component. The computer system according to any one of claims 1 to 4. 6. Further, when a failure of each of the constituent elements is detected, the constituent element is made to repeat the same operation again, and when the constituent element normally operates by repeating a predetermined number of times or less, the constituent element is Is provided with means for continuing the operation assuming that no failure has occurred, counting the number of times the operation has shifted to the normal operation by such repetitive operation, and transmitting the fact to the outside when the number of times exceeds a predetermined value. The computer system according to any one of Items 1 to 5. 7. The computer system according to claim 1, wherein the constituent elements are multiplexed. 8. The computer system according to claim 1, wherein the management means itself is also a component capable of performing a process for substituting the component in which the failure has occurred. . 9. The computer system according to claim 1, wherein the constituent elements are constituent elements of a file system of the computer system. 10. A computer system having a host processor or a peripheral device connected to a network, comprising:
In a peripheral device having a plurality of constituent elements, a detecting means for detecting a failure of the constituent element, and, when a failure occurs in a certain constituent element, substitutes the failed constituent element from other internal constituent elements. A peripheral of a computer system characterized by including a searching means for searching an alternative constituent element that functions as a function, and a management means for performing processing for replacing the found alternative constituent element with the failed constituent element. machine. 11. A computer system comprising a host processor and a plurality of peripheral devices, each peripheral device comprising a plurality of constituent elements, wherein failure of the constituent elements of the peripheral equipment is eliminated. A detection means for detecting, and a management means for causing a peripheral device other than the peripheral device including the component or the host processor to perform a process for substituting the component for which the failure has occurred when a failure occurs in the component. A computer system characterized by having. 12. The management means generates and sends a data string including an identifier indicating a failure recovery processing request, an identifier indicating a failed component, and an identifier indicating a requested processing. The computer system according to claim 11, characterized by causing the peripheral device or the host processor to perform an alternative process. 13. The management means transmits the data string to a plurality of peripheral devices, and the peripheral device capable of processing the request stored in the data string performs an alternative process based on the data string. The computer system according to claim 12, wherein 14. A configuration management table that stores data indicating whether or not a failure has occurred in the component and data representing a process or alternative means for replacing the component when the failure occurs. The detecting unit refers to the configuration management table to detect a failure of a component, and the managing unit refers to the configuration management table to determine where to perform the alternative process. The computer system according to any one of claims 11 to 13, wherein: 15. The computer system according to claim 11, wherein the peripheral devices are multiplexed. 16. The computer system according to claim 11, wherein the peripheral device is a file system of a computer system. 17. A computer system comprising a host processor and a plurality of file systems capable of communicating with each other, each file system comprising a plurality of constituent elements including a disk device, and between the respective file systems. In the computer system, which can mutually access the disk devices of other file systems by means of the cross-call of the above, the means for detecting the failure of the above-mentioned file system components, and the configuration when a failure occurs in the components other than the disk device. A file system other than the file system including the element, and a means for requesting a process for substituting the failed component, and the file system that has received the request performs the alternative process based on the request, Due to the cross-call, Computer system, characterized in that the disk device of the file system that contains the elements, direct access. 18. A computer system including a host processor or a peripheral device connected to a network, comprising:
In a peripheral device that has multiple components, a means to detect a fault in a component inside the peripheral device itself, and when a fault occurs in a component, the fault occurs in another peripheral device. A means for transmitting a data string requesting a process to replace a component, and when receiving the processing result of the requested process from another peripheral device, bypasses the component causing the failure,
When a data sequence requesting a process for substituting the component in which the failure has occurred is received from a means for continuing the process and another peripheral device, the process is performed based on the request for the data sequence, and the processing result is displayed as the above data. A peripheral device for a computer system, which is provided with a means for returning the line to the sender. 19. A computer system comprising a host processor or a peripheral device connected to a network, comprising:
In a peripheral device equipped with multiple components, a means for detecting a fault in a component inside the peripheral device itself, and when a fault occurs in a component, the fault occurs in the host processor. Means for transmitting a data string for requesting processing to replace a component, and when the processing result of the requested processing is received from the host processor, bypasses the failed component and continues the processing. A peripheral device for a computer system, which is provided with: 20. A computer system comprising a host processor and a peripheral device connected to the host processor, wherein the peripheral device performs processing normally performed inside itself on another peripheral device or host processor. A computer system having means for requesting. 21. In a computer system comprising a plurality of constituent elements including a processor capable of executing a program, the operation of the constituent elements other than the processor is emulated or simulated by the processor, and a processing result by the constituent element is obtained. A computer system comprising: means for comparing a result of emulation or simulation by the processor. 22. A failure recovery method for a computer system having a plurality of constituent elements, the step of detecting a failure of the constituent element, and when a failure occurs in a certain constituent element, the constituent element is replaced and functions. A failure recovery method for a computer system, comprising: a step of searching for an alternative constituent element; and a step of causing the searched alternative constituent element to perform processing for replacing the failed constituent element. 23. The alternative component includes a processor capable of executing a program, and the operation of the faulty component is simulated by emulation or simulation using the processor.
A method for recovering from a failure in the computer system described in. 24. The failure recovery method for a computer system according to claim 23, wherein the component in which the failure has occurred is a data compression mechanism, and the processor emulates data compression. 25. A configuration management table that stores data indicating whether or not a failure has occurred in the component, and data representing a process of substituting the component when the failure occurs, the configuration management table comprising: The step of performing refers to the configuration management table to detect a failure of the component, and the step of searching refers to the configuration management table to search for a process for substituting the failed component. The failure recovery method for a computer system according to any one of claims 22 to 24. 26. Further, when a failure of each of the constituent elements is detected, the constituent element is caused to repeat the same operation again, and when the constituent element normally operates by repeating a predetermined number of times or less, the constituent element is Has a step of continuing the operation assuming that no failure has occurred, counting the number of times the operation has shifted to a normal operation by such repetitive operation, and transmitting the fact to the outside when the number of times exceeds a predetermined value. A failure recovery method for a computer system according to any one of Items 22 to 25. 27. A failure recovery method for a computer system according to claim 22, wherein said constituent elements are multiplexed. 28. The failure recovery method for a computer system according to claim 22, wherein the component is a component that constitutes a file system of the computer system. 29. A computer system comprising a host processor and a plurality of peripheral devices, each peripheral device comprising a plurality of components, in a failure recovery method for a computer system, wherein the components of the peripheral device are included. Detecting a failure of the component, and when a failure occurs in a certain component, the peripheral device other than the peripheral device including the component or the host processor performs a process of substituting the failed component. A failure recovery method for a computer system, comprising: 30. The step of causing the alternative process to generate a data string including an identifier indicating a failure recovery process request, an identifier indicating a failed component, and an identifier indicating a requesting process. 30. The failure recovery method for a computer system according to claim 29, characterized in that the peripheral device or the host processor is caused to perform an alternative process by transmitting the data as a substitute. 31. The step of causing the alternative process includes transmitting the data string to a plurality of peripheral devices, and the peripheral device capable of processing the request stored in the data string is based on the data string. 31. The failure recovery method for a computer system according to claim 30, characterized by performing an alternative process. 32. A configuration management table further storing data indicating whether or not a failure has occurred in the component, and data representing a process or alternative means for replacing the component when the failure occurs. The detecting step refers to the configuration management table to detect a failure of a component, and the step of performing the substitution process refers to the configuration management table to perform the substitution process. The method according to claim 29 or 3, wherein it is determined whether or not to perform.
1. A failure recovery method for a computer system according to any one of 1. 33. A failure recovery method for a computer system according to claim 29, wherein said peripheral devices are multiplexed. 34. The computer system failure recovery method according to claim 29, wherein the peripheral device is a file system of a computer system.