JP2749074B2 - Distributed processing method - Google Patents

Description

DETAILED DESCRIPTION OF THE INVENTION [Industrial Application Field] The present invention relates to a distributed processing system composed of a plurality of processors connected by a network, and checks the consistency of contents between files multiplexed in different processors. The present invention relates to a distributed processing method for guaranteeing even when a network failure occurs / recovers.

[Prior Art] In a distributed processing system in which a series of processes are distributed and executed by a plurality of processors, a program that executes the same process is arranged in a plurality of processors, and the programs are executed asynchronously to execute processing. As a method for achieving non-stop, for example, a method disclosed in Japanese Patent Application No. 61-17342 is considered. Here, the multiplexed data that the program executing the same process outputs asynchronously is identified,
The voting method for squeezing is shown.

[Problem to be Solved by the Invention] In the above-described conventional technology, when each program that executes the same processing handles each file, it is necessary to maintain consistency of contents between files that are asynchronously updated by each program. However, there is a problem that when a network failure occurs, inconsistency occurs between the files.

An object of the present invention is to provide a distributed processing method for ensuring 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, in the distributed processing method according to the present invention, each processor that executes the same program asynchronously diagnoses a network failure. Then, as a result of the diagnosis, when a failure of the network is detected, each processor is characterized in that the execution of the program prevents the file from being updated. More specifically, the update of the file is inhibited by inhibiting the execution of a program that is being executed asynchronously on a plurality of processors. More preferably, the content of the file is returned to the state before the start of the program in accordance with the suppression of the update of the file.

[Operation] According to the above means, when a failure occurs on the network, the multiplexed file is not updated by the processors executing the same program. Thus, when a network failure occurs, it is possible to prevent inconsistency between the multiplexed files. Further, with the suppression of file update, the contents of the multiplexed file are returned to the state before the execution of the program for updating the file is started, thereby ensuring the consistency between the files more reliably. It becomes possible.

[Example] Hereinafter, an example of the present invention will be described in detail. FIG. 2 is a diagram showing the overall configuration of a system to which the present invention is applied. Are processors for executing processing, and are CRT terminals 11, 21, 31 and discs 12, 22, 32, respectively.
... are connected. In addition, each of these processors,
It is connected to the network 1 via transceivers 15, 25, 35 for network connection. In this embodiment,
An example in which a bus type is applied as a network is shown, but this may be a ring type network. FIG. 2 (b) shows the format of a message flowing on the network 1. F310 and 308 are flags indicating the start and end of the message. CC302 is a content code, which is a code corresponding to the content and function of data. Each processor determines whether or not the data received from the network is necessary for itself based on the content code. SA303 is the number (source address) of the processor that generated the message,
C304 is a serial number required for transmission. Data D306 is a relay storing information to be transferred by this message, and FCS307 is data for error detection. Also, EN
Reference numeral 305 denotes a serial number of the processing level, which is called an event number. The event number includes a processor number area PN30511 and a message generation serial number area MN30512. It should be noted that this area has an area capable of storing a predetermined number of pairs of a processor number and a message number serial number.

FIG. 1A is a diagram showing the internal configuration of the processor 10. .. Have the same configuration. The transmission control unit 101 is a unit for performing data transfer between the processor 10 and the network 1. Further, in the transmission control unit 101, a test unit 1011 for detecting a failure of the line 1010 between the transceiver 15 and the processor 10 at the time of message transmission / reception is incorporated. The transmission control unit 101 stores, among the messages received from the network, messages necessary for itself, in the content code table 10.
8 and is stored in the reception buffer 102. When the message in the transmission buffer 104 is sent to the network and the message is required by the application program in the own processor, the reception buffer 10
Also stored in 2. The processing unit 103 includes the reception buffer 102
Are stored in the input / output data storage area 105, and a program executable by the data in the input / output data storage area 105 is executed. The program execution area 106 is an area for loading and executing a program from the disk 102. Further, in the present system, it is possible to multiplex a program and place it in a plurality of processors, and to execute the program asynchronously in each processor. In this case, a plurality of messages having the same contents (that is, Output message: hereinafter referred to as a multiplex message) flows on the network. The processing unit 103 has a function of identifying these multiplex messages based on the event number EN (305 in FIG. 2 (b)) in the received message and selecting one of them. The disk control unit 107 and the terminal control unit 114 are units for transferring data between the disk 12 and the processor 10, and between the terminal 11 and the processor 10, respectively. The terminal processing unit 113 takes in the input data from the terminal 11 via the terminal control unit 114, converts the data into a format of a message flowing on the network, and stores it in the transmission buffer 104. The message stored in the transmission buffer is transmitted to the network by the transmission control unit, and is stored in the reception buffer 102 when a program using the message exists in itself. The terminal output data in the input / output data storage area is output to the terminal. The network connection flag 109 is a flag indicating whether or not the own processor can exchange messages with another processor via the network. The network failure flag 110 indicates 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. The flags 110 and 115 are assumed to have the failure detection state set when the processor is started. When the test unit 1011 detects a line error between the processor and the network during transmission / reception to / from the network, the test
Set the fault condition to Conversely, when failure recovery is detected, the flag 115 is reset. Local processor number storage area 111
Is an area for storing a number uniquely assigned to the own processor, and the serial number area 112 is an area for storing a serial number assigned to a message stored in the transmission buffer by the terminal processing unit 113. Also, in the disk 12 connected to the processor 10, application programs 1000, 2000,... Executed by the own processor and files 1500, 250 used by these application programs are stored.
0 ... are stored. In addition, each of these programs,
Whether or not each file is multiplexed, that is, whether or not the same program and file exist in the system, and if so, multiplexing for storing information about them Information tables (programs: 1001, 2001,..., Files: 1501, 2501,...) Are also stored. Next, the contents of the multiplex information table are stored in the first
It is shown in FIG. The multiplex information table is an area indicating the number of the same program or file existing in the system.
10011 and an area 10 for storing a processor number of a processor in which a multiplex program or a file is stored.
012.

Next, the contents of the input / output data storage area 105 are shown in FIG. The first line 1051 of the area is an input / output data storage area for the application program 1000. 10511 stores input data, and 10512 stores output data. The program area 10513 is an area indicating a program (that is, 1000) for executing a process using the input data stored in the 10511. File area 10
Reference numeral 514 denotes an area indicating a file to be accessed by the program indicated by 10513. It is assumed that the contents of the areas 10513 and 10514 are set in advance. Flag area
10515 is a flag indicating whether or not the program shown in 10513 can be executed. The second line 1052 is an area for storing input / output data of the application program 2000. Hereinafter, similarly, an area for storing input / output data is taken for each application program. In the case of data output to the terminal, information indicating the terminal processing unit is set in the program area 10513. FIG. 1D shows the format of the input data storage area 10511. In area 105111, the content code of the input data is set in advance. An area 105112 is an area for a flag indicating whether or not input data is stored, an area 105113 is an area for storing an event number, and an area 105114 is for storing a data part content in a message received from the network. It is an area to do. When the application program uses a plurality of input data, the areas 105111 to 105114 are set for each input data. The output data storage area has the same format.

Next, a brief description will be given of a multiplex message processing method in each processor. The following multiplex message processing method is described in detail in, for example, Japanese Patent Application No. 61-17342.

(1) Terminal processing unit 113 A message having the format shown in FIG. 2 (b) is generated from the data input from the terminal. At this time, the PN part of the event number area in the message (FIG. 2 (b) 30)
511) in its own processor number storage area (111 in FIG. 1 (a))
The contents are set as the serial number area contents (112 in FIG. 1 (a)) in the MN unit (30512 in FIG. 2 (b)). Also, the contents of the serial number area are increased by one.

(2) Processing unit 103 (i) Event number relay A message in the format shown in FIG. 2 (b) is converted from the data output by the application program being executed in the 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.

(Ii) Multiple message identification The processing unit 103 identifies messages having the same content code and the same event number (that is, multiple messages) from the messages received from the network, and selects one message from these. .

FIG. 3 shows an example of a case in which inconsistency occurs between files when a network failure occurs in the system configuration shown in FIG. Fig. 3 (a)
Shows a state where no failure has occurred. The same application program P for processors 10 and 20
If you are running _1, each of these programs are each accessing the file F ₁ in the own processor disk. Further, both programs in the processors 10 and 20 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 arrives at the processor 10 from the network. Is selected and output to the terminal 11.

FIGS. 3 (b) and 3 (c) show a case where a network failure and a line failure between the processor 10 and the network have occurred. In any case, in the conventional system processor 10 for thereby continues processing only in its own, mismatch between the file F ₂ files F ₁ and processor 20 of the processor 10 occurs. Hereinafter, the method of the present invention will be described in detail with reference to FIGS.

FIG. 4 is a flow chart showing processing when each processor is started. When the processor is started, the processing unit (Fig. 1 (a) 103) first reads from the program section (Fig. 1 (c) 10513) and the file section (Fig. 1 (c) 10514) of the input / output data storage area. After creating a message in the data section (306 in FIG. 2 (b) 306) containing information indicating its own application programs and the files to be accessed by them (process 401) and storing them in the transmission buffer (process 402),
Setting the pre-set time T ₁ of the timer (processing
403). This message has 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 a processing flow of the processing unit 103 when receiving a message from the network. First, the processing unit fetches a message from the reception buffer (102 in FIG. 1A), and determines the content code of the message (processing 501). If the content code is the content code of the message at the time of starting the processor shown in FIG. 4, it is determined whether or not the same file as the file indicated in the data part exists in the self (see FIG. 4). Process 504). If it does not exist in itself, generate an acknowledgment message in which the source processor number of the received message is set in the data section,
It is set in the transmission buffer (process 507). If the file exists, the NO section (FIG. 1 (b) 10011) of the multiplex information table (FIG. 1 (a) 1501, 2501,...) Corresponding to the file is incremented by 1, and the PNO section The content of the SA part in the received message (that is, the source processor number) is registered in (FIG. 1 (b) 10012) (process 505).
Next, a file response message is generated and set in the transmission buffer (process 506). Here, the file response message is a message having, in the data part, the source processor number of the received start-up message and the information of the same file detected in the process 505.

Next, the processing of the processor that has transmitted the startup information message shown in FIG. 4 after the startup information message has been transmitted will be described with reference to FIG. When there is a processor having the same file in the system, the start-up processor receives the above-described file response information from the network. The processing at this time will be described below. First, the processing unit fetches the message in the reception buffer into itself, and determines its content code (processing 50
1). If the content code indicates that the message is a file response message, it is first determined whether or not its own processor number is set in the data portion of the message (process 508). If the own processor number has not been set, the processing ends. If the own processor number is set, the multiplex information table corresponding to the file on the same own disk as the file set in the data part in the message is updated (process 509) (the update method is the same as that of process 505) ).

Next, a process when the timer set in FIG. 4 403 times out by T ₁ elapses below. In this case, the processing unit checks the network failure flag 110 and the line failure flag 115 shown in FIG. 1A, and if both are not set to the failure state, the processing is continued as it is. Conversely, if either or both failure states are set, the processing is interrupted at that point, the terminal connected to the own processor indicates that the own processor is in an isolated state, and whether or not processing can be continued. Ask the operator.

Next, the processing of the processing unit when the acknowledgment message is received will be described with reference to FIG. If the content code of the received message indicates an acknowledgment message (process 501), the network fault flag in FIG. 1 (a) 110 is reset (ie, indicating a no fault condition) (process 511).

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

(1) When a program is executed from the own processor connection terminal (processor 10 in FIG. 3) (i) A failure is detected by not receiving a terminal output message from another processor.

(Ii) Since the line fault flag (115 in FIG. 1A) is set, a line fault between the own processor and the network is detected.

(2) At the time of executing a program using network data (i) At the time of reading data from a terminal, a failure is detected without a response from the terminal.

(Ii) A line fault is detected in the same manner as (i)-(ii) described above.

The processor that has detected the failure in the above (1)-(i)
Outputs a confirmation message in which the own processor number is set in the data section. This process is shown in FIG. First, after setting the network failure flag (FIG. 1 (a) 110) to a failure state (process 601), the value of NO (FIG. 1 (b) 10111) in the multiplex information table of the current access file is 2 The above file update is suppressed (process 602). Then it generates a confirmation message, sent to the network by setting the transmission buffer (step 603), advance the timer set in the set time T ₂ (step 604). Each processor which has received this confirmation data sends an acknowledgment response message (same as the processing 507) to the network by the processing 502 in FIG. The failure detecting processor that has received the acknowledgment message from the network executes the processing 51
Perform 1 to reset the network fault flag. Next, upon detecting the timeout of the timer set in the process 604 of FIG. 6, the failure detection processor checks the internal network failure flag, releases the file update inhibition if the flag has been reset, and proceeds with the process as it is. continue. If it has not been reset, the processing in FIG. 7 is performed.

In addition, the processor that has detected a failure in the line between the own processor and the network in (1)-(ii) also performs the processing in FIG. 7 after the update of the internal multiplex file is suppressed. First, an application program that accesses a file in the inhibited state is detected from information in the program section (FIG. 1 (c) 10513) and the file section (FIG. 1 (c) 10514) of the input / output data storage area. (Process 701) If the detected program is being executed (Process 702), the file contents are recovered before the execution of the user program UP (Process 70).
Four). In the flag area 10515 of the input / output data storage area corresponding to the program detected one after another, “executable” is set (process 703).

As a result of the above processing, a processor that has become isolated in the system due to a network failure can arbitrarily update only multiplexed files, that is, files in which the same content exists in other processors, only in its own processor No more. For this reason, when recovering from a network failure and returning an isolated processor to the network, the system must be temporarily stopped, and the multiplexed file in the restored processor must be copied only by copying the same content file in the system. Recovery is possible.

It is also possible to perform the file recovery automatically without stopping the system. This is achieved by detecting the elimination of the isolated state in the isolated processor and generating the startup information message shown in FIG. 4 when the elimination is detected. Here, the startup information message is generated at the following timing.

When a network failure flag is set: When a message is received from the network When a line failure flag is set: When a line failure recovery is detected by the test unit (1011 in FIG. 1 (a)).
After the diagram processing 506, the contents of the local file identical to the file in the startup information message are sent to the network (file copy message). On the other hand, when the processor which has generated the startup information message receives the file copy message from the network, it stores it in its own disk. Also, a file update message received from the network is buffered in its own buffer from the detection of the recovery from the network failure to the reception of the file copy message, and the contents of the file are recovered based on the buffering message and the file copy message. . The file recovery method after the detection of the failure recovery is described in detail in, for example, JP-A-62-102342.

[Effects of the Invention] According to the present invention, in a distributed processing system, a processor isolated from a network does not locally update an internal file related to a file in another processor only in the own processor. It is easy to ensure consistency between files. Also, when an isolated processor returns to the system, it is possible to automatically perform the file sequence in this processor online.

[Brief description of the drawings]

FIG. 1 is a diagram showing the internal configuration of the processor, FIG. 2 is a diagram showing the entire system configuration, FIG. 3 is a diagram showing the system operation state, and FIGS. 4 to 7 show the processing flow of the method of the present invention. FIG. CC: Content code EN: Event number Data: Data section

 ──────────────────────────────────────────────────の Continuing on the front page (72) Inventor Yasuo Suzuki 1099 Ozenji Temple, Aso-ku, Kawasaki City, Kanagawa Prefecture Inside Hitachi, Ltd.System Development Laboratory Co., Ltd. (72) Katsumi Kawano 1099 Ozenji Temple, Aso-ku, Kawasaki City, Kanagawa Prefecture (72) Inventor Yuko Teranishi 1099 Ozenji Temple, Aso-ku, Kawasaki City, Kanagawa Prefecture Hitachi Systems Co., Ltd. (72) Inventor Masuyuki Takeuchi 5030 Totsukacho, Totsuka-ku, Yokohama-shi, Kanagawa Prefecture Inside Hitachi Software Co., Ltd. (72) Inventor Yoshihiko Higuchi 5030 Totsukacho, Totsuka-ku, Yokohama-shi, Kanagawa Prefecture Inside Hitachi Software Co., Ltd. (56) References JP-A-62-169266 (JP, A) JP-A Sho 58-182778 (JP, A) JP-A-62-98445 (JP, A)

Claims (1)

(57) [Claims] 1. A distributed processing method in a distributed processing system in which a plurality of processors are connected via a network and each processor executes a plurality of programs, wherein each processor is provided with each file existing in its own processor. The first processor holds first information for identifying whether or not another processor has a file of the same content. For each program executed by the own processor, the first information for identifying a file accessed by the program. In response to the detection of the network failure in any one of the processors, the other processor refers to the first information in the processor that has detected the failure, and causes another processor to copy a file having the same content. The file which has the update is set in the update inhibition state, and the processor that detects the failure refers to the second information. Detects a program that accesses a file in the update-inhibited state, and if the detected program is not running, sets the detected program to the non-executable state on the processor that detected the failure, and executes the detected program. If the failure is detected, the processor that detected the failure recovers the contents of the file accessed by the detected program to the contents before the execution of the program, and sets the program to an unexecutable state. Distributed processing method.