JPH0281157A - Distributed processing system - Google Patents

Abstract

PURPOSE:To ensure the matching properties between the multiplexed files despite the occurrence of a network fault by making each processor itself detect whether it is isolated from a system or not. CONSTITUTION:A process unit 103 of a processor 10 produces a message to store this in a transmission buffer 104 and then sets a timer. In the case the set timer has a time-out state, the unit 103 checks a network fault flag 110 and a circuit fault flag 115. If one or both of these flags 110 and 115 are set in the fault state, the process is interrupted and the isolated state of its own processor is displayed on a terminal connected to its own processor. Then the propriety for continuation of the process is inquired to an operator. Thus it is possible to avoid such a case where a processor isolated from a network locally updates its own file related to the file of another processor within its own processor only.

Description

DETAILED DESCRIPTION OF THE INVENTION [Field of Industrial Application] The present invention provides consistency of content between files multiplexed on different processors in a distributed processing system consisting of a plurality of processors connected by a network. This invention relates to a distributed processing method that guarantees security even in the event of network failure/recovery.

[Prior Art] In a distributed processing system that executes a series of processes in a distributed manner using multiple processors, programs that execute the same process are placed on multiple processors, and these programs are run asynchronously to speed up the processing. A method for achieving non-stop operation has been proposed, for example, as shown in Japanese Patent Application No. 173642/1983. Here, a voting method is shown for identifying multiple pieces of data asynchronously output by programs executing the same process and consolidating them into one piece of data.

[Problem to be Solved by the Invention] In the above-mentioned conventional technology, when each program that executes the same process handles each file, it is necessary to maintain consistency of content between files that are updated asynchronously by each program. However, there was a problem in that when a network failure occurred, inconsistencies would occur between the above files.

An object of the present invention is to provide a distributed processing method for guaranteeing consistency between multiplexed files even when a network failure occurs in a distributed processing system.

[Means for Solving the Problems] In order to achieve the above object, the present invention provides each processor with:
It is characterized by having (1) means for detecting whether or not an internal file is a multiplexed file, and (2) means for detecting the occurrence of a network failure and analyzing its contents.

[Operation] By means of (1) and (2) above, each processor can suppress updates of white multiplexed files when a network failure occurs, thereby ensuring consistency between multiplexed files. becomes possible.

[Example] The present invention will be explained in detail below using examples.

FIG. 2 is a diagram showing the overall configuration of a system to which the present invention is applied. 10, 20, 30... are processors that execute processing, and CRT terminals 11, 21, respectively.
．． 31...and disks 12, 22゜32...
... is connected. Each of these processors also has transceivers 15, 25, . . . for network connection.
It is connected to network 1 via 35. Note 1
In this embodiment, an example in which a path type network is applied is shown, but this may also be a ring type network. FIG. 2(b) shows the format of a message flowing on the network 1. F310, 308 are flags indicating the beginning and end of a message. CC302
is a content code that corresponds to the content and function of the data. Based on this content code, each processor determines whether the data received from the network is necessary for itself. 5A303 is the number (source address) of the processor that generated the message, and C304 is a serial number necessary for transmission. Data D306 is an airframe that stores information to be transferred by this message.
e2307 is data for error detection. Also, EN3
05 is a processing level serial number and calls an event number. The event number consists of a processor number area PN30511 and a message generation serial number area MN30512. Note that this area is large enough to store a predetermined number of pairs of processor numbers and message number serial numbers.

FIG. 1(a) is a diagram showing the internal configuration of the processor 10. Note that the processors 20, 30, . . . have the same configuration. The transmission control unit 101 is a unit for transferring data between the processor 10 and the network 1. Further, a test unit 1011 is incorporated in the transmission control unit 101 to detect a failure in the line 1010 between the transceiver 15 and the processor 10 during message transmission/reception. The transmission control unit 101 selects messages necessary for itself from among the messages received from the network based on the content code table 108 and stores them in the reception buffer 102. Also.

When the message in the transmission buffer 104 is sent to the network, it is also stored in the reception buffer 102 if the message is required by the application program within its own processor. The processing unit 103 stores the message in the reception buffer 102 in the input/output data storage area 105 and executes the program made executable by the data in the input/output data storage area 105. The program execution area 106 is an area for loading and executing programs from the disk 102. Additionally, this system allows programs to be multiplexed, placed on multiple processors, and executed asynchronously on each processor. Output message (hereinafter referred to as multiple message) will flow on the network. The processing unit 103 has the function of identifying these multiple messages based on the event number EN (305 in FIG. 2(b)) in the received message and selecting one of them.

Disk control unit 107゜terminal control unit 114
are disk 12 and processor 10., respectively. Terminal 11
This is a unit for transferring data between the processor 10 and the processor 10. The terminal processing unit l-113 takes in input data from the terminal 11 via the terminal control unit 114, converts it into a format of a message flowing on the network, and stores it in the transmission buffer 104.

This message stored in the transmission buffer is sent out to the network by the transmission control unit, and if a program that uses this message exists within the device,
It is stored in the reception buffer 102. It also outputs the terminal output data in the input/output data storage area to the terminal. The network connection flag 109 is a flag indicating whether or not the own processor can exchange messages with the input processor via the network, and the network failure flag 110 is a flag indicating whether or not a failure has occurred on the network 1. The line failure flag 115 is a flag indicating whether or not a failure has occurred in the line between the network and the processor. Note that these flags 110, 115
It is assumed that the fault detection state is set when the processor is started up.

Further, when the test unit 1011 detects a line abnormality between the processor and the network during transmission/reception with the network, it sets a failure state in the flag 115. Conversely, when failure recovery is detected, the flag 115 is reset. The own processor number storage area 111 is an area for storing a number uniquely assigned to the own processor, and the serial number area 1
12 is an area in which the terminal processing unit 113 stores a serial number assigned to a message stored in the transmission buffer. Also, a disk 12 connected to the processor 10
Inside are application programs 1000.2000 executed on the own processor and files 1500.25 used by these application programs.
00... is stored.

In addition, for each of these programs and files, whether or not they are multiplexed, that is, whether or not the same programs and files exist in the system, and if they exist, information about them is stored. Multiple information table (program = 1001, 2001...
..., File: 1501.2501.・・・・・・
) are also stored.

Next, the contents of this multiplex information table are shown in FIG. 1(b). The multiplex information table includes an area 10011 indicating the number of identical programs or files existing in the system;
and multiple programs, or.

It is composed of an area 10012 in which the processor number of the processor in which the file is stored is stored.

Next, the contents of the input/output data storage area 105 are shown in FIG.
Shown in c). Area 1 line 1051 is.

This is an input/output data storage area for the application program 1000. 10511 has input data,
Output data is stored in 10512. Program area 10513 contains a program that executes processing using input data stored in 10511 (i.e., 10
00). File area 10514
is an area indicating a file accessed by the program shown at 10513. Area 10513°10
It is assumed that the contents of 514 are set in advance.

Flag area 10515 is a flag indicating whether the program shown in 10513 can be executed. 2nd line 10
52 is an area for storing input/output data of the application program 2000. Below, areas for storing input/output data are similarly captured for each application program. Note that in the case of data to be output to a terminal, information indicating the terminal processing unit is set in the program area 10513. FIG. 1(d) is a diagram showing the format of the input data storage area 10511. In area 105111, the content code of input data is set in advance.

Area 105112 is an area for a flag indicating whether or not input data is stored.
13 is an area for storing event numbers, area 1
05114 is an area for storing the contents of the data part in the message received from the network. When the application program uses a plurality of input data, each of the areas 105111 to 105114 captures each input data. Note that the output data storage area also has the same format.

Next, the multiple message processing method in each processor will be briefly described.
Details are shown in the specification.

(1) Terminal processing unit 113 Generates a message in the format shown in FIG. 2(b) based on data input from the terminal.

At this time, the own processor number storage area (
Figure 1 (a) 111) contents in the MN part (Figure 2 (b) 3
0512), the contents of the serial number area (112 in FIG. 1(a)) are set. Also, the contents of the serial number area are increased by 1.

(2) Processing unit 103 (i) Converts a message in the format shown in FIG. 2(b) from the data output by the application program running in the event number relay program execution area (106 in FIG. 1(a)). generate. At this time, the contents of the event number area in the input message of the program are copied to the event number area in the message.

(n) The multiple message identification processing unit 103 identifies messages with the same content code and the same event number (i.e., multiple messages) from among the messages received from the network, and selects one message from among these messages. .

FIG. 3 shows an example of a case where inconsistency occurs between files when a network failure occurs in the system t1 configuration shown in FIG. 2. Figure 3(a)
shows the state when no failure has occurred. The same application program P is executed on the processor 10220, and each of these programs accesses the file F in its own processor disk. Both programs in the processor 10 and 20 also exchange data with the terminal 11 connected to the processor 10. Here, not only the output data from the internal program to the terminal 11 but also the output data from the processor 20 to the terminal 11 reach the processor 10 from the network, but these data are processed by the multiple message processing method described above. One is selected and output to the terminal 11.

Figures 3(b) and (0) show network failure,
This shows a case where a line failure occurs between the processor 10 and the network. In either case, in the conventional method, the processor 10 continues processing only within itself, so the file F8 of the processor 10 and the file F2 of the processor 20 Inconsistency occurs.

Hereinafter, the system of the present invention will be explained in detail using FIG. 4 and subsequent figures.

FIG. 4 is a flowchart showing processing when starting up each processor. When the processing unit (Fig. 1 (a) 103) starts up its own processor, the program part (Fig. 1 (C) 10513) and file part (Fig. 1 (c) 10514) of the input/output data storage area are read. , create a message with information indicating the internal application programs and the files they access in the data section (306 in FIG. 2(b)) (process 401), and store it in the transmission buffer (process 40).
2) After that, a timer for a preset time T is set (process 403). This message is attached with a content code indicating that it is startup information. This message is sent to the network by the transmission control unit.

FIG. 5 is a diagram showing the processing flow of the processing unit 103 when receiving a message from the network. The processing unit first receives a message from the reception buffer (102 in FIG. 1(a)) and determines its content code (processing 501). If this content code is the content code of the message when starting up the processor shown in Figure 4, it is determined whether or not the same file as the file shown in the data section exists within the device ( Processing 504).

If it does not exist within itself, it generates an acknowledgment message in which the source processor number of the received message is set in the data field, and sets it in the transmission buffer (process 507).

If the file exists, the multiplex information table (1501, 2501 in Fig. 1(a)) in the own disk corresponding to the file is
．． =N of i.

When the PH1 section (10011 in FIG. 1(b)) is incremented by 1, the content of the SA section (i.e., the source processor number) in the received message is registered in the PH1 section (10012 in FIG. 1(b)). 505). Next, a file response message is generated and set in the transmission buffer (process 506).
), here, the file response message is a message that has the source processor number of the received start-up message in the data section and information about the same file within the same file detected in process 505.

Next, the processing after sending the start-up information message by the processor that sent the start-up information message shown in FIG. 4 will be explained with reference to FIG. 5 as well. If there are processors with the same file in the system, the startup processor receives the above-mentioned file response information from the network.

The processing at this time is shown below. First, the processing unit
The message in the reception buffer is taken in and its content code is determined (processing 501).

If the content code indicates that it is a file response message, first determine whether or not the own processor number is set in the data section of the message (
Processing 508). If the own processor number is not set, the process ends immediately. If the own processor number is set, update the multiplex information table corresponding to the file in the own disk that is the same as the file set in the data part of the message (process 509) (the update method is the same as process 505). ).

Next, the processing when the timer set at 403 in FIG. 4 times out due to the elapse of T1 will be described below. In this case, the processing unit checks the network fault flag 110 and the @ line fault flag 115 shown in FIG. 1(a), and if both are not set to a fault state, the processing continues. On the other hand, if one or both of them are set to a failure state, processing will be interrupted, a message indicating that the own processor is in an isolated state will be displayed on the terminal connected to the own processor, and a check will be made as to whether processing can be continued. Ask the operator.

Next, the processing of the processing unit when receiving the confirmation response message will be described using FIG. 5 as well. If the content code of the received message indicates an acknowledgment message (processing 501), the network failure flag 110 in FIG.
(processing 511).

Next, the method for detecting the occurrence of a network failure in each processor will be explained in the following two cases.

(1) When executing a program from a terminal connected to its own processor (processor 10 in Figure 3) (i) Detects a failure by not receiving a terminal output message from another processor, (n) Line failure flag (
By setting 1.15) in FIG. 1(a), a line fault between the own processor and the network is detected.

(2) When executing a program using network data (i) When reading data from a terminal, a failure is detected by no response from the terminal.

(ii) Line faults are detected in the same manner as in (i) to (ii) above.

The processor that detected the failure in (1)-(i) above outputs a confirmation message with its own processor number set in the data section. This process is shown in FIG.

First, the network failure flag (110 in FIG. 1(a))
After setting the file to failure state (processing 1!i!601), among the currently accessed files, the number (first
The update of files with a value of 2 or more -F in FIG. 10111) is suppressed (processing 602). A confirmation message is immediately generated and sent to the network by setting it in the transmission buffer (process 603), and a timer for a preset time T2 is set (process 6o4). Each processor that has received this confirmation data sends an acknowledgment message (same as process 507) to the network in process 502 of FIG. The failure detection processor receives this acknowledgment message from the network.

Process 511 in FIG. 5 is performed to reset the network failure flag. Next, the failure detection processor that detected the timeout of the timer set in process 604 in FIG. continue. If it has not been reset, the process shown in FIG. 7 is performed.

Furthermore, the processor that has detected a fault in the line between its own processor and the network in (1) to (ii) also performs the process shown in FIG. 7 after setting Yamauchi multiple file update to a inhibited state. first,
Process 70 to detect an application program that accesses a file that is in a inhibited state based on the information in the program section (FIG. 1(c) 10513) and file section (FIG. 1(c) 10514) of the input/output data storage area.
1) If the detected program is running (process 7)
02), the file contents are recovered before the user program UP is executed (processing 704). Flag area 1051 of the input/output data storage area corresponding to programs detected one after another
5 is set to "impossible to execute" (processing 703).

Through the above processing, a processor that becomes isolated in the system due to a network failure will automatically update files that are multiplexed, that is, files that have the same content on other processors, only within its own processor. You won't have to do anything like that. Therefore, when recovering from a network failure and returning an isolated processor to the network, it is necessary to first stop the system and then copy the same file in the system to the multiplexed file in the restored processor. File recovery is possible.

Also, this file recovery can be done without stopping the system (
It is also possible to do this automatically. This is accomplished by detecting the cancellation of the isolated state and generating the start-up information message shown in FIG. 4 upon detection of the cancellation of the isolated state. Here, the start-up information message is generated at the following timing.

■When the network failure flag is set: When a message is received from the network ■When the line failure flag is set: Test unit (see Figure 1)
After processing 506 in FIG. 5, each processor that has received the start-up information message upon detection of line failure recovery by (a) lort) sends the contents of its own internal file, which is the same as the file in the start-up information message, to the network (file On the other hand, when the processor that generated the start-up information message receives the file copy message from the network, it stores it in its own disk. Also, from the time network failure recovery is detected until the file copy message is received, the file update message received from the network is buffered in the internal buffer, and the internal file contents are recovered based on this buffering message and the file copy message. . The file recovery method after failure recovery detection is described in detail in, for example, Japanese Patent Laid-Open No. 102342/1983.

[Effects of the Invention] According to the present invention, in a distributed processing system, a processor isolated from a network does not locally update internal files related to files in other processors only within its own processor. It becomes easier to guarantee consistency between files. Furthermore, when an isolated processor returns to the system, it becomes possible to automatically perform file rotation within this processor online.

[Brief explanation of the drawing]

FIG. 1 is a diagram showing the internal configuration of the processor, FIG. 2 is a diagram showing the overall system configuration, FIG. 3 is a diagram showing the system operation status, and FIGS. 4 to 7 are diagrams showing the processing flow of the method of the present invention. It is a diagram. CC...Contents code EN...Event number D ata...Data part 7th item Cb) (c) Cd) 2nd item (IL) υ) (A) Kaya/; wo item 2nd item

Claims (1)

[Scope of Claims] 1. A distributed processing system characterized by detecting whether each processor is isolated from the system in a distributed processing system in which a plurality of processors are integrated in a network. 2. The distributed processing system according to claim 1, wherein each processor detects whether or not its own film is related to a file in another processor. 3. The distributed processing system according to claim 1, wherein each processor determines whether or not its own program can be executed when it detects that it is isolated from the system. 4. The distributed processing system according to claim 3, wherein each processor detects that it has recovered from its isolated state.