JP3334174B2 - Fault handling verification device - Google Patents

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

The present invention relates to relates to a verification device failure processing function in a multi-processing system, and more particularly to apparatus you verify <br/> failure processing function of the entire system including the operating system.

In recent years, computer systems have been used in all fields of society, and their processing power and reliability have been increasingly required. In order to increase the processing capacity, a multiprocessing system in which a central processing unit, a memory, and the like are multiplexed has been widely used. When a failure occurs in a part of these multi-processing systems, a multi-processing system with an emphasis on fault tolerance (faulttolerant) is designed so that the system can continue to operate even if the failed device is separated and the system performance is reduced. Widely used. Each device constituting the computer system has a function of detecting various errors and failures such as failures. The operating system (OS)
It has a function of logging failure information in order to identify the location or device of the failure and to disconnect the device from the system. Accordingly, in such a multi-processing system, a method is required that can accurately verify a failure processing function including a failure detection and a failure information collecting function of the entire system including the OS in a short time with a small number of hands. .

[0003]

2. Description of the Related Art Conventionally, a processing unit (C
An external maintenance support device provided for each of the PUs (PU) was used to inspect the failure detection function of the system. An external maintenance support device, for example, a service processor (SVP)
Each of the devices including a CPU in the computer system has a function of setting a hardware such as a register in each device constituting the system to a predetermined state, and reading the state, and incorporating an independent processor separate from the computer. Intentionally set a failure state, and as a result, collect and dump state information presented by the device irrespective of the operation of the OS, and a technician analyzes the collected information to detect a failure in the entire system. Checked whether the function works correctly.

[0004]

As described above, according to the conventional method, a pseudo failure is generated in a device in a system using an external maintenance support device, failure information is collected, and a failure detection function is manually confirmed. As a result, (1) a simulated fault is generated, an external maintenance support device is required to collect the information, and the system price becomes expensive. (2) The fault detection function of the entire system including the OS is verified. (3) There is a problem that it takes time and labor to collect collected trouble information manually.

SUMMARY OF THE INVENTION It is an object of the present invention to provide a fault processing verification apparatus capable of checking a fault processing function in a multi-processing system in a short time and at low cost in a state where the fault processing function is actually performed.

[0006]

FIG. 1 is a block diagram showing the principle of the present invention. In the figure, reference numeral 21 denotes an operating system for logging device failure information, 3 denotes a separating means for separating a group of devices constituting the system into one specific processing device 1 and the remaining other devices 2, and 4 denotes a separating device. Pseudo failure generating means for generating a specific pseudo failure 41 in another device 2,
5 indicates that when a specific pseudo failure 41 occurs in another device 2,
Expected value creating means for creating an expected value of fault information to be logged by the operating system 21;
This is matching means for checking the fault information logged by the operating system 21 when the specific pseudo fault 41 is generated by the pseudo fault generating means 4 with the expected value created by the expected value creating means 5.

[0007]

According to the present invention, there are provided a plurality of processing units having a function of detecting a failure of a device and logging the failure information by the operating system 21, and a shared device shared by the plurality of processing units. In the fault processing verification method of the multiprocessing system, the separating means 3 separates a group of devices constituting the system into one specific processing device 1 and the remaining other devices 2, and the simulated fault generating means 4 performs The fault 41 is generated in the other device 2, and the expected value creating means 5 creates the expected value of the fault information to be logged by the operating system 21 when the specific pseudo fault 41 occurs in the other device 2, Reference numeral 6 denotes fault information logged by the operating system 21 when the specific pseudo fault 41 is generated by the pseudo fault generating means 4 and an expected value creation step. Since collates the expected value created by 5, based on the collation result of the collating means 6, it is possible to verify the failure processing of the multiprocessing system.

[0008]

2 is a system configuration diagram showing an embodiment of the present invention, FIG. 3 is a system configuration definition table, FIG. 4 is an access condition table, FIG. 5 is a failure setting table, and FIG. 6 is an OS logging table.

Throughout the drawings, the same reference numerals indicate the same or similar components. In FIG. 2, CPUs 1 to n are n processors each having a main memory, an input / output control device, and the like, and perform mutual communication by sharing a shared memory SSM0 and SSM02. CPU1 to n
Share a plurality of input / output devices represented by the adapter device AD. CPU1 to n and shared memory SSM01
And SSM02 are connected via duplexed buses # 0 and # 1, and the bus handlers BH10 and BH11 are
When one of the buses is in use or has a failure, the other bus is used to control the CPUs 1 to n to connect to SSM01 and SSM02 for communication. Similarly, CPUs 1 to n
And the adapter device AD are duplicated buses # 0 and # 1
And the bus handlers BH20 and BH21
When one of the buses is in use or has a failure, the other bus is used to connect the CPUs 1 to n and the adapter device AD for communication.

Each of the CPUs 1 to n has a system configuration definition table (see FIG. 3).
(Implementation), NA (Access prohibited), NI
(Not implemented) to specify whether it can be used as a system resource, so that it can be logically disconnected even if it is physically connected.
Ｎn can be configured arbitrarily. Accordingly, by setting the system configuration definition table as shown in FIG. 3, the CPU 1 can be logically separated from the other CPUs 2 to n.

Each of the CPUs 1 to n has a diagnostic instruction for executing a built-in diagnostic function in addition to a normal instruction. For example, by issuing a diagnostic instruction to another CPU, shared memory SSM01, SSM02, adapter device AD, or the like, the function or a part of the function is stopped.

In the system configured as described above, C
PU2 to PU2 execute normal operations under the OS, and
1 executes a test program. The test programs are CPUs 2 to n, shared memories SSM01 and SSM0.
(2) A diagnostic instruction for generating a pseudo failure is sequentially issued to other devices such as the adapter device AD. By comparing the fault information actually logged by the OS with the expected value obtained in advance for each pseudo fault by the diagnostic instruction, the hardware correctly detects the fault and the OS logs the fault information correctly. Verify whether or not to do.

FIG. 7 is a flowchart of an embodiment of the present invention. The operation of the embodiment of the present invention will be described in the case where the target device in which the pseudo failure occurs is the shared memory SSM01.
This will be described with reference to FIG. 2 based on FIG. (1) One of the CPUs in the system, for example, the CPU 1 is separated from the other devices (CPUs 2 to n) and started up as a verification system for running a test program for causing a pseudo failure. That is, as shown in FIG. 3, when the initial program is loaded, in the system configuration definition table held by the CPU 1, the C
NA for PU2 to CPUn (operating under OS)
By setting (access prohibition), access by the CPU 1 to the CPUs 2 to n is prohibited. Therefore, even though the CPU 1 and the CPUs 2 to CPUn are physically connected, they are logically disconnected and the verification system CPU1 can be separated from the systems to be verified CPU2 to CPUn operating under the OS.

Next, the CPUs 2 to CP operating under the OS
In order to separate Un from the verification system CPU1,
In the system configuration definition table of these CPUs, as shown in FIG. 3, by setting NI (not mounted) for the CPU 1 as the verification system,
Access from Un to the CPU 1 is prohibited. Therefore, even though they are physically connected, logically, the CPU 1 of the verification system does not appear to be mounted from the CPUs 2 to CPU n of the system to be verified. (2) The test program is started in the CPU 1 of the verification system. (3) OS in CPU2 to CPUn of the system to be verified
Start (4) In order to reliably generate the pseudo failure, the operator inputs the information including the name, time, and address of the device accessed by the OS in this table in chronological order from the time when the OS is started. (See Fig. 4)
Is created. (5) The test program issues a diagnostic command to the shared memory device SSM01 to be tested based on the access condition table created in (2),
At 200, a pseudo fault (HALT) for instructing to stop the operation is set for 200 ms. (6) SSM indicating the name of the device for which the pseudo failure was set in (5) above
01, HALT indicating the contents of the set fault, and 23: 59: 59: 100 ms indicating the set time are stored in the disk device DK in the form of a fault setting table (see FIG. 5). (7) OS is SSM0 which is a shared memory device to be tested
Accessing 1 causes a HALT (failure) state. (8) The OS stores the failure information (the SSM01 is in the HALT state at 23: 59: 59: 120 ms) in the disk device DK in the OS logging table format (see FIG. 6). ) Is set by the test program and stored in the disk drive DK (23: 59: 59: 100
SSM01 HALT during ~ 300 ms)
In step (8), the OS checks the failure information logged in the disk drive DK (the SSM01 is in the HALT state at 23: 59: 59: 120 ms). If the collation result is appropriate, both the hardware failure detection function and the OS logging function can be verified.

[0015]

As described above, according to the present invention,
The device group constituting the multi-processing system is separated into one specific processing device (verification system) and the other device (verified system), and is logged by the operating system when a pseudo failure occurs in the system to be verified. The expected value of the fault information to be created is created, and the verification system generates a simulated fault in the system to be verified, and multiplexes the fault information actually logged by the operating system with the created fault information of the expected value. Since the failure handling of the system is verified, the failure handling function of another device is verified by one CPU instead of the external maintenance support device used conventionally, so that the failure handling of the system can be verified at low cost. In addition, hardware and O
Since the failure information processed jointly with S is inspected, there is an effect that the failure handling function of the system can be verified in a state close to actual operation.

[Brief description of the drawings]

FIG. 1 is a block diagram showing the principle of the present invention.

FIG. 2 is a system configuration diagram showing an embodiment of the present invention.

FIG. 3 System configuration definition table

FIG. 4 Access condition table

FIG. 5 is a failure setting table.

FIG. 6: OS logging table

FIG. 7 is a flowchart of an embodiment of the present invention.

[Explanation of symbols]

 CPU 1 to n processing device SSM01,02 Shared memory device BH10,11,20,21 Bus handler device AD adapter device DK disk device

Continuation of the front page (58) Fields surveyed (Int.Cl. ⁷ , DB name) G06F 11/22-11/26 JICST file (JOIS)

Claims (2)

(57) [Claims] 1. A multiprocessing system comprising a plurality of processing units having a function of detecting a device failure and logging the failure information by an operating system, and a shared device shared by the plurality of processing devices. in processing the verification apparatus, the system is provided with a disconnecting means for disconnecting the and one particular processing unit and the rest of the other devices in the multiple processor, the particular processing device, pseudo disorders other and the pseudo fault generating means for generating the device, when the該疑 similar fault occurs in another device, an expected value generation means for generating an expected value of error information to be logged by the operating system, by該疑similar failure means Fault information logged by the operating system when the pseudo fault has occurred, and fault information created by the expected value creating means. Verifying means for verifying fault processing of the multiprocessing system based on a result of the verification by the verifying means.
Equipment . 2. The operating system and the expected value creating means log fault information including the time of occurrence of the pseudo fault and create an expected value of the fault information, respectively.
Fault processing verification apparatus according to claim 1, characterized in that that.