JP2001101032A - OS monitoring method by controlling between different types of OS - Google Patents

Abstract

(57) [Summary] As a method of monitoring whether or not a program is operating normally, a monitoring CPU is not required, and an OS
Even if an abnormality that cannot be detected by itself is detected, the abnormality is detected and the OS is automatically reloaded and restarted, so that an inexpensive and reliable automatic recovery method is realized. In order to achieve the above object, the present invention provides a function of separating hardware resources to a plurality of OSs by virtual hardware having a function of allocating an interrupt from hardware and a processing time of a CPU; A function of enabling data writing and reading between OSs is provided, and the monitored OS writes data to the monitoring OS periodically to monitor the operation of the OS. As a result, when an abnormality that cannot be detected by the monitored OS itself occurs, an abnormality of the monitored OS can be detected without a separate monitoring CPU, so that it is possible to automatically recover.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

The present invention relates to an OS monitoring method for detecting a software abnormality of an OS of a computer, and more particularly to an OS monitoring method between a plurality of different OSs.

[0002]

2. Description of the Related Art As a method of monitoring whether a program operates normally, a method of monitoring a monitoring program by operating the monitoring program on a CPU different from the CPU on which the monitored program operates is well known. Have been. If an abnormality in the program operation is detected during monitoring, the monitored C
A method of resetting the PU, reloading and restarting the program, and recovering from an abnormality is also often used.

[0003] In addition, there is an OS that detects an abnormal interrupt from hardware by accessing an illegal address or the like, and reloads and restarts itself.

[0004]

However, in these systems, a separate CPU for monitoring is required,
When the program hangs up due to an error that cannot be detected by itself, there is a problem that it cannot be automatically recovered. The present invention does not require a monitoring CPU, and
Even if an abnormality that cannot be detected by S itself occurs, the abnormality is detected and the OS is automatically reloaded and restarted, so that an inexpensive and reliable recovery method is realized.

[0005]

In order to achieve the above object, the present invention separates and isolates hardware resources to a plurality of OSs by virtual hardware having a function of allocating an interrupt from hardware and a processing time of a CPU. And a function of enabling data writing / reading between a plurality of OSs. The monitored OS periodically writes data to the monitored OS to monitor the operation of the OS. As a result, when an abnormality that cannot be detected by the monitored OS itself occurs, an abnormality of the monitored OS can be detected without a separate monitoring CPU, so that it is possible to automatically recover.

[0006]

Embodiments of the present invention will be described below with reference to the drawings. FIG. 2 is a configuration diagram of an embodiment of the present invention, and FIG. 1 is a configuration diagram when the OS 2120 monitors the OS 1112. In FIG. 2, when a device on which a plurality of OSs operate at the same time is hardware 101, DK102, KB103, and port 1 for communication are used as the input / output devices.
104 and port 2105 are connected. The hardware 101 includes a CPU 107 that controls the OS 1112 and the OS 2120. The multiple OS control program 111 has a function of distributing an interrupt from the hardware 101 and a processing time of the CPU to the OS 1112 and the OS 2120. The hardware resource visible from the OS 1112 by making the virtual hardware 122 look like hardware to each OS. And the hardware resources seen from the OS 2120 are separated and independent. Firewall 117 is OS
A conceptual barrier separating the OS 1112 and the OS 2120 indicates a boundary line at which resources such as software and memory including the OS are separated. The OS 2120 executes the monitoring process 1 operating on it
19 and a pseudo nonvolatile memory 118. The pseudo non-volatile memory 118 is a memory whose storage content is guaranteed to the OS 2120 as a memory resource even while the OS 1112 is being reloaded. The pseudo nonvolatile memory 118 includes a shared memory 123 that can be written and read from the OS 1112 by a special procedure,
S1112: After the restart, the AP has takeover data 121 that stores information that can be restarted during the processing. OS1112
Above, power supply control 113, AP monitoring 114 for monitoring the operation status of a specific AP, and O for monitoring the operation of OS 1112.
S1 monitor 115, system management AP1 that controls them
16 operates.

[0007] Referring to FIG.
An embodiment of the method for monitoring the system will be described in detail. The OS 112 area and the OS 2120 area cannot directly write and read data to each other because they are separated by the firewall 117. However, since the multiple OS control program 111 manages both areas, it is possible to see both areas. . By setting the arguments shown in FIG. 3 in the common memory processing 202 provided in the multiple OS control program 111 and activating the function, the OS 2112
Data can be written to and read from the area. The arguments shown in FIG. 3 include a data address 301 indicating a relative address from the head of an area for writing or reading data in the shared memory 123, a data size 302 indicating a size of data to be written or read, and a buffer for storing data. , A processing content 304 indicating whether to perform writing or reading, and a data buffer 305 for storing data.

[0008] When the OS1 monitor 115 is started, it uses the above function and uses the above function to specify the monitor designation area 40 in the shared memory 123.
After the function is started in the shared memory processing 202 so as to write the monitoring presence / absence (FF) ₁₆ in the monitoring presence / absence flag 404 of 3, the same function is used at intervals set by the system, and the monitoring status area 401 in the shared memory 123 is used. Monitoring flag 40
2 ON (FF) ₁₆ is programmed to function-initiate the writing of ₁₆ to the shared memory processing 202. The shared memory processing 202 starts monitoring the presence / absence flag 404
And (FF) ₁₆ are written in the monitoring flag 402. At this time, even if the flag is already (FF) ₁₆ , (FF) ₁₆ is written.

The OS1 monitor 115 receives the service of the OS1112 and operates as long as the OS1112 is operating. Therefore, (FF) ₁₆ is written to the monitoring flag 402 periodically while the OS 1112 is operating.

[0010] On the other hand, the monitoring process 119 includes a monitoring presence / absence flag 4
04 is monitored (FF) ₁₆ is written, and the OS1 monitoring flag 402 is turned on (F) at intervals set by the system.
_F) to make sure that they are _{1 6.} OS1 if on
112 determines OFF (00) ₁₆ in the OS1 monitoring flag 402 after determining that it is operating normally. OS1 at confirmation
OS when the monitoring flag 402 is off (00) ₁₆
Due to 1112 error, OS1 monitor 115
OS1 monitoring 1 because the service was not received from S1112
15 turns on (FF) the OS1 monitoring flag 402. _{16 It} is assumed that the function cannot be started, and an abnormality of the OS1112 is detected. If it is determined to be abnormal, the OS 1112 is reloaded. The AP 201 and the OS1 monitor 115 are OS1112
After reloading, it is reloaded by the OS 1112. As a result, it is possible to prevent the system from becoming dumb due to the OS1112 failure.

Also, since the OS 1112 and the OS 2120 are separated and independent by the virtual hardware 122,
Even if the data 1112 is reloaded, the contents of the shared memory 123 are guaranteed. The monitoring process 119 obtains the information at the time of OS 1112 abnormality detection in the fault information 203 area and refers to the information, thereby reducing the time required for fault isolation and fault analysis. In particular, since it is difficult to reproduce a fault that occurs in the intermittent, this fault information is very effective.

Next, a monitoring process according to an embodiment of the present invention will be described with reference to FIG. FIG. 5 is a flowchart of the monitoring process 119. The system starts this processing at intervals and checks in step 501 whether the monitoring presence flag 404 is on.
If the flag is off, nothing is done and the process ends. If it is on, the flow advances to step 502 to check whether the OS1 monitoring flag 402 is on. If it is on, the OS1 determines that it is operating normally, turns off the OS1 monitoring flag 402, and ends the processing. When the OS1 monitoring flag 402 is off, the OS1 determines that a failure has occurred, and in step 505, the monitoring presence / absence flag 402 is turned off to prevent double detection of the OS1 failure. In step 506, information for fault cause isolation and analysis is acquired in the fault information area. Then, in step 507, the OS
1. Reload and restart. The reload here is O
OS2 only for S1 side, separated by firewall
Since the side memory is not reloaded, data can be left in the fault information area.

The OS1 monitor 115 determines that the OS1 monitor flag 40
2 is turned on (FF) ₁₆ and the monitoring process 119
The relationship of the time for checking the state of the S1 monitoring flag 402 is as follows.
It is assumed that OS1 monitoring 115 <monitoring processing 119. In addition, it is assumed that the difference is more than doubled in consideration of the processing delay.

By setting the monitoring presence / absence flag of the monitoring designation area 403 to OFF (00) ₁₆ , the monitoring process 119
1 To stop monitoring the monitoring flag 402, the OS
If 1 does not service the monitor 115 OS1112 is from turning process is expected off monitoring presence flag _{(00) 16}
By doing so, erroneous detection of the OS 1112 failure can be prevented.

In this description, the OS1 side is in the OS2 area
The S1 monitoring flag is turned on, and the monitoring process on the OS2 side causes the OS
The OS1 monitoring is realized by a method of confirming that the 1 monitoring flag is turned on. However, it is also possible to monitor the OS1 operation by sending monitoring data from the OS2 to the OS1 and monitoring the response on the OS2.

In order to prevent the OS1 reload from being repeated indefinitely due to an unrecoverable fault, if the same fault is detected for a certain period of time, for example, a plurality of times continuously on the same day,
It is also effective to suppress reloading of the OS1.

In the present embodiment, the OS1 is monitored on the OS2 side, but it is also possible to monitor the OS2 on the OS1 side. Needless to say, OS1 and OS2 can monitor each other.

[0018]

According to the present invention, when an abnormality that cannot be detected by the monitored OS itself occurs, the abnormality of the monitored OS can be detected without a separate monitoring CPU, and the recovery can be automatically performed. Becomes Further, information for fault cause isolation and analysis can be acquired in a shared memory separated by a firewall.

[Brief description of the drawings]

FIG. 1 is a diagram showing details of implementation of the present invention.

FIG. 2 is a diagram showing a configuration of a computer to which an embodiment of the present invention is applied.

FIG. 3 is a diagram showing an argument table of a function for shared memory processing.

FIG. 4 is a diagram showing a monitoring status area and a monitoring designation area.

FIG. 5 is a diagram showing a flowchart of a monitoring process.

[Explanation of symbols]

101: hardware, 102: hard disk, 10
3 ... Keyboard 104 ... Port 1, 105 ... Port 2, 107 ... CPU 111 ... Multiple OS control programs, 112 ... OS 1,1
13: Power control 114: AP monitoring, 115: OS1 monitoring, 116: System management AP 117: Firewall, 118: Pseudo non-volatile memory, 119: Monitoring process 120: OS2, 121: Takeover data, 122: Virtual hardware 123 ... Shared memory 201 AP AP 202 Shared memory processing 203 Fault information 301 to 305 Function arguments 401
~ 404… Data structure

 ──────────────────────────────────────────────────続 き Continuing from the front page (72) Inventor Toshikazu Umeto 1st Ikegami, Haruoka-cho, Owariasahi-shi, Aichi F-term in the Information Equipment Division, Hitachi, Ltd. F-term (reference) 5B042 GA22 JJ13 JJ21 KK02

Claims (2)

[Claims] A method for detecting the occurrence of a software failure in a computer having a plurality of OSs, comprising the steps of: providing a plurality of OSs to virtual hardware having a function of distributing an interrupt from hardware or a processing time of a CPU; Function to separate hardware resources and multiple OS
It has a function of enabling data writing and reading between devices, and periodically monitors the operation of the OS by writing data and checking the written data, and reloads the OS when a failure is detected. OS monitoring method by controlling between different OSs. 2. A recording medium according to claim 1, wherein software for realizing the OS is recorded and stored.