KR20000045488A - Supervision and control method for disperse management system's obstruction - Google Patents

Abstract

PURPOSE: A supervision and control method for disperse management system's obstruction is disclosed to minimize the use of process resources and monitor each processor's daemon processor's behavior and to maintain normal service operation in case of a LAN disruption. CONSTITUTION: A supervision and control method for disperse management system's obstruction is composed of acception, execution, determination, and registration. Client requests connection to the server and the server accepts the request. The server operates the routine, executes obstacle supervision, returns the result to the client, and disconnects from the server. The failure of client's connection request indicates a problem with LAN or server process, therefore client process performs LAN disruption discrimination routine to determine whether the LAN disruption or the problem with server process caused connection failure. When finished, connection attempt is made to other server processes, the described process is repeated, and error messages of all processes of disperse management system is collected, analyzed, and registered.

Description

Fault monitoring and control method of distributed processing system

The present invention relates to fault monitoring of a distributed processing system and a control method thereof. More specifically, the present invention relates to a fault occurring in a distributed processing system in which a plurality of processors are connected to a redundant LAN to form a system and provide a service. The present invention relates to a failure monitoring and control method of a distributed processing system that efficiently monitors and notifies all processors constituting a distributed system in the event of a failure so that the failed processor does not require service processing.

Normally, distributed processing systems connected by LAN appear to be separate systems in appearance. On the service side, however, multiple processors are connected to the LAN to process a single service.

One of the conditions required for each processor constituting one distributed processing system is to overcome failures such as LAN failure, process failure, and processor failure. And be consistently aware of it. In other words, each processor constituting the distributed processing system includes a monitoring process that monitors failures in real time, collects / analyzes all failure messages generated by each processor, and reports the failure or termination to other processors constituting the distributed processing system. You need a real-time notification process. Implementing a distributed processing system with this capability ensures that services can be handled reliably without data loss in interprocessor communications even in the event of a failure.

In addition, since the main task of distributed processing systems is to handle services, and fault monitoring is part of the overall task, the process responsible for fault monitoring should be implemented so as not to affect service processing by using as little of the processor's resources as possible. .

The present invention has a client / server structure that can be efficiently used to monitor various failures occurring in a distributed processing system, and operates daemon processes operating in each processor while minimizing processor resources. Its primary purpose is to provide a method for monitoring status.

In addition, how to pinpoint which processor failed on which LAN when a LAN failed, and after the client process collects / analyzes the failure data on the processor running the server process, the failure affects service processing. In this case, the second object of the present invention is to notify another processor of a failure area and to provide a method for normal service processing even in the case of a failure.

1 is a configuration diagram of a distributed processing system,

2 is a failure monitoring circuit diagram of a distributed processing system;

3 is a LAN failure monitoring and failure message collection / analysis flow chart,

4 is a process failure monitoring flowchart;

5 is a shape table transfer flowchart.

The failure monitoring method according to the object of the present invention comprises the steps of: collecting / analyzing a failure message when implementing maintenance to notify the other processors of the distributed processing system of the failure; Collecting / analyzing fault messages to maintain a state table; When the client's connection request fails, using the errno set by the access system call and the ICMP_ECHO message of the ICMP protocol to accurately identify the LAN failure site; It attempts to connect to the next server and collects the failure message by repeating the above process, and adjusts the processor's resource usage according to the failure monitoring cycle of the client according to the load condition of the processor.

Also, according to the present invention, there is provided a method of controlling a failure of a distributed processing system, the method comprising: collecting / analyzing a failure message to maintain a state table; If a state table is changed due to a failure in a part that affects service processing, transferring the table to all processors constituting the distributed processing system to control the service not to be performed to the failed part; After collecting / analyzing fault messages using LAN2, repeating the maintenance and control steps.

In addition, the server monitors the daemon process running on each processor, the method comprising: the server receiving a connection request of the client; Passing a signal 0 to a process to be monitored by using a system call kill () provided by a UNIX system to monitor an operation state of a daemon process; And monitoring the operation of the process by using a feature in which the kill () system call returns to 0 when the process is running in the monitoring process delivery step and returns to 1 when the process is down. .

A distributed processing method having a shape table, the method comprising the steps of: a client process traversing each processor constituting a distributed processing system once; Analyzing the collected fault messages and updating a state table maintained in shared memory when the state of the part affecting service processing is changed (fault-> normal, normal-> fault); And then forwarding this table to all the processors that make up the distributed processing system.

Hereinafter, fault monitoring and a control method of the distributed processing system of the present invention will be described in detail with reference to FIGS. 1 to 5.

1 is a diagram illustrating a processor (B, B`, C, C ') for processing an intelligent network service, a processor (D) for managing service data, and a failure monitoring and operation of a distributed processing system through load sharing. It is a block diagram of the distributed processing system in which the processor A is connected by the duplex LAN.

In FIG. 1, processor A is a processor in which a client process for collecting / analyzing fault data is operated, and other processors B, B, C, C, and D are faults occurring in each processor at the request of a client. The server that monitors the server is running.

2 is a basic failure monitoring method used in the present invention, the client process collecting / analyzing a failure message performs a failure monitoring routine only when the server process requests failure monitoring, and delivers the result to the client. / How to monitor the failure of the server structure. That is, when a client requests a connection to the server, the server accepts the client's connection request (analyzes the data received from the outside and determines whether it is the desired data by judgment), and then executes a failure monitoring routine. It executes the fault monitoring activity on the fault monitoring target by transmitting the result to the client and disconnects. If the connection request of the client process fails, the LAN has failed or the server process is down. Therefore, the client process executes the LAN failure determination routine to determine whether the connection failed because the LAN failed or the server process went down. Separate. At this time, server processes running on other processors are blocked in the receiving system call until the client requests a connection.

In this way, when a client process finishes collecting / analyzing a failure message for one processor, it attempts to connect to the next server process, repeats the above process, and collects the failure messages that occur in all processors constituting the distributed processing system. The client analyzes the collected fault messages and registers them in the shape table. This shape table displays the current state of all fault monitoring targets in the distributed processing system. All daemon processes operating in the distributed processing system refer to this table to determine the state of the distributed processing system.

The client first attempts to connect to the server of each processor through LAN1 in the order of 1> 2> 3> 4> 5, collects / analyzes the fault message, updates the shape table, and then changes the shape table. In this case, the shape table is transmitted to all the processors constituting the distributed processing system, so that the service is not processed to the failed part. Next, try to connect in order of 6> 7> 8> 9> 10 using LAN2 to collect / analyze the fault message and repeat the above process.

Implementing a fault monitoring process with this structure allows you to adjust the frequency at which the client requests a connection to the server, allowing you to freely adjust the computer's resource usage, as well as monitor the LAN state as the client attempts to connect to the server to collect failure messages As a result, fault monitoring can be carried out efficiently.

3 is a method of monitoring a failure occurring in a LAN of a distributed processing system in real time as a client process accesses a server process and collects failure data when the connection is successful.

First, the client process running on the processor (A) receives the call of the receiving system by intercepting the client's connection request from other processors (B, B ', C, C', D) to collect failure data generated in the distributed processing system. Set an environment in which the server process blocked in block mode can connect in block mode (step 30).

Next, the client loads the signal and attempts to connect so that a SIGALRM signal is generated 2 seconds after attempting to connect to the server of the processor B through LAN1. This is to prevent a client attempting to connect in block (block) mode from being blocked in the access system call for a long time when a failure occurs on the LAN and the client cannot connect to the server (step 31).

If the connection is successful within 2 seconds, cancel the loaded SIGALRM signal and check if the LAN1 status of processor B is indicated as fault in the shape table. Since the LAN state of processor A and processor B are all normal, a LAN1 failover message of processor B is generated (step 32).

After a successful connection between the client and the server, the server process executes the fault monitoring routine to deliver fault data to the client process, and when the fault monitoring routine is finished, a NULL message is sent to the client to indicate that the fault monitoring routine is over. The client updates the configuration table by collecting and analyzing fault messages until a NULL message is received from the server. If a NULL message is received from the server, the client disconnects from the server running in processor B and attempts to connect to the server running in the next processor B '. If the connection is successful, the failure monitoring routine is executed as above. The failure data is collected (step 33).

In the same way as above, if the shape table is changed, all the processors that make up the distributed processing system fail by passing the shape table to all the processors that make up the distributed processing system. Make the facts recognizable (step 34).

If the client attempts to connect via LAN1, the LAN failure determination routine is executed. If the client's connection attempt fails, the client system's connection () system call is more than 2 seconds due to the server process of processor B being down and the failure of processor A or LAN1 of processor B. In this case, the SIGALRM signal loaded above is delivered to the client and the connection () system call fails. If the connection attempt fails, the client first revokes the loaded SIGALRM and checks if errno is ECONNREFUSED (239) (step 300).

If errno is ECONNREFUSED (239), since the server process receiving the client's connection request is down, a failure message corresponding to the server process failure is generated (step 301).

If errno is not ECONNREFUSED (239), a failure has occurred on LAN1 used at the time of connection, and LAN1 of processor (A) on which the client process still operates has failed or LAN1 of processor (B) on which the server process operates. It is not possible to tell whether a fault has occurred. In the present invention, the ICMP protocol of the TCP / IP protocol stack is used to solve this problem. The ICMP protocol is a ping that is used to check the network by sending ICMP packets to the processor that found the error or the router that sent the packet that caused the error. The command also uses this protocol to check the LAN state. To distinguish from a failed LAN, the client process attempts to connect and forwards the ICMP_ECHO message to the ICMP protocol of the other processor (B`) except the failed processor (B) and waits for an ICMP_ECHOREPLY message, which is a response message (step 302). ).

The ICMP protocol of the processor B` that receives the ICMP_ECHO message delivered by the client process transmits the ICMP_ECHOREPLY message to the client process of the processor A that sent the ICMP_ECHO message. If the client process receives the ICMP_ECHOREPLY message, it means that the LAN1 state of the processor A in which the client process is operating is normal, and that LAN1 of the processor B that fails the connection attempt has failed. Accordingly, the client generates a LAN1 failure message of the processor B and terminates the LAN failure determination routine (step 303).

If the client process does not receive the ICMP_ECHOREPLY message, it transmits the ICMP_ECHO message again to the ICMP protocol of the processor C other than the processors B and B` and checks whether the ICMP_ECHOREPLY message is received. It transmits ICMP_ECHO message to only one processor (B ') except processor (B), and responds to it whether LAN1 of processor (A) in which client operates or LAN1 of processor (B) in which server operates. Determining whether a failure has occurred in the failure of LAN1 of processor B occurs when LAN1 of processor B` fails, even though LAN1 state of processor A is normal (processor B). This is because it is incorrectly determined that the connection has failed and the ICMP_ECHOREPLY message has not been received from the processor B '(step 304).

If the client process does not receive the ICMP_ECHOREPLY message even in the processor C, the client process considers that LAN1 of the processor A has failed and generates a processor A LAN1 failure message (step 305).

If the client process receives the ICMP_ECHOREPLY message from the processor C, it considers that LAN1 of the processor B has failed and generates a LAN1 failure message of the processor B (step 306).

If the client's connection attempt fails without using this method, it is assumed that LAN1 of the processor (B) in which the server is operating has failed. Will incorrectly monitor LAN1 for failure

FIG. 4 relates to "daemon process monitoring", which is one of various fault monitoring routines performed after a server process receives a client process connection request. The server monitors a monitored daemon process and delivers the result to the client process. This is a flowchart that expresses the procedure as a flowchart.

In the present invention, the system call kill () provided by the UNIX system is used to monitor the operation status of the daemon process. When the kill () system call is sent to a process that wants to monitor signal 0 (which is a nonexistent signal) and the process is running, the kill () system call returns to 0 and the process is down. In this case, the method returns to 1 to monitor the operation of the process. Note that passing signal 0 to a process has no effect on the running process. If you don't use the kill () system call, you can also use the system-provided commands, such as ps and grep, and the popen () function, but this uses more processor resources than using the kill () system call. do.

FIG. 5 is a diagram illustrating failure messages collected by a client process by circulating each processor constituting a distributed processing system once and sharing when a state of a part affecting service processing is changed (fault-> normal, normal-> fault). After updating the state table held in shared memory, the table is sent to all the processors constituting the distributed processing system so that all processes running on the distributed processing system can accurately understand the operating state of the distributed processing system and provide services. This is the procedure to deliver the shape table for processing.

From the above description, the present invention can exhibit the following effects.

According to the present invention, a client process periodically requests a connection to a server process blocked in a receiving system call by using a client / server (see FIG. 2) structure for failure monitoring of a distributed processing system. By monitoring the failure to report to the client, it is possible to control the resource usage of the processor by adjusting the client's connection request cycle, and to perform the LAN failure determination function (see Figure 3) when the client's connection request fails.

The connection failure only tells the client and the server that it is unable to communicate. Specifically, it cannot distinguish between server process down, client-side LAN failure, and server-side LAN failure. In the present invention, in case of a connection failure, an error occurrence part can be accurately identified by using errno returned by a connection () system call and ICMP_ECHO and ICMP_ECHOREPLY messages of the ICMP protocol.

In addition, the kill () system call provided by UNIX is used to monitor the daemon process running on each processor so that the process status of the process can be monitored efficiently while using less processor resources (see FIG. 4).

Claims (8)

In the failure monitoring method of the distributed processing system, Collecting / analyzing a failure message when notifying failure of another processor constituting the distributed processing system to implement maintenance; Collecting / analyzing fault messages to maintain a state table; When the client's connection request fails, using the errno set by the access system call and the ICMP_ECHO message of the ICMP protocol to accurately identify the LAN failure site; Failure monitoring characterized by adjusting the resource usage of the processor according to the failure monitoring cycle of the client depending on the load status of the processor, including the step of collecting the failure message by repeating the above process by attempting a connection request to the next server Way. The method of claim 1, When the client makes a connection request to the server, after the server receives the client's connection request, the server performs a failure monitoring to deliver a failure message to the client; And performing a LAN failure determination routine to distinguish the disabled person from the LAN disabled server process if the connection request fails. The method according to claim 1 or 2, Servers operating on different processors comprise the step of blocking at the receiving () system call until there is a client connection request. The method according to claim 1 or 2, And the server performing a failure monitoring activity only when the client's connection request is successful, and forwarding the failure message to the client. In the failure control method for controlling a failure of a distributed processing system, Collecting / analyzing fault messages to maintain a state table; If a failure occurs in a part affecting the service processing and the state table is changed, controlling the service not to be performed to the failed part by transferring the state table to all processors constituting the distributed processing system; And collecting and analyzing fault messages using LAN2, and repeating the maintenance and control steps. The method of claim 5, The client first attempts to connect to the server of each processor via LAN1 in the order of 1> 2> 3> 4> 5 to collect / analyze the failure message, and then to the server of each processor via LAN2 6> 7> And collecting / analyzing a fault message by attempting a connection request in order of 8> 9> 10. In the way the server monitors the daemon process running on each processor, The server receiving a connection request from the client; Passing a signal 0 to a process to be monitored by using a system call kill () provided by a UNIX system to monitor an operation state of a daemon process; Monitoring the operation of the process by using a feature in which the kill () system call returns to 0 when the process is running in the monitoring process delivery step and returns to 1 when the process is down; Disability monitoring method, characterized in that. In the dispersion processing method having a shape table, The client process traversing each processor constituting the distributed processing system once; Analyzing the collected fault messages and updating a state table held in shared memory when the state of the site affecting the service processing is changed; And then forwarding this table to all processors constituting distributed processing.